For most of our customers, how computers work inside is magic... they do not want to know how it works. Entering into a setup page is a crazy thing to do, the computer will surely break down.

For them, if double clicking in the file does not go to where it went yesterday, what is broken is the application (you broke my MS Word, it does not work any more). They do not know any other way to access that application.

In migration processes, you have to install the new applications and then manage the change process. Forcing change from one day to the next might fully break the process and the migration will fail because the new application will be rejected by users who have not yet been trained.

In my opinion AOO needs to have (even for legal reason, maybe) the user click on something that says that they accept the associations (or not) as it used to have. For silent installation, there should be an option to do it or not.

I think that the idea of allowing the change from the application itself is very good. Users like to use the application... not mess up with the system.

Cheers,

Javier





On 6/6/12 7:07 PM, Shenfeng Liu wrote:
One more question is: what's the behavior in 3.3? In my desktop, doc was 
auto-associated to AOO 3.4, but not ppt or xls. It does not look like an 
intentional design. If it is just a regression, I will suggest to simply 
rolling back to 3.3 for now.

- Simon

发自我的 iPhone

在 2012-6-6,17:07,"O.Felka"<olaf-openoff...@gmx.de>  写道:

Am 06.06.2012 10:33, schrieb Shenfeng Liu:
Juergen,
   Agree with you!
   My personal opinion is that it must be an explicit place for user to
choose the file association, in installer, or option dialog...
   Well, we need UX experts here...
We should be aware that file association written by the Options dialog won't be 
removed by the setup.
The setup doesn't know the registry keys written by the application.


Groetjes,
Olaf

- Simon



2012/6/6 Jürgen Schmidt<jogischm...@googlemail.com>

On 6/6/12 4:17 AM, Shenfeng Liu wrote:
As I remember, it is the 2nd customer complaint we got on this issue. And
some of us (e.g. Jihui) has confirmed it. If that's the case, my question
is do we have a defect id to trace it? If no, let's create one. And I
will
suggest it as 3.4.1 must fix.

an issue is good but we should be careful and should define a potential
new default in detail. How exactly we want define the new default,
having 2 complaints is not much compared to thousand of Windows users.

I don't say that we shouldn't change it but we should be clear of what
we are doing. We can't change things every time when 1 single person
don't like the default.

Juergen


Reply via email to