[libreoffice-design] Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Jon, Le 26/09/2012 16:34, Jan Holesovsky a écrit : Hi Michel, Michel Renon píše v St 26. 09. 2012 v 13:45 +0200: UI decisions should be taken based on facts, analysis, polls, statistics. So this is the statistics I have at hand: Several people angry about a feature, and nobody praising it. Now, you are the first one, so please tell me how much do you actually use Impress. If you do, it is really hard to believe that you haven't got bitten by this yet. Also, I would be most interested to hear how many times have you actually used the buttons. I use Impress very few, but this buttonBar has never disturbed me. I essentially use the 'duplicate' button of this toolbar. I can list other parts of Impress that are design nightmare ! (I have a list of bugs of LO and I will create bug reports asap). I asked other people (from my LUG) and they had no problem with the buttonbar, or even with the concept of popup objects. They even find the context menu (with right-click) so '90s (while still very useful) and tend to prefer the popup objects, because they become used to that with current web UI. We cannot measure everything, otherwise we wouldn't get much far because all that time spent talking, and considering, and writing specifications. Much better approach is to try what seems good, and if it does not work, ie. we get complaints constantly, not only a few during a transition period, change it. This way of doing is possible with a small user base (I did it twelve years ago while writing big and important software for Airbus : we used a kind of agile process (idea, code, feed-back and loop). Early users (1-4 people) were also testers and we created a wonderful software, still used and appreciated! (10-50 current users) However, with LO's user base, it's impossible : most users want something that just work out-of-the-box, they are not testers and don't want to be considered like that : they have to produce documents, mostly in professional context, that's all. LO must be stable, efficient and not change UI (that disturb users) every release. You can imagine an equivalence with car industry : drivers won't accept a new car that has defaults or that is not complete or that has something for testing. And look at the huge problem that Apple has to face with his incomplete Maps app. Tim Cook had to apologize and explicitly said to use others software (from concurrents!). It's not a design problem, but it shows that a large user base can't be considered as testers ; they accept only a finished product (already tested). Please note that Renaissance is 3-4 years old project. A good idea will never be obsolete ;-) Renaissance was a project, not an idea ;-) Who cares where ideas come from ? Henri Poincaré (a french mathematician) solve a problem while jumping in a bus, Archimedes is famous for taking a bath, Isaac Newton and an apple. (ok, Newton's apple is a legend...) [...] As a general point of view on this subject, I would say that it shows several problems in the design team (that's why I'm CCing to design list) : - there is a lack of long-term vision for LO's UI/UX : a vision, a roadmap, with tenets. Some big users (administrations, companies...) need that kind of information so that they can plan training, migration [1]. For example : - should we use or avoid appearing / disappearing UI elements ? - should we use floating and/or docked panels ? When a decision is made, it should not change for several years (3-5) Alex / Astron / Mirek / others [in alphabetical order :-)] all have common vision, and it shows with 3.6 - it is the most beautiful open source office suite around. How comes you have not noticed that? ;-) I was talking about something precise : roadmap with practical guidelines : - a roadmap defines where are we going to ? - a roadmap defines what is the schedule ? - practical guideline defines what should you do/don't do ? how to react in every kind of situation ? In the context of design, it would mean : - how will the LO's UI be in the future ? - what is the schedule of the incremental/big changes ? (in X months, the panel Y will be changed, etc) - guideline are for devs / ui people (like Human Interface Guideline, for iOS or Android or MS or Gnome or KDE) Today, the design principles are too abstract to be considered as guidelines. And I repeat that such a schedule is important for companies and administration, so that they can plan one or two years ahead (training /migration) - a developer may decide to make big UI changes, just because he talked with few users : it's a complete by-pass of the existing UI process (whiteboards, proposals, discussions, vote) ; it may also bring some big inconsistencies [2] Imagine a new volunteer who contributed code to improve something, do you want to say him/her that OK, but you haven't followed the PROCESS, return to the drawing board.? yes ! because : - we all make
[libreoffice-design] Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Cor, Jan, Le 25/09/12 16:00, Jan Holesovsky a écrit : [...] Therefore the good OpenOffice.org developers and people conducted a large project some years ago, Renaissance. Of course the toolbar is one of the changes the was a result from that. I guess all the work was done, because many obvious actions are not easy enough accessible for Joe-average. And that these were only the first steps in a route to make Impress (more) more contemporary. The little pop-ups fit more in modern UI (-expectations) I guess then context menu's - let alone short-cuts and pull down menus... I don't think I agree with you here. The touch-based devices need to have everything shown, nothing appearing based on a presence of a mouse pointer; It's a technical fact : touch interfaces have no 'hover' event. But look at what's happening with Nautilus : devs are making big changes to prepare for touch interface. The mistake is that they change *current* desktop version so that *future* versions may work on tablets. Since last year, users just can see Nautilus has less and less behaviors. Devs just say we know what's good for you : we'll bring them back later for touch. The result is that the Nautilus project is forked and will be replaced very soon. We have to realize what for next 2 years (and more...), most LO users will still use a computer (desktop or laptop) to edit. Your modification will be useful for the tablet version of LO, but maybe not for the desktop version. and it seems to me as a good trend in general. This is a personal and subjective opinion. UI decisions should be taken based on facts, analysis, polls, statistics. I also made that mistake : few months ago, I made a proposal for another Insert menu, based on most used items, well most items I used and supposed others also used. In the design list, I had some immediate and strict feed-back : don't suppose, provide real and pertinent usage values otherwise propose something different. They were right. Please note that Renaissance is 3-4 years old project. A good idea will never be obsolete ;-) I have heard complaints about this Button bar from several people, and no 'oh, I love these appearing buttons' - so I believe we are fine. The same with the appearing / disappearing header / footer controls - lots of complaints that it is too much disruptive, so I believe that not using any controls that appear after a timeout only supports that the above mentioned trend is Good :-) I may be the first, but let me tell you that I find the new header/footer control *very useful* ! The complaints I heard about OOo/LO were all about the old look/design. The header/footer control, while not perfect, brings something new that's really welcomed. And I wish we can use that idea for table edition and much more. Why not allow users to enable/disable such appearing-controls by preferences ? Everybody should be happy : - beginners and average users won't see changes between versions - power users may choose what they prefer As a general point of view on this subject, I would say that it shows several problems in the design team (that's why I'm CCing to design list) : - there is a lack of long-term vision for LO's UI/UX : a vision, a roadmap, with tenets. Some big users (administrations, companies...) need that kind of information so that they can plan training, migration [1]. For example : - should we use or avoid appearing / disappearing UI elements ? - should we use floating and/or docked panels ? When a decision is made, it should not change for several years (3-5) - a developer may decide to make big UI changes, just because he talked with few users : it's a complete by-pass of the existing UI process (whiteboards, proposals, discussions, vote) ; it may also bring some big inconsistencies [2] - most important, it may changes/revert recent modifications -- users will be disturbed by those UI flip/flop (for example see previous changes between Rythmbox and Banshee in Ubuntu) (please see absolutely no offense to you Jan, I'm just trying to analyze the situation ; and the context of my feedback is that I have not enough time to work, propose on the UI/UX team, so it's just a little reflexion/suggestion ; but as a simple user, I would be very disturbed by such changes) Thanks, Michel [1] And in France, last week we had an important announce about OSS and the administration : they'll study different projects and choose some of them. Nothing is decided between LO/OOo : Each project's team has to prove his project is stable, well organized, well structured and has a clear roadmap. [2] I just tried Thunderbird 18 (aurora channel) and the main window has no more menu bar ! Menus are now in a popup button on the right. But the problem is that the compose window still has the standard menu bar : inconsistency, users will be disturbed. -- Unsubscribe instructions: E-mail to
[libreoffice-design] Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Michel, Michel Renon píše v St 26. 09. 2012 v 13:45 +0200: UI decisions should be taken based on facts, analysis, polls, statistics. So this is the statistics I have at hand: Several people angry about a feature, and nobody praising it. Now, you are the first one, so please tell me how much do you actually use Impress. If you do, it is really hard to believe that you haven't got bitten by this yet. Also, I would be most interested to hear how many times have you actually used the buttons. We cannot measure everything, otherwise we wouldn't get much far because all that time spent talking, and considering, and writing specifications. Much better approach is to try what seems good, and if it does not work, ie. we get complaints constantly, not only a few during a transition period, change it. Please note that Renaissance is 3-4 years old project. A good idea will never be obsolete ;-) Renaissance was a project, not an idea ;-) I may be the first, but let me tell you that I find the new header/footer control *very useful* ! The control is extremely useful, indeed, only its presentation was annoying, and Cedric fixed that (thanks Cedric!). Now everybody is happy. And I wish we can use that idea for table edition and much more. Come up with a proposal, and implement it, that's the best what you can do. Or try to enthuse a developer to implement it. Why not allow users to enable/disable such appearing-controls by preferences ? Everybody should be happy : - beginners and average users won't see changes between versions - power users may choose what they prefer Every such setting brings you complexity that you have to maintain. It is error-prone, and the time to implement that is non-trivial too. If you find somebody who is willing to implement it, maybe, but I'd encourage the guy/gal to spend the time in some more sensible way. As a general point of view on this subject, I would say that it shows several problems in the design team (that's why I'm CCing to design list) : - there is a lack of long-term vision for LO's UI/UX : a vision, a roadmap, with tenets. Some big users (administrations, companies...) need that kind of information so that they can plan training, migration [1]. For example : - should we use or avoid appearing / disappearing UI elements ? - should we use floating and/or docked panels ? When a decision is made, it should not change for several years (3-5) Alex / Astron / Mirek / others [in alphabetical order :-)] all have common vision, and it shows with 3.6 - it is the most beautiful open source office suite around. How comes you have not noticed that? ;-) - a developer may decide to make big UI changes, just because he talked with few users : it's a complete by-pass of the existing UI process (whiteboards, proposals, discussions, vote) ; it may also bring some big inconsistencies [2] Imagine a new volunteer who contributed code to improve something, do you want to say him/her that OK, but you haven't followed the PROCESS, return to the drawing board.? Do you think that he'll contribute the next time? Sorry, but no - this is what this ux-advise list is for. If the code looks good, and generally the idea looks plausible (even without extensive UX testing), the best is to get it in, and then _cooperate_ with the author to make it even better, and fitting the overall vision. I really appreciate how Mirek reacted on what I've done - concrete points to improve (the toolbar that is too far, etc.). That's something actionable, and the way I'd like to see the design-developers cooperation in general - and I see it happening, thank you all! - most important, it may changes/revert recent modifications -- users will be disturbed by those UI flip/flop (for example see previous changes between Rythmbox and Banshee in Ubuntu) The best way is to test changes early - get the daily builds, test them, and report anything that you see problematic there. and the context of my feedback is that I have not enough time to work, propose on the UI/UX team, so it's just a little reflexion/suggestion Well - talk is cheap ;-) Please do get involved, the best is to improve something that annoys you - an icon that is unpleasant, a drawing artifact that shouldn't be there, etc. Or just test the daily builds from time to time, that won't take you that much time. Regards, Kendy -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
