Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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 arichards@wikimedia.org 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 Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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 arichards@wikimedia.org 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 Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson jrobson@wikimedia.org 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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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 arichards@wikimedia.org 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 Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson jrobson@wikimedia.orgwrote:
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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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 > arichards@wikimedia.org 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 > Design@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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 jrobson@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson jrobson@wikimedia.orgwrote:
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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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 > > arichards@wikimedia.org 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 > > Design@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/design > > > _______________________________________________ > Design mailing list > Design@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design >
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Success for me would be greater percentage of article contents read, and little to no discernible change in load time for users.
freeform feedback from user like "my google search sent me the exact part of an article that answered my question" would also be great
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 12:18 PM, Adam Baso abaso@wikimedia.org wrote:
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 jrobson@wikimedia.orgwrote:
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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson jrobson@wikimedia.orgwrote:
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 abaso@wikimedia.orgwrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.orgwrote:
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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman > > > > On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < > psychoslave@culture-libre.org> 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 >> > arichards@wikimedia.org 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 >> > Design@lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/design >> >> >> _______________________________________________ >> Design mailing list >> Design@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/design >> > > > _______________________________________________ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
This sounds like a good measure of success. There will be absolutely no change in load time for users in either case. This is fact and we don't need to measure it :).
Kenan - could we plan doing this for a future iteration?
Pau: I think your approach is very interesting - we should explore that as well. It doesn't support the find on page function however... (to my knowledge we cannot detect when a find on page action occurs)
On Tue, Sep 17, 2013 at 1:43 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Success for me would be greater percentage of article contents read, and little to no discernible change in load time for users.
freeform feedback from user like "my google search sent me the exact part of an article that answered my question" would also be great
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 12:18 PM, Adam Baso abaso@wikimedia.org wrote:
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 jrobson@wikimedia.orgwrote:
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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Sep 17, 2013 at 11:41 AM, Jon Robson jrobson@wikimedia.orgwrote:
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 abaso@wikimedia.orgwrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.orgwrote:
> 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 < > jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman >> >> >> >> On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < >> psychoslave@culture-libre.org> 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 >>> > arichards@wikimedia.org 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 >>> > Design@lists.wikimedia.org >>> > https://lists.wikimedia.org/mailman/listinfo/design >>> >>> >>> _______________________________________________ >>> Design mailing list >>> Design@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/design >>> >> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Sep 17, 2013 at 1:43 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Success for me would be greater percentage of article contents read, and little to no discernible change in load time for users.
Hmm, I worry that greater percentage read may simply mean more time wasted trying to find specific information...
We also don't really have a way to measure what's _read_, just what's on screen and how long. A delay in scrolling might mean the user is reading, or it might mean they put their phone down to have a conversation.
freeform feedback from user like "my google search sent me the exact part of an article that answered my question" would also be great
That would be awesome yes!
-- brion
On Tuesday, September 17, 2013, Jon Robson 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.
Jon let me show you what I mean, if you're in the office.
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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 < jared.zimmerman@wikimedia.org> 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < psychoslave@culture-libre.org> 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
I think that collapsed headers supports an "overview" scenario that is really important. In order to support the "Immersive reading" experience without breaking the "overview" one we can experiment with the following: 1. Show sections collapsed initially. 2. If (and only) a section is expanded, when scrolling reaches the end of the current section, next section starts to expands as you scroll. 3. If scroll is triggered from the sections itself, they do not expand.
I attached a quick sketch.
Pau
On Tuesday, September 17, 2013, Jon Robson jrobson@wikimedia.org 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 abaso@wikimedia.org wrote:
Resending now that I'm on the design@lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso abaso@wikimedia.org 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 <
jared.zimmerman@wikimedia.org> 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
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf <
psychoslave@culture-libre.org> 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
