I've been spending some time thinking about this "features as add-ons" idea, and I'm really interested to see what we can do here. I think the first step would be to decide which features in particular would be good candidates for this, since it's hard to make any meaningful progress without a real testcase. I don't know that it makes sense to do this now tab queues, since we've already made something we think it good enough to ship, and this is also a feature that would be pretty difficult to implement as an add-on in our current add-on system (e.g. an add-on can't request a new Android permission).
However, I do think we should brainstorm what other features could be good candidates for this type of experimentation. I also want us to try to see if there's a more elegant way to do this than asking a user to "go to AMO and install this thing". I've been wanting to experiment with this idea for some of our about: pages, where the user would "choose to enable" the feature by navigating to the page. A few weeks ago, I wrote a patch to covert our about:config page into an add-on (bug 1175379), but got hung up on a) where that code should live and b) the UX for installing this add-on. The easiest thing to do would be to just depend on the user downloading the add-on from AMO, and the next hardest thing would be including messaging in the product to explain this, but I'm wondering if we could create a system where we automatically download and install the add-on as soon as the user visits about:config. This pattern would also lend itself really well to about:feedback, a feedback solicitation page we show only once in the app's lifetime. In this case, I would also like the add-on to automatically uninstall itself when it's done, but that would be easy enough to put in the add-on logic. I also imagine this could make it easier for us to A/B test and iterate on a feature like this. Or maybe about:feedback should really just be converted into a hosted webpage, since that's the ultimate self-installing/uninstalling experience :) Margaret On Tue, Jul 14, 2015 at 1:44 PM, Michael Comella < [email protected]> wrote: > 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 > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
