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

Hi,

On Wed, Apr 20, 2011 at 11:22 PM, Christoph Noack
<christoph@dogmatux.com> wrote:
> Hi Aaron, all!
Oh my, so this is what my penchant for having so many online personas
leads... Going forward, I will be Aaron/Astron.

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

Hm, the 0.13.1 version I have shows a pause symbol once music is
playing. I tried with a Gnome 3 CD, but sadly Rhythmbox wasn't
included, maybe it's not actually Gnome-3 ready.

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

That's how it's solved in other applications, too. And it's reasonable.

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

I think the first version of StarOffice I've used was 5.1 on Red
Hat/Gnome 1 desktop at school,
but I'd been mostly using Office 2000 at home until around 2006. The
first version of Ooo I was genuinely excited about must have been 2.3
or 2.4, when it became easy to select a different language in Writer.
I haven't been completely inactive, I think I filed two bugs there.
One about custom colours being deleted, the other about having a
toolbar symbol to easily turn on columns in Writer.

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

I'll try to get something done over the weekend.

Later, astron.



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

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