GNOME Bugzilla – Bug 320270
rotate left and rotate right should be under view menu
Last modified: 2010-03-27 13:42:11 UTC
Most of the menu items related to the layout and appearance (i.e. view) of a document are under the View menu. For some reason Rotate Left and Rotate Right are under Edit instead, making them harder to find. Other information:
Agree, but there are too many items already.
Yes, it was done this way by design. The rotate menu items are a persistant rotate, meaning when you open the document up again next time it will be viewed in the same rotation. This supposedly means it's an "Edit" action instead of just a "View" action.
Do you think most users will expect to find it there? If you were in Word and wanted to change between Normal and Print layout, you would go to the View menu, regardless of whether that view would be remembered next time you open it. (Not that Word proves the point, but it is an example.) Likewise, most applications (probably including Adobe Reader) will have the Landscape versus Portrait option in the View menu. If I click "View->Toolbar" in Epiphany, the browser remembers this selection, even for new windows. If I click, "View->Group by Threads" in Evolution, this folder will be grouped by thread until I tell it otherwise, even after quitting and starting the program again. In Evince, I think the Continuous versus Dual option is also persistent. The fact it's persistent is a nice bonus, not a good reason to put it in the Edit menu.
*** Bug 336355 has been marked as a duplicate of this bug. ***
I wouldn't say it's unreasonable request, but we need complete proposal for menu layout, also we need a place for History submenu.
The current View menu has: ------------ Toolbar Side Pane ------------ Fullscreen Presentation ------------ Continuous Dual Zoom In Zoom Out Best Fit Fit Page Width ------------ Reload ------------ I think the simplest layout would involve adding Rotate Left and Rotate Right in their own group, probably just before or after the Continuous, Dual, Zoom In, etc. group, something like this: ------------ Toolbar Side Pane ------------ Fullscreen Presentation ------------ Continuous Dual Zoom In Zoom Out Best Fit Fit Page Width ------------ Rotate Left Rotate Right ------------ Reload ------------ What more detail do we need?
Having so large menu is bad from usability point of view, there should be no more than 7 items in one menu.
Hi Michael, I understand the desire to align the menus as you've proposed. In the general case I would often agree with what you're saying. However we've layed the menus out as they are now because we think it looks better. I don't think there is a way to acurately argue that the usability of the menus more strictly categorized is better than layed out more evenly as we have them. We could go back and forth for a while because I think both are good points, but we've chosen to do it this way just like we've chosen to do a number of things differently than previous applications. I hope you'll understand that. If we change things up in the menus sometime in the future then I think we could revisit this.
Nickolay, "there should be no more than 7 items in one menu" is not an excuse to put a menu item in an illogical place. It's a good trigger for a reality check, because maybe items have just been dumped in one menu when a new, more specific menu should be created for some of those items, but it shouldn't trigger a thought process of "well, we've got more than seven items, which ones can we move to another (arbitrary) pre-existing menu". Bryan, a user should not have to look in every menu to find an item. It should be where the user first expects to find it. Can you explain why a user expects to find it under Edit?
*** Bug 494094 has been marked as a duplicate of this bug. ***
*** Bug 613451 has been marked as a duplicate of this bug. ***
I was unsure whether it was safe to use the rotate tool for the very reason that it was under the Edit menu. I didn't want the document modified. I understand now that this was done to balance the load of the menus but I think it was a bad choice as it mis-represents the function of the button as an edit operation, as opposed to a view operation.