GNOME.org
 

Re: [Rhythmbox-devel] Layout Ideas 2 (specific UI details, mockups, etc)

I like some of your ideas, but some seem to be a step back.

Search, for instance, I love the way RB is now. I dont need to click a button, I dont have to think about popup interaction, it's just always there when I need it. Maybe the filter buttons could be agrouped into a popup, but that would be really annoying if you need them often (I dont need them, but someone might)

In the control buttons, the history thing in the next/back buttons is just a horrible idea. This is not a browser, you dont need a quick jump sort of button. I like the way iTunes and Amarok fade played items in a playlist, but RB doesnt have a playlist the way they do, which is great, but has it's shortcomings. One way to improve it is to have the play queue show the last played item, but that might be confusing.
In most players the controls button have moved to the center (WMP, iTunes, Amarok2), which is a great improvement. Maybe RB could do the same?
And I dont really like separate buttons for Play/Pause. It could change to Pause when Playing to become clearer. But one of the best things in RB is the Play button.

I liked the way you changed the track info. Especially, I think there should be more emphasis to the album cover art. But I didnt like how it is constrained in that rectangle.

I hope this discussion will continue and have a real impact in RB's interface to make it even better.

Alexandre


On Dec 9, 2007 7:48 AM, Steven Brown <steven w j brown gmail com> wrote:
This is a follow-up thread.  The original can be seen here: http://mail.gnome.org/archives/rhythmbox-devel/2007-December/msg00044.html

First of all, thanks for the replies.  Of course I want all feedback, both positive and negative.  That's how designs get improved!  Second, sorry for the length of this email.  I've tried to group all information as best I could and I've tried to address all issues broughtup by the 3 people that replied.  A variety of attachments are included.  HTML was used to help improve readability.  I hope it doesn't do the opposite for anyone.


View Buttons instead of Sidebar/Browse toggles (Link included)

How does search work? (Mockups)
  • Click the icon to bring up a popup menu to select the fields to search.
  • When nothing is typed in the search field, it shows what will be searched, "Albums."
  • Also, if nothing is in the field, the Clear icon is not sensitive.
  • Typing something, makes the Clear icon sensitive.
  • Default search would be "All" but default text would just be "Enter search terms" or something general.  I have a feeling most people won't need to filter specifically on artist, album, or title, and displaying these options all the time clutters the UI.  The arrow on the binocular icon still makes them very discoverable, but they're not, as Edgar Luna pointed out, ONE click anymore.  Instead, it would be TWO clicks.  (But the the clicks are much closer in location, so there's less mouse movement... :P )
  • See search_default.png and search_popup_with_terms.png

Search, Repeat, and Shuffle moved below the "active view."
  • For the longest time, I thought the "Repeat" button would loop the currently playing track.  Obviously I was wrong, it seems to loop the currently active "view" or playlist.
  • These operations act on the active view, and I just wanted to make that more clear through the UI.  (Although, from performance, it seems as though search is done before the Browser filter is applied, which seems backwards, but I guess that's because it's a plugin?)

Song Info changes (Alternative mockup attached)
  • I've found the current "Title by Artist from Album" format not clear enough.  Instead of changing the Album and Artist to italic (more difficult to read), more space should be added between the fields.  Using an icon instead of "By" and "From" would also help.
  • The box format I thought could be almost the same as the RB tooltip and notification, which would be really cool and transitive.  :)  But I've provided a longer alternative.  slim_song_info.
  • Yes, longer text could be truncated with "...".
  • See controls_thin_long.png for updated song info box.

Main Controls (Mockups attached, Glade attached):
  • From reading bugzilla and the mailing lists, I think the history of the RB UI went something like this (but I'm likely completely wrong):  [Prev | Play/Pause | Next], but because HIG says UI elements shouldn't change, Play/Pause became a toggle button: [Prev | Play(1/0) | Next], but then HIG also says different types of buttons shouldn't be mixed.  Then came the current iteration: [Play(1/0) | Prev | Next].  The HIG is great, but they're just guidelines.
  • Play should not be a toggle button.  Once it is playing, it's not immediately obvious how to Pause.  If Play become Pause after the user clicks it (they're already looking at it), it's very obvious.  Or, something like the "toggle combo" button (see below) would also make it obvious.
  • Moving Play/Pause in between Rewind and Forward just makes the controls feel natural.  Look at your iPod or MP3 player.  Look at iTunes and other media players.  This wouldn't be so important, but combining it with the time-bar completes the "naturalness" and provides all the primary controls within a clear and reasonably compact area.  See primary_input_comparison.png.
  • I've also attached a popup menu to the Rewind and Forward buttons.  This will provide the last and next X number (10?) of songs, and allow the user to jump to them very conveniently.  I think this would be very useful.
  • See controls_thin_long.png, controls_everything_3btn.png, controls_crackplay_with_history.png, buttons.glade, and test.py

Toggle combo Play/Pause ("crackplay") button (Mockups, Glade & Python attached):
  • This is just something I was playing around with.  I liked the idea of having both Play and Pause operations visible on the same button.  Muine did this, but it was a toggle button, which made things worse.  This idea toggles the sensitivity of the images for the operations.  Playing: Play is not sensitive, Pause is sensitive.  Paused: Play is sensitive, Pause is not sensitive.
  • I had fun with this, including the current state within the button, but I'm not sure it's as clear to the user as simply toggling the Image/Label.
  • See controls_crackplay_with_history.png.  Grab the buttons.glade and test.py to test out a prototype of the button.  The size of the button could be reduced, obviously.

The Time Bar:
  • "...but I really need a long time bar to select the right second of my progressive metal/classical music." - Edgar Luna.
    • If you really need to jump to the second, wouldn't a "go to" dialog be better?  Maybe brought up with a small arrow button next to the time slider?  I'm guessing most people don't care about this (10%?).  If it is something that is needed, it's better to provide method specifically for this rather than using a widget that's not designed for it...  (Forcing a square block into a triangle hole?)  The time bar has so many issues....
  • Mouse wheel is useless.  Does it move in increments of 2 seconds?  Too slow.  Normally, I wouldn't even attempt grabbing a slider, I'd just roll my mouse wheel a couple times until I got where I was going.  Maybe the increments should be a percentage of the current track length.  (Same for the "Scan" functionality on the buttons.)
  • Because I can't use the mouse wheel, I try clicking and holding on either side of the slider.  This seems to move in increments of 10 seconds, which is much better for this 6 minute song.  But when I let go, it doesn't always play where I stopped it.  This seems to be the best method for scanning, but unfortunately, perhaps the least obvious.
  • Grabbing the slider seems like the most obvious way to scroll through the track.  The slider is roughly 20 pixels wide and 12 pixels high.  And moving.  It doesn't move at a blistering speed by any means, but still.... I don't think sliders were really made as track progress indicators/scrollers.
  • There is also jumping with the middle mouse button.  If I do that a few times on a track, RB will hang, and probably crash.  Not sure if that's common.  For me, my middle mouse button is the scroll wheel, and it's the most unpleasant to press.  Most people don't even know you can press it.
  • Often when I'm scrolling, I'll get unpleasant clicks and pops.  These make me not want to scroll.  I'm not sure if these are because of RB or GStreamer or what.
  • So with a smaller time bar, you could quickly select roughly where you want and use the mouse wheel or the nice large Forward/Rewind buttons to fine-tune.  If you know exactly where you're going, via a "go-to" plugin or default dialog, enter it and go.
  • To avoid the unpleasant playback, maybe when clicking *anywhere* on the slider bar should jump to that point.  Clicking and holding could provide a semi-transparent "ghost" slider with a tooltip of the time to jump to.  The same could be provided when scanning.  The song would continue playing at its original position until the ghost slider has been told to go away (the user is happy with the position and releases the mouse button) - the real slider jumps to the ghost slider's position and starts playing from there.
  • See progress_ghost_drag.png

Too much space is wasted in the top-right (Mockup)
  • I made the time bar and info box both longer.  I don't think making the infobox longer is necessary, but the timebar was too small before.  Now I think it's just right and goes with the extra Prev/Next dropdown controls I added.  See controls_thin_long.png and controls_crackplay_with_history.png
  • plugins?
  • visualizations?
  • Space is flexibility!  :)
  • Default setup should definitely look sexy, though.


Once again, all comments welcome.

Steve

_______________________________________________
rhythmbox-devel mailing list
rhythmbox-devel gnome org
http://mail.gnome.org/mailman/listinfo/rhythmbox-devel




--
Alexandre Rosenfeld
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]