I would like to propose the removal of the following right-click context menu formatting options: Font, Size, Style, Alignment, Line Spacing. I'm making this suggestion because the same formatting options are already available in the toolbar, the sidebar, in Format > Paragraph dialog, and in the right-click Paragraph dialog. In addition to formatting options being available in so many places, very few users actually use it, but for some strange reason it is put at the top of the context menu. Here are the stats for the usage of these formatting options, as taken from OOo's tracking results < https://wiki.openoffice.org/wiki/Tracking_results > for writer. 1) Single Line Spacing - 8,700 ( 22.58% ) 2) 1.5 Line Spacing - 6,501 ( 16.87% ) 3) Strike Through - 3,698 ( 9.60% ) 4) Bold - 3,620 ( 9.40% ) 5) Double Line Spacing - 2,921 ( 7.58% ) 6) Paragraph Center - 2,842 ( 7.38% ) 7) Shadowed - 2,249 ( 5.84% ) 8) Outline - 2,000 ( 5.19% ) 9) Underline - 1,927 ( 5.00% ) 10) Paragraph Left - 1,384 ( 3.59% ) 11) Italic - 1,116 ( 2.90% ) 12) Paragraph Right - 889 ( 2.31% ) 13) Overline - 534 ( 1.39% ) 14) Change Font Name - 68 ( 0.18% ) 15) Change Font Size - 38 ( 0.10% ) You can see from these results that the most popular used group is one not found in the formatting toolbar, i.e. line spacing. The three line spacing options account for 47% of the total usage and 22% of the total usage is taken up by the next group - style options not found in the formatting toolbar (strike through, shadow, outline, overline). 17% is taken up by style options found in the formating toolbar and 13% is taken up by the alignment options. Presently there is a benefit of keeping the Line Spacing and Style options, because they do fill a void in the formatting toolbar, which i had planned to suggest their inclusion into the standard toolbar once i finished my toolbar revamp. It would be one button for text effects (shadow, outline) and a second for line spacing (single, 1.15, 1.5, double). To put the above statistics into perspective, here are the top 10 right-click options. 1) Paste - 1,119,606 2) Copy - 592,585 3) Cut - 225,137 4) Picture - 47,078 5) Paragraph - 41,302 6) Clear Formatting - 30,401 7) Remove Hyperlink - 29,392 8) Table - 21,493 9) Character - 20,466 10) Page - 16,921 The major advantage of a smaller/compact right click menu in writer, something already present in calc, is that if the context menu appears above or below the mouse pointer due to its position on the screen, it will still be faster to get the number 1 right-click function, PASTE. Another advantage of removing them is that the limitation of the Font option wont need to be fixed - bug 34085. :)
I am strongly against this removal. Why do you want we impose the user only one way to access a function? Redundancy is a good thing there, some users could easier find the function in a toolbar, others in a menu and the last in the contextual menu. I removed formatting toolbar from my personal LO configuration, how should I access to these formatting function if you remove it from contextual menu? Formatting has been added in the contextual menu because that has been requested. It was several years ago in the OOo time. Other point: what about accessibility? In other words how does it works without mouse? Changing importance to enhancement because it is not a bug. I propose to close it as WontFix. Best regards. JBF
We need UX advice on this
(In reply to comment #1) > I am strongly against this removal. Why do you want we impose the user only > one way to access a function? Redundancy is a good thing there, some users > could easier find the function in a toolbar, others in a menu and the last > in the contextual menu. Why am i being imposed on to see them there everytime i right-click when i dont use them. If i dont want to go to the menu, i can get most things from the toolbar, if i dont want the toolbar, i can go for the sidebar, but what choose do i have when i dont want it cluttering up my right-click menu. > I removed formatting toolbar from my personal LO configuration, how should I > access to these formatting function if you remove it from contextual menu? You have the right-click Character and Paragraph options. > Formatting has been added in the contextual menu because that has been > requested. It was several years ago in the OOo time. Just because something is added doesnt mean its not good to remove it when its not used. The stats speak for themselves. > Other point: what about accessibility? In other words how does it works > without mouse? Didnt get the question. Are we talking about the desktop, as desktops dont function without mice. > Changing importance to enhancement because it is not a bug. I propose to > close it as WontFix. Sorry, thats my bad, i should have put it as an enhancement.
(In reply to comment #1) > I am strongly against this removal. Why do you want we impose the user only > one way to access a function? Redundancy is a good thing there, some users > could easier find the function in a toolbar, others in a menu and the last > in the contextual menu. Basically I agree here. Of course, when the holy grail of the UI forcing proper use of styles is invented, I'll change my opinion here ;)
So - a point of fact here; the context menu is often exposed for a11y reasons to the Accessibility Technology, and removing things can have an impact. Having said that having smaller context menus is also a worthy goal. Ultimately this is one for the UX team I think - personally I love Jay's data-driven approach.
Created attachment 102535 [details] very large context menu in writer If its to help accessibility technology, then thats a definite reason to not remove the code, but maybe we can have a Tools > Options setting to enable / disable it, so everyone is happy. :) Space is a major issue presently in the context menu as it can take up more than 2/3rds of my screen height (900px), as illustrated in the attached screenshot of what i think is likely a common example most users would encounter (a link inside a table). And additional context menu additions are likely going to be added that will be universally beneficial, like paste special [bug 62947] and my yet to be suggested translation and comment options. Maybe the best approach is to shrink the context menu is to have a submenu called 'Direct Formatting' in which these entries will be put in, along with 'Clear Direct Formatting'. A submenu for hyperlink might also be beneficial and possibly some of the less used table entries as well, as you already have the table toolbar popup when you are in a table.
Let's not forget the benefits of context menus: * Faster keyboard access than menus: as a keyboard user, you select (for example) a range of text, then hit Shift+F10 to open the context menu. You then get only options relevant to what you've selected, while opening menus takes more steps. This also speaks against nesting inside context menus - that would work against the benefit of having fewer steps to the wanted function. * Less memory load: the context menu opens a list of functions relevant to what you selected, so you don't need to remember which menu contains the function you need. I can see two alternative approaches to simple removal of items: * Rearranging them so the most frequently used ones are closer to the top. * Making context menus customisable by providing the option to remove items. However, most users never change settings in their software (I can provide pointers to research if necessary).
(In reply to comment #7) > Let's not forget the benefits of context menus: > * Faster keyboard access than menus: Most users dont remember shortcuts and even if they do, it would be limited to the shortcuts that work in every application like open, save, cut, copy, paste, and close. Nesting is already present in th context menu and add another layer of nesting, if that is even possible, will only add 1 or 2 additional steps to keyboard or mouse users. > * Less memory load: There is no question that the context menu does customize itself to relevent things, but what is the use of a font list in the menu that doesnt even list all the fonts (a bug that has been around since 2011) and you already have a font drop down in the toolbar that works. You also have drop downs for font size and toolbar buttons for style and alignment options. None of these require you to go roaming through menus to find them. > I can see two alternative approaches to simple removal of items: > * Rearranging them so the most frequently used ones are closer to the top. You forget that there isnt a top or bottom for the menu, as when your mouse is close to the bottom of the screen, the popup appears above the mouse and the menu isnt shown in reverse in such a situation. > * Making context menus customisable by providing the option to remove items. I believe making context menus customisable would be quite an undertaking, devs please correct me if i'm wrong, and think a single checkbox in the Tools > Options dialog to enable them, when they are disabled by default, is a great way to go. > However, most users never change settings in their software (I can provide > pointers to research if necessary). Yes it is true that most users dont change settings, thats why it should be our goal to make the best default user experience for the majority of the user base and if users dislike these defaults, they are welcome to customize it. Customization is always an important feature and thats why we have the options dialog, as well as having customizable toolbars, menus, and shortcut keys. Having a small and concise context menu will result it being easier to see the list and easy to expand on nested features, if that feature is what i'm looking to change. As shown in attachment 102535 [details], you have 5 entries for direct formatting, 8 entries for table options, and 4 entries for hyperlink options. If i only wanted to edit the hyperlink, the menu could have been shrunk by 10+ entries, leaving me with a small concise menu. Calc's context menu is no more than 12 entries long, for no matter thing that is being done. Was digging through the OOo tracking data some more and here are some more findings that i thought would be relevant. Line Spacing: ------------ Set in 'Dialog Indent & Spacing' tab : 44,888 ( 71.24% ) Set from Context Menu : 18,122 ( 28.76% ) ------------ comment: there is no line spacing button in the toolbar and no entry in the menu bar Font Effects (Underline, Strike Thru, Shadowed, Outline, Overline): ------------ Toolbar : 508,600 ( 82.65% ) Keyboard Shortcut : 77,843 ( 12.65% ) Set in 'Font Effects' tab : 18,496 ( 3.01% ) Set from Context Menu : 10,408 ( 1.69% ) ------------ comment: 99.8% of the toolbar number is for underline, as the rest of the font effects dont have toolbar buttons in the default toolbars Bold: ------------ Toolbar : 1,219,353 ( 83.70% ) Key Shortcut : 233,868 ( 16.05% ) Context Menu : 3,620 ( 0.25% ) As the stats are showing, the toolbar is the first place people go for improving direct formatting, which is why a font effects and line spacing button in the toolbar would be such a great thing.
Hi guys, So, a couple of thoughts: 1) It'd be good to get feedback from the a11y team on this. I wrote to their mailing list, hopefully someone will comment. (Michael, do you happen to know whether toolbars are exposed to accessibility technology, and, if not, why?) 2) Font name and font size should be removed no matter what the final decision is -- it's very bad practice to hard-code these, styles should always be used instead. 3) Christophe mentioned fast keyboard access. Given the numbers for context menu usage and given that, based just on my own experience, most people trigger this menu using their mouse, this faster access is rarely used, and it's still not anywhere near as fast as memorizing the shortcuts for individual commands. For quick access to context-based commands, it would be nice to show shorcut combinations over the toolbar when the Ctrl key is pressed, in a similar way to MS Office's Alt key handling [1]. 4) Christophe also mentions memory load. He's right, but the contextual toolbars and the new sidebar should ideally keep users from searching through menus and dialogs. It'd be nice to get more things into the sidebar and slowly get rid of the need to use dialogs. It'd be good to invest energy into that rather than customization. 5) It'd be nice if "Clear formatting", "Change Case", and "Synonyms" didn't appear when no text is selected. Conversely, "Page..." should appear only when nothing is selected. Would that be feasible? 6) If the commands under "Style" are kept, the title of that menu should be changed to "Decoration", "Effects", or even "Format", as "Style" should always just refer to our Styles feature. 7) On the topic of styles, it'd be nice to have a "Paragraph Styles" and a "Character Styles" here. Anyway, I'm for the changes Jay proposed. They're backed by data, easy to implement, and just as easy to reverse if they prove unpopular.
Personally I'm for this modification if accessibility is preserved, we need to cleanup those direct formating.
I should probably start by saying that I personally think that the context menu in LibreOffice is one of the big strengths of the suite. I'd say that removing it in master as soon as possible would be a good thing. Mostly to give people a fair chance to react to this change. But I also like to echo Mirek's suggestion: 7) On the topic of styles, it'd be nice to have a "Paragraph Styles" and a "Character Styles" here. Especially the part about Paragraph styles, preferably only a selection of styles like in the combo box in the formatting toolbar. I have a dream about LibreOffice like Word would make it possible to configure what styles that should be shown in that list in addition to the styles used in the document. A few comments about accessibility. Toolbars are exposed to accessibility even though I'd say it's easier to use the context menu. I feel the accessibility of the sidebar is still quite awkward. As I see it, the use of styles is even more important when working with accessibility tools (especially headings) since it gives structure to the document and makes it easier to navigate. So anything that might increase the use of styles over direct formatting is a good thing. Lastly I'd like to comment Mirek's note 5 about the visibility of "Clear formatting", "Change Case", and "Synonyms", I think these work as expected. I should not have to select a whole word to look up a synonym for it. It should be as it is now when I just put the cursor on a word and look it up. The same applies for the other two.
(In reply to comment #9) > 2) Font name and font size should be removed no matter what the final > decision is -- it's very bad practice to hard-code these, styles should > always be used instead. > ... > 7) On the topic of styles, it'd be nice to have a "Paragraph Styles" and a > "Character Styles" here. I do agree in general that styles should be pushed over direct formatting, as i had personally been using ms word for many years without learning about styles and only understood it when i learned css. We should be promoting features to our users that help them make well formatted documents, even if they dont fully understand the concept. I think microsoft did a good job in exposing styles in its ribbon UI, to bring emphasis to its usage. > 5) It'd be nice if "Clear formatting", "Change Case", and "Synonyms" didn't > appear when no text is selected. Conversely, "Page..." should appear only > when nothing is selected. Would that be feasible? I think synonyms should also not be displayed when multiple words are selected. (In reply to comment #11) > Especially the part about Paragraph styles, preferably only a selection of > styles like in the combo box in the formatting toolbar. I have a dream about > LibreOffice like Word would make it possible to configure what styles that > should be shown in that list in addition to the styles used in the document. I think the list of pre-defined styles found in the drop down are a good place to start, along with the list of applied styles. > Lastly I'd like to comment Mirek's note 5 about the visibility of "Clear > formatting", "Change Case", and "Synonyms", I think these work as expected. > I should not have to select a whole word to look up a synonym for it. It > should be as it is now when I just put the cursor on a word and look it up. > The same applies for the other two. There are entries in 'change case' that dont function well without the selection of multiple words - e.g. Sentence case, Capitalize Every Word. Also noticed that the list doesnt include camel case, small capitals or drop caps.
(In reply to comment #12) > > I think synonyms should also not be displayed when multiple words are > selected. Since a thesaurus can contain phrases so it does make sense to show it even when multiple words are selected. These types of "smart" fixes is what I'm a bit afraid of. It's so easy to forget something like this. The synonym menu is hidden if more than one paragraph is selected so personally I think that is good enough. But from now on I will stop commenting on anything else then what this bug is about, the removal of Font, Size, Style, Alignment and Line Spacing.
I think what we should do is to follow Firefox example: http://msujaws.wordpress.com/2014/05/27/experimenting-with-context-menus/ This would both save functionality and space.
I think once we have an optimal/concise context menu, adding clickable icons like firefox (navigation) or ms office (paste, paste special) do it would be a move in the right direction. I have already submitted bug 81475 regarding the removal/addition of buttons to the toolbar, including all the formatting options available in the context menu that arent in the toolbar - line spacing, character lines (strike thru, overline), and effects (shadow, outline).
I've submitted a patch removing the mentioned entries from the context menu: https://gerrit.libreoffice.org/#/c/11111/ Do we really need the "Page" entry in the context menu? And what about "Character" and "Paragraph"? Another thing: In Calc when you select some text you have a context option named "Default" - I couldn't figure out what it does. Any idea?
(In reply to comment #16) > Another thing: In Calc when you select some text you have a context option > named "Default" - I couldn't figure out what it does. Any idea? It calls .uno:ResetAttributs.
(In reply to comment #17) > It calls .uno:ResetAttributs. Yeah but what does it do? It doesn't remove direct formatting and it doesn't remove assigned styles.
(In reply to comment #16) > Do we really need the "Page" entry in the context menu? > And what about "Character" and "Paragraph"? Thanks Samuel for putting in the patch. Yes we do need 'Page', 'Character' and 'Paragraph', as they are not accessible in the toolbar and you can see they take up the 5th, 9th and 10th ranking in the context menu usage. 5) Paragraph - 41,302 9) Character - 20,466 10) Page - 16,921
(In reply to comment #18) > (In reply to comment #17) > > It calls .uno:ResetAttributs. > > Yeah but what does it do? > It doesn't remove direct formatting and it doesn't remove assigned styles. I guess it _should_ do the same as menu Format > Default formatting (as in Writer, where the context menu name is OK)
(In reply to comment #18) > Yeah but what does it do? > It doesn't remove direct formatting and it doesn't remove assigned styles. Double click a cell and write some text. Mark a word and assign a font color by clicking on the icon, apply a background by clicking on the icon. Leave the cell. Right-click the cell and click item "Default" or "Clear direct formatting" respectively, as it is named in v4.4. Notice that all your direct formatting is gone.
Why call it 'Default' when your in the cell and 'Clear direct formatting' when you right-clicking the cell? Maybe 'Default' needs to be renamed.
Those two are not the same. "Clear direct formatting" does remove the formatting, but "Default" doesn't.
AFAICS "Default" works only on character level and resets the character format to the cell format. "Clear direct formatting" works on cell level and resets that to the applied cell style format.
We should improve the context menu step by step. It’s right that the context menu is quite big (sometimes). /Change Font Name/ and /Change Font Size/ can be removed without annoying a lot of people. They are not very useful. But the top 10 right-click options shouldn’t be removed, except /Page/ maybe, which is not really at the right place, imho. We have access to the Page dialog via the status bar.
(In reply to comment #23) > Those two are not the same. > "Clear direct formatting" does remove the formatting, but "Default" doesn't. Default does for me. Here's an example, open calc, right in cell A1 'What is my name', select 'is my' and set it as bold, right-click hit 'Default', bold is removed. (In reply to comment #25) > We should improve the context menu step by step. It’s right that the context > menu is quite big (sometimes). Its 13 entries long if you have nothing selected and when you do, it adds cut and copy to the list so that makes it 15. > But the top 10 right-click options shouldn’t be removed, except /Page/ > maybe, which is not really at the right place, imho. We have access to the > Page dialog via the status bar. For the new user, page is only accessible from the right-click and from the format menu. New users have no idea that double-clicking the status bar page style text would bring up the page dialog. I didnt know until recently and thats only because i was submitting a bug to have tooltips added to all statusbar entries (bug 82708) and then suggested a unified click behaviour for the statusbar (bug 82707).
(In reply to comment #18) > (In reply to comment #17) > > It calls .uno:ResetAttributs. > > Yeah but what does it do? > It doesn't remove direct formatting and it doesn't remove assigned styles. It does. For example, edit a cell to contain "foo bar baz", then format only the words "bar baz" to bold, then select the word "baz" and choose context menu Default. In Calc there are two different formattings, formats applied to the entire cell and in-cell formats applied to portions of text. If in-cell attributes are applied the cell content is a rich text edit-cell, otherwise it is a simple string text-cell. Applying in-cell Default does not overwrite a whole-cell attribute, so if you format the entire cell as bold the in-cell Default does not have any effect.
(In reply to comment #16) > I've submitted a patch removing the mentioned entries from the context menu: > https://gerrit.libreoffice.org/#/c/11111/ Could we please have consent first what _exactly_ is to be removed? For example, the patch removes also the (misnamed) Style submenu (strikethrough and the like), but this forces the user to go through Character->someTabPage choose option click OK ... that's way too complicated. I'm opposing this specific change.
Hi Eike, Well i was worried about this as well initially, but the sidebar will be shown by default from now on (bug 73151), and it contains all of the missing style (strike through, shadow, superscript, subscript) and line spacing (single, 1.5, and double) options except for two - outline, overline. I will also be trying to get the line position, font effects and line spacing options into the toolbar with my toolbar proposal (bug 81475), so these options will hopefully be available in both places. If you still wish for it to go in a slower manner, most people (me, mirek, cor, arnaud), agree we can easily remove the font name, font size, and alignment options, as they are already both in the toolbar and sidebar.
The sidebar is shown only in Writer and Impress by default. Not in Calc and Draw. Maybe it makes sense to keep the style submenu (except bold+italic) and the line spacing submenu until we have those things in the toolbar. So can we agree to remove the following items from that menu? * Font * Font size * Bold+Italic from the Style menu * Alignment
(In reply to comment #30) > The sidebar is shown only in Writer and Impress by default. Not in Calc and > Draw. Well the purpose of this bug was to fix the context menu only in writer. :) > Maybe it makes sense to keep the style submenu (except bold+italic) and the > line spacing submenu until we have those things in the toolbar. If we are keeping the style submenu, we should probably rename it like Mirek suggested to 'Format' or even better 'Direct Formatting' (as we have a clear direct formatting option), as they are all direct formatting features. I think underline could also be removed as its in the toolbar and sidebar and then separate the line position options from the effect options. Strike Through Double Underline (this could be added, already in sidebar) Overline - separator - Shadow Outline Embossed (this could be added) Engraved (this could be added) - separator - Superscript Subscript The suggested additions are ones that i've proposed for the toolbar proposal and will likely be added into sidebar as well. As we have line spacing options in the menu, maybe we can also add character spacing options as a submenu, as unfortunately it didnt make it into my toolbar proposal.
I agree with Jean-Baptiste Faure, Eike Rathke, and Christophe Strobbe that it's a bad idea to reduce the functionality of right-click menus for two reasons. First of all, After selecting a section, the fastest way to edit is right click -> Fonts. Unlike navigating to the sidebar or toolbar, right-clicking requires no mouse movement. Secondly, users from other suites all expect fonts in the right-click menu. Word 2007, 2013, and Word Perfect all have it there. Jay's argument that it's already in the toolbar and sidebar is a red herring. That's a UX issue with the toolbars and sidebars. When the sidebar is enabled, the redundant toolbar items should be hidden. But that's a separate issue. In 4.4, we've already moved cut,copy, and paste to the top, resolving Jay's primary complaint. Instead of rushing to pare down the right-click menu in 4.4 without a replacement in place, let's now work on Niklas Johansson's ideas to make the right-click menu context aware. If "Fonts" and "Size" have to be removed, then "Character" should be renamed "Fonts". If alignment and spacing must go, then paragraph must stay, so the right-click menus will be gimped to the point of being useless.
Hi Jay, (In reply to comment #29) > If you still wish for it to go in a slower manner, most people (me, mirek, > cor, arnaud), agree we can easily remove ... Are you sure I wrote that :) In comment 4 I express my concerns about removing. Furthermore, repeating a point that I made in another issue in a slightly different manner: numbers indication how much a certain function is used, are a useful data that we must look at, but also difficult to interpret and by no way the single thing to consider.
Created attachment 105364 [details] Context Menu Comparison - LibO vs MS Word vs WordPerfect (In reply to comment #32) > I agree with Jean-Baptiste Faure, Eike Rathke, and Christophe Strobbe that > it's a bad idea to reduce the functionality of right-click menus for two > reasons. First of all, After selecting a section, the fastest way to edit is > right click -> Fonts. Unlike navigating to the sidebar or toolbar, > right-clicking requires no mouse movement. Yes the fastest means is definitely to right-click after a selection, but what use is right-click -> Fonts when you dont even have the full list of the fonts (bug 34085). A bug that has been around for 3 years. > Secondly, users from other suites > all expect fonts in the right-click menu. Word 2007, 2013, and Word Perfect > all have it there. MS Word and WordPerfect do not have it in their context menus. MS Word has a hovering direct formatting box that appears even if you dont open the context menu. WordPerect x7 only has a 'Font...' entry in its context menu. > Jay's argument that it's already in the toolbar and sidebar is a red > herring. That's a UX issue with the toolbars and sidebars. When you have stats that more people click bold in the toolbar (84%) then they do it in the context menu (0.25%), that pretty much speaks for itself. Bold is the number 1 direct formatting option and the number 4 used option in writer, only behind paste, save and copy. > When the sidebar > is enabled, the redundant toolbar items should be hidden. But that's a > separate issue. Only when the sidebar is implemented like IBM Symphony will it truly be possible to eliminate the toolbar. Even if it was possible to replace the formatting toolbar, which it presently isn't (bug 73071), when you click on an image or table another toolbar pops up. > In 4.4, we've already moved cut,copy, and paste to the top, resolving Jay's > primary complaint. My primary complaint is that the context menu is to large and the larger it is, the longer it takes to navigate to the item you really need. Selection Context Menu Sizes MS Word : 11 Libreoffice : 16 WordPerfect : 17 > Instead of rushing to pare down the right-click menu in > 4.4 without a replacement in place, let's now work on Niklas Johansson's > ideas to make the right-click menu context aware. Without removing bloat, add enhancements will simply make it more difficult to get to the think that you are looking for. I would love to check Niklas' ideas if you could let me know his bug number, as i also wanted to suggest contextual aware additions to the menu. > If "Fonts" and "Size" have to be removed, then "Character" should be renamed > "Fonts". Yes 'Fonts' is pretty much the universal wording for this - MS Word, WordPerfect, Kingsoft Writer, Abiword (In reply to comment #33) > Are you sure I wrote that :) In comment 4 I express my concerns about > removing. Sorry Cor, that was my bad. I meant Meeks. :)
(In reply to comment #32) > I agree with Jean-Baptiste Faure, Eike Rathke, and Christophe Strobbe that > it's a bad idea to reduce the functionality of right-click menus Just to mention.. I'm not against reducing the functionality where it is overloaded, I'm against removing things you'll otherwise have to hunt down in 3rd level menus and dialogues. I'm fine with removing redundant functionality that you can access by one mouse click on the tool bar or side bar in a default (!) configuration.
(In reply to comment #32) > .... let's now work on Niklas Johansson's > ideas to make the right-click menu context aware. Compare the context menu for normal text, in a table, for an image etcc... It already is, I think?
(In reply to comment #35) > Just to mention.. I'm not against reducing the functionality where it is > overloaded, I'm against removing things you'll otherwise have to hunt down > in 3rd level menus and dialogues. I'm fine with removing redundant > functionality that you can access by one mouse click on the tool bar or side > bar in a default (!) configuration. Yes I do agree with that to a certain level. But let's also think that there are various types of users: those doing all (as much as possible) with toolbars, those doing lots with the context menu and then - at distance - those working with the menu's and key board
Cor: You're totally right, it's important to consider the different users! In general it's very important to have short mouse paths. The longer the path you have to move the mouse, the more you don't experience the functionality as user friendly. For me that means: I will always prefer the formatting toolbar at the top over the sidebar, because accessing options in the sidebar is much longer measured in mouse path compared to the toolbar. If someone would come to the idea and remove the toolbar at the top, I would personally learn the shortcuts over using the sidebar... Having the addressed options accessible inside the context menu, which is the shortest mouse path at all, personally means user friendliness to me. I'm in general for removing clutter, but this one is useful in my eyes.
Created attachment 105472 [details] Mockup of some condensed menu Here's a mockup of some reduced menu. The general intention of this ticket is indeed good. Why have 5 extra options, which are accessible through the dialogs "Character..." and "Paragraph..." later. My proposal: Reduce this 5 options to one meta option, which has the same functionality but one level down. Or make the options of "Character" and "Paragraph" partially accessible through the menu (some kind like MS office).
(In reply to comment #37) > Yes I do agree with that to a certain level. > But let's also think that there are various types of users: those doing all > (as much as possible) with toolbars, those doing lots with the context menu > and then - at distance - those working with the menu's and key board The context of this bug is for users who use the context menu and from the available stats, they primarily go to the context menu for two things - text selection functionality (copy, cut, paste) and assessing more features only available in dialogs (dialogs for picture, paragraph, table, character, page, etc.) as they are not available in the toolbar/sidebar. For those who are opposed to the removal of the 3 currently suggested options (font name, font size, text alignment), can you list which of them you are okay with removing.
I don't like how attachment 102535 [details] removes quick access to the Menu->Character->Font dialog. As Jay points out, people like me use the right-click to quickly dialogs buried in the menu bar. In that mockup, I would change the name of "Character" to "Font",which appears to have the same options that the side bar gives you now, I would then keep the current "Character" behavior of opening the Character->Font dialog.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f59a1c8169f1492c00d884b6eb3ce954645546f fdo#81132 Remove some formatting options from the right-click menu in Writer The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
As you can read in the commit message we have now removed the following options: * Font * Font size * Text alignment Thanks for all your comments, hope we have found a good compromise.
Samuel, You might need to reopen this. It looks like the "Edit Paragraph Style" is now opening "Indents and Spacing" instead of "Organizer". Is this a bug or done on purpose? Also, what do you think of renaming "Character" to "Font"? It's opening the Font dialog and that's what I think most people will be using it for. Other than that, the new menu looks great. The right click menu was getting unwieldy. Thanks for cleaning it up.
(In reply to comment #44) > It looks like the "Edit Paragraph Style" is > now opening "Indents and Spacing" instead of "Organizer". Is this a bug or > done on purpose? What is Organizer? For me it still opens the paragraph dialog. > Also, what do you think of renaming "Character" to "Font"? It's opening the > Font dialog and that's what I think most people will be using it for. Hm it's opening the character dialog which has a font tab, but it has more than that. Don't think this will be helpful.
(In reply to comment #45) > (In reply to comment #44) > > It looks like the "Edit Paragraph Style" is > > now opening "Indents and Spacing" instead of "Organizer". Is this a bug or > > done on purpose? > What is Organizer? For me it still opens the paragraph dialog. Organizer is the first tab of the paragraph style dialog. For me "Edit Paragraph Style" opens the paragraph style dialog at the tab where you were the last time you opened this dialog. Best regards. JBF
This bug fix comes with LibreOffice 4.4 (release notes https://wiki.documentfoundation.org/ReleaseNotes/4.4) Font, Font size and Text alignment formatting options have been removed from context menu in Writer: according to statistics were widely unused and their removal reduces visual clutter. See a graphic of the work: https://wiki.documentfoundation.org/File:Paste_special_context_menu_Writer_4.4.png
Patch to remove it from calc, impress and draw was also put in last month - https://gerrit.libreoffice.org/#/c/13214/
I’m a little late the party here because I just upgraded to 5.2. While I understand the arguments for cleaning up the context menu. You have gone too far. After the upgrade, I find myself spending much more time digging through menus. And worse yet, sometimes I have to Google features that were once available in the context menu. You have gone too far by removing features that are context sensitive. These add no cutter because they were hidden except for when they are usable. All your analytics may show that a feature is only used .01% of the time. But if you are one of those people that use the feature 100+ times in a single document like I do Bug 107635, these stats are meaningless. I'm sure your stats are from basic non-professional users. Also, you are comparing Apples to Oranges with Word. LibreOffice lacks Word’s mini popup toolbar that appears when you select text. MS Word only stripped down their context menu AFTER introducing the mini popup toolbar. By copying their context menu without the toolbar, you have just cause the UI to take a major step backwards.
Created attachment 133207 [details] Context Menu Comparison - LibO vs MS Word is APPLES TO ORANGES Your comparison to Word is incomplete because you fail to consider the context sensitive mini popup toolbar.
(In reply to Joey Reid from comment #49) > I’m a little late the party here because I just upgraded to 5.2 Well, while you were gone... Context menus, like Menus and Keyboard, are now fully customizeable. To depart from current defaults, add any of your favorite Format commands back to your profile per module. First implemented at 5.1, and fully at 5.2 via Tools -> Customize: "Context Menu" tab. You'll want to modify the Shape, Shape Text, Text or Text Frame. Most commands to be added would come from the Format category. Additions will remain with your user profile. Per module customization can be "Reset" to defaults, or your entire profile can be cleared. Would say read the manual, but this facet of the project needs some documentation work. Just filed bug 107758 against Documentation for that.