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
