I felt like it was worth putting forward a little extra information on the subject of this article, specifically one passage which leapt out at me: "One of the worst things you can hear when working on user interfaces is the classic disagreement breaker: let's make it an option. If you're brave enough the response should be: let's not."
I couldn't agree more, and I wanted to go into more detail and offer a specific example. I was providing some on-again-off-again intermittent voluntary development work on a site I rather enjoy using. The site has users; users have homepages; the site has pages; users can bookmark pages; the list of each user's bookmarks appears at the bottom of the user's homepage. The list was just a bog-standard <ul> and a list of page titles, each a hyperlink to the page. I'm using my own content for examples:
<ul> <li><a href="digital">On Digital Extremities</a></li> <li><a href="crushed">Crushed Underground</a></li> <li><a href="oyster">Oyster ring</a></li> <li><a href="coffin">Time travel in Primer</a></li> <li><a href="anomaly">The Sherbrook Road Anomaly</a></li> </ul>
The question which we (the nominal development team) received from several users was: "What order are my bookmarks in?" Because they weren't in any sort of order. Sometimes most of them appeared to be in roughly alphabetical order, but not often. Sometimes, if you looked at the dates on which each page had been created, it looked like the links were in increasing order of date of page creation (not that date of creation was displayed anywhere in the bookmark list itself), or in order of date of bookmark creation (ditto), but there were exceptions and puzzling outliers. It was more or less random.
Of course anybody with a rudimentary knowledge of databases could answer this question instantly. The database query which was used to fetch those bookmarks had no ORDER BY clause, and the bookmarks were simply being retrieved in the fastest order that MySQL could manage. Naturally, the order frequently resembled the order in which the data had been originally inserted into the database.
So what order should the bookmarks be returned in?
"Let's make it an option!"
<a onclick="sort('desc', 'pagename')">Sort by name</a> <a onclick="sort('desc', 'tstamp')">Sort by date</a> <ul> <li tstamp="1028943143" pagename="on digital extremities" ><a href="digital">On Digital Extremities</a></li> <li tstamp="482910104" pagename="crushed underground" ><a href="crushed">Crushed Underground</a></li> <li tstamp="993804320" pagename="oyster ring" ><a href="oyster">Oyster ring</a></li> <li tstamp="1299301001" pagename="time travel in primer" ><a href="coffin">Time travel in Primer</a></li> <li tstamp="1120404940" pagename="the sherbrook road anomaly" ><a href="anomaly">The Sherbrook Road Anomaly</a></li> </ul>
We've added the option for the user to sort their bookmarks into any of four different orders: timestamp ascending, timestamp descending, page name ascending, page name descending. Fine.
The problem was not solved with MySQL: the initial query which retrieves the bookmarks still has no ORDER BY clause. The data is still in that initial random ordering, which is different from any of the other four, when it first appears.
You can also see that we've added nonstandard attributes tstamp and pagename to all of the list items, breaking standards compliance. Broken HTML I can stomach. Nobody's human. But HTML designed to work by being broken, and not even with the excuse of doing so to cope with a browser issue? Urgh.
Without looking at sort() you can't know this, but we don't actually store this preference anywhere; every time the user visits a user's homepage, s/he has to sort the bookmarks manually at least once to get the order desired.
So it's a pretty terrible implementation of the solution. But that's tangential to my point. Nobody actually asked for this option to be implemented at all - whether well or badly. Nobody actually asked, "Can you make it so I can sort my bookmarks?" The question was "What order are my bookmarks in?" and the answer was "None in particular".
And then, implicitly: "User Story: As a developer, I want users to stop bugging me about this."
<ul> <li><a href="crushed">Crushed Underground</a></li> <li><a href="digital">On Digital Extremities</a></li> <li><a href="oyster">Oyster ring</a></li> <li><a href="anomaly">The Sherbrook Road Anomaly</a></li> <li><a href="coffin">Time travel in Primer</a></li> </ul>
Giving the user options up front (or even in some hidden control panel) doesn't void your responsibility.
Firstly, an interface can and should be perfectly acceptable and usable before any options have been selected. Users don't necessarily care about tweaking options to their satisfaction, and/or can't be bothered to invest the mental effort or time to form an opinion on such matters. They just want to get stuff done without anything confusing happening which might require them to slow down to think. This is the "Next next next next OK accept install" usage pattern (it probably has a better name). Option or no option, the default configuration still has to be chosen very carefully because 90% of users will plump for it. A decision still has to be made.
Secondly, "Make it an option!" means that now you have to implement that option, and implement it well. You have to support all the choices, even the "bad" ones. On the same website mentioned, we allow users to create and upload custom stylesheets, replacing the default and making the site look nicer. "Let's make it an option! The entire site design, I mean! Infinite choice!" Now, there are dozens of stylesheets. Many of them are very popular, used by hundreds of users. But many of the stylesheet designers have since fled or stopped maintaining them. So we can't make the slightest design change in the underlying HTML without breaking the UI and making the site look terrible for someone. Maybe this isn't something which happens so often, but I sure regret it.