JasonMorrison.net

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.

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.

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.

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?

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:

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.

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.

Worrying 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.

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.

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.

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.

(more…)

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.

(more…)

Visualizing the web

Although web technologies are constantly changing, most users still browse the web the same way they did back in 1995–typing keywords into search boxes, clicking from home page, to section, to subsection on a navigation bar, or following link, to link, to link. The fact that it is called a “web” suggests that there should be other ways of navigating websites, and there are a number of projects attempting to employ information visualizations and spatial maps to do so.

All web pages organize information visually, but “information visualization centers around helping people explore or explain data that is not inherently spatial, such as that from the domains of bioinformatics, data mining and databases, finance and commerce, telecommunications and networking, information retrieval from large text corpora, software, and computer-supported cooperative work.” (“InfoVis 2003 Symposium”) Spatial metaphors are used to communicate different levels of information. A simple, static example would be a personal homepage built to look like the designers home, with links to favorite movies in the living room and recipes in the kitchen. A more advanced example would be a customer relationship management system for a large company which instead of presenting a list of technical support problems and solutions, displays an interactive map of problems, with more common problems in a larger font size, and recent problems in red. In both cases, users get an immediate grasp of complex information.

Such visualizations are intended to help solve two current web usability problems: the lack of a wide view to web structure, and the lack of query refinement based on relationships of retrieved pages (Ohwada 548). But they must do so without creating additional usability barriers. This paper will describe three current information visualization projects and describe some of the usability issues these sorts of projects face.

(more…)