Heinz, You brought up underlying issue of what is a good design for a user interface. The best I can say is that are general guidelines/rules that are followed. But one must determine when it is best to break or bend the rules for a better user interface.
On Wed, 2011-04-20 at 21:27 +0200, Sparkling Specks wrote: > 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<[email protected]>: > >>>>>> 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 > >>> [email protected] > >>> > >>> -- > >>> Unsubscribe instructions: E-mail to [email protected] > >>> 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. > -- Jay Lozier [email protected] -- Unsubscribe instructions: E-mail to [email protected] 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
