Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
My position on this is, that once we provide Revert or Undo button, we'll (logically) have to add a Redo button, too. So, another idea could again be a dual button, this time [ ← | → ] (the icons should be those the global Undo/Redo function uses, too) -- these would duplicate only those parts of global Undo/Redo that concern the current dialog (e. g. what you were thinking about). I've updated the Wiki page to reflect this change. It's of course still at http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout Astron. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi all, when I first subscribed to this list a couple of months ago, I had that beatiful idea of helping new users to learn and use styles instead of direct formatting. I since have educated myself a little (this list helped a lot), only to find this is a much more difficult task that I first divised, and that maybe people didn't want to be educated in the same line as I thought they should. That said, I've been following this discussion closely, and want to add my two cents: Astron proposition looked pretty good to me, kudos. And I'm with Christoph, astonished by the options and questions raised. I also believe a 'Revert' function is necessary, and remembered Gimp has one in almost every dialog, and that it works very well and intuitively (but they don't have multiple tabs dialogs as LibO). I didn't understand the Version 1 and Version 2 thing, though. Version 1 seems very sane and usable, but is it in substitution to the 'Revert' function? Besides, will 'Revert' take back all active tab modifications (as of today), or all dialog modifications (less intuitive, but perhaps more useful)? I suppose incremental modifications can be left to the Undo function. Plus, I strongly believe we should have 'Automaticaly update this style when formatting is changed directly' right in the formatting or main toolbar, in addition to being able to set it in the Style dialog. This would allow very fast modification of styles, including indentation, without people having to go too often to the dialog: as much as it is already getting improved, it's still a dialog (and generally you have to go through 'Styles and Format window' before getting to it). So if you could just mark 'Automatically update...' in the toolbar, and unmark it after wanted modifications are done, one could easily format a one page document only using styles. I reckon he could get a little confused if he forgets to unmark the option, but at least it's in front of him, so he could easily spot the source of confusion (the way it is nowadays, one could go hours without noticing the 'Auto-update' option in the dialog). Of course the phrasing could be better (this will be a though one) but the gains would be enormous. What do you think? Cheers. Rafael./ -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
I didn't understand the Version 1 and Version 2 thing, though. Version 1 seems very sane and usable, but is it in substitution to the 'Revert' function? Me, I must admit I didn't really understand version 2, either. Take another look at the wiki page: I killed it yesterday. Basically, my proposal is to replace a dedicated reversion functionality by the ability to remove single part of styles from the style, e. g. only the font family etc. (which seems to me more useful than simply duplicating undo/redo). Additionally, global undo/redo should work. Adding a dedicated [Revert] button to the dialog also wouldn't make much sense (at least to me -- if you anyone can explain its function well, it would be added to the proposal again), because users would not learn that global undo/redo works, and thus would find themselves limited to undoing single changes. Plus, I strongly believe we should have 'Automaticaly update this style when formatting is changed directly' right in the formatting or main toolbar, in addition to being able to set it in the Style dialog. This would allow very fast modification of styles, including indentation, without people having to go too often to the dialog: as much as it is already getting improved, it's still a dialog (and generally you have to go through 'Styles and Format window' before getting to it). Great idea, I think. But: I'm unsure how to do this without confusing users who haven't learned that function yet. I think a problem would be properly coupling that symbol/checkbox with the style selector. It would also be an additional proposal that belongs to neither the button proposal nor the redesign of the Paragraph Style dialog. Maybe you want to add this to the Whiteboard? 'Auto-update' option in the dialog). Of course the phrasing could be better (this will be a though one) but the gains would be enormous. Yes, that's the second problem with your proposal: how do you create an icon/phrasing for this function? -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
On Tue, 19 Apr 2011 05:56:40 -0700, Sparkling Specks heinzless...@googlemail.com wrote: Hi, In the upcoming 3.4 release there will be an additional button in dialogs, Apply, to apply changes made in dialogues without closing the dialogue. This new button means that now there are five or six buttons on the bottom of many properties dialogs, OK, Apply, Cancel, Reset, (Default), Help. Yes, please, let's simplify this. In an attempt to cut that number down again, I want to propose combining the Apply and Reset buttons. There's a bug about that here: https://bugs.freedesktop.org/show_bug.cgi?id=36112 , an animation to show the feature ( https://bugs.freedesktop.org/attachment.cgi?id=45456 ) is attached to the bug -- please excuse its amateurish execution. I like the mockup at http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout It moves [Help] to the left. It doesn't have anything to do with any kind of action the user is trying to achieve, and the more the user learns, the less helpful the button is. So let's move it out of the way, to the left. Also, the [Default] button is moved to the organizer. There's where it should be. It appears that, under that mockup, the user can remove individual attributes, so a [Default] button, or whatever is named, could shamelessly clear all attributes. Also, [Revert], can be removed in favor of making the dialog work with Undo/Redo. You can only cancel by pressing 'Escape'. If you want to use the mouse, Undo as many times as needed. I like that. I would only add an [Apply] button before [Close] and NOT auto-apply whatever mistake I make on the dialog. It is bad for performance. It is also not scalable. The longer the document, the longer it will take for _every_ _single_ _change_. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi Octavio, all! Thanks for joining this discussion :-) Am Dienstag, den 26.04.2011, 11:28 -0700 schrieb Octavio Alvarez: On Tue, 19 Apr 2011 05:56:40 -0700, Sparkling Specks heinzless...@googlemail.com wrote: Hi, In the upcoming 3.4 release there will be an additional button in dialogs, Apply, to apply changes made in dialogues without closing the dialogue. This new button means that now there are five or six buttons on the bottom of many properties dialogs, OK, Apply, Cancel, Reset, (Default), Help. Yes, please, let's simplify this. In an attempt to cut that number down again, I want to propose combining the Apply and Reset buttons. There's a bug about that here: https://bugs.freedesktop.org/show_bug.cgi?id=36112 , an animation to show the feature ( https://bugs.freedesktop.org/attachment.cgi?id=45456 ) is attached to the bug -- please excuse its amateurish execution. I like the mockup at http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout It moves [Help] to the left. It doesn't have anything to do with any kind of action the user is trying to achieve, and the more the user learns, the less helpful the button is. So let's move it out of the way, to the left. Still in discussion, because it's currently against our numerous old dialogs ... Also, the [Default] button is moved to the organizer. There's where it should be. It appears that, under that mockup, the user can remove individual attributes, so a [Default] button, or whatever is named, could shamelessly clear all attributes. Also, [Revert], can be removed in favor of making the dialog work with Undo/Redo. We've talked about that earlier, but it might be helpful for any direct formatting (e.g. paragraph formatting) and essential for styles (e.g. paragraph styles). Why? Because use a dialog to format a bunch of things, or to iterate some settings. Providing them Revert helps to form a logical step - all changes made when the dialog was open / has been used on a certain object. But this should be checked with real users ... or at least with a prototype, if we can't solve it by exchanging thoughts. If the lessbuttonsapproach dialog can be used for styles (I still think whether it will work at all), then Revert might be essential. People will rather set back a value (e.g. font size) instead of using the faaar away undo button - but this sets a real value instead of (in most cases) inherit the value from the parent style. You can only cancel by pressing 'Escape'. If you want to use the mouse, Undo as many times as needed. I like that. I would only add an [Apply] button before [Close] and NOT auto-apply whatever mistake I make on the dialog. It is bad for performance. It is also not scalable. The longer the document, the longer it will take for _every_ _single_ _change_. Please see: http://www.mail-archive.com/design@libreoffice.org/msg01615.html Mmh, sorry, I have to stop the good discussions today ... you see in half an hour what I'm referring to :-) Regards, Christoph -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi Christoph, all I just want to add an idea - not even thought to the end, but perhaps some valuable input to reduce the numbers of buttons... It's not too different to Heinzs/Astron's proposal when he started the thread, but avoids name changes on the buttons.: [Help] needs quite a lot of work, but I think it i reasonable to place it at the left border in every dialog. If you click on it, you will get a help window, while the dialog stays open. But this is no button to discuss about (except the position). What I would like to be discussed is an easy to be used multi-function [Apply] button: It should get a two-state behavior: Depending on a pre-defined option it's standard state is pressed (leading to changes preview on the fly) or released (changes are only visible when the button is pressed during your work). Clicking on the pressed button leads to reversion of the just added changes (can be indicated by mouse-over) in the document - and with a double-click, all changes are reverted in the dialog too. This is clearly indicated by changing the button's style from pressed to released. Clicking on the released button applies the changes to the document, but keeps the dialog open. This is the present behavior of the [Apply] button. Double-click on the released button applies the changes to the document and closes the dialog. This would replace an additional [OK] button. The only other button to add would be a [Close] button to exit the dialog. This is a minimalistic approach, but should work for the scenarios I can imagine: 1. [Apply] button pressed as standard: Every change is visible immediately (or after a short time as Christoph suggests) in the document. a. The user wants to keep the changes and leave the dialog: - Just press [Close] b. The user wants to revert the changes and leave the dialog: - press [Apply] to switch to the released style, so no change is applied to the document, and press [Close]. You should reach the same result with [Esc] on the keyboard or [x] in the dialog's upper corner by just one click. c. The user wants to revert the changes, but keep the dialog: - double-click on [Apply]: The style is changes to released, and all entries in the dialog have been reverted. 2. [Apply] is released as standard behavior: Changes are only visible when applied to the document manually: a. The user wants to apply the changes and leave the dialog: - Double-click on [Apply]. b. The user wants not to apply the changes and leave the dialog: - press [Close] (or [Esc] or [x]) c. The user wants to apply the changes with open dialog: - press [Apply]. d. The user wants revert the changes while the dialog stays open: - this is tricky here, because it would mean to introduce a [Revert] button. In my eyes it should not be too hard for the user to close the dialog and re-open it again. Sorry - I'm too tired to think on (additional buttons to avoid double clicks), but I want to send this nevertheless... Best regards Bernhard -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi everyone, @Bernhard: 1. [Apply] button pressed as standard: Every change is visible immediately (or after a short time as Christoph suggests) in the document. a. The user wants to keep the changes and leave the dialog: - Just press [Close] b. The user wants to revert the changes and leave the dialog: - press [Apply] to switch to the released style, so no change is applied to the document, and press [Close]. You should reach the same result with [Esc] on the keyboard or [x] in the dialog's upper corner by just one click. c. The user wants to revert the changes, but keep the dialog: - double-click on [Apply]: The style is changes to released, and all entries in the dialog have been reverted. 2. [Apply] is released as standard behavior: Changes are only visible when applied to the document manually: a. The user wants to apply the changes and leave the dialog: - Double-click on [Apply]. b. The user wants not to apply the changes and leave the dialog: - press [Close] (or [Esc] or [x]) c. The user wants to apply the changes with open dialog: - press [Apply]. d. The user wants revert the changes while the dialog stays open: - this is tricky here, because it would mean to introduce a [Revert] button. In my eyes it should not be too hard for the user to close the dialog and re-open it again. I'm sorry to say this, but double-clicking on _buttons_ (as opposed to icons or similar things) really doesn't seem to have a precedent. And this behaviour is so complicated that you have to actually learn it. If we are sticking to the current dialog for now, I would like to make another suggestion. What about a combined button of two symbols, one an arrow to the left (Undo/Revert), one a tick (Apply), like this: [ ← | v ]. That would create a visual unity and while not actually making much easier, it might look cleaner and would consume less space. @Christoph: Also, [Revert], can be removed in favor of making the dialog work with Undo/Redo. We've talked about that earlier, but it might be helpful for any direct formatting (e.g. paragraph formatting) and essential for styles (e.g. paragraph styles). Why? Because use a dialog to format a bunch of things, or to iterate some settings. Providing them Revert helps to form a logical step - all changes made when the dialog was open / has been used on a certain object. But this should be checked with real users ... or at least with a prototype, if we can't solve it by exchanging thoughts. If the lessbuttonsapproach dialog can be used for styles (I still think whether it will work at all), then Revert might be essential. People will rather set back a value (e.g. font size) instead of using the faaar away undo button - but this sets a real value instead of (in most cases) inherit the value from the parent style. This is not to say that the behaviour of the new dialog wouldn't have to be learned, especially how it ties into the global Undo/Redo function. Could the little bulb help here (the assistant in the corner of the screen)? My position on this is, that once we provide Revert or Undo button, we'll (logically) have to add a Redo button, too. So, another idea could again be a dual button, this time [ ← | → ] (the icons should be those the global Undo/Redo function uses, too) -- these would duplicate only those parts of global Undo/Redo that concern the current dialog (e. g. what you were thinking about). Astron. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hey Ricardo, * What happens for different objects with the same properties dialog? For example, the user edits Text Style 1 and does some changes. Well, right now this is not possible: when you open the first dialogue everything else in the UI gets immediately locked so you need to edit one style at a time. So the question is: do we want that when the accept but not close button/behaviour is used the dialogue become temporary modal? IMHO, this would not be a good idea because to have a dialogue that behave as modal or not modal depending on what you previously did will cause confusion, accidents and headaches. I don't think it should ever be modal. Although I admittedly couldn't quite follow the scenario when it would and would not be modal. I think that we must keep the fact that when you select an object and a property you cannot select another object without closing the property, specially when talking about styles. It is true that this might be confusing at times. Especially when you are using a notebook, and you accidentally touch the touchpad while typing. Yet, I think that maybe a relatively large caption directly under the title bar could maybe proclaim which style/image/etc. you are currently setting properties for. This would of course not eliminate the problem of accidently clicking elsewhere (which ultimately is a touchpad driver problem), but it would at least be likely to alert people that they are. Such a change would probably necessitate taking the name of the style out of title bar (otherwise the title bar would always change and there would be a duplication -- which probably looks silly). Another idea would be to paint the paragraph(s) in question as selected or having an outside glow, when a value is currently edited. On direct formatting for graphical objects could make sense to have a non modal dialogue, though. In this case it might be more commonly accepted, because images are usually large rectangular objects and, even without a caption in the dialog, you notice easier if something is not selected anymore. However, images can also be small, and graphical objects in general can even be very short lines. In this case you won't notice so easily. Again, a slight outside glow might help here. (I don't think it should be too much though, otherwise the graphical might not be recognisable anymore.) Do you think this is a somewhat satisfactory solution that avoids headaches? Astron. 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 -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
2011/4/25 Astron heinzless...@googlemail.com: Hey Ricardo, * What happens for different objects with the same properties dialog? For example, the user edits Text Style 1 and does some changes. Well, right now this is not possible: when you open the first dialogue everything else in the UI gets immediately locked so you need to edit one style at a time. So the question is: do we want that when the accept but not close button/behaviour is used the dialogue become temporary modal? IMHO, this would not be a good idea because to have a dialogue that behave as modal or not modal depending on what you previously did will cause confusion, accidents and headaches. I don't think it should ever be modal. Although I admittedly couldn't quite follow the scenario when it would and would not be modal. I think that we must keep the fact that when you select an object and a property you cannot select another object without closing the property, specially when talking about styles. It is true that this might be confusing at times. Especially when you are using a notebook, and you accidentally touch the touchpad while typing. Yet, I think that maybe a relatively large caption directly under the title bar could maybe proclaim which style/image/etc. you are currently setting properties for. This would of course not eliminate the problem of accidently clicking elsewhere (which ultimately is a touchpad driver problem), but it would at least be likely to alert people that they are. Such a change would probably necessitate taking the name of the style out of title bar (otherwise the title bar would always change and there would be a duplication -- which probably looks silly). Another idea would be to paint the paragraph(s) in question as selected or having an outside glow, when a value is currently edited. On direct formatting for graphical objects could make sense to have a non modal dialogue, though. In this case it might be more commonly accepted, because images are usually large rectangular objects and, even without a caption in the dialog, you notice easier if something is not selected anymore. However, images can also be small, and graphical objects in general can even be very short lines. In this case you won't notice so easily. Again, a slight outside glow might help here. (I don't think it should be too much though, otherwise the graphical might not be recognisable anymore.) Do you think this is a somewhat satisfactory solution that avoids headaches? For the user, yes... but I'm not so sure about the programmer on charge of it ;) But seriously, the only possible problem I can see on adding more visual effects is the increase on the already hight system resource usage of LibO. Even if the effect seems to use only a small portion of system resources, the sum of many small portions could build up a big portion. That's something to worry about, I think. Cheers Ricardo -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi Astron! Wow, I'm impressed :-) That's very good to start with ... cool that you've already added the Competitor View. Good analysis! Am Freitag, den 22.04.2011, 23:29 +0200 schrieb Astron: Hi, so, I've started a Whiteboard page at http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout . It could still use some formatting and I'm not too sure about how to embed the images the best way but see for yourselves. To me, it's absolutely fine at the moment ... talking about the idea (even a bit more). Sure, one of the next steps should add details on the behavior. So, I'm hesitant to apply any changes without having them discussed, so ... * General: We really have to take care if someone alters a style - many user questions (in the past) have been caused since people don't get the idea of derived styles and therefore think setting back a value to its original value means to revert a change (in fact, they are setting a new value which isn't updated). To me, we really need a good Revert functionality (in addition to the atomic undo). (=Version 2) * What happens for different objects with the same properties dialog? For example, the user edits Text Style 1 and does some changes. The dialog is kept open, then the user wants to edit Text Style 2 - will we open a second dialog (unlikely), or update the already visible text styles dialog? * Version 1: * Enter won't work in most cases, since it is bound to the default button in the dialogs. Today, if you enter a value and hit Enter, then you confirm the dialog. The problem is, that we don't have a dedicated confirm key, so ... * Confirmation: * The button Close confirms if the focus is in a field/selection with a changed value which is not yet confirmed * The default button should be Close (and reacts on Enter) * Changing the focus to another input element / group / tab confirms (e.g. using the key Tab) * Confirmation is done via incremental changes (e.g. if using the increase/decrease buttons of a number input field) * Proposal/Idea: If the user is editing a number/text field (thus: the field is in focus), then ENTER confirms the value. If the user presses ENTER again, then the default button action is executed. * Version 2: * The described functionality does rather fit to Revert than Reset. In LibO, Reset has an other meaning. * What will be the action of Revert? I need further thinking, but likely we have two options ... * Reverting all items that have been changed in the current properties dialog session -- All changes that have been done while the dialog was visible/open will be reverted. * Reverting all items that have been changed during the dialog had the focus -- All changes are collected when the user works with the dialog. If the user switches to another dialog, or document (maybe: changes the document) the changes will be finally applied. * Properties Dialogs: In my point-of-view, some of the dialogs should keep the old behavior. For example, the Rename Sheet dialog, or the AutoCorrect dialog ... I think we'll need some criteria (will also think about it). Sorry for that many comments and questions ... but (especially here) the devil is in the detail, I'm sure. Please bear with me :-) Additionally, such changes will affect a lot of places and users. So may it make sense to add a development plan, like: * prototypical realization in one or two dialogs as an experimental feature * checking with the community (maybe asking some users) and other teams * refinement of the behavior (from experience, always required *g*) * agreeing on the larger change and handing over to the development Concerning the competition, we have been very cautious with regard to Microsoft screenshots - the legal situation is rather unclear, so we usually try to avoid to use them. Instead, I usually try to link to images to be found in the web. What do you think? Thanks and keep up the very good work! Cheers, Christoph -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
2011/4/24 Christoph Noack christ...@dogmatux.com: * What happens for different objects with the same properties dialog? For example, the user edits Text Style 1 and does some changes. Well, right now this is not possible: when you open the first dialogue everything else in the UI gets immediately locked so you need to edit one style at a time. So the question is: do we want that when the accept but not close button/behaviour is used the dialogue become temporary modal? IMHO, this would not be a good idea because to have a dialogue that behave as modal or not modal depending on what you previously did will cause confusion, accidents and headaches. I think that we must keep the fact that when you select an object and a property you cannot select another object without closing the property, specially when talking about styles. On direct formatting for graphical objects could make sense to have a non modal dialogue, though. Cheers Ricardo -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hey. Since I'm running out of time, just a short reply :-) I'm going to start with: that's still an alot of things to ponder... Thank you for all this input, also on the buttons proposal -- I didn't even think of most of these scenarios (although they should have been fairly obvious). I'll try to address at least some of this in tomorrow or Tuesday in the wiki. By the way, I'm really preferring version 1 of these. Oh, I really liked your sketches! Here is something I've wrote about last year: http://uxopenofficeorg.blogspot.com/2010/05/picture-is-worth-thousand-words.html Hm, I am a bit wary of posting my handwriting on a wiki for all to see, because, while I like it, it is not always too clear. And also the Inkscape mock-up was done in the same spirit (at least I tried). Oh, sorry, I haven't been clear enough here ... we have a great documentation team, but nevertheless, such changes will have affect on: internal/wiki help, external documentation, training material ... in almost 100 languages ... and also the training effort (in companies). And that's the real issue - and that's what requires to be very careful about change affecting many users. Ugh. When you have more time later, would you mind explaining how careful we have to be? I'm a bit unsure, for instance: are wording changes easy to take care of (just search and replace some words in all documents)? What is a careful interaction change? * this mock-up doesn't use AutoCorrect, but rather something that I Ouch. That should of course mean AutoUpdate... hope is more digestable: automatically update this style when formatting is changed directly (I suppose the wording could still be improved) True, already improved ... :-) But, at some point we have to keep two things in mind (don't worry, let's first discuss the behavioral and structural changes): * there is an OOo styleguide how UI / help texts should be written (to be consistent throughout LibreOffice) I tried googling for it, is this the right document/version? http://specs.openoffice.org/collaterals/guides/text-style-guide.html * we are heavily affected by the size of the dialogs, since English is a rather compact language, but the dialog size has to reserve space for other languages (rule of thumb: English +40...60% space) -- we really need a layout manager, grrr I see there's something making you rather less happy^^. From your experience, is it feasible to leave some blank space under that line so that text can flow more freely or would that look unprofessional? In this case, I'm unsure, how to, after leaving out the that, the idea can be put in a more compact way -- unless one wants an Auto-ism as before. * the field Contains is replaced by a more ordered and professional looking list, from which single items can be selected and removed Using the list alone is a great improvement already :-) I'd hoped that. How about moving the Inherits from above the Style defines, then it might be clearer how inheritance works?. Not sure. Since really, it is a relation to another style. I don't think these should be important enough to warrant putting them above the actual definition of the style. And also, I tried to keep it somehow in order in the Refererences grouping (General type of class, Base class, Followed-by class -- although I just see that this hierarchy isn't really one at all). But I'm fairly sure that changing that text again to based upon will not only translate better but also communicate more clearly. I also think that [this] style defines[:] is not very good wording, but I left it because the current contains or definitions seemed worse. Great work, really! I'm sorry that my time is so limited at the moment, so my support is rather limited ... so please feel free to point out things you might need help with / comments / moral support ;-) Thank you. You've brought up many important things here already. Regards, Astron. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hey there, The downsides I can think of: * The additional button made it easier to distinguish between the Paragraph and Paragraph Styles Dialog * The button below all tabs makes clear that pressing it might affect all dialog elements (which by the way is not true for the today's buttons in this dialog) * It might be easier for users to find this functionality (well, its there all the time) * Changes in this dialog affects a lot of documentation, so we have to be careful with any changes here My proposal: Let's collect the improvements proposals for this dialog (along with the generic button stuff by Astron. Could you be so kind to add this to the wiki, please? I want to present a first entrant to the contest: http://wiki.documentfoundation.org/File:Organizer-rdsgn.png . I felt my first hand-drawn sketches were a bit too rough and unintelligible which is why this is made in Inkscape. Anyway, it is a bit of a departure from the current Organiser page, so this design would probably render obsolete much of the documentation -- I'd be willing to help there, though (as long as it's not on the order of hundreds of help pages). * this mock-up doesn't use AutoCorrect, but rather something that I hope is more digestable: automatically update this style when formatting is changed directly (I suppose the wording could still be improved) * the field Contains is replaced by a more ordered and professional looking list, from which single items can be selected and removed * the standard button is now a reset to '[Style]' button * I've changed some wording and (unintentionally) left out the Style class combobox that should of course go under References. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hi, so, I've started a Whiteboard page at http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout . It could still use some formatting and I'm not too sure about how to embed the images the best way but see for yourselves. Astron. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
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 -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Hello, wow, this has gotten out of hand, ha. 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. 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. 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. 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. 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. 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. 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 Noackchrist...@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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
Heinz, You brought up underlying issue of what is a good design for a user interface. The best I can say is that are general guidelines/rules that are followed. But one must determine when it is best to break or bend the rules for a better user interface. On Wed, 2011-04-20 at 21:27 +0200, Sparkling Specks wrote: Hello, wow, this has gotten out of hand, ha. 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. 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. 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. 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. 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. 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. 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 Noackchrist...@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.
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
On Wed, Apr 20, 2011 at 9:42 PM, RGB ES rgb.m...@gmail.com wrote: 2011/4/20 Sparkling Specks heinzless...@googlemail.com: 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. Play/pause on same button have an history: a stereo I got on late '80s had such setup so it is quite easy to understand on a music player, but other function may not be well together. To some extend, play and pause are in the same game but apply and revert are completely opposite and can confuse people to bound them together. I don't think the Reset (-vert) and Apply functions are so different as you think but yes, this behaviour isn't really expected in such a dialogue -- as opposed to Rhythmbox's most prominent button's behaviour. 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. It would alienate KDE users too... in fact, I do not like when settings apply without my explicit consent ;) Point taken. Although as a Gnome user I really like things done the Gnome way. Oh, and sorry for inadvertently opening a new thread. Regards, heinzs. -- 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
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 lng 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
On Tue, 2011-04-19 at 14:56 +0200, Sparkling Specks wrote: Hi, In the upcoming 3.4 release there will be an additional button in dialogs, Apply, to apply changes made in dialogues without closing the dialogue. This new button means that now there are five or six buttons on the bottom of many properties dialogs, OK, Apply, Cancel, Reset, (Default), Help. In an attempt to cut that number down again, I want to propose combining the Apply and Reset buttons. There's a bug about that here: https://bugs.freedesktop.org/show_bug.cgi?id=36112 , an animation to show the feature ( https://bugs.freedesktop.org/attachment.cgi?id=45456 ) is attached to the bug -- please excuse its amateurish execution. Regards, Heinzs. Heinzs My only concern is that many users would not carefully read the button labels and not realize the function has changed. BTW your animation was excellent. -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
2011/4/19 planas jsloz...@gmail.com: On Tue, 2011-04-19 at 14:56 +0200, Sparkling Specks wrote: Hi, In the upcoming 3.4 release there will be an additional button in dialogs, Apply, to apply changes made in dialogues without closing the dialogue. This new button means that now there are five or six buttons on the bottom of many properties dialogs, OK, Apply, Cancel, Reset, (Default), Help. In an attempt to cut that number down again, I want to propose combining the Apply and Reset buttons. There's a bug about that here: https://bugs.freedesktop.org/show_bug.cgi?id=36112 , an animation to show the feature ( https://bugs.freedesktop.org/attachment.cgi?id=45456 ) is attached to the bug -- please excuse its amateurish execution. Regards, Heinzs. Heinzs My only concern is that many users would not carefully read the button labels and not realize the function has changed. Agree. Sadly there is not an easy solution for this. A possibility would be to merge buttons (normal click to accept, long click to apply, or add a menu to accept button, so if you click on it you accept, but with long click a menu opens), but this will only change clutter with complexity... BTW your animation was excellent. +1 !! -- 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
Re: [libreoffice-design] Proposition to combine the Apply/Reset buttons
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
