Re: [Rhythmbox-devel] Rhythmbox gnome 3 mockup


I'm aware of Jonathan's response, but I'm neither going to agree nor
disagree directly with him here; I just want to provide some
additional feedback. (Disclaimer: I am a developer, but not maintainer
of RB.)

Also, the original links in your mail seem to work fine for me; no
HTTP/503 here.

On Tue, Dec 28, 2010 at 1:24 PM, Hillar Liiv <liivhillar gmail com> wrote:
> Hello!
> I have some made gnome 3 mockup for rhythmbox:
> I used elements from:
> Any suggestions? Is there any way to make rhythmbox look like this?

1. Is there any way you can re-do these mockups using the Clearlooks
GTK engine? The point would be to reinforce the idea that we are going
to use system-provided widget styles. Cleanlooks engine provides us
with the "stock" look and feel (which you find, for example, in RHEL,
Fedora, and the Devhelp GTK+ guides) to remind us that all the
controls are actually drawn by the installed engine, not custom drawn
by our own code. We probably don't want to get into our own custom
drawing code, because such code is difficult to maintain, and the more
we have of it, the less the UI looks well-integrated into the rest of
the user's desktop. The built-in system GTK engine is there to provide
a uniform look and feel across all GNOME applications.

2. The movable toolbar is ok, but personally, having it on the bottom
of the screen is really distracting to me. It seems like it doesn't
belong there at all. In fact, I didn't notice it in the `Vgn' image at
all for quite some time, despite staring at it several times. I'm
worried that a user will inadvertently tap right-click / left-click,
change the position of the toolbar, and complain that they don't know
how to get it back to where it was. We don't currently support
changing the location of the toolbar; in fact, our UI is not very
user-customizable at all, except for resizing a few of the separate
areas. Extremely customizable media players (e.g. Winamp, for lack of
a better FOSS example) have the limitation of increased code
complexity, and increased risk of user confusion if they do something
inadvertently changing around the UI.

3. I notice that the shuffle icon is also a combo box (drop-down). How
exactly does this work? Is it one of those things where clicking on
the leftmost part of the button toggles shuffle, while left-clicking
on the right edge pops up a combobox menu with (presumably) one item
-- the repeat toggle button? This seems kind of weird; if we had
several different options to toggle, it might be worthwhile, but
making the user learn this UI pattern for one extra button is not
really worth it. This is especially true considering that you have so
much unused space in the toolbar: you could still fit it on a netbook
if you collapsed all the empty space between the seek slider and the
playlist summary ("2 songs, 7 minutes, 8 MB").

4. I like the idea of putting stuff into the window titlebar where the
native decorations go. This is something that Google Chrome has done
for a while, and does it well; other browsers like Opera and Firefox 4
are starting to follow suit. It seems like you have some widgets
overlapping the horizontal space with the max/min/close buttons,
suggesting that we would have to override the native window

This is an interesting problem. On the one hand, this places the onus
on the application to draw the max/min/close buttons. We could either
"try" and get the native max/min/close buttons rendered exactly right
on our own; or we could develop a generic set of them and ship them by
default, like Chrome does. The problem with that is it reduces
platform integration and uniformity by having our own custom
max/min/close buttons that may not resemble those from the native
window manager.

The benefits of this are significant, though. The title bar usually
contains a lot of wasted space, and this is a significant proportion
of the vertical real estate on a small screen (e.g. netbooks). In an
effort not to waste this space, web browsers pioneering the concept of
"widgets where the tittlebar used to be" have tended to put an
application-wide main menu of some sorts in the top left corner,
either with a single button, or just the standard menubar. Chrome puts
its tabs in this space, but obviously we don't have that concept in
RB. The only other elements that should go in the titlebar space
should be the application title ("Music Player" or "Rhythmbox") and
the min/max/close buttons.

5. If you look at how we display the currently-playing track in the
traditional UI, we kind of cram it directly above the seek slider.
This is cool: it doesn't add a lot of width to the toolbar, but it
gives you basically a full stripe across the horizontal of the UI to
list a very long album name / artist / track name combo. Would be nice
to replicate this in your mock-up while retaining most of the other
changes. If you collapse the menus into the title bar as discussed in
item 4, you'll have the same amount of vertical headroom as before for
the playlist (unless you use that really big font for the track name
like your mock-up shows).

Also, what program are you using to create these mock-ups? I might
play around with it and pump out some of my own. Of course I could use
Glade/GtkBuilder Designer and do it that way...

All in all, an interesting experiment!



> Hillar
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]