Aug 01

The Challenge

One of my clients is starting work on a global redesign of their registration form, across every site they own. It’s a big deal, and it has the possibility of being very contentious. Multiple areas of the company have a vested interest in the questions, so we need to have a strong justification for every change we recommend.

The client is mostly concerned about getting the right mix of questions that let us gather good, useful information about our visitors without causing drop-off. But this is also a good opportunity to build in some usability best practices that have been missing.

Since our client is awesome, they agreed to run a test. We’re going to design 3 versions of the form, probably representing small/medium/long, and see which one hits a sweet spot in terms of gathering information without causing drop-off. We’ll run all 3 forms at the same time, randomly serving 1 of the 3 to each visitor who registers.

The Solution

Thankfully, Luke Wroblewski just published a book on web form design called… Web Form Design. I picked up a copy and read it during a few short plane flights this week.

In the interest of full disclosure, I should say that I saw Luke speak at this year’s IA Summit and even joined his lunch table discussion group, and I think pretty much everything he says is spot on. So I was predisposed to like the book. But it still exceeded my expectations.

For me, the book follows a perfect outline — exactly the format I want every professional book to follow. It deconstructs the issue of web form design into 14 discrete issues (e.g. “Help Text” “Inline Validation” and “Gradual Engagement”), and focuses one chapter on each issue. Then, within each chapter, he breaks out the various problems and solutions that he has observed within that issue.

The end result is extremely readable, and the content is very strong. Luke makes recommendations based on hard data, common-sense observations, and his own UX expertise. Also, the book comes with a digital version that links to a Flickr library of all the images he used. So it’s easy to take his work and repurpose it for your own presentations.

While researching, I also came across a couple of interesting articles on Smashing Magazine. They did their own research into the most common ways web forms are done. You can read Part 1 and Part 2 here. For me, it’s only somewhat interesting, since it’s reporting more raw data and less actual UX expertise.

Conclusion

I’ll update later with results from the form design project. Stay tuned.

In the mean time, let me recommend a site I just found called Wordle. You can enter in any text you want, or paste in a URL, and it will create an attractive word cloud based on the words in your text! You can even customize the appearance of the cloud. It’s kind of fun, but it’s also useful if you want to quickly pull out the words most commonly used in a source file.

I pasted in the text from Web Form Design and here’s what I got:

A word cloud created by Wordle

Jul 16

If you’ve set up a new account on a website in the last few years, you’re no doubt familiar with the string of random letters and numbers you have to type to prove you’re a human.

These tests — called CAPTCHAs — were supposed to stymie computer programs trying to pose as humans on sign-up pages and forums, but industry experts suspect we may soon be seeing the last of them.

Computerworld is predicting the death of the CAPTCHA, saying that in the decade-long game of cat and mouse, the scammers and their programs — computers tricking other computers into thinking they’re human — have emerged victorious.

With automated tools now able to defeat 90-100 percent of the CAPTCHAs at many popular sites, malicious users can create free e-mail addresses and social networking accounts at will.

Few users will mourn the passing of the tests. As CAPTCHAs grew more complex over the years to hold off computerized attempts to subvert them, they added headaches for site administrators and effectively locked out many blind users. Source: http://marketplace.publicradio.org/

Jul 07

As professionals in the digital industry, we’ve been on high-speed Internet connections for quite a while, at both home and work. So I found value in a recent CNN article that reminded me there still is significant opportunity for growth. According to a recent Pew Internet and American Life Project, 55% of Americans have broadband, and 10% have dialup at home. The 35% of Americans who still don’t have access to the internet from home are primarily those with lower incomes and the elderly. 

Since it’s my job to create the best digitial experiences for users who are already online, unfortunately I’ll need to figure out how I can help those who don’t have internet access another day. My immediate concern is ensuring we design and develop sites that those still on dial-up can use.

Small Percentage, Mighty Number

A colleague of mine made a valuable point that when you only look at the people online, 95.7% have broadband and only 4.3% have dial-up, according to a recent MAGNA Global study. But that 4.3% on dial-up still represents 3.2 million Americans. The MAGNA study forecasts that the number on dial-up will continue to fall during the next few years, but according to the Pew study that won’t happen until prices for broadband become more reasonable for lower-income Americans.

In the meantime, 3.2 million Americans is a small percentage, but a mighty number. Let’s not forget about them as we plan our digital experiences. While sites can be optimized for high-speed connections, dial-up users should still be able to access key pages and functionality without the page hanging up or taking an unreasonable amount of time to deliver. What if it’s a checkout page for an e-commerce site? That’s too many customers to ignore. Plus an increasing percentage of users are accessing the same sites from their mobile phones, with even slower connections.

Your Site’s Dial-up Percentage

Of course, your site analytics are the tell-tale factor to determine how many of your site users have broadband vs. dial-up. A site like Wired.com probably won’t optimize for dial-up users as Knitting World would.

And that’s just the U.S. As another colleague of mine pointed out, if your site has global reach, it’s important to look at the broadband vs. dial-up adoption rate in your target countries. Chances are that will bring your broadband percentage down too.

Championing All Connections

I look forward to the day when everyone is on broadband connections from their homes, and I can access the internet while I’m on a plane or riding in a car. And the day when page load times aren’t much of a factor. But until then, I want to be a champion for all users, big connection or small.

Jun 17

Q: What is a “widget”?

A: To understand widgets, we first need to consider the history of the word.

Originally, the word “widget” was used in business classes to describe a non-specific product. For example, business students might play a simulation game in which they were put into teams that sold “widgets”. It was their job to figure out how to differentiate their widget and market it to consumers.

More recently, the word “widget” has been adopted to describe any small application or tool, ranging from a blog badge to a Facebook application. This usage was originated by executives who were shown various small applications and tools and didn’t know how to describe them. So they used a nonsense word.*

A businessman wants a widget

The bottom line is that the term widget has been used to describe so many diverse things that it’s not really a useful word any more. If someone starts talking about widgets, or asks you to design one, the first thing you need to do is work with them to figure out what they really want.

*This is not actually true. To the best of my knowledge, the word “widget” was coined by the people who developed Konfabulator (now called Yahoo! Widgets), which was was one of original platforms for hosting small applications on a PC desktop. But I do think the term “widget” has been co-opted by executives and stretched to the point of uselessness.

Q: How do I help someone figure out what kind of widget they want?

A: There are three important attributes to every widget. If you define those three things, then you’ll be well on you’re way.

1. Purpose
2. Audience
3. Platform/Technology

Let’s look at each of those attributes in detail.

Purpose
It’s sometimes hard to know whether you should begin planning a widget by thinking about your audience or by thinking about the purpose of the widget (i.e. the business objective of the widget). My feeling in this case is that you need to decide on the type of activity you want to encourage in users before you go too far down the path of figuring out what your users want. But purpose and audience really go hand in hand, so you need to keep both in mind as you work.

Based on my own observation of widgets, I am proposing 4 high level purposes that a widget may have.

1. Perform a task
2. Provide information
3. Gather information
4. Connect people socially

Note: I will add a page of example widgets that demonstrate each of these purposes in the near future.

Actually, a widget might fulfill several of these purposes at the same time. The key is to ask questions that help determine which ones are relevant.

Example Questions

  • Can you do something useful for your audience, like perform some calculations or sound an alarm at an appropriate time?
    Then maybe your widget is meant to perform a task.
  • Do you have content that you want to push out at relevant times?
    Consider a widget that provides information.
  • Do your users want to provide feedback or give you information?
    Maybe you want to design a widget that gathers information.
  • Would your users find it valuable to be connected with other users? Do they have something to say to each other, or do they want to compare themselves against each other?
    Consider a widget to connect them socially.

Audience
Some widgets have only one audience and others have multiple audiences. It’s your job to figure out who the audiences are.

Possible Audiences

  • The user who installed the widget
    In most cases, the widget is going to be used by the person who installs it. For example, if I add a widget to my iGoogle page, it’s because I want to see it every time I go to my home page. The widget should be designed solely to meet my needs.
  • The friends of the user who installed the widget
    Many bloggers add widgets to the sidebar of their blogs. For example, on this blog I might add a widget that searches the email archives at IxDA. As the blog writer, I already know about IxDA, and I already know how to go there and search the email archives. I would only add it to my blog as a service to my readers. They are the real audience.
  • Both the user and her friends
    A lot of Facebook application fit in this category. They provide some value to the user, but they also provide value to the user’s friends who visit her profile page. For example, a Facebook application might be useful to me because it helps me keep track my favorite recipes. But it’s also useful to my friends because they can see the kinds of recipes I like, and recommend more they think I would also like.

Once you have identified your audience(s), then you can start designing an appropriate UI. If your audience includes both the user and that user’s friends, then you want to enable both audiences to do the things they want to do, without making the interface confusing for either audience.

Platform/Technology
Platform is the third and final attribute for a reason. It should flow naturally from the first two attributes.

For example, let’s say you chose to design the following kind of widget…
Purpose: Perform a function
Audience: Only the user who installs the widget

In that case, you probably want to choose a platform like iGoogle or the PC desktop.

However, if the chose to design a widget more like this…
Purpose: Connect people socially
Audience: The user and her friends

In that case, your widget probably belongs on a platform like Facebook.

Since there are so many platforms, and their pros and cons aren’t well known, I’ll provide a brief overview of the most popular options here.

  • Yahoo Widgets
    This is a framework that users download and install on their PC. The framework is for both Mac and PC, which is good, but it does require a separate installation process. So I tend to think this platform is only for people who really want widgets — not for average users.
  • Google Gadgets
    Google Gadgets are a lot like Yahoo Widgets, except they can work in more places. A Google Gadget can be placed on a user’s iGoogle page, it can be installed as a PC desktop widget using Google Desktop (which is just as distracting as installing Yahoo Widgets). And I understand a Google Gadget can even be installed on any regular web page.
  • Facebook
    Facebook is probably the most popular social network for widgets (Facebook calls them “applications”). Since so many people are already using Facebook, it’s almost ideal for any widget that needs to be social. The downside is that Facebook has been overrun by applications, so the managers are taking steps to minimize the role the applications play. Also, Facebook applications are often written in a proprietary language, making them more difficult to port to other platforms.
  • OpenSocial
    Just about every social network that isn’t Facebook uses a Google technology called OpenSocial to power its applications. That includes MySpace, LinkedIn, Ning, and dozens of others. Although I haven’t seen many OpenSocial applications yet, it’s a good bet that they’ll become more popular in the future.
  • Blog badges
    Most blogs give their owners a place to add “badges”, usually along the left or right hand side of the page. These badges are typically just a snippet of HTML and an image, offering minimal interactivity.
  • PC Desktop
    Some PC widgets are actually just specialized applications. A common example is WeatherBug for the PC. It gets installed like any other PC application; it just has a small window and it hides in the Start bar when not in use. Alternately, you could develop a cross-platform desktop widget by compiling a Flash application, or transforming your Flash program into an Adobe AIR application, or by writing your application in any other platform-agnostic language.
  • Mac OS X Dashboard
    The Mac operating system comes with a tool called Dashboard that overlays a set of widgets whenever the user presses a special key. Dashboard widgets are generally very popular with Mac users, but it does require you to build a widget just for the Mac platform.
  • Vista Sidebar
    In Windows Vista, a tool called Sidebar provides a “dock” for widgets on the side of the screen. It’s actually very similar to Yahoo! Widgets, except it’s built into the operating system. However, Vista Sidebar has the same drawback as Dashboard: it only works for a single operating system.
  • iPhone
    The Apple iPhone now allows developers to write 3rd party applications for the phone. Because the screen is small, these applications look like widgets, so they’ve been wrapped in under that term too.

This is not a complete list of widget platforms, it’s just the most popular options. All the same, it’s more than enough options. The good news is that many of these platforms use the same basic technologies (HTML, CSS, Javascript, Flash, etc.), so it’s usually not that hard to rebuild a widget so it works on multiple platforms. Once you’ve picked a platform (or a few platforms) that make sense for your purpose and audience, you need to talk with your developers to figure out which ones you can reasonably support within your budget and schedule.

So what do you think of this framework? So far it has made sense for my projects, but I’d love to hear some other opinions. How are you thinking about the widgets you’re designing?

Apr 16

Since joining Bridge, I’m feeling like a senior citizen.  So I’ve found quite a few interesting and relevant resources about accessibility and the senior population.

 

 Often when we talk about accessible websites, we think about screen readers, alt tags and resizable text.  Vision impairment is definitely an issue for seniors, but there are a lot of cognitive and behavioral differences to consider as well.

 

 Fidelity Investments did studies on designing websites for people over 50, and AARP.org gives a good summary of the Eight Lessons Learned.  Many of the findings do not pertain to vision or motor impairment.  Seniors read, process and interact differently than younger users, have lower levels of confidence and understanding, and higher levels of anxiety when it comes to using the web. The amount of content per page, clarity of content and terminology, and consistent placement of navigation are all important to consider. 

 Lots of links about designing for older users

http://www.aarp.org/olderwiserwired/

 

 Here’s a checklist:

http://www.nlm.nih.gov/pubs/staffpubs/od/ocpl/agingchecklist.html

  

The Greater Good

In an interview with AARP, Ben Shneiderman talks about “Creating Participation”.  This is what he says:

 

 “…I think the highest goal of web design for older people should be not only to serve the elders, but to benefit from them. It’s the contributions that they can make to our society by their participation –that is the real pay off.

We’re going to benefit their lives by the social communication, by the challenges we give them, by the educational experiences, by the information for their own lives, by their capacity to do banking, or make travel arrangements, and send photos, and receive photos from grandchildren, and so we’ll benefit seniors.

But we’ll also benefit everyone else who will gain from their experience and their wisdom. Increasing the participation of older users in society is the opportunity that attracts me.” 

 

 

 

 

Apr 11

During today’s Design and Architecture of Social Web Experiences workshop, I took 5 pages of notes and designed a very simple, yet very cool social website. So, yeah, I’d say it was a good session.

Here are some of the highlights from my perspective…

The Webb/Butterfield/Smith Model

This is an illustration that shows 7 aspects of social networks in a way that makes it easy to describe the functionality of a social web site.

Webb Butterfield Smith Model for Social Software

It’s not like this diagram does anything, so to speak, it just gives you a way of describing social features, and it serves as a reminder of the social network attributes you should consider when designing social software. Wodtke created an expanded version that includes some attributes she considers missing from this honeycomb, which hopefully I’ll be able to share later, along with an expanded description of the attributes.

Open design patterns

One of the presenters (Wodtke, I think) made a point about how, when you’re designing a social network, you don’t need to “own” the content your users create — you just need to aggregate it in a way that’s useful. For example, if your users already have blogs, maybe you just want to search that content for certain tags and aggregate the posts in a way that’s useful.

The presenters often hit on a similar idea: when designing social networks, open is good. Users are tired of entering in all their personal information, building their network of friends, and then having all that data locked inside your application. We need to build networks that allow data portability (through RSS, APIs, microformats, etc.) if we want to provide a product that’s easy to use from beginning to end and integrates with users’ whole digital life.

Trust and monitor

The phrase “trust and monitor” describes a good approach to maintaining editorial control over a social network. “Trust” means you assume your users are not criminals who all want to break the rules or game the system. “Monitor” means you still do your due diligence to make sure offensive content doesn’t crop up.

This stands as a recommendation for our corporate clients who often want to keep an iron fist around anything social on their websites.

The problem of the Cold Start

Near the end of the session, we talked about the problem of the “cold start”, which is when you build a social network, but nobody’s there. And nobody’s going to come until there are people there. Catch-22.

We talked about 2 ways of overcoming that problem. First is having content or functionality that’s valuable even if nobody is there. But in cases where the site isn’t meant to have its own content, the only real solution is to start the group yourself. You join the social network and get your friends to come, and get them to bring their friends. Or, if not you, then a chosen community manager. The idea is you have to start at home. 

Group size

There was an interesting conversation about the right size for a group online. We talked about Dunbar’s number, and how that doesn’t directly apply to web experiences because the social information you would normally need to keep in your head can instead be kept on the computer. But we also talked about how “scale kills conversation”, meaning as groups get larger, the conversation becomes less meaningful.

At work, we’ve been discussing this issue for an upcoming social network, but I’m not sure today’s session really helped me figure out an answer. Does anyone really think there’s a “right” size for online groups? Or does it depend on the situation?
Apr 08

One thing that I like to hear when I first dig in on a project at Bridge:

“We used to be able to do this type of website in a month. Now it takes seven.”

There are a few things that have changed in the three years that I have been with Bridge–all of which run through my mind and, as most who know me know… if it is on my mind, you’ve got a 78 percent chance of hearing it. Things like: We’ve instituted rigorous process; we’ve added subject matter experts from several disciplines; we’ve made large, complex websites the focus of most of our engagements.

But, mostly I think that 1) it never took a month, it took six, 2) those six months made a lot of people run away (and by run away, I mean cry, yell, or quit–and sometimes I wanted to run far, far away), and 3) the hours ran away. They really ran away.

Not that I want to start a trend or anything, but Jeff sent an email a little while ago w/the subj line: AdAge on becoming a TRUE interactive agency. The story went something like this: One firebrand initiates a digital revolution at his agency. Agency adopts senior technology leadership to shape direction, begins a deep love affair with IA, and reengineers process to become a TRUE interactive agency. Agency successfully becomes TRULY digital. (I’m not sure what’s with the TRUE, that might be Jeff making a pt or AdAge.)

Well, Bridge is on that very same road. When I started at Bridge in April of 2005, there were three centers of excellence that drove client work: Account, Creative, Research, and Technology (let me make this clear: that was in alpha order). And we were nutty. Technology was… I don’t know, either Flash or the support desk. Anyone could do a site map. Sometimes, it was the client. Often it was creative. Sometimes it was technology. As for process… well, we had process?

And then Uncle Chally came. I don’t know if he knows this. Frankly, I don’t know if anyone else realizes it either–but I’m blown away by CH and Bridge. Overnight we went from, “User experience is like … uh, usability and junks right?” to “Hey, this is not the optimal experience for the user. How can we fix it?” We went from designing for the client and what made sense to us to… well, designing for the user.

We adopted a complex and rigorous process. If I could digitally snap my fingers to show you how fast, I would. But, it was an intensely different philosophy and approach to the work, and everyone jumped on the 5D process.

And finally, IA. Well, I’m a senior experience planner. There weren’t any XPs walking around, loving on IA 2 years ago.

We even have SEM guys–three of them.

Yes, all of this takes time. But, it adds focus, thinking, strategy, tactical and executional excellence, risk mitigation, and outstanding results.

This is not the agency I started at. Thank god.

Viva la Revolution!

* Are we allowed to swear on this blog?