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
In case you haven't seen, User:Rillke on Commons has implemented a
(default-on!) gadget that makes it possible to subscribe to
notifications of different types, e.g. policy changes, new features,
etc. These are shown as watchlist banners and upon login.
Here's a screenshot of the "subscription" interface:
http://i.imgur.com/gdImENz.png
IMO that type of gadget lends supports to the notion of shooting for a
subscription model to be ultimately integrated with Echo so that users
can get standard read-once notifications about things they care about
while keeping the core UI clutter-free.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
VisualEditor has the option to take over section edit links. We find this
is probably going to be unpopular for people who want to at least sometimes
edit wikitext, but don't want to loose them as VisualEditor users. After
discussing a few different options, including showing both links (really
cluttered and horribly long in some languages) and using icons (no icon
would really convey what we want here).
We have decided that it's probably best to make the edit link show an
alternative in a menu on hover. There's a prototype of this (somewhere)
that MatmaRex has hacked together (screenshot attached) which is close. I
mocked something up that is similar but perhaps a little better looking.
Max brings up a good point about my mockup, which is that it doesn't quite
fit with other vector-isms. Given that Vector is something we want to
evolve, we shouldn't get too caught up in that, but it's something worth
considering since deviation from what vector is today should probably only
be done if it's in the direction of what Vector should be in the future.
I'm hoping that others on the list could perhaps make suggestions, offer
ideas, make simple mockups or prototypes and help make this feature as good
as possible.
We need to have this solved quickly since we are releasing in a couple of
weeks.
- Trevor
Restarting the Commons Android app icon discussion; we want to ship an
update in the next couple weeks so it'd be great to get this sorted out.
Some quick notes:
* Don't forget to talk to your clients when planning designs! I felt a
little bit like the first version from the design team got created with no
input from the people working on the app, and that my feedback wasn't
welcome because I wasn't in on the design team's original discussion. This
is an open, transparent organization with an open, iterative software
development process, and we expect to be able to participate in all aspects
of that.
* Always test icons in a realistic environment next to other built-in apps
and third-party apps -- if you guys don't have good templates for this, I
can produce more screenshots from my phones and tablets that you can
cut-n-paste into.
* We *always* need a vector original that we can keep in source control so
future revisions or new resolutions can be created as necessary. SVG is
strongly preferred, since it can be edited with free tools, uploaded to the
wikis, viewed in browsers, etc.
Here's a screenshot of my phone with the current temporary icon in place:
https://upload.wikimedia.org/wikipedia/mediawiki/5/5e/Commons-android-Curre…
^ This current icon is "too iOS-y"; it has a color logo, is very gradienty,
etc. We have a PSD original somewhere in the design Dropbox share but since
it's a PSD we can't edit it with free tools.
Here's a screenshot with the proposed icon May put together based on
discussion from the design team:
https://upload.wikimedia.org/wikipedia/mediawiki/0/0f/Commons-android-Flat-…
^ To me this is overly flat and washed out -- the logo is mid-gray on
white. We have no original vector version that I can find, only the output
versions on dropbox. I'm not willing to ship this icon as-is, but it's a
good starting-off point for discussion.
Here's a screenshot today with an iteration I tossed together:
https://upload.wikimedia.org/wikipedia/mediawiki/d/d2/Commons-android-Flat-…
^ This has a black-on-offwhite icon which I think fits in better with other
Android launcher icons, and tweaks shading to match the 'light source on
top' look (top is lighter than the front, not darker). We have an SVG
original in source control:
Git branch with this icon:
https://github.com/brion/apps-android-commons/commits/mono-icon
SVG and large PNG in scratch dir:
https://github.com/brion/apps-android-commons/tree/mono-icon/scratch/icon-m…
Thoughts?
-- brion
For those interested in what's dropping in the fall with iOS7, it seems
that there will be a slight change in the way Wikipedia search is
integrated in to Siri.
Currently, you would need to explicitly use the name to search Wikipedia
results alone or primarily ("Search Wikipedia for surfing" or "Wikipedia
surfing"). It seems that they'll be using more natural language in iOS7,
with phrases such as ("Tell me about surfing"), and also using something a
lot more like the information snippets in Google Now or Quick View.
Here's a screenshot from today's keynote, which to me seems thin on
attribution...
http://tctechcrunch2011.files.wordpress.com/2013/06/img_9327.jpg?w=720&h=480
--
Steven Walling
https://wikimediafoundation.org/
That's how its currently implemented (with an attribute named mode). How it
all works (Or even if it gets adopted), will depend on the sort of feedback
I get.
You're 100% right, that this would not work well with the COM:QIC workflow,
and there are many places where the captions are important. But I would
argue there are many places where people just have captions as a place
holder text since there is a spot for a caption (Many [not all] galleries
on commons fit this description). In particular, the captions on the
auto-generated galleries in category listings are pretty useless, and could
easily be replaced with something triggered on hover.
Even in encyclopedic contexts, a gallery is used as a collection of pretty
pictures, and the caption is a sort of "see also" text to provide further
context for if one of the images catches the reader's eye.
--bawolff
On Mon, Jun 10, 2013 at 10:53 PM, Daniel Schwen <lists(a)schwen.de> wrote:
> If this should find its way into core, it should be made optional
> (using an attribute of <gallery>)! Please be aware that this would
> instantly destroy gallery applications like COM:QIC. Also from a
> usability standpoint hiding the captions is probably not always a good
> thing. Especially in the context of an encyclopedia rather than a
> "pretty picture" site (like flickr).
> Daniel
>
> On Mon, Jun 10, 2013 at 6:36 PM, bawolff <bawolff+wn(a)gmail.com> wrote:
> > [Cross posting to commons-l and design list]
> >
> > Hi all,
> >
> > Over the last couple days, I've been looking at making our <gallery> tag
> a
> > lot more slick. Compared to other websites, our galleries look very
> "boxy"
> > imo. This isn't that bad when it comes to icon/clip art type media, but
> for
> > photos I feel we could really do better. So I've tried to make the
> galleries
> > be more compact, with rows of images all the same height but different
> > width, and the caption visible on hover. The only downside to this is the
> > borders of the gallery become a little ragged, which mostly looks fine
> to me
> > (Possibly could be dealt with with js. Would involve a bit of double
> loading
> > the images though).
> >
> > A demo speaks louder than words, hence:
> >
> > *
> >
> http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/…
> > (contrast with
> >
> http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographi…
> > )
> > *
> >
> http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/…
> > (contrast with
> > http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish)
> > * http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page
> >
> > Additionally the wiki is open to editor (You need to register an account
> > first), so please don't hesitate to experiment.
> >
> > Anyhow, this is all still a work in progress, and I would really
> appreciate
> > your feedback/criticism/hate mail/love letters/etc.
> > --
> > Thanks,
> > Bawolff
> >
> > _______________________________________________
> > Commons-l mailing list
> > Commons-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/commons-l
> >
>
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
