|Release target||Thunderbird 17|
|Directly Responsible Individual||`|
|Product marketing lead||`|
|Additional members||Nate Watson|
1. Microsoft will be the only provider of Metro apps. Getting it through is going to be a problem.
2. Running an E-mail client with the suspend system is going to cause some annoyances to the users and developers.
3. How is a calendar going to be included? The calendar team will need to be brought in on this.
Stage 1: Definition
1. Feature overview
Windows 8 will have 2 application environments: classic and metro. Thunderbird only has a classic version. Comments about metro aside, Thunderbird will need a metro version in order to compete with Microsoft's proprietary clients, and to work on WOA. The goal of this feature is to port Thunderbird to the Metro environment, while continuing to use Mozilla's technologies.
2. Users & use cases
The target users in this case are Windows 8 users who would prefer a Metro version of Thunderbird, and WOA users who have no alternative.
This feature may require some or all of the Gecko, Necko, scripting engines, etc. to be somewhat modified. These should be reusable from Firefox metro.
Hard to define. Ideally, as many features from mainline Thunderbird as possible. However, if required, the following features can be skipped: search features, chat, big files.
All of the windowed components for Thunderbird will need to be moved to the tab infrastructure for Metro, but should remain as preferred in classic. We will also need to figure out how to work with the suspend system. While support for Add-ons should be included by default, inter-compatibility with Thunderbird Classic add-ons may not be viable. Naturally, we will need a version of lightning or an equivalent for this.
Due to the system framework, having synchronization between classic and metro Thunderbird.
Inter-compatibility with Thunderbird Classic add-ons.
Stage 2: Design
5. Functional specification
This feature will provide a Thunderbird interface that is designed to run on Metro. Large amounts of configuration will need to be introduced, due to the support for both touch screens and kb/m/m interfaces. Many elements from Thunderbird will need to be geometrically re-calibrated for touch screens. Due to Thunderbird's shortage of developers, in the early versions, Thunderbird Metro's interface will probably need to be as close as possible to Thunderbird main as possible.
For Metro, we should include 2 tabs systems: standard, like the one in Firefox; and visual, like the one in Firefox for tablets in horizontal mode. We may want to introduce some adaptations and/or port this over to Thunderbird for Classic. Introducing visual tabs may even necessitate its own feature due to the release cycles.
Due to the lack of a windowing system, many things that are currently windows will probably have to be moved to tabs in Thunderbird Metro, such as the message editor, contact manager, reminder system, and a bunch of other pages. As a result, Thunderbird Metro will use the tab infrastructure a lot more. This may require porting over "tab groups" from Firefox. It would also require certain "On hold" features to be completed.
Thunderbird Metro will need to be just as customizable as classic; but this will need to have various components released over different cycles.
6. User experience design
The current plan is to use thumbnail tabs at 0.75 inches of height. This won't waste too much screen space and will be easy to use for both touch and standard users.
The launchers, such as the calendar and task list, will be under a "launchers" menu.
The search icon will be equal to the launchers icon, at 0.75 inches by 0.75 inches. When active, it becomes a "close" button, with a "search board" up. There should be a suggested searches menu, and a touch-screen friendly mechanism for choosing which search engine, messages, or use all searches feature someone wants. When the user has the text entered/ selected, and they either select a search engine or just hit enter to go to their default, the search board will go away and open a new tab with the query results.
The calendar project should figure out how to set up their internal components.
Assuming this ships with the Thunderbird home tab feature, instead of using windowed alerts, which won't be viable, the designed internal alerts system in the Thunderbird home tab design should be used for things such as the activity manager. Other things which are more complicated should be moved to the tabs.
The toolbar buttons should be comparable to now, but with larger icons so they're easier to use on touch screens.
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Experience|
Team status notes
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);