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:
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:
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
_______________________________________________
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