From CS294-10 Visualization Fa08

Jump to: navigation, search


Data Domain and Previous Work

We discovered that we were interested in the same domain (Last.fm data); more description can be found on A3-MaxwellPretzlav and A3-NicholasKong.


We decided to combine both of our ideas to implement a hierarchical exploration of the time-series last.fm listening data. We have a core set of features we'd like to complete by the deadline, and subsequently a few additional components that we will work on if time permits.

Core application

Music falls naturally into a hierarchical categorization of genre -> artist -> album -> track. However, one of the main features of last.fm is that it allows users to explore their listening history; now we have hierarchical time-series data. We want to allow users to explore their listening history at any one of hierarchical levels mentioned previously; for the core application, we seek to implement only the genre -> artist -> album hierarchy. Track data could overwhelm flare's capabilities if the libraries become too large, so we will leave that as an optional feature. After logging in, the user would see the following main interface:

Main display

This is a display of genres, based on Last.fm user tags of the artists. Upon hovering over a genre, the user will see a tooltip with details about that particular strip, in this case number of plays and number of artists in that genre.

The bottom right slider allows the user to interactively adjust the date range they wish to visualize. Last.fm provides play count data by individual weeks, so we can allow the user to have control of time ranges down to the week level. The user could drag either the "begin" or "end" handles to specify the date range. The range endpoints are just temporary labels in the mockup; they'll be dates in the final product.

If the user were to click on a certain genre, they would then be able to visualize the artists in that genre:

Artist view

The "Tag: Post-rock" button at the right both indicates where the user is in the visualization, and also allows the user to back up to a previous view by clicking on it.

The text-box is used to filter the current view; here we see "Mo" has been entered, and only artists containing the substring "Mo" are displayed. A similar tight-coupling as is seen in Job Explorer will be used: the text-box will both allow the user to filter and will inform the user of the current state of the visualization.

Possible extensions

As stated earlier, we plan to only implement Genre -> Artist -> Album nesting, but if time permits we'd like to add Album -> Track as well. This may prove to be an issue with flare if the amount of data is prohibitive.

Also, Last.fm measures the popularity of an artist/album by the number of plays of their songs. However, not all songs are of the same length, and this method may bias the rating in favor of artists with shorter songs. If time permits we'd like to match the Last.fm track data with the Musicbrainz track duration data in order to rank popularity by approximate time spent listening to the artists. It may also be interesting to enhance the tooltips with other Musicbrainz metadata, such as release date/country in the case of albums.

Final application

You can view and interact with our application by clicking here. As mentioned below, you can use either of our usernames, quasiphoton or wetzel, to explore our data. Type one in and hit enter. If the application hangs during loading, try refreshing, restarting your browser, or both. The fewer windows or tabs you have open the higher chance of success, but unfortunately we've been unable to positively identify the cause of this problem.


Media:LastfmVisSource.zip or svn co http://alex.turnlav.net/lastfmvisflex/trunk/src/ lastfmvis

To compile the source you'll need to check out the latest version of flare directly from the flare's svn: svn co http://svn.prefuse.org/flare/trunk/flare/ flare

Changes from Storyboard

We did not implement artist-to-album drill-down functionality. This is further explained in the Development commentary section where Alex talks about problems integrating two different, but related, datasets. Besides this, all of the essential features from our storyboard were implemented.


When the application is first started, the user is presented with a username textbox. If you don't have a Last.fm account, you can explore Nick's music library with quasiphoton or Alex's with wetzel. It'll take a while to load all of the data, partially because we're limiting our API accesses to five requests/second averaged over five minutes, as specified by Last.fm.

Once loaded the user is presented with a chart similar to the following:

Main display, final application

This is a display of all the top tags assigned to artists that the user has been listening to over the past year. Hovering over the tags reveals a tooltip displaying the tag, date, and the number of tracks played for that tag on the week beginning on that date. Clicking on any tag will expand that tag. The search box will match substrings in any part of a tag. Here's an example of that applied to "metal":

Filtered "metal" tag

The slider at the bottom can be used to zoom in on a portion of the displayed date range. The left thumb controls the earliest date displayed, the right thumb the latest.

Double-clicking on any tag allows for a drill-down operation. The tag is expanded into all of the artists comprising that tag, as shown below for "jazz":

Artist drill-down

Here the date range has also been modified. To return to the tag view, click "back to all tags".

Work breakdown

Nick worked on the front-end: date slider, search box, hover tool-tips and coloring scheme. He also created the storyboard and co-authored the final write-up.

Alex implemented the framework for the visualization as well as the back-end: all the components related to interfacing with the Last.fm API and storing and converting the data. He also implemented tag-to-artist drill-down functionality and co-authored the final write-up.

Both Nick and Alex squashed bugs throughout the application.

Development commentary


Once I had adapted somewhat to ActionScript and Flex, particularly in merging the two into one project, working with flare proved to be surprisingly easy and intuitive. Animation became simple and elements such as axis labels came essentially for free. However, the major obstacles I encountered occurred when I needed to circumvent flare's architecture, particularly when implementing the date slider. As we were using the StackedGraphLayout class, our NodeSprites each contained a number of playcounts associated with a single artist or tag, indexed by date. flare made it very easy to filter out artists or tags because each artist or tag was a single all-encompassing NodeSprite. However, the date slider required a modification of the underlying data for each NodeSprite. My solution is very messy and there is likely a much more elegant solution that doesn't quite work against flare as much: I ended up exposing the x-axis scale variable in StackedGraphLayout and modifying that, as well as changing the layout function slightly. As a very rough estimate, I spent 20-25 hours on development.


Getting my hands dirty with Flare taught me a few things about jumping into a new unfamiliar API. Flare is an impressive and powerful tool, but when I started to push it beyond the examples I had seen I started to encounter it's "alpha"-ness. Due to how new it is there was very little information online beyond the existing example applications and API demos, and there were places where it seemed the API documentation was slightly incomplete (althogh the forum did help). In one case I spent a good deal of time trying to figure out why some code in JobVoyager wouldn't work in our application, only to discover that the code for JobVoyager is written for a version of Flare several versions back and the API had changed.

I found the most time-consuming part of this project was figuring out how to pull all the data from Last.fm and integrate it into a format that Flare could easily display. Since part of what we do is combine different available data sets together, this took several intermediary data formats and a good deal of care to make sure everything was put together properly. If we had implemented this project in Java, I expect this section of the project would have taken even longer due to the more strict and complex data types and XML APIs in Java — using E4X made data processing much easier than it otherwise would have.

I also spent a fair amount of time trying to figure out why things that seemed like they should work with Flare didn't. For instance, keeping the tag-listening data and artist-listening data separate seemed like a reasonable approach—I would just swap the data in the visualization when the user double-clicked on a tag in the graph. It turns out that Flare doesn't seem to like having the data in a visualization directly changed. I ended up combining the two datasets into one and using a filter to tell the graph to only show one at a time. I ran into a number of instances of things like this in the Flare API, where something that seemed like it would work failed and I had to use trial and error to find a workaround.

Lastly, we ran into performance limitations when it came to displaying the chart itself. Displaying more than about a year's worth of data causes a significant slowdown; if I try to view all four years of my last.fm data, the application becomes incredibly difficult to interact with. Because the data is still interesting, I've put a version online here which will pull all the data available for a given user, instead of just the last year. Beware, it will take considerably longer to download all the XML data, and the responsiveness to user interaction is on the order of tens of seconds.

I spent roughly around 20-25 hours on this project as well.

[add comment]
Personal tools