Did a quick mockup of a floating/togglable table of contents for the mobile
view:
http://svn.wikimedia.org/svnroot/mediawiki/trunk/mockups/mobile-sections/in…
* sets up section 0 as a togglable section as well
* on narrow screens, ToC shows fullscreen, triggered by a floating fixed
button in the corner, so it's always available
* on wider screens (such as tablets), ToC shows as a fixed sidebar
This is a fairly primitive quicky mockup and requires position:fixed to
work ('for reals' would need some smarts for some platforms to scroll
things around) and makes no attempt for things to be formatted nicely. ;)
Clicking a section in the toc bar also does a toggle rather than
unconditional _show_, so sometimes hides things instead. ;)
Seems to work in iOS 5 (iPod Touch and iPad) and Android 2.3 (Nexus 1 stock
browser), as well as on desktop Firefox.
Any thoughts? I kinda like the notion of having navigation controls always
accessible; perhaps tweak things with a nicer section list and displaying
only one section at a time by default.
(A lot of portal-style pages also interact poorly with our mobile section
collapse/expand right now, so that might need some adjustment as well...)
-- brion
I went ahead and did a quick mockup for some modified JavaScript and CSS
for image pages. Here's a live demo:
http://toolserver.org/~brion/mockups/mobile-imagepage/
This is using the current existing File: page markup and modifying it with
CSS and JavaScript:
* the extra data sections are hidden by default except for the image, so
they don't get in the way
* link bar at top is reformatted and links are used to show/hide each
section instead of jumping around
* the image itself is sized down to fit the screen, but using the same
medium-resolution version that we started with
I also changed the viewport settings to allow zooming in, which we've been
thinking about doing anyway.
Result is:
* by default there's less clutter on screen
* by default the image fits
* auto-scales to fit when changing orientation
* on high-resolution screens (iOS with Retina display, Android with 240dpi
or 320dpi display) the picture appears much sharper
* can zoom in for more detail with standard pinch-to-zoom
Confirmed that it works in at least iOS 5 Safari and Android 2.3.6 Browser,
haven't tested all other things.
Checked in with Phil & Patrick -- we think this is a good direction to
start with and should be easy to include in MobileFrontend extension (it's
a conservative change that doesn't alter any HTML of the page itself, and
just adds some CSS/JS that will be easy to keep and port in future).
Any comments, ideas? For instance the initial view could be made more
'image viewer'-y by centering things, removing some extra links or
reformatting them, etc
-- brion
I'm having some positive results in preliminary tests simply switching the
cache mode on the WebView.
Getting rid of the urlcache bits which we've had problems with, and adding
this into WikipediaActivity.java.onCreate():
this.appView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);
lets me go back to previously-visited pages without complaint after
switching on airplane mode -- and very quickly!
However, any loading that *fails* (such as a page that hasn't been cached)
triggers an application-fatal error, as far as I can tell because DroidGap
assumes that iframes don't exist and the only thing that might fail to load
is the entire application. :P This may just have to be hacked around by
modifying the phonegap infrastructure. :P
Some potential issues with this approach:
* not sure if/how to control the amount of space used for caching
* (though you should be able to clear it manually from the standard Manage
Applications panel on the phone)
* presumably we should load from network first if we're online, so would
need to swap this mode dynamically or else find a better behavior
* not sure if any way to tell what's in cache ahead of time
* of course since it's platform-dependent, similar behavior would need to
be tweaked on other platforms
A couple other possibilities include:
1) Making an "HTTP caching proxy"-like layer that we slide under the
ability to override how requests are made.
Again, this would be platform-specific and may need to be reimplemented in
the backend for other platforms. Advantage: makes our JS-side code super
easy as it would just try to load things and they'd show up. We can control
the return results, so errors wouldn't have to trigger the fatal code as
above.
2) Do platform-independent 'caching' by slurping the contents of pages
within JavaScript after loading, and managing the re-loading from cache
ourselves when offline
* Still needs the android fix for not dying when a connection fails. :P
* may not be able to handle images this way
* could explode with JS stuff :)
-- brion
Niklas has landed the first commit of localization data from
TranslateWiki.net into the repository. The app now picks up the language in
Android's locale and shows localized menus in most of the UI:
https://upload.wikimedia.org/wikipedia/mediawiki/b/b7/Mobile_menu_en_franca…
It _should_ also default to the selected language for content on first
launch.
There are a couple bugs yet:
* Changing locales while the app is running doesn't take effect <
https://bugzilla.wikimedia.org/show_bug.cgi?id=32897>
* Chinese locales don't work <
https://bugzilla.wikimedia.org/show_bug.cgi?id=32898>
We also have localizations for a number of languages that aren't
necessarily in a default Android device's set of languages, such as Hebrew
and various Indic languages. These *should* work on Android devices that
have been customized with locales for those languages, but we'd appreciate
testing!
-- brion
On Thu, Dec 8, 2011 at 4:55 PM, Erik Zachte <ezachte(a)wikimedia.org> wrote:
> Asher, "The uncertainty here should be much less than that hanging over
> all of the stats due to the large but variable random logging packet loss
> for all wmf traffic that occurred during parts of these months"****
>
> This is actually not the case. We also know exact message loss per squid
> per hour, inferred from gaps in sequence numbers. ****
>
> So some weeks ago we did patch each hourly file based on weighed average
> for that hour of losses over all squids. ****
>
That's great, kudos for that level of attention to detail.
While in Mumbai last month I stumbled onto a feature for our desktop site
that I think would be killer for mobile.
Its the map overlay that we use on English Wikipedia. Where is it? .. well
.. unless your determined then your likely not to find it as its not
identified very well. To find it
1) Load http://en.wikipedia.org/wiki/Mumbai
2) Wait for about five seconds for it to load (you'd never know)
3) Scroll down to the middle of the info box to the "Coordinates" section
4) Click on the "Globe" icon (the globe .. no the gps coordinates)
You'll be greeted by a really cool map overlay that shows you articles that
are near the one that your browsing. You can hover over an icon for a text
page preview, click to see the article, and scroll the map to see more
pages. I think this is a great start but we can do much better.
And were not the only ones that have thought about this. The German
Wikipedia has another really interesting implementation.
1) Load http://de.wikipedia.org/wiki/Mumbai
2) Scroll to "Koordinaten"
3) Click "Karte"
This implementation uses open street maps and has some nice user filters
and options.
Now some people might ask. Isn't this the same thing as near by me? Not
exactly. The near by me is really meant as its name implies to be a tool
that travels with you as you navigate through space. This tool instead
allows you to navigate Wikipedia visually rather then textually regardless
of where you are. I think both tools could play off of each other very well.
This would be a really powerful way of browsing Wikipedia that would be
perfect for touch based devices. With tablets we could add more filters and
sub selections options as screen real estate allows. And it would be far
move relevant then showing them GeoHack (http://bit.ly/shxI7Y) [1] when
they touched a GPS link on a mobile wikipedia page. Think about how we
could navigate Wikipedia by just taping each point. Icons for different
categories. Colors for articles needing images or general improvement. And
so much more.
We know that typing is tough on phones. Lets make it even easier to
interact with Wikipedia by making it a touch based activity.
I'm eager to rally some folks from the open street maps community and WMF
to tackle this during the SF Hackathon (http://bit.ly/u5EXjM).
Who's in?
[1] https://wiki.toolserver.org/view/GeoHack
--tomasz
On Tue, Dec 6, 2011 at 2:58 PM, Erik Zachte <ezachte(a)wikimedia.org> wrote:
> Asher, ****
>
> ** **
>
> I quote Tomasz,****
>
> ** **
>
> " October is likely under reported by up to 25% while November is under
> reported by up to 50%."
>
****
>
> ** **
>
> 'Likely' and 'up to' don’t sound like high level of confidence. ****
>
> Apparently you have better figures?
>
For October, cp1043 stopped logging on 10/15 at 23:24:23, so it wasn't
counted for a tad >50% of the month.
For November, cp1043 was logging for 35 hours, or was missing around 95% of
the month.
> This will be the first time ever we adjust figures manually in wikistats.
>
> It is a line we can only cross once. So at least I'd like to be as careful
> as possible.****
>
> ** **
>
> You know when the server died. Only day number or exact time?****
>
> Are you positively sure that both servers had equal load?
>
Yes, they are load balanced with unweighted rr, show the same network
traffic levels in ganglia, and in sampled-1000.log-20111204.gz, one was
logged 39771 and the other 39747 times, within 99.9% of each other, at 0.1%
sampling.
The uncertainty here should be much less than that hanging over all of the
stats due to the large but variable random logging packet loss for all wmf
traffic that occurred during parts of these months.
For those of you eager to know whats coming next in the beta .. we've
created a simple status page to keep track of everything thats moving in
and out of the beta
http://meta.wikimedia.org/wiki/Mobile_Projects/beta
Let us know how it works.
--tomasz
I wanted to alert us to an alarming trend in our overall mobile page stats
http://stats.wikimedia.org/EN/TablesPageViewsMonthlyMobile.htm
We've been trending down over the last couple of months. This is not good.
We need these stats to be growing not dropping. If any of us see any reason
about why this may be happening then we need to speak up. I did some
digging and found out that we may have another logging issue.
Asher from our ops team informed me that
*binasher <member:binasher>: *bad… i need to do something like make puppet
monitor and ensure that our customized varnish logging daemon is always
running
*binasher <member:binasher>: *it died on one of the varnish servers, but
not the other
Which would account for the massive dips we are seeing. We can confirm that
the logger died on 10/15 and that we've been under reporting for October
and November. October is likely under reported by up to 25% while November
is under reported by up to 50%.
Now i'm happy that we have a simple operations related reason for this dip
but we should have caught it sooner. With the foundations goal of 2 billion
page views by July we have to stay on top of this.
--tomasz
I'm really happy to announce that full screen search is out in out beta:
http://blog.wikimedia.org/2011/12/02/mobile-full-screen-search/
This is a really exciting change for our community as its the first
significant design change that we've made to the mobile site.
Many thanks go to Patrick and the rest of the tech team for getting this
out.
If your on this list and not in the beta then head over to
http://bit.ly/wmoptin and then tap on search to see our changes.
--tomasz
