Some thoughts:
- We used separate "channels" when we've split out to separate branches:
home panels and new tablet. These were rarely tested (e.g. I didn't like
losing my profile data) and we found many more bugs after the merge -
essentially the same thing that happens when we move into the larger Beta
population. Granted, these channels were based off Nightly and unpublicized
beyond mailing lists but the fact that few devs used it is saying something.
- As part of the "Go Faster" initiative, there's the idea of shipping
features as addons - we can do this right now. Most of our control over the
user interface is from Java so it doesn't make sense to write many features
in JavaScript, but what we can do is ship the feature behind flags (e.g.
tab queues), one of them being, `if (isFeatureAddonInstalled()) {
doFeatureStuff(); }`. We can introduce users to these features via the Home
Banner and send them to AMO. The one thing we'd need here is a feedback
mechanism, but perhaps we can write a boilerplate JS addon that would
prompt the user if they'd like to give feedback on a feature, bring them to
a web page form if they accept, and give us the feedback that way. All
features-as-addons can be based off this boilerplate. Perhaps we can add a
hook on new-feature uninstall too to see why users are uninterested?
(Pending no negative feedback) Martyn, do you want to file a bug and get
moving on the latter? It'll probably require a bit more polishing but I'd
love to see tab queues in release. :)
- Mike (:mcomella)
On Fri, Jul 10, 2015 at 11:41 AM, Darrin Henein <[email protected]> wrote:
> cc UX
> *––*
> *Darrin Henein *∙ *Design Lead, Firefox Mobile *∙ Mozilla
>
>
> On Jul 10, 2015, at 12:45 PM, Nicholas Alexander <[email protected]>
> wrote:
>
>
>
> On Fri, Jul 10, 2015 at 9:33 AM, Martyn Haigh <[email protected]> wrote:
>
>> Hey people,
>>
>> At the start of the year I wrote a bit of functionality called Tab Queues
>> which stemmed from a personal desire to do something different in how
>> people use Firefox. I spent a lot of time learning the codebase (it was the
>> biggest bit of work I've done on Fennec by myself since I joined the team),
>> creating patches, working out where I went wrong and redoing patches.
>>
>> The Mozilla workweek at Whistler recently got me thinking a lot about how
>> we use our time, and if we are using it in the best possible way (hint:
>> we've got no idea). We're at the stage where Tab Queue V1 looks ready to
>> ship and what is troubling me is that we still have no idea if this is a
>> feature that people want rather than something we see as 'neat'.
>>
>> Really before a feature rides the trains I'd like to ship it to a group
>> of people who aren't our nightly users [1] and I'd like to get feedback
>> from them. We don't have a way of doing either of these things at the
>> moment as Beta is on lockdown for production ready code and we just don't
>> really have any way of getting actual feedback from users other than usage
>> stats from the telemetry data which is somewhat hand-wavey. We're flying
>> blind and it seems crazy to me that we often put in months of work on a
>> feature when we haven't even justified it's existence with real users.
>>
>> The way we operate at the moment in terms of letting features ride the
>> trains is great from a stability point of view, but not so great from an
>> experimentation / feedback point of view. It seems that we don't know if
>> people are going to like a feature until we ship it, by which point it's
>> too late to get constructive feedback. Apparently we have an early Beta
>> flag which we can use, but personally I don't understand why it's there.
>> Imagine if we shipped TQ behind this flag, users will start using and at
>> some point shortly after it'll just disappear as if it were never there.
>>
>> It's time to try something new. I've got some ideas:
>>
>> - We introduce a new channel which runs alongside Beta but differs in
>> two ways:
>>
>>
>> 1. Users sign up with the knowledge that this is our testing ground
>> and all that entails.
>> 2. We build a feedback mechanism in to the channel, similar to the
>> heartbeat on desktop ("How do you feel about <feature x>" - Happy face
>> /
>> Sad face with room for comments)
>>
>> We ship features in this channel which may never see the light of day;
>> this channel doesn't necessarily follow the same release schedule as
>> Beta/Prod and doesn't represent a final product (although it'll mostly be
>> stable enough to use as a daily driver). Using this channel allows users
>> to test features and also provide feedback for these features, giving them
>> a voice as to what works or not within Fennec. It allows us to prototype
>> an idea without having to get it to production level polish. We don't
>> worry about localisation at the moment and instead concentrate on getting
>> ideas out and getting feedback in.
>>
>> - Or we introduce a "Labs" section in Beta which enables users to opt
>> in to our testing ground. We then build and release features to beta
>> which
>> are hidden behind flags. The downside of this is that it wouldn't help in
>> the case of TQ which requests a permission bump as we can't currently
>> request permissions on the fly (come on Android M!). Also shipping stable
>> code is important and Beta is a great way of ensuring that our production
>> code is ready, I'm reluctant to mess with Beta too much.
>>
>> tl;dr. (Actually, I'm kidding -- I read it.) But there are a lot of
> folks pushing on these angles:
>
> * Right now, Desktop ships "Experiments" to a subset of people. These
> tend not to be user facing, IIUC.
>
> * There's a much larger effort to opt Desktop users into user-facing
> experiments. I don't know the engineers involved here but jgruen has been
> doing a lot of design work around this. I think this went under the name
> "Idea Lab". I don't know how advanced this work is.
>
> Nick
> _______________________________________________
> mobile-firefox-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
>
>
>
> _______________________________________________
> mobile-firefox-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
>
>
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
