Wednesday, June 3. 2009
From the Post 2.1.0 Git Vaults, Part 4: No more vertical tabs, revisited
In a previous blog post I showed an experimental prototype that aimed to do away with the vertical tab bar along the left edge of Amarok. The many replies to this post was about 50/50 for and against this idea. In the post, I mentioned that I wanted to add some kind of "breadcrumb" navigation bar to make navigation easier and also to always show the user where he "is", something that the tabs, admittedly, quite nicely accomplished, at least for the lowest level (which browser is active).
Since I had some time off last week, I decided to see how I could improve the original idea and add the breadcrumb interface. I quickly realized that the big vertical, kickoff style, back button was not very pretty, so as you will see, the latest version does away with that completely. It also turned out that when you have a nice breadcrumb bar, having each "category" show its own name, as all the services have been doing so far, really does not make much sense, so this is something that I could remove as well. Finally, this new interface finally gave me the chance to display some extended info about each category, before selecting it, something I have been planning to do for a long time for the services and which now makes sense for all categories. The info that is currently shown is just a placeholder until we figure out the real text/image for each item, so don't place too much importance on the actual info just yet!
I guess you think that I have been writing enough and you want to see the video already, so here it is:
Video on youtube
(note that this vid is available in HD)
I think that overall this works much better than the initial version I blogged about (even though I already liked that a lot) and I am confident enough that I can work out the final issues, that I am going to commit this to trunk as soon as 2.2 opens up for development.
Since I had some time off last week, I decided to see how I could improve the original idea and add the breadcrumb interface. I quickly realized that the big vertical, kickoff style, back button was not very pretty, so as you will see, the latest version does away with that completely. It also turned out that when you have a nice breadcrumb bar, having each "category" show its own name, as all the services have been doing so far, really does not make much sense, so this is something that I could remove as well. Finally, this new interface finally gave me the chance to display some extended info about each category, before selecting it, something I have been planning to do for a long time for the services and which now makes sense for all categories. The info that is currently shown is just a placeholder until we figure out the real text/image for each item, so don't place too much importance on the actual info just yet!
I guess you think that I have been writing enough and you want to see the video already, so here it is:
Video on youtube
(note that this vid is available in HD)
I think that overall this works much better than the initial version I blogged about (even though I already liked that a lot) and I am confident enough that I can work out the final issues, that I am going to commit this to trunk as soon as 2.2 opens up for development.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Nice, I can get along with that just as easily as with tabs, and bonus points for getting some contextual stuff in the context window.
Later, Seeker
Later, Seeker
Maybe the '>'-marks where the menu is shown from should state a bit clearly that they are select-boxes?
Currently if a user doesn't know that, and he accidentally doesn't hit them, he might think they're just separators.
Currently if a user doesn't know that, and he accidentally doesn't hit them, he might think they're just separators.
Ah, it's like that in KDE4 overall, and I didn't know that. So here you go.. but I guess that's not up to you, but rather a general matter of KDE4?
That is a valid point, but it falls under the tweaking that will naturally happen once this thing hits trunk! There is a number of other small issues like this as well.
That is why I call these things prototypes. The concepts are solid but not all the details are perfect yet.
There is a number of other small issues like this as well.That is why I call these things prototypes. The concepts are solid but not all the details are perfect yet.
I think the rightmost arrow "button" should be extended to the bolded active label next to it (which afaik has no function unlike the other labels on the left of it). Doing this would make it easier to find out for new users that the whole of the breadcrumb bar is used for nativagtion.
Now that's a nice idea, much better than the kickoff-like system you showed before. I still can't see why Amarok should abandon the vertical tabs, but this is at least a usable replacement.
This looks so much easier to use than the tab system now. I often forget which tab I'm in which leads to me closing the whole panel. My suggestion, though, is to make it part of the song info applet instead of a whole new one. It's wasted space for the majority of the time when I'm passively listening to music & if you're looking for new music you don't need to see what's playing. It makes sense to see the information about what you're currently doing (looking for a new song). Have it all work on mouseover so that if you need to see the currently playing track info you just move the mouse off the panel. Hope to see this soon in the best music player on any platform.
OK, this is much better. I can not really say whether this will be a decent (for me) replacement of the tabs until I try it, but this time I have faith
p.s. Heh, the captcha I got starts with QT4
p.s. Heh, the captcha I got starts with QT4
Because they are the same people who seem incapable of running one of those scripts which grabs videos off of youtube and converts them to a usable format, such as h.264 
In principle I agree completely. Unfortunately this video was a bit too large to host on our own server as this blog gets quite a few hits. So for now, youtube seemed the simplest way to distribute it.
Once the html 5 tag gets a bit more common, I am going to switch to a site that uses this system instead as that is based on ogg theora which is completely free and unencumbered.
Once the html 5 tag gets a bit more common, I am going to switch to a site that uses this system instead as that is based on ogg theora which is completely free and unencumbered.
I can't test as not running the 3.5 beta, but does this not work?
http://www.youtube.com/html5?v=cR3Djq4Gmdw
or
http://www.youtube.com/mpg4?v=cR3Djq4Gmdw
Perhaps not, but they do redirect. My Konq just shows an error about not being html5 compatible.
So I guess it'll be possible in some capacity at some point!
http://www.youtube.com/html5?v=cR3Djq4Gmdw
or
http://www.youtube.com/mpg4?v=cR3Djq4Gmdw
Perhaps not, but they do redirect. My Konq just shows an error about not being html5 compatible.
So I guess it'll be possible in some capacity at some point!
Brilliant, I love it. It's much more consistent with the 'one true way' things are done elsewhere in KDE4; I never had much love for the vertical tabs anyway. Ship it!
I really like it, great work
However, there is an inconsistency in the breadcrumb navigation compared to the one in Dolphin and file dialogues: These breadcrumbs also show the name of the currently selected sub-item, and it has a bold text. The breadcrumb bar you showed completely hides the item which is currently selected, which could indicate that it is no longer available, and which breaks overall consistency (something I always liked about KDE).
(btw, my CAPTCHA ended with "QT" - you made it appear more often, didn't you?
However, there is an inconsistency in the breadcrumb navigation compared to the one in Dolphin and file dialogues: These breadcrumbs also show the name of the currently selected sub-item, and it has a bold text. The breadcrumb bar you showed completely hides the item which is currently selected, which could indicate that it is no longer available, and which breaks overall consistency (something I always liked about KDE).
(btw, my CAPTCHA ended with "QT" - you made it appear more often, didn't you?
This implementation is completely separate from the one in dolphin, mainly because it is quite closely coupled to the dig down interface itself.
That said, I deliberately decided to deviate a little from dolphin on this point as I my opinion, you get the same item listed twice the way dolphin does it, and switching from one item to the same item makes no sense to me. And I took great care to line up the items in the menu with the already selected one. Perhaps tweaking the style sheet of the menu to make it have less of a border at the top, thus nicely integrating the current item into the overall "flow" of the menu...
This is a relatively minor implementation detail though, and something that might change once it hits trunk. Remember, this will have quite a long time to mature before it ever makes it into a stable version of Amarok.
That said, I deliberately decided to deviate a little from dolphin on this point as I my opinion, you get the same item listed twice the way dolphin does it, and switching from one item to the same item makes no sense to me. And I took great care to line up the items in the menu with the already selected one. Perhaps tweaking the style sheet of the menu to make it have less of a border at the top, thus nicely integrating the current item into the overall "flow" of the menu...
This is a relatively minor implementation detail though, and something that might change once it hits trunk. Remember, this will have quite a long time to mature before it ever makes it into a stable version of Amarok.
Showing the current selected item would make the breadcrumb looks similar to a combobox. This would be a good thing imho because it already behaves like a combobox.
GREAT! really, great work! Vertical tabs suck so hard... in fact I'm one of the few complaining about it since ages.. and now you come to the rescue with this brilliant solution! This must be implemented, it's a really good solution cause it doesn't take away functionality.. in fact it adds features like context changing on hover.
Screw the vertical tabs fanatics!
Screw the vertical tabs fanatics!
Positive noises in replies so far but I'm not convinced that is necessarily enough to suggest this is really a good move.
What problem is this trying to solve and can it be solved in other ways?
e.g.
(1) make the highlighting of the active vertical tab clearer
(2) Give a visual hint that clicking on the active tab will hide the side-panel (e.g. a left pointing arrow appearing over the panel on mouse-over the active tab.
(3) animate sliding in/out of panel to let user know what has happened to it.
If this is intended to solve the problem of accidentally hiding the side-panel, note that it only achieves this by removing the ability to do so.
Finally someone on the last list suggested creating an "experimental features" branch for Amarok that (especially if distros packaged it) could allow for more informed feedback on ideas like this... is that totally pie-in-the-sky?
What problem is this trying to solve and can it be solved in other ways?
e.g.
(1) make the highlighting of the active vertical tab clearer
(2) Give a visual hint that clicking on the active tab will hide the side-panel (e.g. a left pointing arrow appearing over the panel on mouse-over the active tab.
(3) animate sliding in/out of panel to let user know what has happened to it.
If this is intended to solve the problem of accidentally hiding the side-panel, note that it only achieves this by removing the ability to do so.
Finally someone on the last list suggested creating an "experimental features" branch for Amarok that (especially if distros packaged it) could allow for more informed feedback on ideas like this... is that totally pie-in-the-sky?
It doesn't solve the inherent problem of vertical tabs: the vertical text. It's simply unnatural to read rotated text.
I am trying to solve a few issues with this. One issue, as mentioned by another answer is that vertical text is really not pretty or easy to read. The only reason we have kept the vertical tabs around for so long (believe me, they have been up for discussion numerous time) as that no one ha so far come up with a a usable alternative.
To me however, what was more important was that we currently have 3 different ways of navigating in the browsers. There is the tabs for selecting browsers, the toolbox thingie for the playlist categories and finally the dig-down interface for the services. I find this hugely annoying when using Amarok, and it also makes for quite messy code when doing other stuff, like implementing the Amarok urls that are capable of navigating to specific view. So what I wanted to achieve was really to unify this navigation.
To me however, what was more important was that we currently have 3 different ways of navigating in the browsers. There is the tabs for selecting browsers, the toolbox thingie for the playlist categories and finally the dig-down interface for the services. I find this hugely annoying when using Amarok, and it also makes for quite messy code when doing other stuff, like implementing the Amarok urls that are capable of navigating to specific view. So what I wanted to achieve was really to unify this navigation.
Vertical text: I don't find it a problem, but if other people do then I can't really argue with that.
As for the different methods of navigation. In some ways I think it actually makes it easier for the user. Multiple levels of navigation with a homogeneous interface can be disorienting. That's not to say it's worse but it might be worth considering.
It's great to see how much though goes into these things, and even better for including public debate.
Thanks to the Amarok devs!
As for the different methods of navigation. In some ways I think it actually makes it easier for the user. Multiple levels of navigation with a homogeneous interface can be disorienting. That's not to say it's worse but it might be worth considering.
It's great to see how much though goes into these things, and even better for including public debate.
Thanks to the Amarok devs!
If you hadn't guessed I prefer the tab system (though not having used the breadcrumb bar I couldn't be 100% certain).
Vertical tabs make intelligent use of the valuable edge-of-screen real-estate as a hit-target. In comparison breadcrumb bars are fiddly and I for one rarely bother to use them.
Vertical tabs make intelligent use of the valuable edge-of-screen real-estate as a hit-target. In comparison breadcrumb bars are fiddly and I for one rarely bother to use them.
Yay, no more vertical tabs!! No more (virtual) head rotation! Finally
I can see two problems with your suggestion, though. First Amarok already needs a lot of horizontal space. With the (admittedly nice) breadcrumbs it could need even more (unless it's squeezed showing "...", which might make it a bit pointless).
Second, navigation of e.g. the Shoutcast directory is (probably) still cumbersome. When you unfold branches the tree becomes incredibly huge. Also it's often way too narrow to show the full stream names.
One problem with current Amarok layout is that a lot of navigation is squeezed into the left panel, while at the same time there is often a lot of unused space in the center (e.g. when you browse an internet service you're probably not interested in the lyrics of the current song atm.). In fact when playing radio streams also the playlist could be removed in favor to gain space for browsing (and playing). Playlist and radio streams don't fit together anyway.
How about a more or less static and comparatively narrow source list (like iTunes or Banshee) on the left and then use the center area with lots of space to display the source content? Yes, this might let Amarok look like a copycat, but IMHO this is simply the best solution for the source selection and navigation problem of audio players.
I can see two problems with your suggestion, though. First Amarok already needs a lot of horizontal space. With the (admittedly nice) breadcrumbs it could need even more (unless it's squeezed showing "...", which might make it a bit pointless).
Second, navigation of e.g. the Shoutcast directory is (probably) still cumbersome. When you unfold branches the tree becomes incredibly huge. Also it's often way too narrow to show the full stream names.
One problem with current Amarok layout is that a lot of navigation is squeezed into the left panel, while at the same time there is often a lot of unused space in the center (e.g. when you browse an internet service you're probably not interested in the lyrics of the current song atm.). In fact when playing radio streams also the playlist could be removed in favor to gain space for browsing (and playing). Playlist and radio streams don't fit together anyway.
How about a more or less static and comparatively narrow source list (like iTunes or Banshee) on the left and then use the center area with lots of space to display the source content? Yes, this might let Amarok look like a copycat, but IMHO this is simply the best solution for the source selection and navigation problem of audio players.
Still not as easy to use a vertical tabs.
It looks like once you go back you need to go fw through all the steps to get to to where you were.
This is really annoying and i think it's a major issue.
Vertical tabs are better as back shorcuts anyway.
It looks like once you go back you need to go fw through all the steps to get to to where you were.
This is really annoying and i think it's a major issue.
Vertical tabs are better as back shorcuts anyway.
Well, yes and no.
You need to keep in mind that the entire thing is never more than 3 levels deep. So it will never, under any circumstance, be more than 2 clicks to go forwards. And in many cases with the current scheme, unless the sub category you are aiming for happens to be open, it will be 2 clicks anyway. Add to this that half the browsers ( collection and files ) do not have any sub levels at all, so for these its really a non issue.
Also remember that in 2.1.0 and onwards, you can "bookmark" views (or categories if you like, I am not sure of the exact terminology to use yet) making anyone accessible with a single click from the bookmark applet.
You need to keep in mind that the entire thing is never more than 3 levels deep. So it will never, under any circumstance, be more than 2 clicks to go forwards. And in many cases with the current scheme, unless the sub category you are aiming for happens to be open, it will be 2 clicks anyway. Add to this that half the browsers ( collection and files ) do not have any sub levels at all, so for these its really a non issue.
Also remember that in 2.1.0 and onwards, you can "bookmark" views (or categories if you like, I am not sure of the exact terminology to use yet) making anyone accessible with a single click from the bookmark applet.
I do agree,
to switch from Playlists to Internet, it is two clicks..... One click would be better...
Keep up the great work on amarok!
Cheers, Neil
to switch from Playlists to Internet, it is two clicks..... One click would be better...
Keep up the great work on amarok!
Cheers, Neil
I think this looks beautiful. However, I see some issues with it. The navigation sidebars were nice, big, and flat against the side of the screen, meaning that I could throw my mouse against the screen and hit what I wanted to hit 9 times out of 10. The home button is far too small of a target: it would be very easy to overshoot or click the wrong button. I can see this pixel hunting being very frustrating in the long run.
I propose this mockup as what I think would be a solution to these navigation woes: http://g.imagehost.org/dl/328a226ba90380b0648d50090ac87297/0359/amaroknavigationmockup.jpg
In this approach, a user would click one of the categories, and the corresponding tray would slide out , leaving a slice along the side still belonging to the 'home' layer. Clicking the side would you bring you home, sliding the tray back and out of sight. These animations would provide excellent visual cues to what is happening and how a user can navigate around (it would be a similar sliding motion to the motion when you click on 'Local Collection' and your music list slides out). A third menu layer could have the same behavior, covering all but a bit of the 1st tray, while still leaving the side open for home.
Also, if you guys haven't read it already, please take a look at http://www.asktog.com/columns/022DesignedToGiveFitts.html . It's an excellent article on Fitt's law, which should be the guiding force behind any usability decision.
Great work on Amarok, and let me know what you think about the mockup!
I propose this mockup as what I think would be a solution to these navigation woes: http://g.imagehost.org/dl/328a226ba90380b0648d50090ac87297/0359/amaroknavigationmockup.jpg
In this approach, a user would click one of the categories, and the corresponding tray would slide out , leaving a slice along the side still belonging to the 'home' layer. Clicking the side would you bring you home, sliding the tray back and out of sight. These animations would provide excellent visual cues to what is happening and how a user can navigate around (it would be a similar sliding motion to the motion when you click on 'Local Collection' and your music list slides out). A third menu layer could have the same behavior, covering all but a bit of the 1st tray, while still leaving the side open for home.
Also, if you guys haven't read it already, please take a look at http://www.asktog.com/columns/022DesignedToGiveFitts.html . It's an excellent article on Fitt's law, which should be the guiding force behind any usability decision.
Great work on Amarok, and let me know what you think about the mockup!
Thanks - Here's the new link
http://www.freeimagehosting.net/uploads/358f1e16d6.jpg
http://www.freeimagehosting.net/uploads/358f1e16d6.jpg
This looks great. Good that you have got rid of this thin vertical back-button, too. Yeah, fitts law. But when you don't run Amarok full screen, that would be terrible to hit.
Which brings me to my point of critique. Amarok 2 needs a lot of screen space, and is best used full-screen on small screens. At the moment one can collapse the middle pane, as shown here **:
http://www.freeimagehosting.net/uploads/05b60ae5e2.png
When I click on the active tab, it shows the middle pane again:
http://www.freeimagehosting.net/uploads/9fc2d2eae9.png
Do you think this would be still possible? Maybe one could add an option to integrate the "middle pane" in the sidebar? (Yay, Amarok 1 feeling)
---
*) Note the suboptimal GTK integration. Maybe, if I'll find some time these days, I'll work on it. Should be possible to improve with some QT stylesheet magic and some svg editing
Which brings me to my point of critique. Amarok 2 needs a lot of screen space, and is best used full-screen on small screens. At the moment one can collapse the middle pane, as shown here **:
http://www.freeimagehosting.net/uploads/05b60ae5e2.png
When I click on the active tab, it shows the middle pane again:
http://www.freeimagehosting.net/uploads/9fc2d2eae9.png
Do you think this would be still possible? Maybe one could add an option to integrate the "middle pane" in the sidebar? (Yay, Amarok 1 feeling)
---
*) Note the suboptimal GTK integration. Maybe, if I'll find some time these days, I'll work on it. Should be possible to improve with some QT stylesheet magic and some svg editing
Well, this just hit trunk together with a pile of other stuff.
One of the other things that has been committed for 2.2 is this http://amarok.kde.org/blog/archives/1018-From-the-Post-2.1.0-Git-Vaults,-Part-3-Something-really-far-out.html which will allow you to remove any part of the ui and move the parts around like you want to, even making several parts take up the same space and switch between them using tabs.
I guess me or someone else really should do a "new features already in Amarok 2.2" blog post as it is quite interesting to see how some of these things that have previously been sitting in separate branches work together.
One of the other things that has been committed for 2.2 is this http://amarok.kde.org/blog/archives/1018-From-the-Post-2.1.0-Git-Vaults,-Part-3-Something-really-far-out.html which will allow you to remove any part of the ui and move the parts around like you want to, even making several parts take up the same space and switch between them using tabs.
I guess me or someone else really should do a "new features already in Amarok 2.2" blog post as it is quite interesting to see how some of these things that have previously been sitting in separate branches work together.
Amarok Links
Calendar
|
November '09 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
Quicksearch
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
