sacha chua living an awesome life

I’ve been fiddling with Quantified Awesome, this personal dashboard that I’m building so that I can keep track of what’s going on in my life and use that data to make it even more awesome. For example:

• Tracking my time helps me make sure work doesn’t tempt me too much, and that I make time for both personal projects as well as connecting with other people. It also helps me improve my time estimates: How much time does it really take to walk to the subway station? How instant are instant noodles?
• Tracking library books reminds me before they’re overdue, helps me collect my reading history, and gives me a greater appreciation for where my tax dollars go.
• Tracking my clothes helps me remember to wear different types of clothes more often, makes it easier to donate items I don’t typically wear, and encourages me to try new combinations.
• Tracking the produce we get from community-supported agriculture helps us avoid waste.
• Tracking stuff helps me remember where infrequently-accessed items are.

It turns out that other people are interested in this too. 21 people have signed up through my “I’ll e-mail you when I figure out how to get this ready for other people” page, and my mom wants to use it too. That’s awesome!

Now I have to go ahead and actually build it so that other people can use it. That’s scary.

And like the way I deal with other scary, intimidating, procrastination-inducing things, I’m going to list my excuses here, so that I can shine a light on those assumptions and watch them scurry away like the cockroaches they are and, if necessary, squishing them with a well-applied flipflop.

• Excuse #1: Idiosyncrasy. The way I work might be really weird, and other people may not be able to figure out what to do.
  • What’s the worst-case scenario? “I have no idea how this works!” I end up with lots of crufty special cases because I can’t figure out how to reconcile different ways of working.
  • What’s the best case? I adapt the system to the way other people work, and I get inspired by what they do. I build a lovely, flexible web app and API.
• Excuse #2: Risk. I’m fine with loading my own data into an experimental system, but if I mess up and delete other people’s data, I’ll feel terrible. Also, they might trigger bugs.
  • What’s the worst-case scenario? Catastrophic data failure, nothing saved.
  • What’s the best case? Regular backups help me recover from any major mishaps, and careful coding avoids more common mistakes.
• Excuse #3: Support. I’m going to spend more time handling bug reports and feature requests, and less time building little things that might be useful only for me.
  • What’s the worst-case scenario? People get annoyed and frustrated because I’m currently focused on other things, like my work.
  • What’s the best case? I get the system to become mostly usable for people, and I use my discretionary time to build more features. People’s requests inspire me to build more stuff and create more value.
• Excuse #4: Documentation. I’ll need to write documentation, or at the very least online help. This means confronting the less-than-intuitive parts of the system. ;)
  • What’s the worst-case scenario? I describe what currently exists, get frustrated because I want to improve it, and end up cycling between updating documentation and improving the system.
  • What’s the best case? I describe what currently exists, and end up improving it along the way. I build online help into the system so that it’s easy to change. There’s a blog that helps people learn about updates, too.
• Excuse #5: Offline access. A web-based time tracker might be of limited use if you don’t have web access often. I’ve been working on an offline HTML5 interface, but it’s still buggy.
  • What’s the worst-case scenario? Early testers try it out, but get frustrated because of the lack of offline access.
  • What’s the best case? I figure out the HTML5 offline thing. Someone else might be interested in building a native app, and we work together on fleshing out an API.
• Excuse #6: Impatience. If I bring people on too early, they might get annoyed with a buggy system, and lose interest.
  • What’s the worst-case scenario? People give it a cursory try, and give up in annoyance.
  • What’s the best case? Early users are extraordinarily patient. We figure out a minimal viable product for each of them – the simplest thing that could possibly support what they want to do. Over time, things keep getting better and better. Also, I build a decent export interface, so even if people move on to a different system, they’ll still have their data.
• Excuse #7: Privacy and control. A bug might accidentally expose people’s information, which is not fun. I also don’t want to have to police the system for objectionable content, considering the thumbnail uploads.
  • What’s the worst-case scenario? Someone’s private notes get accidentally published.
  • What’s the best case? People sign on knowing that I might have bugs, and don’t save any super-secret or inappropriate information on the system.

Okay. I think I can deal with that. So, what are the smallest, least-intimidating steps I need to take in order to get closer to opening up?

• Write a quick test to make sure that people’s data will stay private. We’ll make people’s accounts private by default, although mine will stay mostly-public.
• Make a list of things that people should be able to do right now. (Not including new functionality!) Gradually write tests to nail down that behaviour.
• Make a list of things that people may want to do some day. Eventually set up an issue tracker.
• Enable Devise’s invitable feature so that I can set up accounts for people easily.
• Doublecheck backups.
• Bring one person on. Then the next, then the next…

It will still be better than nothing, it will be a good learning experience, and participation is purely voluntary anyway.

One step at a time.

More posts about: analysis, decision, development, planning, quantified // 2 Comments »