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
How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" abaso@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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@gmail.com wrote:
How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" abaso@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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@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@gmail.com wrote:
How does this compare to usage of users on say Chrome...? On 9 Jun 2014 18:02, "Adam Baso" abaso@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@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
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@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 it from Opera/lower JS devices.
On Tue, Jun 10, 2014 at 5:45 AM, Adam Baso abaso@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@gmail.com wrote:
How does this compare to usage of users on say Chrome...?
On 9 Jun 2014 18:02, "Adam Baso" abaso@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@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
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
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@gmail.com wrote:
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@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
it
from Opera/lower JS devices.
On Tue, Jun 10, 2014 at 5:45 AM, Adam Baso abaso@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@gmail.com wrote:
How does this compare to usage of users on say Chrome...?
On 9 Jun 2014 18:02, "Adam Baso" abaso@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@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
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
-- Jon Robson
...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@wikimedia.org> wrote:
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@gmail.com> wrote:
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@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
it
from Opera/lower JS devices.
On Tue, Jun 10, 2014 at 5:45 AM, Adam Baso <abaso@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@gmail.com>
wrote:
How does this compare to usage of users on say Chrome...?
On 9 Jun 2014 18:02, "Adam Baso" <abaso@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@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
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
-- Jon Robson
- http://jonrobson.me.uk
- https://www.facebook.com/jonrobson
- @rakugojon
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?
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=su...
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
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?
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@gmail.com wrote:
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?
Jon Robson wrote:
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).
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 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
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.
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.
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@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.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso abaso@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@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.
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@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
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@opera.com wrote:
On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso abaso@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@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.
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@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
-- Gautam Chandna | Director - Technical Partner Management | gautamc@opera.com | +47-4567-1789
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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
On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso abaso@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
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@opera.com wrote:
On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso abaso@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@opera.com | +47-4567-1789
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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@gmail.com wrote:
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@opera.com wrote:
On Wed, Jun 11, 2014 at 1:08 PM, Adam Baso abaso@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@opera.com
| +47-4567-1789
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Wed, Jun 11, 2014 at 11:09 AM, Jon Robson jdlrobson@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
- 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
- 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
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.
(will follow up on Adams reply on this)
On Tue, Jun 10, 2014 at 3:08 PM, Gautam Chandna gautamc@opera.com wrote:
On Tue, Jun 10, 2014 at 2:46 PM, Adam Baso abaso@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@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.
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@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
-- Gautam Chandna | Director - Technical Partner Management |
gautamc@opera.com
| +47-4567-1789
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson