Revised Ctrl+Tab and All Tabs UI landed, disabled by default

[Dao]

I've landed bug 465076 today. The UI is now disabled on trunk. This is
controlled by the browser.allTabs.previews and browser.ctrlTab.previews
preferences. I'd like to encourage nightly testers and whoever's
interested to flip both prefs and report bugs, so that we can make
further progress there. I've filed bug 505404 for tracking these bugs.

Regards,
Dao

[Axel Hecht]

I've tried to find out what the plan is for flipping those prefs, but
didn't really understand it. I'd love to see the rationale, in
particular as we're somewhat in the land of pre-landed strings.

Thanks

Axel

[belt...@mozilla.com]

The plan is that they will stay off for the foreseeable future, as
Boriss and Dao continue to iterate the UI based on user feedback. The
feature is not yet ready to ship to users on by default.

Does that make things more clear?

cheers,
mike

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

[Axel Hecht]

On 21.07.2009 13:10 Uhr, belt...@mozilla.com wrote:
> The plan is that they will stay off for the foreseeable future, as
> Boriss and Dao continue to iterate the UI based on user feedback. The
> feature is not yet ready to ship to users on by default.
>
> Does that make things more clear?

Somewhat.

I'll ask a little deeper because we just ran into somewhat of an public
outcry with how we code up an experimental feature in TB. Pref'ing off
something wasn't on the list of alternatives we had in that discussion,
so I'd love to collect some pros and cons. Incoherent as always when I
try to type thoughts flying through my brain.

What's the benefit of landing this pref'ed off, compared to keeping it
as an extension or a project branch?

From an l10n-impact point of view, pref'ing off a feature scares me in
the old familiar fuzzy way.

- do we have any expectations on what's happening for users of localized
builds that'd flip the pref?
- If it's supposed to work, then it'd it double the testing matrix.
- it doesn't practically differ from a pre-landed string, and
- when you flip the pref, you have a hard time figuring out how many
strings you expose. Not liking to run into something like the B3 count.
- what happens if we don't flip the pref?

Or, in a more pike-ish short way, do we have a timeline/plan for either
switching it on or backing it out?

Axel

[Dao]

On 21.07.2009 22:39, Axel Hecht wrote:
> What's the benefit of landing this pref'ed off, compared to keeping it
> as an extension or a project branch?

The extension doesn't yield useful feedback anymore, maybe its users are
satisfied too easily. I expected the worst when replacing the original
two-year-old Ctrl+Tab UI [1] with the one that's now on trunk. But there
was hardly any reaction from the 60,000 users who made the transition
from 3.0 (where the extension keeps the old UI) to 3.5 (where it uses
the new UI).

After not even a full day pref'ed off on trunk I've already got more
feedback from nightly testers.

I'm afraid feature branches aren't a viable option yet in that regard.

> From an l10n-impact point of view, pref'ing off a feature scares me in
> the old familiar fuzzy way.
>
> - do we have any expectations on what's happening for users of localized
> builds that'd flip the pref?

I don't think so, or at least no expectations that would require extra
QA attention. The browser won't start up without &showAllTabsCmd.label;
and &showAllTabsCmd.accesskey;, but that doesn't depend on the pref.
ctrlTab.showAll.label could be completely missing and the UI would still
work.

Dao

[1] https://addons.mozilla.org/en-US/firefox/images/p/24526/1218384633

[Dao]

On 22.07.2009 01:06, Dao wrote:
> 60,000 users who made the transition from 3.0 to 3.5

... roughly 77,000 users, actually. Somewhat hard to extract from the
AMO statistics.

[Blair McBride]

I had basically the same experience with Taskfox builds, until I also
put up a screencast. But even then, most feedback was directly from the
screencast, not the builds. Of course, that doesn't work well for
everything.

For feature branches to work, I think we need to be able to easily
switch between branches via the updater, and have the relevant
infrastructure to support that. And probably some additional special
sauce to change the mindset of testers, to make it more acceptable to
people.

- Blair

On 22/07/09 11:24 AM, Shawn Wilsher wrote:

> On 7/21/09 4:06 PM, Dao wrote:
>> I'm afraid feature branches aren't a viable option yet in that regard.

> I have to agree. I've gotten just about zero feedback on the
> asynchronous location bar from a feature branch.
>
> Cheers,
>
> Shawn