A/B tests in beta? I agree with Jared, I don't really like preferences, either. I'd like to see in beta an Expand Sections / Collapse Sections toggle as another feature for which usage is measured.
On Tue, Sep 17, 2013 at 12:17 PM, Jon Robson <[email protected]> wrote: > The page load will be exactly the same in both situations. > Would would success look like? > > I also worry about doing this in alpha as alpha tends to have a small > audience of people with invested interest in the project (e.g. editors or > developers). I think the reader persona is the one we should be optimising > for and these tend to exist in beta... > > > On Tue, Sep 17, 2013 at 12:11 PM, Jared Zimmerman < > [email protected]> wrote: > >> I'm always reticent to add more preferences. I like Jon's suggestion of a >> way of the app learning from the users behaviors, although that can also >> lead to unexpected and inconsistent behavior. >> >> Instead of adding more prefs, i'd recommend that we try some of the >> following approaches. >> >> >> - In alpha expand by default, and collect metrics about page load >> times (in real world bandwidth scenarios) >> - Instrument a metric of what percentage of an article is viewed. >> - Instrument a metric of what percentage of sections that are expanded >> - Determine if the term in the search referer is in a sub-section and >> expand and go to that section by default >> - see if percent article read is different in autoexpanded and >> non-autoexpanded articles >> >> see if users freak out… >> >> >> >> * >> * >> * >> * >> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia >> Foundation >> M : +1 415 609 4043 | : >> @JaredZimmerman<https://twitter.com/JaredZimmerman> >> >> >> >> On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson <[email protected]>wrote: >> >>> Thanks so much for all the discussion so far. >>> I'm not so sure about infinite scroll I need to think more about this. >>> It seems wrong to me as there are always a finite amount of sections (so >>> it's never truly infinite or close to looking like infinite) and these >>> sections are already in the HTML so it seems wrong / unnecessary to hide >>> them. >>> >>> That said I think there are benefits to both approaches of the existing >>> behaviour - one where they are all open (and can be collapsed) and one >>> where they are all collapsed (and can be open) >>> >>> I think a sticky preference would be best that uses a combination of >>> localStorage and user preferences (the latter taking preference). I think >>> such a setting could be surfaced as a simple toggle control at the bottom >>> of the footer (although I'm not sure what the icon would look like). >>> >>> We could also imagine 'learning' a preference based on behaviour by a >>> user (do they always open all the sections they come across?) >>> >>> Personally the current setup only makes sense to me if the page loads >>> quicker due to not serving the html inside sections and loading the content >>> of those sections only when the section is toggled open (ie. lazy loading >>> content of sections). In the current form we serve all the content and due >>> to this there is an inevitable flash of the section collapsing as the >>> JavaScript and entire page has loaded. >>> >>> I'm not sure I agree with Steven's assessment that this will make >>> navigating between sections difficult - behaviour gets reverted - you close >>> the section to see the next section. This is akin to flicking through a >>> book and flicking to the next page (closing the section) if the heading at >>> the top of the page doesn't interest you. It just means you don't see all >>> the headings in one go which could be a good or bad thing. >>> >>> Is there an A/B test we could do here? In situation A we show all >>> sections open by default on say the Barack Obama article and in case B show >>> all sections closed by default (note this is a simple line of JavaScript). >>> If we were to do this what would we be optimising for? >>> * Would it be how many sections are collapsed? >>> * What % of the article is read (could equate to how far down the >>> article a user gets)? >>> >>> I think this matter can be solved by collecting data... >>> >>> >>> On Tue, Sep 17, 2013 at 10:29 AM, Adam Baso <[email protected]> wrote: >>> >>>> Resending now that I'm on the [email protected] list. >>>> >>>> >>>> On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso <[email protected]> wrote: >>>> >>>>> There's been some additional discussion on this, taking search engine >>>>> and Find in Page optimization into account. >>>>> >>>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=45951 >>>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=49202 (my duplicate >>>>> with some Find in Page-oriented stuff) >>>>> >>>>> The smart search engine / Find in Page stuff is moderately complex, so >>>>> I think the tappable options for section expansion are the place to start. >>>>> >>>>> It seems to me that the following achieves TOC-like information at a >>>>> glance while balancing page load performance, usability, user choice, and >>>>> user choice measurement: >>>>> >>>>> * Don't auto-expand articles by default >>>>> * Do have a JavaScript-injected "Expand Sections" / "Collapse >>>>> Sections" feature at the top of articles with multiple sections >>>>> * Do have a user preference for Auto-Expand Sections on Article Load. >>>>> * To gauge love/hate for features, have two preferences as follows >>>>> >>>>> *Show 'Expand/Collapse Sections' Option at Top of Articles* >>>>> On / Off (default = On) >>>>> >>>>> *Auto-Expand Sections on Article Load* >>>>> *Note: this may slow page load time* >>>>> On / Off (default = Off) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Sep 16, 2013 at 4:20 PM, Jared Zimmerman < >>>>> [email protected]> wrote: >>>>> >>>>>> I like the idea of expanding by default because it fixes my pet peev >>>>>> of not being able to do a find on page from my mobile browser without >>>>>> first >>>>>> expanding all sections. >>>>>> >>>>>> * >>>>>> * >>>>>> * >>>>>> * >>>>>> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia >>>>>> Foundation >>>>>> M : +1 415 609 4043 | : >>>>>> @JaredZimmerman<https://twitter.com/JaredZimmerman> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I didn't followed the thread, but if you try to consult the french >>>>>>> wiktionary with the mobile interface it's impossible: section title >>>>>>> are >>>>>>> links so when you try to uncollapse them, you follow the link. >>>>>>> >>>>>>> Le lundi 16 septembre 2013 à 11:05 -0700, Brion Vibber a écrit : >>>>>>> >>>>>>> > On Mon, Sep 16, 2013 at 10:51 AM, Arthur Richards >>>>>>> > <[email protected]> wrote: >>>>>>> > If we still want to explore dynamically loading article >>>>>>> > sections (which we all seemed to be in favor of when we did >>>>>>> > annual planning back in June), it's hard for me to imagine >>>>>>> how >>>>>>> > we could realistically pull that off if we display sections >>>>>>> > uncollapsed as default. >>>>>>> > >>>>>>> > >>>>>>> > We could rig up an "infinite scroll" type of situation, where we >>>>>>> > basically: >>>>>>> > >>>>>>> > >>>>>>> > * load section 0 and section 1 >>>>>>> > >>>>>>> > * leave placeholder <div>s for sections 2 and beyond >>>>>>> > >>>>>>> > * when the user scrolls down into section 1, start loading section >>>>>>> 2 >>>>>>> > in the background >>>>>>> > >>>>>>> > ** prepare the same thing for the bottom of section 2 load section >>>>>>> 3, >>>>>>> > etc... >>>>>>> > >>>>>>> > >>>>>>> > Of course a problem with this setup is that if you go offline >>>>>>> partway >>>>>>> > through reading the article, the later sections might be >>>>>>> unavailable >>>>>>> > when you scroll down to them. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- brion >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Design mailing list >>>>>>> > [email protected] >>>>>>> > https://lists.wikimedia.org/mailman/listinfo/design >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Design mailing list >>>>>>> [email protected] >>>>>>> https://lists.wikimedia.org/mailman/listinfo/design >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mobile-l mailing list >>>>>> [email protected] >>>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Design mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/design >>>> >>>> >>> >> >> _______________________________________________ >> Mobile-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > _______________________________________________ > Mobile-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
