Skip to main content

Mobomo webinars-now on demand! | learn more.

The main function of data visualization is to help us better understand the concept of a data set quickly. When done effectively, data visualization can look organic and beautiful, but the primary goal is to help the viewer to consume and understand the gist of the data quicker than if he/she were looking at the sum of its parts.

Rating systems are a great example of where we could do better with data visualization. As Goodfil.ms mentioned last week in a post about rating systems, 5-star rating systems are broken.

A typical rating system should convey information quickly to a user as they browse through many entities on a screen. The 5-star rating system does do this, but it only shows a mean, not an entire dataset that the mean is derived from. Amazon.com does a breakdown of ratings and shows the context and relationship between all of the ratings for a product but they are too verbose to be put into a browsing view; they simply take up too much space.

The problem: we need to show detailed information of a dataset in a small space in a way that can be understood easily and quickly.

Plenty of research has gone into sparklines, which does exactly this – cram detailed information into a small space. Sparklines have been deemed pretty successful in applications, especially when surrounded by a lot of content. A study published in the IEEE Transactions on Visualization and Computer Graphics in 2010 showed that tag-cloud using sparklines resulted in faster task times, fewer errors, and was more preferred than its stacked-bar and multi-line chart counterparts.

Ok, great, a sparkline visualization meets our needs for space and can be an effective conduit, but how are we going to actually show the data we have?

Typically we think of heatmaps working really well in spatial relationships, but they've also been attributed to working extremely well when reviewing large datasets. Specifically, heatmaps can be used to find clusters and correlations from large datasets to those with only a few data points, such as 5-star ratings.

Heatmaps and sparklines are two good solutions to the problems with displaying rating results. That's why we created heatRate; a jQuery plug-in which takes a simple 1-dimensional array and creates a CSS gradient heatmap that displays the data on any HTML element you'd like.

You can keep the visualization in-line with your other elements but still see details you might otherwise miss on the standard 5-star rating visualization. heatRate has various options you can adjust to change contrast and the overall look of the heatmap gradient altogether. It works by employing HSLa, so you can choose to have values change based on hue, saturation, or lightness.

heatRate would be a good choice for you to use anywhere that you might have varied values in your data, even outside of the scenario of a rating system.

Give it a try and share your feedback with us! We'll be working on new features for this project in the coming weeks. We're obsessed with finding better ways to visualize data.

Categories
Author

Pick any popular open source library. It'll have more documentation than your application code - I guarantee it. Test and documentation are both acknowledged as good development practices. But unlike testing, documentation doesn't get the same love from developers. For code that isn't intended for a public audience, developers keep all the docs in their head, or assume that their code is self documenting. Additionally, the tests become a kind of runnable documentation. But there's several lessons we can apply to our private application code from open source documentation. Today, we'll start the conversation with the lowest hanging fruits - the README.

The lack of a good README is one of my major pet peeves. When starting on a new project, more often than not, I'll find myself staring at this README:

== Welcome to Rails  Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Control pattern. 

That's a fantastic README introduction... for the Rails framework. But it also happens to be the default scaffold README for every new Rails project. Think of a README as a first impression of your project. Just like open source projects, your README should introduce the project the new developers.

Take 5 minutes of your time to write a README that explains the following things:

What is it?

A short elevator pitch about your application. Examples:

  • Travis is an attempt to create an open-source, distributed build system for the Ruby community that allows open-source projects to register their repository and have their test-suites run on demand...
  • YARD is a documentation generation tool for the Ruby programming language. It enables the user to generate consistent, usable documentation that can be exported to a number of formats very easily, and also supports extending for custom Ruby constructs such as custom class level definitions.
  • Spree is a complete open source commerce solution for Ruby on Rails. It was originally developed by Sean Schofield and is now maintained by a dedicated core team. You can find out more about by visiting the Spree e-commerce project page.

How do I set it up?

List any dependencies your project has, both libraries it depends on, as well as external services it uses. Also remember to include any commands to start required services. Example:

Development Setup  # install redis, mysql brew install redis brew install mysql  # install rvm: http://beginrescueend.com/rvm/install/  # within the project directory bundle rake db:setup foreman start # visit: http://localhost:3000 

Project Workflow and Tips

Usually, I like to add an additional section for developers to add tips and tricks that help with their day to day workflow. The notes listed in this section are optional and individual developers can choose to use them or not.

Seed and Test Data

Often times, existing developers and stakeholders will have their environments configured and won't remember what seed data the system assumes to exist. Versioning a gzip dump of the test data is perfect for someone to come along and get a sense of what the app data looks like.

Who do I contact for help?

If the project is a client project, it's good to list the stakeholders and their roles. It's also a good place to put down the names and contact information for members who may have worked on the project in the past.

Relevant links

A list of links to other sources of documentation or project management tools.

  • bug tracker
  • comps, wireframes, and design prototypes
  • wikis
  • staging, qa environments
  • other servers

Having a good README can help you onboard developers faster and have a single starting point for your project. It's easy and fast to write, so go forth and write yours today!

Categories
Author
1
Subscribe to Opensource