Sunday, March 15, 2009

When Designing to a Trend Goes Bad

Do you prefer seeing a post marked 'Friday', '2 days ago' or '3/12/2009'?

I find myself translating a lot because I need to compare two dates. And if the date I need to compare with is expressed as '3/11/2009', then the 3rd format above is easiest to compare. The other two formats require a bit of transformation (in my head) to make that comparison possible.

We are all accustomed to seeing dates and times in our emails and other digital lists that give us an idea of how old each item is. But in recent years, we have been seeing these indicators expressed as 'yesterday' and '7 minutes ago'. This is kind of cool. It seems to raise the apparent intelligence of the machine. And in some cases it really fits better - especially if the comparison that needs to be made is to 'now'. By translating into how old the event is, we get the comparison to now without having to do any math in our head. This is a great reason to display the information this way.

But a far more egregious problem than making me do date math in my head is presenting flat out wrong information. If you display the text '3 minutes ago' on a page that is statically rendered and the user glances back at the page 3 hours later and still sees the text '3 minutes ago' displayed, it's just flat out wrong. As a programmer you didn't intend it to be wrong. But because you do not constantly update the page, the message is wrong a minute after you display it.

Twitter's home page and Facebook are the biggest offenders of this principle (presently). I may not have a chance to look at my twitter page for a couple of hours. And when I come back to it, I can never figure out how long ago I updated the page and how far back to go to see all of the updates. This is an example where displaying the actual date and time would be far better. The date/time of the post is a static piece of information. It doesn't change so displaying it (rather than an expression relative to now) in static page content is a great choice. I may have to do the math to figure out how long since I looked at the page. But at least I can figure it out and know how far down on the refreshed page I will need to read to catch up!

Interestingly , Ebay solves this problem in a different way with a 'time left' display that updates itself every second - so you're never looking at stale data - plus you don't have to do the math to figure out how much time is left (comparing 'now' to an auction end date).

So if you find yourself trying to decide how to display date/time information for an item, consider these (sometimes opposing) design elements: First choose the format that makes the most sense for the user of the system. If the logical choice is something relative to now, make sure that the value updates as 'now' moves. If that is not possible because of the platform, consider ways of helping the user - either with a clue that the data is stale (date/time stamp on the page) or by simply going back to an actual time display format.

Bottom line: You don't want to show '7 minutes ago' just because it's trendier than '12:37 pm'.

Saturday, March 7, 2009

Purpose of design IS function

This is a rather intricate topic. But I think it's appropriate for my inaugural post since it is so fundamental.

Many people have debated form vs function in the design of things. What often gets missed is the essential point - that function leads and form follows. A deeper exploration of this topic as it pertains to web site design is coverd masterfully in Form vs. Function: Finding the Balance which addresses web site development.

What I address in this post is some of the more subtle forms this takes in software application design - not just the grand layout.

I develop software for a living and have been an 'observer' of the world of Apple for a few years, but mostly worked on PCs. After watching the Steve Jobs keynote last March announcing the iPhone SDK, I couldn't contain myself. I bought a MacBook Pro and an iPod Touch the same week.

Of course the iPhone had no 'to do' application. But that would come in 3 months with the App Store. So I just had to wait.
As I waited, I researched the topic and two apps for the Mac bubbled to the top - OmniFocus and Things. (I had recently started adopting the Getting Things Done approach).

I tried OmniFocus on the Mac and found it overly complicated.
I tried Things on the Mac and found it about right.

I didn't buy either though because my 'to do' app needed to be one that really shined on the iPhone - since that is the device I would primarily use for to-do's.

Finally when the app store launched, they both became available.

First I bought Things. I preferred it on the Mac and thought it could work on the iPhone. Plus it was $10 instead of $20 for OmniFocus.

I quickly became frustrated with Things because of the lack of support for tags on the iPhone. The ability to list to-dos by context was one of the most important features to me. I have hundreds of to-do's. And if there is no way to filter them down to the set I can accomplish within the context of the situation I'm in, it is overwhelming.

So, I bought OmniFocus.

I held off on buying any Mac to-do app since that would be a bigger purchase. And I still wanted Things to work out. So I waited - and used OmniFocus on the iPhone.

After a couple of months, I got frustrated that Things was not getting this critically important 'contexts' feature. Plus not being able to sync with the Mac, decided to purchase OmniFocus for the Mac. This is no small purchase either. $80 for a 'to do' app is a good chunk. Ultimately the justification for that purchase comes down to time. I couldn't bear wasting time because of the inefficiency of my 'to do' processing.

What is interesting to me are the factors that pushed me one way or the other and how they relate to design and timing. For instance, why did I 'want' Things to work out? A. I liked the simplicity of the application and B. The checkboxes are more satisfying to click done.

A. Simplicity is a double-edged sword. I wanted a simpler application, but ultimately it was the simplicity that killed it. If it was slightly more complex and had contexts (or 'tags' in the Things vernacular), I would have stuck with it. (Things Touch now does have tags). What I really wanted was 'just enough' - that right balance of just enough functionality without making it more complicated than necessary. Things fell just short of my minimum requirement.

B. The checkboxes in OmniFocus are very large - too large. Whereas in Things they are smaller. They just look more checkable and I found it more satisfying to check things off.
This is absolutely the most minor thing one could imagine in a piece of software. But it brings up an important point regarding the relationship between form and function. In this case the form aids or detracts from the function expressly because of the desire it creates in me as I use the application. Function again reigns as the master. But the form is essential to achieving the function. In my case OmniFocus still won out. But a big part of wanting Things to work out was the way I felt as I used it.

When is the last time you stopped using an application or switched to antoher application just because its appearance was less than desirable?

And then there are gimmicks...

I have to admit that when I purchased OmniFocus for the iPhone, I made an impulse decision based on a feature it has that in 9 months I have never used once. OmniFocus can show you to-dos that can be done within X miles of your current location. The idea of the feature intrigued me and motivated an impulse purchase. But in practice, the effort of setting up the information for this feature to work well is too great. Plus I really don't have many to-dos that can't be done at home or the office or 'anywhere' I have my phone with me. I likely would have purchased OmniFocus anyway. But it was essentially a gimmick that hooked me early.

BTW, I don't mean to diminish the value of the feature by calling it a gimmick. I'm sure there are people that get a lot of use out of it.

The real irony to my whole 'to do' story is that 90% of the time I use due dates to whittle my to-do list down to a manageable size - and I ignore 90% of what is in the app. I don't even use contexts that often! I probably could have used Things after all.

Bottom line: Design matters to function - but often in ways you do not expect.