Mentoring isn’t worthless after all!

Standard

I enjoy talking to young companies (or proto-companies) about their projects. I do that with a few incubators and the like, and I consistently find it rewarding. I find myself always trying to tweak people’s product vision a bit, looking for a way to turn a “business idea” into something that will have deeper, human value — not just because I think it’s the moral thing to do, but because if you’re “just working for the man” (even if you are the man), then when things get tough, it’s going to be hard to get up in the morning. When you’re doing something that deeply resonates with people, and which either relies on positive human qualities or strengthens them, then I’m confident that your odds as an entrepreneur are better. Also because there are plenty of mentors who will do a better job of getting your social viral marketing plan in shape.

Sometimes I wonder whether I’m the only one getting value out of our conversations, but this blog post reassured me that at least sometimes I have an interesting impact: Do you really need a server? Build your minimum viable product entirely client-side.

I’m particularly interested by the fact that I wasn’t really trying to force them to think about the privacy advantages of client-centric development (I realize it’s hard for budding entrepreneurs to make that a priority), simply going for the pragmatics of it all. I’m so glad it’s working out for them.

Outlook PST importer anyone?

Standard

This week, Microsoft published an open source (Apache 2) SDK to read PST files. From what I heard, it works with Unicode PST files as generated by Outlook 2003 or later.

It’s a healthy move on Microsoft’s part, as it releases their users from feeling like their data is locked in to their relationship with Outlook. I hope the code is easy to use, etc.

I’d naturally be very interested to hear of anyone experimenting with using this code in an add-on to make the process of importing all one’s data from Outlook into Thunderbird. If you know of such an effort, let me know!

Support job with Mozilla Messaging

Standard
frustration, from e-magic on Flickr

"frustration", from e-magic on Flickr

One of my first jobs in IT was as a “computer consultant” for my university.  I got to learn a lot about computers of various kinds (including currently useless but still formative bits like writing REXX programs on a CP/CMS IBM 3090 mainframe), and, more importantly, I learned a lot about what it takes to really help people solve computer problems.  We had all the kinds of users you’d expect in a decent-sized community: haughty faculty (and haughtier grad students, for some reason), who absolutely demanded that you stop whatever you were doing to help them fix their margins <em>right now</em>.  We had to mediate between first-year students lost and confused in their first exposure to the net, and technical staff who were straining under the onslaught of the first week of classes.

Still, it was a lot of fun — we had autonomy to decide what problems were worthy of paper handouts, to hand out as answers to FAQs — we had special accounts with free access to the high-resolution printers — but most of all, we had lots of interactions daily with people who were truly grateful for the help we provided.  Not all interactions were positive, but the vast majority of them were.  There was a real community between the student staff, the full-time staff, and the avid users who spent their days in the computer center working on their papers, homework, and assignments.

The job

These memories come back as we’re now looking for someone to help coordinate Thunderbird’s technical support communities.  The challenge is orders of magnitude harder, but the opportunities to help are equally huge.

Mountain Lion Safety by ekai on flickr

Mountain Lion Safety by ekai on flickr (helpful, no?)

It’s become clear to me that this job is fairly unique, both in scope, and in what we’re looking for.  The right candidate will have a rare blend of empathy & technical knowledge, clear organization skills.  She or he must have the ability to bring people off the ledge, recognize and encourage peer leaders, but also know how to deal with poisonous people.  This requires both clarity of thought and clear, efficient expression.  Our ideal candidate knows Thunderbird well, but most importantly can understand both the requirements of providing technical support for hugely diverse populations of users, who often come for help when they have critical issues that are often caused by external actors like email providers.  A hard job to fill.

A big part of the job is also to understand the existing bits of the existing world of Thunderbird support, and figure out ways of connecting the bits that work, and building new bits if needed.  From where I’m standing, this ecosystem includes forums like mozillazine, which have garnered huge numbers of posts with very valuable information, but which don’t necessarily provide the best experience for novices.  It also includes the GetSatisfaction forums, which provide a lower barrier-to-entry for many users, but which are still in their infancy, both in terms of content and in terms of people providing answers.  The ecosystem also importantly includes SUMO, which right now is focused on Firefox, but which could hopefully be deployed for Thunderbird use someday.  A comprehensive solution also likely involves figuring out how to help people over Twitter, on Facebook, or wherever Thunderbird users are likely to look for answers or express frustrations.  Whoever gets this job will end up diving deep into the world of Mozilla support overall, and learn from all of the people who’ve built those foundations — then build upon them.

As the central point of contact for support issues, this person will be incredibly helpful in working with the QA and dev teams to prioritize bugs and other issues, so that the next revisions of Thunderbird or Thunderbird websites work better for more people.  Finally, it would be great to coordinate with the support micro-communities that exist around the world.  In general, the job is clear: help people with Thunderbird, and help people help each other.

If this sounds like you, send us an email, explaining why you’re the right person for the job.

Getting insight into one's own email

Standard

Thunderbird knows a lot about your email. After all, it’s got access to large amounts of data, and builds sophisticated databases so that it can be very responsive, even when dealing with large folders containing thousands of messages. Wouldn’t it be nice if we could use this information to extract either faster workflow, or even insight into our email habits?

On Tuesday, as he was slogging through some somewhat antique code in the front-end of Thunderbird, Andrew asked whether Thunderbird’s “start page” was what we wanted it to be, which is Andrew-speak for “this is broken, we should fix it”. We’d actually discussed what to do with that page for a long time, but had focused on other, more infrastructure bits for a while. I decided it was time to dust off those plans, and see what we could do.

First, some background. The “start page”, which makes a lot of sense in Firefox, never made a huge amount of sense to me in Thunderbird. In particular, it’s shown only when a folder is selected, and no message is selected. That’s hardly a logical time to show the (colorful, pretty, but fairly useless) page we show now. Instead, why not show information about the selected folder, and help people who clearly intended to select a folder, so most likely wanted to do something related to that folder!

We could still use a small part of the pane to display interesting news snippets, as a way of keeping users aware of new developments, such as new add-ons that we want to promote, or Mozilla events. In fact, by making that page useful, we’re more likely to get people to read a sentence or two which might change periodically, as opposed to changing a page that is so big, wordy and useless, that I suspect most users are completely blind to it.

A couple of days later, we have an early patch, which feels pretty compelling to me:

  • It summarizes critical data about the folder (name, number of messages, number of unread messages);
  • if you were recently reading that folder, it points out the last message you were reading, so you can quickly find it again;
  • it shows you a few of the messages that are most likely of interest (because they’re unread or starred);
  • and finally it gives some information about the activity in the folder: a histogram showing activity over the last 52 weeks, and most prolific authors and most active threads during that same period.

For example:

Folder summary

The icing on the cake is that if you hover over an author or a thread title, it will highlight when those messages occurred in the histogram (in this case, the “An alternate take on HTML 5″ thread). Readers of m.d.platform won’t be surprised at any of the names that show up above!

There are lots of possible additions: Some of the ones we’ve thought of include:

  • showing how much disk space is used by the folder
  • showing the “largest” messages
  • showing the status of autosync/indexing jobs

Note: this hasn’t been through a visual design phase yet — the look will change, once someone who knows what they’re doing has a chance to make it nicer! There’s also a lot of work to do to make sure that it does the right thing for saved searches, smart folders, etc. And yes, we’ll make it optional, just like the start page is now.

I’ve been playing with it for only a little bit, and it’s fascinating how interesting it is to get some data on one’s email. For example, I more-or-less follow a small-inbox model, where emails don’t stay in my inbox if I can avoid it — they get deleted, or archived. As a result, the sparkline for my inbox is:

inbox sparkline

which isn’t as short as it should be, telling me pretty quickly that I have some old messages that need attention. It’ll be interesting to see what else we learn from these kinds of simple personal analytics.

What other kinds of visualizations, summaries, and analysis would you like to see in Thunderbird, or in add-ons?

[Update]: I liked the idea that a commenter suggested of showing what tags were in use in the folder, so I had some fun, first with a “tagpie”, which proved mostly useless, just like most piecharts; then with a “tagdots” small-multiples visualization:

tagpies, tagdots, sparklines oh my!

I don’t think the tagpie is worth keeping, but the dots are tempting. As an aside, the Protovis library really is as easy to use as I’d hoped.

Getting insight into one’s own email

Standard

Thunderbird knows a lot about your email. After all, it’s got access to large amounts of data, and builds sophisticated databases so that it can be very responsive, even when dealing with large folders containing thousands of messages. Wouldn’t it be nice if we could use this information to extract either faster workflow, or even insight into our email habits?

On Tuesday, as he was slogging through some somewhat antique code in the front-end of Thunderbird, Andrew asked whether Thunderbird’s “start page” was what we wanted it to be, which is Andrew-speak for “this is broken, we should fix it”. We’d actually discussed what to do with that page for a long time, but had focused on other, more infrastructure bits for a while. I decided it was time to dust off those plans, and see what we could do.

First, some background. The “start page”, which makes a lot of sense in Firefox, never made a huge amount of sense to me in Thunderbird. In particular, it’s shown only when a folder is selected, and no message is selected. That’s hardly a logical time to show the (colorful, pretty, but fairly useless) page we show now. Instead, why not show information about the selected folder, and help people who clearly intended to select a folder, so most likely wanted to do something related to that folder!

We could still use a small part of the pane to display interesting news snippets, as a way of keeping users aware of new developments, such as new add-ons that we want to promote, or Mozilla events. In fact, by making that page useful, we’re more likely to get people to read a sentence or two which might change periodically, as opposed to changing a page that is so big, wordy and useless, that I suspect most users are completely blind to it.

A couple of days later, we have an early patch, which feels pretty compelling to me:

  • It summarizes critical data about the folder (name, number of messages, number of unread messages);
  • if you were recently reading that folder, it points out the last message you were reading, so you can quickly find it again;
  • it shows you a few of the messages that are most likely of interest (because they’re unread or starred);
  • and finally it gives some information about the activity in the folder: a histogram showing activity over the last 52 weeks, and most prolific authors and most active threads during that same period.

For example:

Folder summary

The icing on the cake is that if you hover over an author or a thread title, it will highlight when those messages occurred in the histogram (in this case, the “An alternate take on HTML 5″ thread). Readers of m.d.platform won’t be surprised at any of the names that show up above!

There are lots of possible additions: Some of the ones we’ve thought of include:

  • showing how much disk space is used by the folder
  • showing the “largest” messages
  • showing the status of autosync/indexing jobs

Note: this hasn’t been through a visual design phase yet — the look will change, once someone who knows what they’re doing has a chance to make it nicer! There’s also a lot of work to do to make sure that it does the right thing for saved searches, smart folders, etc. And yes, we’ll make it optional, just like the start page is now.

I’ve been playing with it for only a little bit, and it’s fascinating how interesting it is to get some data on one’s email. For example, I more-or-less follow a small-inbox model, where emails don’t stay in my inbox if I can avoid it — they get deleted, or archived. As a result, the sparkline for my inbox is:

inbox sparkline

which isn’t as short as it should be, telling me pretty quickly that I have some old messages that need attention. It’ll be interesting to see what else we learn from these kinds of simple personal analytics.

What other kinds of visualizations, summaries, and analysis would you like to see in Thunderbird, or in add-ons?

[Update]: I liked the idea that a commenter suggested of showing what tags were in use in the folder, so I had some fun, first with a “tagpie”, which proved mostly useless, just like most piecharts; then with a “tagdots” small-multiples visualization:

tagpies, tagdots, sparklines oh my!

I don’t think the tagpie is worth keeping, but the dots are tempting. As an aside, the Protovis library really is as easy to use as I’d hoped.

Thunderbird 3 beta 2

Standard

On the road to Thunderbird 3, another milestone — this time, Thunderbird 3 beta 2.

illustration

Why do beta releases?

Beta releases are funny things. They serve a few purposes. The first is to make sure that we periodically stabilize the code base, as without periodic ‘cooling’, it’s hard to get a handle on the quality of a piece of software. Betas also serve as deadlines, which are magical motivators for some people. Some of us will spend way too many hours staying up late in the night in order to “make a deadline”.

Betas for open source software are even more odd in that people interested in staying very involved with the project can use nightly builds, which are updated every day. I’ve been using nightly builds of Thunderbird for over a year, as have several thousand other users. As a user of nightlies as much as a project coordinator, by the time the beta is released to a wider audience, all the excitement is historical.

Another fascinating aspect of beta releases is that, because we know there will be another release, and because the purpose of the beta is to get a broader set of testers to shake out edge cases, we try to be conservative about slipping in major features at the last minute, as the odds of those features being polished in time are never what we hope they’ll be. So we routinely delay feature additions until the next cycle, to avoid dragging the beta validation process out. It’s an unpleasant, but unavoidable part of optimizing releases.

If we do our job right there, then by the time the beta ships, the features that have landed are free of major bugs. We of course can’t know that until we get feedback from the beta.

What’s in this release?

The most striking part of the release is the sheer volume of bug fixes. It’s not sexy work, it’s often the hardest work, but it’s very important. This list (of bug fixes and feature work, but mostly bug fixes) is impressive.

Of the features that have landed, I want to talk about two that many users could easily ignore: archiving, and the activity manager.

The archive feature is straightforwardly borrowed from GMail’s archive feature, which we think is great. The idea is that figuring out exactly which folder each message should be filed is a process that can take a lot of time and effort — something that wasn’t a real problem in the early days of email, but which becomes a real time sink with thousands of messages. With a good enough search engine, it’s easier for many users to simply “archive” the message (doesn’t really matter where), get it out of the way, and then rely on the search capability to find the message again.

In this beta, we’re half-way there. The archive feature is there if you want it, but you can also use the standard “file in a folder” method. Thanks to work we did before beta2, the archiving is fast, putting messages in per-month folders at the click of a buttton or a keystroke. The new fast global search hasn’t landed yet, but even our “old” cross-folder search mechanism has gotten a lot better.

I already love the feature — being able to select messages I don’t need to worry about anymore, hit ‘A’ and be done with them, saves me a lot of time and mental effort

The second feature worth highlighting is also not fully deployed, but already useful. The Activity Manager was born out of a recognition that Thunderbird 2 is pretty bad at telling you what it’s doing. It says a lot of things, it says them fairly loudly, but they’re rarely the things you want to know. We’re building infrastructure that will let the various bits of Thunderbird be much more helpful in describing what’s going on (through a log of notable events), what went wrong (non-intrusive but notable alerts), and how it’s progressing at long-running tasks (with more context than just a single progress bar). Teaching software that wasn’t designed with a notification mechanism or philosophy in mind how to be polite and informative is a slow and arduous task, but we’re making good progress. In Thunderbird 3b2, there’s an Activity Manager window, which for now will just report on message moves, copies and deletes, and IMAP auto-syncing. Now that the framework is in place, we should be able to have a lot more informative messages when you need them, and reduce the number of dialog boxes (especially the ones you can’t do anything about!).

One of the fascinating aspects of the activity manager is that it’s giving even those of us who know how the software works on a detailed level a better handle on important global aspects. For example, the activity manager showed me that the autosync function can and should be much more aggressive, so that more of your email is already downloaded before you need it.

Other features you may notice:

  • Much more useful Growl notifications on OS X
  • Keyboard shortcuts for quick tab navigation
  • Better looking forwarded mail
  • Fewer dialog boxes

What’s next?

The next beta release is our last scheduled beta. As such, we’re thinking of it as the last milestone to introduce Big New Features. Furthermore, we’re hoping to be even better behaved this cycle and land features as early in the process as possible. Upcoming features which we hope will be available in a nightly build soon include:

  • the new global search function, leveraging tabs
  • cleaning up the message header area further
  • “pop tarts” to complement the activity manager
  • the beginning of some theming work (prettier icons, etc.)

And then, of course, there will be unplanned bright ideas which show up out of nowhere. Life wouldn’t be fun without those.

Try out the beta, file bugs, send feedback!

PS: the illustration at the top is from a brand spankin’ new website for Mozilla Messaging. We’ve changed the site to make it the primary destination for Thunderbird users, riffing on the look of other Mozilla websites, and yet quite distinct. I find the illustrations in particular a lot of fun, and I’m very proud of the team that built it. Rafael Ebron ran the project with the SpreadThunderbird team, with designs from The Royal Order, and implementation from silver orange. A very nice job, thanks to all who contributed!  The new site also allows us to build localized sites, which will be amazing.

Progress Update

Standard

I just realized that I forgot to blog about some of the exciting things going on in Thunderbird land these days.

First, I’m very happy to announce that another engineer has signed up to work full time on Thunderbird — Mark Banner, aka Standard8 on IRC. Mark is well known to the Mozilla community, as someone who’se been a steadfast contributor for years, doing important behind-the-scenes work, especially on the address book — a part of Thunderbird which I expect will become more important over the next few releases. It’s great to have Mark on board, even though he’s not officially starting until next month. One of the projects that Mark will finally have time to push on is to beef up the test automation framework and help drive better test coverage for the codebase, which is a crucial step to allow the refactoring we want to do, and facilitate a more agile development model.

Second, I’m equally happy to announce that Rick Tessner has joined as a part-time build engineer, helping with build automation, release automation, etc. If you’re interested in build engineering, I highly recommend reading John O’Duinn’s blog. John’s team has taken on the task of bringing some sanity to the Mozilla build system while Firefox 3 is finishing. To use an analogy my ActiveState colleagues will remember, it’s like repairing an aircraft fuselage in flight. John’s team has made great strides in improving build and release automation for Firefox 2 (and 3), and Rick will work with them to improve build and release automation for Thunderbird 2 and 3.

Which brings me to the topic of release planning for security updates, a topic which may be puzzling to people who don’t follow the process closely. Here’s how it works, from my newbie perspective.

Mozilla regularly ships security updates to both Firefox and Thunderbird (these days, they’re called 2.0.0.x), with a schedule which is the result of analyzing:

  • the number and criticality of the security fixes that are available
  • the likelihood of people being impacted (taking into account things like whether the default configurations are vulnerable)
  • the frequency of recent releases (as users get “update fatigue” and updating too often may in fact result in more exposure).
  • the unavoidable challenges of scheduling the activities of the people needed to produce a quality release, including developers, build engineers, QA engineers, release managers, localizers, etc.

This is further complicated by the fact that, as of now, there are three product lines which end up relying on many of the same staff, especially in the Build & QA stages (Firefox 2.0.0.x, Firefox 3, and Thunderbird 2.0.0.x). For now, MoCo staff are primarily responsible for the Thunderbird security releases, with great people like Dan Veditz, Sam Sidler, Al Billings, Nick Thomas, and more pushing those through.

What that means in practice is that we have to make some tough choices. For example, there’s a Firefox 2.0.0.13 release coming up, which fixes some security bugs. Some of those are in the part of the code that is shared with Thunderbird. There will therefore be a matching Thunderbird 2.0.0.13. The only question is when. At the scheduling meeting, it was clear that the ideal scenario (near-simultaneous security releases for Firefox and Thunderbird) was simply impossible, mostly because of resource contention. Some of those resource contentions are due to not enough automation for the Thunderbird release process, and some of it is the consequence of not enough people with the right training — one of the factors that led to the creation of Mozilla Messaging. After careful weighing of the various options, we all agreed that Thunderbird 2.0.0.13 will have to release several weeks after Firefox 2.0.0.13. The strange thing is this: everyone on the call was unhappy about it. But I actually feel that the choice was the right one, given the circumstances.

For example, some of the security fixes can only be exploited using JavaScript. Because the vast majority of Firefox users have JavaScript enabled (because it’s the default, because it’s a key part of the web experience), a Firefox user is more at risk for that kind of issue than a Thunderbird user (Thunderbird doesn’t ship with JavaScript enabled by default). We could delay releasing Firefox until Thunderbird was ready, in the interest of mitigating the risk of someone using knowledge from the Firefox release to try and attack Thunderbird users. But that would mean leaving over a hundred and fity million users vulnerable. So, applying the correct math, we release Firefox security updates as soon as possible, and Thunderbird security updates as soon as possible. This time, we were hit by the extra whammy that some of the people needed for the Thunderbird build are also doing work that’s critical to the Firefox 3 release, which itself will boost security on the net. That’s unfortunate, but I still think we should be proud of these tough choices.

The process that we go through when scheduling these releases is to try to optimize a global metric which I think of as “public safety”. And when we do that well, the outcome is one that I can live with because 1) the global metric is the one to pay attention to, and 2) Thunderbird benefits so much from Firefox that any scheduling slight is “immaterial” in the grand scheme of things. Even just looking at the (relatively) narrow topic of security, it’s incredibly valuable to have the ear (and attention, and interest) of security folks like Dan Veditz, who truly care about Thunderbird. Beyond security, Thunderbird gains daily from the improvements in the platform, and even features built “for” Firefox 3 like the new download manager will be even more valuable in Thunderbird. The list goes on.

Naturally, living with the best possible schedule given constraints isn’t _enough_, and that’s why we’re hiring the best people possible to:

  • reduce the amount of manual work for test, build or release,
  • increase test coverage and code quality, and
  • build out parallel build, QA and release processes for Thunderbird.

Which loops back to Mark and Rick whose work will, in time, help alleviate these issues. Note that while I’ve primarily talked about the 2.0.0.x security updates, the vast majority of what Rick will do in release automation will be applicable straight away to future Thunderbird 3 releases. Mark Banner’s test automation work is going to apply to Thunderbird 3 nightly builds, for example.

I’ll be away from the net for a while, but when I get back I’ll write a more detailed introduction to the people working on Thunderbird, both staff and contributors.

JSON vs. XML for configuration files?

Standard

One of the topics we’re discussing in Thunderbird dev land involves how to distribute configuration files for Thunderbird, so that if you’re part of a group (users of large ISPs, enterprise users, gmail users, whatever), that the “right” default configuration can be picked up as automagically as possible.

There’s lots behind that effort, but there’s one point of debate which I thought I’d throw out here explicitly to get input from people outside the Thunderbird community. Thunderbird can easily support either an XML dialect, or JSON files. There’s a feeling that the formats are isomorphic, and that figuring out which syntax ends up being a tooling issue, in particular for unknown third parties who might want to also implement parsing of these files. Some people believe that XML, being more mature, is more likely to be parseable by various software packages “out there”. Others believe that JSON is a better fit, because it’s lighter weight, more mashable, etc.

Are there good best practices that people have developed as to when to use which markup language?

Comments here, please. Keep it civil and constructive, please!

Philippe Starck on TED

Standard

Watching (and listening) to Philippe Starck is fun, and surprisingly easy to map onto my own beliefs about software and product design. A good way to end the week:

I particularly like the section in the middle about walking, and the difference between looking down, looking ahead, looking up, looking straight up, and looking inwards. It’s stunningly easy to apply to software designers.