On Thu, Feb 16, 2017 at 10:41 PM Heiko Tietze <[email protected]> wrote:
> looks like a really cool Notebookbar focusing on the average user with a > broad spectrum of needs - Eve. The current 'contextual sections' variant > was made having Benjamin in mind. My toolbar concept targets mainly Benjamin. The left part of the interface contains only actions targeted at Benjamin, as further you go to the right, the more advanced features are present. Toolbar Group 1 - 05 of 05 items target Benjamin (100%) Toolbar Group 2 - 05 of 05 items target Benjamin (100%) Toolbar Group 3 - 07 of 11 items target Benjamin (64%) Toolbar Group 4 - 04 of 09 items target Benjamin (44%) Toolbar Group 5 - 00 of 05 items target Benjamin (0%) Overall 21 of 35 items are targeted at Benjamin (60%). Of course it depends how someone rates the buttons/actions – I did it reserved (for example I didn't count remove-formatting as Benjamin-targeted). Therefore all icons have a label, sections are labeled... Labeling everything comes at a high price, label take a lot of screen-space. I think that labeling is not that important, what rather matters is to group similar actions together → grouping over labeling. Not using section labels allows to be not forced to have only actions of a certain section-group in one group – e.g. in the mock-up I have the comment-button in the same group as the text-size button. ... only the most relevant features are present. This is a controversial topic. Some years ago I helped an older man to accomplish the needed computer-tasks to get his music businesses done. He never used the mouse right-click menu nor any keyboard shortcuts. Soto-say, he was a real live Benjamin user. When watching him write his songs on the computer, I saw that he used the copy & paste buttons quite a lot – I've also seen other average users use them. So I would argue that they are essential. And this is the problem, office applications have a lot of functionality that could be described as essential, even when focusing at Benjamin type of user. If I had labeled the first two of my toolbar groups, I would probably have used more than half of the toolbar screen width without having any office functionality, only open, save, copy, paste... > Users with not so perfect sight may struggle with bullets vs. numbers, for > instance, that are distinguished by only a few pixels. Casual users may not > recognize some functions and need to read the tooltips. > The concept interface is designed from the left to the right. I would expect users to read tool-tips or ignore icons that are further on the right side. This is expected behavior, not a failure of the UI. Like in the real world, I don't need to understand how to use every tool in a toolbox to get work done. The icons on the left should be known from other applications or speak for them-self. To help users with less sight there should be a high-contrast icon theme. Labeling all buttons would IMHO not help here, because not all basic-actions (controversial, I know) can be present in the toolbar. Which leads to that the actions must be present somewhere else → side bar. In the sidebar they currently have no label. Even if they had labels, it would mean that the sidebar would have more menus or that you would have to scroll down, which is in both cases not that great. From thinking about that problem I don't see what else beside of having a high-contrast icon theme and a good default navigation scheme could be done in this respect. If labels are primary there to help less sight people, than I disagree, a UI should never be bend to serve mainly a minority. > The idea to show a menu when the width is not sufficient for all icons is > quite interesting. You may compare it with the implementation at the tabbed > variant. But I wouldn't use Add and a plus icon, though. > It is just an idea. The add-button is there to solve an inconsistency in the current LO Writer UI (also present in Microsoft Writer), let me explain. We could say that there are different write-modes, which need different toolbar buttons to manipulate their behavior. The default-mode is to write text and needs many always visible buttons, e.g. the formatting buttons. When adding a table, the table is a sub-mode, lets call it table-mode. To handle the behavior of the table-mode we need some more buttons, plus the buttons from the default-mode to handle text written inside the table. The add-button orders the visibility of the sub-mode buttons and solves therefor the above described problem, the UI no longer needs to mix buttons from different modes. > And last but not least about user expectation. This was also a question > when we created the contextual sections. But on the other hand we have a > sidebar that allows very efficient access with widescreen displays. And why > not show a few functions in the toolbar and everything else in the sidebar? > Calligra did this and has only New, Open, Save, Undo, Redo, Cut, Copy, > Paste, and Find in the toolbar. I'm currently not sold on that idea. Mainly because it means to split actions to different places. There is the problem of mouse-distance-to-target and for small screens screen space doubts, also it is a quite uncommon approach and breaks therefor with common user habits – why even have a toolbar at all? There seems to bee some agreement that the sidebar is a good thing here, I would like to learn about the reasoning behind it. Has some user testing been done that indicates the sidebar is better than a traditional toolbar? Why did Microsoft go with such a feature packed toolbar and not a sidebar? Did someone evaluate if a sidebar only approach would work, if it works it could be quite an interesting idea. That's it for now, sorry for the long reply ^^ Thibaut -- To unsubscribe e-mail to: [email protected] 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
