+1 for shipping the same UI to all Android versions. >From a UX point of view I can see many benefits to giving all our users the same UI/UX. Especially since L has support down to 2.3 (?) now.
On Thu, Sep 3, 2015 at 11:25 AM, <mobile-firefox-dev-requ...@mozilla.org> wrote: > Send mobile-firefox-dev mailing list submissions to > mobile-firefox-dev@mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/mobile-firefox-dev > or, via email, send a message with subject or body 'help' to > mobile-firefox-dev-requ...@mozilla.org > > You can reach the person managing the list at > mobile-firefox-dev-ow...@mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mobile-firefox-dev digest..." > > > Today's Topics: > > 1. Re: Shipping one UI for all Android versions (Nicholas Alexander) > 2. A/B Testing in Firefox for Android (Mark Finkle) > 3. Re: A/B Testing in Firefox for Android (Martin Thomson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Sep 2015 10:46:02 -0700 > From: Nicholas Alexander <nalexan...@mozilla.com> > To: Sebastian Kaspari <s.kasp...@gmail.com> > Cc: mobile-firefox-dev <mobile-firefox-dev@mozilla.org> > Subject: Re: Shipping one UI for all Android versions > Message-ID: > < > camnwbr0k5oyfj0dvunzprx1nr7bn93t2u80ahpvr5wfd2tn...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Sebastian, > > On Thu, Sep 3, 2015 at 2:11 AM, Sebastian Kaspari <s.kasp...@gmail.com> > wrote: > > > Hey everyone, > > > > I remember when I joined Mozilla Michael asked me what's different > working > > here compared to working at other Android "companies". Back then my > answer > > was: The build system! Because this was so obviously different and maybe > a > > bit painful at the beginning. Since the build system gets better almost > > every day (Thank you nalexander!) my answer today would be: The big > effort > > we are making to ship multiple variations of our UI to the different > > Android versions. > > > > I don't have direct expertise in maintaining these UI variations, but I > would like to pile on that this type of unification is a Good Thing, and > I'm happy Sebastian has raised it. > > > > Two examples of what I mean: > > > > 1) The overflow menu. In Firefox: On most modern devices it's in the top > > right corner. On Gingerbread it's a simple, old Android menu triggered by > > pressing a hardware menu button. Then there are some devices with Android > > 4+ and a menu button. These devices get a menu that shows up from the > > bottom of the screen but has more features like the overflow menu. And I > > wouldn't be surprised if there are even more variations. :) Touching this > > code is not always easy. Writing UI tests can be frustrating because you > > have to handle all these variations (even though we do a good job hiding > > this behind components). > > > > 2) Themes: We have a default theme that derives from Android's default > > theme (Back then this could be anything, including funky variations > shipped > > by the device manufacturers), a v11+ theme that inherits from the Holo > > theme, a v14+ style that overrides some styles and a v21+ theme that > > inherits from the Material theme. In addition to that we define styles in > > default, v11, v13, v16 and v19. Some styles are inherited from previous > > versions and some are overridden. I recently tried to change the v21 > theme > > and I couldn't follow all style paths because of the complexity. > > > > On the one hand, I'm impressed that we have been able to maintain this > and > > are shipping a Look & Feel that matches the one of the particular > platform > > very closely, but on the other hand, I don't know of any other popular > app > > that does that. Instead they ship the same (modern, now: Material) UI to > > all devices with the help of the support library and appcompat library > (And > > nowadays the Android design support library too). > > > > Some examples: > > * The Toolbar API allows us to have the same ActionBar behavior > > independently of the Android version we are running on (vs. maintaining > > different menus) > > * The appcompat library comes with a theme that resembles the Material > > theme on all Android versions (as good as it can). This allows us to use > > and adapt just one theme. > > * We are maintaining some custom components that we could replace with > > feature richer and more tested support components, e.g our > > TabMenuStripLayout > > > > But of course there are some downsides: > > * We already include the support library and the appcompat library (at > > least for builds with MOZ_NATIVE_DEVICES set) but not the design library > > (bug 1189306). We don't need it yet but it will grow the APK size. Even > > though proguard might be able to reduce this a bit. > > > > The AAR is 200k, of which almost all of that is classes.jar. It's worth > investigating the impact of Proguard further, but using this design library > sounds like a great idea. The more custom code we replace with upstream > code, the easier it is for new engineers to come to the code base. > > > > * Shipping the same thing to all devices with the help of support > > components removes the advantage of possible APK size reductions by > > splitting APKs by version. > > > > In some ways, yes. In others, no. We do need to be aggressive about > guarding features across APK splits. > > > > Okay, this mail got longer than I thought. I wanted to write it for some > > time to hear your opinions but now that I saw a new bug about inheriting > > styles from AppCompat (bug 1201206) I wanted to get it out. :) > > > > Thanks for this email. I hope that mcomella, mhaigh, and others with more > informed opinions will weigh in here to set public direction. > > Nick > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.mozilla.org/pipermail/mobile-firefox-dev/attachments/20150903/29bdcc33/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 3 Sep 2015 14:16:42 -0400 > From: Mark Finkle <mfin...@mozilla.com> > To: "mobile-firefox-dev@mozilla.org" <mobile-firefox-dev@mozilla.org>, > "group, mozilla.dev.planning" <dev-plann...@lists.mozilla.org> > Subject: A/B Testing in Firefox for Android > Message-ID: > < > cacfdpeyxmacpyreyedquajifnsotudxagumhpazzy16fng3...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > We have decided to start running A/B Testing [1] in Firefox for Android. > These experiments are intended to optimize specific outcomes, as well as, > inform our long-term design decisions. We want to create the best Firefox > experience we can, and these experiments will help. > > The system will also allow us to throttle the release of features, called > staged rollout, so we can monitor new features in a controlled manner > across a large userbase and a fragmented device ecosystem. If we need to > rollback a feature for some reason, we'd have the ability to do that. > > Technical details: > * Switchboard is used to control experiment segmenting and staged rollout. > * Telemetry is used to collect metrics about an experiment. > * FHR is used to track active experiments so we can correlate to > application usage. > > == What is Switchboard? == > > Switchboard is an open source SDK for doing A/B testing and staged rollouts > [2][3]. It connects to a server component, which maintains a list of active > experiments. > > The SDK does create a UUID, which is stored on the device. The UUID is sent > to the server, which uses it to "bucket" the client, but the UUID is never > stored on the server. In fact, the server does not store any data. The > server we are using is being hosted by Mozilla. > > We decided to start using Switchboard because it's simple, open source, > saves no data and can be hosted by Mozilla. Thanks to the KeepSafe folks > for releasing Switchboard. > > == Planning Experiments == > > The Mobile Product and UX teams are the primary drivers for creating > experiments, but as is common on the Mobile team, ideas can come from > anywhere. We have been working with the Mozilla Growth team, getting a > better understanding of how to design the experiments and analyze the > metrics. UX researchers will also have input into the experiments. > > Once Product and UX complete the experiment design, Development would land > code in Firefox to implement the desired variations of the experiment. > Development would also land code in the Switchboard server to control the > configuration of the experiment: Is it active? How are the variations > distributed across the user population? > > Since we use Telemetry to collect metrics on the experiments, the Beta > channel is likely our best time period to run experiments. Telemetry is on > by default on Nightly, Aurora and Beta; and Beta is the largest userbase of > those three channels. > > Once we decide which variation of the experiment is the "winner", we'll > change the Switchboard server configuration for the experiment so that 100% > of the userbase will flow through the winning variation. > > Yes, a small percentage of the Release channel has Telemetry enabled, but > it might be too small to be useful for experimentation. Time will tell. > > Note: Switchboard itself will be enabled on all channels. It collects no > data and gives us a "code-free" way of staging rollouts. It much less risky > and time consuming than uplifting patches that need to land on branches at > specific times. > > == What's Happening Now? == > > Switchboard has already landed in Nightly [4] and is currently behind a > Nightly build flag. Once we feel comfortable, we'll let it ride the trains. > Our first experiment will likely be testing a new onboarding experience > [5]. > > [1] https://en.wikipedia.org/wiki/A/B_testing > [2] https://github.com/KeepSafe/Switchboard > [3] > > http://keepsafe-engineering.tumblr.com/post/28437940369/easy-mobile-ab-testing > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1196897 > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1199859 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.mozilla.org/pipermail/mobile-firefox-dev/attachments/20150903/2c784c85/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 3 Sep 2015 11:25:07 -0700 > From: Martin Thomson <m...@mozilla.com> > To: Mark Finkle <mfin...@mozilla.com> > Cc: "group, mozilla.dev.planning" <dev-plann...@lists.mozilla.org>, > "mobile-firefox-dev@mozilla.org" <mobile-firefox-dev@mozilla.org> > Subject: Re: A/B Testing in Firefox for Android > Message-ID: > <CAPLxc= > uka9jf+wvjytrpxfe-8_kuopnuh9xze4oz5bjasoo...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > This seems like a good idea. > > Has anyone considered contributing a change to switchboard that would > allow the experiment policy to be downloaded to clients and the A/B > decision made there? That removes any possibility of creating another > potential tracking mechanism. > > On Thu, Sep 3, 2015 at 11:16 AM, Mark Finkle <mfin...@mozilla.com> wrote: > > We have decided to start running A/B Testing [1] in Firefox for Android. > > These experiments are intended to optimize specific outcomes, as well as, > > inform our long-term design decisions. We want to create the best Firefox > > experience we can, and these experiments will help. > > > > The system will also allow us to throttle the release of features, called > > staged rollout, so we can monitor new features in a controlled manner > > across a large userbase and a fragmented device ecosystem. If we need to > > rollback a feature for some reason, we'd have the ability to do that. > > > > Technical details: > > * Switchboard is used to control experiment segmenting and staged > rollout. > > * Telemetry is used to collect metrics about an experiment. > > * FHR is used to track active experiments so we can correlate to > > application usage. > > > > == What is Switchboard? == > > > > Switchboard is an open source SDK for doing A/B testing and staged > rollouts > > [2][3]. It connects to a server component, which maintains a list of > active > > experiments. > > > > The SDK does create a UUID, which is stored on the device. The UUID is > sent > > to the server, which uses it to "bucket" the client, but the UUID is > never > > stored on the server. In fact, the server does not store any data. The > > server we are using is being hosted by Mozilla. > > > > We decided to start using Switchboard because it's simple, open source, > > saves no data and can be hosted by Mozilla. Thanks to the KeepSafe folks > > for releasing Switchboard. > > > > == Planning Experiments == > > > > The Mobile Product and UX teams are the primary drivers for creating > > experiments, but as is common on the Mobile team, ideas can come from > > anywhere. We have been working with the Mozilla Growth team, getting a > > better understanding of how to design the experiments and analyze the > > metrics. UX researchers will also have input into the experiments. > > > > Once Product and UX complete the experiment design, Development would > land > > code in Firefox to implement the desired variations of the experiment. > > Development would also land code in the Switchboard server to control the > > configuration of the experiment: Is it active? How are the variations > > distributed across the user population? > > > > Since we use Telemetry to collect metrics on the experiments, the Beta > > channel is likely our best time period to run experiments. Telemetry is > on > > by default on Nightly, Aurora and Beta; and Beta is the largest userbase > of > > those three channels. > > > > Once we decide which variation of the experiment is the "winner", we'll > > change the Switchboard server configuration for the experiment so that > 100% > > of the userbase will flow through the winning variation. > > > > Yes, a small percentage of the Release channel has Telemetry enabled, but > > it might be too small to be useful for experimentation. Time will tell. > > > > Note: Switchboard itself will be enabled on all channels. It collects no > > data and gives us a "code-free" way of staging rollouts. It much less > risky > > and time consuming than uplifting patches that need to land on branches > at > > specific times. > > > > == What's Happening Now? == > > > > Switchboard has already landed in Nightly [4] and is currently behind a > > Nightly build flag. Once we feel comfortable, we'll let it ride the > trains. > > Our first experiment will likely be testing a new onboarding experience > [5]. > > > > [1] https://en.wikipedia.org/wiki/A/B_testing > > [2] https://github.com/KeepSafe/Switchboard > > [3] > > > http://keepsafe-engineering.tumblr.com/post/28437940369/easy-mobile-ab-testing > > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1196897 > > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1199859 > > _______________________________________________ > > dev-planning mailing list > > dev-plann...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-planning > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > > > ------------------------------ > > End of mobile-firefox-dev Digest, Vol 31, Issue 4 > ************************************************* > -- *Anthony Lam* Senior Product Designer – Firefox for Android a...@mozilla.com
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
