Elisa UI Redesign
Open, Needs TriagePublic

Description

Hi, I was inspired by @manueljlin mockups, and i decided try to make UI redesign for Elisa, it looks very different from current Elisa UI, but it could be as part of Plasma 6 with new Breeze style.

  • I tried to simplify interface.
  • Categories bar now like in Dolphin and have new highlight effect T11124
  • Timeline has moved to down.

1x:

4x:

If you want to improve mockup, here a SVG.

For comparison, screenshot of current Elisa:

There are a very large number of changes, so older changes are hidden. Show Older Changes
ghost34 updated the task description. (Show Details)Dec 15 2019, 7:39 PM
ghost34 updated the task description. (Show Details)Dec 15 2019, 7:56 PM

That's actually not what Elisa looks like now; you must be using an old version. This is what it looks like now:

A lot closer to your mockup in many ways, in fact. :) Do you still think it needs a redesign? ;)

This comment was removed by ghost34.

I made some changes, the most replacement thing is that i relocate a timeline to bottom.

ghost34 updated the task description. (Show Details)Dec 16 2019, 4:22 PM
ndavis added a subscriber: ndavis.Dec 16 2019, 4:50 PM

Based on this screenshot, I don't think Elisa needs a complete redesign. It mainly needs the following:

  • More colorscheme compatibility, unless that has already been fixed
  • We need to decide if some of the styling for its UI elements should be changed to match the Breeze widget style or if our widget style should be changed to match Elisa
  • Pixel perfect icons (maybe colorful icons, but monochrome looks so nice here), but this is mainly a breeze-icons problem, unless Elisa is using 24px icons.

Based on this screenshot, I don't think Elisa needs a complete redesign. It mainly needs the following:

  • More colorscheme compatibility, unless that has already been fixed
  • We need to decide if some of the styling for its UI elements should be changed to match the Breeze widget style or if our widget style should be changed to match Elisa
  • Pixel perfect icons (maybe colorful icons, but monochrome looks so nice here), but this is mainly a breeze-icons problem, unless Elisa is using 24px icons.

I think it's better to overhaul Elisa, it's a very uncomfortable music player IMHO, too many buttons, timeline on top (I like timeline on bottom like in Spotify).
I'll try to make good mockups, wait a little bit.

In T12372#214006, @KonqiDragon wrote:

I made some changes, the most replacement thing is that i relocate a timeline to bottom.

This could easily be done by the user if the layout is made modifiable by the user. That would make it an actionable task. Do you want to help on that ?

Based on this screenshot, I don't think Elisa needs a complete redesign. It mainly needs the following:

  • More colorscheme compatibility, unless that has already been fixed
  • We need to decide if some of the styling for its UI elements should be changed to match the Breeze widget style or if our widget style should be changed to match Elisa
  • Pixel perfect icons (maybe colorful icons, but monochrome looks so nice here), but this is mainly a breeze-icons problem, unless Elisa is using 24px icons.

I agree with all those goals.

I used to regularly test with Breeze dark color scheme but somehow forgot to do it for the current stable version. Please, if you can test and open bug reports, that would be really nice.

I believe that @ngraham already did a few changes to make Elisa more consistent with other KDE applications. I am all for that as long as we do not remove features. This is exactly what happened during the 19.12 development cycle. Thanks for the help here !

On the third point, I definitely need help on that. Why is 24 pixels a problem ?
I sometime have the impression that some icons are blurry. Maybe we could identify the problems and fix Elisa to use the correct icon size ?

In T12372#214006, @KonqiDragon wrote:

I made some changes, the most replacement thing is that i relocate a timeline to bottom.

Thanks for the mockup.
Please, do not remove features when doing them. As is, I would say that this mockup is not actionable because I see no way to configure the application for example. That would be a problem for the users with non standard paths.

mgallien added a comment.EditedDec 16 2019, 8:37 PM

Based on this screenshot, I don't think Elisa needs a complete redesign. It mainly needs the following:

  • More colorscheme compatibility, unless that has already been fixed
  • We need to decide if some of the styling for its UI elements should be changed to match the Breeze widget style or if our widget style should be changed to match Elisa
  • Pixel perfect icons (maybe colorful icons, but monochrome looks so nice here), but this is mainly a breeze-icons problem, unless Elisa is using 24px icons.

I agree with all those goals.

I used to regularly test with Breeze dark color scheme but somehow forgot to do it for the current stable version. Please, if you can test and open bug reports, that would be really nice.

As far as I can say, the master branch works fine with Breeze Dark. One can even switch dynamically and everything works fine. Thanks a lot for the work going on to allow proper usage of qml to develop KDE applications. Everything is perfect currently !!!

Here a Artists category mockups, prompt me what to add about selected artist in addition to Name and Genre? Also than fill the empty space upstairs (where the search place)?

I think there are probably a few actionable tasks here, as well as some design matters we could discuss. For example:

  • We can tweak the Breeze icons used in the sidebar not to be blurry. Alternatively, we could decrease the size of the icon used in Elisa so it's using a size where we always have pixel-perfect versions for all icons. This should be a pretty simply fix.
  • To simplify the UI when the user first opens the app, we could have the Playlist hidden, and make it more accessible by adding a button (with text) on the main toolbar to open it. Then the default view would have two paned rather than three. Maybe, undecided on this. Just a thought.
  • We could make the top bar with the colored blur a bit shorter, or even make the fairly blingy colorful blur background only appear in the expanded view (the mode you enter when you click the arrow button on the left side, I don't know what it's called).
  • We definitely need a more attractive Artist view, for sure. I think the main challenge here is how to get artwork for those large grid items. Lollypop fetches artwork from the internet, but of course this is associated with some technical challenges.
  • @ndavis I think we should make Breeze look more like Elisa does not, rather than the inverse--in particular, with regards to how elements are separated by single-pixel lines rather than putting each view in a frame. The Elisa style is basically the Kirigami style and it's probably the future for KDE software in general, and it's the general style that we've more or less agreed on in our mockups from T10891 and T11663:

ndavis added a comment.EditedDec 17 2019, 12:56 AM

I used to regularly test with Breeze dark color scheme but somehow forgot to do it for the current stable version. Please, if you can test and open bug reports, that would be really nice.

Here's an example. It's probably the only example.


The outlines are very dark, which looks unnatural for Breeze Dark.
Sliders normally look like this:

On the third point, I definitely need help on that. Why is 24 pixels a problem ?
I sometime have the impression that some icons are blurry. Maybe we could identify the problems and fix Elisa to use the correct icon size ?

A few icons are actually blurry (that's a breeze-icons problem) and not all monochrome icons in breeze-icons are available at 24px, but most KDE applications use 22px instead of 24px. I'm guessing this is because 22px is slightly closer to 2x the area of 16px than 24px, but I don't actually know.

Our 24px icons are really just 22px icons with an extra pixel of margin on each side. It might be possible to automatically generate 24px icons from 22px icons at build time.

I'm a big proponent of auto-generating 24px icons, and well as all the breeze dark assets.

I used to regularly test with Breeze dark color scheme but somehow forgot to do it for the current stable version. Please, if you can test and open bug reports, that would be really nice.

Here's an example. It's probably the only example.


The outlines are very dark, which looks unnatural for Breeze Dark.
Sliders normally look like this:

On the third point, I definitely need help on that. Why is 24 pixels a problem ?
I sometime have the impression that some icons are blurry. Maybe we could identify the problems and fix Elisa to use the correct icon size ?

A few icons are actually blurry (that's a breeze-icons problem) and not all monochrome icons in breeze-icons are available at 24px, but most KDE applications use 22px instead of 24px. I'm guessing this is because 22px is slightly closer to 2x the area of 16px than 24px, but I don't actually know.

Our 24px icons are really just 22px icons with an extra pixel of margin on each side. It might be possible to automatically generate 24px icons from 22px icons at build time.

I will work on a merge request to address the look of sliders. I will see if I can preserve the custom look while fixing your issue.

Regarding the icons, I still do not understand what is the best solution. We can always change the icon sizes in Elisa. I am not sure the current size has been chosen while taking care of pixel perfect look. That would definitely be nice to improve that.

ghost34 added a comment.EditedDec 19 2019, 1:28 AM

Ugh, I did it, this time there's mockups of Timeline, say what you like of this variants!

ghost34 updated the task description. (Show Details)Dec 20 2019, 5:52 AM
ghost34 updated the task description. (Show Details)Dec 20 2019, 5:58 AM
ghost34 updated the task description. (Show Details)
ghost34 updated the task description. (Show Details)
ghost34 updated the task description. (Show Details)Dec 20 2019, 6:04 AM
ghost34 updated the task description. (Show Details)Dec 20 2019, 6:07 AM

The only thing I would change to the mockup is the top toolbar, it looks a bit empty. Maybe you could do it like Kaku (electron based youtube player that happens to have a similar naming scheme to KDE apps), where the settings and search buttons are on the sidebar.

+1, with those mockups there's almost nothing on the top toolbar. To be honest I don't really think we need to move the player controls to the bottom. I don't see that it solves any problem and it created a problem of the top toolbar being almost empty. I would keep the playback controls on top like they already are; we can maybe reduce the space it takes up, but I don't think it needs to be moved to another part of the window

Here's a dark version.

+1, with those mockups there's almost nothing on the top toolbar. To be honest I don't really think we need to move the player controls to the bottom. I don't see that it solves any problem and it created a problem of the top toolbar being almost empty. I would keep the playback controls on top like they already are; we can maybe reduce the space it takes up, but I don't think it needs to be moved to another part of the window

Sorry, i don't know how improve toolbar. But, you can improve it! I attach a SVG file of this mockup in description.
I VERY don't like that in current Elisa a playback controls is on top, becouse i use Spotify and on other my favorite music players playback controls is on bottom, so I decided to move the playback control to bottom.

ghost34 updated the task description. (Show Details)Dec 20 2019, 7:53 PM
In T12372#214423, @KonqiDragon wrote:

Sorry, i don't know how improve toolbar. But, you can improve it! I attach a SVG file of this mockup in description.
I VERY don't like that in current Elisa a playback controls is on top, becouse i use Spotify and on other my favorite music players playback controls is on bottom, so I decided to move the playback control to bottom.

"I personally don't like it" is not a good reason to change something. Having the playback controls on top is natural since it puts them into the app's toolbar area, where most apps have their global tools and actions.

In T12372#214006, @KonqiDragon wrote:

This could easily be done by the user if the layout is made modifiable by the user. That would make it an actionable task. Do you want to help on that ?

Maybe if more people want to set the toolbar to be on the bottom, this would be a viable option

ghost34 added a comment.EditedDec 20 2019, 8:54 PM
In T12372#214423, @KonqiDragon wrote:

Sorry, i don't know how improve toolbar. But, you can improve it! I attach a SVG file of this mockup in description.
I VERY don't like that in current Elisa a playback controls is on top, becouse i use Spotify and on other my favorite music players playback controls is on bottom, so I decided to move the playback control to bottom.

"I personally don't like it" is not a good reason to change something. Having the playback controls on top is natural since it puts them into the app's toolbar area, where most apps have their global tools and actions.

I moved playback controls to top, now toolbar not looks too empty and now it's more similar to a current Elisa :)

Thanks, much nicer. :)

We can always not having anything on top.

We can always not having anything on top.

I like it, I still want to save playback controls on bottom in "Elisa 6" mockup, but other peoples don't like it :(

I still think a redesign is completely unnecessary.

It's not that the mockup is bad, it's that the current design isn't bad either. If the current design needs to be improved, it can be improved without throwing it away.

We can always not having anything on top.

A few thoughts about the mockup:

  • Search button placement is not good. It's visually disconnected from the part of the UI it affects (Dolphin has the same problem)
    • Elisa currently puts it in a very good spot
  • Main control bar is too wide and tall.
  • Elisa seems to built around playlists, so adding a way to quickly access them to the sidebar is a good idea that can be adapted into the current design.
  • Is the heart Last.fm integration? Isn't that out of fashion now?
  • The repeat and shuffle buttons look like they're on opposite sides for visual balance, but it's better for usability to put them next to each other. They're strongly related to each other and are placed next to each other in every other music player.

We can always not having anything on top.

A few thoughts about the mockup:

  • Search button placement is not good. It's visually disconnected from the part of the UI it affects (Dolphin has the same problem)
    • Elisa currently puts it in a very good spot
  • Main control bar is too wide and tall.
  • Elisa seems to built around playlists, so adding a way to quickly access them to the sidebar is a good idea that can be adapted into the current design.
  • Is the heart Last.fm integration? Isn't that out of fashion now?
  • The repeat and shuffle buttons look like they're on opposite sides for visual balance, but it's better for usability to put them next to each other. They're strongly related to each other and are placed next to each other in every other music player.

It possible to adapt current Elisa to the new Breeze theme evolution (T10891) standarts? There's a lot things that require to be completely UI update in Breeze theme evolution.

hmm, the svg seems to be just a png inserted with a bg

hmm, the svg seems to be just a png inserted with a bg

Hm, i’ll check now, in what program did you check it?

Inkscape and figma

Inkscape and figma

I creating this mockup in Gravit Designer, maybe it have a exporting bug, now i checked this SVG file that I attract in description, i checked in Inkscape and Gravit Designer, it really a export bug, becouse i use too many groups (to not get confused) and all objects divided to 2 groups Light and Dark, and when i exporting it, these 2 groups become to just 2 objects, but the fact that inside the groups becomes as a single object.
I fixed it! I just ungrouped all groups in my project :)

Here is a fixed SVG:

ghost34 updated the task description. (Show Details)Dec 21 2019, 12:10 PM
manueljlin added a comment.EditedDec 21 2019, 12:17 PM

Thanks! This one works perfectly

edit: mostly


edit2: works now

Maybe something closer to the current design like this: (ignore the different progress bar and volume slider)

Maybe something closer to the current design like this: (ignore the different progress bar and volume slider)

Looks kool! Do you will to change "Artist" category or it's looks ok?

The artist category looks good but maybe make a bit thinner the banner:

(85px tall)

also, have the svg from the previous one

One thing I agree with is making the search global rather than per-view. I've been mildly irritated recently when I search for a song or an artist while in album view and get no results.

trmdi added a subscriber: trmdi.EditedDec 21 2019, 4:53 PM

Just my feeling about the current UI, it looks a bit too big on low resolution screen like 1366x768.

The current design from the app or the mockup from the description?

trmdi added a comment.Dec 21 2019, 5:36 PM

The current design from the app or the mockup from the description?

From the app. Your mockup seems to be better.

The main window can actually be quite small when you hide the playlist:

We should probably make the playlist hiding feature more obvious, and maybe make it auto-hide itself when the window is shrunk down to be very small, similar to hos the sidebar become icons-only for small window sizes.

The main window can actually be quite small when you hide the playlist:

We should probably make the playlist hiding feature more obvious, and maybe make it auto-hide itself when the window is shrunk down to be very small, similar to hos the sidebar become icons-only for small window sizes.

Really nice idea. If I remember correctly, there is still a task related to that.
If nobody does it, I will eventually do it next year.

Really nice idea. If I remember correctly, there is still a task related to that.
If nobody does it, I will eventually do it next year.

I've just submitted an MR to do the first part (making the action more obvious): https://invent.kde.org/kde/elisa/merge_requests/47

Actually I adjusted the MR to do the auto-hiding too. It seems to work well.

I've also submitted an MR to adjust the delegate header styles to match the general KDE style and move towards these mockups: https://invent.kde.org/kde/elisa/merge_requests/48

In T12372#214054, @KonqiDragon wrote:

Here a Artists category mockups, prompt me what to add about selected artist in addition to Name and Genre? Also than fill the empty space upstairs (where the search place)?

Those mockups are really good ! Thanks for your work.

I plan to work again on https://invent.kde.org/kde/elisa/merge_requests/3 and implementing your mockup at the same time makes plenty of sense.

I really am motivated to make them reality if there is a consensus about them ?

The artist category looks good but maybe make a bit thinner the banner:

(85px tall)

also, have the svg from the previous one

Could to make a album more smaller? To keep the album inside the background with blur, not the album on the left and blur on right.
Something like this (sorry i make it in GIMP)

smaller version (maybe when you scroll down)

ghost34 added a comment.EditedDec 22 2019, 12:57 PM

smaller version (maybe when you scroll down)

Yes, yes, looks kool. Smaller version have the same size as a playback controls?

yes, it has the same clickable area (30 px)


I updated the mockups, now it's have a kool tweaks by @manueljlin

ghost34 updated the task description. (Show Details)Dec 22 2019, 7:15 PM

I make mockup of Tracks category

ghost34 updated the task description. (Show Details)Dec 23 2019, 5:33 PM

Some mockups that include the Playlist sidebar would be nice too. That's an integral feature of Elisa that we aren't going to want to lose.

Some mockups that include the Playlist sidebar would be nice too. That's an integral feature of Elisa that we aren't going to want to lose.

+1

That would be really nice

daerny added a subscriber: daerny.Jan 4 2020, 1:21 AM

I quite like how you can 'close the drawer' as such, to remove the unneeded information onscreen, after you got your playlist down. If that is going to be removed, i will not like it.

The 'header bar' look on the top of the mockup is very nice. Regarding the 'playlists' feature you mentioned, why not integrate that on the left side? Have a 'Currently Playing' or similar option that shows the songs in the currently selected playlist and then a 'Playlists' option (like in the mockup) for choosing which playlist you want?

Is any work, of the above still pending, I want to help, which part of the problem can I take on? Can someone help me out? Thanks.

You can always work on whatever you want. :) See https://community.kde.org/Get_Involved/development and https://community.kde.org/Elisa. If you need a hand with anything, subscribe to the Elisa mailing list at https://mail.kde.org/mailman/listinfo/elisa and send an email to the list.

Any mockups for plasma mobile elisa?

Hello, would this redesign still include the cover art view? I'm asking since it doesn't show up in the mockups.

We can just adjust current design
We can remove the big color in top
And combine the art cover with the tools bar
And make media buttons much bigger
Combine current with the best from the mockups

Hey, not sure if this would be the right place to say this, just my 0.02$ of feedback on the playlist stuff. Most people I know listen to music through playlists, with most of my friends having around 5 of them. One of the things I miss from other music players is having such playlists readily available on the side bar, such as in rhythmbox, spotify, itunes, etc. I'm not sure how the playlist sidebar came to be, as I can't see it in the mockups, but it seems to assume that when a user wants to listen to a playlist they will load it from a playlist file and into the queue. In my eyes, this has a few implications when it comes to user experience:

  1. It has a steep learning curve: it takes a bit of time to wrap your head around the logic of loading playlists instead of playing them. Loading files is also not a very user-friendly way of listening to a playlist.
  2. It mixes the concept of queue and playlist: while it's an interesting idea, the two concepts aren't totally compatible. Let's say, for example, that I have loaded a playlist to the queue and i have made some modifications to the queue (let's say that i have removed some songs that I wasn't in the mood for). Now imagine that i wanted to add a song to one of my playlists: because the queue is where you edit the playlists, I would have to clear everything in that queue, load the fresh playlist, add the song, save the playlist and then remake the queue that I made earlier. As you can see, it interrupts playback and can be confusing if you don't understand the logic behind it.
  3. It clutters the UI: while it is normal for professional software to use multiple panels to give access to more functionality at once, in my opinion a music player doesn't have to cater to the power-users, instead aiming to be as intuitive and simple to use as possible. Unless you make playlists for a living, I'm sure that most users would rather have ease of use than direct access to all of the features.

Therefore, I propose that playlist list be implemented in the left sidebar, for quick access. I see that a lot of people here are very fond of the playlist sidebar, but listing the playlists on the side would make it a less essential part of the UI and it could be moved to an entry on the left sidebar, like rhythmbox does. This way we could keep the same flexibility when editing the queue, with the only inconvenience being that it wouldn't be always visible.


I don't want this to sound like one of those "I want this because x application does it this way", but I feel like the design patterns that the users are used to conflict with Elisa's current implementation. Huge thanks for all you work!

Yes, our awkward playlist support is simply a bug (or more precisely, the lack of a feature). It's not an intentional design choice. See https://bugs.kde.org/show_bug.cgi?id=406477