Last weekend, when I logged in to my bank's website to pay my bills, I discovered that they have added a new security feature. Now, if they think that a login is potentially fraudulent (even if I type my password correctly!), they'll ask one of three secret questions. I had to select the secret questions and give their answers. This turned out to be a usability nightmare.
This is another one of those messy intersections between security and usability. I've written about one of these intersections earlier, specifically about Entourage not automatically downloading images from the email you receive. Security, in this case in the form of authentication, is difficult. I have approximately eleventy billion passwords to remember. What happens when I forget my password? In the interests of usability and reducing calls to tech support, many places have given us the curse of the secret question. I'm not going to go into the security issues associated with the use of the secret question, that's someone else's blog post. But I will discuss the usability issues associated with using secret questions.
Once upon a time, there was only one secret question: what's your mother's maiden name? I'm not sure why there are more secret questions now. One potential reason is that there's a significant chance that the user has the same last name as their mother's so-called maiden name. But the new list of secret questions is horrible. Either I can't answer them because I don't remember the answer or one doesn't exist, or my answer doesn't fall within their parameters.
Let's take a look at some common secret questions.
That's just the usability problems with these questions. That's ignoring that most of these questions aren't really that secure. Any name associated with my parents is a matter of public record, since all of that will be on my birth certificate. Everyone knows my cat's name. Mascots and city names are susceptable to brute force attacks.
I don't claim to have an answer here. I understand why sites want passwords, and I understand why users forget their passwords. I understand why sites want to use secret questions to help authenticate their users. I'm concerned that secret questions solve neither the usability problem of users forgetting their passwords nor the security problem of the institution wanting to protect themselves and their users from fraudulent log-ins.
In an earlier post, I mentioned that there is a bevy of non-coding jobs involved in software development. According to Money Magazine, software engineering is #1 on their list of the best jobs in America. Their description of software engineering is as follows:
Computer software engineers apply the principles and techniques of computer science, engineering, and mathematical analysis to the design, development, testing, and evaluation of the software and systems that enable computers to perform their many applications.
User assistance: There are many different titles that this job takes, including technical writer and information developer. This is the person who writes the online help or written manual (if one exists). A strong understanding of software concepts is useful. You have to be a really good writer for this. There are several technical writing programmes at many universities, and some people recommend dual-majoring in technical writing and something else: computer science if you want to do software, biology/chemistry if you want to do medical writing, etc. According to Money Magazine, this is #13 on the aforementioned list of best jobs in America and #19 on the list is editor (which includes technical editing, so I include it here).
User experience research: This is obviously a topic that is near and dear to my heart. User experience researchers (sometimes called usability engineers, user research engineers, or human factors engineers) determine what users actually want their software to do, and figure out how to do it easier. This job includes conducting usability studies, ethnographic studies (where you go to visit the user in their home environment and observe them for an extended period of time, usually at least a day), surveys, and simply going out and talking to users at events like Macworld Expo and WWDC. There are several degree programmes that cover human-computer interaction, user experience, or user interface design.
Program manager: These people design the features that the developers code. This requires a good understanding of a lot of technologies and the ability to figure out how these technologies should fit into your software. An important part of being a PM is not getting caught up in what's possible or what's not possible, but in figuring out what is the best way to meet your customer's needs.
Software testing: These people are good at breaking things, and figuring out what
they've done to break things. This is a great way to go if you like solving problems. You have to be detail-oriented.
Product design: These guys make the software look good. This ranges from designing the individual icons to the whole window that you see when you open the app. Designers tend to have art degrees instead of CS degrees, but they also have a strong understanding of how users use their software. Designers are hugely important -- if your icons are indecipherable, or if the individual elements in the window aren't laid out in a way that users can figure out how to do what they want to do, your software isn't going to be successful.
System administration: These are the guys who keep the computers and the network running. They might also assist the other people listed here in doing their job. If you like putting together your own computer or if you're always the guy that your friends ask to help when their network goes down, this might be a good job for you.
Technical support: This is, in my opinion, one of the hardest jobs in CS. You have to have a deep understanding of whatever you're supporting. You have to be able to explain things well to all kinds of people, from complete novices to experts who have run into a problem. You have to be really good at dealing with people who are unhappy (after all, if they're calling tech support, they're probably frustrated). You have to be able to crawl into their head and figure out what the problem is. You wouldn't believe how many times someone calls tech support and says, 'my computer isn't working'. There are bad tech support people out there, but the ones who are really good are worth their weight in gold.
Localisation: These guys make the software work in other languages and cultures. Some of this is simple translation (English to German, Japanese, French, ... ), but a lot of it is understanding how to make software work well for other cultures. For example, they help us choose graphics that won't be offensive to other cultures. They have a strong understanding of international users, which a lot of American software developers are missing.
I'm sure that I've missed some, so feel free to add your non-coding software job in the comments ...
Happy update day! If you haven't noticed yet, Office 11.3.4 is now available. Download it from Mactopia, or go to the Help menu in any app and select 'Check for Updates', or just wait until Microsoft AutoUpdate runs.
The guys over at Rolling Stone sure do know how to get lots of hits to their site. A recent entry in their Rock and Roll Daily blog is titled Is Apple the New Evil Empire? They cite the dominance of the iPod and the iTunes Store, the vaporware that is the iPhone, and a complaint that Steve's recent thoughts on music are nothing more than propaganda. It's an interesting enough read, although I largely disagree with them.
This month, the MacBU is ten years old. One of the coolest things that has been done to celebrate our birthday was masterminded by Joe LeBlanc, one of the testers on the Excel team. With the help of two other folks and with more than 1300 sticky notes, they created a birthday message in the windows of our Redmond building. It's massively cool. Check out the whole story over in Mac Mojo.
Let me put forth an axiom: software development is hard. It's not just the coding bits that are hard -- they are, don't get me wrong, it's just that coding isn't the only thing that's hard about software development. There's more to software development than the coding, which is why software development has a bevy of non-coders working on the software.
One of the things that's surprisingly difficult about software development is crafting the error messages. (A second axiom, since I'm feeling axiomatic today: Software has bugs and unexpected problems that it can't handle on its own.) Error messages are so notiously bad that we make jokes about them, write error messages in haiku, and allow you to generate your own.
I've been reminded of how difficult it is to write good error messages a couple of times last week. I reviewed the error messages for RDC v2, which has its own challenges inherent in writing its error messages. Just think of all of the reasons that you might not be able to connect from your Mac to a Windows box, and figure out how to document them in a way such that the user can do something about it (if, in fact, there is something that the user can do). I really don't envy our user assistance team.
In the middle of that review, I've been using Pandora lately. I haven't been keeping music or podcasts on my work laptop (that's all been moved over to my Mac Mini in my office, since people seem to like my shared iTunes library), but I need something to listen to when I'm on the road. Pandora to the rescue. The problem with Pandora is that it requires a solid Internet connection, and my last hotel gave me anything but a stable Internet link. So when it ran into problems when I asked it to add another artist to my newest Pandora station, it gave me the following error message:
I'm sorry, I had a small problem while looking for that music. It's my fault.[try again]
I actually exclaimed, 'oooh!' out loud. I felt bad for the app, felt guilty for making it think that it was the app's fault. What a great error message! I didn't get upset or frustrated. For an app like this, the tone is just right. They don't need formal-sounding error messages, it's a nice little casual app, and friendliness is important for it.
So what's important in writing error messages? Don't tell the user that error 448115490235 just happened or that some generic system error happened, tell them the actual problem. Even better, tell them what they can do to try to fix it or at least troubleshoot the problem. Use the right words and a tone that's appropriate for your audience.
This all sounds easy enough, but it turns out it's not. Software engineers are notoriously bad at this kind of thing (nothing against you code monkeys out there!), which is why there's so many really bad error messages out there. Kudos to the Pandora folks for doing a pretty good job of it.