Oh I forgot to post this. After a short discussion with Heiko last week, I committed to providing a set of high level requirements for the music player that both the design and the implementation will aim to satisfy. A few notes:

• These requirements are considered, for the moment, to be sufficiently valid. While there is certainly a chance for error in that consideration, we're electing for now to accept the potential for a validation error as an acknowledged risk. Given the many successful implementations of several music players across multiple platforms, a benchmark of those implementations suggests that the risk that any of these requirements are invalid should be relatively low.
• I certainly welcome any additional validation, by user survey or another method, of any of these requirements.
• The order of the requirements is not an indication of importance or priority - they're all requirements

The music player shall:

1. Allow the user to quickly play all music on an album, by an artist, in a genre, or just in general. Music refers to locally stored music.
2. Allow the user to quickly play their favorite music by an artist, on an album, in a genre, or just in general. The user's favorite music are the songs that they rate highly or they frequently play.
3. Allow the user to quickly play recently played music by an artist, on an album, in a genre, or just in general.
4. Allow the user to quickly search for music to play.
5. Allow the user to easily create and play custom playlists.
6. Allow the user to easily add and listen to online radio.
7. Allow listeners to quickly determine what song is playing, the time left in the current song, what band is playing and the upcoming track.
8. Allow the user to skip directly to an upcoming song, replay a previously played song, and quickly pause playback.
9. Allow the user to control the music playback volume and quickly mute playback.
10. Allow the user to quickly retrieve or add additional information about a song, an album or an artist while browsing the music library. Additional information includes missing song metadata, artist bio or discography, album descriptions and artwork.

alake wrote:... a set of high level requirements for the music player...

Thanks a lot. I think that helps to understand and classify the application. From the usability POV it makes sense to talk about a specific persona instead of a user. I guess you haven Susan in mind. Consequently, the UI has to focus on ease of use and not functionality (soft criteria are as much important as functional requirements).
We talked about video playback, perhaps it should be added to the features concerning the party mode. And it makes sense to confine the requirements by those stuff that is not planned. An example: I want to hear music that I did not recently listen to. And that's not part of the primary features (Susan don't want it).
About user survey: I'd say we look if there is common agreement on your list. There is no need to challenge basic assumptions if all agree on for instance a playlist based workflow. But in case of unclear functionalities we start the survey.

alake wrote:The music player shall:

• Allow the user to easily create and play custom playlists.

Is there no interest in smart playlist at the moment?

Maybe it would help clearify what this music player is aiming for by listing points what/why this music player is different to the existing music players?
- Amarok
- JuK
- Bangerang
- dragonplayer
- vlc
- Kaffeine
...
?

Let's not worry about what other music players this might replace, or how it's different from other players at the moment. For now let's just focus on the design and how it will help to satisfy the requirements.

Heiko, thanks very much for reviewing the requirements. Great feedback. One note regarding what you describe as a playlist based workflow; please note that playlists are mentioned in only one requirement. How the music data is stored or accessed (via metadata database or file system) is a implementation choice that, if we were developing in a vacuum, would emerge at a lower level than these high-level requirements. It is the difference between what the system is required to do versus how the system does it. It is a helpful distinction to prevent premature identification of an implementation before fully understanding the requirements. The requirement (#5) mentions custom playlists - which means the ability for the user to create and play an arbitrary collection of songs of their choosing (beyond just the collection of songs on an album). I'll update the requirements to avoid any misunderstanding (see below). Other requirements cover allowing the user to find and play the collection of songs on an album. How it's done underneath (via metadata database or with the file system) is less important at this stage. If anyone elects to run a survey in order to provide additional validation of these requirements beyond what we already have via other methods, the focus of any such survey should be on the what instead of the how.

So the updated requirements are as follows:
The music player shall:

1. Allow the user to quickly play all music on an album, by an artist, in a genre, or just in general. Music refers to locally stored music.
2. Allow the user to quickly play their favorite music by an artist, on an album, in a genre, or just in general. The user's favorite music are the songs that they rate highly or they frequently play.
3. Allow the user to quickly play recently played music by an artist, on an album, in a genre, or just in general.
4. Allow the user to quickly search for music to play.
5. Allow the user to easily create and play an arbitrary collection of songs of their choosing (playlists).
6. Allow the user to easily add and listen to online radio.
7. Allow listeners to quickly determine what song is playing, the time left in the current song, what band is playing and the upcoming track.
8. Allow the user to skip directly to an upcoming song, replay a previously played song, and quickly pause playback.
9. Allow the user to control the music playback volume and quickly mute playback.
10. Allow the user to quickly retrieve or add additional information about a song, an album or an artist while browsing the music library. Additional information includes missing song metadata, artist bio or discography, album descriptions and artwork.

@donniezazen for the moment, yes smart playlists are out-of-scope.

Hope this helps!

Okie-dokie, back to design work...

I would suggest adding the following to the requirement;

• Have the option to quickly change between looping the playlist, looping a single song, playing from the playlist randomly, and stopping after each track.*

*Usually seen as a single button which cycles.

Here are some features I think might be useful:

Abiltiy to play music from the file manager

Ablity to play music without a playlist (or have the playlist cleared when a file is opened).

I know that the suggested feature is a bit more special. Nevertheless we live today in a world where a media player should also enable us to stream music (or other media) to DLNA/Airplay/Chromecast device. So far this is rarely supported in Linux applications and I must say that Microsoft made a really good job with its integration in the Windows Media Player (http://gizmodo.com/5146859/windows-7-wi ... patibility). Another example is Songbird providing a very nice UI for remote playlists and remote media-device controls: http://de.tinypic.com/view.php?pic=29kumf9&s=8

I'd like to see this functionality included into the default "Made for KDE/Plasma" default applications because I believe this belongs to a modern desktop environment. I guess it doesn't make sense to implement this as a hard requirement into the applications but rather than a playlist and control widgets being called for instance from THIS media player, or the movie player or the gallery application.

I'll also post to the "secret plan" thread, because I feel this discussion isn't limited only to the media player!

kraschute wrote:I know that the suggested feature is a bit more special. Nevertheless we live today in a world where a media player should also enable us to stream music (or other media) to DLNA/Airplay/Chromecast device. So far this is rarely supported in Linux applications and I must say that Microsoft made a really good job with its integration in the Windows Media Player (http://gizmodo.com/5146859/windows-7-wi ... patibility). Another example is Songbird providing a very nice UI for remote playlists and remote media-device controls: http://de.tinypic.com/view.php?pic=29kumf9&s=8

I'd like to see this functionality included into the default "Made for KDE/Plasma" default applications because I believe this belongs to a modern desktop environment. I guess it doesn't make sense to implement this as a hard requirement into the applications but rather than a playlist and control widgets being called for instance from THIS media player, or the movie player or the gallery application.

I'll also post to the "secret plan" thread, because I feel this discussion isn't limited only to the media player!

While it's a great idea in it's own right, you have to consider developer resources. Any developer will tell you that it's a nightmare to develop for devices not available on hand. Also while DLNA/Airplay/Chromecast devices all have similar user experiences their APIs do not converge which means supporting at least 2-3 extra APIs that can break beyond our control.

kraschute wrote:I know that the suggested feature is a bit more special. Nevertheless we live today in a world where a media player should also enable us to stream music (or other media) to DLNA/Airplay/Chromecast device. So far this is rarely supported in Linux applications and I must say that Microsoft made a really good job with its integration in the Windows Media Player (http://gizmodo.com/5146859/windows-7-wi ... patibility). Another example is Songbird providing a very nice UI for remote playlists and remote media-device controls: http://de.tinypic.com/view.php?pic=29kumf9&s=8

I'd like to see this functionality included into the default "Made for KDE/Plasma" default applications because I believe this belongs to a modern desktop environment. I guess it doesn't make sense to implement this as a hard requirement into the applications but rather than a playlist and control widgets being called for instance from THIS media player, or the movie player or the gallery application.

I'll also post to the "secret plan" thread, because I feel this discussion isn't limited only to the media player!

Yeah, Ideally this functionality would available at a lower layer and exposed to apps via a similar output-this media-stream-to-this-reciever API. That way support for the different target devices can be added with minimal specialized application code. At the music palyer level it could be exposed as a simple chromecast-style button for all target media devices.

alake wrote:

kraschute wrote:I know that the suggested feature is a bit more special. Nevertheless we live today in a world where a media player should also enable us to stream music (or other media) to DLNA/Airplay/Chromecast device. So far this is rarely supported in Linux applications and I must say that Microsoft made a really good job with its integration in the Windows Media Player (http://gizmodo.com/5146859/windows-7-wi ... patibility). Another example is Songbird providing a very nice UI for remote playlists and remote media-device controls: http://de.tinypic.com/view.php?pic=29kumf9&s=8

I'd like to see this functionality included into the default "Made for KDE/Plasma" default applications because I believe this belongs to a modern desktop environment. I guess it doesn't make sense to implement this as a hard requirement into the applications but rather than a playlist and control widgets being called for instance from THIS media player, or the movie player or the gallery application.

I'll also post to the "secret plan" thread, because I feel this discussion isn't limited only to the media player!

Yeah, Ideally this functionality would available at a lower layer and exposed to apps via a similar output-this media-stream-to-this-reciever API. That way support for the different target devices can be added with minimal specialized application code. At the music palyer level it could be exposed as a simple chromecast-style button for all target media devices.

From a UI perspective, this is a clear case for Share/Like/Connect (the page is about Plasma Active, but it will be available in Plasma Desktop as well in a future version, because that's the framework for sharing features that work across applications. We really should not do it any other way than with SLC.

colomar wrote:

alake wrote:Ideally this functionality would available at a lower layer and exposed to apps via a similar output-this media-stream-to-this-reciever API. That way support for the different target devices can be added with minimal specialized application code. At the music palyer level it could be exposed as a simple chromecast-style button for all target media devices.

From a UI perspective, this is a clear case for Share/Like/Connect (the page is about Plasma Active, but it will be available in Plasma Desktop as well in a future version, because that's the framework for sharing features that work across applications. We really should not do it any other way than with SLC.

Makes sense to me.

I would love to see the playlist category in the left pane expand and collapse to show playlists. It would provide, by my lights, the easiest and most intuitive way to edit and create playlists.

Just wanted to post some Tomahawk-related news. Maybe it could be used for inspiration, or comparisons:
https://medium.com/@jordiverduorts/toma ... d444e45f18

ivan wrote:Just wanted to post some Tomahawk-related news. Maybe it could be used for inspiration, or comparisons:
https://medium.com/@jordiverduorts/toma ... d444e45f18

Awesome, thanks Ivan!