I spent a little more time the last few weekends on ogv.js
(JavaScript-based player for Ogg Theora and Vorbis media in IE and Safari)
and have gotten two major things working:
* an all-Flash version -- should work in older IE and Safari versions that
can't run the JS code
* optional GPU acceleration with WebGL or Flash Stage3D where available
More details on my blog:
https://brionv.com/log/2014/03/29/ogv-js-now-in-webgl-and-flash-flavors/
The Flash version generally runs a bit faster than the JS version on IE
10/11, about the same as JS on Safari 6.1/7, and slower than JS on current
Chrome and Firefox. Note that the player demo page currently requires IE 9
or later although the player itself should work on IE 6/7/8.
I've also compared performance to the Cortado Java applet we currently use
-- Cortado is still a little faster in terms of CPU usage, but getting the
applet to actually *run* with the current version of Java is a nightmare --
even the signed version of the applet from theora.org requires adding a
security exception -- whereas JS or Flash "just works".
GPU acceleration in both JS and Flash combines YCbCr->RGB colorspace
conversion into the drawing step and can be a *huge* speed boost at higher
resolutions. At 360p or 160p it's a modest improvement of a couple
milliseconds per frame on my test machines. Note that WebGL is available in
IE 11, but is disabled by default in current versions of Safari (and cannot
be enabled on iOS without a jailbreak).
The main missing feature left is seeking, which I think can be left for
later. I expect to do a bit more performance tuning and code cleanup, but I
think it's time to devise some integration into TimedMediaHandler so people
can try it out "in-place" on Wikipedia & Commons...
-- brion
Hey,
I have been redoing the change email page with vforms and I kinda stuck at
a point where I have the following three choices.
If there is a special page already with two buttons, whose style I could
copy that am not aware of please notify me.
http://ux.stackexchange.com/questions/54894/button-choices-for-canceling-fr…
Also in the previous change email page you should have noticed that when I
enter a invalid email I cannot cancel out of that form. Is that the
expected behaviour( which I highly doubt ) or is that a bug that I could
probably fix.
https://gerrit.wikimedia.org/r/#/c/121975/ -> bug patch.
Regards,
Aditya
Hi all.
I apologize for cross-posting; I'm trying to reach all projects here, and encourage you to translate and spread this message to relevant village pumps. (I explain a tool here, some points, and provide you with a link where you can participate in the discussion I opened.)
The WMF Engineering Team is kindly working on Media Viewer, which would show a pop-up of some sort when you click an image. This tool is available for testing to those people who created an account, in Beta tab, on all projects. Like you may see the tool has a relatively high impact on average reader experience.
It came to my mind that the tool goes full-screen, which doesn't meet the "I stay on the article" expectation. I feel it may be important to an average reader to gain orientation.
I opened a discussion, with some people calling my idea a "metadata pop-up" rather than a "media viewer". I feel that may be good thing: the existing default opens a lot of image info and tells people what Commons is. I feel the media viewer should do something close to the same, with the advantage of not leaving the page, and some interactive means of viewing the image if the user clicks some buttons.
As opposed to that, a "Media Viewer" would show a bigger image and make use of space. But the mock I have is slightly bigger already, like the existing "File:*" page. I am not assuming that the reader wants a bigger image; I'm assuming he may also be interested (and it would be more transparent to) in reading some metadata, description, date, author.
Please see the discussion here and weigh in, basing on your preferences and Wikimedia projects experience. Your voice powers the future of the tool, and Wikimedia projects.
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Please_do…
Regards,
Gryllida.
Yesterday I have held lectures about Wikipedia at the School of Electrical and
Computer Engineering of Applied Studies in Belgrade
[http://www.viser.edu.rs/?lang=EN] and observed them trying to create a new
user
and save an article. Since all the students used the same IP, they have all
triggered captchas, so here are my general remarks. Note that these students
should be more computer literate than most students of their age (early 20s).
Some students have found the captchas to be difficult to read - for example
some
could not differ 'a' from 'x' or 'r' from 'y' - so perhaps captchas should not
be made even more difficult. Captcha localization could help here.
The warning that the article is not saved is not clearly visible, and some
students have managed to not save their articles without realizing that they
have not saved them. The warning could be made more visible, but I believe that
the best way of solving this would be to try to save the article by ajax, and
to
display the captcha on the article editing page itself.
Account creation is botched in several ways, and these are really beginners'
errors for which I don't understand how could they happen in age-old software
as
MediaWiki. Examples:
- If you enter a mismatched password, the error message will only appear after
you click on 'Create your account'. The mismatch could be checked in the
javascript after entering the passwords on the page itself, the same way
duplicate username is checked.
- If you enter the passwords right but the captcha wrong, you have to reenter
the passwords. Basically, whatever mistake you make, you have to reenter the
passwords. I see no reason to do this, the password fields could be pre-filled
with the entered passwords. Also, similar to article saving above, it would be
even better if the captcha would be verified via ajax on the page itself.
- The opposite: if you enter a password wrong but the captcha right, you have
to
reenter the passwords (good) AND reenter the captcha (bad). Some quick typers
have oscillated several times between entering one or the other wrong. I see no
need to have to reenter the captcha once you have entered it correctly - you
have already authenticated as a human.
Also, if I may ask for a wish, a special page where I could enter an IP and
free
it of all the spam filters and protections would be nice and all the
wikieducators would thank you :)
Yesterday I have held lectures about Wikipedia at the School of Electrical and
Computer Engineering of Applied Studies in Belgrade
[http://www.viser.edu.rs/?lang=EN] and observed them trying to create a new
user
and save an article. Since all the students used the same IP, they have all
triggered captchas, so here are my general remarks. Note that these students
should be more computer literate than most students of their age (early 20s).
Some students have found the captchas to be difficult to read - for example
some
could not differ 'a' from 'x' or 'r' from 'y' - so perhaps captchas should not
be made even more difficult. Captcha localization could help here.
The warning that the article is not saved is not clearly visible, and some
students have managed to not save their articles without realizing that they
have not saved them. The warning could be made more visible, but I believe that
the best way of solving this would be to try to save the article by ajax, and
to
display the captcha on the article editing page itself.
Account creation is botched in several ways, and these are really beginners'
errors for which I don't understand how could they happen in age-old software
as
MediaWiki. Examples:
- If you enter a mismatched password, the error message will only appear after
you click on 'Create your account'. The mismatch could be checked in the
javascript after entering the passwords on the page itself, the same way
duplicate username is checked.
- If you enter the passwords right but the captcha wrong, you have to reenter
the passwords. Basically, whatever mistake you make, you have to reenter the
passwords. I see no reason to do this, the password fields could be pre-filled
with the entered passwords. Also, similar to article saving above, it would be
even better if the captcha would be verified via ajax on the page itself.
- The opposite: if you enter a password wrong but the captcha right, you have
to
reenter the passwords (good) AND reenter the captcha (bad). Some quick typers
have oscillated several times between entering one or the other wrong. I see no
need to have to reenter the captcha once you have entered it correctly - you
have already authenticated as a human.
Also, if I may ask for a wish, a special page where I could enter an IP and
free
it of all the spam filters and protections would be nice and all the
wikieducators would thank you :)
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_31st
Notable items...
== Monday ==
* The new logging tool in use at WMF, Logstash, will have it's backend
search cluster (powered by ElasticSearch) upgraded to a newer version
(1.0.1).
** No user-facing change or disruption associated with this.
== Tuesday ==
* MediaWiki deploy window, currently following the 1.23 schedule
** group1 to 1.23wmf20: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf20>
** Schedule: <https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_depl…>
** NOTE: This includes the continuing rollout of Typography Refresh:
<https://www.mediawiki.org/wiki/Typography_refresh>
== Wednesday ==
* Cirrus Search will be graduated from Beta Feature to enabled for all
users on all non-wikipedia wikis (eg Commons, etc)
** <https://www.mediawiki.org/wiki/Search>
== Thursday ==
* MediaWiki deploy window, currently following the 1.23 schedule)
** group2 to 1.23wmf20 (all Wikipedias)
** NOTE: This includes the continuing rollout of Typography Refresh:
<https://www.mediawiki.org/wiki/Typography_refresh>
** group0 to 1.23wmf21 (test/test2/testwikidata/mediawiki)
** <https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf21>
Thanks, and as always, questions welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi,
Guillaume and I will be hosting an IRC office hour
on March 28, 2014 (Friday) at 17:00 UTC / 10:00 PDT
in #wikimedia-office on irc.freenode.net.
We will quickly present the progress and status of the ongoing Project
management tools review [1] and after that we are happy to answer your
questions!
See you at the IRC office hour!
Thanks,
andre
[1] https://www.mediawiki.org/wiki/Project_management_tools/Review
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Chemical Markup support for Wikimedia Commons has been a feature
requested for a long time[1][2] and now I think it's time to act. Please
consider my GSoC proposal[3]. I will focus on molecules and reactions,
both supported by MDL molfiles, through a media file handler and a
JavaScript front end.
Spectra and analytical data, chemical crystallography and materials --
this is somewhat more complicated and I think; let's start it simple. If
there is sufficient time to play with CML after implementing MOL file
support, no one prevents us from doing so. But past experience has shown
that even simple projects grew into dimensions that were not expected
resulting in software that is not ready to use till today.
Curious about your opinion.
Kind regards
Rainer Rillke
----
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2004-June/010715.html
[2] http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068573.html
[3]
https://www.mediawiki.org/wiki/User:Rillke/Chemical_Markup_support_for_Wiki…
Chemical Markup support for Wikimedia Commons has been a feature
requested for a long time[1][2] and now I think it's time to act. Please
consider my GSoC proposal[3]. I will focus on molecules and reactions,
both supported by MDL molfiles, through a media file handler and a
JavaScript front end.
Spectra and analytical data, chemical crystallography and materials --
this is somewhat more complicated and I think; let's start it simple. If
there is sufficient time to play with CML after implementing MOL file
support, no one prevents us from doing so. But past experience has shown
that even simple projects grew into dimensions that were not expected
resulting in software that is not ready to use till today.
Curious about your opinion.
Kind regards
Rainer Rillke
----
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2004-June/010715.html
[2] http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068573.html
[1]
https://www.mediawiki.org/wiki/User:Rillke/Chemical_Markup_support_for_Wiki…