I have been reading and thinking recently about the idea of simplicity in software, and really in any technical design problem. Take a look at these posts from Donald Norman and Joel Spolsky – I couldn’t agree more with both conclusions! When you start to think about what you personally feel is the most powerful software you use, I would wager you will find it is not actually that simple – even if its ultimate goal is straightforward.
Let me provide an example – my new favorite tool and site, Remember the Milk. It might sound a little weird, but I have struggled for more than a year now looking for an effective to-do list application. Before this Web 2.0 push to online applications, I downloaded every to-do application listed on Download.com, and disliked every one. Granted, that might be because there is an inherent flaw in trying to track your to-do list on a single computer when you use on-average two or three computers during your day, but I was uninterested in using some component of a larger site, such as Yahoo, and until recently individual web applications were a little more rare.
I have carried a palmtop or blackberry for several years now, so my next logical choice was to use the task list in Outlook, since it would sync with my portable-of-the-moment. But, as much as I am used to (I am not 100% sure I would go so far as to say “like”) Outlook for other tasks (I use the calendar heavily), I found something about the task list restrictive. I had trouble placing my finger on exactly why at the time, which only made my search for a better app harder. Eventually I began to realize my troubles were related to getting a list of real to-dos into the app in a readable way, versus a list of maybe-to-dos, someday-to-dos, etc. In other words, the disparity between tasks that had an immediate deadline and tasks that just “had to get done sometime soon” was noticeable. And that was not a good thing – it was difficult to track both types of tasks in the same UI.
Enter Remember the Milk – which on the surface, seems very, very simple. You have two basic lists and an inbox and outbox for receiving and sending tasks. Tasks at a minimum are just a single line (example: “remember to bring home milk”), at a maximum they can have notes, a prioritization, a due date, etc. The more I use RtM, the more I see where Outlook falls short – the UI in outlook is always as complex as its starting point, that is, regardless of the type or complexity of the task I am tracking, I have to wrestle through the same fairly complex UI to track them (and if you want to customize the UI – well don’t even go there unless you are a power user). Remember the Milk’s approach is different – the UI adapts to what I am trying to track.
What do I mean? Adding a task always starts with typing that single slug – and then I add detail as I go. Any task can have a little or a lot of detail, but they all still appear in the same list. Even more important, only the text boxes I need appear at a given time (literally) – when editing the notes for a task, I don’t also see the clutter of the date box, radio buttons for priority, etc.
This perceptual simplicity hides actually a complex-enough database to track virtually all the tasks I deal with (I am not using this as a Gantt chart, granted). In reality, RtM can track tasks by category (tags), associate URLs with tasks, set priority separate from due date, and much more. But where do you start? Typing in a single-line task into the list the task belongs on.
My favorite, micro-example of this philosophy is their due date entry box. When I click the little icon next to due date, I get a text box, ready to receive my due date. What can you type? Intuitively, you want to type many different things here: in one week, tomorrow, January 2nd, 8 PM, January 2nd at 8 PM, etc. What can you enter into RtM’s box? All of the above! Try it out. It correctly interprets all of the above examples and many more. That is exactly how I want to use a due date box – typing it is 10x faster than using a calendar tool or date drop-down, but I want to type it any way I am thinking about it, not in some ISO standard date format.
I never liked the principle of KISS – Keep It Simple, Stupid. I think it portrays the type of simplicity that Donald and Joel are talking about in their posts – simplicity that is not really useful to the user. The wikipedia definition of KISS says that some people feel Unix was entirely developed under this principle, and I think that makes a great example. Flavors of Unix have their strengths but I don’t think that anyone would argue that ease-of-use to non-technical users is one of them. In fact, that built-in simplicity to the code makes user actions generally extremely complex (in the form of multiple steps of command-line input with a sometimes cryptic syntax – go ahead, try to change permission on a unix box using chmod). However, the “alternative”, if you will, is not appealing either – the alternative here being Outlook’s task management – where they made a nice UI, but that UI represents every single possibility the applications is capable of.
I think KISS ends up being more for the developer and less for the user, which has some postiives but some negatives as well. So in place of KISS, I propose a new principle – Solve It Through Simplicity, or maybe alternately Solve It With Simply. How is this different from KISS? Specifically, for software development, it means your software might not be simple at all, but keep in mind that what your user wants to do probably is (or more correctly, what your user wants to do starts simply), so present to them only what they need at that moment, and learn from what they have done just before to guide them to the data the application will need next (maybe in another post I will go into the difference of learning from what the user just did versus what the user has always done – the former is the powerful, the latter is often misguided).
So next time you are approaching the design of a new application – remember to SITS on it!