Features/Desktop/Ability to run concurrent channels

Please use "Edit with form" above to edit this page.

Status

Ability to run concurrent channels
Stage	Feature Inbox
Status	`
Release target	`
Health	OK
Status note	Channel switcher removed, identifying participants & priority next.

{{#set:Feature name=Ability to run concurrent channels

|Feature stage=Feature Inbox |Feature status=` |Feature version=` |Feature health=OK |Feature status note=Channel switcher removed, identifying participants & priority next. }}

Team

Product manager	`
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	`

{{#set:Feature product manager=`

|Feature feature manager=Alex Limi |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Juan Becerra |Feature ux lead=Alex Limi |Feature product marketing lead=` |Feature operations lead=` |Feature 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.

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:

1. 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.
2. 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)
3. 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.
4. 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:

1. Make the solution conceptually simple, and make it easy to identify what browser you're actually using.
2. Make running the various versions in parallel dead simple, and make this the default behavior.
3. 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:

1. By downloading it from the Firefox web site
2. 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:

1. All be separate binaries, with their own directories named accordingly.
2. Never mention the version name in the start menu or app name.
3. Have separate process names, like firefox-beta.exe, firefox-aurora.exe, etc.
4. 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

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |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. |Feature users and 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:

1. 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.
2. 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)
3. 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.
4. 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:

1. Make the solution conceptually simple, and make it easy to identify what browser you're actually using.
2. Make running the various versions in parallel dead simple, and make this the default behavior.
3. 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:

1. By downloading it from the Firefox web site
2. 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:

1. All be separate binaries, with their own directories named accordingly.
2. Never mention the version name in the start menu or app name.
3. Have separate process names, like firefox-beta.exe, firefox-aurora.exe, etc.
4. 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. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	Unprioritized
Rank	999
Theme / Goal	`
Roadmap	Platform
Secondary roadmap	`
Feature list	Platform
Project	`
Engineering team	`

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=` }}

Team status notes

	status	notes
Products	tbd	`
Engineering	tbd	`
Security	tbd	`
Privacy	tbd	`
Localization	tbd	`
Accessibility	tbd	`
Quality assurance	tbd	`
User experience	tbd	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=tbd

|Feature products notes=` |Feature engineering status=tbd |Feature engineering notes=` |Feature security status=tbd |Feature security health=` |Feature security notes=` |Feature privacy status=tbd |Feature privacy notes=` |Feature localization status=tbd |Feature localization notes=` |Feature accessibility status=tbd |Feature accessibility notes=` |Feature qa status=tbd |Feature qa notes=` |Feature ux status=tbd |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}