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 have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Nothing is saved to disk. You can reply to topics or even add new ones but on refresh everything reverts to state.
Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples":
* Fully Chaos (everything is generated randomly.)
* Jimmy Wales
* Maggie Dennis (Moonriddengirl)
* Me
* A single topic (this is what you get to if you get an echo notification)
Speaking of, if you click the echo badge, and then click on the unread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to your feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs:
* The "New Topic" dialog doesn't close when you click the "X" button. No idea why; it worked the other day and now it doesn't.
* Some of the conversations are threaded weird. This is an artifact of the JSON.
* The tab highlights are a bit goofy.
Upcoming:
* The search functionality will work
* You'll be able to add and edit tags
* Stuff like archive/split/whatever
* Edit your own post, etc.
Please share your thoughts.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hello, I just had a call with
Mikael Wiberg, Professor, Head of Department
Department of Informatics, Umeå university, Sweden
He is now a new member of this list. Hej!
They want to get involved in different types of Wikimedia contributions.
One area of high interest among their students is interaction design.
We could start with a small and quite informal collaboration. From time
to time people come here asking for feedback or help about a UX problem,
a new workflow, some gadget needing some UX love... These students could
simply join the list and get involved in the discussions, bringing
feedback and ideas.
From there many progressive paths are possible:
* Start working on "design" AND "easy" bugs:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=design%2C%20easy%2C%20&…
* Help kicking the https://www.mediawiki.org/wiki/UX_review_queue
* Get involved in https://www.mediawiki.org/wiki/Micro_Design_Improvements ?
And probably more, but I think it's important to go for first things
first, and start with simple feedback to requests made to this list.
Welcome Mikael, we hope you bring more participation to this list and we
are looking forward to the first results.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Mad*Pow are organising a Webinar on April 30 about design critique and
getting effective feedback on designs. Those interested can register for
free at: http://mpwebinar11.eventbrite.com
Pau
--
Pau Giner
Interaction Designer
Wikimedia Foundation
Hello
I am Rahul Maliakkal, 3rd year UG student applying for Google Summer of
Code(GSoc). The idea that I plan on implementing is a "PRONUNCIATION
RECORDING EXTENSION' .I have made a few UI Mockups in my proposal, I would
like the feedback and suggestion from the WMF Design community
The link to my proposal: https://www.mediawiki.org/wiki/User:Rahul21/Gsoc
Thank You
whoops. sending fail...
---------- Forwarded message ----------
From: <design-owner(a)lists.wikimedia.org>
Date: 26 Apr 2013 08:46
Subject: Re: [Design] Left nav/right nav
To: <jdlrobson(a)gmail.com>
Cc:
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected in error, contact the mailing list owner at
design-owner(a)lists.wikimedia.org.
---------- Forwarded message ----------
From: Jon Robson <jdlrobson(a)gmail.com>
To: "A list for the design team." <design(a)lists.wikimedia.org>
Cc:
Date: Fri, 26 Apr 2013 08:46:08 +0100
Subject: Re: [Design] Left nav/right nav
Raging hatred is for having 2 places for menus. History has shown us (user
testing) that secondary menus are not discoverable. People always look in
the hamburger first (or don't even find that!!) That said a user button
makes sense if it takes a user to a profile page.
I'm mostly worried about moving things from the left menu to another menu
and having a second menu. Somehow even though login, watch list and uploads
belong to a user they are a site activity in some ways and I'd still prefer
to see them in the left menu. To me a profile would best serve access to
user page, stats and user talk page but not incorporate the other things.
Having 2 menus also makes the user have to think is that in x menu or y
menu?
"I don't understand. When I press our current hamburger, the page moves to
the right and my finger is over the Home button..." That's what 24 hrs
without sleep does to you. :) I can't articulate what it is about the
Facebook app and wiki right menu prototype I don't like but this is not in.
Just something feels unnatural about it. In terms of fb it could be the
inconsistency...on private messages hitting info hides the button and
leaves hamburger in place but doesn't do this for news feed. It may however
be the fact the right user menu is just not how I use Facebook and contains
features I see as useless. The search on the left menu in Facebook serves
the exact same purpose.
I'd really push us to leave the left menu as it is (with some visual
separation) and think of the user button as more of a profile page then a
place to find features. Where watch star goes is another question.
In terms of fixed positioning the only way to do this reliably and nicely
(and then only if JavaScript is enabled) is to use something like iscroll
and reimplement native browser scrolling.
On 25 Apr 2013 20:30, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote:
> That's more like it ;)
> Also, I'd squeeze in a few most recent notifications in there when we have
> Echo.
>
>
> On 04/25/2013 12:11 PM, Maryana Pinchuk wrote:
>
> You're right, Vibha; a picture is worth a thousand words :)
>
> Jon, ignoring the specific elements of what's in the "me" menu (all just
> placeholders at this point), does my scribbling below make more sense
> conceptually? Despite the "nav" in the title, the story card actually
> leaves implementation pretty open:
> https://mingle.corp.wikimedia.org/projects/mobile/cards/579. I can
> clarify in the title of the card and the A.C. that this should be an
> overlay, not a nav. Does that address some of your concerns?
>
>
> [image: Inline image 1]
>
>
> On Thu, Apr 25, 2013 at 11:32 AM, Vibha Bamba <vbamba(a)wikimedia.org>wrote:
>
>> At this point we should be doing this at a whiteboard.
>> There are some legitimate concerns but text is hardly a medium to improve
>> ideas =]
>>
>>
>> On Thu, Apr 25, 2013 at 11:21 AM, Maryana Pinchuk <
>> mpinchuk(a)wikimedia.org> wrote:
>>
>>> On Thu, Apr 25, 2013 at 10:39 AM, Jon Robson <jrobson(a)wikimedia.org>wrote:
>>>
>>>> I'm beginning to exhibit raging hatred of the right nav concept...
>>>>
>>>> Firstly.. Ergg. two settings is confusing (site and user) - they
>>>> should be the same page and there is no reason why they can't be. It
>>>> would be great if when logged in the settings page morphed from device
>>>> specific to user specific. Would be great to be able to activate alpha
>>>> on all my devices.
>>>>
>>>> In terms of a right nav, the more I think about it and having played
>>>> with a prototype I knocked up, the more I think a right nav is bad.
>>>> Although it seems to be becoming an established pattern it seems like
>>>> an easy option that in my opinion is badly implemented. We can do
>>>> better and should lead by example. For one I never touch the Facebook
>>>> one... it just doesn't come natural. I also don't like the idea of 2
>>>> menus. I wonder if we could envision 2 stacked menus that can be
>>>> toggled between and persist when selected.
>>>>
>>>> To quote
>>>> http://www.upassoc.org/upa_publications/jus/2011august/faulkner2.html
>>>> "... Kingsburg and Andre carried out two studies with 16 users and
>>>> found in both of their studies that selection from a left-hand menu
>>>> was faster than from a right-hand menu (2004). However, their research
>>>> also showed that selections were best done from the same panel,
>>>> whether that was on the right or left. Thus it is better to have a
>>>> single design, either on the left or the right, rather than a mixed
>>>> navigational method that requires the user to select from both left
>>>> and right panels (Kingsburg & Andre, 2004). This is hardly surprising
>>>> and is both predicted and supported by Fitts’ Law. (1954)."
>>>>
>>>> The thing that bugs me most is that when you move your finger over the
>>>> left hamburger button and press it the page moves to the left. Your
>>>> finger is still above the button. This doesn't apply to the right
>>>> menu. Your finger is now above something else. This to me is very
>>>> jarry and always feels icky.
>>>
>>>
>>>> It still leaves the question of where things such as watch star, talk
>>>> page link, edit, move and delete buttons go.
>>>> The bottom would make sense for an app, but position fixed is buggy in
>>>> the majority of current mobile browsers and we will need a fallback of
>>>> some sort.
>>>>
>>>
>>> Is it just the "nav" part that bothers you, and not so much the
>>> "right" and "my stuff" part? What if we had a little person icon to the
>>> right of the search bar, and tapping that opened an overlay with pretty
>>> visualizations of your recent editing and uploading activity, as well as
>>> links to your watchlist and talk page? *That's* what I ultimately want
>>> to work toward; in my mind, the nav part was always just a stepping stone,
>>> but maybe we don't actually need that stepping stone and can just go
>>> directly to (sneakily) beginning work on a totally new, totally rad mobile
>>> userspace :)
>>>
>>> --
>>> Maryana Pinchuk
>>> Associate Product Manager, Wikimedia Foundation
>>> wikimediafoundation.org
>>>
>>> _______________________________________________
>>> Design mailing list
>>> Design(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/design
>>>
>>>
>>
>> _______________________________________________
>> Design mailing list
>> Design(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/design
>>
>>
>
>
> --
> Maryana Pinchuk
> Associate Product Manager, Wikimedia Foundation
> wikimediafoundation.org
>
>
> _______________________________________________
> Design mailing listDesign@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/design
>
>
>
> _______________________________________________
> Design mailing list
> Design(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
>
commonElements (one of the screen stylesheets for both Monobook and
Vector) has:
a:hover, a:focus {
text-decoration: underline;
}
Do you think it makes sense to turn this underline off for all
a.mw-ui-buttons (Agora buttons using an a element)?
We're doing this for GuidedTour buttons (e.g.
https://commons.wikimedia.org/wiki/File:Guiders-Agorastyle.png), but I
thought it might be of broader use.
Thanks,
Matt Flaschen
I'm beginning to exhibit raging hatred of the right nav concept...
Firstly.. Ergg. two settings is confusing (site and user) - they
should be the same page and there is no reason why they can't be. It
would be great if when logged in the settings page morphed from device
specific to user specific. Would be great to be able to activate alpha
on all my devices.
In terms of a right nav, the more I think about it and having played
with a prototype I knocked up, the more I think a right nav is bad.
Although it seems to be becoming an established pattern it seems like
an easy option that in my opinion is badly implemented. We can do
better and should lead by example. For one I never touch the Facebook
one... it just doesn't come natural. I also don't like the idea of 2
menus. I wonder if we could envision 2 stacked menus that can be
toggled between and persist when selected.
To quote http://www.upassoc.org/upa_publications/jus/2011august/faulkner2.html
"... Kingsburg and Andre carried out two studies with 16 users and
found in both of their studies that selection from a left-hand menu
was faster than from a right-hand menu (2004). However, their research
also showed that selections were best done from the same panel,
whether that was on the right or left. Thus it is better to have a
single design, either on the left or the right, rather than a mixed
navigational method that requires the user to select from both left
and right panels (Kingsburg & Andre, 2004). This is hardly surprising
and is both predicted and supported by Fitts’ Law. (1954)."
The thing that bugs me most is that when you move your finger over the
left hamburger button and press it the page moves to the left. Your
finger is still above the button. This doesn't apply to the right
menu. Your finger is now above something else. This to me is very
jarry and always feels icky.
It still leaves the question of where things such as watch star, talk
page link, edit, move and delete buttons go.
The bottom would make sense for an app, but position fixed is buggy in
the majority of current mobile browsers and we will need a fallback of
some sort.
On Thu, Apr 25, 2013 at 5:57 PM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:
> On Apr 24, 2013, at 2:37 PM, Juliusz Gonera <jgonera(a)wikimedia.org> wrote:
>
>> My only concern about the right nav is that we might be moving too many things there. I think that people might be confused by not seeing e.g. Settings after tapping the hamburger (the mingle card mentions it in the right nav). Also, settings are currently tied to the device, not the user.
>
> I had the same hesitation with settings, actually. I think you're right that the way we use settings currently is more like "site-wide settings" than "my personal preferences" and thus belongs in the left nav. But at some future date, we could also add personal user preferences to the right nav :)
https://www.mediawiki.org/wiki/Accessibility has a list of "People and
organizations working on MediaWiki accessibility" including Sami
Mubarak, who works on the accessibility of MediaWiki for the blind (in
Arabic). I've cc'd Sami.
Hope this helps!
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
On 04/24/2013 03:17 PM, Brion Vibber wrote:
> Please note that "screen readers" and "readers without JavaScript" aren't
> in any way the same thing -- modern screen readers hook into "real
> browsers" like IE, Safari, Chrome, and Firefox and JavaScript runs just
> great in them.
>
> Serious accessibility concerns should really be referred to someone who's
> an expert... do we have anybody on staff or volunteer who has real, direct,
> current experience with vision-impaired users and their needs?
>
> -- brion
>
>
> On Wed, Apr 24, 2013 at 11:51 AM, Pau Giner <pginer(a)wikimedia.org> wrote:
>
>>>
>>> Also, did you think of the accessibility issues in your solution?
>>
>>
>> First, I want to clarify that the prototype was made just to communicate
>> the idea in terms of interaction. The The implementation is just a quick
>> hack to simulate this interaction.
>>
>> For a production implementation I can image the whole list of languages to
>> be sent to the client, and then, the list being shortened by Javascript.
>> For those users without Javascript (from screen-readers, to Search engine
>> crawlers) the same list of links they receive now will be available for
>> them.
>>
>> In any case, developers could provide even better strategies to solve that.
>> As an interaction designer I just wanted to share the idea to collect
>> possible concerns with the interaction proposed, to be fixed in next
>> iterations of the designs before development effort is made.
>>
>>
>>
>>
>> On Sat, Apr 20, 2013 at 2:04 AM, Mathieu Stumpf <
>> psychoslave(a)culture-libre.org> wrote:
>>
>>> Also, did you think of the accessibility issues in your solution? Here I
>>> especialy think of people with view disabilities, for who js often mean
>>> no way to get the content, while a long list of hyperlinks is
>>> manageable.
>>>
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
