Hi, On Wed, Apr 20, 2011 at 11:22 PM, Christoph Noack <[email protected]> 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<[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. >> > > > > -- > 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
