On Sun, Jun 6, 2010 at 12:14 PM, Mark Williamson <node.ue(a)gmail.com> wrote:
Aryeh, I was under the (apparently mistaken?)
impression that at
Wikipedia, the community makes the decisions
Not exactly. If the community actually made decisions, Wikipedia
would be a direct democracy, and it's not. The community does have a
large say in decisions, but it doesn't make them, in the end.
Particularly not on technical issues, which have always been
controlled by a much smaller group.
On Sun, Jun 6, 2010 at 1:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:
You're simultaneously arguing for evidence-based
decisions and explanations,
while also adding to the pile of anecdotal (or simply made-up) logic behind
the decisions ("my first guess...").
Because evidence is a great thing, but judgment is necessary too. It
would be nice if you could do everything strictly based on evidence,
but real life isn't so simple.
And you're doing it as someone with the
ability to gather actual, hard data on interlanguage link usage, which adds
a bit more annoyance.
I have no more access to click data than you do. I only have commit
access and toolserver root access, nothing else.
As far as I'm aware, nobody has properly graphed
occurrence on the English Wikipedia. The data I found querying non-redirects
in the article namespace on the English Wikipedia is available here. As
you can see, 1774000 articles have 0 interlanguage links (53%). Looking at
pages with 5 or fewer interlanguage links, it's 2948039 articles (88%).
That doesn't weight by views. We care about people's ability to use
an average page *that they actually visit*, not a page selected
uniformly at random. Some kind of view or click data is needed.
The links are placed in the sidebar, which generally
has more than enough
room to accommodate these links. The links are completely out of the way,
but still accessible to the user. While there has been some jibber-jabber
about the page layout being "psychologically free," having a few links in
the sidebar that don't overlap anything or get in the way of anything hardly
seems like it's going to cause user claustrophobia.
You can collect data from real usability studies, where people
actually sit in a room, with eye-tracking to see how much time they
waste looking at interface elements they aren't going to use. This is
not practical to do for every single interface element. Instead,
rules of thumb result from that kind of study, like "reduce the number
of interface elements". These may or may not be correct in any
particular case, but they are not jibber-jabber.
The default should be flipped. There is near-universal
agreement on this
point at this point, including from Erik Moeller. I expect this will happen
This might be a good idea. I think a solution that only showed some
of the links might be even better (although maybe not), but I'm not
strongly committed to the idea that hiding the interlanguage links
entirely is better than showing them all, if those are the only two
choices right now.
On Sun, Jun 6, 2010 at 2:37 PM, David Levy <lifeisunfair(a)gmail.com> wrote:
I'm not claiming that most users complain.
I'm noting that there are
_some_ complaints when there's anything remotely worth complaining
about (and sometimes even when there seemingly isn't).
Just because there are complaints about *many* problems, doesn't mean
there are complaints about *all* problems. Some problems draw few to
no complaints, by their nature. If every problem really did trigger
complaints, we wouldn't need usability studies -- we could find all
problems by just looking at complaints. This isn't the case.
So yes, it's true that any substantial change to
links' default behavior would have generated complaints, regardless of
whether it was a good idea. This, however, does not automatically
render said complaints invalid.
No, but it means the complaints are only worth as much as the
arguments they bring forth.
If there were evidence that the longstanding
configuration caused a
problem addressed by the change, this likely would outweigh the
complaints. There is no such evidence.
There is ample evidence that when users are presented with more
buttons to click, they take longer to find what they want and make
more mistakes. We can apply this generality to specific cases without
having to directly check it every time. In fact, we have to, what
with our lack of infinite time and money.
We frequently receive complaints from unregistered
users lacking any
meaningful degree of familiarity with the site.
Complaints like "I can't access the site" or "I can't figure out
to do X", not like "I took half a second longer to find the interface
element I was looking for than if there had been no interlanguage
links". The latter isn't even observable by users themselves, only in
usability studies. But it makes a difference, when you add it up.
Before investigating potential solutions, there should
be evidence of
a problem. I disagree with the strategy of implementing a significant
UI modification on a hunch and testing to see whether this "helped or
We don't have the budget to run a usability study on every individual
possible problem. We have to make inferences from what usability
studies we (and others) do run, and apply those to specific cases.
On Sun, Jun 6, 2010 at 2:59 PM, Tim Landscheidt <tim(a)tim-landscheidt.de> wrote:
So there is not only "evidence" to
consider, but also
"policy". We do want to emphasize: "Everyone can edit!", so
we put an "Edit" button up there, even if it might disturb
someone's mind with "clutter". Do we want to advertize:
"This article is available in 100+ languages!", so someone
when reading another article without that long list will
think about translating this article to his mother tongue?
Or maybe just say: "Awesome!"
As I mentioned before, I think this is a potentially good reason to
keep the whole list: as a form of advertising. I've never been
strongly against keeping the expanded list, I'm just addressing
specific arguments that I believe are flawed.
On Sun, Jun 6, 2010 at 9:24 PM, Andrew Garrett <agarrett(a)wikimedia.org> wrote:
I will say to be fair that the best response to what
you perceive as a
poor design choice in somebody else's code is not to revert them and
say "There, I fixed it for you. Thank me later.", but perhaps to
discuss it with them first and find a compromise.
There was a lengthy discussion about it. That the usability team
mostly chose not to participate was their decision, and shouldn't have
forestalled other developers from taking action based on it. Now, if
the original authors disagreed with the conclusion of the discussion,
then it would have been totally acceptable for them to revert the
change, *provided* that they did so in combination with a detailed
explanation of their original reasoning. Which they didn't. I've
been the only one making anything resembling a detailed defense of the
decision, and I don't even fully agree with it.