>
> Awesome! :)
Thank you :)
>
> However typing a few language whom I know the ISO code didn't gave me
> much result, but this may be due to my browser version (firefox 8.0.1).
Its more likely that the names in many of the latin languages are the same
as English.
>
> Do plane to allow zoom, also ? What I can test with my current browser
> is already, adding zoom, moving around would be great. Also as I said I
> think it would be intesting to see how some phenomena propagate through
> time, so you may click "play" and see how it happened, or browse through
> a timeline.
All this and more is possible and quite easy to do if you know javascript.
Check out the d3 gallery: https://github.com/mbostock/d3/wiki/Gallery
Its a little ambitious for my coding experience, but I will probably give
it a try in the coming months.
--
Arun Ganesh
(planemad) <http://en.wikipedia.org/wiki/User:Planemad>
<http://j.mp/ArunGanesh>
You're probably aware of the new Create account and Login forms using
the mw-ui "Agora" styles for a compact vertically-stacked form. They
will soon be the default across all wikis. Meanwhile the Echo, Getting
Started, and Guided Tour extensions are using the Agora button styles.
Many other forms use the HTMLForm framework, which defaults to a
tabular layout. I added an option to display in 'vform' mode to this
in https://gerrit.wikimedia.org/r/#/c/65346/ , and on machine toro, I
made this the default. So:
* http://toro.wmflabs.org/wiki/Special:PasswordReset
* http://toro.wmflabs.org/wiki/Special:Redirect
* http://toro.wmflabs.org/wiki/Special:EditWatchlist
etc. You can append ?useNew=table to compare with the old appearance.
Even user preferences changes but that's not ready for a compact
vertical form (and may never be), so again you can go back to the old
appearance with
http://toro.wmflabs.org/wiki/Special:Preferences?useNew=table .
There's design work to do to improve the look: the ruled wrapper
legend around some forms, the error feedback after submission, etc.; I
have a list in https://www.mediawiki.org/wiki/Agora/Engineering#HTMLForm_issues
. But your feedback is welcome. It's not "my" design or Munaf's, it's
WMF's. Thanks to Munaf's use of Compass and Sass, it's even kinda fun
to work on.
Regards,
--
=S Page software engineer on E3
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
>
> 2013/5/27 Mathieu Stumpf <psychoslave(a)culture-libre.org>
>
> > Hi, I foward this mail to design, since it seems relevant here.
> >
> > As far as I know, currently there is no other way to create (world)maps
> > than taking some existing blank one, and put the color on regions of
> > interest. Maybe it would be intersting to have such a tool online, but
> more
> > important, to ease contributors ability to make interactive maps, which
> > enable readers to see how a phenomenon evolved/is evolving through time.
>
Hi Mathieu, coincidently I worked on doing this exactly during the
Amsterdam Hackathon.
What we are looking for is a platform where users can contribute to map
creation online by picking the right data layers, projection and
annotations. New web technologies can make this quite simple to do.
What I'm doing here is loading only the geodata for India's States as a
geojson(90kb) into the browser. I then use d3js to convert and reproject
the geojson as an interactive SVG along with automatic labelling.
We now have a fully functional map object in the dom to play with and with
styling set via css. Type in a new language code and see what happens :)
http://4thmain.github.io/d3hacks/wiki-atlas.html
This opens a new world with d3, jquery and openstreetmap data.
I'm still traveling, and will post more details on the maps-l list in about
2 weeks.
PS: I starting javascript a month back, look into the code at your own risk
:)
--
Arun Ganesh
(planemad) <http://en.wikipedia.org/wiki/User:Planemad>
<http://j.mp/ArunGanesh>
Hi, I foward this mail to design, since it seems relevant here.
As far as I know, currently there is no other way to create (world)maps
than taking some existing blank one, and put the color on regions of
interest. Maybe it would be intersting to have such a tool online, but
more important, to ease contributors ability to make interactive maps,
which enable readers to see how a phenomenon evolved/is evolving through
time.
What do you think ?
Le 2013-05-24 20:26, phoebe ayers a écrit :
> On Fri, May 24, 2013 at 1:55 AM, Mathieu Stumpf <
> psychoslave(a)culture-libre.org> wrote:
>
>> Le 2013-05-23 19:03, phoebe ayers a écrit :
>>
>> Perhaps of interest to many Wikimedians: the Endangered Languages
>> project
>>> recently launched a new layout, making it easier to find and submit
>>> information on languages that are in the "catalog of endangered
>>> languages"
>>> that they are building. Worth a look.
>>>
>>> http://www.**endangeredlanguages.com/<http://www.endangeredlanguages.com/>
>>>
>>> -- phoebe
>>>
>>
>> Thank you for the link.
>>
>> It seems to be the result of a realy huge work! Do you know if their
>> solution to create interactive map is free software? I would love to
>> have
>> such a tool within wikimedia. To my mind, it would be really useful
>> for
>> geographic and historical articles. Having a tool that would enable
>> to
>> "watch events propagation through time and localisation on a map"
>> would be
>> awesome, and it seems to me that their software is almost all that.
>>
>
> Hi Mathieu,
>
> I don't know anything about this project beyond what's on the site --
> I
> just ran across it. From what I can tell the user-submitted language
> data
> is CC-by but unfortunately they seem to be using Google Maps for the
> map
> interface.
>
> -- phoebe
--
Association Culture-Libre
http://www.culture-libre.org/
Hello,
It was nice to meet you all, this hackathon was really a great event
for me, enriching, passioning and enjoyable. I hope that it was also the
case for all others.
So, in one of the design workshop, we worked on the "Knowledge
requirement", that is some time articles treat non-obvious subjects and
go with assumptions on user knowledge. That can lead the user to a
frustrating situation where she think that she will never be able to
understand the topic. As far as I know, the writing guideline is that
every article should be suffisant, so probably that kind of article
would need to be improved. On the other hand, some community member
aren't find with the idea to "expand the whole subject from the ground"
in every article, and the most knowledgeable on a topic are not
necessarily those with the best pedagogic skills.
So our concern here is to bring a solution to user who want to know,
but don't necessarily have the basic knowledge expected to understand
it. The "let's make the article perfect for everyone" being out of
reach, the proposal to avoid user frustration is to inform him that the
article have knowledge requirements that she can acquire with some
pedagogical materials (preferably on wikversity/wikibook/wikisource).
I already had a mokcup of a possible solution I thought by myself, but
within this workshop, we were able to come with something probably far
more relevant : simpler, less invading, while at least as much
informative. The idea is to use a something similar to
Template:Disambiguation, and to list all the "dependencies" in a section
at the bottom of the article or in a subpage.
Moreover I think that this template may rise a warning message when
this sections/subpages doesn't exist, like with the ref and references
markup, so that if one place the template in an article, if would be
inclined to create the corresponding sections/subpages.
Now what is needed is to design/pick the text (which should short of
course) and the picture/icon to illustrate it. I already made some
research on commons to find a releavant icon, but maybe someone could
come with a better proposition, or even an original icon which fit the
topic. You can find a preliminary report on[1], but it's in french. I
will translate it later this week on meta, but this mail tell most of
what is written there, and I guess you don't need to know french to tell
your opinion on icons I selected from Commons as candidate for this
template.
[1]
https://fr.wikipedia.org/wiki/Utilisateur:Psychoslave/pr%C3%A9requis
--
Association Culture-Libre
http://www.culture-libre.org/
We currently have a goal to push our nearby feature to stable next week.
Your feedback on the current page would thus be greatly appreciated:
https://en.m.wikipedia.org/wiki/Special:Nearby
In particular please focus on these outstanding concerns remembering
this is a first pass and we should focus on the most essential things:
1) Copy text - in particular is it clear that certain pages need
photos and how to do that?
2) Refreshing the list of nearby results - is the icon choice correct
and how is the user experience?
3) Is the preview useful? (the preview is mobile only and activated
when you click on an article) - does the experience break without it?
(to get an idea of how it might work without try the desktop version
at https://en.wikipedia.org/wiki/Special:Nearby or click "Read this
article in full" before reading the preview and click back button to
get back to the nearby view
4) Any styling tweaks you'd recommend (especially with respect to the
article preview)?
Thanks for your feedback - all much appreciated!
Matthew Roth, 23/05/2013 17:31:
> So, what's the future of CC on Flickr?
> http://www.flickr.com/__creativecommons/
> <http://www.flickr.com/creativecommons/> shows only 260M CC images:
> there were already 220M in 2011 if I read news correctly; only 60M
> are free. 75 % of the times I ask a user to put an image under
> cc-by-sa they choose -nc-nd because "it was the first option" (and
> some of course "what, isn't Wikipedia non-commercial?!).
> Is this the price to pay to Instagram, Tumblr and Facebook?
>
>
> There are already lots of problems with Facebook (and various other
> social networks) and free licenses. See this analysis here:
> http://meta.wikimedia.org/wiki/Legal_and_Community_Advocacy/CC-BY-SA_on_Fac…
Yes but there's a difference between that and forcing good sources of
free knowledge like Flickr to drop this aspect, which Facebook never
had. :) (If this is what's happening.)
Ah, of course they also removed the option to have unlimited uploads:
only current pro users can keep it, for the others there are only
expensive storage plans.
Nemo
I made this today:
http://unicorn.wmflabs.org/staticheader/
It could use some work (I hard-set the searchbox width on movement, and it should probably flow to fill all available space).
But it gives an idea of what the experience would be like.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Currently we have very different upload detail and add-category screens
between Android and iOS versions of the Wikimedia Commons uploader app.
I've put descriptions and quick comparative videos on mediawiki.org:
https://www.mediawiki.org/wiki/Apps/Commons/Categories
Impressions and ideas welcome!
(Y'all can try the Android version with categorization from Google Play --
the iOS version in the App Store doesn't yet have categories but you can
try the older version to get a feel for the layout and the first data entry
screen. For those on the beta group, there'll be a push via TestFlight
later today.)
-- brion