Usability and Eyesonhives

Useful data and Easy Interpretation

Two key ideas of Eyesonhives are Useful Data and Easy Interpretation. This is one of the reasons we capture video! The video is both useful data, as well as makes interpreting the activity data for what’s happening at a beehive, an easier experience!

Today, I’m taking a design course on Udacity with the goal of improving Eyesonhives usability.

The first ‘quiz’ is to share an example picture of something with an understandable design, as well as something with a confusing design.

Why does everything look a little better on a Mac?

Understandable Design

My understandable design example is the ‘play’ icon on the Eyesonhives daily bee activity graph.

The icon is understandable because of the affordance that I can click the icon to launch the video for that datapoint!

It’s also understandable because I have the conceptual model that a circular icon with the ‘play’ icon, usually means ‘play video’.

There’s also a signifier in the icon itself, and that when I hover over the icon and see that the mouse changes, and I can click play.

Confusing Design

I’m actually going to use the exact same home page as an example of a confusing design too! Let’s take another look!

The example I’m going to pick is the confusing design of the “Temperature”, “Humidity” and “Wind Speed” axes on the right hand side.

I have heard from users that they are not sure about what the axes actually mean when they see the primary view (of bee activity counts and videos), or how to see the data representing temperature, humidity or wind speed.

Using the model above, there’s no affordance for triggering the view of this data from the colored axes labels on the right hand side. Actually, there is an affordance on the labels below the main graph to trigger the data to show.

There’s also no conceptual model that’s easy to match with how to show the extra data – looking closer, the greyed out lines below the graph meet this function, but they’re not obvious, and not connected to the more obvious labels.

Finally, there’s not an obvious signifier that the grayed out labels can actually be clicked to show them! Whoops! This is an opportunity for improvement!


An affordance is the relationship between the product, and the person who can do something with it!

e.g. Color coding the Eyesonhives buttons may not be a useful affordance to someone who is blind to color.


Signifiers tell people what to do, and where to do it!

e.g. the ‘previous day’ and ‘next day’ buttons signify that’s how to change the day’s data in Eyesonhives!

How can we improve?

First pass of a concept – make the dataset toggles follow the conceptual model of buttons. Create a signifier for whether they’re active or not, maintain their current affordance of toggling on the dataset, and add another affordance to show the appropriate axes labels when actually activated!

What do you think? Did I properly understand how to improve this interface?

Do you have any better ideas that can be justified with the affordances, signifiers and conceptual model framework of design?

Leave a Reply