Dear developpers,
I think my idea is as interesting for authorship as for the users on
androids and tablets.
As especially excellent contributions, you want to save on your device for
quotation or adding your own ideas, commentaries, etc. are just prepared
for storage on demand, I found this only in classical website, on the
search for PDFDownload. My problem or idea was, to do this by
SmartphoneHTC, but after packing the file archive and then touch for
download (onclick) the Download on SDChipcard does not launch or
initialize. The device then stops there and waits.... Comfortable und
desirable is the PDF function for Mobil devices and the Mobile version of
the Contents, as well, as it exists on the classical site. Possibly an
appfunction? Perhaps you have a solution for this, or you are in
preparation? Looking forward to your answer, sincerely yours Ursula Fuchs
Along with supporting RDFa 1.1 I'm planning to add support for <link> and
rel="" in our RDFa code.
To protect against injection of HTML rel values (including
rel="stylesheet") I'm going to be converting all RDFa terms like "foo" to
CURIEs like ":foo" (these are almost exactly the same, and the "edge case"
shouldn't happen at all in RDFa 1.1).
((I really wanted to wrap everything except protocol whitelisted AbsIRIs
in safe CURIEs making that "[rdf:type]" and "[:stylesheet]" but
unfortunately it seems safe CURIEs are only valid in about and resource))
Anyone worried about the possibility that there's a badly written browser
out there that'll treat <link rel=":stylesheet" href="..."> as a valid
stylesheet and include it is welcome to try out any browser they can think
of and bring it up.
I've written a test case for it http://bl.ocks.org/dantman/5695980 if the
bg there is red instead of blue then it's unsafe.
I've tested IE 6, IE 7, IE 8, IE 9, IE 10, Opera 10, Opera 12, Safari 5
(Windows), iOS 6's browser, Firefox 3.0, Firefox 21.0, Android 4's stock
browser, and Chrome 27. They're all safe.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
hi,
magnus mentioned on the cultural partners list that there should be a
non-overloaded alternative (kraken) to stats.grok.se to have tracking
for baglama and other view trackers?
when is this available?
rupert.
Hey Kaldari,
Thanks so much for yesterday's code fix to display videos in a modal viewer when you click on article thumbnails!
This was long overdue and makes a huge difference already, as shown in this example:
https://en.wikipedia.org/wiki/Congenital_insensitivity_to_pain
I agree with Erik that the ideal behavior would be to play the video immediately after you click on the thumbnail, without requiring a second click to play in modal view.
Now, is there any chance we could do something similar for still photos? As a longtime photographer, it drives me nuts that clicking on a thumbnail article takes you to this overwhelming page on Commons, with scary walls of text all around the image. (That's one of the reasons I haven't yet migrated any of my 20k Flickr photos to Commons, BTW.)
Most modern web sites nowadays just show you the photo in full screen, with only a few icons around it, so you can experience the image as it was intended to be seen (typically in a black modal panel, to make it pop up more). You still have the option to reveal all the text details if you want them, but they are not forced on you as we do today on Wikipedia and Commons.
Hopefully, our new multimedia team will be able to join forces with the design team to tackle some of these commonsense UI improvements, once we get up to speed this summer.
Thanks again for this welcome prelude :)
Fabrice
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
On May 30, 2013, at 1:35 AM, wikitech-l-request(a)lists.wikimedia.org wrote:
>
> From: Erik Moeller <erik(a)wikimedia.org>
> Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles
> Date: May 29, 2013 9:21:48 PM PDT
> To: Ryan Kaldari <rkaldari(a)wikimedia.org>
> Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Yes, better support for display of images through a modal viewer would
> be great. I'm not sure a "modal" parameter that has to be explicitly
> set for files is the best approach - I would recommend optimizing the
> default experience when a user clicks an image or video. It's not
> clear that the current behavior based on a pixel threshold is actually
> desirable as the default behavior. (On a side note, the TMH behavior
> should be improved to actually play the video immediately, not require
> a second click to play in modal view.)
>
> Magnus Manske explored an alternative approach pretty extensively in
> response to the October 2011 Coding Challenge, which is worth taking a
> look at:
> https://www.mediawiki.org/wiki/User:Magnus_Manske/wikipic
>
> Cheers,
> Erik
>
>
> From: Brion Vibber <bvibber(a)wikimedia.org>
> Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles
> Date: May 30, 2013 12:42:00 AM PDT
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Cc: Erik Moeller <emoeller(a)wikimedia.org>
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> I tend to agree that a light box or other modalish zoom should become the
> default behavior.
>
> -- brion
> On May 30, 2013 5:50 AM, "Ryan Kaldari" <rkaldari(a)wikimedia.org> wrote:
>
>> For years, I have weeped and wailed about people adding complicated maps
>> and diagrams as 220px thumbnail images to Wikipedia articles. These sort of
>> images are virtually useless within an article unless they are displayed at
>> relatively large sizes. Unfortunately, including them at large sizes
>> creates a whole new set of problems. Namely, large images mess up the
>> formatting of the page and cause headers, edit links, and other images to
>> get jumbled around into strange places (or even overlapping each other on
>> occasion), especially for people on tablets or other small screens. The
>> problem is even worse for videos. Who wants to watch a hi-res video in a
>> tiny 220px inline viewer? If there are subtitles, you can't even read them.
>> But should we instead include them as giant 1280px players within the
>> article? That seems like it would be obnoxious.
>>
>> What if instead we could mark such complicated images and high-res videos
>> to be shown in modal viewers when the user clicks on them? For example:
>> [[File:Highres-video1.webm|**thumb|right|modal|A high res video]]. When
>> you clicked on the thumbnail, instead of going to Commons, a modal viewer
>> would overlay across the screen and let you view the video/image at high
>> resolution (complete with a link to Commons and the attribution
>> information). Believe it or not, this capability already exists for videos
>> on Wikipedia, but it's basically a hidden feature of TimedMediaHandler. If
>> you include a video in a page and set the size as 200px or less, it
>> activates the modal behavior. Unfortunately, the default size for videos is
>> 220px (as of 2010) so you will almost never see this behavior on a real
>> article. If you want to see it, go to https://en.wikipedia.org/wiki/**
>> American_Sign_Language#**Variation<https://en.wikipedia.org/wiki/American_Sign_Language#Variation>and click on one of the videos. Compare that with the video viewing
>> experience at https://en.wikipedia.org/wiki/**Congenital_insensitivity_to_
>> **pain <https://en.wikipedia.org/wiki/Congenital_insensitivity_to_pain>.
>> It's a world of difference. Now imagine that same modal behavior at
>> https://en.wikipedia.org/wiki/**Cathedral_Peak_Granodiorite#**
>> Geological_overview<https://en.wikipedia.org/wiki/Cathedral_Peak_Granodiorite#Geological_overvi…>and
>> https://en.wikipedia.org/wiki/**Battle_of_Jutland<https://en.wikipedia.org/wiki/Battle_of_Jutland>
>> .
>>
>> Such an idea would be relatively trivial to implement. The steps would be:
>> 1. Add support for a 'modal' param to the [[File:]] handler (
>> https://gerrit.wikimedia.org/**r/#/c/66062/<https://gerrit.wikimedia.org/r/#/c/66062/>
>> )
>> 2. Add support for the 'modal' param to TimedMediaHandler (
>> https://gerrit.wikimedia.org/**r/#/c/66063/<https://gerrit.wikimedia.org/r/#/c/66063/>
>> )
>> 3. Add support for the 'modal' param to images via some core JS module
>> (not done yet)
>>
>> As you can see, I've already gotten started on adding this feature for
>> videos via TimedMediaHandler, but I haven't done anything for images yet. I
>> would like to hear people's thoughts on this potential feature and how it
>> could be best implemented for images before doing anything else with it.
>> What are your thoughts, concerns, ideas?
>>
>> Ryan Kaldari
>>
>>
>> ______________________________**_________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
>
> From: Ryan Kaldari <rkaldari(a)wikimedia.org>
> Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles
> Date: May 30, 2013 12:46:13 AM PDT
> To: Erik Moeller <erik(a)wikimedia.org>
> Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> On 5/29/13 9:21 PM, Erik Moeller wrote:
>> Yes, better support for display of images through a modal viewer would
>> be great. I'm not sure a "modal" parameter that has to be explicitly
>> set for files is the best approach - I would recommend optimizing the
>> default experience when a user clicks an image or video. It's not
>> clear that the current behavior based on a pixel threshold is actually
>> desirable as the default behavior. (On a side note, the TMH behavior
>> should be improved to actually play the video immediately, not require
>> a second click to play in modal view.)
>
> Does anyone think it would be a bad idea to just make modal viewing the default for thumbnailed videos?
>
> Ryan Kaldari
>
>
>
> From: Antoine Musso <hashar+wmf(a)free.fr>
> Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles
> Date: May 30, 2013 12:52:25 AM PDT
> To: wikitech-l(a)lists.wikimedia.org
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Le 30/05/13 05:49, Ryan Kaldari a écrit :
>> When you clicked on the thumbnail, instead of going to Commons, a modal
>> viewer would overlay across the screen and let you view the video/image
>> at high resolution
> <snip>
>
> I discovered yesterday that Commons as such a tool to browse pictures in
> a category. Whenever you browse a category page such as:
> https://commons.wikimedia.org/wiki/Category:Hackathons
>
> There is a Green icon which when hovered will expand to 'show slideshow'
> and when clicked replace the view with a slideshow view like Picassa /
> Flickr ...
>
> It would be nice to have that build in MediaWiki. Maybe there is a well
> supported JQuery plugin that does just that and we could ship in core?
>
>
> --
> Antoine "hashar" Musso
>
>
>
> From: Antoine Musso <hashar+wmf(a)free.fr>
> Subject: Re: [Wikitech-l] showing videos and images in modal viewers within articles
> Date: May 30, 2013 1:34:35 AM PDT
> To: wikitech-l(a)lists.wikimedia.org
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Le 30/05/13 09:46, Ryan Kaldari a écrit :
>> Does anyone think it would be a bad idea to just make modal viewing the
>> default for thumbnailed videos?
>
> Be bold! To play it safe, you can make the feature protected with a
> global feature that we will slowly enable on all wiki and eventually
> phase out later on :-] This way the code will land everywhere and we
> can play test it on beta then on commons ...
>
> --
> Antoine "hashar" Musso
> "did I say: 'be bold' ?"
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi everyone
It is my pleasure to introduce Nik Everett as a new Senior Software
Engineer specializing in Search, working remotely from his home in
Raleigh, North Carolina. Nik joins us from Lulu, a company founded by
Bob Young[1] to enable anyone to publish a book (dealing with print,
distribution, and order fulfillment issues). Nik was responsible for
a number of DevOps-related tasks at Lulu, mainly centered around test
automation, build infrastructure, and database performance, but also
including maintenance and support of their Solr infrastructure. He
also founded and chaired Lulu’s architecture review board, which is
similar to a group we’re just now starting up here[2]
Prior to Lulu, Nik worked at Bandwidth.com, Radarfind, and Nortel. He
has Bachelors Degrees in Computer Science and Mathematics from
University of North Carolina at Chapel Hill.
Nik knows many programming languages. He prefers writing in Python,
but due to the nature of what we’re doing here, he’ll probably end up
writing more Java and (of course) PHP. He likes picking up a new
languages every so often. He’s currently playing around with Haskell,
and on good days may be able to explain what a monad is. :-)
Nik’s nick on Freenode is “manybubbles”, and he's cc'd on this mail.
Rob
[1] One of Bob Young’s other claims to fame is as co-founder and
former CEO of Red Hat.
[2] Not yet an “architecture review board”, but that may be as good a
name as any for this:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-May/069569.html