"Let's make it an option!"

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:

        <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>

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!"

Below is what we ended up with. This is not quite verbatim; a few minor Javascript coding horrors have been removed in order to clarify the point. You can probably surmise from context that the Javascript sort() routine (not shown) modifies the clicked anchor tag to change "desc" to "asc" and so on, so that clicking twice alternates between ascending order and descending order.

<a onclick="sort('desc', 'pagename')">Sort by name</a>
<a onclick="sort('desc', 'tstamp')">Sort by date</a>

        <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>

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.

  • Obviously, the problem was solved with gratuitous use of Javascript, and the solution doesn't degrade gracefully in the absence of a Javascript-enabled browser. You just get two useless <a>s.

  • 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."

        <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>

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.

Discussion (16)

2010-06-24 02:30:44 by bbot:

E2's dead anyway. Might as well alienate the two people still using it and break old stylesheets.

2010-06-24 07:20:30 by skztr:

I can't really take seriously the development woes of a decade-old site which is open to new developers, but has no way for people to edit code in a non-"live" environment, no sane version control, etc. The only reason there is no site like E2 to replace E2 is the chicken<->egg problem about content. No system can prove itself worthy of replacing E2 without already having replaced E2.

2010-06-24 14:52:20 by Thrack:

Is that why he didn't refer to E2 by name? It doesn't seem like what website it is should really matter though, unless something about its code makes this a unique problem for E2 alone. Can a similar example be given using a different website or software?

2010-06-24 15:36:33 by qntm:

Nobody mentioned E2!

2010-06-24 23:21:33 by DanielC:

E2's dead. Long live E3.

2010-06-25 04:10:01 by YarKramer:

What does the Electronic Entertainment Expo have to do with Everything2? It's like comparing Wikipedia to watching a movie. ;) Ooh, I have an even better (which is to say, worse) idea than "never changing the HTML-layout": Why not make the HTML-layout ITSELF an option!?!?

2010-06-25 18:32:07 by urza:

E2 may be dead, but this discussion is very much alive :) (and this is very valuable addition to it, with optional point).

2010-06-25 20:11:35 by Rangi:

I've been lurking on E2 until now, but I joined because I just had to see such a crazy solution to the problem of sorting a <ul>.

2010-06-26 02:00:02 by TJSomething:

How about E17?

2010-06-27 14:17:10 by pozorvlak:

There's a very nice <a href="http://tablesorter.com/docs/">jQuery plugin</a> that does exactly what you want, without requiring horrible HTML hacks. Ordinarily, I'd have said that you should have just added the ORDER BY clause (by date, I'd have thought) and seen how users like it, but the ability to sort a table by various things is actually a very useful one once the table gets above a handful of rows long, and common enough that users will have encountered the UI before. So you probably actually did the right thing in this case, modulo broken HTML.

2010-06-27 14:27:34 by qntm:

Well, yes. If only this was a table, and somebody had asked for that feature, and there was *anything* other than page name to sort by?

2010-06-27 16:41:36 by pozorvlak:

There's date of submission - and if you're going to make that a possible sorting key, you should probably make it visible. Table thing: yeah, sorry, didn't realise that changing your <ul>s to <table>s would run into the abandoned-stylesheets problem. Never mind - I wasn't seriously expecting you to switch E2 to using jQuery anyway. OTOH, it's a nice tool, and worth knowing about for the future.

2010-06-29 15:50:20 by qntm:

I think you may have missed the entire point of the article. Nobody wants a table, nobody wants the date for each bookmark to be visible, nobody wants the bookmarks to be sortable, nobody wants jQuery. You're solving problems which aren't there.

2010-07-01 10:44:02 by YarKramer:

No offense, pozorvlak, but I think you're actually making the exact same mistake as the people mentioned in both Sam's article and the blog he linked. There *was* no "problem" that needed to be "solved," and if there was, it was entirely on the dev team's end ("we want users to stop bugging us about this"). The bad implementation of that specific "solution" isn't (only) what's at fault here: it's the fact that they made an option where no options were needed or asked-for in the first place. Wait, I thought of a better (which is to say, worse) solution to the CSS/HTML issue: Make the HTML ITSELF an option!!! ... oh, sorry, I didn't mean to make your head explode ...

2012-11-26 02:31:30 by Justsomedude:

The less choices you give people to customize, the less chance you have of them breaking it.

2014-08-27 17:32:59 by TBFProgrammer:

The problem was that users couldn't retrieve information they wanted. This is a user problem that may be worth solving. One possible solution: A default bookmark labeled "Bookmark FAQ" which can be updated with any future questions about bookmarks.

New comment by :

Plain text only. Line breaks become <br/>
The square root of minus one: