Category Archives: Writing

Academic Papers Artwork baby names Blog blogging democracy Design ethics Facebook firefox Flickr folksonomies Google Google Docs Google Spreadsheets how-to information-architecture information-retrieval information design internet iphone journalism listserv mailing list maps mass media Online News Papers Photography plugin poll social-bookmarking social networking social software spam tagging trust Twitter Usability web-development Web2.0 webspam web standards WordPress Writing

Tagging and Searching: Search Retrieval Effectiveness of Folkonsomies on the World Wide Web

To complete my MS in Information Architecture and Knowledge Management at Kent State I did some research on folksonomies and how the can support information retrieval.  I compared social bookmarking systems with search engines and directories.  I’m hoping to see the results published in an academic journal.   In the mean time, you can see a pre-publication copy of my results:

Tagging and searching [pdf, 989K]

Formal usability testing with eye tracking – Mealographer

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.

Continue reading

Project report – Mealographer


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:


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


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


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


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


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

Continue reading