https://bugs.freedesktop.org/show_bug.cgi?id=81475
--- Comment #14 from Jay Philips <[email protected]> --- Created attachment 104556 --> https://bugs.freedesktop.org/attachment.cgi?id=104556&action=edit IBM Symphony single toolbar line with standard and contextual toolbars Hi Mirek, (In reply to comment #12) > Yes, but the font name drop-down is rarely used, which means it should > either be removed from the toolbar and left to the sidebar or it should at > least occupy less space (as a drop-down with an icon). Well i guess that we'll have to disagree on how used the font name drop-down is. You also have to take into consideration that styles arent highly used in calc and impress, as there isnt a style drop down in the toolbar. Here are responses about this issue from the ux mailing list. Jean-Francois Nifenecker: Could you elaborate, please? When I see the people around me (corporate environment, 400+ users) who don't use styles (most of them, unfortunately), the font drop-down *is* used very often. David: I really do get irritated with this argument about styles. Yes, they are the right way and yes, we should use them all the time. But the real world isn't like that and a significant proportion, if not majority, of LO users just don't get styles. Period. I use styles and have taught their use in offices I've managed for many years. But for short 1 to 2 page documents it is irrelevant whether users will be bothered about spending time styling their documents. Please do not reduce the choice of users to use fonts and direct formatting if they wish, and do not make it harder for them to do so. > Spelling is an integral part of the Language menu under tools -- > spell-checking and grammar-checking are the only reasons to apply a language > to parts of text. What I meant to say is that there's no need for a separate > Spelling menu -- it would just duplicate the Language menu. Well if you'd prefer to have 'Spelling and Grammar' and 'AutoSpellcheck' underneath the Language submenu, then i'm fine with that, though i think it maybe confusing for some users. The reason for suggesting the spelling menu was that i didnt want to suggest cluttering up the main Tools menu with an 'AutoSpellcheck' entry, but maybe it would be worth it so users didnt have to go digging through a submenu for it. > The thing is, we don't need to save space. We should keep all the common > options as accessible for users as possible and relegate all the lesser-used > commands to the sidebar. LibO has a plethora of useful features that can be brought forward to users, so they dont have to go through menus, dialogs, and sidebars. And in order to bring some of these features to the toolbar, space needs to be freed up. > Button groups make things harder to access, and if the formatting toolbar is > supposed to provide quick access to the most common commands, it should > avoid them when possible. Button groups do not make things harder to access, as we already have button groups for open, new, paste, table, font color, highlight color, background color, and all the shapes in the drawing toolbar. You could easily consider the style, font name and font size a button group. As an example, lets take my proposed 'Insert Internal Link' group button. Instead of a user having to go into Insert > Footnote/Endnote and then the dialog opens up and then them select 'Endnote' under type, they would click on the down button in the group button and click the endnote entry. This is easier access. This functionality isnt available in the sidebar as well. > (Ideally, LibreOffice would be responsive and group buttons into drop-down > menus when there is no room for them.) It would be great if LibO was smart enough to do that, but as it isnt, we can still help. :) > A simple Find button is probably best, as it encompasses both search and > navigation. Presently there isnt a Find button available. > The problem around panes being duplicated in the sidebar is still a hot > topic now, but, generally, we should either promote one or the other, and > since the sidebar has panes that aren't available individually, we should > prefer the sidebar over the panes. Yes i've seen the discussions around this issue and thought to comment on it, but chose not to. Ultimately, i think users who use the sidebar would like the panes in the sidebar, but users who dont, would prefer it the old way. > Rather than buttons for individual panes, then, how about having a button > for the sidebar? I think it would be useful to have a sidebar/toolbar mode button that would allow users to choose what they prefer to use. If they are in toolbar mode, it works as it has always done. If they are in sidebar mode, only a single toolbar line should be visible that primarily hosts the standard toolbar, and there shouldnt be drawing, table, and find toolbars popping up at the bottom (similar to how IBM Symphony had it). > We have the same sidebar that Symphony had -- IBM donated the code to AOO > and now we have it -- we just refined it a bit. We're already there. I am aware that the sidebar was brought from IBM Symphony, but the additional toolbar functionality wasnt brought over. In IBM Symphony, there was a single top toolbar line that had a small standard toolbar and then an additional contextual toolbar, which changed when you were on/in an object (see attached image). This contextual toolbar took the place of all the bottom popup toolbars (table, picture, etc) as well as the toolbars that that switch with the formatting toolbar (frame, ole-object, drawing object properties, etc). > The toolbar is for quick access. If you need lesser-used commands, you'll > have to open either the sidebar or the formatting dialog. The sidebar is > easier to work with and some may just view it all the time. It's not being > forced on anyone, though. The toolbar is quick access just like the sidebar, but as the sidebar is a non-experimental feature introduced in 4.2 and is not enabled by default, many users may not be aware of it or prefer not to use it. If the styles, navigator, and gallery are decided to be exclusively kept in the sidebar, then they will be forced to use it. > I'm just saying that putting common things into harder-to-access group > drop-downs to make room for lesser-used commands goes against the quick > access nature of toolbars. Group drop-downs are not hard-to-access and most entries proposed for the drop-downs are for highly used commands, as the statistics have already shown. If you look at the WordPerfect screenshot, you will notice that they have similar group drop-downs for underline (this is in the sidebar already), alignment, and symbols. -------------------- Regarding the sidebar, I believe there are two types of users who use writer. One type of user who will use the sidebar and one type that wont. I think the use of the sidebar will likely come down to the user's screen size, but the maturity of the sidebar will also likely effect some users decision. If you look at these stats, < http://www.w3counter.com/globalstats.php > and < http://gs.statcounter.com/#resolution-ww-monthly-201307-201407 >, you will see that the second most used screen size is 1024x768. A user at this small 4x3 screen size, is highly unlikely to use the sidebar over the toolbar, as the sidebar takes up 1/3 of the screen (the smallest size of the sidebar is 317 pixels). Such a user wouldnt be able to handle that huge chunk of space taken away from him/her and would prefer the formatting toolbar. This proposal was done for toolbar users who may not know about the sidebar, as its not enabled by default, and for users who choose not to use it. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
