Hello,
The 1.23 release of MediaWiki deprecates
the ResourceLoaderGetStartupModules hook which TimedMediaHandler /
MwEmbedSupport depend on. See <
https://bugzilla.wikimedia.org/show_bug.cgi?id=63240> for details.
I'd like to accelerate the complete removal of this hook. It was created as
a special kludge for MwEmbedSupport, with the expectation that it would be
used only on pages which require the extension, and only until
MwEmbedSupport could be refactored to be in-line with other MediaWiki
extensions. Instead, MwEmbedSupport uses it to load five modules on every
single page: 'jquery.triggerQueueCallback', 'Spinner',
'jquery.loadingSpinner', 'jquery.mwEmbedUtil', and 'mw.MwEmbedSupport'. (A
sixth module, 'mw.MwEmbedSupport.style', is also added to every page, but
by different means.)
This has been the status quo for just under three years, now:
commit dc5c9fe9efa, which added "TODO look into loading this on-demand
instead of all pages", was merged in June 2011.
Could the multimedia team please make this a priority? I'd recommend using
the opportunity to fold MwEmbedSupport support into TimedMediaHandler.
MwEmbedSupport passes itself as a generic module-loading framework, but
three years in, TimedMediaHandler remains its single application.
The relevant bugs are:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55550https://bugzilla.wikimedia.org/show_bug.cgi?id=58086https://bugzilla.wikimedia.org/show_bug.cgi?id=42928https://bugzilla.wikimedia.org/show_bug.cgi?id=58082
I can't imagine it's too much fun to wade into these problems, but we need
to fix this, finally. I would be happy to help.
Hi all,
I wanted to share the results of our latest round of usability testing with
the current version of the Media Viewer. As a really quick summary we can
say that the basic design concept and the way we present information and
controls seem to work, while some aspects such as the connection with
Commons info page and license details need more clarity.
To get more details check the notes at
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Usability_testing
The idea is to keep testing periodically as new features are added to the
Media Viewer and new prototypes are built for future features.
Feel free to circulate the participation form
link<https://docs.google.com/a/wikimedia.org/spreadsheet/viewform?usp=drive_web&…>
to
those users that may be interested in testing new multimedia features.
thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
The number of Apache busy workers on the image scalers spiked between 2:55
and 3:15 UTC, peaking at about 3:12 and overwhelming
rendering.svc.eqiad.wmnet for about a minute.
The outage correlates fairly well with a spike of fatals in
TimedMediaHandler, consisting almost entirely of requests to this URL: <
http://commons.wikimedia.org/w/thumb_handler.php/2/2c/Closed_Friedmann_univ…
>.
The full stack trace is included in <
https://bugzilla.wikimedia.org/show_bug.cgi?id=64152>, filed by Reedy
yesterday. It appears File::getMimeType is returning 'unknown/unknown' and
that File::getHandler is consequently not able to find a handler.
On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
> On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc <gilles(a)wikimedia.org>wrote:
>>
>> When the user opens media viewer, but there are 4 API calls per image and
>> we preload the next/previous images fairly quickly after opening one. So
>> generally within a few seconds, you're looking at 12 API calls when opening
>> Media Viewer.
>>
>
> That's way too high. Since you're planning to deploy this soon, we should
> figure out how to meet the requirements using the infrastructure that we
> have rather than the one we'd like to have. Have you considered adding a
> MediaWiki API module to your extension that composes the data into a single
> response? You could do this without duplicating code by
> constructing DerivativeRequest objects to each endpoint, as described in <
> https://www.mediawiki.org/wiki/API:Calling_internally>.
>
This is the current behavior (in master):
- one filerepoinfo API call per page
- one imageinfo, imageusage, globalusage API call per image
- depending on the language, there might be a users API call per image,
possibly to another wiki (Commons).
- there might be another imageinfo call to get sizes for a specific
thumbnail. This on the file type/size, should be very rare.
All but the imageinfo call are cached on Varnish for one day. (Caching
imageinfo for more than a few minutes would be more problematic as users
would expect to see changes to image description etc. immediately.)
Merging filerepoinfo/imageinfo/imageusage/globalusage into a single API
call should be possible even on the client side, but it would mean that we
cannot cache anything; not sure how that affects server load (I suppose the
API has its own caching mechanism, but even that must have some overhead
compared to Varnish). Similarly, merging multiple calls to the same API
would be possible but would make caching mostly useless.
The users API call can go to a different wiki, so would be very difficult
to merge it directly with the other calls. We only use it to get the gender
of the uploader, though; maybe that information could be added to the
imageinfo API, which has its own mechanism of handling remote filerepos.
If you absolutely had to cut some functionality out in order to roll this
> out more broadly, what would you eliminate?
IMO we could get rid of the users, imageusage and globalusage calls without
much trouble. The first one is only used for gender-correct translations.
The other two are used to show some pages which use the image - since there
is not enough place on the UI to show more than a few, this is not a very
useful feature as it exists now.
We could also only enable preloading after the user has used prev/next
navigation for the first time.
Hi all,
I've been asked how to make templates that can provide information for
MediaViewer to display on the metadata panel; I will try to give a few
pointers.
== Metadata types that are already handled ==
If you want to ensure the some type of metadata that is already handled by
MediaViewer (license, description, author name etc.) will be read correctly
for files which have been uploaded to your wiki, you need to present it in
the same way it is presented on Commons. See the first two sections of
COM:MRD [1] (infobox templates, license templates) on how to do that.
(Also, COM:GEO [2] although currently it is not very helpful for figuring
out how to make location templates in other wikis compatible.)
tl;dr: you need to add a certain HTML id or class to some container element
in the template, and another one to the specific text that you want to be
machine-readable (such as the license name) - this usually means wrapping
the text in a <span> which does not change anything visually (or maybe
hides the text completely) but has a certain class or id.
So in practice it will look something like this:
<div class="licensetpl">
(lots of fancy HTML)
Licensed under the <span class="licensetpl_long">Do What the Fuck You Want
to Public License</span> (<span class="licensetpl_short">WTFPL</span>).
<span class="licensetpl_attr_req" style="display: none">false</span>
(more fancy HTML)
</div>
Alternatively, if you don't want to mess with existing template code, you
can just add all the information in hidden fields, the way the PD templates
do it on Commons [3]. If you have lots of templates for the same license,
and they do not share a common layout template, this way it can be done by
a bot.
== New metadata types ==
If you want to add some new kind of information to MediaViewer, you need to
make sure there is a template which will provide it in the way described
above (have a class that wraps the whole template plus a class for each
specific piece of information you want to read from it).
Just marking up the template as a whole will probably not be enough. That
way MediaViewer gets a big HTML blob instead of proper metadata. We would
really like to avoid displaying big blobs of HTML which will clash with the
design of the viewer in uncontrollable ways. We made an exception with
permission templates, because they are important (also there is lots of
them, and marking all up properly would be herculean work), we would prefer
if we didn't need to make more. So please try to figure out what is the
specific text (or link, logo image, whatever) that needs to be shown, and
add specific markup for that.
(Also, before putting a lot of work into making some templates provide
metadata, make sure somebody is willing to implement it on the MediaViewer
side!)
== IQ&A (answers to imaginary questions) ==
Q: Is the class wrapping the whole template ("licensetpl" in the above
example) important?
A: Yes! We use it to know which fields belong together when multiple
templates of the same type are used on the page.
Q: I am adapting templates for a new type of metadata. Should I use ids or
classes?
A: Classes. Please. Using ids is almost always a bad idea. Using the same
id twice on a page is invalid HTML and can cause unexpected behavior (XML
parsers choking on the page, CSS selectors not returning all matching
elements etc). You might think that the template will never need to be used
twice on a page, but you will probably be proven wrong eventually.
(Also, ids are more trouble when adding CSS styles. Although using the same
id/class for marking up metadata and for styling the content is probably a
bad idea in itself.)
Q: I want to mark up templates on my local wiki to be compatible with
Commons templates. Are all the fields described on COM:MRD used by
MediaViewer?
A: No, most aren't. You can check the source code [4] if you need an exact
list. (It is not as hard as it sounds!)
Q: Does all information come from the templates described on COM:MRD?
A: No, some comes from categories (specifically assessment data such as
featured image status - although we do not display it yet). That will not
work for non-Commons-hosted images :( If you want to help with fixing that,
see the previous section.
Q: What about internationalization?
A: If the template uses MediaWiki messages for localization, that will
work. Other methods probably won't. (Language templates like {{en}} work in
{{Information}} and similar templates, but that's probably not a method
that can be used for other types of metadata.)
[1] https://commons.wikimedia.org/wiki/Commons:Machine-readable_data
[2] https://commons.wikimedia.org/wiki/Commons:Geocoding
[3]
https://commons.wikimedia.org/w/index.php?title=Template:PD-Layout&action=r…
[4]
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCommonsMetadata/mas…
Hi everyone,
Keegan and I reviewed our release plan for Media Viewer today and would like to update it based on community feedback.
We propose to spread out the release to large wikis over the next 3 weeks, so we can better focus on each community’s needs. Next week, we would like to deploy on the French and Dutch Wikipedias, and carefully evaluate the performance and community feedback on these first large sites.
At the request of our community partners, we would like to push back to the following week the release to Portuguese, Swedish and a few other wikis. This will give their users two weeks to test it out in beta and and give us more feedback — and it will enable us to carefully review the performance and community response on our first large wikis and pilot sites before deploying widely on a lot of large wikis. And a week later, we would release to English, German, Italian and Russian, which are likely to require more community interaction.
Here is the updated schedule we recommend:
• May 1:
Dutch and French Wikipedias
• May 8:
Japanese, Portuguese, Spanish, Swedish, Telugu? Wikipedias, Wikimedia Commons
• May 15:
English, German, Italian and Russian Wikipedias
• May 22:
Enable by default on all wikis
Does this plan work for you? Any comments or recommendations?
You can read more here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
We’ve added links to local pages or surveys on many of these sites. If we are missing a link to an important announcement or discussion, you are welcome to add it on this page. :)
Thanks for all your help with this project. Have a wonderful weekend!
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
There've been some issues reported lately with image scaling, where
resource usage on very large images has been huge (problematic for batch
uploads from a high-resolution source). Even scaling time for typical
several-megapixel JPEG photos can be slower than desired when loading up
into something like the MMV extension.
I've previously proposed limiting the generatable thumb sizes and
pre-generating those fixed sizes at upload time, but this hasn't been a
popular idea because of the lack of flexibility and potentially poor
client-side scaling or inefficient network use sending larger-than-needed
fixed image sizes.
Here's an idea that blends the performance benefits of pre-scaling with the
flexibility of our current model...
A classic technique in 3d graphics is
mip-mapping<https://en.wikipedia.org/wiki/Mip-mapping>,
where an image is pre-scaled to multiple resolutions, usually each 1/2 the
width and height of the next level up.
When drawing a textured polygon on screen, the system picks the most
closely-sized level of the mipmap to draw, reducing the resources needed
and avoiding some classes of aliasing/moiré patterns when scaling down. If
you want to get fancy you can also use trilinear
filtering<https://en.wikipedia.org/wiki/Trilinear_filtering>,
where the next-size-up and next-size-down mip-map levels are combined --
this further reduces artifacting.
I'm wondering if we can use this technique to help with scaling of very
large images:
* at upload time, perform a series of scales to produce the mipmap levels
* _don't consider the upload complete_ until those are done! a web uploader
or API-using bot should probably wait until it's done before uploading the
next file, for instance...
* once upload is complete, keep on making user-facing thumbnails as
before... but make them from the smaller mipmap levels instead of the
full-scale original
This would avoid changing our external model -- where server-side scaling
can be used to produce arbitrary-size images that are well-optimized for
their target size -- while reducing resource usage for thumbs of huge
source images. We can also still do things like applying a sharpening
effect on photos, which people sorely miss when it's missing.
If there's interest in investigating this scenario I can write up an RfC
with some more details.
(Properly handling multi-page files like PDFs, DjVu, or paged TIFFs could
complicate this by making the initial rendering extraction pretty slow,
though, so that needs consideration.)
-- brion
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/495
There are a few links at the bottom of the current Media Viewer interface -
they say "About Media Viewer | Discuss this feature | Help | Preferences".
There was a request to change "Discuss this feature" to "Discussion" and
I wanted to ask for advice here before we did it.
I'm afraid that "Discussion" will be misinterpreted as being a link to the
file's talk page, and that we'll get feedback about the files (or worse,
the subjects of the files a la AFTv5) on the Media Viewer talk pages.
Does anyone else share that concern? Am I being unnecessarily paranoid?
Justifiably paranoid?
Cheers,
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
On Tue, Apr 29, 2014 at 12:30:57PM -0700, Oliver Keyes wrote:
> Geneally speaking my advice to the multimedia team would be "don't go near
> surveys". I've done a lot of them in the last 3 years, and the one thing
> I've learned is that surveys are very, very difficult to get right. Another
> thing I've learned is that if you don't get them right, the results are
> meaningless and it's hard to tell when that happens.
>
> As I understand it, Jared's team is hiring a qualitatively-focused UX
> researcher or two in the upcoming budget to do research around design and
> feature usage; we should hold off until they come in, first because they're
> simply going to be better at it than we are, and second because it's
> probably going to be frustrating for them if they come in and find a tool
> locked in as How We Do Things (and frustrating for us if they want to
> change that tool):
Hi, Multimedia list!
Just thought I'd cross-post this reply to my call for help with surveys
[0] on the analytics list.
I'm sort of of the mind that skipping the survey for UploadWizard is a
good idea, especially now that I've thought about it more - using a survey
from a third-party site is silly for logged-in users, because logged-in
users will know how to use the talk pages and/or bugzilla.
Thoughts?
[0] http://lists.wikimedia.org/pipermail/analytics/2014-April/001911.html
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
Hi folks,
Here are our plans for the multimedia team’s next development cycle.
This 6-week cycle starts tomorrow, May 1, and ends on June 11 (second half of fiscal Q4), and will include 6 weekly sprints. In this next cycle, we plan to switch our focus to Upload Wizard and Technical Debt, while addressing Media Viewer's most critical issues, as needed.
For this cycle, we propose to divide our time evenly between these three main projects:
* Media Viewer - address remaining critical tasks (e.g. serious bugs, global load estimates, basic zoom feature)
* Technical Debt - fix serious issues that need quick solutions (e.g. image scalers, timed media handler update)
* Upload Wizard - start planning for this project (metrics, feedback, UX designs, code review, unit tests)
In subsequent cycles, we expect work on Upload Wizard and Technical Debt to continue to be a primary focus for us. We also hope to start work on Structured Data and File Notifications this summer, as time allows.
Here are our meeting notes, for your review:
https://www.mediawiki.org/wiki/Multimedia/Meetings/Next_Cycle_2_Q4_2013-14
And here is our updated wall for what is now our current cycle:
http://ur1.ca/h7w5s
This cycle wall now includes separate columns for Media Viewer (~28 points), Tech Debt (~29 points) and Upload Wizard (~21 points). We moved all leftover Media Viewer cards into either this cycle wall -- or in one of the Media Viewer Release walls in Team Favorites (see upper right corner of Mingle site). We could easily spend another quarter or two working on Media Viewer, but our team is needed on other projects that were neglected during this big product push. For the next few weeks, we will continue to front-load Media Viewer tasks to address critical issues from our worldwide deployment, but then start shifting more and more to Technical Debt and Upload Wizard projects.
The meeting notes also include results of the previous cycle and a team retrospective, which will give you a sense of the agile development process we have been using in recent months. We have found this agile process invaluable, and we note that it has helped improve our overall performance, so we are now getting more work done, more efficiently. Music to our ears … :)
Please let us know if you have any questions about these plans. We will be sure to consult you as we start new projects like Upload Wizard -- and Gilles will update you shortly on our current sprint, which we just planned today.
Onward!
Fabrice
for the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
