Blog-o! Notes from latte.ca

Wed, 15 Jun 2011
Customization and choice.

A friend of mine recently said:

EVERY behavior aspect of EVERY application should be user-settable if the user is prepared to drill down far enough. No exceptions. Even if the user will be shooting his own foot by messing with it.

I, obviously, disagree with him, and wanted to explain why in a few more characters than Twitter would allow.

While giving the user complete control over every aspect of an application seems like a good idea, there are two slightly-hidden downsides to it.

First, every choice you give the user doubles the amount of testing you have to do. (Okay, it doesn’t exactly double it, but it certainly adds a testing, maintenance, and support burden.) Is it a responsible use of your time to implement these options if less than 1% of your users will ever change them (and risk shooting their own feet), or would it be better for everyone to implement a feature that more people would use?

Second, Emacs notwithstanding, you’ll never get to a great text editor by customizing a mail reader. The whole Unix (and iOS, oddly) philosophy is to write each app to do one thing, and do it well. Not to do a whole bunch of optional things. And if you’re doing only one thing, presenting an option to the user to do it or not doesn’t make a lot of sense.

And finally, because I can’t count, if you offer people too much choice, it imposes a cognitive burden on them which can lead to their making no choices at all, or at least not making them any happier than when they had fewer choices.

To bring this back to the product I’m working on, we are going out of our way to make Thunderbird more usable and part of that is simplifying it by offering fewer, more meaningful choices.

[Posted at 10:13 by Blake Winton] link
Sat, 11 Jun 2011
Great Piles of Crap

I cleaned my purse out today. It had been getting heavier and heavier, and I was quite curious as to what was in there.

Crap from my purse

Some highlights:

  • vast quantities of paper napkins (only some of which were used)
  • Chinese restaurant flyer
  • pirate eye patch
  • pirate map
  • plastic telescope
  • plastic shark
  • yoga studio brochure
  • Ontario Science Centre flyer
  • four lip glosses
  • Licemeister™ lice comb

I've been doing a lot of work-work lately, and not finding time for life maintainance. The state of my purse, before I cleaned it out, was much like the state of my wallet, and the state of my desk, and the state of my yard, and indeed the state of my house. When that much of your life is in disarray it makes you feel like a bit of a failure. I was really glad to get a chance to clean out my purse, and I hope I can get to some of that other stuff soon.

[Posted at 22:26 by Amy Brown] link
Wed, 01 Jun 2011
Who should review my change?

One of the big questions I had when I started writing patches was who I should ask to review them. Now that I’ve been in the community for a while, I’ve got a much better sense of who I should be talking to for the type of things I’m likely to write, but there are still times when I want to make a change in a part of the code that I haven’t touched before, and I’m not sure who to ask. In those cases, I usually fall back to a fairly simple (if non-obvious) set of steps to try and figure out who to pick.

  1. Get the list of files I’ve changed.
  2. Get the hg log for those files.
  3. Check through the log for “r=”, and “sr=”.

Of course, that’s a fairly easy set of steps to automate, and so I present my first cut at the automated reviewer chooser!

Of course, there are a lot of things I’ld like to do with this, such as:

  • Improving the documentation.
  • Checking to see how well this script would have done on previous commits.
  • Taking into account the length of the queues for the reviewers.
  • Adding some sort of recent-ness calculations.

But I think that this tool is useful enough in its current state that releasing it and getting feedback on what to actually work on would be a win.

To use it, be in a mercurial source repo, and type getReviewer.py to get a list of suggested reviewers for the current differences, or getReviewer.py temp.diff or getReviewer.py https://bugzilla.mozilla.org/attachment.cgi\?id\=536017 to specify a different set of changes.

[Posted at 20:13 by Blake Winton] link