One thing I have understood better through Astrid’s development process is how software uptake is influenced by image and perception (this essay mostly applies to consumer software). Most folks encountering a new software package see it in the following light:

Everything in the black box is somewhat magical and not understood well. The desire to make software that “just works” further compounds this effect, trying to hide as much as possible from the user. The problem is, if you don’t know what is happening, when something goes wrong, you tend to doubt the software’s good intentions:

This reminds me of an article I once read, that mentioned that people become angry at remote controls far more often than they become angry at their cars. Cars are a lot more transparent than computers, giving users (a) control over what they do, and (b) feedback about what is happening. When I drive, I turn the steering wheel left, and the car almost always turns left with you. There’s no guesswork. If I turn too hard, I will experience resistance against my steering wheel that corresponds with the car’s inability to turn.
Recently, however, I was in a car running low on power steering fluid, and it was a severely dissonant experience. When I made a turn, there would be a two second delay before the car would turn, which shattered the illusion of control and made it impossible for me to trust that I would get to my destination safely.
What does this have to do with software? When software does something that we don’t expect: crashing or giving incorrect results, we start to lose the illusion that we are in control, and often will respond by distrusting the software in question. It only has to crash once, but fairly early on, and we may never use this piece of software again.
A few principles we can gather from this little thought experiment might be:
- Help the user feel in control
- Give feedback on what is going on behind the scenes
- Don’t crash hard! (i.e. quit the program without a message telling the user what happened)
Trust & Astrid
In fact, Astrid has a competitor todo list that is great in a lot of ways. I used it for a while, and probably most folks who currently use Astrid have used it at some point in the past. I looked at it recently, and thought, wow, this program is actually pretty neat. I wish Astrid had all of these features! This led me to ask what exactly caused me to put a few hundred hours of my life into creating a tool that already exists in the world.
Then, I remembered the things I mentioned above. When this competitor todo list first launched, it had a few problems. The interface was pretty clunky, certain features didn’t really work, everything was a bit slow, and you could definitely make it crash. This really turned me off, and I stopped using it. Now, I am guessing most of these issues are fixed in the new versions of this application, which is still being actively developed (good for them!). But, I don’t really feel like wasting my time on it anymore, since it was broken before and my faith in the software has been diminished.
It comes down to an issue of trust: can I trust that this program will do what it says it does? Can I trust that I won’t lose my data? A user’s trust is a precious commodity that developers need to steward, and this includes making every effort never to lose data or cause the user an unpleasant experience.
Trust is the reason why I implemented synchronization with remember-the-milk, an online task list organizer. When I released Astrid, this was by far the most requested feature – synchronization with Google tasks, or RTM, or Toodledo, or whatever. I understood that people would have to recreate their task lists in Astrid in order to migrate, but I thought that wasn’t a big deal, since it’s something we do all the time. I really didn’t understand why people would want to use both at the same time.
As soon as I talked to some users, I realized the underlying trust issue: if Astrid were to die, how could users get their data out?
Translation
Speaking of which, one of the fundamentally difficult issues in synchronizing with another service is what happens when information is stored in different formats. Translators have to be built, and when the process is not perfect, things are lost in translation.
Take, for example, Google Translator. It’s probably the best free language translation service, and if you’ve used it, you know it’s not great. Probably the most famous example of this is the phrase: “the spirit is willing but the flesh is weak”, which, as urban legend has it, was fed into a machine translator into Russian, and back to English, to get: “the vodka is good, but the meat is rotten”.
Astrid also suffers from the “good vodka” problem, but in a much more subtle way. For example, Astrid supports repeating a task every # days, # weeks, or # months. Remember the milk has a few other options, including every Monday, every other week, every 15th of the month, etc. Translating them into Astrid’s world would mean losing some information: “every Monday” would become “every week”, for example.
How do you handle issues of translation? That’s a tough one. Some would say that partial translation is obviously better than none. I think that that’s not always the right answer, and sometimes, you just have to throw up your hands, and say, it’s not really do-able, unless it can be done perfectly. It comes back to the issue of trust.
While not exactly the same issue, check this out. People are lazy, and so you need to let them know (fail-fast) when things aren’t going to turn out as they expect.
Potpourri
Astrid got a makeover!

Our little todo list been received with far more enthusiasm than I had anticipated. People haven’t really donated much in the past few weeks, probably because they’re satisfied enough with the current product and because I’m unsatisfied enough to continue developing on it for free. (edit: as I wrote that, someone just dropped in $20 =) Still, I’m so grateful for every person who’s donated… they are a huge encouragement.
In other news, some nice reviews have come in. It’s been really rewarding to hear about how Astrid is helping people out, so one feature that I’ve been kicking around is an “Astrid community” where people can share things that Astrid has helped them accomplish.
- “Astrid is a cute little to-do list and reminder program that probably takes the title as the most reliable of such apps available in the Android Market” – phonedog.com
- “Astrid will be the kick in the butt needed to pick up the pace or reevaluate your game plan.” androinica.com
- “Astrid is een prima todo app met flink wat features.” (Astrid is a great todo app with a good deal of features) in dutch, frankwatching.com
- “Give it a shot and never forget any other appointments again!” rhodzy.co.uk
Also, if you were interested in statistics, here’s a nice graph. It’s a shame Google doesn’t produce pretty graphs for us.
So there it is, folks. Astrid is still a work in progress, but I’m going to be putting my focus on some other projects for the time being, so I figured I’d write another recap while everything was still fresh in my mind.


great post, bison2.
working with people as project coordinator, i find much of the same concepts of trust you found to be true for ppl using astrid/other machines (let ppl feel they’re in control, let ppl know what’s going on, don’t crash hard) to be true for ppl-ppl relationships as well.
and oh geez, that road sign… glad I wasn’t in charge of that project!
I just ditched the competitor’s to do for yours. Despite it’s advances, it’s still clunky to navigate and can be very user unfriendly. For example, try to edit default category settings some time after your first start up of the app after installation. There’s no way!
You have created a simple, straightforward, easy to use app w/ instinctive usability. When you added RTM synch, you had me.
I’m not much of a ToDo list guy, but I loved your app and I learnt a couple of things looking at your code that I was able to use in my app. Thanks for making it open source.