Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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 next to 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 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.

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

7 Answers 7

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          >>
share|improve this answer
    
+1, I was going to write something like this, but you saved me the effort :) –  Carson Myers Aug 16 '10 at 21:08

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.

share|improve this answer

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, I guess? :P )

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. I think it could work really well.

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 you app, and perhaps not.

share|improve this answer
    
Nice answer - this is a side project so I don't get to work on it as often as I'd like. –  ChrisF Aug 9 '10 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. –  LoganGoesPlaces Aug 9 '10 at 22:30
    
@LoganGoesPlaces, yes, that's a really good point. –  Scott Newson Aug 12 '10 at 7:07

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.
share|improve this answer
    
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 Aug 20 '10 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 Feb 27 '11 at 11:51

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.

share|improve this answer

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.

share|improve this answer
    
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 Aug 16 '10 at 20:20

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.

share|improve this answer
    
+1 for 'click cover to play' implies user will discover mouse-over overlay quickly. –  James Crook Mar 30 '11 at 9:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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