Created attachment 109889 [details] context menu for shapes and images If you right-click on a shape or image in Impress, the context menus that appear are way to large and take up more than half of my 900 pixel screen height. The context menu for shapes has 18 entries and the context menu for images has 24 entries. I'd like to suggest the removal of :- 1) Position and Size - This is primarily accessed through F4 by 97% of users and is available in toolbar and menubar 2) Character - More useful to be shown in text boxes and is available in menubar 3) Paragraph - More useful to be shown in text boxes and is available in menubar 4) Arrange - Available in the toolbar and menubar 5) Alignment - Available in the toolbar and menubar 6) Interaction - Available in the toolbar and menubar 7) Custom Animation - already being removed with bug 86607 8) Line - Available in toolbar and menubar 9) Area - Available in toolbar and menubar 10) Description (.uno:ObjectTitleDescription) - Seldomly used and can be added to the menu bar 11) Name (.uno:NameGroup) - Seldomly used and can be added to the menu bar
I would agree with the removal of CHARACTER and PARAGRAPH, because I don't know how this would be necessary for images and shapes (in shapes only context-sensitive if a text inside a shape is selected). The rest I personally currently would prefer to keep. I for instance use very often POSITION AND SIZE, ARRANGE, LINE and AREA from the right mouse click context menu.
Created attachment 109891 [details] mouse movement of 3 of the proposed removals (In reply to A (Andy) from comment #1) > I would agree with the removal of CHARACTER and PARAGRAPH, because I don't > know how this would be necessary for images and shapes (in shapes only > context-sensitive if a text inside a shape is selected). As its possible to add words into images and shapes in impress, this is why it is there. :D > The rest I personally currently would prefer to keep. I for instance use > very often POSITION AND SIZE, ARRANGE, LINE and AREA from the right mouse > click context menu. With a large context menu, the distance between your mouse and the context menu entry and your mouse and the toolbar button is many times a similar distance. (check the attached file to see what i mean :D) About line and area, many of the features available in the dialog box are available in the toolbar, which means that you have easy access to these options without opening the dialog, which is the primary purpose of the toolbar.
(In reply to Jay Philips from comment #0) > .... > > I'd like to suggest the removal of :- > 1) Position and Size - This is primarily accessed through F4 by 97% of users > and is available in toolbar and menubar > ... > 4) Arrange - Available in the toolbar and menubar > 5) Alignment - Available in the toolbar and menubar > ... I don't agree with this ones. I use them a lot and has sense to be in the shape and image context menus as well as in the toolbar and menubars. the other suggestions instead look reasonable to me.
(In reply to Jay Philips from comment #2) > > The rest I personally currently would prefer to keep. I for instance use > > very often POSITION AND SIZE, ARRANGE, LINE and AREA from the right mouse > > click context menu. > > With a large context menu, the distance between your mouse and the context > menu entry and your mouse and the toolbar button is many times a similar > distance. (check the attached file to see what i mean :D) > > About line and area, many of the features available in the dialog box are > available in the toolbar, which means that you have easy access to these > options without opening the dialog, which is the primary purpose of the > toolbar. I understand it and appreciate your proposal very much, but I am used to it and for me it is very intuitive and fast. For instance LINE and AREA belong to a shape and if I touch a shape I expect it in the context menu, because this context menu "belongs" to the shape. Of course, this is subjective and has nothing to do with measuring distances, because from an objective point of view if you think of distances, then you are probably right.
(In reply to Jay Philips from comment #0) > If you right-click on a shape or image in Impress, the context menus that > appear are way to large and take up more than half of my 900 pixel screen > height. The context menu for shapes has 18 entries and the context menu for > images has 24 entries. The fact that a context menu uses so much screen high, is no argument for me. When I'm done in the context menu, all is visible.. If others are used to the context menu for shapes as me... you're going to make a lot of users unhappy. You know, in general, the context menu has the advantage that it shows what can be done on the object. Without having to choose from the items in one or more menus.
So to be clear: I would not change this
(In reply to Cor Nouws from comment #5) > The fact that a context menu uses so much screen high, is no argument for > me. When I'm done in the context menu, all is visible.. It would be an argument for many users who are at resolutions from 800x600 to 1366x768, which is approximately 55% of internet users, when the context menu takes up ~75% of the screen height. > If others are used to the context menu for shapes as me... you're going to > make a lot of users unhappy. So which of the 11 items would you be okay with removal in shapes and which ones for images. :D > You know, in general, the context menu has the advantage that it shows what > can be done on the object. Without having to choose from the items in one or > more menus. The toolbar has the same advantage of showing what can be done with an object. We also have toolbars that appear when you click on a particular type of object, to customize the type of functionality available to that type of object. I removal suggests were primarily of buttons present in the toolbar, as the last thing i would want to do is have people go into the menus. :D
(In reply to Jay Philips from comment #7) > It would be an argument for many users who are at resolutions from 800x600 > to 1366x768, which is approximately 55% of internet users, when the context > menu takes up ~75% of the screen height. Even if it takes 90% of the height, who cares? Reading it is easy and fast. > The toolbar has the same advantage of showing what can be done with an > object. You need a mouse and mouse-over for the tool tips. (Context menu is also in the key board)
Tommy and Andy, Which settings in the Position and Size dialog do you guys primarily go into that menu for? (In reply to Cor Nouws from comment #8) > Even if it takes 90% of the height, who cares? Reading it is easy and fast. I believe this is called bad UI. :D > You need a mouse and mouse-over for the tool tips. > (Context menu is also in the key board) Not for buttons you know the icon or keyboard shortcut for. :D
(In reply to Jay Philips from comment #9) > Tommy and Andy, > > Which settings in the Position and Size dialog do you guys primarily go into > that menu for? I use in the POSITION AND SIZE dialog mainly: - Position (X/Y coordinates) - Size (Width, Height, Keep Ratio) - Rotation Angle (Position and especially Size I use in almost all cases)
(In reply to Jay Philips from comment #9) > Tommy and Andy, > > Which settings in the Position and Size dialog do you guys primarily go into > that menu for? > mainly - Position (X/Y coordinates) - Size (Width, Height, Keep Ratio) don't use rotate that much
Tommy and Andy, Thanks for the info. So do you guys never set the locking of the size or position in the dialog? Isnt it easier to access these settings in the 'Position and Size' section in the sidebar?
(In reply to Jay Philips from comment #12) > Tommy and Andy, > > Thanks for the info. So do you guys never set the locking of the size or > position in the dialog? Isnt it easier to access these settings in the > 'Position and Size' section in the sidebar? No, never thought about this, I do it that way only out of habit
(In reply to Jay Philips from comment #9) > Tommy and Andy, > > Which settings in the Position and Size dialog do you guys primarily go into > that menu for? What is "primarily" ? 30%, 60% ...% of the times I use it. > (In reply to Cor Nouws from comment #8) > > Even if it takes 90% of the height, who cares? Reading it is easy and fast. > > I believe this is called bad UI. :D I see this as a irrelevant remark. You complain about the height. But as longs as it does not run out of the screen and it does not hinder other work (which it does not by design), you need strong arguments to remove access to features here. > > You need a mouse and mouse-over for the tool tips. > > (Context menu is also in the key board) > > Not for buttons you know the icon or keyboard shortcut for. :D I assume that an attitude more focused on trying to understand what someone writes, rather then again explaining what your idea was, may be beneficial here.
(In reply to Cor Nouws from comment #14) > What is "primarily" ? > 30%, 60% ...% of the times I use it. Put another way. What feature do you most frequently used in the dialog? > I see this as a irrelevant remark. You complain about the height. But as > longs as it does not run out of the screen and it does not hinder other work > (which it does not by design), you need strong arguments to remove access to > features here. Making the UI better isnt irrelevant. The longer height makes it more difficult to get to the feature you want. As can be seen in attachment 109891 [details], look at the distance the mouse has to travel if i wanted to cut or copy the object. > I assume that an attitude more focused on trying to understand what someone > writes, rather then again explaining what your idea was, may be beneficial > here. My apologize if i misunderstood what you had written, can you please explain what you meant.
(In reply to Jay Philips from comment #15) > (In reply to Cor Nouws from comment #14) > > What is "primarily" ? > > 30%, 60% ...% of the times I use it. > > Put another way. What feature do you most frequently used in the dialog? Position, size and rotation equal more or less. > > I see this as a irrelevant remark. You complain about the height. But as > > longs as it does not run out of the screen and it does not hinder other work > > (which it does not by design), you need strong arguments to remove access to > > features here. > > Making the UI better isnt irrelevant. The longer height makes it more > difficult to get to the feature you want. As can be seen in attachment > 109891 [details], look at the distance the mouse has to travel if i wanted > to cut or copy the object. That is then the disadvantage for the advantage that the context menu offers a nice access to and view of what one can do. It would be a severe problem IMO if it ran off the screen. > > I assume that an attitude more focused on trying to understand what someone > > writes, rather then again explaining what your idea was, may be beneficial > > here. > > My apologize if i misunderstood what you had written, can you please explain > what you meant. I mean that it looks as if you focus on what your idea is, and not on what someone else is trying to say :) Cheers, Cor
(In reply to Cor Nouws from comment #16) > I mean that it looks as if you focus on what your idea is, and not on what > someone else is trying to say :) You start explaining what you already said. I miss questions like "do I understand well that .." "why do you suggest x/y/z" etc :)
(In reply to Cor Nouws from comment #16) > > That is then the disadvantage for the advantage that the context menu offers > a nice access to and view of what one can do. > It would be a severe problem IMO if it ran off the screen. I would seriously check "the" definition of context menu ;)
(In reply to Cor Nouws from comment #18) > I would seriously check "the" definition of context menu ;) The purpose of the context menu is to provide easy access to frequently used general and contextual features/functions not available in the toolbars, so users dont have to go digging through the menus. The context menu is not intended to be jammed packed with ever possible contextual option available to an object.
Put in the first patch to add the removed name and description entries into the menu bar, removal of the character and paragraph entries, placing position and size at the top of its group of entries, and moved image related options to the top of the menu. https://gerrit.libreoffice.org/#/c/13632/
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f11863d43d96c4bcad9ae43ceb25c05d9a94307d fdo#86614 reorganize image, shape and line context menus It will be available in 4.5.0. 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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca6997fbb8b1f4b8c039db1c487df0ce8961472c tdf#86614 Adjusting some text entries and rearranging and removing others It will be available in 5.1.0. 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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfd0da82964d25d465e3e5f315820bf9dc86a7f8&h=libreoffice-5-0 tdf#86614 Adjusting some text entries and rearranging and removing others It will be available in 5.0.0.0.beta2. 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.