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