I am struggling with the UI presentation for a search module in a music library web application for a radio station, it will be used by on-air staff. I am working with a library of tens of thousands of albums, thousands of artists, and hundreds of thousands of tracks. Clearly, search functionality will be a key component of this application, and we're really trying to get it "right"

Within this interface, there are a row of tabs on the top (typical appearing tab-type interface). One of these tabs is "Quick Search". The intention of the contents of this tab is to provide progressive/auto-complete search results from three pools: artists, albums, and tracks. As the user types in their term, each of these three "buckets" independently displays the matching results (via AJAX), or "Did you mean?"-type suggestions when no results are found for the given term.

The trouble is, primarily, screen space. We've made the decision to limit results for each of the three buckets to 10 (there is another section of the application which provides more fine-grain searching with tags). The key to this one is speed - we're looking to accommodate a user that knows exactly (or almost exactly) what they are looking for. To that end, we also want the interface to be very clean and minimal.

Currently, the content portion of the screen is divided into three columns. Each column displays a table with the results for each of the search pools (an artist column, an album column, etc). The results tables in each column can only really fit 2-3 table columns. For example, with artists the columns would be Artist name, number of albums, and rating (internal star-based rating). If the user sees what they want, they can just click the result and move on.

This interface strikes me as too busy. Three side-by-side tables with mouseover row hiliting, a variety of data, and click actions on every row is a little overwhelming. I can't imagine dropping columns from the tables - I feel like we're already at the minimum with 3. I considered displaying only one "bucket" at a time with some kind of mechanism to switch between them, but I'm already using the tab UI element, and nested tabs strike me as an unnatural UI.

So... if you can follow all that, does anyone have any inspiration, suggestions, or ideas on how to present three separate tables, having each be easily accessible with minimal clicking to transition between each, and without using a tab UI? I hope I've described it well enough, I can provide screenshots if it would help. For reference, the entire concept is inspired by Winamp's music library search - there are three panes which display the result "buckets". I tried to emulate the pane-type layout, but it has the same screen-crowding issue that the side-by-side columns have.

ETA: I have considered using strong color-coding as an alternative. Something like they do here: http://www.triplify.com/search.php?q=test+this+out. But, the difference between a Google search result and a Yahoo search result is less important than the distinction between a music track (something I can play) and an artist (something I cannot play directly, but "contains" albums), and an album ("contains" tracks that I can play). I fear that strong color-coding may not be enough distinction between results to be clear.

  • 1
    Consider adding a central question, one sentence, and bolding it so that people can figure out what exactly it is that you're asking before reading the background. It'll help you get answers. Also, please do consider adding screenshots!
    – Rahul
    Jun 4, 2011 at 0:16

4 Answers 4


What I'd do is to have all the results from the three "buckets" interleaved in a single table, then add use "bold" text to highlight the search terms.

So, if you're searching for the term "bill", an example result page might look like:

Track              Album               Artist
**Bill** Song      Some Album          John Doe
Good Song          Bad Album           **Bill**y Doe
Some Song          **Bill**ie Album    Jane Doe

(where things in ** are in bold)

User should also be able to click on a column, say, on "Some Album" to easily narrow down their results to search results of "bill" in "Some Album" albums. If the user want to search on track, album, or artist only then they can use operators, e.g. album: bill, artist: bill, etc (user might be familiar on using advanced search operators from Google).

What is left unsaid for this UI to be effective is that you also need a solid sorting algorithm.

  • I sort-of ended up with this solution. After trying several iterations of the same theme, the client seemed to take to this: img714.imageshack.us/img714/6623/resultsj.png. Each search area (artists, albums, tracks) is simultaneously searched, each is searched at three levels progressing sequentially. So first, a search is made for exact matches only, when those results come back another search is made with wild cards (term is IN name/title), then a "sounds-like" search is last.
    – Chris
    Sep 13, 2011 at 14:30

Rather than answer your direct question, I'm going to show you how Spotify does this because I think they nailed it. While I also like Winamp's approach, Spotify is more recent and draws inspiration from iTunes. However, iTunes is slow and unoptimised for giant libraries, and this is where Spotify shines as it instantly searches hundreds of thousands of tracks.

Here's what their search results page looks like:

Spotify search results for 'beat it'

Some comments:

  • The top area displays album covers. Album covers can be very distinctive and Spotify recognises, like iTunes' cover flow, that many people can quickly pick out an album by cover image as opposed to by title.
  • Results are sorted by popularity. Spotify can do this because it's a cloud service, but perhaps you could sort things by number of times played on the radio station or something to emulate popularity.
  • Clicking an artist in the list shows all tracks by the artist with 5 top hits displayed first (again based on popularity). Clicking an album shows all tracks in that album.
  • Dragging anything from the right pane onto the left pane's "new playlist" button creates a playlist. Dragging onto a playlist entry adds to that playlist.
  • Note the little arrow with a line above it next to some tracks. Clicking this "expands" the track to let you see that it's grouped by title and gives you the opportunity to see albums on which that exact track is featured.

What I like about this UI is that it makes it very easy to quickly drill down when I'm searching for something. In the case of Michael Jackson's Beat It, it's a no-brainer to get the classic. But it's also easy to get an apparently popular cover or things like B-sides and demos because network-wide, those are very popular (Richard Cheese? Really?).

Of note is that the search works like Google. In the list I have in the screenshot, halfway down the list we start finding tracks not called "Beat It" but containing those words. If I just wanted tracks titled "Beat It" I could include the quotes in my search. I find this an important aspect of search as it brings the power user features from Google into Spotify and that "expectability" is an important part of searching when I want to drill down to something specific. I imagine DJs would be happy if search worked as smoothly as this.

Although I understand you won't be able to play with Spotify yourself in the US (you might be able to via a proxy), it's worth looking into if you're designing a music search interface. This is simpler than a three-column approach and necessitates fewer complex solutions like autocomplete or color-coding simply because it's very fast and very accurate. You might not be able to implement something to this degree of quality due to constraints, but it's a good target to aim for.

  • Thanks for the input. I didn't end up doing this, but I did spend a lot of time on this site getting a feel for the mechanics, and some other aspects of the UI reflect this experience. Thanks again for the tipoff!
    – Chris
    Sep 13, 2011 at 14:31

It's tough to envision what you're working on, but my gut feeling is that you might be trying to make the software 'be powerful' for the users and showing too much all at once.

If you're confident in the quality of the search technology, you could try taking your top hit(s) and showing items from the bucket where those highest scoring results reside, and provide toggles to show the other buckets and their results. This would also allow you to show more results per bucket.

For example, suppose I search for "Jackson". The search would likely come beck mostly with artist name as the bucket with the most results, so show that bucket. The toggles for the other two buckets could have numbers beside them. To indicate how many results are in that category.

Hopefully that helps, and I haven't gone way off course. As I say it sounds somewhat complex and is hard to visualize. Not to mention, I know nothing about Djing :)


Is it really necessary to display the results as tables? Tables work best for displaying a large number of results given plenty of width, but that isn't really what you have to work with.

Given that you can just type a bit more to bring more relevant results to the top, anything beyond the first 10 results doesn't matter. That means you have lots of vertical space to work with - around 5 lines for each result would probably work well.

As well as being able to display more detailed information for each result, you have the option of including visual elements that may allow the user to recognize the correct result faster than reading the text in a table.

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.