Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hello,

wow, this has gotten out of hand, ha. Sorry for not answering for so
long -- school kept me busy today. Anyway, the animation was indeed
made with screenshot tool and GIMP, the red circles and some text were
made in Inkscape -- that was quite tedious.

Okay, to counter some of the criticism: the rule against buttons
changing their role seems to play less of a role, today, see for
instance Rhythmbox's current Play/Pause button. But, you are right, it
is not too discoverable that the button has changed and why it has
changed. And, of course, it's probably against (only an example) Gnome
2 HIG.
To make the change in state more discoverable, I proposed an icon in
the Apply/Revert button in the original bug -- probably also against
most modern HIGs.

Of the other ideas, the one I think would probably work best, is the
one by Christoph (Help | Close, Reset, [Standard]) -- but I think it
could alienate Windows users who are not used to the concept of
applications automatically applying different settings as you enter
them. It would surely be the way to go, if LibO was Gnome/Mac-only
software. And if on these two platforms this change could be done that
would be great -- I know OpenOffice.org never was the product that
tried to mimic the platform it ran on too much, but rather relied upon
(partly legacy) Windows behaviour.
About the proposal to put an Undo button behind every single item I am
unsure, as I can't think of a precedent of this being done and as I
think it would mostly add clutter to the dialogues.


On 20/04/11 17:09, planas wrote:
Vamsi and All,
On Wed, 2011-04-20 at 09:52 -0400, Vamsi Kodali wrote:

Hello everyone!
I am a little late to join the party...
Heinzs, it is indeed a very nice animation. I too would like to know how you made it.

I was wondering if we could move the 'Revert' button next to the setting itself instead of 
keeping it next to the standard Close, Reset, etc buttons at the bottom of the dialog box. See a 
picture here: http://flic.kr/p/9A9rWR The 'Undo' buttons next to each of the settings will be 
inactive and grey unless there is a change at which point they become active and clickable.

I know that this will increase the number of buttons by large proportions (after all, the 
discussion intends to 'reduce' the number of buttons in the first place) but I feel that this 
arrangement will give the user the flexibility to finely adjust the settings after applying. For 
example, in the picture, user changes the 'Before Text' option followed by 'After Text' option 
and then 'First Line' option only to realize that (s)he does not want the 'Before Text' option. 
In such a case, the user just has to go to the 'Before Text' option to revert it.

Vamsi.

On Apr 19, 2011, at 6:36 PM, planas wrote:

Hi Christoph,

On Tue, 2011-04-19 at 23:41 +0200, Christoph Noack wrote:

Hi Ricardo!

Am Dienstag, den 19.04.2011, 23:36 +0200 schrieb RGB ES:
2011/4/19 Christoph Noack<christoph@dogmatux.com>:
Let's assume that any change within this dialog applies the changes
immediately (reasonable with regard to today's computational power).

Uhmm, there are not-so-difficult cases on which this could not be
true. Suppose you have a complex document of a couple of hundreds of
pages with several images, tables, embedded objects and so on. You
then edit the default paragraph style because you need to change font,
but instead of clicking on "Liberation Serif" you accidentally click
on "Liliput steps" (common problem if you only have a touchpad), a
really wide (and ugly) font: if the change apply immediately then the
whole layout will be changed immediately, with all your images and
tables jumping to the following pages... writer could be quite slow on
complex documents and fixing this wrong click could take even minutes.
In fact I don't like at all the "apply immediately" paradigm: it could
be quite dangerous.
Cheers

 From my point-of-view, that can be easily solved ... if a document
becomes complex, or if the setting itself might have an unwanted impact,
then the system might delay the update until the user did not change
anything for XXX ms. Similar things are done within websites (e.g.
Google with their Instant Search).

For example, and if I remember correctly, the same has been done for the
new chart component. The "live view" is updated after 3 seconds ... Do
you agree?

Good point nevertheless :-) To me this seems to emphasize that some
reasonable description of the intended behavior is a must before
reaching out to the development.

Cheers,
Christoph



Good point about we need to describe what should be done. One idea would
be to have preview window showing the changes before they are accepted.
I tend to prefer delaying the change, if possible, until the user clicks
"OK". But if users are acclimated to a system delay before the changes
are implemented, it might work well if we select the correct delay.
--
Jay Lozier
Jslozier@gmail.com

--
Unsubscribe instructions: E-mail to design+help@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/design/
All messages sent to this list will be publicly archived and cannot be deleted



I think the idea was to make the form less confusing. With bottom
buttons it would not be obvious what an "Undo" button would undo. The
idea of moving the "Undo" next to the control it is linked to is good,
it is obvious to the user what will be changed. It is more programming
and buttons but it may end up being easier to do.

-- 
Unsubscribe instructions: E-mail to design+help@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/design/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.