Say The Secret Word! January 19, 2009
Posted by Chuck Musciano in Random Musings, Technology.Tags: Interfaces, Security, Software, Users
add a comment
It has become fairly common for sites to enhance their security by asking you to answer a few “secret questions” to confirm that you are, in fact, you when updating account information or even just logging in. As a result, users now have the opportunity to forget several bits of information for each web site they visit, instead of just forgetting their password on a regular basis.
We use this approach at my company, where users can reset their passwords by answering special questions. The system we use even lets people pose their own questions, which led to one user to create this question:
Question 1: How do you feel today? Answer 1: Good
So far so good. Here is their second question:
Question 2: How do you feel today? Answer 2: Bad
I kid you not. Not surprising, this user eventually forgot their password, and it took quite a while for us to figure out why they could never access the automatic password reset system.
Here’s my helpful usability tip for the day: No matter what the secret question, use the same answer every time. Choose something different from your password, but use it consistently.
People are astounded when I suggest this. It never occurs to them that the system cannot check to make sure that “groucho” really is the name of the first person you kissed, or your first pet, or your second grade teacher. It just wants a string of characters that only you know.
Before all the security people reading this freak out, I’ll concede that this is not a security best practice. It leaves you vulnerable to some tiny chance of a security breach. You assume all the risk if you choose to go this route. Et cetera.
But in reality, this is much better than the approach most people take, which is to write all this stuff down on a Post-It note and stick it on the monitor. (Security-conscious users put the Post-It under the keyboard, or in their desk drawer. Thanks for incorporating physical barriers into your security practices!)
Security breaks down when security systems are too complicated. People revert to simple solutions just because they want the computer to get out of the way and let them accomplish the task at hand. We need to stop creating complicated, unusable systems and focus on simple, usable ones. With security, as with everything else on earth, it is tough to make things foolproof because fools are so ingenious.
Brownie points to readers who know why I chose “groucho” as my answer!
At The Tone, The Time Will Be… January 16, 2009
Posted by Chuck Musciano in Technology.Tags: Interfaces, Time Zones, Users
4 comments
When it comes to user interface pet peeves, I don’t just have a few pets, I have a whole zoo. Today, let’s talk about time zones.
Many, many web sites want to know your time zone so they can correctly send you messages or set appointments or reminders. Fair enough. But the manner in which they ask for your time zone leaves a lot to be desired.
One long-standing tradition involves providing a pull-down menu with every time zone in the world, starting with Greenwich, England and heading east or west. Sometimes the list includes the official names of the zones, which may help, but often just lists the offset (in hours) from the time in Greenwich. This is sometimes known as “Zulu” time or the increasingly common “UTC,” which is the French acronym (acronym Français?) for Universal Coordinated Time. This is so handy: ask your Mom if she is in UTC-4 or UTC-5 next time you chat. I’m sure she’ll know in a heartbeat.
Occasionally the list presents you with major cities in each time zone. Presumably, you pick a big city near you and your time zone is set to match. Why, then, do they list several cities in each zone? Atlanta, New York, and Washington, DC, are all in the Eastern Time Zone (UTC-5, duh). Why three choices? Are we catering to the city slickers but rebuffing small-town America? Seems like someone is going to get offended, somehow. And then, you need that special time zone for Indiana, or at least you did until this year, and parts of New Mexico, I think.
You might also get prompted for Daylight Savings Time. I always read too much into this question. Are they asking if my locale use DST in general, or if it is in effect right now? In the summer, the safe answer is always “yes,” but in the winter you are rolling the dice, my friend.
I’ve seen lots of interfaces for setting the time zone, and they all violate the important rules of user interfaces: they require too much geeky user knowledge, they are hard to understand, and they make the user do more work than the computer.
All but one, that is. I recently came across a delightfully elegant interface that asks one simple question of the user: “What is your current time right now?” It then presents a pull-down menu with the current time in every time zone. The user just finds the time that is closest to their current time (usually within a few minutes either way) and the computer figures out the rest! What a concept! Gather one bit of trivial data from the user and do the heavy lifting to compute UTC offset, look up DST rules for that zone, and set the time zone accordingly.
Kudos to the developer! There is always a better way that respects the user and exploits the computer, if we only work hard enough to find it. Every aspect of every user interface should be this elegant and clever.
Another Web Irritant November 21, 2008
Posted by Chuck Musciano in Technology.Tags: Interfaces, Irritants, Software
2 comments
I understand that advertising helps keep vast swaths of the web free. I respect a site’s right to sell ads; I just wish they would respect my intelligence.
The latest affront to my self-esteem comes along with interstitial ads, those full-page popups that appear for a fixed period of time before letting you see the real content you were seeking. I don’t mind the ads; that’s part of life, and that’s why Firefox has all those clever ad-blocking plug-ins.
I do mind the inane message that accompanies the ad, the one that says something to the effect of “Please wait while your page is loading…” While my page is loading? Come on!
I suppose there are some folks who may think that web pages are handcrafted as you request them, with teams of web artisans standing by to put all that content together in the fifteen seconds that the ad stays on your screen. For those folks, it may seem like a courtesy to provide something to look at, instead of a blank screen and an hour-glass cursor.
If only they knew the exact opposite: your page starts rendering after the ad goes away, and the twenty-something web designer who put that “Please wait” message on your screen got a snarky chuckle over getting away with such a blatant, insulting lie. It’s as if a full page ad in a print magazine had a tag line at the bottom: “Please wait for fifteen seconds while we print the next page.”
How about a little truth in advertising? I’d much prefer a message like “Please, please take a moment to look at this ad. We’re running out of VC funding, and unless we get some positive cash-flow out of our ad-based revenue model, I’ll be looking for my fifth job in three years.” If I see that message on my screen, I’ll not only read the ad, I’ll click through just for good measure!
Old School Email November 19, 2008
Posted by Chuck Musciano in Technology.Tags: Email, History, Software
2 comments
Technology matures, and expectations change. Email, designed to be a slow, reliable messaging system, is now expected to be instantaneous. I’ve seen people send an email and then pick up the phone to call to see if it had arrived!
Twenty-five years ago, email was a hodge-podge of technologies, linking wildly different systems using all sorts of connections. Getting a message from here to there often required knowledge of your system, the recipient’s system, and all those in between. Email might take days to arrive, and never made it in just a few seconds. A well-connected site could get a message in a few hours, which was considered really good performance.
Our modern person@place.com addressing scheme masks a huge amount of complexity. Your message may actually travel among many nodes on the network to get to its final destination, and individual pieces of your message may take different routes before being reassembled at the end. You don’t worry about all of this, of course; you just click “Send” and magic happens.
This simplicity didn’t exist back then. Instead, your email address changed depending on where the message originated. In essence, your address was the route your message would take to get to where it was going. Each stop along the way was named, separated by exclamation points (known as “bangs”). Thus, the “bang path” for my email back in 1984 looked something like this:
...!gatech!mit!trantor!chuck
When the message arrived at the Georgia Tech server, it would be sent to the MIT server, which sent it to my server (trantor), which delivered it to me. The “…” was important; you replaced it with whatever you needed to get from your machine to the Georgia Tech server.
You were expected to know what to put in place of that “…” and if you didn’t, tools existed to help you figure it out. A vast database (ahem, “flat file”) listing every node in the network was sent around every so often. For each node, you could see what other nodes they would connect to, and from that list you could construct a route for your message. If your path to Georgia Tech was through kremvax and wustl, your address for me would be
kremvax!wustl!gatech!mit!trantor!chuck
You may wonder why every node didn’t just connect to every other node. Another historical fact comes into play: phone calls used to cost money, charged by the minute and varying by the length and distance of the call. Given tight budgets, each site would only call to other, nearby sites. Cross-country calls were rare, especially for lengthy data transmissions. Sending email overseas was almost unheard of. Instead, you built a route of short hops, constrained by local phone charges, and hoped for the best
To further reduce costs, sites only dialed out every so often, and sometimes only at night. After your message arrived at a site, it might sit for a day before the next scheduled transmission. If that transmission failed, it would sit for another day before a retry occurred. Mail moved, but it moved slowly.
As the modern internet began to grow, addresses began to merge. You might use part of a bang path after sending to an internet host:
trantor!chuck@mit.edu
Networks were not completely interconnected, so you might route through a gateway between two networks:
chuck%trantor.harris-atd.com@gatech.edu
It was confusing, constantly changing, and not for the faint of heart.
In comparison, email today is easy. Back in the day, email had to go uphill, through the snow, both ways, all the time. But when mail got through, you felt like you had accomplished something! So be thankful, and be patient. Try to wait at least ten minutes before calling to check on your latest urgent message.
The Effective CIO 