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 -- 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
