Removing the Watchlist icon on Opera / Lower JS Devices?

List overview All Threads
Download

newer

older

Translate FFS support for plurals...

Getting Flow mobile ready

Adam Baso

10 Jun 2014 10 Jun '14

3:02 a.m.

Juliusz suggested I email out details to mobile-l on the following. The question arose during an Opera discussion today whether hiding the Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia Zero) on mobile web in the page menubar (not the same as the flyout "hamburger" menu) might make sense generally for <noscript> or lower JS devices? The Watchlist star on the page menubar takes up a lot of space, and as it's the only thing there at the moment (on en.m at least, icons like Edit and Add Photo aren't shown), hiding that menubar icon would free up some valuable screen real estate. On <noscript> or lower JS devices (or browsers where RL suppresses JS due typically to challenges around timing of Deferreds and the like), using the Opera traffic as an example of such a browser, it seems like Watchlist usage is sort of low (this is at 1% sampling resolution). $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep 'action=watch' | wc -l 3 In other words, it seems users make it to the point of using the feature, but only about 300 times per day total. Meanwhile, the Watchlist start takes up valuable screen real estate for every pageview. The usage of the feature is about 1/10 of the Opera usage involving submission of the login form (a prerequisite of watchlist usage). $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l 31 Which is about 1/10 of Opera usage of the login feature in any capacity (GETting the form or POSTing the form) $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l 331 Which is maybe 1/270 of an oversimplified "pageview" metric on Opera Mini, using text/html response types as a rough guide. $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep 'text/html' | wc -l 89403 The relatively low usage of the Watchlist feature is probably symptomatic of the multiscreen flow on such devices. -Adam

Attachments:

attachment.htm (text/html — 2.6 KB)

Show replies by date

Jon Robson

10 Jun 10 Jun

3:33 a.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote:

...

Adam Baso

2:45 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Good question, will take a look once I'm at a place with stats cluster access. On Mon, Jun 9, 2014 at 6:33 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:

...

How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote: > Juliusz suggested I email out details to mobile-l on the following. > > The question arose during an Opera discussion today whether hiding the > Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia > Zero) on mobile web in the page menubar (not the same as the flyout > "hamburger" menu) might make sense generally for <noscript> or lower JS > devices? The Watchlist star on the page menubar takes up a lot of space, > and as it's the only thing there at the moment (on en.m at least, icons > like Edit and Add Photo aren't shown), hiding that menubar icon would free > up some valuable screen real estate. > > On <noscript> or lower JS devices (or browsers where RL suppresses JS due > typically to challenges around timing of Deferreds and the like), using the > Opera traffic as an example of such a browser, it seems like Watchlist > usage is sort of low (this is at 1% sampling resolution). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'action=watch' | wc -l > 3 > > In other words, it seems users make it to the point of using the feature, > but only about 300 times per day total. Meanwhile, the Watchlist start > takes up valuable screen real estate for every pageview. > > The usage of the feature is about 1/10 of the Opera usage involving > submission of the login form (a prerequisite of watchlist usage). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l > 31 > > Which is about 1/10 of Opera usage of the login feature in any capacity > (GETting the form or POSTing the form) > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l > 331 > > Which is maybe 1/270 of an oversimplified "pageview" metric on Opera > Mini, using text/html response types as a rough guide. > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'text/html' | wc -l > 89403 > > The relatively low usage of the Watchlist feature is probably symptomatic > of the multiscreen flow on such devices. > > -Adam > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >

Maryana Pinchuk

7:09 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Thanks for digging into this, Adam. I don't think the prominence of the feature is justified by the usage stats, so I'd be in favor of removing it from Opera/lower JS devices. On Tue, Jun 10, 2014 at 5:45 AM, Adam Baso <abaso(a)wikimedia.org> wrote:

...

Good question, will take a look once I'm at a place with stats cluster access. On Mon, Jun 9, 2014 at 6:33 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:

How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote: > Juliusz suggested I email out details to mobile-l on the following. > > The question arose during an Opera discussion today whether hiding the > Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia > Zero) on mobile web in the page menubar (not the same as the flyout > "hamburger" menu) might make sense generally for <noscript> or lower JS > devices? The Watchlist star on the page menubar takes up a lot of space, > and as it's the only thing there at the moment (on en.m at least, icons > like Edit and Add Photo aren't shown), hiding that menubar icon would free > up some valuable screen real estate. > > On <noscript> or lower JS devices (or browsers where RL suppresses JS > due typically to challenges around timing of Deferreds and the like), using > the Opera traffic as an example of such a browser, it seems like Watchlist > usage is sort of low (this is at 1% sampling resolution). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'action=watch' | wc -l > 3 > > In other words, it seems users make it to the point of using the > feature, but only about 300 times per day total. Meanwhile, the Watchlist > start takes up valuable screen real estate for every pageview. > > The usage of the feature is about 1/10 of the Opera usage involving > submission of the login form (a prerequisite of watchlist usage). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l > 31 > > Which is about 1/10 of Opera usage of the login feature in any capacity > (GETting the form or POSTing the form) > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l > 331 > > Which is maybe 1/270 of an oversimplified "pageview" metric on Opera > Mini, using text/html response types as a rough guide. > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'text/html' | wc -l > 89403 > > The relatively low usage of the Watchlist feature is probably > symptomatic of the multiscreen flow on such devices. > > -Adam > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

Jon Robson

7:29 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Maryana, I'm still not convinced that these usage stats tell the whole story. Also when talk/Flow gets added, then there will be 2 buttons in that bar, so I'm not sure the screen real estate issue is a good argument. Would we also remove Flow from the menu? Removing the watchstar from Opera only would actually be messy. The only correct way to do this programatically would be to remove the page actions bar for all non-JavaScript users (I refuse to have some nasty Opera specific hack). Some more questions and points: * you should look for the unwatch action as well. 'action=watch' is only for watching articles. * What is the global usage of the watchstar without JavaScript? What % of this is from Opera? e.g. $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'action=watch' $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'action=unwatch' On Tue, Jun 10, 2014 at 10:09 AM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:

...

Good question, will take a look once I'm at a place with stats cluster access. On Mon, Jun 9, 2014 at 6:33 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:

How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote: > > Juliusz suggested I email out details to mobile-l on the following. > > The question arose during an Opera discussion today whether hiding the > Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia > Zero) on mobile web in the page menubar (not the same as the flyout > "hamburger" menu) might make sense generally for <noscript> or lower JS > devices? The Watchlist star on the page menubar takes up a lot of space, and > as it's the only thing there at the moment (on en.m at least, icons like > Edit and Add Photo aren't shown), hiding that menubar icon would free up > some valuable screen real estate. > > On <noscript> or lower JS devices (or browsers where RL suppresses JS > due typically to challenges around timing of Deferreds and the like), using > the Opera traffic as an example of such a browser, it seems like Watchlist > usage is sort of low (this is at 1% sampling resolution). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'action=watch' | wc -l > 3 > > In other words, it seems users make it to the point of using the > feature, but only about 300 times per day total. Meanwhile, the Watchlist > start takes up valuable screen real estate for every pageview. > > The usage of the feature is about 1/10 of the Opera usage involving > submission of the login form (a prerequisite of watchlist usage). > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l > 31 > > Which is about 1/10 of Opera usage of the login feature in any capacity > (GETting the form or POSTing the form) > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l > 331 > > Which is maybe 1/270 of an oversimplified "pageview" metric on Opera > Mini, using text/html response types as a rough guide. > > $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | > grep 'proxy=Opera' | grep 'text/html' | wc -l > 89403 > > The relatively low usage of the Watchlist feature is probably > symptomatic of the multiscreen flow on such devices. > > -Adam > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l >

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

Adam Baso

7:45 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Looking at all non-JS devices is a bit challenging. That said, Opera proxy market share of pageviews on mobile web is about 5% of mobile web total from what we've seen (X-Analytics of proxy=Opera on text/html responses for certain well-defined "obvious" pageview request paths). Add to Watchlist is the only button on the menubar for such Opera proxy-sourced users, whose experience is about the same as <noscript> or other devices where the RL bootstrapping process bars further JS hooks. Opera proxy-sourced usage of the Add to Watchlist feature is about 0.5% of total non-Opera proxy-sourced access. $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep -v 'proxy=Opera' | grep 'returntoquery=article_action%3Dwatch' | wc -l 527 # note the grep -v for exclusion $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep 'action=watch' | wc -l 3 # note this is inclusive grep No Opera proxy-sourced usage invoked unwatching an article for that particular day from the looks of it. $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep 'proxy=Opera' | grep 'action=unwatch' | wc -l 0 I can't say for sure, but I suspect the trends for watch/unwatch are about the same on the other <noscript> and RL module load JS-barred UAs. I can't remember if that was something that was tracked at the outset, but I wonder if adding EL for the higher-JS Add to Watchlist JSON calls (that is, the ones invoked on tap of the star /post-authentication/) would be useful longer run, as it seems like a kind of interesting metric to gauge interest and regression analysis as items for higher-JS browsers are added/subtracted/reworked on the menubar? I couldn't tell if Add to Watchlist taps on higher-JS was part of http://mobile-reportcard.wmflabs.org/graphs/watchlist-activity or mobile-reportcard.wmflabs.org/graphs/ui-daily; those seem more related to actual Watchlist maintenance and sidebar usage, respectively, instead. Maybe it's somewhere in a wfDebuglog or backend EL table? -Adam On Tue, Jun 10, 2014 at 10:29 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:

...

Thanks for digging into this, Adam. I don't think the prominence of the feature is justified by the usage stats, so I'd be in favor of removing

from Opera/lower JS devices. On Tue, Jun 10, 2014 at 5:45 AM, Adam Baso <abaso(a)wikimedia.org> wrote: > > Good question, will take a look once I'm at a place with stats cluster > access. > > > > On Mon, Jun 9, 2014 at 6:33 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: >> >> How does this compare to usage of users on say Chrome...? >> >> On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote: >>> >>> Juliusz suggested I email out details to mobile-l on the following. >>> >>> The question arose during an Opera discussion today whether hiding the >>> Watchlist icon (which is the case on non-HTTPS supporting UX on

Wikipedia

>>> Zero) on mobile web in the page menubar (not the same as the flyout >>> "hamburger" menu) might make sense generally for <noscript> or lower

>>> devices? The Watchlist star on the page menubar takes up a lot of

space, and

>>> as it's the only thing there at the moment (on en.m at least, icons

>>> Edit and Add Photo aren't shown), hiding that menubar icon would free

>>> some valuable screen real estate. >>> >>> On <noscript> or lower JS devices (or browsers where RL suppresses JS >>> due typically to challenges around timing of Deferreds and the like),

using

>>> the Opera traffic as an example of such a browser, it seems like

Watchlist

>>> usage is sort of low (this is at 1% sampling resolution). >>> >>> $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz

>>> grep 'proxy=Opera' | grep 'action=watch' | wc -l >>> 3 >>> >>> In other words, it seems users make it to the point of using the >>> feature, but only about 300 times per day total. Meanwhile, the

Watchlist

>>> start takes up valuable screen real estate for every pageview. >>> >>> The usage of the feature is about 1/10 of the Opera usage involving >>> submission of the login form (a prerequisite of watchlist usage). >>> >>> $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz

>>> grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l >>> 31 >>> >>> Which is about 1/10 of Opera usage of the login feature in any

capacity

>>> (GETting the form or POSTing the form) >>> >>> $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz

>>> grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l >>> 331 >>> >>> Which is maybe 1/270 of an oversimplified "pageview" metric on Opera >>> Mini, using text/html response types as a rough guide. >>> >>> $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz

> grep 'proxy=Opera' | grep 'text/html' | wc -l > 89403 > > The relatively low usage of the Watchlist feature is probably > symptomatic of the multiscreen flow on such devices. > > -Adam > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l >

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

Adam Baso

8:11 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

...I looked a bit at the UA distribution for action=watch excluding the proxy=Opera rows. Most of that seems to be with higher capability UAs, perhaps from within WebView components or perhaps from non-CTA contexts or perhaps both. Or something. zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep -v 'proxy=Opera' | grep 'action=watch' | cut -f14 | sort | uniq -c 5 Mozilla/5.0 (Android; Mobile; rv:28.0) Gecko/28.0 Firefox/28.0 ...<a list> $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep -v 'proxy=Opera' | grep 'action=watch' | wc -l 153 # note the grep -v -Adam On Tue, Jun 10, 2014 at 10:45 AM, Adam Baso <abaso(a)wikimedia.org> wrote:

...

Thanks for digging into this, Adam. I don't think the prominence of the feature is justified by the usage stats, so I'd be in favor of removing

wrote:

>> >> How does this compare to usage of users on say Chrome...? >> >> On 9 Jun 2014 18:02, "Adam Baso" <abaso(a)wikimedia.org> wrote: >>> >>> Juliusz suggested I email out details to mobile-l on the following. >>> >>> The question arose during an Opera discussion today whether hiding

the

>>> Watchlist icon (which is the case on non-HTTPS supporting UX on

Wikipedia

>>> Zero) on mobile web in the page menubar (not the same as the flyout >>> "hamburger" menu) might make sense generally for <noscript> or lower

>>> devices? The Watchlist star on the page menubar takes up a lot of

space, and

>>> as it's the only thing there at the moment (on en.m at least, icons

>>> Edit and Add Photo aren't shown), hiding that menubar icon would

free up

>>> some valuable screen real estate. >>> >>> On <noscript> or lower JS devices (or browsers where RL suppresses JS >>> due typically to challenges around timing of Deferreds and the

like), using

>>> the Opera traffic as an example of such a browser, it seems like

Watchlist

>>> usage is sort of low (this is at 1% sampling resolution). >>> >>> $ zcat

/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |

>>> grep 'proxy=Opera' | grep 'action=watch' | wc -l >>> 3 >>> >>> In other words, it seems users make it to the point of using the >>> feature, but only about 300 times per day total. Meanwhile, the

Watchlist

/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |

>>> grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc

-l

>>> 31 >>> >>> Which is about 1/10 of Opera usage of the login feature in any

capacity

>>> (GETting the form or POSTing the form) >>> >>> $ zcat

/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |

>> grep 'proxy=Opera' | grep 'text/html' | wc -l >> 89403 >> >> The relatively low usage of the Watchlist feature is probably >> symptomatic of the multiscreen flow on such devices. >> >> -Adam >> >> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

Juliusz Gonera

8:25 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Adam Baso wrote:

...

$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz | grep -v 'proxy=Opera' | grep 'returntoquery=article_action%3Dwatch' | wc -l 527 # note the grep -v for exclusion

Why are we grepping for 'returntoquery=article_action%3Dwatch' instead of 'action=watch' here? -- Juliusz

Adam Baso

8:38 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

...

Why are we grepping for 'returntoquery=article_action%3Dwatch' instead of 'action=watch' here?

I was trying to not overcount. On higher-JS devices, it seems to be the simplest way to capture the following: 1. Not being logged in while reading an article (e.g., http://en.m.wikipedia.org/wiki/2008_Seattle_Mariners_season) 2. Tapping on the Add to Watchlist star and being toasted to Log in. 3. The browser POSTing to login and be returned to the article with the article being auto-starred ( https://en.m.wikipedia.org/w/index.php?title=Special:UserLogin&action=s… If you're suggesting that action=watch is common even in higher-JS execution contexts, that may explain why so many apparently higher-JS UAs were also hitting action=watch bearing URLs (as opposed to sandboxed WebViews or something like that, although those certainly constitute some portion of such hits). -Adam

Jon Robson

8:57 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

It would also be worth considering what this would mean if the mobile skin ever became a desktop skin. What does usage of the non-JavaScript watch feature on desktop look like? Also what about super slow connections - are we going to prevent watching there until they have loaded all the JavaScript - it's always good to have fallbacks. In terms of article_action%3Dwatch VS action=watch - you actually want both. In case one it only catches the case when an anon clicks the watch star and then logs in/creates an account and then watches the article. Note this applies to both non-JavaScript and JavaScript users.. action=watch applies to people who are already logged in with slow connections / JS disabled; action=unwatch applies to people who are logged in and unwatch an article with slow connections / JS disabled. I'm still not seeing the real benefit here - if it's just about screen real estate, why don't we just fix the design for this case?

Adam Baso

9:14 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Interesting. What do people think about a compromise as follows? Again, this is not speaking to the Wikipedia Zero case specifically, but rather to the broader mobile web audience... <noscript> / low-JS device: put "Add to Watchlist" labeled button at the bottom of the article. High end JS device, possibly on slow connection: keep star at top of page with menubar (and use JS to suppress "Add to Watchlist" labeled button at the bottom of the article). -Adam -Adam On Tue, Jun 10, 2014 at 11:57 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:

...

Juliusz Gonera

8:31 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Jon Robson wrote:

...

I would remove page actions for non-JS users if watchstar proves to be hardly ever used. Also, Gautam from Opera showed us some stats and devices with really low screen sizes (less than 300 or even 200px width) prevail among Opera Mini users (and that's our most popular non-JS browser). I'm not sure how you want to display Flow on old devices that have less than 200px in width. Things just won't fit. -- Juliusz

Federico Leva (Nemo)

9:37 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Juliusz Gonera, 10/06/2014 20:31:

...

I would remove page actions for non-JS users if watchstar proves to be hardly ever used.

Personally I'm quite disturbed by the idea of further reducing discoverability of editing/non-passive usage. I don't know about the specific case, but remember not to trade the (visibility of the) *essence* of the wiki for a few pixels saved. Nemo

Juliusz Gonera

9:43 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Federico Leva (Nemo) wrote:

...

Juliusz Gonera, 10/06/2014 20:31:

I would remove page actions for non-JS users if watchstar proves to be hardly ever used.

Adam Baso

11:46 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

I believe Gautam over at Opera may have some viewport stats he can share with the list. He'll be emailing that pretty soon I think. I feel a compromise with a labeled "Add to Watchlist" button at the bottom of the article on low-JS devices (freeing up the menubar at the top), but keeping the star at the top on higher-JS devices (and hiding the "Add to Watchlist" button at the bottom), is one way to strike a balance between discoverability and usability in light of what seems to be pretty low practical usage of the feature on the low-JS devices. -Adam On Tue, Jun 10, 2014 at 12:43 PM, Juliusz Gonera <jgonera(a)wikimedia.org> wrote:

...

Federico Leva (Nemo) wrote:

Juliusz Gonera, 10/06/2014 20:31:

I would remove page actions for non-JS users if watchstar proves to be hardly ever used.

I understand this argument, however, on small feature phones with Opera Mini, the initial page view consists only of page header and a watchstar button. None of the article content fits without scrolling. -- Juliusz _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Gautam Chandna

11 Jun 11 Jun

12:08 a.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

...

I believe Gautam over at Opera may have some viewport stats he can share with the list. He'll be emailing that pretty soon I think.

I've just joined this mailing list, and have gone through this thread. I've got some data and screenshots that are relevant for this discussion: h3. Screen size for Opera Mini clients (sample data, 1 day): upto 400x320 50% 401x321 upto 470x320 3% 471x321 to 640x480 24% 641x481 to 960x720 17% 961x721 and above 7% I'm running this stat with lower screen sizes, for users using Wikipedia and will report here once I have new data. h3. Screenshots: Size 180 x 240, Size 240 x 320 https://drive.google.com/folderview?id=0B-yck2WBt5TwekdHa0kxN0psRk0&usp… This is what I presented yesterday at Wikimedia, to emphasize that there is a problem. Of course, you decide how to tackle it. Best regards, Gautam

...

I feel a compromise with a labeled "Add to Watchlist" button at the bottom of the article on low-JS devices (freeing up the menubar at the top), but keeping the star at the top on higher-JS devices (and hiding the "Add to Watchlist" button at the bottom), is one way to strike a balance between discoverability and usability in light of what seems to be pretty low practical usage of the feature on the low-JS devices. -Adam On Tue, Jun 10, 2014 at 12:43 PM, Juliusz Gonera <jgonera(a)wikimedia.org> wrote:

Federico Leva (Nemo) wrote:

Juliusz Gonera, 10/06/2014 20:31:

I would remove page actions for non-JS users if watchstar proves to be hardly ever used.

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Gautam Chandna | Director - Technical Partner Management | gautamc(a)opera.com | +47-4567-1789

Jon Robson

8:09 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Hey Gautam thanks for sharing. So as I understand it really the issue here is not actually an Opera issue but a resolution issue There's a couple of issues here 1) The main page is a static page provided by the community - https://meta.wikimedia.org/wiki/Www.wikimedia.org_template Feel free to start a talk page comment about improving this for tiny screens. This sadly is out of my control. 2) On all pages the content is mostly hidden because of the search, watch star and menu icon. This is not helped by the fact Opera has browser chrome on the top and bottom of the page - out of interest Gautam, in the case of the device which is 320 by 240, what the browser reports the width and the height of the window is (if we were to use media queries and responsive design to adapt that). I actually think what would be the best solution here is to hide all the Wikipedia chrome for screens, and replace it with links to Home (and in future Search) at the top. I've knocked up a patch that does this - https://gerrit.wikimedia.org/r/138867 and would be interested in your views. On Tue, Jun 10, 2014 at 3:08 PM, Gautam Chandna <gautamc(a)opera.com> wrote:

...

On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

I believe Gautam over at Opera may have some viewport stats he can share with the list. He'll be emailing that pretty soon I think.

Federico Leva (Nemo) wrote:

Juliusz Gonera, 10/06/2014 20:31: > > I would remove page actions for non-JS users if watchstar proves to be > hardly ever used. Personally I'm quite disturbed by the idea of further reducing discoverability of editing/non-passive usage. I don't know about the specific case, but remember not to trade the (visibility of the) *essence* of the wiki for a few pixels saved.

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Gautam Chandna | Director - Technical Partner Management | gautamc(a)opera.com | +47-4567-1789 _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

Adam Baso

10:08 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

...

I actually think what would be the best solution here is to hide all the Wikipedia chrome for screens, and replace it with links to Home (and in future Search) at the top. I've knocked up a patch that does this - https://gerrit.wikimedia.org/r/138867 and would be interested in your views.

Here's roughly what the browsing experience would look like with Jon's patch, presuming media query support for max-width: https://docs.google.com/file/d/0BxJX28FKLm78dDNPN29naGlPSEk/edit?pli=1 It's unclear if removal of /all/ of the chrome is optimal. Although there's a need for some slight improvement in the UX of the searchbar for users on Opera (and other <noscript> or RL JS-restricted UAs) today, taking away the search box at the top of the page would get rid of perhaps 136,000 searches per day on Opera sourced searches from from article display (contrast this with 100-300 successful Add to Watchlist actions per day on Opera). $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep '/w/index.php?search=' | cut -f12 | grep -c '/wiki/' 1362 $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep -c 'action=watch' 1 -Adam

Gautam Chandna

12 Jun 12 Jun

9:06 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

...

I actually think what would be the best solution here is to hide all

the Wikipedia chrome for screens, and replace it with links to Home (and in future Search) at the top. I've knocked up a patch that does this - https://gerrit.wikimedia.org/r/138867 and would be interested in your views.

Here's roughly what the browsing experience would look like with Jon's patch, presuming media query support for max-width: https://docs.google.com/file/d/0BxJX28FKLm78dDNPN29naGlPSEk/edit?pli=1

Opera Mini supports max-width and max-device-width If you'd like to test this on Opera Mini, I've added a java emulator with mini4 and mini8 jad/jar files here: https://drive.google.com/folderview?id=0B-yck2WBt5TwekdHa0kxN0psRk0&usp… Instructions are simple: - Have Java - Double-click/run the microemulator.jar file - [optional] Options->Select device->Resizable device->Resize - File->Open->mini4.jad or mini8.jad

...

It's unclear if removal of /all/ of the chrome is optimal. Although there's a need for some slight improvement in the UX of the searchbar for users on Opera (and other <noscript> or RL JS-restricted UAs) today, taking away the search box at the top of the page would get rid of perhaps 136,000 searches per day on Opera sourced searches from from article display (contrast this with 100-300 successful Add to Watchlist actions per day on Opera). $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep '/w/index.php?search=' | cut -f12 | grep -c '/wiki/' 1362

Search is usually a big deal on mobile phones/Opera. So it probably helps to keep that bar, just with some background image or CSS borders. Opera Mini has pretty good support for CSS. I recommend taking a look at m.facebook.com on Opera Mini 4 and 8, to see how they're dealing with our rendering. (Not that their UI applies to wikimedia, but that their heavy use of CSS shows what's possible.)

...

$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep -c 'action=watch' 1 -Adam

-- Gautam Chandna | Director - Technical Partner Management | gautamc(a)opera.com | +47-4567-1789

Jon Robson

13 Jun 13 Jun

1:42 a.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

Yeh, I envisioned search might be a link at the top, but we can iterate on that. A lot of our traffic is from search results, so I think the more important function is reading, but we definitely should provide a search function. I think any phone which has a screen res of around 240px but media query support is doomed - maybe some old Nokia phones. Support of modern devices is pretty good across the board http://caniuse.com/css-mediaqueries On Thu, Jun 12, 2014 at 12:06 PM, Gautam Chandna <gautamc(a)opera.com> wrote:

...

On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

Here's roughly what the browsing experience would look like with Jon's patch, presuming media query support for max-width: https://docs.google.com/file/d/0BxJX28FKLm78dDNPN29naGlPSEk/edit?pli=1

$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep -c 'action=watch' 1 -Adam

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

Adam Baso

1 Jul 1 Jul

6:03 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

For the edification of the list, here's the latest update: from the sounds of it yesterday on #wikimedia-mobile on Freenode, in an upcoming sprint the low resolution devices will have the menubar and last-edited stuff at the top suppressed, with the last-edited bar being presented lower in the page (the bottom?). I think in practice those low resolution devices will tend to have no or ResourceLoader-impaired JavaScript support, so does it make sense to only activate the menubar at the top when there's JavaScript support /and/ the screen size is sufficient? Maybe that was the plan already. During the mobile web standup yesterday I mentioned I was doing a little patch for proof of concept on moving the page menubar (most notably on no-/RL-impaired devices, the Watchlist star feature) down below the lead section (or after the first section if no lead section), but the general mobile web team was already planning to do a number of enhancements for small screens, so it looks like I don't need to keep working on that proof of concept code. -Adam On Thu, Jun 12, 2014 at 4:42 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:

...

On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

Here's roughly what the browsing experience would look like with Jon's patch, presuming media query support for max-width: https://docs.google.com/file/d/0BxJX28FKLm78dDNPN29naGlPSEk/edit?pli=1

Opera Mini supports max-width and max-device-width If you'd like to test this on Opera Mini, I've added a java emulator with mini4 and mini8 jad/jar files here:

https://drive.google.com/folderview?id=0B-yck2WBt5TwekdHa0kxN0psRk0&usp…

Instructions are simple: - Have Java - Double-click/run the microemulator.jar file - [optional] Options->Select device->Resizable device->Resize - File->Open->mini4.jad or mini8.jad > > > It's unclear if removal of /all/ of the chrome is optimal. Although > there's a need for some slight improvement in the UX of the searchbar

for

> users on Opera (and other <noscript> or RL JS-restricted UAs) today,

taking

> away the search box at the top of the page would get rid of perhaps

136,000

> searches per day on Opera sourced searches from from article display > (contrast this with 100-300 successful Add to Watchlist actions per day

Opera). $ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep '/w/index.php?search=' | cut -f12 | grep -c '/wiki/' 1362

Search is usually a big deal on mobile phones/Opera. So it probably

helps to

keep that bar, just with some background image or CSS borders. Opera Mini has pretty good support for CSS. I recommend taking a look at

m.facebook.com

on Opera Mini 4 and 8, to see how they're dealing with our rendering.

(Not

that their UI applies to wikimedia, but that their heavy use of CSS shows what's possible.)

$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140611.gz | grep 'proxy=Opera' | grep -c 'action=watch' 1 -Adam

-- Gautam Chandna | Director - Technical Partner Management |

gautamc(a)opera.com

| +47-4567-1789 _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Gautam Chandna

12 Jun 12 Jun

8:45 p.m.

New subject: Removing the Watchlist icon on Opera / Lower JS Devices?

On Wed, Jun 11, 2014 at 11:09 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:

...

Hey Gautam thanks for sharing.

Hey! Not a problem at all.

...

So as I understand it really the issue here is not actually an Opera issue but a resolution issue

True, and an extension of the problem is that devices in the smaller screen size ranges don't have browsers that support media-queries. Adding media queries will help Opera, but may not help others. I think the decision to "support devices with small screens" has to be made by people measuring usage-per-browser, features-per-browser and market-expectancy-per-browser at Wikimedia. Once that decision is made, this one becomes easier.

...

There's a couple of issues here 1) The main page is a static page provided by the community - https://meta.wikimedia.org/wiki/Www.wikimedia.org_template Feel free to start a talk page comment about improving this for tiny screens. This sadly is out of my control.

Understood

...

2) On all pages the content is mostly hidden because of the search, watch star and menu icon. This is not helped by the fact Opera has browser chrome on the top and bottom of the page - out of interest Gautam, in the case of the device which is 320 by 240, what the browser reports the width and the height of the window is (if we were to use media queries and responsive design to adapt that).

You can use the media query max-device-width or max-width Though in Opera's case, the screen width (240px) is the same the device width (240px). There is no chrome on the sides. The height changes from 320px to 234px because of Opera's chrome, though users can choose to go fullscreen. There is another Opera Mini client for smaller screen sizes which has a thinner chrome. J2ME Low-end: Mini version 4.5 (thin chrome) J2ME High-end: Mini version 8.0 (thick chrome) Android: Mini version 7.5 iOS: Mini version 7.1

...

(will follow up on Adams reply on this)

...

On Tue, Jun 10, 2014 at 3:08 PM, Gautam Chandna <gautamc(a)opera.com> wrote:

On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso <abaso(a)wikimedia.org> wrote:

I believe Gautam over at Opera may have some viewport stats he can share with the list. He'll be emailing that pretty soon I think.

I've just joined this mailing list, and have gone through this thread.

I've

got some data and screenshots that are relevant for this discussion: h3. Screen size for Opera Mini clients (sample data, 1 day): upto 400x320 50% 401x321 upto 470x320 3% 471x321 to 640x480 24% 641x481 to 960x720 17% 961x721 and above 7% I'm running this stat with lower screen sizes, for users using Wikipedia

and

will report here once I have new data. h3. Screenshots: Size 180 x 240, Size 240 x 320

https://drive.google.com/folderview?id=0B-yck2WBt5TwekdHa0kxN0psRk0&usp…

This is what I presented yesterday at Wikimedia, to emphasize that there

a problem. Of course, you decide how to tackle it. Best regards, Gautam > > > I feel a compromise with a labeled "Add to Watchlist" button at the

bottom

> of the article on low-JS devices (freeing up the menubar at the top),

but

keeping the star at the top on higher-JS devices (and hiding the "Add to Watchlist" button at the bottom), is one way to strike a balance between discoverability and usability in light of what seems to be pretty low practical usage of the feature on the low-JS devices. -Adam On Tue, Jun 10, 2014 at 12:43 PM, Juliusz Gonera <jgonera(a)wikimedia.org

> wrote: >> >> Federico Leva (Nemo) wrote: >>> >>> Juliusz Gonera, 10/06/2014 20:31: >>>> >>>> I would remove page actions for non-JS users if watchstar proves to

>>>> hardly ever used. >>> >>> >>> Personally I'm quite disturbed by the idea of further reducing >>> discoverability of editing/non-passive usage. I don't know about the >>> specific case, but remember not to trade the (visibility of the)

*essence*

>>> of the wiki for a few pixels saved. >> >> >> I understand this argument, however, on small feature phones with Opera >> Mini, the initial page view consists only of page header and a

watchstar

button. None of the article content fits without scrolling. -- Juliusz _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

_______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Gautam Chandna | Director - Technical Partner Management |

gautamc(a)opera.com

| +47-4567-1789 _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

-- Gautam Chandna | Director - Technical Partner Management | gautamc(a)opera.com | +47-4567-1789

3599

days inactive

3620

days old

mobile-l@lists.wikimedia.org

Manage subscription

21 comments

6 participants

tags (0)

participants (6)

Adam Baso
Federico Leva (Nemo)
Gautam Chandna
Jon Robson
Juliusz Gonera
Maryana Pinchuk