One thing that some interface designers sometimes overlook is button text. In a lot of contexts, buttons are given default values that seem "good enough". But consider your button text carefully. I'll give you the negative example that spawned this very thought process.
I'm installing a program with the standard Windows installer dialogs. There is some setup to do, and when it is finished, I'm presented with a screen that informs that everything is kosher and the install can commence. The default button that will kick everything off reads "Finish". Erroneous! I'm finishing nothing! Adding to surreal nature of the dialog is the descriptive sentence above the button: "Click Finish to begin installation."
"Click finish to begin" is going to be my new "get up to get down".
Verbs are good words for buttons. Buttons do things, and the word should describe what's going to happen. "Submit" is a popular, though vague, button word. "Cancel" is another popular one. In my example, the answer was staring the programmer right in the face when he wrote the description: the word should have been "Install", since that's exactly what's going to happen when the user clicks the button.
Give some thought to your button labels and make their purpose clear. If whatever IDE you're using provides defaults ... well, try to make it not to. Forcing yourself to fill in that text won't be a bad thing.
Thursday, July 16, 2009
Monday, March 30, 2009
Order Up!
A quick note on form elements and tab ordering: if you are going to include links inside the form to provide more information on what a field is doing, you MUST unequivocally and without question, absolutely with no exceptions, positively set the tab ordering on your form so that those links are not included in the ever-popular keyboard shortcut of tabbing to the next item in the form.
Breaking the flow of "enter data - tab - enter data - tab" by highlighting help text interrupts the user's expectations, possibly to such an extent that said user will stop mid-form to write about it on his blog!
Breaking the flow of "enter data - tab - enter data - tab" by highlighting help text interrupts the user's expectations, possibly to such an extent that said user will stop mid-form to write about it on his blog!
Tuesday, March 10, 2009
On Public Speaking
For my own future reference, and because it may interest others, here's an interesting post I found via Boing Boing today. Duncan Davidson's "Dear Speakers" - a few notes on public speaking from a man tasked with photographing talks and round tables and the like.
Monday, December 15, 2008
Usability Testing in the Wild
This post over at BoingBoing describes how Meetup does usability testing: quick, dirty, and often. This is my ideal approach, too.
You see, I recently did a usability test here at SEP for an internal project. Unfortunately, I haven't had a lot of spare time to compile my results (either from the test itself or my upcoming report, "Why Usabilty Testing Is the Best Thing Ever, I Mean, Really"). But, because the test took on a similar form to Meetup's, my lack of "finished report" isn't that big a deal - the tool's developers observed the whole test and were taking notes the whole time. That, coupled with a few ten-minute "here's something you might not have noticed" discussions, gave the team enough feedback to fix (hopefully - I haven't seen the latest revision yet) a lot of the usability problems.
P.S. Because I haven't mentioned it before, if you're interested in the whys and wherefores of usability testing, you can do worse than to start with Steve Krug's Don't Make Me Think, which covers usability testing in brief, including instructions (which I took to heart) on how to do it for cheap.
You see, I recently did a usability test here at SEP for an internal project. Unfortunately, I haven't had a lot of spare time to compile my results (either from the test itself or my upcoming report, "Why Usabilty Testing Is the Best Thing Ever, I Mean, Really"). But, because the test took on a similar form to Meetup's, my lack of "finished report" isn't that big a deal - the tool's developers observed the whole test and were taking notes the whole time. That, coupled with a few ten-minute "here's something you might not have noticed" discussions, gave the team enough feedback to fix (hopefully - I haven't seen the latest revision yet) a lot of the usability problems.
P.S. Because I haven't mentioned it before, if you're interested in the whys and wherefores of usability testing, you can do worse than to start with Steve Krug's Don't Make Me Think, which covers usability testing in brief, including instructions (which I took to heart) on how to do it for cheap.
Tuesday, May 20, 2008
Security vs. Usability, SUNDAY SUNDAY SUNDAY
Forewarned: I talk about the issue of non-usable web security, but this is one of those cases where I don't really have an opinion about how things could change for the better. But I do think it's something to think about.
Web security is a Big Deal. One of the biggest, in fact. No major website today can get away without paying very special consideration to security. Unfortunately, security and usability are pretty much the oil and vinegar of the web application world. After all, from a usability standpoint, we want to get out of the user's way and present the information as quickly and cleanly as possible. On the other hand, security-wise, we want to take every precaution and ensure that the person viewing the information is, in fact, the person they claim to be. And, because most users will agree that it's more important to keep their information secure that it is for them to have easy access to that data, security usually takes precedent.
Unfortunately, a lot of modern security methods don't just get in the way of usability, they outright prevent it. Consider the modern-day gatekeeper to all data financial - the security question. Most online banking, financial planning, and portfolio management sites use security questions to verify who you are. Some of these sites ask these questions randomly during your visit, others only use them to verify identity when changing passwords. And, for the most part, they're pretty secure. After all, who but me is going to remember that my first pet was a collie named *REDACTED*, or that I grew up in *REDACTED*.
Of course, my life is a fairly simple one, and I remember the answers to these "simple" questions. Except that my first pet was actually a cat named "Mama Cat", and I actually grew up in a tiny town named Francisco, which is just outside the town I tell everyone I grew up in. Depending on the day, I answer these questions differently. So it's less a game of "This is Your Life" and more "What's My Line?".
In Lore Sjöberg's "Test Your Brain with Trivial Security Questions", this very phenomenon is addressed, with the winner of Lore's fictional game show being the person who circumvented the security altogether. In short, this person made the page more usable by sacrificing some of that well-thought-out security. And this happens a lot. Passwords get written down on sticky notes and "hidden" under keyboards or behind monitors. (Or, worse, in one case I've seen, sticky noted to the front of a monitor. For everyone to see. In a public area. At a hospital.) Maybe all the answers to your security questions get jotted down in a text file six directories deep and named "Completely Uninteresting Innocuous File.txt".
This is not to say that security is bad. It's not, not at all. But I think that usability is actually more important that most users let on. So if anyone out there is working on a usable security method, the world may soon be beating a path to your door. Just so you know.
P.S. My personal favorite security circumvention: my bank uses biometric typing data to identify whether or not it is actually me typing in my password. How I type varies dramatically from day to day (I don't touch type. At all.), so this method always fails. My new way to check my balances is to skip the password box altogether, hit the "Forgot my password" link, answer the security questions and just change my password every time. Bonus side effect though: I now know the answers to those security questions without even thinking. So that's nice.
Web security is a Big Deal. One of the biggest, in fact. No major website today can get away without paying very special consideration to security. Unfortunately, security and usability are pretty much the oil and vinegar of the web application world. After all, from a usability standpoint, we want to get out of the user's way and present the information as quickly and cleanly as possible. On the other hand, security-wise, we want to take every precaution and ensure that the person viewing the information is, in fact, the person they claim to be. And, because most users will agree that it's more important to keep their information secure that it is for them to have easy access to that data, security usually takes precedent.
Unfortunately, a lot of modern security methods don't just get in the way of usability, they outright prevent it. Consider the modern-day gatekeeper to all data financial - the security question. Most online banking, financial planning, and portfolio management sites use security questions to verify who you are. Some of these sites ask these questions randomly during your visit, others only use them to verify identity when changing passwords. And, for the most part, they're pretty secure. After all, who but me is going to remember that my first pet was a collie named *REDACTED*, or that I grew up in *REDACTED*.
Of course, my life is a fairly simple one, and I remember the answers to these "simple" questions. Except that my first pet was actually a cat named "Mama Cat", and I actually grew up in a tiny town named Francisco, which is just outside the town I tell everyone I grew up in. Depending on the day, I answer these questions differently. So it's less a game of "This is Your Life" and more "What's My Line?".
In Lore Sjöberg's "Test Your Brain with Trivial Security Questions", this very phenomenon is addressed, with the winner of Lore's fictional game show being the person who circumvented the security altogether. In short, this person made the page more usable by sacrificing some of that well-thought-out security. And this happens a lot. Passwords get written down on sticky notes and "hidden" under keyboards or behind monitors. (Or, worse, in one case I've seen, sticky noted to the front of a monitor. For everyone to see. In a public area. At a hospital.) Maybe all the answers to your security questions get jotted down in a text file six directories deep and named "Completely Uninteresting Innocuous File.txt".
This is not to say that security is bad. It's not, not at all. But I think that usability is actually more important that most users let on. So if anyone out there is working on a usable security method, the world may soon be beating a path to your door. Just so you know.
P.S. My personal favorite security circumvention: my bank uses biometric typing data to identify whether or not it is actually me typing in my password. How I type varies dramatically from day to day (I don't touch type. At all.), so this method always fails. My new way to check my balances is to skip the password box altogether, hit the "Forgot my password" link, answer the security questions and just change my password every time. Bonus side effect though: I now know the answers to those security questions without even thinking. So that's nice.
Monday, April 14, 2008
Standards and Quirks
In the olden days, every browser rendered things differently. Complicating matters, most of these browsers paid only the slightest attention to the standards set forth by the W3C, so web designers either spent a whole lot of time and money figuring out how to render their pages correctly in all browsers, or just wrote their pages for one browser only. Now that the most popular browsers have come around to following the standards, a whole lot of established web sites are having to make some changes to keep up.
Eric Meyer has a good write-up on this topic, wherein he covers the differences in the older browsers, how to keep some modern browsers in "quirks" mode (which causes the browser to render pages just as their non-standard compliant predecessors did), and lists some additional resources for the tragically interested.
For anyone updating old web code, this is essential reading.
Eric Meyer has a good write-up on this topic, wherein he covers the differences in the older browsers, how to keep some modern browsers in "quirks" mode (which causes the browser to render pages just as their non-standard compliant predecessors did), and lists some additional resources for the tragically interested.
For anyone updating old web code, this is essential reading.
Welcome, humans!
Howdy, all, and welcome to the technical blog of one Matt Sheehe. It is here I intend to post insightful and meaningful words on the topics of web design, software engineering, and technical matters in general.
Subscribe to:
Posts (Atom)