Why Design Cannot Ignore Performance...

I have been using OmniFocus for a full year now. I track hundreds of items in it and use it daily (multiple times per day) to get things done. It has become an essential part of my life.

Lately I've become fed up with OmniFocus. Well, actually I've been fed up with OmniFocus for several months. But I've kept using it because the cost of switching is so high. No more. I bit the bullet and committed several hours recently to replicating all of my action items into Things.

What was so egregious about OmniFocus?

It comes down to one thing really - how long it takes to record a new 'to-do' (or task) for myself.

Consider this: From the moment you hit 'new task', it may take you 10 seconds to record a new task like 'pick up the dry cleaning'. In a lot of situations where you're in conversation or doing some other activity, taking a 10 second break is acceptable. Your spouse will wait for you. (Your boss might not, but your spouse will.)

But suppose it took a full minute to launch the application and get a usable entry screen? Now we're talking about a break long enough for the other person to engage in their own time-filling activity. It's completely disruptive.

To be fair, it doesn't take OmniFocus on the iPhone a minute to launch. Though it can take 10 or more seconds. It likes to 'optimize' the database before giving me any control. Then once I get control, I don't actually have control because it starts syncing with a remote copy of the database and the UI is unresponsive. This is where it goes way beyond the 10 seconds. Why must syncing take all available CPU so that the UI is unresponsive until it is done? And why must it 'optimize' the database before I get a usable entry screen? Regardless of why, the end result is way too many seconds until I can make a new entry.

As it turns out all of these extra seconds are not just 'less seconds' out of my day. Rather, I noticed myself actually skipping the recording of a new task thinking, "I don't have time to wait right now. I'll do it later." This of course completely defeats the purpose of the list - to get stuff out of your head!

About syncing...

I use OmniFocus on the Mac together with OmniFocus on the iPhone. The iPhone version is the more important user experience because that is always with me. But I use the Mac version to do more comprehensive reviews where lots of screen real estate comes in handy. So I have to sync the two.

OmniFocus syncing is severely lacking. It routinely takes a full minute or more to sync even when I've only changed a couple of action items. The algorithm appears to transfer a lot more data than necessary. And I've had more than one occasion to have OmniFocus tell me that it couldn't resolve something and that I would have to choose to start fresh from either the local database or the database on the server. (At which point I'm supposed to remember what I edited since the last sync so that I can make this choice wisely and minimize re-entry. This also kind of defeats the purpose of making a to-do list in the first place).

As a programmer I know that syncing does present interesting challenges. But this is a problem that has been solved quite well by many people. The folks over at OmniFocus need to invest in an overhaul of their sync algorithm or this is going to continue to frustrate users.

I could share many examples of great syncing experiences I have with other products that just work. But the list is pretty long, so back to OmniFocus.

I thought for a while that part of the problem might have been the fact that I was syncing OmniFocus through MobileMe. But after trying the local sync option for a while and experiencing the same problems, I can no longer blame MobileMe.

The OmniFocus sync solution may be 'good enough'. But because of the interplay with launching the app and getting a responsive interface, 'good enough' isn't.

Now that I've switched to Things, I never have to wait more than a few seconds for a sync to finish. The folks at Cultured Code got this one right.

I'll cover more differences between OmniFocus and Things in a future post - after I've had a year to live on Things. For now OmniFocus lost for failing at the most basic task - quick entry. They designed a good quick entry screen. They just didn't start measuring quickness from the moment the user taps on the application icon to launch it.

When Feedback Loops Go Missing

I've been noodling around a couple of thoughts for a while now about Twitter - one having to do with what I'll call a Publisher Rank (similarity to PageRank intentional). The other has to do with the meaninglessness of Twitter social climbers who follow too many users to ever possibly read their tweets. The two thoughts go hand-in-hand and their relationship is interesting. But I avoided the topic because it had nothing to do with design. Plus, my last post was about Twitter.

However, something occurred to me as I was unfollowing someone because he was too chatty. I realized that the user probably had no idea I was unfollowing him - and most certainly would not learn anything from my unfollow. Of course Twitter does not notify for 'unfollow' operations. (Twitter users can employ services like Twitterless or Qwitter to figure out they have been unfollowed. But most don't use these services.) And compounding the problem, users think they have no reason to look for unfollows because their follow count keeps going up. After all, they must be doing something right since their follow count keeps rising. Right?

The fallacy in this is two-fold: 1. The Twitter population is growing so fast that everyone's count is going up just as people try out the service. 2. The social climber doesn't care if you tweet too much. After all who can follow thousands of tweeters anyway - just ignore everything and follow to be followed.

The bottom line for every publishing twitter user is that the feedback loop is quite broken. And this is the loose tie-in to design. Twitter publishers have designed their behavior to draw in followers. But the feedback loop for validating their design is essentially missing.

This can be fixed with some effort.

1. Watch for 'unfollow' operations. You don't have to obsess about every one. Just keep track of how the number correlates to how much you tweet. Or if you're really ambitious, there may be something to learn about your tweeting style.

2. Rank yourself with the Publisher Rank (see below). If all of your followers are social climbers, you'll have a rather pathetic score and may want to do some soul searching about the design of your tweeting plan.

Defining Publsiher Rank:

First, we have to define Follower Rank. This is the rank a user has as a follower - effectively his value to the publisher. A follower who has few tweets in their inbound stream is worth more to the publisher because she has fewer tweets to read and can spend more time on each (perhaps even buying what was tweeted about). A follower who follows many users is worth less to the publisher because he has less time to read each tweet. And in extreme cases may never see a tweet. For practicality, let's call 100 tweets per day for a single user a Follower Rank of 1. This is arbitrary. But it is a constant we can use throughout the calculations.

Using this constant, a precise Follower Rank for a user can be obtained by reading their follow stream and counting the number of tweets in a 24 hour period. Divide 100 by this number to get their Follower Rank. If they get 200 tweets in a day, their Follower Rank is 0.5. If they get 5000 tweets in a day, their Follower Rank is 0.02. Remember, more tweets in a user's stream means less time per tweet to read (and act on) the stream.

Estimating Follower Rank

According to HubSpot the average number of tweets a user publishes is 4.4. Let's use 5 to keep the math simple. Using an average, we can simplify the Follower Rank calculation by multiplying 5 times the number of users a user follows. A user follows 20 users, he gets a Follower Rank of 1. A user follows 1000 users, she gets a rank of 0.02 for that user.

Calculating Publisher Rank

Next we calculate your Publisher Rank by adding up the Follower Rank for each of your followers. You can use the precise method (today's tweets for each user) or the approximate method. Either way, the sum of these is your Publisher Rank. If you have 1000 followers each with a Follower Rank of 0.002 your Publisher Rank is 2. If you have 100 followers each having a Follower Rank of 0.5, your Publisher Rank is 50. In the latter case, you have a much higher rank because your followers have greater capacity to read your tweets.

For those who prefer equations to prose, here is the formula for the precise method of computing Publisher Rank:

Where:

P represents our publisher we want to rank

Fj represents an individual follower of P

Gji represents an individual follow of Fj

k = the count of followers of P

nj = the count of follows for an individual follower Fj of P

mji = the count of tweets for an individual follow Gji of Fj

It's left as an exercise to the reader to implement a service that computes Publisher Rank based on this formula. Maybe I'll work on it in my spare time.

Any thoughtful reader will come up with flaws in this ranking system. Not all Twitter users are active. Some people aren't even online much. Others spend their time in other social network contexts, etc. To see it taken to an extreme, check out this post. In fact, I would argue that any system that can track actual follow-through (clicked linked, purchases, etc.) trumps the guesswork about how to rank a Twitter user.

Still, contemplate this: If we all used Publisher Rank instead of Follower Count to rank Twitter users, a bunch of social climbers would simply vanish from visibility. I could live with that. Could you?

Are Twitter Trends Meaningful?

How much value is there in a Twitter trending topic? Does it really represent what is on people's minds?

Since practically everyone on Twitter is both a publisher and a reader, we don't often think the distinction between the two is important. But it is - especially if you want to interpret the meaning of trending topics. And this is simply because trending topics directly measure publishers, not readers.

If you're not sold yet on why the distinction is important, take a quick sidebar to more traditional news sources. Would you consider the headlines of newspapers what is on people's minds? Would you consider them the 'trending topics' (on more of a daily pace)?

Not exactly. Rather, these are the stories that publishers 'think' the population will be interested in. So if publishers are good and do their research well, perhaps the headlines do line up with what is on people's minds. And of course, if what's on your mind is what you just read in the newspaper this morning, we may arrive at the same result - just with the publisher influencing the reader - not the other way around.

So back to Twitter.

Since everyone is a publisher, one might dismiss the notion that we aren't looking at real trends. However, there are two distinct distortions we should not forget about when looking at Twitter trends:

1. Whenever we tweet something, we tweet things that we think will be interesting to our followers. It is the same thing that newspaper publishers do. When we tweet too many things our followers are not interested in, we lose them. And we don't want to lose followers. If we are good, we may know what our followers want. So perhaps it is not a complete disconnect. But even good people will mess up. And how many are that good? We can't forget that the publisher chooses the topic, not the reader.

2. There is a large segment of the Twitter population that is very focused on gaining a large following, without much else driving their activity. How does one gain a large following? Tweet about interesting stuff. Don't know what is interesting? Check out the top 10 trends on Twitter. Tweet about that.

So now there is a segment of the Twitter population that has turned Twitter and it's top trends into an amplifier. One can no longer tell how interested people are in a particular topic because Twitter publishers have picked up the 'trends', tweeted about them and pushed them even higher on the charts.

On a gross scale, we often do get to find out what people are thinking about. But the top 10 trends will always be much higher on the scale than they deserve to be because of this phenomenon.

Are Twitter trends useful? Probably. Just keep in mind their limitations are very much like those of every media outlet that preceded Twitter. Trends are amplified through the 'Twitter amplifier' and they really represent what publishers are thinking about, not necessarily what readers were thinking about before their publisher tweeted the story.

Notes for BibleReader on iPhone - A First Look

I've been using Olive Tree's BibleReader for iPhone for almost a year now. I love the interface and am completely thrilled not to have to carry a few pounds of paper with me all the time.
The biggest complaint I've have with using an electronic form of the Bible is the inability to take notes in it. Our pastor regularly encourages us to mark up our Bible, underline important phrases, make reference to other parts of the Bible, etc. Sitting in church I had no way to comply with these suggestions - though I really wanted to.
So, I was super excited to have a chance to get an early look at the implementation for BibleReader notes by participating in the beta program for the feature. Now I too can mark up my Bible!

Overall I like the implementation. And though it is beta, it seems quite stable.

It's easy to add a note to any verse. Tap a verse number (or the '+' icon at the bottom of the page) and an edit window slides up in which you can type your notes. Tap Done and you're viewing the note. A Note icon appears at the start of the verse. Whenever the icon is tapped, the note slides into view. Tapping on the page makes the note slide away. Slick. This is consistent with how other notes work in the application. The difference is that these are notes created by the user rather than by a theologian (unless you, the user, happen to be a theologian).

By default, you get a speech bubble icon for your notes. You can change it to one of a few dozen other icons. Presumably if you come up with a standard for each icon, it could help you identify certain types of notes - say 'prayers', 'cross references', 'special word from the Lord', etc. I struggled at first trying to do this. But with a bit of creativity, I was able to come up with a mapping for myself that worked at least for this small set (i.e. speech bubble, direction sign and heart respectively). There are various forms of push pins, speech bubbles, paper pads, traffic signs, stars, etc. with many colors to choose from. Though there are many icons built in, it would be nice to have user-defined icons that convey meaning of user-defined categories.

I've got a couple of other things on my wish list (below). But the biggest drawback I've encountered is that my notes are trapped in my phone.
While I love having the Bible in my phone, it is not my only Bible. I also read a paper copy and an online copy. I would love to have my notes show up in the online Bible I am reading - something quite feasible. I would love to have them show up in my paper bible also - not so feasible unless you stretch the definition of paper to include a Kindle.
I asked the developer about getting notes off the phone and found out that in fact Olive Tree has plans to sync notes over the web. I wasn't able to get more details. But I'm hopeful. This will make a huge difference in the usefulness of the feature.

Here's the wish list I promised:
* Auto-tag a date to each note. I find myself repeatedly entering this manually (not the time, just the date).
* Add ability to search notes.
* Include a way of going to the verse text from viewing the note after selecting 'View Annotations' (kind of like a bookmark).
* Recognize scripture references in notes and make them tappable links (like the cross-references in built-in notes).
* Add ability to place note icons mid-verse.
* Add ability to indicate a note (even a blank one) by underlining or highlighting a section of text - not bounded by the beginning or end of a verse.

Looking over this list, you might think the feature falls short. But that's not the case. The implementation is simple and gets the job done. And it is more full-featured than other notes implementations I've seen. The only show-stopper is the inability to get notes off the phone. Solve this, and I'll be writing up a storm of notes in my iPhone BibleReader.

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

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.

About This Blog

After 20+ years of software development, I've learned a couple of things about design. And while most of those lessons are about software design, a few spread into other areas of life. Maybe some of these will be useful to you as well.