GNOME Bugzilla – Bug 509179
Various UI changes for a better HIG compatibily (and maybe usability)
Last modified: 2018-10-03 16:22:48 UTC
I played a bit with glade, trying to adapt current Cheese UI to HIG, and maybe making it more simple to use. First of all, the most useful design change could be remove the photo/video mode selection and provide one action to grab a photo and one action to start grabbing a video. Users don't have to pre-select a working mode, just clic they want to grab. IMHO this is better. Second, could be really interesting add a toolbar to move buttons[1] and a statusbar to display current status (for example the number of currently saved photos and videos, or if there are applied effects, or, but this is the standard, the tooltip for selected menu entry). Third, add SHADOW_IN to the bottom icon view, and make custom scoll arrow buttons a la Eye of GNOME. See http://svn.gnome.org/viewvc/eog/trunk/data/gtkrc?view=log Fourh: the effects... Honestly I don't have any strong opinion about it. If we want show theme in "preview" area, we should at least disable the other buttons/menu items. Otherwhise we could move them to bottom icon list, and use a notebook to select between grabs and effects (or radio menuitems like the mode selector to switch). The glade file is attached, with the proposed changes (you don't need to agree or adopt all, it's just a starting point to make Chesse better integrated in a GNOME environment) both with and without mode selection. [1] I didn't check cheese code. Is it yet using GtkActions? If so, building menubar and toolbar is a breeze.
Created attachment 102748 [details] Cheese using photo/video mode with toolbar Photo and Video buttons are radio, Grab and Stop are simple buttons. Stop is disabled when mode is photo, Grab take a photo or start recording. The Cheese menu reflect the toolbar: (*) Photo Mode ( ) Video Mode -------------- Grab Stop -------------- Exit
Created attachment 102749 [details] Cheese without modes and using a toolbar All buttons on toolbar are simple button. Take Photo, whell take a photo. Take Video start recording. Stop stop recording. It's available (not grayed) only while recording. Also, while recording, both Take buttons should be grayed (you can't take a photo while recording as well as you can't start another record) Cheese menu reflect the toolbar: Take Photo ----------- Take Video Stop --------- Exit
Created attachment 102750 [details] Glade file with both mochups
Luca, Cheese is already using GtkActions In general I like your suggestions. Some comments: 1) Take Video sounds weird to me. I suggest Record Video 2) For the effects we like to go to a live preview mode in GNOME 2.24. So I suggest we keep it as is for the moment 3) I like the gtkrc approach of eog. Can you provide a patch for cheese?
Created attachment 102766 [details] Another mochup with a more complete toolbar and View menu Changes: * Use Clearlooks as theme for the screenshot (it's the default theme..) * Use a single workd for toolbar item labels (HIG) * Add Preview|Effects radio buttons in toolbar to switch * Add a View menu see below. Cheese menu: Shoot Photo (camera-photo or image-x-generic icon) ------------- Record Video (media-record or camera-video icon) Stop Recording (media-playback-stop) ------------- Exit View menu: [x] Toolbar [x] Statusbar [x] Grabber Items <-- the iconview with recorded stuff ----------------- (*) Preview ( ) Effects ----------------- (*) Large 640x480 <-- "Lock" the preview are to this size. ( ) Medium 320x240 Could be interesting use to choose ( ) Small 160x120 the size of grabbed stuff too. Maybe an addional Custom entry to manually resize the window ?
Created attachment 102768 [details] Latest mochup but without toolbar Same design of latest mochup, just use buttons below the preview area instead toolbar. The Record Video button should change icon (and label?) while recording. This is not so good for HIG, but it's needed to keep the interface so simple and minimalistic. Note the SHADOW_in around the preview area (not needed if we choose to use a toolbar). Final note: IHMO using those buttons there is no suitable place for any other action (i.e. a choose effects button)
Forgot to mention: the View -> Preview|Effects radiobutton group can be, in next versions, expanded to Preview|Effects|Adjustments (contrast, brightness...). Same for respective radio toolbar items. PS BTW we need a custom themeable icon for Effects, Cheese should not use "applications-graphics" only 'cause in current theme is good enough. About custom themeable icons see http://live.gnome.org/ThemableAppSpecificIcons. I'll open a bug adding some GNOME artists in CC
Jaap, I'll check EoG code and I'll open another bug only for this.
Luca, I think we should not have an option to not show the "Grabber Items". If it issnot there how would a user know how to open the photo that was just taken. I err towards having a toolbar instead of the buttons below the preview window, because it's more flexible (you can remove it, have more buttons on it etc.) Daniel, what's your opinion on this?
i totally like the last mockup ;) i dont think a toolbar is great for cheese...
Why do you like the last mockup better? Luca which option do you prefer? BTW Just saw this on planet GNOME http://macslow.thepimp.net/?p=156 it's basically a copy of the effect in apple photobooth http://www.youtube.com/watch?v=1rFV3BJqilk Personally I don't feel like copying the effect. We should be able to think of something better ;-)
(In reply to comment #9) > Luca, > > I think we should not have an option to not show the "Grabber Items". If it > issnot there how would a user know how to open the photo that was just taken. Yeah, it was just to show the power of View menu. > I err towards having a toolbar instead of the buttons below the preview window, > because it's more flexible (you can remove it, have more buttons on it etc.) I agree. Maybe the toolbar is more "boring" then buttons, but it makes really simple (both for code and UI design) keep the needed widget to grab from camera and to choose effects. About the 3-2-1-shoot effect: are we able to put a zoom in/out text over the preview are (somethink like the new-window-appering-from-nowhere in compiz)? Or maybe sliding... The fullscreen flash is awesome.
BTW viewing the youtube video seems to me that the "fullscreen flash" acts just like a real flash...
*** Bug 505517 has been marked as a duplicate of this bug. ***
i think we got the idea of a minimalistic interface pretty good. whats missing is the HIG guidelines, usability and a nice ui (e.g. not aligned buttons..) - i like the idea of dont having two modes, but just two buttons or something like that. its a click easier than we have it right now. - i would leave the effects widget for now, as we are going to a live preview in gnome 2.24 - the menu is a bit crappy in cheese. we should think about doing that from scratch (i dont mean the codebase, but the menu items and that). i like lucas ideas - i added macslows countdown widget. ui freeze is in two weeks, if you want to modify it, feel free - flash: a real flash isnt really possible at the moment, so we just are changing the gamma value of a screen. when metacity has compositing support, we can show a white window and fade that out. that will be a nice flash. - lucas last mockup got it pretty nice, but: - there is no way to change the effect in less than 2 clicks - the picture in a button should always stay on the same side - there is no reason showing 4 arrows in the media bar - eog buttons, rocking! - i like the idea of having _just_ videos or _just_ pictures shown, like in the first two mockups. of course the default should be to show both media formats
(In reply to comment #15) > > - i added macslows countdown widget. ui freeze is in two weeks, if you want to > modify it, feel free BTW I've strange timing issue. I've this sequence: time ---------------------------------------------------------> 1 2 3 camera_icon screen_gamma shutter_sound ^ photo grabbed here While it shoudl be: 1 2 3 camera_icon screnn_gamma shutter_sound The tree events should occur at the same time, i.e. while grabbing photo. > - lucas last mockup got it pretty nice, but: > - there is no way to change the effect in less than 2 clicks The Cool Way(TM) could be put a transient button (to show effects) on the preview area when you make mouseover it. But I don't think GStreamer allow you this kind of stuff. And It's not really HIG... > - the picture in a button should always stay on the same side Yeah, that was a joke. > - there is no reason showing 4 arrows in the media bar ?? > - i like the idea of having _just_ videos or _just_ pictures shown, like in > the first two mockups. of course the default should be to show both media > formats >
(In reply to comment #16) > And It's not really HIG... A bit off-topic: I have been a fan of the HIG for some time now and I have filed quite a few bugs to improve HIG compliance of some apps. But, in some cases, following the HIG to the letter results in sub ideal interfaces I think. Interfaces can lose their simple and modern feel. You just can't innovate that much while following the HIG. So, looking into the HIG for basic guidance is nice, but mostly to be aware if the problems which the HIG intended to solve.
in reply to comment #16 > BTW I've strange timing issue. I've this sequence: > > time ---------------------------------------------------------> > > 1 2 3 camera_icon screen_gamma shutter_sound > ^ > photo grabbed here > > While it shoudl be: > > 1 2 3 camera_icon > screnn_gamma > shutter_sound > > The tree events should occur at the same time, i.e. while grabbing photo. could you open a new bug for that? anyway, i dont get that effect here ;) in reply to comment #16 & #17 you are right, that the hig isnt the holy grail, but we should find a way in the middle
Created attachment 103481 [details] Custom Widget Mockup This is not much about HIG, boo! An idea that came when I had lunch today. Using a custom, filmstripe-like cairo widget. The left side of the stripe can be used to select between two stripes: a photo stripe and a video stripe. Toggeling between the who also toggles photo and video mode. The line above this custom widget has a "take photo" or, depending of the state, a "start recording" or "stop recording" button. Also on this "bar", the old effects button (which would display the effects similar to now) and, for videos, a toggle button to enable/disable microphone capture. Total crack? ;)
Created attachment 103495 [details] Custom Widget Mockup #2 I got some positive feedback on IRC so here's new mockup: # traditional photo/video switcher above the film widget. custom gtk button that works like a lightswitch (one side up, other side down). IMHO this would work great for making the two modes obvious (better than two separate buttons) # mute button directly beside the video button. If photo mode is active, the mute button can be grayed out. # photobook button: a fantastic idea of _ke! Keeps the main window simple by putting advanced (pre-)view and sort features into a new, gallery-like window. Would also allow to apply effects (and perhaps some other simple editing effects) when the photos are already done. # effects button: same as before, using the new cool icon from andreasn. # all buttons (but middle button): icons only, no text labels! I really think we can make good use of icons here that actually say everything that has to be said. # simplified film widget: just one stripe showing the history of recent pictures and movies. Most users are probably only interested in the last few shots, for more, they would use the photobook. Fading should be nicer than what I can do here... scrolling would be done using the arrows or (even nicer) using kinetic scrolling when dragging the black area or the black/white border.
Michael: Wow, the last one is really sweet!
It's awesome that you care about following the HIG, but remember, it's only a guide to usability, not an end in itself. It's possible to have a fully HIG-compliant program that's horribly unusable. Conversely, it may be possible (though it's probably very difficult) to have a decently usable program that thoroughly defies the HIG. My point is, "Various UI changes for better HIG compliance" isn't really a valid bug report -- this is a collection of ideas that probably would make better progress if they were discussed, implemented, and tracked separately.
i think its time to add a few UI-patches to cheese. remember, ui freeze is on 28th february. whos the first?
I find your app great and I can hardly see what you need to improve. I only see one small usability issue in effects - when you click on a effect that effect just gets a blue overlay. That immediately looked too subtle but I shrugged it of as "it's maybe only me". When I introduced cheese to a new linux user and that user didn't register when some effects were active and which ones (sometimes multiple). I had to explain to that user "you see there icons are blue and that means they are active". Also now that I look at it "Back" button should be maybe bigger? I also found that users after applying effect had to look more than they should have in order to find how to get back to taking snapshots or video clips. Thanks for a great app! Valent.
Created attachment 103816 [details] cheese with modes - another version I got an idea and did a mockup really fast so please don't judge it because it really isn't one of my greater works :) Idea is that users should be shown without mistake where they currently are - as it is in previous mockup "cheese-with-modes". This one is just variation on the theme. I have played with shadows and bevel - just to see how different effects look like. Cheers.
Sorry, missed this discussion before I sent some general Cheese/HIG comments here: http://mail.gnome.org/archives/usability/2008-January/msg00055.html
Thanks for taking the time Calum! I have to cite this part: >> Effects: IMHO it would be better if these were presented in a >> sidebar or a floating palette, which could be shown or hidden >> by clicking the button. That way I could see a live preview as >> I was selecting my effects. You'd probably want to make the >> preview icons much smaller if you did this, so you could see >> the full list without having to make the window much larger. I had filed a bug to turn effects into a sidebar previously, but it was not considered a valid request. Actually I think the current effects dialog, without the means to get a quick real life preview, is not very helpful at all. It has been discussed that doing live previews for all effects would be overkill for the CPU, but one would certainly be possible. Simplifying the effect icons and allowing a preview is the way to go, not having to switch back and forth to preview all the effects. For reference, there's also some discussion about this on the GHOP thread¹ where I attached a mockup for a f-spot-like effects bar². [1] http://code.google.com/p/google-highly-open-participation-gnome/issues/detail?id=103 [2] http://code.google.com/p/google-highly-open-participation-gnome/issues/attachment?aid=-111557126251633186&name=cheese.png
Created attachment 104057 [details] Proposal that look similar to totem I made this mockup from some of the ideas provided by Calum and the current UI of totem. - The ComboBox [1] with "Effect" selectionned also contain two more entry : "Pictures taken" and "Video taken" - The list of effect is instant apply and permit multiple selections. - The stop button is only active while recording
Daniel asked me to add my comments on the UI here. I am a lazy bastard and thus didn't read through all the comments already posted here. So, taking the risk of duplicating what has already been suggested: - I want preview when i choose an effect. I'd thus recommend: live-preview-on-mouse-hover in the effects panel. - It sucks that the video/photo buttons behave like radio buttons but aren't. Perhaps they should actually be some? It would certainly be more intuitive, though not as pretty. Alternatively: drop down list box. sucks a bit too. - It is strange that the effects panel is hidden in the "edit" menu. It should be in the "view" menu together with an option to switch back to preview mode, as radio menu items, of course. - It would be preferable if effetcs would be reachable by a button that has a forward sign in some way on it: >>. And then go back to preview with <<. That would have a bit of a wizard-like UI. Makes sense to me. Maybe not to you. Dunno. - It is not clear what Edit|Move all to trash means. To which objects does "all" refer to? - It would be nice if the album bar on the bottom of the window would contain some (maybe light gray) text in the bg which describes what that area is actually used for. - If I select "Photo" I expect only photos to be shown in the album bar. If I select "Video" only videos should be shown there. That's it for now.
is this bug still relevant? what could we take out of the bug report?
Speaking of UI changes, I'd really like to remove the text from the "Take photo"/"Record video" button. Maybe we could get some artist to draw two custom icons that could replace the current "icon + label" thing. It wouldn't be just an aesthetic change, the labels casually have the same length in English but can have different lengths in other languages so if I shrink the window to the minimum size and then go to video mode the window changes its size (see bug 573301). I tried more than once to mess up with glade for a couple of hours and fix that bug and I'm almost sure there is no way that not involves some hacky voodoo. Maybe we could have a cool icon (eventually themable like the effect one) that wouldn't make us miss the labels. Also the Photo and Video labels in the "radio" buttons could be easily removed since the icon it's already pretty much self explanatory. This could probably be made optional or dependent to the current global toolbar_style.
Filippo: I'm uncertain if there is a globally recognized image for photo. Daniel suggested a camera (this is also what PhotoBooth on the Mac use [1]). Problem is, that icon is already used for the camera button. The record icon isn't really optimal in this case either, since it's primary connected to recording sounds and video on most consumer electronics, but never for taking photos. A wide record/take photo button is pretty nice since it makes a great hit target (and it also communicates that it's the most important button, since the bigger the better). Isn't there some way to always make the record button, say a third of the width of the window that would fit both the record and take photo text in all current languages? 1. http://upload.wikimedia.org/wikipedia/en/3/32/PhotoBooth.png
What about getting rid of the take photo/start recording icons and at the same time make the button a bit wider? :)
The tricky thing is not the button size. There will always be a minimum size of the window when all the widgets are scaled down to their minimum size. The thing is that the minimum size of the take_photo button changes with the label size. So when you change the label the whole window is rescaled to adapt to the new widget size. The only way I see to fix this is to hardcode a big enough minimum size either for the window or for the take_photo button but there is no chance to find a good one because it will depend on the current theme, the font used, etc... Another thing I could do is to remove Photo and Video labels from the toggle buttons. That will have the side effect of giving more space to the take_photo button pushing down the size where the unfortunate window shrink on label change will actually happen. At that size maybe the window is little enough to not cause any issue since no one will ever use it at that size.
(In reply to comment #34) > Another thing I could do is to remove Photo and Video labels from the toggle > buttons. That will have the side effect of giving more space to the take_photo > button pushing down the size where the unfortunate window shrink on label > change will actually happen. See "Custom Widget Mockup #2" which would IMHO work very well, even without the icon on the take photo button. Using only icons for Photo/Video is no issue IMHO because the icons are quite clear and a custom combined toggle button widget like shown in the mockup helps, too.
phew. Generally speaking: I'd like you to use mailing lists to discuss stuff and use the bugtracker to more or less keep track of the status of an identified bug. As for this bug: Given the discussion after comment #30, I assume this bug is still relevant. I am thus reopening.
in the master branch we used quite some ideas from this. if you still are not happy with it, lets discuss on the mailing list or on a new (more specific) bug