Following up on Lila's Wikimania keynote: what platforms and devices should
we have in mind when making decisions today or in the near future about
Wikimedia content creation and delivery?
*Digital eyewear?
*Smart watches?
*3D displays?
*Large format displays?
*Health monitoring devices?
*Smart homes and buildings?
*Computer-led education systems in classrooms and remote learning?
*Driverless or semi-driverless cars?
*GPS-enabled devices of all sizes?
*Artificially intelligent consumers of Wikimedia content?
I would be interested in hearing others' thoughts.
Thanks,
Pine
Hello everyone,
It’s with great pleasure that I’m announcing that Marc Ordinas i Llopis joined the Wikimedia Foundation as a Features Engineer. Note the past tense. :-D
Before joining us, Marc was a programmer at Collabora[1] open source consultancy where he worked on a window manager for the Nokia N900 mobile phone and various Webkit[2] ports for Gtk+ and Qt. Before that he spent eight years programming for video game studies and on a distributed GUI based on CORBA.
He started to work with us a little over a year ago in July of 2013, but his first official day as an international contractor was December 2, 2013. (You know it is bad when you have to look in your mail archives to provide years with your dates.) Along with Arlo (a future e-mail), the two of them work with Subbu Sastry and C. Scott Ananian to form the Parsoid team which provides the back-end voodoo that turns your VisualEditing into wikitext and back again.[3]
He studied technical engineering in computer systems at the University of Balearic Islands. He is fluent in Catalan, English and Spanish, with a dabbling of German, French, Russian and Chinese. He lives in Majorca, Spain where the latest Parsoid team offsite just was.[4] There, he spends his free time reading, making (and tasting) wine and generally seemingly being the IT support for the island. He’s also involved in local politics and currently serving as town councillor. He goes by Marcoil on the Internet because he’s sick of me misspelling his name on contracts.[5]
Please join me in a belated welcome of Marcoil to the Wikimedia Foundation. :-)
Take care,
Terry
P.S. In keeping with Jared’s demand of a picture to accompany every new hire announcement, here is a photo: https://www.flickr.com/photos/tychay/14775054560/
[1] http://www.collabora.com/ <http://www.collabora.com/>
[2] https://en.wikipedia.org/wiki/WebKit <https://en.wikipedia.org/wiki/WebKit>
[3] https://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with… <https://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with…>
[4] Jealous? Like compiler design? Perhaps you should apply to Team Parsoid. :-D
[5] http://marcoil.org/ <http://marcoil.org/>
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org <mailto:tchay@wikimedia.org>
i: http://terrychay.com/ <http://terrychay.com/>
w: http://meta.wikimedia.org/wiki/User:Tychay <http://meta.wikimedia.org/wiki/User:Tychay>
aim: terrychay
Hello!
If you are interested in following along, please join us tomorrow
(time/location below) for the following IRC meeting:
---------
Google Summer of Code and FOSS Outreach Program for Women interns and
mentors are invited to this IRC meeting to showcase the work done and share
any ideas for the future. We are scheduling two hours because of the amount
of projects involved, but the length of the meeting will depend on you.
This is how the showcase will work:
* We will start from East to West, based on the location of the intern.
First stop: Taipei.
* Each intern (or mentor if the intern can't make it) will point to the
project page and a demo (if possible), and will add a short comment written
in advance. We will leave a bit of time for comments questions, and then we
will move on.
The open discussion will follow, if time permits.
-----------
*Time:* 3pm UTC
http://www.timeanddate.com/worldclock/fixedtime.html?msg=IRC+Meeting&iso=20…
*Location:* #wikimedia-office
*Length:* 2 hours
Hi,
In collaboration with Chris Steipp, I am considering starting a monthly
security newsletter for Wikimedia, focused on common risks and mitigation
techniques. The target audience is the broad Wikimedia community including
developers, WMF and chapter employees, and volunteers with high risk
accounts.
Example topics:
Phishing
Coding best practices
Wifi security
Securing data stored on cell phones
Check fraud
Preventing insider theft of funds in Wikimedia organizations
If you are interested in contributing to the newsletter please email me off
list.
Thanks,
Pine
Dmitry Brant wrote:
> The fact that you don't see the benefits of the native app over the mobile
> website is simply an indication that we still have a lot of work to do with
> the apps, which we are excited to do.
Partly this is because you don't support my mobile platform.
Dmitry Brant wrote:
> But, is it a waste of effort to bring a truly integrated, seamless
> Wikipedia experience to our users' mobile devices? I don't think so. Nor
> is it a waste of effort for the WMF to be seen as a driving force in mobile
> design and mobile user experience.
I was assuming that integration and being seamless are easily doable from a web browser.
Offline storage is hard in a browser, as you pointed out; that's too much detail for me to understand quickly, and I have no comment yet. In principle, such concern is valid.
Documenting extra differences and shortcomings of web browsers could be a nice task.
svetlana
When I do preparsing of the following text
Some text
===<!-- Comment written this way ===
And a new line after the end of the comment-->
It gives me a level 1 header with = as a title (what is expected), but it also
put a comment inside of <h></h> tags:
<root>Some text
<h level="1" i="1">===<comment><!-- Comment written this way ===
And a new line after the end of the comment--></comment></h>
</root>
This is not a problem for web rendering since comments are simply removed, but
if one will try to create some ObjModel from the result xml, it would be not
exactly the result that person would expect. And there might be some other
unexpected results. i.e. some code would expect to find = before </h> tag, and
would be surprised when it does not find it there. Etc.
This quite a minor problem, but I think it worth reporting.
There's been some recent controversy over access to & control over site JS
which I'd prefer not to wade into... but it does remind me of some ideas
I've been mulling over related to sandboxed JavaScript execution.
Power users need to have an easy way to write, deploy, and use tools that
integrate into the wikis:
* custom editing tools
* custom menu items
* custom widgets for the sidebar
* that can be enabled widely with a minimum of security worries
(We can make separate tools on Tool Labs already but that provides no UI
integration beyond putting links in sidebars or wiki pages.)
JavaScript code can be isolated from the primary execution context by
running scripts in an <iframe> based on a distinct domain, with a
well-defined "safe" communication channel between it and the parent window
over the window.postMessage interface.
I've experimented with this previously in Extension:EmbedScript
<https://www.mediawiki.org/wiki/Extension:EmbedScript>to try "interactive
media"-like things such as graphs with dynamic components or graphical
quizzes/games. But I think this could be generalized to utility scripts
that hook up to a well-defined portion of the UI or a particular data
pipeline.
For instance, a custom citation editor tool might add a toolbar button in
the editor (via defined API), then accept input data and be given a chance
to display its own UI on activation in a floating iframe, just as if it
were a 'native' lightbox-style dialog; on completion it would send the
modified text back into the editor through the defined postMessage API, and
the editor would save it into the page.
Such a tool would be unable to, say, edit other pages on your behalf
unexpectedly, and it would be unable to have side effects on the rest of
the UI, but it could be safely selectable on-wiki through an interface like
selecting Gadgets...
And that limited integration means much better security and stability
controls than gadgets and user scripts can provide today -- a broken or
malicious sandboxed widget would only be able to do things you explicitly
permit it to.
This sort of clean/limited in-wiki script API might allow for a lot of the
stuff that site scripts and auto-enabled Gadgets are used for today,
without the related QA, security, and control/side-effect issues.
If folks think this is an interesting idea I'll pick it back up in my
research time as I get some of the video stuff I've been working on
finished up.
(Note I'm still in the UK for another week and a half, so I'll be
reading/replying on lists intermittently until I get back to SF.)
Thoughts on specific classes of tools that might be easy or hard to do with
this technique are welcome.
-- brion
I just love this Google I/O 2013 talk on human perception and
cognition, and its implications for interactive and visual design. It
is accessible, but with a lot of information and applies very well to
us I think.
I'm sure that many designers know all about this and some have
probably seen the clip before, but it is also very good for
developers, because many of these things we know subconsciously, but
it's not really part of our vocabulary.
https://www.youtube.com/watch?v=z2exxj4COhU
DJ