yungtrizzle wrote:+1 to your design so far. Not a UI person but I definitely don't mind working on the internals of this. I can see this surpassing Amarok in the future.

Thanks so much yungtrizzle! I'll contact you directly as the development plans firm up. Also don't be afraid to offer visual design feedback, even if you're not a "UI person". The VDG is about ensuring that everyone feels free to provide constructive healthy feedback, regardless of skill or expertise.

anditosan wrote:I wanted to add to what Andrew made here. There was a conversation about visualizations and I wanted to see if implementing that would be easy. I tried making a separate button for it and also tried integrating the selections from its menu within the interface. I know these images are still, but the idea here is that when you click the visualizations button, the content on the center panel moves to the right and also uses animations to change visualizations and disappear.



Full Size http://i1108.photobucket.com/albums/h41 ... d89def.png

Great ideas anditosan, thanks! I'll look at integrating these suggestions into the design.

shantanu wrote:While you're looking for more developers, it'd be awesome if there could be some on help on Plasma Media Center where there are quite some developers crying for design help viewtopic.php?f=285&t=121705

shantanu, I forgot to say thanks for mentioning this. It prompted me to pop over there and offer to help out. The PMC folks have been most gracious.

andreas_k wrote:what is the background image? every time the same? how would it look like you use the album icon with a blur effect.

The current design for that background image is for a sort of album art blur filter. So yes that would change with the album art. Also anditosan's ideas for visualizations is also another way that background visual might change.

left to the shuffle and repeat mode I would implement a view icon to switch between different views. Album view, list view and so on.

Thanks great idea. That's along the lines of what I was thinking as well. I'm working on the artist, album and genre view designs this week these ideas are helpful.

donniezazen wrote:* Custom and smart playlists.
My whole music listening habit revolve around playlist. I use both custom playlists and smart playlists. I think iTunes/Banshee are a great example of players that revolve around playlists. Playlists are on left panel and single click on them would bring you the songs in those playlist in the songs window. Currently, I have to use Banshee because none of the Qt or KDE players including Amarok, Clementine or JuK have such a facility. Playlists aren't treated as first class citizens. They are clubbed together in a playlist tab that you have to constantly visit and then add/remove music from there. I think playlists should be on left side pane and music files should be as shown in the middle pane.

Thanks for taking the time to provide feedback donniezazen. I can't promise that the design will be exactly like you describe. But this feedback is certainly helpful. I can say that playlists will be treated with no less signification than other lists.

* Sort media on basis of metadata like album, genre, artist, stars, etc.
I currently use name, artist, album, genre, time, and playcount metadata to sort media. I am not sure if left panel is the best place to sort files. A one-line-thin-panel above the media list would be better use of space. So the left pane can be used for listing playlists.

Thanks for the suggestion. For the moment I'd like to continue exploring using that left panel list to preserve a single top-level navigation model. It'll require some patience and creativity, but I'd like to see how it holds up as the design evolves.

* Single click to launch media.
In Amarok, I have to right-click media files and click Add to Playlist. And I have to click Remove from Playlist to remove music files. I think this is unnecessary complexity. Left pane should just have a list of playlist and single click on them should bring music files to playlist. Clicking on other playlist would bring their files. There is no need to constantly add and remove music in playlists.

Hmm, I'll have to think on this one a bit to make sure I understand the full implications. I'll get back to you on this.

* Search bar.
Search bar is a must.

Oh there'll be search functionality. Yes, indeedy there will.

andreas_k wrote:The mockup could be nicer but for the understanding it will be hopefully ok.

I like where this is going. Search field should in my opinion be visible at all times. Now it has search tab and search button. Replacing both with visible search field would be more discoverable and straightforward. What are filters?

[quote=EraX]Personally not a fan of rhythmbox UI especially the split view also find It a waste of space [/quote]
You can hide the category listing by clicking that "view all" button.

daedaluz wrote:Search field should in my opinion be visible at all times. Now it has search tab and search button. Replacing both with visible search field would be more discoverable and straightforward. What are filters?

the search will open, when you click the search button. and the genre, album, artist selection like you know it from rythembox was also only shown when you use the search.

It is also no problem to use a search field, but than the results should be separated into different groups.
- current playlist
- music collection genre pop
- music collection genre rock
- youtub
...

otherwise you need a search for current playlist, collection, ....

Andreas_K
It should be stated that Amarok and this music players design goals are kinda different so we can't make both look the same. It might benefit to have you start a new thread on Amarok redesign since your designed is more aimed at that sort of music player.

I also think we should go for simplism. Really scale down different things and build from scratch design wise otherwise we run the risk of reimplementing the spaceship design. Lets ignore the "what would user x, y, z enjoy" and just design for ourselves and then move from there. Use as much white space as possible large images, wide fonts and a calm interface assuming that the user is intending to simply play music. Then for example there could be addons in which case we have a set framework and we can force those addons into the same calm, no-nonense and non-cluttered interface ideals.

jensreuterberg wrote:Andreas_K
Lets ignore the "what would user x, y, z enjoy" and just design for ourselves and then move from there. Use as much white space as possible large images, wide fonts and a calm interface assuming that the user is intending to simply play music.

I agree.

That being said. There are a million music players on Linux. For some weird reason folks likes to write music players from scratch and lose interest after some time. It goes back to categories of Amarok, Clementine, JuK, etc. which have huge lack of resources, lack of features and lots of bugs that go unconfirmed from one release cycle to another.

I think it would be worth spending some time on what do we expect of this new music player. Are there other music player that also has the same features? If yes how are we taking it a step further and more specifically who would be our target audience.

The goal of this new music player is 'simplicity' - the user interface looks non-confusing and is easy to understand even for newbies.
But: If simplicity is the target, would it not be more reasonable to make a unified player application for music and videos? If a user opens a video or a music file he gets the same interface and doesn't have to 'learn' a new application.

Even if Windows Media Player is ****, it's a good example for this.

If the user wants more and more specific software, he can use newly designed 'Muon Discover' to find a better application.


And: I like the idea of this background image/visualization, which uses the cover if no visualization is active - but what happens if there's no cover. I have a lot of music which don't have any cover.

Idea:
Note: Imagine: Replace 'cover image' by video thumbnail or running video (blurred) if in playlist mode;



Note: Please upload the *.svg as well. It's hard to create new mockups from existing mockups

rumangerst wrote:The goal of this new music player is 'simplicity' - the user interface looks non-confusing and is easy to understand even for newbies.
But: If simplicity is the target, would it not be more reasonable to make a unified player application for music and videos?

I think "light"* apps that are designed for a specific task make more sense than throwing everything into one place.
That way you can focus the design on that task without any compromises. Never liked MS approach in that area.
But that is just my personal opinion...

*Doesn't mean stripped out of features

EraX wrote:

rumangerst wrote:The goal of this new music player is 'simplicity' - the user interface looks non-confusing and is easy to understand even for newbies.
But: If simplicity is the target, would it not be more reasonable to make a unified player application for music and videos?

I think "light"* apps that are designed for a specific task make more sense than throwing everything into one place.
That way you can focus the design on that task without any compromises. Never liked MS approach in that area.
But that is just my personal opinion...

*Doesn't mean stripped out of features

I agree with you, but in my opinion there are too many similarities between a normal (no TV, ...) video player and a music player. What would a lightweight video player would look like? If the resulting app is too similar, it would be possible to merge them together.

rumangerst wrote:I agree with you, but in my opinion there are too many similarities between a normal (no TV, ...) video player and a music player. What would a lightweight video player would look like? If the resulting app is too similar, it would be possible to merge them together.

I'd say let's design both the music and video player and if we find that the designs end up being so similar that they can be merged into one application without any loss in GUI simplicity, we can still do it.
Bangarang has shown that it's easy to create a player for both music and videos with KDE technology, but I wouldn't start from that assumption. Consistency is important, but two different UIs that suit their respective tasks best are still better than one which suits two tasks only "okay".

Definitely agree with colomar, if a simple GUI can support both video and music, go for it but don't force two GUIs into a complex mess.

A couple updates based in part on the feedback I've received so far.

I started working on a design for search.


I also started working on the artist view design.


In case anyone is wondering, yes more design ideas are in the queue for the currently playing track area at the top. I haven't yet incorporated anditosan's idea for selecting visualizations, but that idea will certainly end up there in some form. If you have ideas for that area, please feel free to share. I likely won't clutter it up with gobs of stuff, but I'm certainly open to ideas.

Some of the major design work remaining: saving and editing playlists, adding online radio stations (audio streams), music library settings and more.

On the development side, we have an additional developer who has offered to help.

Thanks for your help and great feedback so far!