JasonMorrison.net

When designing a user interface or doing a usability review of an existing website, simplicity is an extremely important goal. When I get to your interface, don’t force me to spend time thinking. Make it easy for me to do what I want to do.

Here’s a perfect example: ever wish you had remote controls that looked like this?

Like anything else, though, don’t take the drive for simplicity and turn it into an inflexible dogma. Make sure your UI simplification efforts stop before your interface is:

… so simple it doesn’t give users any cues. This is a classic Web2.0 sandtrap – yes, your site looks very modern and clean with one giant button, but what does the button do?

… so simple it doesn’t do what the user wants. Here’s a great example of oversimplification from Tim and Eric Awesome Show:

It’s great – users have expressed frustration in getting calls when they’re at dinner or trying to enjoy a relaxing round of golf – so they’ve taken away the ability to get incoming call. Problem solved.

… so simple that important efficiency gains are lost, requiring users to expend repetitive manual effort. The Cinco Fone example above fits this one as well, but here’s another fun satire from the Onion News Network about the Macbook Wheel:

I’d love to hear any example of websites that you think might be committing one of the three sins of over-simplicity, please add a comment below.

Also, ff the title of this post is familiar, it’s because it’s based on a quote often attributed to Albert Einstein. The actual quote is:

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

An apology to anyone who got an unwanted invite to social networking site Bebo.

I tend to join and try out a lot of social apps as I run into them. I was signing up for Bebo when I got to the part of the process where you add friends to your account. First I saw the section I wanted, “Friends found on Bebo who are in your address book:”

Next, there’s a section, “Friends of friends on Bebo who you MAY know:” I started down this list but noticed many duplicates from the first list. Normally this kind of duplication is a minor usability issue, since it wastes some screen real estate and a small amount of user attention. But in this case the duplicates were so prevalent I scrolled back to the top and clicked the “Add Friends” button.

Had I kept scrolling, I would have seen the “Invite friends to Bebo from your address book:” section with every email address checked by default.

Every social networking site has a feature like this, and it fuels the exponential growth that some of these sites experience. But sending an in-site friend invite is very different from sending a email invite. Most of us have email contacts who fall into various categories – friends, co-workers, people we’ve bought stuff from, former bosses, friends’ parents, etc. Very few people would want to actually send out invites to every single email address in their address book, so that should never be the default behavior.

So, yeah, sorry for the Bebo invite spam.

In other news, I just sent out over 3300 emails to people who voted in the baby name poll and left their email address.

I have a little project called Localographer, which you can use to create heat maps and find a house or apartment near your workplace, friends and relatives, or other place you’d like to be.  When I showed it to my brother he tried mapping out places in Boston and ran into a limitation – the interface doesn’t show you various transit options and it doesn’t make it easy to figure out the real cost and benefits of living in different places.

If you move to the suburbs, you might be able to commute by car but living by a train stop can be cheaper and easier.  In some neighborhoods you can get 10 different kinds of food in a 10 minute walk, in others you need to get in your car and drive a quarter mile to get anything to eat at all.

Adding features like this to Localographer means solving two problems – data and user interface.  I don’t have access to restaurant locations, transit stops, etc. and that sort of data can be expensive to get from commercial sources.  I could go the wiki route but that would require building an interface for users to contribute data and finding ways to make the data more reliable.

So in the mean time, if you want to get an idea of how walkable a potential neighborhood might be, take a look at Walk Score.  It’s a very cool site which has some of the features I’ve been meaning to add to Localographer – you can get a score for how livable the area around any address might be.

For example, my current neighborhood in California has a score of 74 out of 100.   Our house in Shaker Heights scores 62 out of 100.  Because any excuse is a good excuse to use a spreadsheet and a graph, I’ve plotted out the walkability of all the places I’ve lived using a Google Docs spreadsheet and the Interactive Time Series Gadget.  I wrote earlier about how you can embed any Google Doc or Spreadsheet into a blog post but Gadgets are even easier – just click the “Publish” button on the gadget and paste the Javascript code in the raw HTML view of your blogging software.

There are some issues with Walk Score, of course – for example Naples, Florida scores very high, but when I lived there I really missed having access to a car.  Most of the restaurants and shops along 5th Street and Tamiami Trail were out of my internship-funded price range.  I used to bike some distance to get to The Clock, a cheap diner.

All of this discussion is pointing toward a much larger question that I have been thinking about for a long time – I know how to study the usability of web sites and other software, but I wonder if anyone does usability studies of urban planning?  I’ve seen traffic flow studies and I know building codes have some basis in ergonomics and accessibility, but does anyone do observational studies of how people interact with different urban environments to figure out what works and what doesn’t?  Is there a Fitt’s Law of where to locate grocery stores compared to condos?

Marchionini, G., & Komllodi, A.  (1998). Design of interfaces for information seeking. Annual Review of Information Science and Technology (ARIST), 21, 89-130.

In this chapter Marchionini and Komlodi examine the state of user interfaces for information seeking. Interfaces are defined as the conjunctions and boundaries where different physical and conceptual human constructs meet, and is at the center of information science in fields such as human-computer interaction (HCI and human factors. The chapter looks at advances in technology and research, summarizes the developments of the first two generations of user interfaces, and examines current (as of 1998) developments in the field. One way to look at the chapter is shown in figure 1, with technology, information seeking, and interface design research and development shifting from mainframes to PCs to the web, from professionals to literate end users to universal access, and from ASCII characters to graphics to multimedia respectively. Some early developments remain important today, such as the components of an interactive system – task, user, terminal and content (with context added later). Another milestone was the development of the GOMS (goals, operators, methods and selection) model, the first formal model of of HCI. Two themes throughout the chapter are the interdependent nature of research in this area and the importance of human-centered concepts and design.

This is a really good summary of the history of HCI with an eye specifically toward searching and information use. It’s not surprising the many of the names we have seen on articles this semester show up here as well. The only real regret I have is that there are no pictures. User interfaces often rely on visual display for interaction, so in addition to all the description it would be really interesting to see examples of the different generations of user interfaces. One other criticism is that little attention is paid the the interfaces of video games—I have read a lot of articles about interface design that ignore this field as well.

Although it is a little out of date, there’s a lot to be taken from this chapter’s historical perspective. I found three things in particular that were talked about in relationship to third-generation user interfaces that were particularly interesting. First was the move toward universal access or ubiquitous computing. It is in some ways a measure of success that researchers now worry about the lack of computers in Sub-Saharan Africa—this wouldn’t be a problem if information seeking computer interfaces were not so available, useful, and approachable. Second was the notion that the advance of the web in some ways slowed the advance of user interface design, although the apparent disadvantage quickly disappeared. This is something I’ve run into in a different form as a web designer—clients complaining that their web site did not look exactly like their brochure. Again, in some ways this was an embarrassment of riches—the web site cost nothing to distribute, could be found by search engines, acted as a storefront, but the lack of a particular font face was a step backward? Finally, the notion that the whole field is really interdisciplinary is important to always keep in mind.

A poster mentioned that they want to concentrate on cross-cultural user interface design in school, but hadn’t seen much about it.  No one seemed to think that there was enough research/work done on the issue, and I don’t think I’ve really seen anything about it.  There are some obvious things like language but the real problem is how different cultures assign different meaning to signs and symbols.

As part of a class project I’ve been reading the Online-News mailing list and responding to some of the issues and discussion brought up there.

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…)

After my first expose to the Dialog structured search system I wanted to put down some thoughts about relational databases.  There may very well be reasons why flat-file text databases are better for systems like Dialog or OhioLink, but I really don’t think they are the ones I’ve heard mentioned in class.

The first major point made in class was that in a flat file database like those in dialog the creators could do something like this for a record with multiple authors:

TI = Title of this article
AU = Smith, Bob B
AU = Jones, Joseph H
AU = Fakename, Robert P
etc…

Whereas in a relational database the table would have to have fields like this:

Table Article
——————
Title
Author1
Author2
Author3
etc…

Although I have seen databases designed exactly as described, that that design defeats the entire point of having a “relational” database–relationships.  A better design would be to break Articles and Authors into two separate tables, since they are two separate entities, and because they have a many-to-many relationship (any number of authors can write any number of articles) a link table would be made as well:

Table Article
——————
Article_id
Article_title

Table Author
——————
Author_id
Author_name

Table Article_Author
——————
Article_author_id
Article_id
Author_id

This is a better approach than the flat file database as well, because it means an author only needs to be entered once, and that the author record only exists in one place.  If a user is typing up hundreds of citations a day, it is likely they will misspell an author name once and a while–with the relational database, they would be picking from a dropdown or using some other method to select the author record that already exists.  Also, it allows for changes to be made easily.  Imagine if a prolific author has adopted a stage name and gained notoriety–now the author record can be changed only once and the changes will be reflect every time an article record–joined to the author table–is called up.

But what if some users will still search for the author’s old name?  There are a number of approaches the database designer could take, for example creating a new Author_aliases table that links to the correct record in the Author table, etc.  Also, the tables above are highly simplified.  It is doubtful the author table would have a field for name–most likely it would have fields for first, middle, and last name and any other pertinent information as well.  That, and proper construction of the interface, would eliminate such silliness as having to type Lastname, First in one place and Lastname First Initial in others.

There are a number of good tutorials on this subject online, for example:
http://www.phpbuilder.com/columns/barry20000731.php3?page=1
http://www.serverwatch.com/tutorials/article.php/1549781
http://builder.com.com/5100-6388-1050841.html

The second issue brought up in class was the need for unlimited field size.  I have also seen relational databases where the designer only allowed 5 characters for a field that after a year really needed 10, but again this is poor design.  Relational databases, at least for the last ten years or so, have been able to handle more or less unlimited field sizes.  MySQL, which is available for free, is a good example.  (http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#Column_types) For numerical data, the bigint column type has a range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 or 0 to 18,446,744,073,709,551,615 unsigned, and the varchar type supports up to 255 characters.  If you need more room than that, the longtext type supports up to 4,294,967,295 characters.  War and Peace in ASCII from the Gutenberg project, is just over 3 million characters.  How often do you need to store more than 1,000 copies of war and peace in one column of one record?  Expensive commercial databases like Oracle no doubt have even more impressive figures.

There are reasons why most of the largest web sites with the most traffic and largest amount of information use relational database backends, and not CSV files or even XML for storage and retrieval.  XML is great at moving, exchanging, and marking up information for display.  But from what I’ve read most people seem to agree it’s not great for storage of anything of real size, or anything that needs to be accessed very often and very quickly.

The more I use Dialog the less impressed I am by it.  It strikes me very much as a tool that was amazing in its day, but severely limited by available hardware.  Now that hardware is ridiculously fast and cheap, its limitations are purely artificial and indistinguishable from clunky design.  I know many people who swear by command-line interfaces, and I know there are studies showing CLI to be more “efficient” for the most expert of users, but there has to be a reason why 99% of the world uses Windows or MacOS (or Gnome or KDE even if they run Linux).  If it takes a year for most users to reach expert status and reap the efficiency benefits, but users can master a 20 percent less efficient GUI in a week, which is better?  And I say that from the point of view of someone who used DOS for years and is comfortable coding in notepad.  And it’s not as if creating a GUI means you have to abandon the CLI completely–both can happily coexist.

There are some major structural problems.  The fact that Author name entry isn’t standard across Dialog is nonsensical.  I understand where some fields in chemistry databases will differ from fields in business databases, but nearly everything will have an author, and all that do should conform to a standard.  The advantages of controlled vocabulary dwindle when nothing is well controlled.  Descriptors differ from one database to another, may or may not be updated, etc.  A well-designed relational database would help to eliminate these sorts of problems.

It would not be hard to make a system like Dialog with a relational database.  Give a decent programmer or dba complete access to Dialog’s data and a year full-time, and I bet they could come up with something.  The biggest problem would be trying to reconcile all the weirdness of the individual databases, like truncating hyphenated names and such.   Designing the tables and fields in MySQL for ERIC and a couple others would be a fun little project that would take less than a week.

I wonder – has there been any effort to bring Dialog into the current decade, or even the 1990s?  How many people still actually use it, with so many library and journal catalogs going online?  I know Medline is available elsewhere.  I asked a friend of mine majoring in LS at Pittsburgh and she said one professor showed it to them in one class, but no one ever actually used it.  I understand the difference between being able to search fields vs the web, controlled vocab, etc., but surely there’s a less aggravating system out there that includes these features?

I mean, just the whole bluesheet thing…  searching with the Find on this Page feature of your browser?  You should never rely on your visitors to have a specific browser feature, and search boxes aren’t too hard to do.  The Dialog Database Catalog is a series of randomly chopped up PDFs?  And none of this is integrated into any of their telnet-workalike interfaces?