Sorry about that!

I’ve been pretty heads-down lately – here’s what’s going on:

1. The address book work I was talking about has been put on a tiny bit of a backburner as I deal with two more pressing Thunderbird projects, namely, finishing up the Account Provisioner (a service that offers you email addresses if you don’t already have one) and Tabs on top (a part of the general UX refresh that Thunderbird is working towards)
2. A few weeks ago, I was knee-deep in sound design for a show called FIREraisers being put up by the red light district.
3. UCOSP has been going strong, and our Review Board students have been pluggin’ away.

About the address book – I’ve received a bunch of email making suggestions and asking for things.  That’s great!  I’ll comment on that shortly – I just need a little more time to clear Account Provisioner and Tabs on Top off my plate.

More soon.

I also got the Contacts add-on from Labs working (limping, rather) in Thunderbird.  Some very interesting ideas in that add-on.

I’ve also started reading some related work.  Here’s what I’ve been gazing at for the past few days:

1. Bug 674720 (WebContacts or Contacts+)
2. The W3C Contacts API draft spec
3. The PortableContacts draft spec
4. The vCard spec
5. The Firefox Sync development documents

So, basically, I’m exposing myself to as much current work in this problem space as possible.  Is there anything else I should be reading?

Probably what rang out loudest for me was that I don’t really have any data on how real users actually use Thunderbird’s address book.  I know how I use it, but that’s about it.  In fact, I talked a Thunderbird user the other day who didn’t even know that the Thunderbird address book existed.  Go figure.

And here I went and jumped the gun, and tossed together some mock-ups.

If there’s anything that my grad supervisor Greg Wilson taught me, it’s not to jump to conclusions (or mock-ups) when we don’t have any data to back it up.  I’m a scientist, damn it, and that’s just how we roll.

Credit: http://cowbirdsinlove.com/46

Firefox has this great add-on called Test Pilot that lets Firefox users volunteer to have data periodically collected from them.  Work to get Test Pilot working for Thunderbird is underway, and I think that’d be an awesome tool for gathering feedback about how users use the address book.

Some questions I’d want answered, right off the top of my dome, in no particular order:

1. Does anybody actually use Thunderbird’s address book?
2. When someone is using the address book, what are they likely doing?
   1. Looking for a contact?
   2. Sorting and organizing their contacts?
   3. Creating or editing contacts?
   4. Other?
3. Do people use mailing lists?  If so, how many do they tend to have?
4. How many address books do people tend to have?
5. How many address books do people want to have?
6. How many contacts to people tend to have in their address books?
7. Is it important for people to be able to group their contacts into sets, like “Family”, “Friends”, “Acquaintances”, “Employees”, “Co-workers”, etc?
8. Given several address books, where each address book has some large number of contacts, how quickly can an individual contact be found?
9. How much switching back and forth from mouse and keyboard is required to create a new contact, or to edit an old contact?
10. How important is it for Thunderbird’s contacts to be synchronized with other contact services, like Google Contacts or the OSX address book?
    1. Or is it sufficient just to import them?
11. How important is it for Thunderbird’s contacts to be synchronized with user’s mobile devices?
12. On average, how long does it take to create a new contact?
13. On average, how long does it take to edit a contact?
14. On average, how much time are users spending in the address book?
15. What fields do most users want to associate with a contact?
16. What are the top 10 complaints about Thunderbird’s address book?
17. What are the top 10 best things about Thunderbird’s address book?

What are some other questions I should try to get answered?

UPDATE (Aug 29 – 10:00EST)

I’ve gotten some awesome feedback on this post, and some new questions to add to my list.  Here they are, in no particular order:

1. What is the main way in which Thunderbird users use and manipulate their address books?
   1. Through the main address book interface
   2. Through the contacts sidebar in the compose window
   3. Through the inline contact editor within a message header
   4. Other?
2. If the answer to the above is anything other than 1, is it possible that the address book manager is not needed?  Or does not need to be as complicated as it already is?
3. How many duplicate contacts does the average user possess (where a duplicate contact is a contact with the same e-mail address, or possibly the same name)
4. How frustrating is it to add a contact in Thunderbird?
5. How frustrating is it to edit a contact in Thunderbird?
6. How frustrating is it to search for a contact in Thunderbird?
7. How often do users want to create a contact based on a pre-existing one?  Example – creating co-workers, with similar fields for work addresses, etc, but different names, phones, etc.

I normally don’t play the “band card”, but I’m particularly proud of this latest achievement, and wanted to share.

Here’s us playing some Lady Gaga.

It felt like some pretty big steps.  There was a palpable sense of finality.  I was out.  It was over.

The University has played a big role in my development, and despite all of my moaning and complaining over the years, I’m glad I went, and I’d do it again.

But not right now.

Graduate school almost didn’t happen for me, and I have two very important people to thank for making that happen:  Karen Reid and Greg Wilson.

I still fondly remember when you cornered me during that codesprint in 2009, and convinced me to try graduate school.  I don’t regret it.  It was the right decision.  So thank you both so much for convincing me, and giving me the chance, and thank you Greg for supervising, and guiding me through.

I learned lots.  I had fun. 

Shakespeare wrote that brevity is the soul of wit.  Well, I

Anyhow, after lots of hard work, my research paper was finally signed off by my supervisor, Dr. Greg Wilson, and second reader Dr. Yuri Takhteyev.  A huge thanks to both of them!

Here’s the abstract, followed by a download link for the PDF.  Enjoy!

Abstract

Peer code review is commonly used in the software development industry to identify and fix problems during the development process. An additional benefit is that it seems to help spread knowledge and expertise around the team conducting the review. So is it possible to leverage peer code review as a learning tool? Our experiment results show that peer code review seems to cause a performance boost in students. They also show that the average total peer mark generated by students seems to be similar to the total mark that a graduate-level teaching assistant might give. We found that students agree that peer code review teaches them something – however, we also found they do not enjoy grading their peers’ work. We are encouraged by these results, and feel that they are a strong motive for further research in this area.

Click here to download my research paper

Several good reasons, actually.

And here they are:

UCOSP has wrapped for the semester

This semester, I was a teaching assistant for the UCOSP (Undergraduate Capstone Open-source Projects) course.  I helped out with two projects:  MarkUs and Review Board.

This semester, we saw some outstanding work for both projects.  Lots of great students, lots of good code, lots of leaps forward.

I’m looking forward to helping out next semester with UCOSP.

I won’t be doing it as a paid teaching assistant though.  Why?  Well…

I’ve finished school

My research paper was signed off by my two readers, and I just wrote my last final exam a few nights ago.  Unofficial grades have been posted, and I’ve passed what I needed to pass.

So that’s that – I’m a Master of Computer Sciences, I guess.  Awesome!

I got a job!

I’ve been hired by Mozilla Messaging to work on the Thunderbird project!  I’m 100% psyched about this opportunity, and look forward to peeling into the code.  An added bonus:  since Thunderbird is an open-source project, I’m absolutely free to discuss the code and the various things I’m doing with it.  No NDAs for me!  So stay tuned – I’ll have lots to say about Thunderbird and the Mozilla Framework code.  Just give me some time to wade through it.

Zihuatanejo

It’s been a pretty long road.  I’ve been in school, in one form or another, for over two decades.  It’s strange that it’s over.  I’m extremely excited about my next adventures, but I think I’m going to miss school.

Still, I can’t help but be a bit dramatic…

View at Picasa

In 1966, Andy Dufresne escaped from Shawshank prison. All they found of him was a muddy set of prison clothes, a bar of soap, and an old rock hammer, damn near worn down to the nub. I remember thinking it would take a man six hundred years to tunnel through the wall with it. Old Andy did it in less than twenty. Oh, Andy loved geology. I imagine it appealed to his meticulous nature. An ice age here, million years of mountain building there. Geology is the study of pressure and time. That’s all it takes really, pressure, and time. …Andy crawled to freedom through five hundred yards of shit smelling foulness I can’t even imagine, or maybe I just don’t want to. Five hundred yards… that’s the length of five football fields, just shy of half a mile…

Andy Dufresne – who crawled through a river of shit and came out clean on the other side.

P.S.:  Here are some celebration rituals, if so inclined.

I’m bogged down with school work, and I’m aiming to have the first draft of my research paper done next week.  So that’s taking 100% of my resources.

Just be patient.  I’ll post my idea soon.

I guess code review just isn’t really all that fun.

So a few months ago, I broadcast the idea of turning code review into a game. It was my way of trying to mix things up – “let’s add points, and have reviewers/developers competing to be the best participant in the code review process”.

Well, if there’s one thing that my supervisor Greg has taught me, it’s how I shouldn’t rush headlong into something before all of the facts are in.  So before I decide to do something like game-ifize code review, I should take a look at some prior work in the area…

Enter this guy:  Sebastian Deterding.

In particular, check out the following slide-show.  Flip through it if you have the time.  If you don’t have the time, scroll down, where I get to the salient point with respect to game-ificating code review.

Here’s the slide-show. Be sure to read the narrative at the bottom.

The Salient Point

Sebastian seems to be saying that adding points to apps and trying to incite competition does not make something a game.  If it did, then this should be countless hours of fun.

Without play, there is no game. Points do not equal a game.  It’s not nearly that simple.

Free Pizza and Pop

I’m going to divert for a second here.

Last week, a company set themselves up a couple of booths in the lobby of the Bahen Center where I work.  They were there to recruit university students to work for their company – either as interns, or full-timers.

They were also handing out free pizza and pop.

Needless to say, I wanted a few slices – but I figured it would be polite if I engaged them in conversation before waltzing off with some of the free food and drink they’d brought.

So I sparked up a conversation with one of the recruiters, and he told me about the company.  I’m going to call this recruiter Vlad.

I ended up gently steering the conversation towards code review, and I asked my inevitable question:

“So, do you guys do code review?”

I felt like a dentist asking a patient if he’s been flossing.  Vlad waffled a bit, but the general impression was:

“Not as much as we should.  We don’t have a prescribed workflow. It’d be hard to persuade all of the teams to do it.”

And then we started talking about code review in general.  It turns out that Vlad had worked in a few companies where they’d done code review, and he always felt a little short changed.  He said something along the lines of:

“I never felt compelled to do reviews.  They just sort of happened…and I did it, and it felt like…unrecognized effort.  I mean, what’s the incentive?  Do you know what I mean?  There’s incentive for the software, but I’m talking incentive for me.  And some people did really lousy reviews…but my reviews were treated the same as theirs.  I didn’t get recognized, and didn’t get rewarded if I did a good review.  So it was hard for me to do them.  I want to be recognized for my good reviews, for my good contributions.”

I wish I’d had a tape-recorder running so I could have gotten Vlad’s exact words.  But that’s what I remember him saying.

Feedback and Recognition

Maybe instead of trying to game-ulize code review, I can instead hear what Vlad is saying and work off of that.

With the code review that Vlad participated in, all of the feedback went to the code author, and none went to the reviewers.  And the reviewers are the ones who are doing all of the heavy lifting!  As a reviewer, Vlad also wants feedback, and recognition for code review done well.

There’s a company in Toronto that specializes in feedback like this.  They’re one of the major players in the Toronto start-up scene, and have built a pretty sweet suite of tools to facilitate quick and easy feedback/recognition.

The company is called Rypple.  And maybe that’s the name of the application, too.  (checks website) Yeah, it’s both.

So Rypple has this feature called Kudos that let’s people publicly acknowledge the good work of their team.

Normally, I don’t pimp companies.  And it upsets me when people comment on my blog, and their sub-text is to try to sell their product or service.  However, I think this video is relevant, so I’m posting their demo video so you can see how Kudos work:

Click here if you can’t see the video.

The Idea

So Rypple’s idea is to have a feed that the team subscribes to, and publicly display things like Kudos.  The badges for the Kudos are also limited in how many you can give per week, so they’re a valuable commodity that can’t just be handed out all over the place.  Cool idea.

So there’s one approach – use a service like Rypple to give your reviewers better feedback and recognition.

Or maybe we could build an extension for Review Board that does something similar, and more oriented around code review.

It’s not oriented like a game, like I had originally envisioned.  But somehow, I think this idea has more meaning and traction than just “adding points”.

More on this idea in a few days.  But please, comment if you have any thoughts or ideas to add.

It’s still in it’s very early stages.  The code hasn’t been reviewed.  I’m still really really open to suggestions and feedback on this.  So please, comment here, or on the reviewboard-dev list.

So here it is – enjoy!

(Click here if you can’t see the video)