[Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

David Levy lifeisunfair at gmail.com
Sat Jun 5 05:30:12 UTC 2010


[replying here and at
http://usability.wikimedia.org/wiki/Opinion_Language_Links]

Howie Fung wrote:

> First, some background on the problem we're addressing and the design
> principle that we used.  Every situation is unique, but in the case of
> the interwikilinks, we believe the sheer number of language links,
> especially within the context of an information-heavy page, makes users
> "numb" to the list.

I regard this as an unreasonable assumption.

In my experience/observation, readers saw the links and recognized
them as a list of articles in various languages.  Most didn't wish to
view such articles, so they paid no further attention to the list
until such time as they did.  (No harm done.)  Meanwhile, users
wishing to view articles in other languages (a small percentage, but a
large number in absolute terms) knew exactly where to look.

To equate this unusual type of list with large blocks of text in
general (without any data to demonstrate the principle's
applicability) is to completely ignore context.

> When people see large collections of things, they tend to group them all
> together as one object and not identify the individual parts that make
> the whole. As the number of items in the list decreases the likelihood
> of a person identifying the individual items increases. This is similar
> to how viewing a traffic jam appears as a long line of generic vehicles,
> while seeing just a few cars driving down the road might be comprehended
> in more granular detail (a motorcycle, a truck and a sports car).

This analogy fails to consider a very important distinction.

Unlike the motor vehicles, one (or a small number) of the links on the
list are meaningfully different from the user's perspective.  To a
reader of Japanese, the 日本語 link stands out in much the same way that
an ice cream van would stand out in the aforementioned traffic jam.
The other links, being foreign to this particular user, do not compete
for attention (and therefore are less of a distraction than the random
cars surrounding the ice cream van are).

> While we did not explicitly test for this during our usability studies
> (e.g., it wasn't included as a major design question), we did exercise
> judgement in identifying this as a problem, based partly on the applying
> the above design principle to the site, partly on the data.

Said data indicated only that the interwiki links were used relatively
infrequently.  Apparently, there is absolutely no data suggesting that
the full list's display posed a problem.  Rather, this is a hunch
based upon the application of a general design principle whose
relevance has not been established.

Aryeh Gregor: You cited the importance of data (and the systematic
analysis thereof).  In light of this explanation, what is your opinion
now?

> A more effective approach would be to balance the two, by showing just
> enough links to clearly illustrate the meaning of the list.  So our
> proposal is to show a list of, say, 5 languages with a "more" link.  We
> think that a list of 5 languages should be sufficient to communicate to
> the user that there are other language versions available.  If the
> language they want is not on the list, they may click "more" to see the
> full list.

If the language that the user seeks is not visible, why do you assume
that he/she will recognize the list's nature?

Imagine seeing the following on a page full of similarly unintelligible text:

Ectbadi
Feskanalic
Ibsterglit
Kreviodeil
Tionevere
> Straknaj 6 tak

Would you recognize the first five items as languages and the last as
"Show 6 more"?

Compare the above to this:

Bacruhy
Ectbadi
English
Feskanalic
Ibsterglit
Kreviodeil
Nuprevnu
Ootredi
Rozlovatom
Tionevere
Zidentranou

And keep in mind that the above allows for the use of Ctrl-F to find
"English" on the page.

> There are numerous ways we can populate the list of 5.  The simplest way
> is to populate based on the current order, but we can also do it based
> on size of the wiki, browser language, geo IP, etc.

Browser language and location detection are the best of the above
options, but they're far from flawless.  It's been explained that
there are reasons for speakers of some languages to set their browsers
to other languages.  Location detection is not entirely reliable and
only enables en educated guess as to the language that someone speaks.

To me, all of this comes across as a manufactured problem in search of
a solution (while the initial change was a solution in search of a
problem).

> Our proposal is to go with something simple for now, and then continue
> to explore options for greater customization.

Or you could simply restore the one-line code modification that
provided the default behavior requested by the community (pending
evidence that an alternative setup is beneficial).

David Levy



More information about the foundation-l mailing list