10

I've got a small desktop application that scans music folders and randomly chooses an album to play. The first version is WinForms and has "previous" and "next" buttons either side of the album art that are activated when there are more albums by the same artist.

enter image description here

I'm not happy with this UI as the buttons take up too much space.

I'm rewriting the application using WPF and I'm looking for a better way of indicating that there are other albums by the same artist. I've experimented with displaying the buttons on top of the cover art and only showing them when the mouse rolls over their position but I'm not happy with the result primarily because there's no indication that the options are there.

I found a neat trick on Brian Stevens Photography site where the cursor changes to "+" and "-" over each half of the image to indicate navigation, but I also use a click on the image to play that album so I'd have to adapt this approach if I wanted to use it myself.

Is there a better way or is a carousel or coverflow control the way to go with this?

For a bit more background read this blog post of mine.

2
  • Is the choice of album title a hint about what's gone wrong in the UI? Commented Mar 24, 2011 at 21:49
  • @James - no, it was just what happened to show up when I needed to take the screen shot.
    – ChrisF
    Commented Mar 24, 2011 at 21:50

7 Answers 7

9

Basically 2 ideas here, the first is showing small circles, the one highlighted in the center is the current page/album being shown, as you click on the arrows it would highlight the next/previous one. This gives the users an idea of how many albums are available for the given artist.

(re-purposing of Matt Lutze excellent ASCII drawing)

[Settings]  [Random album]  [Info]

 {                              }
 {                              }
 {            Cover             } 
 {                              }
 {                              }

 <<       o o o * o o o        >>

This next one could be shown when there are more than say 6 albums for an artist, which is just showing album 1 of total albums.

[Settings]  [Random album]  [Info]

 {                              }
 {                              }
 {            Cover             } 
 {                              }
 {                              }

 <<          1 of 10           >>

This way the elements are still present and shows a visual (or literal) queue that there is more to view/listen.

Random Idea: Of course I really like the idea of clicking on the Cover Art and being able to look inside, which in this case would simply be showing a list of the songs available in that album. This would be them the option of playing a specific song.

[Settings]  [Random album]  [Info]

 {   1. Song Names here       ^ }
 {   2. Song Names here         }
 {   3. Song Names here         }
 {   4. Song Names here         }
 {   5. Song Names here       v }

 <<           1 of 10          >>
1
  • +1, I was going to write something like this, but you saved me the effort :) Commented Aug 16, 2010 at 21:08
5

The navigation buttons look bad because of visual dissonance

  • They are round and the image is square.
  • They are strongly luminously 3D and the image is flat

and

  • The space they waste above and below is flat grey unused, not using similar decoration to the buttons, so it doesn't harmonize with the buttons either.

Narrow rectangular flat buttons the full height of the album art, using stacked ">"'s (or "<"'s) at the middle would solve these three problems, but the cover art would still be separating your navigation controls. It's going to work better having the navigation controls in one visual chunk.


Here's an old fashioned solution (left) and a more modern one (right).

The buttons' styling (bevel/rounding/drop-shadow/what-have-you) should match the styling for the cover-art frame.

enter image description here

The left one has the advantage that you can easily increase the size of the left/right buttons depending on how much real estate you want to give them and how easily you want them to be hit.

The right one has a fish-eye mini carousel underneath it. You'd need to old-photo the thumbnail images when not activated so as not to distract from the cover art, and you have little choice over sizes.

The left is simple and effective, the right has more eye candy kudos. I prefer the left. You can probably guess which era my taste in music comes from.

3

As another suggestion, Apple's CoverFlow uses a horizontal scrollbar below the cover art to allow the user to scrub through the covers.

Advantages:

  • Can quickly scrub through art. May not be a requirement for your app.
  • Scales okish with large numbers of art.
  • Enables good random searching by scrubbing back and forth.

Disadvantages:

  • Not obvious how many items there are.
2
  • I've already thought of using a coverflow. My current approach also doesn't indicate how many albums there are just "none" and "some".
    – ChrisF
    Commented Aug 20, 2010 at 12:07
  • + 1 for itunes coverflow. it has a nice visual impact and it's really usable. Dont know how easy is ti develop it with WPF...
    – franz976
    Commented Feb 27, 2011 at 11:51
3

Just because a UI element isn't immediately obvious, it doesn't mean that it's a bad choice. I'd definitely go with something where clicking on the right hand side of the cover advances one step, and clicking on the left hand side goes back. (Assuming that this will only be used with left to right languages?)

Instead of the + and - signs of the photo website, I'd just suggest < and > . And I wouldn't have them transform or follow the cursor, I'd just place them in the middle right and middle left.

You could experiment with clicking in the middle as a way to play/pause the album.

This sort of nearly invisible user interface is just as easy to use once you've found it, and it looks much nicer than having separate buttons hanging around that (as usual) look like buttons. The aesthetic extreme of this would be to incorporate all UI elements into invisible elements in the cover preview. So that you just see the cover (and perhaps the song title) when the mouse is not hovering over it. Perhaps this would work for your app, and perhaps not.

3
  • Nice answer - this is a side project so I don't get to work on it as often as I'd like.
    – ChrisF
    Commented Aug 9, 2010 at 21:04
  • 2
    As far as the users to notice the feature, you may want to look into a way to have them display briefly on load and then disappear until they hover over it. Commented Aug 9, 2010 at 22:30
  • @LoganGoesPlaces, yes, that's a really good point. Commented Aug 12, 2010 at 7:07
2

As someone who answers support e-mails I can tell you that if a user interface element isn't immediately obvious a good percent of your user base will never find it.

They will also never read the docs or any popup message.

A feature should either be obvious (and often even having a button isn't obvious enough) or just work without bothering the user (the red squiggle underline spell checker is a good example, you don't have to find it - it's just there).

You can re-style the buttons so they aren't so big and so they blend more into the background, for example if you replace the buttons with two small arrows that don't have that heavy button frame they wouldn't stick out that much while still signaling to the user there's something more available.

2

Interesting question, and some good points with both existing answers.

Regarding omnipresent vs. hidden controls: I would recommend leaning toward controls that are always visible, but are not visually distracting. Green, blue, patterned; all have the potential to be at least a little distracting. I generally agree with Nir here on using simple arrows or "greater than" symbols

<< {Image} >>

vs. icons/buttons.

I'd extend the suggestion toward your top icons as well, and perhaps suggest letting the concept visually bridge the desktop app / web app boundary:

[Settings]  [Random album]  [Info]
              Title
   {                          }
   {                          }
<< {          Cover           } >>
   {                          }
   {                          }

I would generally tend toward making the cover art the dominant object in the interface. Thin-ish row of text-link-buttons on the top, the title, then a large image of the cover, with narrow back-forward bars on either side. Or something like that.

However you swing it, I at least suggest not using novel dynamic indicators like a changing mouse pointer icon. A lot of people will get scared or nervous when their pointer changes; from my experience, the user expects their pointer to do predictable things after predictable actions and not to surprise them.

Neat project, and thanks for the discussion. I'm curious to hear what others think.

1
  • Thanks for the input, I agree the album art should be the dominant feature. The UI has changed a bit since that screen shot - I've removed the "'Album' by 'Artist'" text. This was always available as a tooltip on the cover art anyway.
    – ChrisF
    Commented Aug 16, 2010 at 20:20
1

Look to the Web for guidance. It's where most users live, and it guides their UI expectations. Look at popular sites for your target demographic, and see how they manage navigation. Navigating music is similar to navigating photos, so look to newspaper and magazine sites for guidance.

Navigation of this sort is most often accomplished by small buttons above the graphic, or by transparent buttons that appear on mouse-over. If your UI is designed so that the user clicks on an album cover to listen to it, they will discover the tranparent buttons quickly enough.

1
  • +1 for 'click cover to play' implies user will discover mouse-over overlay quickly. Commented Mar 30, 2011 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.