Re: [Libreoffice] [Libreoffice-ux-advise] Suggestion and patch for "Confirmation of save format" dialog

Hi Josh, Astron, all!

Astron, although you've already replied to this mail (thanks!), I'd like
to pick one point from Josh - there is nothing more I can do today ;-)

Am Montag, den 15.08.2011, 22:41 +0930 schrieb Josh Heidenreich:
[...]
> > ... Without a good reason, it is not much fun to break the
> > user's his workflow. So my proposal is to go ahead as soon as
> > possible ... and discuss such non-modal dialogs we need (and miss) quite
> > frequently. In our case, it could be saving to WhatEver format and then
> > telling him afterwards (for a few seconds) that ODF might have been the
> > better format.
>
> We have to be careful to not be condescending to the user though, or
> make them feel bad or guilty that they chose the "wrong" format. There
> is plenty of reasons to choose a non-odf format.

Maybe some misunderstanding at this point? In my opinion, the today's
dialog already tells our users that ODF is the better format - without
any good reason, because we don't really know.


> Really, I think we should all remember two things:
>
> 1. The best way to "fix" this dialog is to have the filters do a
> better job of saving in other formats. If it only came up for formats
> which actually destroyed formatting, like TXT, wouldn't that be great?
> We should always keep that as a primary goal rather than this dialog.

Yep, I totally second that - but that requires some changes within
LibreOffice/OpenOffice.org. The two things I've noticed over the years:
there is still misunderstanding/confusion what this dialog is about (or
why it disturbs without any good reason), and the technical limitation
of identifying serious issues (like destroyed formatting).

Because of the latter, people (including myself) had to "work around"
those technical limitations - resulting in this dialog, ambiguous clues,
broken workflows. Although we're not solving the root cause (which I'd
love to do), it is still better than people having screwed up documents.

> 2. This shouldn't be seen as an attack on developers of other
> projects, but there have been recent large changes in the Open
> Source/Free Software world, in regards to UI design (and also in
> propriety software), which have brought a lot of complaints for no
> reason. Lets not make changes for the sake of making changes. I'm not
> going to point the finger or anything, but I have noticed a lot of
> outcry about Gnome 3, KDE 4, Office ribbon, Ubuntu, Firefox, etc.
> It seems to be popular at the moment to just make changes for the sake
> of it, and it really confuses and often annoys users. I'm not saying
> these projects are bad or we are going in the wrong direction, but we
> all need to vigilant to ensure we don't make fatal UI mistakes, and
> while non-modal may seem like the best thing from a UI design
> perspective, if it's not what users are expecting, it's still no good.

Wow, this would require a multi-dimensional answer ... but I don't know
whether this helps, since it seems to me that we are both on the same
side. Changes for the "sake of change" are bad for those who rely on
consistency and stability - especially in our "office productivity"
world. The word "productivity" is important here - the aim is to make
working with the software more efficient. And there is much we can do
(good and bad).

All of the products you've named do have some excellent UI solutions ...
and some introduced issues people are (for good reasons) unhappy with.
So the simple answer (example) is: design, test, iterate, ... implement
it for production use. Well, that requires time, skills, tools, and dev
support.

And sometimes the right framework. Concerning our initial discussion
about the "Confirmation of save format" dialog, here is one example: the
non-modal messages. Every month, the answer on an issue is to turn it
into non-modal feedback. Every month it is said that for that (single)
problem it is not worth the effort. So, every month we go for a
sub-optimal solution. Since years. I consider this a real issue ...
although the possible solution might have changed over the years ([1]
shows a design I've started 4 years ago, scroll doooown, please).

Looking forward - what can we do? (My answer: go to sleep *g*)

Cheers,
Christoph