As multilingual content grows, interlanguage links become longer on
Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than
200 links, and that becomes a problem for users that often switch among
several languages.
As part of the future plans for the Universal Language Selector, we were
considering to:
- Show only a short list of the relevant languages for the user based on
geo-IP, previous choices and browser settings of the current user. The
language the users are looking for will be there most of the times.
- Include a "more" option to access the rest of the languages for which
the content exists with an indicator of the number of languages.
- Provide a list of the rest of the languages that users can easily scan
(grouped by script and region ao that alphabetical ordering is possible),
and search (allowing users to search a language name in another language,
using ISO codes or even making typos).
I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to
illustrate the idea. Since this is not connected to the MediaWiki backend,
it lacks the advanced capabilities commented above but you can get the idea.
If you are interested in the missing parts, you can check the flexible
search and the list of likely languages ("common languages" section) on the
language selector used at http://translatewiki.net/ which is connected to
MediaWiki backend.
As part of the testing process for the ULS language settings, I included a
task to test also the compact interlanguage designs. Users seem to
understand their use (view
recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
but I wanted to get some feedback for changes affecting such an important
element.
Please let me know if you see any possible concern with this approach.
Thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
I'm removing the 'beta' branding from the Android version of the Commons
app for our next release.
This provisional commit replaces the current beta icons with the icons I
found in the WMF design DropBox, and also tosses in a copy of the PSD
source file (compressed as it's huge) under a 'scratch' directory so we
don't lose it:
https://github.com/brion/android-commons/commit/811a23c17fa9a0cb52171c17561…
Design folks who worked on the icons, please confirm if this is the correct
icon set -- it's a little different from the beta icon, and I don't know
whether that's deliberate or not. :) If there are newer assets for this
please let me know and I'll merge them instead!
Thanks!
-- brion
Hello,
Seeking for icons to reprent things like "axioms", "theorems" and so on
for the french wikiversity, I found the "Project Nuvola 2.0+"[1],
despite it seems that there's currently not much activity on it, I began
to put new proposals on the page. I think I red some messages on this
list about this topic. Is there some active projects I should look at?
By the way, if you have ideas to illustrate the following concepts, let
me know:
Axiom
Corollary
Definition
Example
Lemma
Principle
Proof
Property
Suggestion
Theorem
You may look at [2] to see my current proposals for some of them.
[1] https://commons.wikimedia.org/wiki/Commons:Project_Nuvola_2.0%2B
[2] https://fr.wikiversity.org/wiki/Modèle:Emphase
--
Association Culture-Libre
http://www.culture-libre.org/
Trevor, Arun and I will be organising a design workshop at the Amsterdam
Hackathon<http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013#Interface_design_sol…>
.
We'll apply the 6-8-5 quick design
technique<http://konigi.com/book/sketch-book/work-fast>to explore and
review design ideas for different design problems. We will
sketch and discuss collaboratively with the attendees to solve design
problems on Wikimedia projects. Although we have an initial list of design
problems (more suggestions are welcome), we will encourage attendees to
propose their own (based on the projects they will be working at during the
event).
The Workshop is organised in two sessions of one hour each on May 24 and
May 25.
If there is interest from remote participants to join the event, please let
me know.
It may be complex due to the nature of the event, but it is at least worth
trying.
Pau
--
Pau Giner
Interaction Designer
Wikimedia Foundation
>
> 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>