GNOME Bugzilla – Bug 310455
toolbar UI rework
Last modified: 2007-03-25 20:07:20 UTC
As per discussion yesterday on irc, I'm opening a bug to discuss the rework of the current toolbar. My proposal is something similar to evince: 1 - remove the New toolbutton: opening an empty new window is not really useful nor a frequent operation. [Note that the option would be still available from the menu] 2 - remove the Open toolbutton: while not silly as the New one, I don't think that opening a image from the file chooser is a frequent enough operation to warrant a toolbutton. Usually users open images by double clicking in nautilus, by drag and drop and or by viewing a series of images (see below). Open would still be available from the menu obviosly. 3 - Add Next and Prev buttons: a really really common operation when using an image viewer is to walk a collection of images in a folder. I think that EoG should always allow to move to the next/prev image (like when we load a dir in the current behavior). In fact I think this operation us common enough to have the buttons on the toolbar. 4 - Experiment with the Zoom control used in evince... I'm not sure that this fits in EoG, but we should try, especialli considering that EoG handles zoom really well with the mouse scroll wheel, so I don't think that the zoom toolbuttons are used much. Short term (2.12) I propse to just do 1 (kill New) since 3 and 4 require major work on the internals and without doing 3 the toolbar would look too empty if we also remove the Open button.
Sounds great to me! May I suggest a 5:? Move the Rotation buttons to the far right of the toolbar- they are used way less than zooming and Next/Prev.
*** Bug 320826 has been marked as a duplicate of this bug. ***
Is this planned for 2.14?
Yes. See http://live.gnome.org/EyeOfGnome for further information.
*** Bug 159323 has been marked as a duplicate of this bug. ***
> 3 - Add Next and Prev buttons: Although Bug 320826 it was marked as a duplicate of this report it specifically requested keybindings for Previous/Next image. It requested Page Up and Page Down which would conflict with bug #152364 (thanks again for fixing it) however I'd be quite happy to have the keybindings Ctrl + Page Up and Ctrl + Page Down.
Ctrl+PageUp (previous image) and Ctrl+PageDown (next image) keybindings are present in the patch I'm preparing. Also, Ctrl+Home (first image) and Ctrl+End (last image).
Many users will try and use PageUp / PageDown to go to the next image/slide, as that is how it usually works in many other programs (e.g gthumb impress and on windows the standard image viewer and powerpoint). My suggestion would be that iff the whole image is visible that then PageUp/PageDown also goes to the previous/next image
Another nice shortcut for next image would be spacebar. Evince also does this
Ok, commited most of the UI changes suggested here. Specifically, 1, 2, 3, and 5 (sigge). I'm not sure about 4. I still think the zoom buttons are nice. Also, added spacebar as an accelerator for "Next Image" (I don't agree with "switch when the whole image is visible" suggestion). Leaving this bug open for more toolbar rework inputs.
lucasr has been rocking the toolbar, so as far as I can see we now have prev next | 4 zoom related buttons | rot. left rot right. I think there are other candidates to a toobutton: print and fullscreen/start slide. That would lead us to 9/10 items in the toolbar, which may be a bit overwhelming: afaik the magic number of items after which things become difficult to grok is 7. How do we solve that? It looks like the worst offender is "Zoom" which takes 4 buttons. In the original bugereport I proposed investigating using a control similar to the one of evince, though that may be the best solution for an image viewer. Another option is something similar to the one used by Nautilus in navigation mode. Another idea is about rotation: first of all is rotation a common enough operation to require to be in the toolbar at all? If yes, do we really need both rotate left and rotate right... after all pressing three times rot left is the same as rotate right and as far as I know rot left is much more common for switching pictures from landscape to portrait mode. A random idea would be to use a GtkMenutoolButton where rotate left is the button and rotate right, upside down and mirror are accessible from the dropdown menu. Comments? As usual would be nice to discuss my ramblings with a real UI expert (clarkbw, calum, seth, ...)
Nice :-) Thanks for this work. I'm sure because of this quite some users won't feel the need to install another image viewer, because eog just works Can you explain why PageUp/PageDown cannot be bound to Prev/Next image when the whole image is visible? As said almost all viewers use these keys for Prev/Next Image Furthermore the function Prev/Next Image is far more common operation then scrolling images (most people just view the images and don't use zoom). So it is more logical to have a very easy shortcut for Prev/Next Image. Also the scrolling of the images in all directions can already be done with the arrow keys. With PageUp/PageDown you only can move vertically. Most of the time people will just want to be able to move around in the whole image. So they will use the arrow keys. User test --------- Just to test these ideas, I tested this on my girl friend who just knows Windows. First I showed her a full picture and told her to use the keyboard to go to the next picture: She wasn't able to do this. She used the arrow keys to try to go to the next image. That failed. Then used the Enter key. Also failed. Then she got upset about the stupid program. Secondly I showed her a zoomed in picture and told her to move around in the image. She immediately went for the arrow keys and happily moved around. Then I told her that she could also use PageUp/PageDown. "But then I can only move up and down" was her reply. I know it's just a test with one user, but I'll bet you a caiparinha that 8 out of 10 non computer-savvy people won't be able to go to the next image by the keyboard if the shortcuts are Ctrl+PageUp/Down Consistency with Evince ----------------------- In presentation mode in Evince you can use the arrow keys, pageup/pagedown, spacebar to go to the next picture. So for consistency sake it would be really nice that eog used the same keys. Evince just misses the Enter key. I will make a patch for that.
Created attachment 55394 [details] [review] Patch using my proposed keyboard shortcuts Lucas, I know you were not so in favor of my proposal for the shortcuts, but I still hope you (and other people) will try the patch and see how it works in practice. And if you can, test it on non computer savvy people Shortcuts for naviagtion are now the same as in Evince and now work as follows 1. Shortcuts that always work Prev Image Ctrl+Left PageUp (new) Shift+Return (new) Shift+SpaceBar (new) Next Image Ctrl+Right PageDown (new) Return (new) SpaceBar First Image Ctrl+Home Home (new) Last Image Ctrl+End End (new) 2. Shortcuts that work when the image is fully visible (i.e NO scrollbars visible) Prev Image Left (new) Up (new) Next Image Right (new) Down (new) 2. Shortcuts that work when the image is NOT fully visible (i.e scrollbars visible) Arrow keys pans the image Looking forward to hear your feedback on this patch
Created attachment 55500 [details] [review] Updated patch Lucas already applied the part of the (Shift) Return and Shift Spacebar to CVS. So I updated this patch to that it applies again to current CVS
Jaap asked for me to take another look and comment again but I'm sorry to say I very strongly disagree with using unmodified "Page Up" and "Page Down" for anything other than going up and down the page, especially since there are already keybindings for next and previous. Overloading them as suggested seems very risky. I'd be a little less nervous if you could show me examples of other image viewers doing things this way. By all means ask on the Usability mailing list and you will probably get better opinions than mine or people who are less biased willing to properly test out the ideas. (Keep in mind I really wanted bug #152364 fixed so I'm probably the person most likely to disagree with the suggestion. I also suggested Ctrl+Page Down because it is a standard keybinding to go down the whole page to the next page in a variety of other software.) The use of Space to move to the next image sounds pretty good (and it is a reasonably logical leap to have Shift+Space take you back). Personally I wouldn't ever use Return to move to the next image, especially when I could use space but it seems harmless. My only reservation is how some keybinding might be wanted for Slideshow (or some other future feature) which might complicate things if too many keybindings are already taken. Thinking in the context of a presentation it does make some sense where things are fit to fullscreen the idea of a page down moving to the next page does make more sense but I'm still not particularly enthusiastic about having this behaviour everywhere. I think users have slightly different expectations of the slideshow, so it is hard to know if everything in EoG should be completely consistent everywhere or if it is reasonable to treat the slideshow as a special case for all these extra Forward/Back keybindings. I have to checkout Evince because I think it might behave slightly different in a variety of circumstances, so I wont comment until I've checked it properly myself. It would help if there was an easier way to configure the keybindings in EoG. Looking at EoG in isolation single letter keybindings would not be a bad idea at all but as part of the Gnome desktop we really want to reuse the same ideas so users can easily transfer their skills. Is there a menurc file somewhere we should be customising instead of overcomplicating the defaults and trying to do everything? Might make it easier to agree to disagree and more easily test out alternative ideas. Thanks for your patience, tough problem to solve and keep most people happy.
Alan, thanks for your comment. It's clear to me that you do not like the PageUp PageDown behavior of my patch. Do you like the behavior of the arrow keys I introduced? We could have the same behavior for PageUp/PageDown. I.e. they scroll if there are scrollbars and they do next/prev slide if there are no scorllbars. I'll try and find some other test users, to get some more data. And will also bring up this issue on the usability list.
OK tested it the keyboards shortcuts on one more user (not familiar with Linux/GNOME) Tests run with all short cuts disabled so I can observe what people use. For accessing Next Image she was trying in this order: 1. spacebar 2. return 3. arrow keys 4. user gives up For scrolling the image 1. arrow keys 2. user gives up So concluding from these two test I guess PageUp/PageDown does not seem very important and Ctrl+PageDown Ctrl+PageUp is something non computer savvy person probably will never think of
To get some more advice on how to setup the shortcut keys I posted a mail on the usability list [1]. Gabriel Hurt responded that F-Spot already uses the arrow keys to show prev/next image when the image is fully visible, and uses page up/down exclusively for going to the next/prev image. Usability expert Calum Benson [2] also responded to the mail. He basically agrees to my proposal but he has a slight preference to still bind PageUp/PageDown to scrolling when scrollbars are visible. I especially like his suggestion to use Alt-Left,Right,End,Home to images, because of the fact that eog is a browser like app. So my proposal is to update the attached patch such that it implements my suggestions in comment 13 with the change that page up/down is used for scrolling if the image is partially visible. I'll also fix bug 324871 so that page up/down actually scrolls by the proper amount. Furthermore I add the Alt modifiers and show them in the UI instead of the Ctrl modifiers, and the recommended Ctrl+PageUp/PageDown for scrolling left / right. Lucas, Alan. Is such a patch acceptable for inclusion?? Thanks Jaap [1] http://mail.gnome.org/archives/usability/2005-December/msg00191.html [2] http://mail.gnome.org/archives/usability/2006-January/msg00092.html
Hi Jaap, nice catches. Looking at the usability guys comments and your arguments, your suggestion seems fair enough. Go on, attach a patch with the suggested behavior.
I'll start writing the patch as soon as I have my new laptop up and running. The old one broke down :-(
Created attachment 61126 [details] [review] Patch for shortcut keys The patch for the shortcut keys as agreed. NOTE the Ctrl+Home|End|PageDown|PageUp shortcuts are not in the code anymore, but they still work because if you hit any of these key combinations the code for Home|End|PageDown|PageUp gets executed. Since we are in freeze. When would this be able to go in? 2.14.1? Changes: 2006-03-12 Jaap Haitsma <jaap@haitsma.org> * shell/eog-gtk-ui.xml: Add Home and End as shortcut keys for the first and last images respectively * shell/eog-window.c: (action_entries_image) Add Home and End as keyboard shortcuts for the first and last images respectively. (action_entries_collection) Change the keyboard shortcuts of first, last, next and previous image so they conform to the HIG First was Ctrl+Home now Alt+Home Last was Ctrl+End now Alt+End Next was Ctrl+Right now Alt+Right Previous was Ctrl+Left now Alt+Left (eog_window_key_press) If no scrollbars visible PageDown, Right and Down show the next image and PageUp, Left and Up show the previous image Fixes bug #310455 partly * libeog/eog-scroll-view.{c|h}: Add eog_scroll_view_scrollbars_visible function (display_key_press_event) Page up/down now scroll 3/4 of the image (page) height. Fixes bug #324871 Ctrl PageUp/PageDown scroll left/right
GNOME 2.14 has been released :-) Can this patch now go in??
Applied in HEAD. Thanks a lot Jaap! :-) There are some more remaining suggestion from Paolo that I still need to think about. Leaving this open for now.
(In reply to comment #23) > Applied in HEAD. Thanks a lot Jaap! :-) > Thanks Lucas
*** Bug 338601 has been marked as a duplicate of this bug. ***
Paolo, Lucas I'll close this bug, as far as I can see it all this work is part of eog 2.19.1. If some item is not I suggest to open a new bug.