Features/Desktop/Ability to run concurrent channels
Status
| Ability to run concurrent channels | |
| Stage | Design |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | Channel switcher removed, identifying participants & priority next. |
Team
| Product manager | Chris Lee |
| Directly Responsible Individual | Alex Limi |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | Juan Becerra |
| UX lead | Alex Limi |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
We want us to move to a model where the channels are self-contained and standalone instead of using a channel switcher model, and use Firefox Sync to bring over the data if those users want it to be available across channels.
This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)
2. Users & use cases
Web Developer use case
Here are the defining characteristics of pretty much every web developer that I have contact with in my other open source projects and consultancy companies:
- They rarely want to give up the stability of their setup. They need a functional Firefox with a stable, predictable Firebug. It's their bread and butter, and they need this to always work.
- They don't know about the profile manager (I'm always surprised about this, but it makes sense, since it's invoked via command line, and you have to know it exists in the first place to look for it)
- They'd like to test in multiple versions of Firefox at once, especially once we hit beta, so they know what to expect from the sites they are working on, so their clients won't come back and yell at them 1 month later when the new version is out.
- Having their history, bookmarks and settings available in the Beta, Nightly or whatever version they are testing is a bonus, but not super important to them.
How I'd like us to solve this:
- Make the solution conceptually simple, and make it easy to identify what browser you're actually using.
- Make running the various versions in parallel dead simple, and make this the default behavior.
- Use Sync to transfer data and settings, and don't try to reuse the same profile across different channels.
How it would work for them, step by step
I'm a web developer. I have the latest stable version of Firefox installed. I have two paths to discovering the Aurora/Beta channels:
- By downloading it from the Firefox web site
- By following a link or selecting an option in the About dialog
...both of which would give me a downloadable installer instead of trying to switch the release version I have with something else.
Let's say I decide to test the Beta:
- I get the downloadable installer, branded "Firefox Beta" everywhere. No version numbers anywhere.
- I install the thing, and end up with an entry called "Firefox Beta" in my start menu.
- When I click the Firefox Beta entry, it starts in parallel with my existing, running Firefox. It has a blank profile that is associated only with the Beta.
- The first page I see is "Congratulations, and thanks for helping us test Firefox Beta. Here's how to set up Sync if you want your data & settings to exist in all of your Firefox setups."
- I set up Sync, have my data & settings available, and I'm able to quickly switch between Firefox and the upcoming Firefox+1 (= Beta) to see if the project I'm currently working on is working the way it should in the upcoming version
- I can even run an experimental new Firebug in the Beta, and have my stable Firebug in the Release version.
- When e.g. Firefox 4 release upgrades to Firefox 5, my Firefox Beta will automatically be what will become Firefox 6.
- I can keep these start menu entries around essentially forever, and always be able to test the latest on each channel, with a minimum of confusion, since the application name always reflects what I'm looking at.
Summary
If someone was testing all of our variants, their start menu on windows would then look something like this:
- Firefox
- Firefox Beta
- Firefox Aurora
- Firefox Nightly
These entries would have the respective logos of the various channels. It would appear in a similar way in the Mac OS X dock. They would update on their respective channels, in a mostly silent manner.
These would:
- All be separate binaries, with their own directories named accordingly.
- Never mention the version name in the start menu or app name.
- Have separate process names, like firefox-beta.exe, firefox-aurora.exe, etc.
- All of them would run in separate profiles by default.
I believe this is conceptually simpler for the end user, easier to work with for us, and solves the testing use cases in a better way than what replacing the binary from under you will accomplish.
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
bug 895030 for Nightly
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P2 |
| Rank | 3 |
| Theme / Goal | Experience |
| Roadmap | Firefox Desktop |
| Secondary roadmap | ` |
| Feature list | Desktop |
| Project | ` |
| Engineering team | Desktop front-end |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
