Posts Tagged ‘information design’

Map App of the Day: Tracking hurricanes with Stormpulse.com

Monday, September 1st, 2008

Many years ago I spent a summer in Florida working for the Naples Daily News website.  One of my jobs was to keep the hurricane section up to date - so I scoured state, county and federal government sources and wire stories to find every informative map that I could get my hands on.  What we had available on the web back then pales in comparison to the information rich interface at Stormpulse.com.

Hurricane Gustav as seen from stormpulse.com

The screenshot above is from the site, tracking Hurricane Gustav as it climbs up Louisiana, just missing New Orleans.  It doesn’t take an information design expert to tell you that weather and disaster news can be expressed very effectively with maps.  Stormpulse does a particularly good job, pulling together data from various sources including satellite cloud cover maps, ocean buoy data, and a large number of forecast models.

The site also keeps some historical data on file, which was something I’ve found particularly perplexing when checking out storm maps in the past (I admit I’m a bit of a weather geek too).  Especially back in the days of pre-rendered maps, why wouldn’t you store everything and make it available to users?  Hurricanes might seem like very time-bound events, but they can cause profound changes in people’s lives that resonate for decades to come, and historical data can be useful in predicting future storms.

Another interesting thing to note is that they are not using the Google Maps API, which seems to be the go-to API for many web mapping efforts.  In fact they offer and API of their own, although it’s limited to embedding self-contained maps.

Sphere: Related Content

Map App of the Day: A genetic map of Europe

Friday, August 15th, 2008

I’m a bit of a map geek and a big fan of using maps to convey information geographic and otherwise, so I’m starting a new series of posts - Map App of the Day.  I’ll highlight either a mapping web application or an application of mapping in information design that’s interesting, innovative, or just plain strange.

The New York Times had a brief article about a new study of genetic relationships between peoples in Europe.  The paper, by Lao et al., looked at genotype data from more than 2000 individuals spread throughout Europe.  The map on the right shows the normal geographic map of Europe, while the one on the left maps the genetic relationships between countries.

Here’s a link to a larger version on Current Biology’s web site.

The genetic map is a great example of why you should always consider mapping to illustrate data with a geographic component, and why you should always consider breaking the rules a bit  to get a good representation (most maps don’t show countries overlapping, for example).

This is also a great illustration of how permeable and impermanent national borders really are.  It would be interesting to see the same analysis done with distinctive populations like the Basque in Spain and the Sami in Finland added.

This also brings up with two non-mapping issues about journalism and research.  First off, the NYT article didn’t bother to actually link to the journal article, the researcher’s websites at their respective institutions, or any of the other places that readers would need to go to follow up on this paper or get more detailed information.  Why not?

Second, when I searched for Current Biology I was delighted to see that the journal publishes everything online, available via regular Google search, rather than hiding behind some expensive and proprietary publication database.  Open access is very cool.

Sphere: Related Content

The Art of Information Graphics

Wednesday, May 14th, 2008

I recently ran across a couple of really great examples of how information can be conveyed dramatically with infromation graphics and one example of how to fix graphics that aren’t so good.

First, from the Radical Cartography project, a map of all nuclear explosions since 1945.  This map encodes a lot of information fairly simply - we can see where nuclear tests have taken place, countries are indicated by color, and blast yield is indicated by size.  Click on the image to see the full version.

Next, from the United Nations Environment Programme’s Global Environment Outlook report, you can see a great illustration of how little of the world’s water is freshwater and how little of that is readily available in rivers and lakes.  Click on the image to see the full-sized version.

Why point out good example of information design?  Because even the professionals get it very wrong a lot of the time.  Bob Nystrom wrote a great post about how little information is presented in CNN’s chart of the delegate totals for Hillary Clinton and Barack Obama.  Here’s their version:

Without looking at the numbers, can you tell who’s in the lead?  Can you tell how close the race is to the end?  Do you read the bars left-to-right or up-and-down?  Here’s Nystrom’s improvement:

Everything becomes clearer.

Got any good (or bad) examples?  Post them in the comments below.

Sphere: Related Content

Announcing Localographer: find an apartment or house with Google Maps

Monday, April 7th, 2008

Localographer logo Earlier I wrote about using Photoshop to create a heat map and to use data maps when house hunting.  I got a pretty good response to those tutorials but the process is a little too labor intensive for most.  So when I moved to California, I decided to do something similar, using the Google Maps API, so that it would be easy for anyone to make their own heat map.So here it is:  Localographer - build interactive heat maps for house and apartment hunting.  You can see a screenshot below:Screen shot of a Bay-area heat map from LocalographerLocalographer is a beta release right now, so watch out for bugs and random downtime.  Also, I have to add a disclaimer:  this is not an official Google project, this is something I did on my spare time.  In fact, most of the work was done before I started working at Google in preparation for our move to California.The site takes you though a series of steps to build your map:

  1. Pick your city and create your map;
  2. Add places you’d like to be near (like your job or your school);
  3. Add potential locations (houses, apartments, condos) to see how they compare.

I’ve got a ton of ideas for additional functionality, so hopefully I’ll have time to add more in the next few weeks.  I’ll also be working on the site’s design, making it a bit more usable and interactive.Here’s how a map in Localographer compares to my Photoshop heat map of the Cleveland area (click on the images to see larger versions):Screen shot of a Cleveland-area heat map from Localographer   Heat map we used for house hunting, with hotspots placed at locations we need to drive toIn case you’re interested, the site was developed in PHP with a MySQL database.  The maps use the Google Maps API with some hand-written functions to correctly draw the hot spots.Please take a look and let me know what you think.  Post and problems, bugs, or new feature ideas in the comments below.  Later I’ll post a poll so you can vote on new features and other enhancements.

Sphere: Related Content

House hunting the geek way, Part 2: Data-driven maps in Photoshop

Friday, March 28th, 2008

In part 1 we created a simple heat map in Photoshop to figure out which neighborhoods would be good places to look for a new house. But distance from work and school isn’t the only factor worth considering. We can always add more radial gradients to show proximity to favorite restaurants, family members, and the like. But that’s really just more of the same.

Think about the things that make a neighborhood a pleasant place to be - low crime, low pollution, parks nearby, friendly neighbors - some of those things can be quantified and mapped. We’ll have to wait for demographers to release official neighborhood friendliness metrics after the next census, but let’s see if we can find some of the other data.

Step 3: Highlight on-map elements

At least one of the new factors we want to look at is already available on our map - parks. All the parks on the map are in one of two shades of green. Use the Magic Wand Tool to select park areas and then Select -> Similar. You can see how I’ve selected the parks in the example below.

megamap-example-parks

Now we’re going to do something similar to the concentric circles in step 2. Choose Select -> Modify -> Expand. You might have to play around with the number of pixels you expand by - for the scale I was working at, 20 pixels looked like close walking distance. Now use the fill tool with a low opacity to fill the area with the same color you used for the circles.

You can then repeat the expand and fill steps as many times as you like to build a heat map of park proximity. Don’t forget to change the blending mode to Multiply to match your other layers.

megamap-example-parks-heatm

You can follow similar steps for other on-map elements, like shopping centers, college campuses, bodies of water - it all depends on what you like to be near and what’s available on your base map.

Step 4 - Pulling in data maps

First, a disclaimer: this isn’t a tutorial on how to automatically pull data from a server and have Photoshop map it for you (but keep watching my blog for a similar project in the future). Instead, we’re going to pull data maps from other places on the web and fit them over our heatmap.

The hardest part of this next step is finding the maps. The number and quality of maps available depends on your location, but in general the best two places to look are county and city websites and nearby colleges. If you don’t find what you’re looking for under “Maps” try looking for “GIS,” planning departments, or property information. Also, many government web sites have poor search systems - try doing a Google search with the site operator instead. For example, a search for Cuyahoga County might look like this: site:cuyahogacounty.us maps gis.

For this example, I’m going to grab a map from Case Western Reserve University’s NEO CANDO site. Another good source for the Cleveland area is the the Cuyahoga County Brownfields GIS server. My wife and I both have graduate degrees and we really value education - so I’m going to grab a map of the percentage of people with bachelor degrees or higher by census tract.

Cuyahoga_NEOCANDO32443568931

Now that we have a data map, we need to clean it up a bit and add it to our base map. Open the data map in Photoshop and use the Magic Wand tool to select the black and gray areas - the lines and numbers. Use Select-> Similar to make sure uoi have most of it selected and hit Delete. Now Select All, Copy and Paste it into your map as a new layer.

You’ll might want to use the Magic Wand and Select-> Similar again to clear out all the white area around the map and leave it transparent, but you don’t have to - you’re going to change the layer blending mode to Overlay like the other layers anyway. At this point, I can almost guarantee that the data map will be much smaller than your base map. Chose Edit -> Transform -> Scale to stretch it to fit. There’s no sure-fire way to do this, just keep stretching until you have a good fit to known boundaries like coastlines and major streets.

Here’s the result:

megamap-example-college

Step 5 - Bring it all together

Now that we have all these different layers, it’s time to pull them all together in one heat map.  You have a few options on how to do this.  If you make all the layer visible at the same time your going to get a lot of very blue areas.  Instead, try lowering the opacity of each layer based on who important it is to you.  You can see an example of my Cleveland area map below.

megamap-example-final

If you want to make the strongest areas of the heat map more visible, start by making your base map invisible while leaving all your other layers up.  Go to Select -> color range and clikc the eye dropper on the darkest blue area you can find.  Now increase the Fuzziness until it looks like the best areas are selected.  Hit the OK button, create a new blank layer, turn off the rest of your layers, and fill the selection with your blue.  You can see the result below.

megamap-example-final2

Hopefully this has been helpful.  You don’t have to make your map quite as involved as mine, and of course if you are looking in a smaller area you can constrain your map further.

Stay tuned for more updates on this topic.  If you have a feed reader you can subscribe to my blog and if you’d like you can get email updates, too.

Sphere: Related Content

House hunting the geek way, Part 1: Using Photoshop to make heat maps

Wednesday, March 26th, 2008

If you’ve ever moved to a new city and looked for a house or apartment you know how difficult it can be.  What neighborhood, which side of town?  Can we live close to my wife’s workplace and not to far from mine?

I thought I would share the method I used to find our last house, using Photoshop to build a heat map of the city.  Note that this is NOT the method I used to find our current apartment - watch this space for more news on that coming up.

Step 1 - Build a map

In order to build our heat map you’ll need a base map to place everything on.  Back in 2004 when I did this project Mapquest was still the best thing going, so that’s what I used.  If I were doing it now, I would go with Google Maps.

This is the most tedious step, since you’ll need to center your map, take a screenshot, then cut the map portion of the screenshot and paste it into your working image.  If you have a scanner and a nice print map you’d like to use instead, feel free to go that route.

You can see my example, a map for the Greater Cleveland area, below.  Click to see a larger version.  The inset shows you the level of street detail I found best - zoomed in close enough to see all the streets, but not so close as to make your map unusably large.

megamap-example-plain

Step 2 - Place your main locations

What are the three most important factors in real estate?  Location, location, location.  In our case we want to live close to the locations we need to go to on a regular basis.  For us that was two workplaces and two universities.

Heat maps are a great way to visualize information.  They are a perfectly appropriate choice for map location and distance information.  So create a new layer in Photoshop.  Choose the gradient tool and make sure you’re using a Radial Gradient.  The gradient should go from a solid color (I chose blue) to transparent.  Using the map, create a radial gradient about as wide as you would like to drive.

These smooth gradients can make it hard to make distinctions when you are zoomed in and, on a large map, will take up a lot of disk space.  So an alternative method would be to create a series of coencentric circles, each smaller than the last.  That’s the method I used in the example below.

megamap-example-locations

Once you have one good circle layer, copy it for each of the locations you want on your map and drag them in to place.  You’re probably going to want to change the blending mode for the layers so that you can still see map details - I recommend using Multiply and lowering the opacity just a bit.

In my example map, you can already see how this could help narrow down which neighborhoods to look in.  It also shows quite visually that there’s no point in trying to live closer to Kent - it doesn’t intersect with any of the other hot spots.

In part 2, we’ll take a look at pulling in data maps for things like crime statistics , highlighting other map features, and pulling it all together.  Also, I’ll have an exciting announcement about another project I’ve been working on soon as well.  Stay tuned.

Sphere: Related Content

The usability and design of two warning labels

Monday, January 14th, 2008

Usability and design aren’t just concerns for web developers.  They can make a real impact in the use and usefulness of physical products as well.

Warning labels are a great example - you can’t buy anything these days without some kind of warning label, and they are visual design elements intended to convey important information to buyers and users.  I ran into two great examples in the course of packing up and clearing out our house.

Example number one is from a big plastic storage tub.  It’s a great example of both usability and design, though the actual message might seem a bit silly.  Do people really need to be warned not to seal their children inside airtight containers?

A clear warning - do not store baby in plastic tub

It’s great from a design standpoint because it is clean, puts clear emphasis on the important diagram, and uses bright, attention-grabbing colors.  Any parents poised to place their toddler in the bin will not doubt see the label before recklessly replacing the lid.  It’s a good usability case because it conveys information very clearly and effectively-the silhouette kid is immediately recognizable and it uses common conventions such as the red circle and slash to mean “NO!”

The second example is…  well, strange and off-putting.  We might laugh at the thought of tupperwared toddlers but fireworks obviously pose some danger.  This series of warning messages from the back of a box of fireworks is, well…  take a look for yourself.  I recommend clicking on the image to zoom in in Flickr.

Strange fireworks warning label with creepy inhuman cartoon characters

So what could have been improved from a design standpoint?  For one thing, it would help if the coach and the two children in the second panel weren’t wearing what appears to be ghoulish, grimacing deathmasks.   They look like a cross between some misguided ventriloquist’s dummy and the clown that haunts the nightmares of every five-year-old child.  Cartoons caricatures can be very effective in warnings because we can remove unneeded visual detail to focus on what’s important and because people are accustomed to following short narratives in the style of comic strips.  But not if they are so ugly.

What are the usability problems?  Let’s start at the top.  The phrase “Common sense coach reminds you to…” isn’t quite as clear and gripping as “Warning: suffocation risk” in the first example.  The idea of using cartoons to illustrate each point is good, but the actual illustrations miss the point.  Without the text, do you think you could figure out the meaning of each of these?

For more examples of how usability and information design impact the real world, see The Design of Everyday Things by Don Norman.

Sphere: Related Content

The information design and aesthics of five-year-old me

Thursday, January 3rd, 2008

I recently came across something at my grandmother’s house - a drawing I made when I was five years old. Normally it would be more appropriate to post it on a refrigerator than a design and usability blog, but bear with me. The interesting thing about this crayon drawing is that it’s a representation of a real place - so we can see a little bit about how I saw my world at that age and how I tried to represent it.

Let’s look at this picture from three perspectives to find the good, the bad, and the ugly.

My house, according to 5-year-old me

The Good - Information Design

First, how well does this image convey information to the viewer?  Most of the time when we talk about information design we’re worried about accurate infographics, legible labels and structured documents.  Since this image was intended to represent a real-world place we can look at it the same way.

Young me apparently had an eye for color and texture. The red and black brick makes the house immediately recognizable - I bet that if I handed it to a stranger and lead them to the right street, they would pick out my parent’s house immediately. The barn to the right was my dad’s large shed, and the color scheme and pattern of the beams is pretty accurate.

My house, according to 5-year-old me When viewed as a thumbnail, it’s clear this image actually has a fair degree of information density - and this is years before I had read anything by Edward Tufte. The viewer gets a good number of identifying characteristics in a small space, including architectural style and building materials.  I had even included a bit of topography (the barn is uphill from the house and front yard).

The Bad - Artistic Aesthetics

Now let’s look at it from a more artistic point of view.  Aesthetics are subjective, so I like to take into account the intent of a piece if possible.  For this drawing, accuracy is the most immediate concern.  Not all art has to be photorealistic or even representative, but I have no doubt that young Jason was trying his hardest to draw the place exactly as it existed.

For an objective piece this has many errors and omissions.  For example, my parents’ house does indeed have a door, a number of additional windows, and a garage. The house is a ranch and my guess is that the shape shown here was influenced by the boxy, generic house shape that shows up in cartoons and childrens’ books.  The window in the barn was never actually there and the driveway shouldn’t reach all the way back to it, instead ending at the missing garage.

Note that everything is completely flat - there’s no notion of perspective. I can’t be too hard on kindergarten self on this point because even the Ancient Greeks and Romans never mastered linear perspective. It’s hard to believe, but the brilliant minds that designed and built the Parthenon did not understand that to accurately represent our three-dimensional world on a two-dimensional surface, parallel lines should converge toward one or more vanishing points.

Classic photo of the Parthenon

The two human figures represented in the windows are trite, generic stick figures.  They show no emotion or individuality, and are poorly executed compared to the house and barn.  The green grassy ground ends abruptly to the left of the house leaving an unbalanced, awkward composition.  Overall I would have to say that this work was a failure, with some consideration given for the limit of the medium and the spotty recall of my five-year-old brain.

The (Potentially) Ugly - Childhood Development

Now for the analysis that is a little too close to comfort - where does this artwork put young me on the timeline of childhood development?  I remember getting a lot of praise for my drawings when I was little, but lately I’ve begun to notice that adults praise any mark a child puts to paper.  Was the foundation of my self-worth built upon patronizing indulgence?

Psychology researcher Viktor Lowenfeld mapped out childhood drawing development into stages by age.  Here’s a page illustrating some of the stages and here’s a great comparison between his stages and those of Betty Edwards of Drawing on the Right Side of the Brain fame.

Lucky for my inflated ego, 5-year old me falls comfortably ahead of the curve.  The ground is defined as a flat line, and there’s a clear spacial relationship between objects.  Colors reflect the real world, especially when you take into account the limited Crayola palette.  This places 5-year-old me firmly in the Schematic stage of development, usually see at 7 to 9 years.

I should stop congratulating myself long enough to note that in this stage, size often reflects emphasis or importance.  The barn is much larger in this picture than in real life, and the stick figures are small and deemphasized.  Did the barn stand out in my mind simply because I spent most of my time in the back yard, or was it because that’s where my dad kept cool things like the sledge hammer and gas for the lawnmower?  Are the people small and anonymous to fit the window spaces, or do they reflect some lack of social development?

Sphere: Related Content

When graphics lie

Sunday, December 16th, 2007

The Cleveland Plain Dealer ran a story today about the origin of guns used in crimes in the city. This is an issue that people are concerned about and it deserves coverage. Rather than present information about gun laws in various states and numbers of crime gun recovered as a boring list, the PD provided a helpful infographic.

Maps and bar charts can be really useful tools to help people make sense of information. But look closely and you’ll see a problem - the bar chart showing the relative number of crime guns recovered is wrong:

pd-chart-error

At first glance it looks like about as many guns are recovered from Cleveland as from Cincinatti and Columbus. But the Cleveland number is really about 65% of the Columbus number.

This is probably just an error, akin to misspelling someone’s name in an article. But it’s a good example of a bad graphic, sometimes called chartjunk. Ignoring the error, a bar chart like this might conceal more than it conveys. The top three cities are much larger than the rest, so wouldn’t we expect them to have more guns seized? Maybe a measure per 1000 persons would be better. We also need to think about what this chart implies to readers - is a higher number worse, because it correlates to more crimes, or better, because it means police departments are doing a good job of taking guns off the streets?

If you’re interested in reading more about how to design good graphics and communicate large amounts of data effectively, take a look at the books of Edward Tufte.

Sphere: Related Content

The importance of design - Can you read this at 60 MPH?

Tuesday, November 27th, 2007

The New York Times had a great article a few months ago about redesigning the font used on highway signs.  You’ve probably seen the current font, Highway Gothic, a million times without ever thinking about it - it’s been in use for more than 50 years.

Granphic from the New York TimesWorrying about the font on the signs seems pretty silly compared to all the engineering and resources that go into a single bridge, let alone the entire highway system.  Why does this merit an article in the Times and what does this have to do with programing, web development, social software, or any of the topics many visitors to this blog are interested in?

Programmers and analysts sometimes doubt the value of design.  It’s hard work gathering all the requirements and writing all the code - we don’t have time to worry about how pretty it looks.  A lot of projects we work on, though, involve creating user interfaces, often web applications.  That means that, when it comes down to it, your job is to support the user’s tasks.

Now if someone wanted to add 10% to your hours to pick just the right shade of chartruse, you would be justifiably miffed.  But good interface designers will have good, empirically-tested reasons for their work and the guidelines they live by.  Highway signs are a great example of this kind of empirical benefit:

Intrigued by the early positive results, the researchers took the prototype out onto the test track. Drivers recruited from the nearby town of State College drove around the mock highway. From the back seat, Pietrucha and Garvey recorded at what distance the subjects could read a pair of highway signs, one printed in Highway Gothic and the other in Clearview. Researchers from 3M came up with the text, made-up names like Dorset and Conyer ? words that were easy to read. In nighttime tests, Clearview showed a 16 percent improvement in recognition over Highway Gothic, meaning drivers traveling at 60 miles per hour would have an extra one to two seconds to make a decision.

A one or two second gain in legibility matters a lot when your life depends on it.  Few web applications present the same kind of physical danger, but multiply a small gain over an application with 10,000 users, operating 24 hours a day for a year, and you can see how this can impact the business.  Good design is part of the larger concept of usability.  As anyone who’s done any usability testing can tell you, most applications have many small, easy-to-change pitfalls that can quickly add up to huge wastes of time and effort.

Sphere: Related Content

Data Visualization with Maps

Monday, June 11th, 2007

One of the best ways to show relationships in data is also one of the oldest: maps. There are lots of cool, fun visualizations out there like topic maps and tag clouds, but sometimes they emphasize form over function (and usability). Maps can be a great choice, even if your data is not directly geographical.

Here’s one example: a map of the United States showing where people use the terms “soda,” “pop,” or “coke.”

You might think this one was a pretty obvious choice, but you could definitely imagine someone using a pie chart to show the total percentages instead, throwing out a ton of information in the process.

Here’s one that’s a little more clever: a map of the United States, which each state labeled by a country with the same GDP. from strange maps.

states-gdp.png

Now, you could argue with the precision of presentation since most people don’t know the exact GDP of Algeria off the top of their heads. But show them a table of figures and ten minutes later they still won’t know. This is a much more interesting and memorable presentation of the data.

Sphere: Related Content

Formal usability testing with eye tracking - Mealographer

Monday, May 15th, 2006

Usability Testing

Usability tests can be seen to fall into two general categories, based on their aim: tests which aim to find usability problems with a specific site, and tests which aim to prove or disprove a hypothesis. This test would fall into the former category. A search of the literature will reveal that tests looking to uncover specific usability problems often use a very small number of participants, coming from Nielsen’s (2000) conclusion that five users is enough to find 85 percent of all usability problems. Nielsen derived this formula from earlier work (Nielsen and Landauer, 1993). Although there is much disagreement (Spool and Schroeder, 2001), this rule of thumb has the advantage of fitting the time and money budget of many projects.

Use of Eye-Tracking Data

In terms of raw data, eye tracking produces an embarrassment of riches. A text export of one test of Mealographer yielded roughly 25 megabytes of data. There are a number of different ways eye tracking data can be interpreted, and the measures can be grouped into measures of search and measures of processing or concentration (Goldberg and Kotval, 1999):

Measures of search:

  • Scan path length and duration
  • Convex hull area, for example the size of a circle enclosing the scan path
  • Spatial density of the scan path.
  • Transition matrix, or the number of movements between two areas of interest
  • Number of saccades, or sizable eye movements between fixations
  • Saccadic amplitude

Measures of processing:

  • Number of Fixations
  • Fixation duration
  • Fixation/saccade ratio

In general, longer, less direct scan paths indicate poor representation (such as bad label text) and confusing layout, and a higher number of fixations and longer fixation duration may indicate that users are having a hard time extracting the information they need (Renshaw, Finlay, Tyfa, and Ward, 2004). Usability studies employing eye tracking data may employ measures that are context-independent such as fixations, fixation durations, total dwell times, and saccadic amplitudes as well as screen position-dependent measures such as dwell time within areas of interest (Goldberg, Stimson, Lewenstein, Scott, and Wichansky, 2002).

Because of the time frame of this investigation, the nature of the study tasks, and the researcher’s inexperience with eye tracking hardware and software, eye tracking data was compiled into “heat maps” based on the number and distribution of fixations. These heat maps are interpreted as a qualitative measure.

Methods

The goal of the study is to evaluate the usability of the web site and identify problem areas that might be improved.

Participants were solicited from a population of Kent State University graduate students in the School of Library Science (SLIS) and the Information Architecture Knowledge Management (IAKM) program via email. Five students volunteered, although one dropped out of the study at the last minute. Participants ranged in age from 25 to 35 with half female, half male. All had more than five years experience using computers and the web.

Participants were invited to the SLIS usability lab where they were informed of the procedure and asked for their consent. Once demographic data was collected, participants were calibrated on the eye tracking system and then asked to complete eight tasks using the web site. Participants were encouraged to “think out loud” while they attempted to complete each task, and their comments were recorded. Interaction with the web site was recorded by screen capture software and an unobtrusive eye-tracking device. Finally, participants were asked to fill out a short survey gaging their opinion of the site and it’s usability. Participants were free to stop at any time, and no incentive was offered for participation other than the opportunity to see the new lab and equipment.

Quantitative measures of usability include task completion, time required for task completion, and number of steps to completion. Participant comments and eye tracking data are used as qualitative measures.

Testing Difficulties

During the course of testing a number of problems arose with the eye tracking software, ClearView. At the conclusion of one of the four tests, the software locked up, making the computer unresponsive. Eventually it crashed, losing all test data for that participant. Consultation with a faculty familiar with the software confirmed that this is an unpredictable, but common bug in ClearView with no known workaround.

In addition, a deficiency was discovered in ClearView’s scanpath and hot spot visualization tools. Both overlay fixation data on top of screen shots of the web page the user was viewing. Unfortunately, the screen shots are not taken as the participant proceeds through each task. Instead the software remembers the URL of each page and then retrieves the screen shot at a later time. Many pages in Mealographer (and virtually any non-trivial web application) look different depending on whether or not a user is logged in, what the user has submitted in a form, and the presence or absence of cookies for session information. Therefore, many of the hot spot maps are laid over a version of the page dissimilar to what the participant had actually seen.

Findings

Task Completion Analysis

Overall, participants were able to complete the tasks 70% of the time. For the purpose of this evaluation, a task is considered complete only when the participant has found and used the expected feature for each task – often times, users were satisfied with their outcome, even though they had not used the most appropriate features. For example, two participants approached Task 1A by searching for a food they already knew was high in protein and low in fat, instead of finding and using the Healthy Food Search form. Table 1 displays the task list and completion rates. The tasks with the lowest completion rate were 1B, 6B, 7 and 8. It is interesting to note that the best-performing tasks include food search, meal entry, and user account functionality, which are the top items seen on the homepage when not logged it. This may be an indication of poor discoverability.

In general, the task completion rate indicates plenty of room for improvement.

Task Completion Rate 1. A. Think of a food that you like. Use this website to find out how much protein is in that food. 4/4
1. B. Try to find a food that is high and protein but low in fat. 1/4
2. Please find your way back to the Mealographer homepage without using the browser’s Back button. 4/4
3. Use this website to figure out how much fat and fiber you had at lunch today. 3/4
4. Sign up for an account. 4/4
5. Now that you have an account, please enter in what you had for breakfast today. How many calories did you have at breakfast? 4/4
6. A. Did you have more Calories at breakfast or lunch today? Find a way to figure this out. 3/4
6. B. Let’s say that you wanted to see a summary of your nutrition each day this week. Try to find a report that shows a week’s worth of information and look up your calcium intake. 2/4
7. Let’s say you wanted to try to have more than 25 grams of fiber each day. What’s the best way to make sure that you are with this web site? 2/4
8. If you were going to use this web site often, what would you do to make entering meals easier? If you can think of something, go ahead and do it. 1/4
Total 70%

Table 1: Task Completion

 

Completed Tasks

Incomplete Tasks

Number (recorded) 19 11
Average Time 1:56 2:37
Average Path Length 3.79 6.27

Table 2: Task Completion vs Performance Measures

 

Note that for the three participants with recorded times per task and path lengths, completed tasks took less time and involved a shorter path (see Table 2). This is logical, but with only three participants the correlation is not significant.

Individual completion rates, average times per task, and average path lengths are given in Table 3 along with user ratings of the site from the post-test questionnaire. It is interesting to note that user performance on task does not seem to correlate with user ratings (although with so few participants, correlations would not be statistically significant). The user with the highest completion rate gave the site the lowest ease of use score and lowest score overall, while the highest rating was given by a participant in the middle of the field for each performance measure.

Overall, the user ratings of the site were positive, but not outstanding. Although the ratings don’t correlate to the measures, many of the specific usability problems noted later in this report were noticed by the participants themselves as they used the site. Presumably changes to correct these problems would result in higher ratings.

Participant Completion Rate Avg Time per Task Avg Path Length Organization Rating Ease of Use Rating Design Rating
1 4/10 1:33 2.9 4 4 3
2 6/10 3:35 8.0 3 3 4
3 10/10 - 3 3 3
4 8/10 1:36 3.2 4 5 4
Total 70% 2:15 3.7 3.5 3.75 3.5

Table 3: Participant Performance and Site Ratings

 

Table 4 shows the task time and path length for each recorded participant broken down by task. Except for tasks 2 and 8, target path lengths for each task were set to the smallest path that would achieve the goal plus one, and target task times were set somewhat arbitrarily to 2 minutes. Task 2 was much simpler than the other tasks and task 8 was open-ended, allowing participants to enter favorites, usuals, or both. It is difficult to set a task time goal for an interactive web site without data from previous tests. The amount of time a user might want to spend on a particular activity before becoming frustrated or giving up may very based on a number of factors including user motivation, user enjoyment, and web site stickiness. The target of two minutes was chosen because it was thought to be fairly aggressive, meeting the goal of the project to make diet tracking quick and easy.

 

Participant 1 Participant 2 Participant 4 Average Target
Task Time Path Time Path Time Path Time Path Time Path
1. A. 1:10 3 1:55 4 1:33 4 1:33 3.67 2:00 3
1. B. 0:38 1 1:29 4 1:11 2 1:06 2.33 2:00 3
2. 0:08 2 0:17 2 0:17 2 0:14 2 0:30 2
3. 1:56 3 4:35 3 2:17 4 2:56 3.33 2:00 4
4. 1:18 4 1:19 4 1:56 5 1:31 4.33 2:00 4
5. 1:25 3 4:56 3 2:53 3 3:05 3 2:00 4
6. A. 1:51 3 5:26 14 1:52 4 3:03 7 2:00 3
6. B. 1:23 3 5:59 15 0:36 1 2:39 6.33 2:00 2
7. 1:16 4 3:29 8 1:30 3 2:05 5 2:00 5
8. 2:48 3 6:20 23 1:58 4 3:42 10 - -
Total 13:53 29 35:45 80 16:03 32

Table 4: Performance Measures by Participant

 

Items in Table 4 in bold denote tasks in which a participant had not met the target, and those with gray backgrounds represent successfully completed tasks. Looking at average performance, only tasks 1B and 2 completely met all objectives. It would be reasonable to look for specific usability problems in the tasks for which each participant missed one or more target, and many are addressed in the Specific Usability Problems section below.

Hot Spot Analysis

In Illustrations 5, 6, and 7, hot spot maps of the Mealographer home page are shown for three participants (one, two and four, respectively). These images show the relative number of fixations by color, with green meaning at least one fixation and red meaning three or more, with fixations length set to a maximum of 100ms.

 

Hot spot map for Mealographer user 1

Illustration 5: Hot spot map for participant 1

Hot spot map for Mealographer user 2

Illustration 6: Hot spot map for participant 2

Hot spot map for Mealographer user 4

Illustration 7: Hot spot map for participant 4

These hot spot maps illustrate some of the observations that can be made with eye tracking that might be missed by other usability testing methods. For example, participant one did not read the light blue help boxes at the bottom of the page whereas two and four did. The participants fixated on many of the red “* required” labels, but only briefly - this may mean that they served their purpose in alerting users without causing confusion or additional concentration. Note the large red areas under the drop-down boxes for “Month” and “Question.” Users had to fixate more on these controls than on many of the text fields.

Scanpath of user 1 looking for Coffee

Illustration 8: Scanpath for participant searching for “coffee”

Scanpath of an expert user looking for Tea

Illustration 9: Scanpath for expert searching for “tea”

Scanpath of user 4 looking for Coffee

Illustration 10: Scanpath for participant searching for “coffee”

Scanpath Analysis

The scanpaths in Ilustrations 8, 9 and 10 show the result of users entering in a search term on the meal entry form and searching for the proper item to add to their meal. The two on the left represent searches for “coffee” by two participants, novice users of the site. The one on the right is a search for “tea” by the researcher, and can be considered an example of expert use. Note that the paths of both novice users are both much longer than the expert, and that the convex hull area would be larger as well, despite the fact that the desired item is located in a similar position on all three. The novices need to gaze at each item on the list in order, and require more gazes on likely items in order to make a decision. In all three cases, the long, spread out gaze paths indicate that desired items are not near the top of the results, and are not readily apparent. Improvements should be made to the search engine and the results display, perhaps highlighting search terms within each line.

Specific Usability Problems

A list of specific usability problems has been compiled from the participant performance results in Table 4, observations made during the test by the researcher, and participant comments. Problems are organized by task.

Task 1A – Food search

Search results do not always match user expectations. Multiple participants expresses confusion or had to refine their search to get to the food they were looking for. As the tagging system grows, it will help to address this issue.

Search results are hard to scan. Participants seemed lost in all the text in the results. This can be addressed by highlighting the search terms within the results and visually dividing items from each other.

The ordering of nutrients on food pages might not be intuitive. The food pages were designed to match the ordering used on product packages, but some users needed extra time to find what they were looking for. One participant said she expected them to be in alphabetical order.

Task 1B – Healthy food search

Users did not notice the healthy food search function at first. Three users tried using the food search to search for a food they already knew was high in protein and low in fat, at least at first, and another was satisfied with the food he had just searched for by name. The healthy food search could be given more prominent placement, perhaps above the scroll on the search results page.

Task 3 – Meal entry using the quick form on the homepage

One user did not find the meal form on the homepage. Participant 1 used the food search instead, explaining that she had only had one thing to eat. Since the other found the form easily, action might not be needed to correct this.

Results for each food entered in the form do not match user expectations. One participant, for example, entered “rice” but did not find plain rice in the dropdown on the next page. This is another search engine difficulty.

Users could have refined their terms, but did not see a way to do so. In fact they would have had to go back to the homepage and submit the new terms. An entry box could be added to the results page to allow users to refine their terms.

Some users left some fields blank, and did not get useful results. One user left all the “Units” fields blank and the results showed a meal with no nutrition. It took some time for that user to figure out the cause of the problem. Validation hints could be added to the form, and units could default to one instead of blank or zero.

Task 4 – Account creation

Meals entered by visitors could be lost if they do not go directly to create a new account. One user missed the link to create an account from the meal page and went to the homepage first. This is a perfectly valid action. The ID of the temporary meal record in the database should be associated with the user session so visitors do not have to re-enter meals later.

Task 5 – Meal entry

It is not immediately clear how to use the meal entry form. Three users tried to click on the notepad at first, expecting it to work similarly to the quick meal form. Although both did figure out to use the search form to find and then add items, this could be improved. Currently when the form first loads, the search results frame is blank. An arrow graphic and some explanatory text might make use of this form more clear. It might also make sense to have only one meal entry form, mixing the strengths of each.

Users did not always try to modify search terms to improve results. At least one user suggested good modifiers when thinking out loud, but did not try any of them. There is text in the results that suggest trying again, but it could be made more clear.

Food search results were difficult to scan. Participants seemed to take a long time finding the item they wanted on the list (see Illustrations 8, 9, and 10 for scanpath diagrams). One participant suggested adding bullet points to better mark items in the list. Search terms could also be highlighted in the results.

Users are not sure how to enter complex or compound food items. One user tried “salad” and “caesar salad” but compound items with many variable ingredients like salads and sandwiches are left out of the database. Some instructions could be added. This might also be solved by the addition of a food or recipe entry system.

Some users left some fields blank, and did not get useful results. Like the quick meal form, validation hints could be added to the form.

Task 6A – Use of daily report

Some users didn’t think to look for a report system. Three users used pen and paper to compare meal totals instead, although two did later find the daily reports. The existence and functionality of the reports could perhaps be made more clear, and additional links might make the reports more discoverable.

Reports (and many other sections of the site) are not identifiable from browser history.

Participant 2 had a particularly difficult time finding the reports using the browser’s history function. Page titles were very similar, and he tried nine different links before trying another tactic. This is important because it means many pages would not make good bookmarks either. Better, more succinct page titles need to be used on interactive pages.

Reports cannot be accessed when not logged in. In the course of using the browser history, participant 2 accidentally logged himself out without noticing. This made it almost impossible to find the reports, and when he did find the reports they did not have any data. Care was taken to ensure users could not alter other users data, or make entries without logging in, but dynamic pages such as the reports should clearly remind users to log back in rather than displaying zeros. Once that is done links to the reports could be added to the tour page.

Task 6B – Use of weekly report

Users were not immediately aware of the weekly report. The control to switch to the weekly report is located below the scroll on the report page. It could be moved up or a simpler control could be added to the top of the page.

Task 7 – Goal creation

Users did not think to look for goal-setting functionality. Two users reported being happy just using the reports to track progress, though one later did find the goal functionality. Another user overlooked the link to create a goal at least once before finding it. Goals should be better integrated into the report pages.

The list of goals was confusing when no goals were listed. A new user looking at the list before entering sees the column headings but no indication that this is list with zero items. The list should not appear when no goals exist.

Some terms are unfamiliar to users. One participant did not know what “DRI” and “Daily Value” meant when entering a goal. Tooltips or links to a FAQ could be used to help inform users.

Task 8 – Use of usuals and/or favorites

The list of favorites was confusing when no favorites were listed. This is also true for usuals. The list should not appear when no favorites exist.

Favorites and usuals were not discovered by most participants. Three participants either did not think to look for such options or did notice them while using the site. Favorites and usuals need to be better integrated into the rest of the site. It might be helpful to indicate existence of favorites on meal page, even if user has no favorites. Also, an “add this food to my favorites” link could be added to food pages.

 

 

 

References Cited

 

Gibson, J. J. (1979). The Ecological Approach to Visual Perception. Hillsdale, NJ:Lawrence Erlbaum Associates.

 

Goldberg, J.H., Kotval, X.P., (1999). Computer interface evaluation using eye movements: methods and constructs. International Journal Of Industrial Ergonomics 24, 631–645.

 

Goldberg, J.H., Stimson, M.J., Lewenstein, M., Scott, N., Wichansky, A.M. (2002). Eye Tracking in Web Search Tasks: Design Implications. Proceedings of the 2002 symposium on Eye tracking research & applications. New York: ACM Press. pp. 51-58.

 

Golder, Scott A., Huberman, Bernardo A. (2006). Usage patterns of collaborative tagging systems.

Journal of Information Science, Vol: 32, Issue: 2, April 2006, pp. 198-208

 

Lindgaard, Gitte, Fernandes, Gary, Dudek, Cathy, and Browñ, J. (2006).

Attention web designers: You have 50 milliseconds to make a good first impression. Behaviour and Information Technology, Volume 25, Number 2, Number 2/March-April 2006, pp. 115-126(12).

 

Nielsen, Jakob. (2000). Why You Only Need to Test With 5 Users. Alertbox March 19, 2000. Retrieved May 15, 2006, from http://www.useit.com/alertbox/20000319.html

 

Nielsen, Jakob and Landauer, Thomas K. (1993). A mathematical model of the finding of usability problems. Proceedings of the SIGCHI conference on Human factors in computing systems. April 24-29, 1993, Amsterdam, The Netherlands. pp. 206-213.

 

Norman, Don. (2004). Affordances and Design. Don Norman’s jnd.org. Retrieved May 15, 2006, from http://www.jnd.org/dn.mss/affordances_and.html

 

Renshaw, J.A., Finlay, J.E., Tyfa, D., Ward, R.D. (2004). Understanding visual influence in graph design through temporal and spatial eye movement characteristics. Interacting with Computers. Vol: 16, Issue: 3, June, 2004. pp. 557-578.

 

Spool, J. and Schroeder, W. (2001). Testing Websites : Five Users is Nowhere Near Enough. CHI ‘01 extended abstracts on Human factors in computing systems. New York: ACM Press. pp. 285-286.

 

Stafford, Tom and Webb, Matt. (2005). Mind Hacks: Tips and Tools for Using Your Brain. Sebastopol, CA:O’Reilly Media, Inc.

 

 

 

Sphere: Related Content

Project report - Mealographer

Wednesday, May 10th, 2006

Abstract

Diet can have a great effect on health, but few people keep track of what they eat each day, let alone how much fat, protein, Calcium, or other nutrients. Although most food items have nutrition information printed on the packaging, few people can tell you whether or not the 10 grams of fat in their candy bar is acceptable, or whether it has put them over the edge.

In this project the author assumes that a big part of the reason people do not keep track of their diet is that there is no easy way to do so. The final product of this project is Mealographer, a simple interface that allows users to enter in the foods and meals they eat each day, set simple nutrition goals, and see reports of their progress. Mealographer was created by implementing a large number of improvements to the product of a previous investigation, WhatYouEat. A usability test was conducted to evaluate Mealographer and find specific usability problems.

Previous Work – The WhatYouEat Project

Mealographer inherits much of its functionality from a previous project, titled WhatYouEat, part of an individual investigation from fall, 2005. The original project had two goals: to create an application that allows users to track their dietary intake, and to make the application as easy to use as possible.

WhatYouEat allowed users to record their meals, set simple goals for different nutrients, and

track their diet through simple reports. Supporting functionality included a simple user sign up and login system, and systems allowing users to indicate favorite foods and “usuals” – foods eaten on a regular basis.

WhatYouEat was demonstrated informally to several groups and an informal usability test was run with four participants. Although this style of evaluation was not rigorous, users were asked to use the site and comment on any confusion or difficulties. Many users also commented on design and additional functionality. Usability issues included difficulty in:

Targeting

  • Even with a large screen size and large font, it was hard for one subject to click on fields before entering text.
  • Field labels were used to enlarge the clickable area. It may be possible to have the cursor will default to the first field.

Layout

  • Two users were a little confused about the two-column layout of input forms.
  • A thin line was added to help make the grid more clear.

Forms

  • Three users forgot to set the meal date at least once. The submit button was easy to miss. One user hit enter to submit the search form and didn’t expect the entire meal to be submitted. There were problems using the back button.
  • The submit button was made more visible
  • The forms were be broken up so that the submit button for a particular field only submits that field.
  • Required fields could be made more clear with a symbol and some JavaScript.

Labeling

  • Some labels were unclear or hard to read. In particular, dates presented in yyyy-mm-dd format and names of nutrients.
  • The labels should be changed to reflect user expectations.

Measurements

  • Many users had a hard time determining how much they had eaten, or understanding how much food each measurement amount actually represented. Few of them knew what an ounce or gram of a given food looked like, or how much of non-fluid items made up a cup.
  • Some graphic representation of food amounts should be available in the system, as well as a conversion application. See Future Plans for more information on the approach to this problem.

Missing items

  • Users more than once looked for food items that did not appear to be in the database at all. This included brand-name items or items from specific restaurants. This is a limitation for the USDA database.
  • There is no simple or quick solution to this problem. See Future Plans for more information on the approach to this problem.

Mealographer Features and Functionality

Mealogapher includes a number of improvements to the existing WhatYouEat functionality as well as some additional features. Major new and improved features include:

Information Design

WhatYouEat had simple, somewhat consistent design that did not convey much information about the content of each page. Mealographer was designed to

Action blocks – on each page where a series of actions are appropriate next steps, those actions are placed in a lighter-colored box with a descriptive title.

Simple icons – small icons are used throughout the site to quickly convey small bits of information. For example, purple arrows replace list bullets on action items in blocks. The Calendar employs icons to indicate whether or not a goal has been met.

Nutrition information – The nutrition information for foods and meal totals has been designed to match the familiar nutrition information boxes on foods.

Link highlighting – Many links, including the navigation bar and action items, have been given a highlight when the user’s mouse hovers over.

Language

Care was taken to make the verbiage used on the site straightforward, concise, consistent, and in line with the site’s brand. For example, when users are presented with options they are asked, “would you like to… Add another item to your usuals.” Users are addressed directly by the site, and not given static items like “Add usuals,” or “My usuals.”

Home Page

The homepage has been redesigned to be a central gateway, allowing easy access to site features, as well as an introduction to the site. The homepage has two different configurations: a “general public” version for site visitors and new users that have not yet logged in, and a “personal” version for logged-in users.

Public Homepage

The general public homepage was created with two goals in mind: first, to introduce new users to the site; and second, to intrigue and draw them in by giving them features to try out. The first goal makes sense since new users must know what the site does if they are to ever use it. The second goal was inspired by the fact that when presented with a choice, people generally chose to stay with the status quo (Stafford & Webb, 2005, p. 246). The status quo in effect when a user reaches a new, possibly complex web application for the first time is simple—do nothing. Mealographer presents an additional challenge, because most people do not actively track their diets. Using a diet-tracking site will be a big divergence from the status quo for many new users.

Mealographer user interface screenshot

Illustration 1: Public home page

The public homepage is intended to break visitors out of the status quo by giving them a simple, quick way to try the site out. The interface must be immediately apparent because users can make decisions about web designs in as little as 50 ms (Lindgaard, Fernandes, Dudek, and Brown, 2006). The way to make it apparent that a user can interact with a site is by presenting clear affordances, or visual impressions that imply likely use (Gibson, 1979, p.127). Cultural, learned conventions can be used to help users perceive affordances on a computer screen (Norman, 2004).

Visitors are presented with two elements to try. The first is the “What did you eat today?” quick meal entry form, which allows users to begin using the site’s functionality with as little investment of time and effort as possible. The second is a “Search for a food” form that acts as a simple search engine. In order to take advantage of cultural conventions, a multi-line text area was chosen to allow visitors to type in items they’ve eaten, and a single-line text input was used for the food search.

Personal Homepage

The personal homepage both acts as a central location for registered users to find and discover functionality and a top-level view of the actions they are most likely to want to do at the current time. Entering meals and watching diet changes are both activities with strong temporal dimensions. Accordingly, a daily “to do” calendar was chosen as the metaphor for the list of meals entered and yet to be entered, and a monthly calendar is used to display a high level view of progress. Both employ simple visual cues to give users an immediate impression. Completed activities are marked off the to do list with check marks, and smiling or frowning faces are displayed on the days of the monthly calendar to show if a goal has been met for each day.

Mealographer user interface screenshot

Illustration 2: Personal home page

The rest of the items on the personal homepage are organized into the action blocks “Connect to People,” “More Options,” “Goals and Reports,” and “Foods and Facts.”

Food Pages

Nutrition information about the food items in the database was used to generate a detailed page for each food. The pages include the nutrition information box, a food search form, and links to other similar foods in the database. They serve three purposes: first, users can search for and find information about a specific food. Second, the pages can be linked to from multiple locations in the site, wherever users might see a food name and want additional information. Third, the pages would be available to outside search engines, and might therefore act as landing pages for visitors and new users.

Mealographer user interface screenshot

Illustration 3: Example food page

Although the information is from the database, these pages are not dynamic. Instead, static HTML pages are generated from the database and then saved and uploaded to the web host. Nutrition information is unlikely to change, so this technique saves web server processing time and database access.

Food Search and Folksonomies

One of the most apparent usability problems of WhatYouEat was the food search. Food search is a standalone function and is an inherent part of meal entry, so it is critical that it be improved. Problems stem from three main areas:

Missing items – although the USDA database contains thousands of foods, it is missing many items users are looking for. Many brand-name items are not in the list, as well as ethnic foods and composite foods (there is no general entry for “sandwich” or “salad”). Possible fixes to this problem include searching for and entering new foods, allowing users to enter new foods, and allowing users to build recipes from multiple foods. None of these options were implemented in this time frame.

Naming and Labeling – the USDA database uses very precise names for many foods. These names are very useful for professionals, but do not match language used by typical users. For example, a user might search for “Coke,” when the database has “Carbonated beverage, cola, contains caffeine.” The solution to this problem implemented in Mealographer is a behind-the-scenes tagging system to build up a folksonomy for foods. Tagging systems can allow for both majority consensus on labels or search terms while maintaining minority opinions as well, and allow sites to harness information entered by users for personal use for wider benefit (Golder and Huberman 2006).

The tagging system implemented in Mealographer does not directly ask users for keywords for each food—that would be an extra step, and it is hard to see the immediate benefit a user would receive for their tagging work. Instead, as users perform searches, the system silently remembers the keywords used and the food ultimately chosen and builds tags automatically. A robust tag set requires many users, so it may be difficult to judge the value of the tagging system at this time.

Technical Limitations – by default, the search engine included in MySQL uses a fairly simple search engine which does not meet high expectations users have gained from using advanced engines like Google. In addition, the MySQL full text search ignores all works three characters or less. This can be useful in screening out words like “and” or “for,” but is less helpful when a user searches for “Big Mac.” As the folksonomy grows and tags are added, these limitations might become less important.

Healthy Food Search

In addition to searching for foods by keyword, an interface was created to allow users to search for foods by nutrient content. For example, a user can search for foods that are high in protein, or low in fat and high in fiber. Users may also filter by food group.

New User Invitations

A simple interfaces has been added to allow current users to send invitations to others via email.

Navigation