Hey, playlist is just an ordinary thing - it\'s just ok to have that one amarok owns at the moment.

After using amarok for half a year or so, I\'ve started to feel that I need more and more control over my music playlists.

Playlist navigator sucks. Without any doubt it sucks, when it comes to quick switches between playlists. It\'s a wonderful thing just for storing playlists that you know you won\'t edit too frequent.

The present playlist is good, but it could be perfect, if the devSquad introduced a usability improvement by adding favorite `tabs\'. I see it working like this (very similar, almost identical, to the Koqnueror\'s tabbed navigation mode)

Right under the Search field there\'s a line for tabs of playlists. Identically to Konqueror (Mozilla, Opera and whatever else on earth...) if we have just one playlist currently in usage the application shows only the playlist without any bars between the Search field and the playlist\'s area itself. If a user needs to create one more playlist leaving the current one without any changes (no additions, or removes), he\\she does one of the next actions:

* presses a \"$Defined_Key01+$Defined_Key02\"
* goes to a menu `Playlist->Add new playlist\'
* any other way possible and suitable for the application

A happy user now has got two playlists, e.g.

\"The Cranberries\" | \"New Playlist\"

Okay now, a user can even dj with amaroK :woohoo: switching between queued tracks from different playlists. It\'s a convenient way to handle current playlists which you are NOT going to save after the application\'s sent the SIGTERM from a user

It\'s damn good feature that can level up the amaroK\'s usability even more.
Playlist navigator is GOOD ONLY WHEN a user is intended to store a playlist for a long time.

PS: There\'s been one more request for such a feature previously:
http://amarok.kde.org/component/option, ... /catid,16/

Really this would reduce \'usability\' if you define usability as being easy to understand and use when starting out. I agree if you want to do more advanced playlist handling amaroK falls short. But basically have just straight tabbed playlist would have all sorts of problems that would have to be solved, basically where would the user expect newly added tracks to end up in.

eean wrote:

basically where would the user expect newly added tracks to end up in.

In the active tab?

it can be done as markey presumed, or\\and as follows:

a user browses his collection either with the help of \"Collection\" navigator or \"Files\" navigator and when he\\she clicks right mouse button he\'s suggested a service menu where he sees the next:

----------------------------------
----------------------------------
Add current track to
----------------------------------

he points the cursor to that menu and gets a submenu with the list of currently created\\opened tabbed playlists:

Add to the current playlist
Add to the playlist \"$name_01\"
Add to the playlist \"$name_02\"
Add to the playlist \"$name_03\"
Add to the playlist \"$name_04\"

The quantity depends obviously.

What do you think?

Ivan Lezhnev, Jr. wrote:

it can be done as markey presumed, or\\and as follows:

a user browses his collection either with the help of "Collection" navigator or "Files" navigator and when he\\she clicks right mouse button he\'s suggested a service menu where he sees the next:

----------------------------------
----------------------------------
Add current track to
----------------------------------

he points the cursor to that menu and gets a submenu with the list of currently created\\opened tabbed playlists:

Add to the current playlist
Add to the playlist "$name_01"
Add to the playlist "$name_02"
Add to the playlist "$name_03"
Add to the playlist "$name_04"

The quantity depends obviously.

What do you think?

Once again, the "Tab Topic" arises and I would like to state my opinion, as tried to explain in the wiki under "Main Window refactored"

Tabs would extend the complexity of the interface in an unecessary way. Tabs were introduced in the GUI world long ago and misused at least for the same time. You can
achieve the same results by rethinking the goal and usage scenarios.

The playlist tabs can be replaced by splitting "active view of a playlist" from the "actualy played playlist" in the playlist browser and marking the last one as beeing such (hilighting or like this). This way a single click would show the contents of a playlist and a double click would make it active aka. "play this list" (eventually with differentiating between "now" and "after current song").
How to edit this playlists? select one view as source (collection, filesystem, another playlist) and use drag-and-drop on the left pane for adding songs into another playlists. removing is as easy as hitting "del" on the song in the active view.

RESULT: no additional gui concepts; no additional complexity and a lot of space saving.

animefan

animefan wrote:

The playlist tabs can be replaced by splitting "active view of a playlist" from the "actualy played playlist" in the playlist browser and marking the last one as beeing such (hilighting or like this). This way a single click would show the contents of a playlist and a double click would make it active aka. "play this list" (eventually with differentiating between "now" and "after current song").

If I get you right, this is pretty much what JuK does. And I have to say I really dislike this concept. It\'s a step backwards from the freely editable playlist system that amaroK does well.

animefan wrote:

Tabs would extend the complexity of the interface in an unecessary way.

It heavily depends on what you mean by complexity of the interface. If you consider it to become complex from the point of view of a programmer it\'s one deal, if you consider this complexity purely an obstacle for users to perform the task it\'s quite another deal.

The playlist tabs can be replaced by splitting "active view of a playlist" from the "actualy played playlist" in the playlist browser and marking the last one as beeing such (hilighting or like this)...
animefan

What if I need more than 3 playlists opened at the same time?

Ivan Lezhnev, Jr. wrote:

animefan wrote:

Tabs would extend the complexity of the interface in an unecessary way.

It heavily depends on what you mean by complexity of the interface. If you consider it to become complex from the point of view of a programmer it\'s one deal, if you consider this complexity purely an obstacle for users to perform the task it\'s quite another deal.

Nah, it would probably be complex from both points of view.

eean wrote:

Nah, it would probably be complex from both points of view.

Oh, okay. One thing is obvious, the current playlist doesn\'t respond the demand of functionality. There\'s a demand (you can start a poll to gather a bit more information) for extended functionality as described above. I think, it doesn\'t matter how it is realized, whether it\'ll be tabbed interface or something else. What matters is the usability aspect.

Any ideas about how to do that? :ermm:

Post edited by: Ivan Lezhnev, Jr., at: 2005/05/10 20:57

markey wrote:

animefan wrote:

The playlist tabs can be replaced by splitting "active view of a playlist" from the "actualy played playlist" in the playlist browser and marking the last one as beeing such (hilighting or like this). This way a single click would show the contents of a playlist and a double click would make it active aka. "play this list" (eventually with differentiating between "now" and "after current song").

If I get you right, this is pretty much what JuK does. And I have to say I really dislike this concept. It\'s a step backwards from the freely editable playlist system that amaroK does well.

In what way it\'s a step backwards? I don\'t get it. What do you dislike in this concept?
The playlist handling as it is now in amarok (1.2 at least) is not very flexible. Most annoying "feature" is you can\'t easile take a look at another playlist, while one playlist ist playing (active). So what do you mean by "freely editable"?

animefan

Ivan Lezhnev, Jr. wrote:

animefan wrote:

Tabs would extend the complexity of the interface in an unecessary way.

It heavily depends on what you mean by complexity of the interface. If you consider it to become complex from the point of view of a programmer it\'s one deal, if you consider this complexity purely an obstacle for users to perform the task it\'s quite another deal.

I don\'t deal with complexity at developer level as it is irrelevant. Applications are there to make the life of users more easy, not developers - and I am both.

The playlist tabs can be replaced by splitting "active view of a playlist" from the "actualy played playlist" in the playlist browser and marking the last one as beeing such (hilighting or like this)...
animefan

What if I need more than 3 playlists opened at the same time?

Please describe a scenario with more than 2 playlists at the same time. I think all of this kind can be mapped on 2 playlist ..... oh, wait: finding differences between two playlists (manualy) would be such one, but with tabs it isn\'t possible either. You would need split-screen. Are there more?
Simple editing by moving songs from one pls to another is a 2-open-pls-thing.

I think the main problem is with screen \"real estate\"

We have this great big space on the right that is great for showing track information (artist, title, length, compression, bitrate, year, etc.), but it can only be used for things we have already decided to play! If you want to see the contents of a playlist, you either add it to the queue to view it in detail, or are forced to view it in a really small display on the left (which, incidentally, is user interface duplication).

I agree it would be a lot better to be able to navigate playlists without actually queuing them up for play.

Also, the current system makes smart-playlists very unusable, since you can\'t see their contents AT ALL before queuing them up for play.

My suggestion is the same as I have proposed before: make the right pane a \"live\" playlist display, that shows the currently selected playlist, and add some special button to access the \"queued for play\" playlist, where all the songs that are actually going to be played go.

sgomes wrote:

I agree it would be a lot better to be able to navigate playlists without actually queuing them up for play.

ACK

Also, the current system makes smart-playlists very unusable, since you can\'t see their contents AT ALL before queuing them up for play.

YES!

My suggestion is the same as I have proposed before: make the right pane a "live" playlist display, that shows the currently selected playlist, and add some special button to access the "queued for play" playlist, where all the songs that are actually going to be played go.

other words for same idea - seperating "view" and "active" playlist ...

animefan wrote:

My suggestion is the same as I have proposed before: make the right pane a "live" playlist display, that shows the currently selected playlist, and add some special button to access the "queued for play" playlist, where all the songs that are actually going to be played go.

other words for same idea - seperating "view" and "active" playlist ...

This idea doesn\'t sound too shabby. Its just a manner of how to do it.

eean wrote:

animefan wrote:

My suggestion is the same as I have proposed before: make the right pane a "live" playlist display, that shows the currently selected playlist, and add some special button to access the "queued for play" playlist, where all the songs that are actually going to be played go.

other words for same idea - seperating "view" and "active" playlist ...

This idea doesn\'t sound too shabby. Its just a manner of how to do it.

How about with tabs?