Hi A...stron :-) Am Freitag, den 22.04.2011, 00:20 +0200 schrieb Astron: > On Wed, Apr 20, 2011 at 11:22 PM, Christoph Noack > <christ...@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.
Hehe, I just picked what I found, because I - personally - prefer real names if I talk with people (even if its online stuff). > > 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. Ah, okay, I have an older version of Rhythmbox ... but the question is whether this is what the majority of users expect and whether it is okay from the platform's point-of-view. Concerning the former one, it is hard to say - are the few people on the mailing the users, or the thousands (in our case: maybe millions) the ones to consider. Concerning the platform - this behavior is wrong with regard to Gnome 2 HIG. I think - if developers cooperate with us - we have great responsibility to consider those people who are not on this list. :-) For us, it is more difficult. The Play/Pause stuff is rather non-destructive and is more closely related to each other. Apply/Reset is very different and may lead to unintended information loss by users. So I'm happy if we can go with a better solution. [...] > > 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. Wow, cool! Then you've seen many changes over the years, I think. > > 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. Pretty cool! Go go go :-) It's much easier to discuss and to improve ... > Later, astron. Cheers, Christoph > >> 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<christ...@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 > >> >>> jsloz...@gmail.com > >> >>> > >> >>> -- > >> >>> Unsubscribe instructions: E-mail to design+h...@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+h...@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
