Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons

Hi Aaron, all!

Am Mittwoch, den 20.04.2011, 21:27 +0200 schrieb Sparkling Specks:
> Hello,
>
> wow, this has gotten out of hand, ha.

;-) Hehe, depends on the topic ...

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

Wow!

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

Let's re-counter ... it indeed plays a role, since this "Play/Pause"
buttons has caused loooong discussions within the Rhythmbox project some
years ago (if I remember correctly).

But today (at least in the version of Rhythmbox I use), it doesn't
change the button caption - the button simply stays pressed until it
gets clicked again.

To me, this kind of behavior is a rare exception ... along with the
behavior of some video players out there.


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

Mmh, even if it would be in line with the HIGs, I think the behavior
already gets a bit too complex if it is just about replacing a button.
Please read on ...


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

A very similar concept is already available in Microsoft Office since
2007 - so we might assume that some people are aware of that. But - the
Microsoft Office advantage - it is usually less needed to tweak such
formatting, since the supplied "Designs" already cover a broad range of
user needs. Finally, if something works really well and there are
*really* good reasons for that, then we might break the rules (a bit).
(Please don't ever cite me *g*)

I also thought further about this issue - we have to clearly separate
between different types of dialogs (thus: actions). If its something
that can easily be reverted, then we might use the "instant apply
thing". If the action can't be undone (weird example, but I think it is
understandable: printing), or if it would imply bad behavior (as Ricardo
mentioned) it has to be the classical OK / Whateveraction button.


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

True - just a personal question. Since when have you been OOo/LibO user?
Sounds if you have been around for quite some time. Being silent ;-)

The reason for OOo to behave like "OOo" was, that the specification and
implementation effort was quite limited. So they relied on something
that had to work everywhere okay ... tweaking the keyboard shortcuts,
the visual appearance (but: not the button order for example). Still,
there has to be agreement within the LibO community how we want to
handle that ... since it also implies effort. But that shouldn't stop us
here.

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

I feel the same way - and with regard to the earlier proposal. Since
I've proposed to use a non-modal dialog, the "normal" undo button should
work well enough. Although the "Reset" button behavior is difficult
enough to handle.

Finally - Aaron, would you be interested to put together the information
about the "H|CR[S]" proposal and to make a visually rough mockup [1]?
That would be amazing! As I announced some hours ago, we have now a
whiteboards section :-) [2]

Cheers,
Christoph

[1]
http://uxopenofficeorg.blogspot.com/2010/05/picture-is-worth-thousand-words.html

[2] http://wiki.documentfoundation.org/Design/Whiteboards

> 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