The reduced quality images is now live in production. To see it for
yourself, compare original
with low quality
(253KB => 99.9KB, 60% reduction).
The quality reduction is triggered by adding "qlow-" in front of the file
name's pixel size.
Continuing our previous discussion, now we need to figure out how to best
use this feature. As covered before, there are two main approaches:
network/device/user preference conditions. Issues may include multiple
downloads of the same image (if the browser starts the download before JS
runs), parser cache fragmentation.
* Varnish-based rewrite - varnish decides which image to server under the
same URL. This approach requires Varnish to know everything needed to make
Zero plans to go the first route, but if we make it mobile, or ever site
wide, all the better.
We did another round of guerrilla testing for VE on mobile today. Overall
it was much improved from the last tests!
Especially these changes: X icon to back icon, arrow icon to word "next",
save page updates, and the switch between edit modes.
Here are those findings:
- Used back button and it did what they expected
- Hesitated when asked to save but all were able to find "Next" button
- Filled out the save screen appropriately, although 1 person said it
looked like an error screen at first
- When asked to switch to wikitext, tapped gear icon almost immediately,
but several people still struggled with "edit" and "edit source" language.
Everyone also struggled with the pop-up asking them to save before
But the link and reference context bars really failed the user tests.
:( Most did not notice that the icon in the toolbar was highlighted. Nobody
even noticed the context bars, and didn't know what they meant when I
pointed to them.
I would suggest we try adding blue links that say "edit link" and "edit
citation" in those context bars, to show a user what they'll be doing
specifically. The taller height will also make the bar more noticeable.
Then we can test again!
I talked to Dan Duvall today and he said that many mobile browser
tests fail on default vagrant instance because other extensions that
are not hard dependencies of MF are not activated by default when
activating the mobilefrontend role (extensions such as Echo, GeoData,
VisualEditor). There are two things we can do:
1. Make other extensions that mobile uses dependencies of
mobilefrontend role in vagrant
2. Create a separate role, e.g. mobilefrontend-browsertests, that will
list mobilefrontend and all those extensions as its dependencies
I was wondering if there is anyone who uses vagrant and would like to
have MF enabled, but not all the other extensions. If not, 1. seems
like a simpler solution.
Adam: Whilst we standardise on template languages we need to
distinguish between the types of template languages that currently
exist in the MediaWiki world e.g. handlebars and hogan
https://gerrit.wikimedia.org/r/149360 is in the code review queue and
basically makes it mandatory to include a template language file
extension (previously it would default to hogan when none was
Basically you have to rename all your template files from having a
.html extension to .hogan and update the ResourceLoader resource
Mobile has already done this as have Flow.
I think Zero is the only other extension that uses them and I'm keen
not to break it.
Next steps would be to get Gabriel's knockoff template language
integrated into the Mantle extension and allow extensions to give it a
That then gives us a clear path to migrating this to core once we've
decided on a standard template language.
I have some requests.
* Full text search functionality
* Compatibility with Signpost front page template
* Support interwiki linking such as to Meta
* Condense the options panels from the left and right hamburger icons to a
* More emphasis on encouraging people to edit
* VisualEditor fuctionality
Now that we have new shiny native apps and at the same time we're about to
deprecate dynamic page views, it might be a good time to think for a while
about the API module that powers it, action=mobileview.
Having been written using assumptions about workflow that didn't come true,
it has accumulated some cruft and technical debt. I therefore propose to
form a long-term vision. I'd like to hear your thoughts on how it can be
changed, can its interface be simplified (e.g. ), how fast do we want it
to perform, what do we expect from Parsoid migration.
Max Semenik ([[User:MaxSem]])
Hi, I'm running into an opera mini strangeness. I have a <script src="...">
tag inside <body>, which is suppose to return document.write("some HTML");
This works fine except on opera mini, which does not seem to even call the
server, because I looked at server:source and saw the unsubstituted
<script> tag. Any suggestions?
The Wikimedia Research Hackathon on August 6 and 7 takes place parallel to
the general Wikimania Hackathon in London.
Wikimania Hackathon information is available at
Research Hackathon information is available at
>From the Research Hackathon info page: this "is an opportunity for anyone
interested in research on wikis, Wikipedia, and other open collaborations
to meet, share ideas, and work together. It's being organized by
researchers in academia and the Wikimedia Foundation, but we want anyone
interested in research to participate. Whether or not you consider yourself
a researcher, or would ever want to be one, come with questions, answers,
data, code, crazy ideas... or just your insatiable curiosity."
Local participation will occur at Wikimania London and in Philadelphia, PA,
US. Remote participation is possible and will include researchers and
community members globally.
Please see the Research Hackathon information page for scheduling and
Further questions may be directed to Aaron Halfaker (ahalfaker(a)wikimedia.org)
or Leila Zia (leila(a)wikimedia.org).*
*A $1 fine will be imposed by Oliver Keyes on anyone who misspells Leila's
name or misdirects emails to the WMF Executive Director.
While we're talking about technology issues on WIkimedia-l, I'd like to say
that now that I've worked my way over a few speedbumps with mobile editing
I'm happy with the direction that mobile editing is going, so thank you