Technology
Using VoiceOver for Low-Cost Accessibility Testing
Mac OS X's VoiceOver screenreader is a quick and simple tool to check for accessibility issues. Best of all, it's free. Here's a brief video to get you acquainted.
Continue reading "Using VoiceOver for Low-Cost Accessibility Testing"
3D on the Web
Twenty years ago I was playing Rad Racer and watching Captain EO in 3D. I would have predicted that by now, we'd be well into the 3D era of entertainment. However, films like Up and Avatar have only recently brought 3D into the mainstream of Hollywood. Going forward, I can't imagine many major animated or action films NOT being released in 3D. While being the last person on Earth to see Avatar this past weekend, I couldn't help but think how this technology might one day relate to my day job. Will the type of 3D effects we're now seeing on the big screen make it onto the web? I think so, but it will take a while and won't be as impactful as it has been for the movie industry.
3D entertainment content will make its way onto the web first.
It's not a huge leap to expect we'll be seeing movie trailers offered online in a 3D format in the near future. When you go to a movie's trailer page, you're already seeing multiple options for the resolution of the trailer. Tacking on a 3D option seems to be a no-brainer; they're already filming the movie in 3D anyway and the only barrier for the user is obtaining a cheap pair of glasses. After movies, I expect to see video games make the leap. In fact, I'm sure armies of people are working to make this happen as we speak.
"Web" content will follow with shopping sites leading the way.
There are a number of other types of content that would benefit greatly from the 3D treatment. Most notably, I can imagine users wanting to view products like sneakers, bike helmets, furniture, etc. in 3D. Allowing rotating views of certain products was a big leap forward for online shopping experiences. Enhancing that type of online product browsing with 3D would be another step forward. In addition to retail, I envision real estate tours, trail maps, photo sharing sites, and infographics all benefiting from 3D enhancement.
Will we see interfaces designed for 3D?
We'll likely see some attempts to make this happen, but ultimately, it won't catch on. I think the path here is roughly analogous to the one Flash previously went down. It's a great fit for delivering certain types of content (video, audio, games, etc.), but building entire interfaces around the technology typically creates more problems (accessibility being a big one) than it solves. I have a hard time envisioning 3D interfaces providing a real, tangible benefit to users.
Don't start worrying about 3D any time soon.
Ultimately, designing for 3D content is not going to have a major impact on web and user experience designers' jobs in the near future. I'll be on the watch out for the first movie trailer site that offers the 3D option though.
Geo: Soon to be Legit
The W3C has been working on a specification for a geolocation API, and has reached the point where it's starting to firm up and come together. That's good news, as it allows browsers to tell websites, through a JavaScript interface, where the browser is located.
The better news is that we're going to be able to use these new APIs sooner than you might have thought, given the relatively new nature of the API draft spec. Opera has implemented the spec in builds for several months, and it will be implemented in the release of Firefox 3.5. More recently, it's become evident that Mobile Safari in the new iPhone 3.0 software provides a geolocation API, and it appears (outside of the NDA realm, at least) that it is indeed compatible with the W3C API.
What does this mean?
Confirming Passwords Is Annoying: Is There a Better Way?
The defining characteristic of a password field is that it abstracts text as dots. While the intention of this behavior is understandable (it makes users feel secure and protects from prying eyes), the unintended effect is that it creates a usability problem. Users can't tell if they've entered a password incorrectly until after the site's validation informs them. It's like typing with your eyes closed.
The most common solution for the password field problem on registration pages is to require people to confirm their password in a second field. Again, the intention is understandable (it cuts down on mistakes), but the reality is that sites are requiring people to deal with two password fields. Here's an example of the common solution with some JavaScript validation:
Demo
While this isn't a terrible experience, I think there are a few other ways to handle this problem worth exploring. With some inspiration from a post on IxDA.org, I've created three below. Of note, all of these proposed solutions load a password field when the page is generated, so the browser will initially treat them as regular password fields.
Solution #1: Users click a checkbox to show characters
Demo
Pros: The decision to show or not show characters is fully at the discretion of the user. Passwords can be edited while characters are displayed.
Cons: It doesn't automatically switch back to a password field. People could accidentally keep it checked while they're filling out the rest of the form, leaving the password susceptible to prying eyes.
Solution #2: Users hold down a button to temporarily show characters
Demo
Pros: Users are able to see their password characters if they'd like and cannot accidentally leave the field in the show character state. This solution potentially feels more secure to users than solution #1.
Cons: The downside is that users cannot leave the field in "Show characters" mode while they're editing the field. They can only see what they've entered when the button is pressed down.
Solution #3: The password field automatically changes to show characters
Demo
Pros: As a user, this approach would be my personal favorite because it's the easiest option, and you always see your password as you're typing it in. I don't really care about other people seeing what I type, since I rarely find myself in situations where I notice or would expect people to leer at my screen.
Cons: When users first select the field and start typing, it will look and behave like a regular text field -- which may be startling to some. Users will not see that it switches to a password field until after they've entered something and clicked off of it.
Conclusion
None of the solutions presented here are the silver bullet for how to handle password fields in all situations. Depending on your users, your goals for the form, and your willingness to try something a little extraordinary, one of these options may make sense for your site. If anyone has any other ideas for how to handle password fields, I'd love to hear about it in the comments.
Update! April 16, 2009
In response to this post, Stephen Lewis from Experience Internet put together a writeup and demo for another alternative to password confirmation. His works very similarly to the iPhone password input field where the last character is momentarily a character before automatically switching to password "bullet".
Creating a Feedback Loop for Users
Over the last few months, I've worked on several projects that started with good, solid user research efforts. We've sent out surveys, performed interviews, run usability tests, and worked with customer support teams. It's exciting to start a design project with good input from users, but the research we've been doing made me realize how often we have to work without the benefit of good user insights. This got me looking around at tools that companies can use to get started on gaining insight into their user's needs. I found two that looked particularly useful, and easy to use: Get Satisfaction and UserVoice.