Hi my name is Matthieu Gallien.

I'm working on a music player started to fill my personal desire for a good music player usable in an UPnP environment. I want to use it both to get music from UPnP content servers but also to be able to play music on a UPnP MediaRenderer.

I have started the design from the mockups from Andrew Lake.
I need a designer to help me with the design of the albums or artists views especially related to interaction with mouse or touchscreen. I have also started a wiki page about Elisa (https://community.kde.org/Elisa) with some screenshots and a few pain points that would highly benefit from some design help.

I would also like to define a few persona to better formalize the target people for my application. If somebody can help, this would be highly appreciated.

If you got any ideas post them here or contact me at gallien.matthieu gmail.com .

Best regards

Cool stuff mgallien! My goodness that looks great.

Holler with the specific pain points you'd like to tackle, and I'll carve out some time to help.

Some predefined personas are here which might be helpful to give you a head start:
https://community.kde.org/KDE_Visual_De ... 4_Personas

Also some persona related information is here: https://community.kde.org/KDE_Visual_De ... sic_Player

Hello Andrew,

Thanks for your reply.

As I already said, I started my project to have a player able to handle UPnP in a pleasant way (both to get music and to remotely play it).

I have been an heavy and happy user of Amarok back when Amarok was in major version 1.
I also have been an happy user of Bangarang when Nepomuk was working.

I have started interviewing people around me to better know their habits when playing music with computers or smart phones. As far as I could tell I am not alone to have this need. People are using it even not geeks people (Sonos, Chromecast, mpd, ...).

I will have a go to persona building especially from the existing work you have pointed.

Thanks in advance for your help.

Best regards

Hello,
Dear members of the Visual Design Group, I am still looking for help with regard to design of the user interface of Elisa.

I am very open to collaboration. I did decide to differ from the design started by Andrew Lake but everything is open for change at this point.

I hope somebody is interested to help. This is a chance to have a music player being built inside KDE community that could be simple to use.

I really want to build a music player that integrates well with plasma desktop while being open to other environments. This is the main reason for usage of Baloo, other frameworks and interfaces like MPRIS2. This makes it possible to use it without having to configure it before being able to play music.

Best regards

mgallien,

I'm still available to help with the visual design. Feel free to post your specific requests for help here and I'll offer my support for each of those requests. You mentioned in your OP that you need help with the design for Album or Artist views and I took a look at the designs on that community wiki page. As I mentioned before cool stuff.

Would you like just some general design ideas for the interface, design adjustments to the existing interface design, new icons for artists/albums, some UI layout ideas? I'm super excited to support. Just tell me where you'd like to focus first.

(BTW: I'm definitely not wedded to my original design, so I'm happy to go in a direction that fits with your ideas)

Hello Andrew, thanks again for your help offer.

Right now, I am thinking about 2/3 problems where I would like to identify a good solution:

* If somebody puts music in its play list and restart the application, the playlist is restored. Before tracks are found, they are in "invalid" state. I am not sure how to show this state visually. I am also not sure how to let the user interact with the playlist while music indexing is running and state might not be fully restored (think of the time needed to get tracks from an UPnP server).

* I thought that a user with a lot of music could appreciate a way to zoom the grid views with all artists or albums. Do you have suggestions around this topic ?

* Do you have good book suggestions around user based design ?

Best regards

mgallien wrote:Hello Andrew, thanks again for your help offer.

Right now, I am thinking about 2/3 problems where I would like to identify a good solution:

* If somebody puts music in its play list and restart the application, the playlist is restored. Before tracks are found, they are in "invalid" state. I am not sure how to show this state visually. I am also not sure how to let the user interact with the playlist while music indexing is running and state might not be fully restored (think of the time needed to get tracks from an UPnP server).

My suggestion is to focus on the user action that is prohibited when the playlist tracks aren't found yet. If the displayed information about the tracks are cached locally, then it would seem like the only action the user is prevented from is playing the first track in the playlist (or playing a selected track from the playlist). So I'd disable the play button with a tooltip indicating that the app is searching for the selected track. I would also prioritize restoration of the tracks in the playlist when the app starts up. Then re-enable the play button when the first track in the playlist is no longer "invalid" (or when the selected track in in the playlist is no longer "invalid"). I wouldn't worry about rendering the tracks differently for the invalid state.

* I thought that a user with a lot of music could appreciate a way to zoom the grid views with all artists or albums. Do you have suggestions around this topic ?

Zooming is a cool effect and interaction mechanic. What user-specific need can you think of that would potentially be satisfied by zooming? I can think of zooming for accessibility purposes or for browsing purposes where an album may switch over to a list of tracks on that album past a certain zoom level. The latter could be neat, but at least for the context switching, I think it'd need to be executed extremely well to make an argument that it is easier for the user than simply clicking on the album.

I've seen zooming work well for picture browsing, so it could be useful for album browsing with the album art as a picture. I'd skip any context switches at a specific zoom level though. Separately, I think zooming for accessibility purposes is usually a band-aid for poor accessibility design.

* Do you have good book suggestions around user based design ?

Best regards

@colomar might have some suggestions.

Hope this helps!

alake wrote:

mgallien wrote:Hello Andrew, thanks again for your help offer.

Right now, I am thinking about 2/3 problems where I would like to identify a good solution:

* If somebody puts music in its play list and restart the application, the playlist is restored. Before tracks are found, they are in "invalid" state. I am not sure how to show this state visually. I am also not sure how to let the user interact with the playlist while music indexing is running and state might not be fully restored (think of the time needed to get tracks from an UPnP server).

My suggestion is to focus on the user action that is prohibited when the playlist tracks aren't found yet. If the displayed information about the tracks are cached locally, then it would seem like the only action the user is prevented from is playing the first track in the playlist (or playing a selected track from the playlist). So I'd disable the play button with a tooltip indicating that the app is searching for the selected track. I would also prioritize restoration of the tracks in the playlist when the app starts up. Then re-enable the play button when the first track in the playlist is no longer "invalid" (or when the selected track in in the playlist is no longer "invalid"). I wouldn't worry about rendering the tracks differently for the invalid state.

Yes, sure. I have a bit of work to do to be able to effectively restore state as quick as possible but this is the goal.

Still, I am not sure how to unequivocal convey the idea that the track is invalid and that the user may remove it.

* I thought that a user with a lot of music could appreciate a way to zoom the grid views with all artists or albums. Do you have suggestions around this topic ?

Zooming is a cool effect and interaction mechanic. What user-specific need can you think of that would potentially be satisfied by zooming? I can think of zooming for accessibility purposes or for browsing purposes where an album may switch over to a list of tracks on that album past a certain zoom level. The latter could be neat, but at least for the context switching, I think it'd need to be executed extremely well to make an argument that it is easier for the user than simply clicking on the album.

I've seen zooming work well for picture browsing, so it could be useful for album browsing with the album art as a picture. I'd skip any context switches at a specific zoom level though. Separately, I think zooming for accessibility purposes is usually a band-aid for poor accessibility design.

I was specifically thinking that the size of album covers could be adjusted such that the user may display a lot of them or only a few but with more details (full title instead of elided title, ...)

* Do you have good book suggestions around user based design ?

Best regards

@colomar might have some suggestions.

Hope this helps!

I will try to ask him by IRC.

Thanks for your help.

Little status update.

I have almost finished making the music database persistent across runs of the application. This allows the application to restore a "working" state quite quickly.
I still have to compute the possibly new missing tracks after a restart and remove them.

I would like to be able to get incremental changes from Baloo before release. Not sure this will be possible.

Could somebody look at ideas for an icon that is not the generic one I am using ? This would be very nice.

Best regards

I have a specific question related to the original design from alake.
At the top of the application, a colored background is shown.
As far as I have understand, the idea was to use the current cover with a blur effect or something like that. Is it correct ?

I would like to improve the visual identity of Elisa by working a little bit on this. Do you have suggestions ?

Thanks in advance

Best regards

mgallien wrote:I have a specific question related to the original design from alake.
At the top of the application, a colored background is shown.
As far as I have understand, the idea was to use the current cover with a blur effect or something like that. Is it correct ?

Yes that's correct.

I would like to improve the visual identity of Elisa by working a little bit on this. Do you have suggestions ?

I like the effect because it is simple - the album art is already available and the blur is a pretty straightforward effect to implement - and it an effective way to create a visual mood corresponding to the current track. There was also a proposal that it could also serve as a canvas for some kind of music visualization plugin. Whatever the visual, I suggest dimming that background image a bit so that the album art overlay and text can more easily be read. Album art is also one of the central visual components of the music experience I think, so don't be shy about showing a bigger thumbnail in this area.

I'd also suggest some variation is the font size and/or weight and/or color used for the current song title, album and artist in this area. I think it would create a little more dynamic balance in that area. For example the current song title could be displayed a larger font size, while the album and artist could be the same, but smaller size.

Hope this helps,
Andrew

Hello,

I tried working in the direction of your suggestions.
Please find a screenshot below.

https://community.kde.org/images.commun ... 225733.png

What do you think about it ?
In order to have a better contrast for the text when the background has the same color I have added a glow effect. I have mixed feeling about it but at least it makes the test readable.

I have another question about design.

I have been showing passive notification in the application when something is added to the playlist. I have reused the notification from Kirigami. Do you have any suggestions ?

Best regards and thanks for your help

mgallien wrote:Hello,

I tried working in the direction of your suggestions.
Please find a screenshot below.

https://community.kde.org/images.commun ... 225733.png

What do you think about it ?

Great progress mgallien! I like it!

In order to have a better contrast for the text when the background has the same color I have added a glow effect. I have mixed feeling about it but at least it makes the test readable.

It's a great place to start. Another simple way to get more contrast is to put a low opacity/alpha black rectangle over the entire background. Then you can adjust the opacity/alpha of the rectangle until it is just dark enough to provide sufficient contrast with the text but transparent enough to let the blurred artwork show through setting the visual mood.

I have been showing passive notification in the application when something is added to the playlist. I have reused the notification from Kirigami. Do you have any suggestions ?

I could see the value in such a notification if the playlist wasn't always visible, but in your design the playlist is always visible. So my instinct says keep the visual noise low and skip the notification altogether. It should be relatively easy for the user to glance at the playlist and confirm that the track was added.

One thing that might also help is providing a single consistent visual design for a track throughout the entire interface. i.e. make sure a track in the browsing area looks exactly like a track in the playlist. That way it is even easier for the user to recognize the same track wherever it shows up (like when it is added to the playlist).

Best regards and thanks for your help

Sorry for the delay in responding. Happy to help. Holler if there is anything else I can help with!

Hello,

I am now showing ratings with 5 stars. I think that it would help reach the user's goal to be able to filter the views by the rating. This way, one could access highly rated tracks very easily.

I am thinking of adding 5 stars at right of filter text input. It would filter all the tracks that have strictly less stars than what is selected.

Do you have any suggestions about this ?

By the way, I am reading the book "The inmates are running the asylum" following recommendation by Thomas Pfeiffer.

I will never say enough thank you for your design work. This has really provided a lot of help in implementing Elisa. Your work is of very high quality.

Best regards

mgallien wrote:Hello,

I am now showing ratings with 5 stars. I think that it would help reach the user's goal to be able to filter the views by the rating. This way, one could access highly rated tracks very easily.

I am thinking of adding 5 stars at right of filter text input. It would filter all the tracks that have strictly less stars than what is selected.

Do you have any suggestions about this ?

Great idea. Go ahead and take a stab at what you suggest and post a screenshot. We can iterate on the design as necessary from there.