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
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
On Thu, 2012-09-27 at 00:04 +0200, Stefan Knorr wrote: I personally would have been more in favour of making the overlay bar appear only after clicking on a slide where it could then have stayed, until the user selected another slide. :-) Sounds like a reasonable approach to me too. Creating a space to place the toolbar between the slides in the slide-pane, but inside the selection rectangle for that slide might 'fix' it without annoying the few people (not including me) ;-) who use that feature ? Anyhow - in general, I like to keep people who are hacking to improve our UI productive; rather than provide endless stop energy ;-) but of course no doubt the point of Kendy posting here was to gather feedback; there is no limit to what we can do here to change/improve things :-) ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Michel, everyone, On Thu, Sep 27, 2012 at 6:04 PM, Michel Renon michel.re...@free.fr wrote: Hi, Le 27/09/12 09:47, Mirek M. a écrit : [...] If you're afraid about the lack of association between the slide pane and the toolbar, which should sit right below it, I suppose we could tie the toolbar to the slide pane, similarly to the Navigator and the Styles dialog, only with the toolbar on the bottom. Just FYI, I already proposed something equivalent... in 2009 ;-) http://wiki.openoffice.org/w/**images/2/26/Proposal_impress_** ui_renon3.pdfhttp://wiki.openoffice.org/w/images/2/26/Proposal_impress_ui_renon3.pdf see part 4.3.11, page 35. Its was my draft proposal for Renaissance project, in may 2009 (http://wiki.openoffice.org/**wiki/Proposal_by_Michel_Renonhttp://wiki.openoffice.org/wiki/Proposal_by_Michel_Renon ) That document is incomplete, may be outdated, may contain errors/inconsistencies, but it was imagined and written during some few nights (and I was *very* busy at my dayjob). Well, I should finish it an update it with new ideas I had since...(specially ideas to remove the tab to select Impress view modes) and try to prototype it. We've agreed to evolve LibreOffice over time, so that means no big bang changes. You're still free to prototype, of course, but I hope you understand that it's unlikely that your proposal will be implemented in whole. As for the button bar, it seems that we all have very different ideas about how to solve the problem and we should be careful not to end up with an endless argument. The decision, of course, rests with Kendy. However, if he allows, we could do a very quick whiteboard, with the call for proposals on Friday and then analysis and tentative design on the IRC chat. Kendy, what do you think? ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Kendy, Jan Holesovsky wrote (25-09-12 16:00) Cor Nouws píše v Út 25. 09. 2012 v 14:58 +0200: Hmm, currently the pop-up is the (only?) way to see the name of the slide. How should we think about that? That is not changed currently, as that is a tooltip, and shows outside OK, if that's not influenced, I'm fine ! And does the removing also refer to the little toolbar in the side pane? (If I see the number of line changes in the commit, I guess yes...) Not sure if I understand you correctly; I removed the Button bar that is highlighted on the screenshot attached to the original mail, which I think you refer to as 'the little toolbar' - but not sure. Yes, that is what I meant. And currently it's both shown in the slide sorted and the side pane (View Side Pane in design mode). 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; and it seems to me as a good trend in general. I expect that (some) controls on small devises appear when you move to an edge/side. You can see that as a sort of appearing after mouse-move? Please note that Renaissance is 3-4 years old project. So them problems identified at that time have been solved ;-) ? 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 agree with the header/footer thing. Never heard complaints about the button bar, other then that it's creation came together with the hiding of the slide name... I can understand that people do not like pop-ups. And maybe I even do agree. But removing them, leaves the challenge that they were set up for in the first place, the problem that they were to solve, orphaned..? Maybe I missed part of the plan. Or maybe we simply declare that office-users are expected to use the context menu abundant :-) Cheers, Cor -- - Cor - http://nl.libreoffice.org - www.librelex.org ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Cor, Cor Nouws píše v St 26. 09. 2012 v 11:49 +0200: Please note that Renaissance is 3-4 years old project. So them problems identified at that time have been solved ;-) ? No, the solution offered at that time is not valid any more ;-) Worse - proved as annoying. I can understand that people do not like pop-ups. And maybe I even do agree. But removing them, leaves the challenge that they were set up for in the first place, the problem that they were to solve, orphaned..? Nope, the removed functionality is still accessible by other, less annoying means: in the right-click menu (for the fast access), or via the Presentation toolbar (that is not that conveniently located, as Mirek pointed out, but provides the functionality). Regards, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
On Wed, 2012-09-26 at 11:49 +0200, Cor Nouws wrote: I agree with the header/footer thing. Heh - I think the general concept of things appearing instantly on a timeout you can't see, and then being click-able is a really bad one. We had this with header-footer widgets getting clicked by mistake. Never heard complaints about the button bar, other then that it's creation came together with the hiding of the slide name... I've heard the complaints -worse- I've seen the effects at conferences: oh, where did that slide go (afterwards it turned out to be accidentally hidden) that have harmed people's talks, not isolated examples either and different to Kendy's set so ... ;-) I can understand that people do not like pop-ups. And maybe I even do agree. But removing them, leaves the challenge that they were set up for in the first place, the problem that they were to solve, orphaned..? Yep - it seems a shame to hide something that is quite beautiful and seems like it -should- be really useful, but ... screwing up people's presentations is not ideal ;-) ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
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. ___
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 ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Michel, On Wed, Sep 26, 2012 at 1:45 PM, Michel Renon michel.re...@free.fr wrote: 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. Actually, the new version of Nautilus is about as usable on a tablet as the old version. The changes have been brought about after careful deliberation -- you can read about it in-depth at http://blogs.gnome.org/mccann/2012/08/01/cross-cut/. Your modification will be useful for the tablet version of LO, but maybe not for the desktop version. The on-hover button bar is being removed primarily because it causes frequent accidental errors, not to better suit tablets (although that would be a good reason as well). 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. Actually, I have heard widespread complaints about the on-hover control. I myself have struggled with it. Additionally, if you check the control against our design principles [1], it performs quite poorly. It breaks ux-discovery, since it's not visible by default, and ux-error-prevention, as any clickable buttons that appear unexpectedly over another clickable target is bound to result in errors. 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 1) It adds complexity (see Hick's law), goes against ux-minimalism 2) It has to be maintained. 3) It adds baggage to LibreOffice, makes it slower, makes the code less manageable. 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. Right now, we're hoping to change LO's UI iteratively, one usability problem at a time. Take a look at our design principles [1]. 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 ? Yes -- they go against ux-discovery and ux-error-prevention. - should we use floating and/or docked panels ? When a decision is made, it should not change for several years (3-5) I disagree. If a design has problems, it should be changed right away. It's best for the user. - 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) That process is for large design changes that need to be thoroughly thought out. It would be overkill to spend 3 weeks on minute design changes. it may also bring some big inconsistencies [2] It may also bring more consistency, such as in this case, where the on-hover toolbar was unlike any other toolbar in both LO and elsewhere. - 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) That's pure speculation. I personally expect users to be glad to be rid of a usability nightmare. [1] http://wiki.documentfoundation.org/Design/Principles ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Kendy, On Tue, Sep 25, 2012 at 3:35 PM, Jan Holesovsky ke...@suse.cz wrote: Hi Mirek, Mirek M. píše v Út 25. 09. 2012 v 12:19 +0200: Slide duplication was not easily accessible after this, so I added it to the right-click menu: http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b Could you also show it on the Presentation toolbar? The Presentation toolbar currently has it, but hidden - when you click on the arrow next to the Slide (it should be called New Slide, I guess), it is at the bottom of the control that appears. Do you suggest to remove it from there, and add a button for that directly on the toolbar instead? Yes. If you feel like it would waste too much space, you could hide Slide design by default, as it's not very useful in its current state. And perhaps rename the Presentation toolbar to Slide toolbar, since all of its commands apply to the current slide, not to the presentation as a whole. Makes sense, will do that. I would also propose to move it to the bottom left so that it sits directly under the Slide toolbar, where it can be associated with the current slide (as per ux-natural-mapping [1]). I meant Slide pane, not Slide toolbar, sorry. Possible, of course, just it would shift the Drawing toolbar to the right, and that might hide some items on smaller resolutions. Could you please double-check if we really want that? First I asked on our G+ page [1]. Then I took another look at it. Here's my take: 1) We should hide the Gallery and the Fontwork gallery by default, as they're outdated, promote bad habits, result in bad quality, and are hard to use. 2) Rotate, Position and Size, Alignment, Arrange, and Interaction are on the Drawing toolbar, but they have little to do with drawing and apply to a whole range of objects, not just drawings. I would suggest to put them in a separate toolbar. I would place it to the right of the toolbar below the Standard toolbar, as it also contains commands related to the selected object (ux-natural-mapping). These changes should improve usability in general as well as make room for the Slide toolbar below the Slide pane. [1] https://plus.google.com/102673546895803839652/posts ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi there, On Wed, 2012-09-26 at 11:57 +0200, Jan Holesovsky wrote: Hi Cor, Cor Nouws píše v St 26. 09. 2012 v 11:49 +0200: Please note that Renaissance is 3-4 years old project. So them problems identified at that time have been solved ;-) ? No, the solution offered at that time is not valid any more ;-) Worse - proved as annoying. Well, sort of anyway. I guess one thing to take away from this incident and the other about the header/footer indicators is that (understandably) our users don't like functionality flashing in and out for no good reason. Or put more seriously, functionality must not solely rely on hovering the mouse over some part of the UI. (Yes, sure, hand over that award for restating the painfully obvious after Mirek already did that.) At the same time, I think the current solution of just removing functionality that is useful (at least to me in at least 80% of cases, so count me among those who [mostly] praise it) is a bit frivolous. I personally would have been more in favour of making the overlay bar appear only after clicking on a slide where it could then have stayed, until the user selected another slide. About Mirek's idea of making the functionality a toolbar proper, I am not so sure, as the code between the slide sorter and the slide sidebar is shared and I would suspect a full-width three-button toolbar would look rather lost below the slide sorter. Nope, the removed functionality is still accessible by other, less annoying means: in the right-click menu (for the fast access), or via the Presentation toolbar (that is not that conveniently located, as Mirek pointed out, but provides the functionality). Well, I suspect the Renaissance people have put it there for a reason and they might have thought about reusing existing infrastructure. (Btw, I think Mirek is proposing a new toolbar – not reusing the Presentation toolbar which doesn't provide functionality for hiding slides and duplicating slides, only for starting the slide show. I should let Mirek clarify that, though, I guess...) Astron. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Astron, UX guys, I've talked to an Impress power user recently, and he was complaining about the buttons in the slide sorter [the thing you can see on the attached screenshot]. This was actually not the first complaint I got, and also I remembered our discussions that we should do something about them, so I decided to just kill them for now: http://cgit.freedesktop.org/libreoffice/core/commit/?id=504d3ed897915bff3b3794dc3f069cb4fb528719 Slide duplication was not easily accessible after this, so I added it to the right-click menu: http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b The rest (slide show start, hide slide) are already available easily - the former from a toolbar, the latter from right-click menu. Using that feels surprisingly well to me, and visually it is much less disturbing - I hope OK for you too? This all leads me to thinking that things that appear somewhere with a timeout after having placed the mouse pointer there are annoying in general [referencing there the header / footer too], so I wonder if we have any other occurrences of such behavior around? I'd probably kill it too, in case we do ;-) Thank you, Kendy attachment: button-bar.png___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Kendy, On Tue, Sep 25, 2012 at 10:34 AM, Jan Holesovsky ke...@suse.cz wrote: Hi Astron, UX guys, I've talked to an Impress power user recently, and he was complaining about the buttons in the slide sorter [the thing you can see on the attached screenshot]. This was actually not the first complaint I got, and also I remembered our discussions that we should do something about them, so I decided to just kill them for now: http://cgit.freedesktop.org/libreoffice/core/commit/?id=504d3ed897915bff3b3794dc3f069cb4fb528719 Slide duplication was not easily accessible after this, so I added it to the right-click menu: http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b Could you also show it on the Presentation toolbar? And perhaps rename the Presentation toolbar to Slide toolbar, since all of its commands apply to the current slide, not to the presentation as a whole. I would also propose to move it to the bottom left so that it sits directly under the Slide toolbar, where it can be associated with the current slide (as per ux-natural-mapping [1]). The rest (slide show start, hide slide) are already available easily - the former from a toolbar, the latter from right-click menu. Using that feels surprisingly well to me, and visually it is much less disturbing - I hope OK for you too? It's great, thanks. This all leads me to thinking that things that appear somewhere with a timeout after having placed the mouse pointer there are annoying in general [referencing there the header / footer too], so I wonder if we have any other occurrences of such behavior around? I'd probably kill it too, in case we do ;-) Thank you, Kendy [1] http://wiki.documentfoundation.org/Design/Principles ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Mirek, Mirek M. píše v Út 25. 09. 2012 v 12:19 +0200: Slide duplication was not easily accessible after this, so I added it to the right-click menu: http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b Could you also show it on the Presentation toolbar? The Presentation toolbar currently has it, but hidden - when you click on the arrow next to the Slide (it should be called New Slide, I guess), it is at the bottom of the control that appears. Do you suggest to remove it from there, and add a button for that directly on the toolbar instead? And perhaps rename the Presentation toolbar to Slide toolbar, since all of its commands apply to the current slide, not to the presentation as a whole. Makes sense, will do that. I would also propose to move it to the bottom left so that it sits directly under the Slide toolbar, where it can be associated with the current slide (as per ux-natural-mapping [1]). Possible, of course, just it would shift the Drawing toolbar to the right, and that might hide some items on smaller resolutions. Could you please double-check if we really want that? Thank you, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter
Hi Cor, Cor Nouws píše v Út 25. 09. 2012 v 14:58 +0200: I've talked to an Impress power user recently, and he was complaining about the buttons in the slide sorter [the thing you can see on the attached screenshot]. This was actually not the first complaint I got, and also I remembered our discussions that we should do something about them, so I decided to just kill them for now: Hmm, currently the pop-up is the (only?) way to see the name of the slide. How should we think about that? That is not changed currently, as that is a tooltip, and shows outside the slide; so even if somebody clicked on that by mistake , it has no effect, compared to the Button bar, where you usually end up with a hidden or duplicated slide [happened few times even to me - but IIRC I've never went with the mouse far enough to start the presentation ;-)]. And does the removing also refer to the little toolbar in the side pane? (If I see the number of line changes in the commit, I guess yes...) Not sure if I understand you correctly; I removed the Button bar that is highlighted on the screenshot attached to the original mail, which I think you refer to as 'the little toolbar' - but not sure. 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; and it seems to me as a good trend in general. Please note that Renaissance is 3-4 years old project. 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 :-) All the best, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
