Know Your Limits

By Matt in Applications

Limitations. It’s one of the central tenets of the modern web application design and development aesthetic: less is more; niche-level focus is the path to success; feature creep spells doom and confusion. Limitations keep things on track. Building only what is necessary benefits both developer and user.

But, as with all principles, careful application is key, and limits are a sticky subject. Are your limits unexpected? Are they advertised, explained, or easily understood when discovered? What happens when a limit is hit? Is the limit purely a technical one? How much work is saved by placing a limit on something, and do you run the risk of raising user ire by enforcing it? What will you tell your users is the reason for the limitation if they ask? Are you trying to follow a trend of behavior, or set one?

Twitter

Twitter limits posts to 140 characters, and largely because of that limitation the platform is the biggest thing since sliced Facebook. Brevity is the cornerstone of Twitter; as a result, URL-shortening services have become a necessity to pack as much into a tweet as possible. You can only follow 2000 people on the service, which helps the servers that run Twitter and is a number that no user would be able to realistically keep track of anyway. And, for some reason, only only 162 pages of archived tweets are available — likely another technical limitation designed to reduce load on the historically unreliable Twitter architecture.

Twitter is a great example of an idea successfully based on limits, and the limits it enforces are not conspicuous enough to be annoying. On the other hand, Twitter’s limits on API usage have irked some deveopers, and when features sometimes disappear in the name of keeping the site live under heavy stress, users are understandably surprised, confused, even angry. As Twitter is iterated upon, these issues should become less and less prevalent, and the expectations of its limits will be fulfilled more consistently.

Muxtape

The late great Muxtape was all about limitations. Each user was limited to a single mix, and each mix was limited to no more than twelve tracks. This kept things from getting indulgent, and doubtlessly saved disk space. On the flip side, users were also limited to only twelve ‘favorite’ mixes to save on their profiles. As a frequent Muxtape user, I found this limitation made it difficult to keep track of more than that number of mixes, which presented a problem — I wanted to maintain a list of both friends’ mixes and mixes I wanted to save for later listening. It never kept me from using the site, and it may have been changed in the future, but it was a little annoying.

Take It to the Limit!

The key is to make sure your limitations never restrict exploration and excitement, but instead focus on creating those emotions in your users. For new users, exploring a site’s purpose can be intimidating and, potentially, a waste of time. If you can condense the message and narrow the feature set, your product will be much easier to understand, and thus easier to participate in. Once a user is in, however, don’t let them stop at accumulating reasons to revisit the site, or telling friends. Keep things as sticky as possible.

Helpful Limits

• Your site doesn’t need all of the features it could have. If a problem has already been solved, don’t replicate — incorporate or eliminate.
• Would your site’s content (user-generated or otherwise) be more compelling if limits were applied to it? What if you only had a sentence to explain each page? What if users’ bios could only be six words long? Restrictions can often provide the frameworks in which participation and creativity truly thrive. Read Peter Bregman’s Why Doing Things Half Right Gives You the Best Results for an idea of what can happen when users are presented with too many choices.

Hopefully Limitless

• Users should be able to have as many friends, favorites, and other “collectibles” as they need. If all that data storage is costing you too much to keep it free, make people pay to up their limits. It works for Flickr, and there are a lot of people who would pay for Twitter too.
• Explain your limitations upfront, and go easy on users that reach or try to break them.
• Limits should look like limits, not like errors or something unfinished.

So?

Limits and their potential consequences are a helpful structure in which to evaluate the features of your site and every facet of its design — both the system and the interface. Keep limits in mind as you’re building, and you may end up launching ahead of schedule, saving yourself time and your users the time of figuring out the ins and outs of your site’s feature-set.

I’ll leave you with some questions. Which of your favorite services employ limits, and how does it make things easier or more difficult? Is limiting favorites is a mistake? Is there something positive to be said for a limitation that users won’t like?

Wikipedia’s Babel Userbox

By Matt in Applications

There are few who would deny that Wikipedia is an incredible resource for information and a testament to the power of an intelligent global human community given basic interconnectivity and the tools to share knowledge. But it’s not perfect. From a design and usability standpoint, in fact, there’s a lot wrong. A number of sections and features on the site are downright baffling to use, and poor design is more than prevalent. I could go on for hours, but I’ll stick to one thing for the moment: something I noticed when I went to update my user-page this morning.

I am a contributor to Wikipedia, and I speak Japanese. To indicate that fact to people that visit my user page, there’s a box that lists the languages I speak and just how well. (This box, technically called a ‘userbox’, sometimes abbreviated ‘UBX’, is part of the Babel project, and was the first userbox template on Wikipedia. Since its inception, badges for every conceivable attribute have emerged.)

I don’t understand this box. What’s going on here?

The numbers don’t mean anything

The numbers are somehow meant to signify your proficiency at each particular language, but they are basically meaningless. The questions immediately raised are:

• Is 2 is a high number or low number?
• The range into which a number falls is unclear. Two out of what? Of five? Of ten? Of six hundred quadro-billion?
• There’s no way to tell the particular language skills actually signified by each number. What’s the difference between a ja-2 and a ja-3? Is it a difference in vocabulary size, conversational ability, etc.?

Furthermore, the scale isn’t limited to just numbers — there’s a ja-N for native speakers. Even more confusingly, I speak English natively, but the template Babel box posted for native English speakers uses only en, not en-N. (Incidentally, there’s also an en-N category). The system is totally inconsistent.

If you read the fine print, it turns out a lower number indicates a lower level of proficiency. There are many different metrics one could use for language proficiency (or any sort of skill, for that matter), and among them both high or low numbers could be used to indicate expertise or accumulated experience. You can be a first-class pilot (a low number) or a Level 64 Gaming-Warlock (a high number). Incidentally, the Babel box numbers are roughly based on the ILR scale, in which a lower number indicates lower proficiency. Contrast this with the Japanese Language Proficiency Test, where a lower number indicates higher proficiency.

The point is, the nature of the metric being used here needs to be made obvious by showing the bounds of the metric and the significance of each bound.

The explanatory text is unhelpful

The Japanese sentence next to the ja-2 box explains that I’m a medium-level speaker, but only people who read Japanese can understand that. (And what does speaking have anything to do with it, anyways? This is a website concerned with reading and writing.)

The design of the box is lacking

• Why is it titled ‘Wikipedia:Babel’?
• Is there any rhyme or reason to the color scheme?
• What does it mean to ‘Search user languages’?
• It’s aesthetically boring at best, ugly at worst.
• The syntax for creating userboxes is needlessly confusing.

It turns out that investigating the ‘medium-level’ link hidden in the explanatory Japanese sentence in my Babel userbox reveals yet another badge:

Confoundingly, this badge is a different color and is more explanatory, but it’s hidden away in the Babel userbox documentation pages. It doesn’t really even make sense as a badge in that context. I give up.

Why is it such a mess?

Clearly, the Babel userbox needs work. I chose to focus on this tiny little aspect of the site, but it’s indicative of a much wider swathe of design and usability flaws on the site in general. But why is this the case? Some insight into Wikipedia’s defects may be found in two places: Google and open-source software.

Those who find success in Google’s infamously minimal “non-design” point to its ability to sink into the background and make way for the important stuff — search results, emails, etc. Likewise, Wikipedia is about articles. Only the power-user needs to worry about things like revisions, categories, templates, and profile customizations such as the Babel userbox. The article (and editing it) are the strong idea, and Wikipedia has the momentum of quality, quantity, and notoriety, which, like Google’s search engine and email service, are enough to get beyond what’s lacking in the interface.

Open source software is plagued by poor usability. As an open-source software project, MediaWiki suffers from many usability problems. This is compounded by the fact that Wikipedia, the encyclopedia built upon it, is itself open to anyone. And those anyones are often experts, but not in the field of design or information architecture. Thus, amateur and suboptimal design is the standard.