March 31, 2005
Card Sorting
Today at work I got to do some more Card Sorting exercises. Those are one of my favorite pieces of usability work.
For this situation we used the top 100 search keywords entered into a knowledge base type tool, the purpose was to come up with a "browsing" type navigation that would be optional to the keyword search. So to see how users group the content we wrote all the top searches on the cards. The hard thing about naming groups in web design is you want to keep the names relatively short, but most of the time people like to call a group of things a fairly long name.
Another thing that is hard is picking good Card Sorting candidates. It's really bad to get anyone inside the design group to do it because we are all biased web designers who think inside the standards that we know, sometimes this is not a good thing when your trying to think like a "user" and not a web designer. Also if your actually working on the project your going to have lots of biases towards the current or planned navigational groupings.
I was able to get two people in our group who are not on the project but I won't feel good about it until I get people who can give me less biased feedback.
Posted by brandy at 03:49 PM | Comments (0)
March 16, 2005
AJAX & Usability: Let the user be in control
I'll start off by saying this is not my trying to knock this most awesome example. I think it's so great that people are experimenting with AJAX. It's waking a lot of us up who have been asleep for a while, and I also think it's going to improve the design of a lot of applications.
With that said I thought I would express some of my concerns with it's use. Just because the form now doesn't need a login button, doesn't mean we should take it away from the user. It's an important concept that the user feel in control, and even more so that an action has a reaction. If they submit their info, then the system will come back with a reaction and let them know how it worked. It also adds a feeling of security.
By removing the submit button you are relying on the fact that the user will know to click outside of the text field to find out if they logged in correctly, and for gosh sakes if they have to click OUTSIDE the field to get the system to tell them they are logged, why the heck not give them a button to click on! It's the same amount of energy and time required by the user and a lot more clear. Or if you have it set on a timer that they will wait, or if your timer is to fast that they won't get annoyed by it when they arn't done thinking. If you are going to rely on ANY form of action from the user to confirm that they are finished, you might as well provide a submit button.
One example that has been mentioned is when a user is installing a program and they have to input a serial number and they get the nice green checkbox over to the right that lets them know they can continue. If this was to be used properly in the context of a login module, then when the users moved their cursor from the username field, to the password field, you could have a checkmark or message appear beside that field, letting the user know if that username exists in the system at all.
If you include a submit button and the password is incorrect then your message can appear. The page still doesn't have to reload, and the user is still in control.
Here is an excellent example of an AJAX module that I think has very good usability.
View the graffiti wall example
Also another point if your still reading, it's not very helpful to have a page with two login fields disabled. From a purely esthetic perspective it wouldn't lend much to the design. You could of course have it update on any other pages in the application, but the user may think they actually didn't login till they went to another page because they think seeing the "logged in" module without the fields means they are actually logged in. Now I'm getting fairly convoluted here but the designer in me just had to say something!
Posted by brandy at 08:54 PM | Comments (0)