Last weekend I shook off my Berkeley inertia and took a trip in to the city to attend WordCamp.

I particularly enjoyed a talk by Rashmi Sinha about social networks and popularity. There are some problems inherent in basing a site’s navigation on popularity. A lot of sites like Flickr, Digg, etc. emphasize browsing based on “most viewed”, “most downloaded”, “most popular” tags, etc. The undiscovered posts/images/constributions (the Long Tail) cannot rise to the top in this structure, and ultimately become less findable. The hierarchy reinforces itself. Early adopters of a social network become overly dominant, and their popularity is difficult to dismantle.

Rashmi presented a few ways to override this self-reinforcing popularity mechanism. On her project SlideShare, they set up other navigation panels such as “most recently added”, and they restrict the popularity measures to a specific period of time (”most viewed in the past week”.)

Her presentation from the talk is here (on SlideShare, of course).

Bret Victor makes some salient points in this piece — in essence, rather than desiging good interactive experiences, we should present information in such as way that the user doesn’t have to interact with it to find things. He proposes redesigns of Amazon and Yahoo! Movies that are very information-dense but also quite useable (and not “interactive”).

Abstract:

The ubiquity of frustrating, unhelpful software interfaces has motivated decades of research into “Human-Computer Interaction.” In this paper, I suggest that the long-standing focus on “interaction” may be misguided. For a majority subset of software, called “information software,” I argue that interactivity is actually a curse for users and a crutch for designers, and users’ goals can be better satisfied through other means.

Information software design can be seen as the design of context-sensitive information graphics. I demonstrate the crucial role of information graphic design, and present three approaches to context-sensitivity, of which interactivity is the last resort. After discussing the cultural changes necessary for these design ideas to take root, I address their implementation. I outline a tool which may allow designers to create data-dependent graphics with no engineering assistance, and also outline a platform which may allow an unprecedented level of implicit context-sharing between independent programs. I conclude by asserting that the principles of information software design will become critical as technology improves.

Although this paper presents a number of concrete design and engineering ideas, the larger intent is to introduce a “unified theory” of information software design, and provide inspiration and direction for progressive designers who suspect that the world of software isn’t as flat as they’ve been told.

It’s well worth the read. At least twice!

I find personas virtually useless when it comes to design, and I very rarely reference them in making design decisions. For me, personas aren’t about design, but that doesn’t mean they’re not incredibly powerful in other ways.

Rather than using them to drive design, she advocates using personas to communicate the user-centered design process to key stakeholders:

Having your clients view user research and testing is incredibly powerful in helping them realise that there is a problem in the way they’ve been approaching things to date (if you’re not encouraging stakeholders to actively participate in observing research and testing you’re missing out on a lot). But to get them to actually understand what user centred design is about – you need personas. … Personas should always be developed collaboratively with key stakeholders – as many as possible.

Personas can be useful in determining the edge cases, but guiding design around that is dangerous:

Personas should define the boundaries for which you will design. It’s a common misconception that personas are about creating a set of ‘typical’ or ’stereotypical’ users. Much more useful is to use personas which incorporate edge cases behaviour or requirements.

…Creating ‘edge case inclusive’ personas and then prioritising personas and their goals is much more useful in helping decide what functionality goes in and what doesn’t.

… If you use the personas to closely guide your design you will end up supporting a series of edge cases. This will invariably mean that your CORE functionality is compromised. That’s bad design.

Personas help to remind us that there is more than one “user” in “user-centered design”. Instead of saying “the user wants to …” we can use personas to explain that “Susan wants to do X, whereas Scott wants to do Y.”

And now, the detractors. Since the Kathy Sierra scandal, the Web 2.0 community has started talking about its dark side, albeit hesitantly. Is anonymity really that great? Are we abusing the democratic promise of the Internet by engaging in cowardly flaming wars under pseudonyms? Can you really trust information that is unedited and unattributed? Are people spending too much line creating online personas and online friendships, thereby forgetting how to connect as a real person, face to face?

Andrew Keen is one of the loudest critics of the Web 2.0 mania. In The Cult of the Amateur he writes:

The infinite desire for personal attention is driving the hottest new part of the Internet economy–social networking sites like MySpace, Facebook, MTV Flux, and Bebo. As shrines for the cult of self broadcasting, these sites have become tabula rasas of our individual desires and identities. They claim to be all about “social networking” with others, but in reality they exist so that we can advertise ourselves: everything from our favorite books and movies, to photos from our summer vacations, to “testimonials” praising our more winsome qualities or recapping our latest drunken exploits.

The criticisms are mounting. Fast Company warns us not to collect colleagues like Pez dispensers. Even Jurgen Habermas has commented that in the fragmented and decentralized context of the Internet, “contributions by intellectuals lose their power to create a focus”.

It’s important to remember: just because you have 524 online friends (or colleagues) doesn’t mean they really know you or can vouch for you (or would show up with jumper cables if your car stalled at midnight in the rain).

The expo-only ID — the yellow badge announcing that “I didn’t pay to be here” — only allowed access to the “Products and Services” track, which was basically a bunch of pitches that were not interesting to me. So, I opted for the “un-conference” going on in the hallways outside the conference rooms — the Web 2.Open. These sessions were quite interesting and much more intimate than the larger audience-of-hundreds format. In particular I enjoyed Nicole Simon’s talk on a European perspective on Web 2.0, and a roundtable discussion on usability issues led by Chris Cole of Human Factors.

As far as the rest of the conference goes, I heard from other attendees that some of it was quite good. If anyone is interested in what was presented, LukeW has posted a very generous collection of notes from some of the sessions.

As the question of top, right, or left aligned form labels comes up often for designers, here’s a short overview of the pros and cons of each method. For illustrated examples and more details, take a look at the full document: Best Practices for Web Form Design (3.9 MB PDF).

Another recent article related to web forms addresses instructional text in the user interface. Embedded user assistance can quickly become more complicated than you might think. Too much assistance clutters the screen, but if you hide the form field explanations under tooltips, your users might never see them.

Mike Hughes offers up the compelling idea that contrary to the logic of flow, instructions should appear below the form element rather than above it. When completing a form on the web, people tend to go straight to the action–so if the help text comes first, they skip over it:

Users skip static elements, such as instructional text, because they focus immediately on downstream actionable objects. Effective user assistance design accommodates users’ natural workflows by providing instruction immediately beside or following interactive elements that constitute points of need for more information.

Now that average Internet users are more accustomed to interacting with web forms, they have higher expectations for usability. Written best practices like those above help to make these expectations explicit, so we can better understand what makes a form easy vs. annoying.

Some surfers may not understand the difference between the address bar and the Google search bar. Other people do this intentionally as a shortcut. The comments offer some insight: one poster writes, “If I want to search amazon I type [into Google] ‘amazon mybook’, wikipedia is ‘wiki somesubject’, or ‘weather san diego, ca’.”

A parallel development is that some people choose a search term and make up a domain name to match it–like “aromatherapy.com”–rather than entering “aromatherapy” into a search engine.

In summary, we can observe two opposite trends: People who “should” type domains into their address bar end up typing them into their search bar or search engine. And people who “should” use search engines to find what they’re looking for, make up domains on the fly and type them into their address bar. You could call it the Battle of the Clueless. And the battle has only just begun.

Those of us who have been using the Internet since the first GUI browser tend to forget that newer users don’t necessarily follow the “rules”. People find surprising ways of using software that may never have occurred to its designers. “Clueless” or otherwise, users run the show and designers must adapt.

It will be interesting to explore how this phenomenon impacts search engine rankings, pay-per-click advertising, and the value we place on website hits statistics. If search engines aren’t used only for searching, traditional methods of measuring clicks and referral sources may need to be rethought.

Wabi-sabi is a Japanese aesthetic and philosophy of simplicity, humility and naturalness. In the era of information anxiety, this sort of approach is regaining popularity–”wabi-sabi” the new design trend now graces the covers of numerous books on home design, lifestyle, and pocket guides to zen.

As a designer of primarily digital information, I’ve been pondering how this aesthetic (of natural materials, impermanence, taking time to let things develop) might apply to the web medium. Obviously I cannot design a website with bamboo paper. Even if I were to scan images of natural materials, the website visitor is still confronting a computer screen between herself and that image–the very antithesis of naturalness.

Simplicity in design is not just about sparse, minimalist design. This approach can feel harsh and cold, knife-like. Simplicity should still have life:

Pare down to the essence, but don’t remove the poetry. Keep things clean and unencumbered, but don’t sterilize.

The culture of technology has its own momentum. New software products are released daily it seems, and trends are born and die off faster than bean sprouts. We are attached to the newest ideas, the latest techniques–and as a result we create things that cannot last. Simplicity is the latest keyword, but that doesn’t mean it comes from the perspective of the wabi-sabi philosophy:

Things wabi-sabi are unpretentious, unstudied and inevitable looking. They do not blare out “I am important” or demand to be the centre of attention. They are understated and unassuming, yet not without presence or quiet authority. Things wabi-sabi easily coexist with the rest of their environment.

How possible is this in the web design culture 0f awards, accolades, and IPOs?

Designing this is tricky, especially if the list of items is longer than one screen (more than 20 items). If the contents of the list are known entities (for example, product names that the user is familiar with), data entry would become faster once the user has filled out the form a few times. For a new list or a list of lengthy items, however, the task has more usability issues.

I worked out three different approaches to desiging this question, each using standard form elements: radio groups, pull-down lists and text fields. Advantage and disadvantages are given after each example.

1. Radio groups

Example:

Advantage: With radio groups it’s easy to restrict the user’s choice to one first, one second, one third. It’s easier to scan and visually compare items, especially those that are sentence-length or longer.
Disadvantage: If the list is longer than one screen, the ease of scanning is reduced.

2. Pull-down lists

Example:

1st Choice:

2nd Choice:

3rd Choice:

Advantage: Saves a lot of screen space. Easier for the user to verify her choices at a glance before submitting.
Disadvantage: If the list is very long, or the list items are longer than a few words, scanning inside a pull-down can be very difficult.

3. Text entry

Example:

Generally I prefer option #2—pull-down lists—because they take up the least space on the page. For a list of sentence-length items, however, radio groups are probably best. You could also create a list of abbreviations to represent long items (such as paragraphs), but this requires the user to take the extra step of interpreting the abbreviation before evaluating it.

Ultimately, the question should probably be written differently in order to avoid the cognitive overload of prioritizing a long list. But, as we all know, the designer doesn’t always have that option, hence the task at hand.