• Thunderbird

Desktop Calendar: A Design Journey

Hello, Thunderbird community and followers of the blog! This is Jesse from the design team. Today’s post is about our recent journey in redesigning the calendar portion of Thunderbird, and what you can expect us to deliver in the near future.

The calendar is a key part of any productivity toolset, from your PC Desktop to your office wall. There has been a calendar in Thunderbird since early in the project, and like all parts of the application, it’s evolved on its own terms, for better or for worse. It has many layers of functionality, but the experience has lost parity with current UI standards — at this point, it feels stylistically dated and functionally convoluted.

So, with the help of the design team and the developers and the community, we have taken on the task of modernizing and streamlining the calendar. This is my account of the designers’ part of that journey.

The Big Picture

Here are some of our guiding principles for this redesign:

First, we are here to serve the entire user base, not just the technical experts, or the productivity enthusiasts, or the brand new adoptees. For this reason, the dialog with the community is critical: we need to understand as many of the use cases and interaction patterns as possible, and we want to support them broadly, and efficiently, and effectively. Our ideal solution is open and flexible, respecting the broad range of users who rely on Thunderbird.

Second, a key point: Thunderbird is aiming higher than being simply “the other email client.” We are all committed to creating an experience that meets and exceeds expectations, and competes directly with the oliphaunts in the room: the Google Calendars, the Apple and Microsoft application suites, and the many targeted productivity apps that jockey for this space.

And as always, we will do this transparently, with an open source philosophy, in collaboration with our users and contributors.

The Journey

This design journey has been ramping up for several years now, in parallel with other company initiatives (Mobile! Web! Accessibility!). As our design practice has evolved, we have worked on the project from several directions, redesigning dialogs and rethinking patterns and collecting insights. For a while, this meant a lot of partial designs, but without a guiding vision.

Among these early designs, one of our success stories was a visual and functional update of the Event Details dialog, to replace the existing, rather archaic event details window (”archaic” both visually and in terms of code). These were one of the first redesigns to reach a point where it could be implemented — prioritized partly because it’s a self-contained element, able to be tested without reworking the whole calendar code base.

If you use Thunderbird Daily, you may recognize this:

We’ve followed this pattern for several other bits and bobs, including the dialog for editing an event, and the notification for unanswered invitations. In all cases, these changes will create better contrast and visual hierarchy, and improve the visibility and organization of controls:

This alone could provide enough work for several release cycles. But designing isolated elements creates inconsistency and debt, both for design and development. As the design process on Calendar increased in velocity, it became clear that we needed to articulate a unifying vision.

Bringing it together

With these designs setting a direction, we had to step back and decide how all the pieces would fit together. In order to do that, we still had to answer three more questions:

• How does the actual calendar grid look, set to view a day, a week, a month, or a year?
• How does the user change their view and navigate forward and backward?
• How does the user connect to their calendars, and manage them all in one place?

These considerations led us to a lean design, with screen space broken up into three main sections. First is the grid, which provides the main element at the center of the layout — the user’s primary workspace. Second is the navigation bar, directly above the grid. Third is a sidebar for managing calendars — the nerve center for your calendars and data sources. This design, focused on the most important functional areas, provided a great foundation for all the necessary functionality, with low friction and strong fundamentals.

The blueprint for our design (called a “wireframe” in the UX design world) ended up looking like this:

The grid acts as the user’s main workspace, and the header and navigation provide their basic controls.

Here is a final design mock-up, which will provide the basis for development (this one is showing a week view in the main grid):

Given the wide range of our users’ scheduling needs, we decided the calendar sidebar should be collapsible, and useful at both large and small sizes, so that users could decide how much of a footprint they needed to manage their calendar list.Here is the screen with the sidebar in a collapsed state, showing a Month view in the main grid:

And here is this screen after the user has pressed “New Event,” showing the Create Event window over the interface:

Where we go from here

As these elements came together, we also turned outward and looked to our community for more feedback. Through the various stages of design, we published two TopicBox posts (here and here), and we ran a short but informative survey, looking for initial reactions to the direction we were taking.

This feedback has been very encouraging, and also enlightening: we have seen a positive response to our designs, and we’ve also gathered lots of insights on what you cite as most important (task integration, platform interoperability, and a re-assessment of agenda, mini-month, and multi-week views, to name a few).

These discussions gave us some additional confidence, but more so, they reminded us that we are still at the beginning of a longer arc. After we develop version 1 of our new calendar design, we will follow signals from our users as we plot a path forward. The new calendar design will clean up and simplify many aspects of the experience, but it will only be a promising first step (sort of the Rivendell stage of the epic). We will have many more cycles of design and iteration to bring our users the toolset they deserve.

For now, we venture forth, from design to implementation, and then from implementation to feedback and engagement. The new calendar will be released gradually, via proper channels, so users can try it and provide feedback — and feedback will be appreciated! We will be looking for usability testers and survey participants as we keep refining the roadmap.

The future of calendar is wide open, and much brighter and less gray than the bygone era. We appreciate all the support we’ve gotten from the community so far, and we hope you’ll continue with us as we keep making Thunderbird awesome.