On Dec 9, 2007 11:26 AM, Alexandre <[EMAIL PROTECTED]> wrote:

> 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)


I agree they're quite useful, right now.  But I think that the frequency of
their use (for most people, including myself) is likely very low.  It's
certainly not the most important of the ideas, though.


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.


For me, I rarely play from playlists.  I usually play shuffle on my entire
library, skipping stuff I don't feel like, once in a while "Browsing this
artist" to play more songs that I particularly enjoyed at any given time.
Greying out items within a month's worth of music wouldn't do much for me.
:P  I like having this freedom to just jump around, but having an organized
play history (and to some degree, a play future) would be very useful.  To
overcome this, I currently have an autogenerated playlist called Last Hour
which lists all songs within the last hour... and it's reasonably
accessible.  However, it's NOT organized by the order of which the songs
were played which reduces its utility immensely.  I can do this, by going
into preferences and adding the Last Played column, then sorting by that,
but I do not want to see that column in every view.  On top of this, I had
to manually create it.  Seeing what the last track (or tracks) played is, I
believe, a very common use-case, which the current UI does not facilitate.

The UI's I proposed are perhaps not optimal, but I hope they get the idea of
the functionality across.


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 did that to have all the information about the currently playing track in
one place.  I don't like the dissociation  created with the album art in the
sidebar.  Perhaps clicking the mini image could toggle the album art in the
sidebar, or hovering would show a larger image.  I guess having the mini
album art next to the info box but outside of it would give it a few more
pixels of dimension....


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


Me too!  That's the idea.  :)



> Alexandre
>
>
> On Dec 9, 2007 7:48 AM, Steven Brown <[EMAIL PROTECTED]> 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)*
> >
> >    - Yes, instead of the Sidebar and Browse buttons set how i have
> >    them, they could be listed as a collection of "view" buttons in the main
> >    area.  This is similar to iTunes, as seen in the image here: 
> > http://www.pyrusmalus.com/_resources/images/blog/itunes_7_and_the_view_controls/itunes_browse_and_view.jpg
> >
> >
> >
> > *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.gladeand
> >    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
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
> >
> >
>
>
> --
> Alexandre Rosenfeld
> _______________________________________________
> rhythmbox-devel mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>
>
_______________________________________________
rhythmbox-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/rhythmbox-devel

Reply via email to