https://bugzilla.wikimedia.org/show_bug.cgi?id=44394

Ori Livneh <o...@wikimedia.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |o...@wikimedia.org

--- Comment #59 from Ori Livneh <o...@wikimedia.org> ---
I think MatmaRex's patch should be merged.

It seems that everyone involved in this thread agrees that using one set
of typefaces in two isolated cases and another set of typefaces in all
other interfaces is inconsistent, and that inconsistent interfaces are
bad. So what we're debating is whether there are other factors that
recommend the font change that are significant enough to trump the cost of
the inconsistency. There were several arguments to that effect in this
thread. I'll treat each in turn.

(I took the liberty to mix and match quotes from different
individuals without attribution below.)


1) It's just temporary.

> We're working, albeit slowly, on making things more consistent

> We're testing out design ideas on a small scale and spreading them
> across the site if they've been successful; this will lead to temporary
> inconsistencies, but we're trying to make those short.

This was posted in 2013-01-27. Although the changes have moved from an
extension to core, the use of Helvetica Neue in core is still confined to
post-edit feedback and the account creation / login forms. There are plans
to expand it further, but I think we have to acknowledge that we haven't
made substantial progress here over the past seven months. We can't
credibly argue that the inconsistencies are temporary / transitional.


2) There are bigger fish to fry.

> Wikipedia is designed inconsistently anyways, and in far worse ways 
> there are far bigger fish to fry from a consistency standpoint.

Even if the assertion is true, it fails to explain why additional
inconsistencies should be tolerated. This is an appeal to hypocrisy
(http://en.wikipedia.org/wiki/Tu_quoque), a kind of logical fallacy.


3) It's not as bad as you make it sound.

> This inconsistency is easier to spot for developers rather than users
> Depending on the browser, Helvetica is likely the default sans-serif on
  those machines and is quite similar to HN.

I researched typespace consistency a little because I wanted to have an
informed position on this bug. The sources I found argued that, if anything,
using font-faces that are very similar to one another is *especially* bad:

"There's nothing wrong with having two pieces of text look the same,
only something wrong with two pieces of text that *almost* look alike but
are different enough to be distracting."
(https://tinyurl.com/typography-dos-and-donts)

Ultimately, I think that this isn't a valid argument, either. What it's
really saying is "it's not nearly as bad as you're making it sound".
Even if true, so what? It doesn't make a case for the font change.


4) It's just better.

> Simply put, it's widely accepted that Helvetica Neue reads better than
> the default sans-serif *on systems that have it*.

This could have been a valid argument if we supplied some evidence to
subtantiate the claim, but we haven't.

Ryan Kaldari denied that Helvetica Neue reads better and went on to
identify specific issues. His preferences may ultimately be subjective,
but they are clearly well-considered, and they raise the standard of
evidence that would be needed to decide the argument in favor of Helvetica
Neue.


5) It's what we tested.

> It works in its current state and deviating from that, even in a small
> way, might affect its impact. 

> In the short term, sticking with the design that was tested successfully
> is a change I support.

We've already deviated from the designs we tested in other minor ways. If
it is indeed the case that even small changes mean that all bets are off,
than all bets are already off. In other words, if the results we got from
ACUX support only the redesign *exactly* as we tested it, then the current
design is not supported by the experiment.

I reject the premise of this argument, by the way. I think it's dishonest.
Our working mental model of usability is that the login and account
creation interfaces would be improved by being made more welcoming and
less cluttered, and I attribute the positive result to our adherence to
these broad principles rather than to minute particulars. I think the
flexible approach that we took as a team when moving this redesign into
core suggests that this belief is shared by the rest of the team.



So, how do we go forward from here?

I think we should start by merging MatmaRex's patch. We've let this drag
on long enough and we've run out of excuses. By allowing this to fester
we've both undermined trust in our work and soured relationships that
could be pleasant and productive. Let's move on, really.

Second, like all of you, I propose that we continue to think about how we
could effect horizontal improvement of typefaces. The bits and pieces of
design advice that I read tonight were unanimous in recommending explicit
& specific typography over browser defaults. We shouldn't scorn MediaWiki
design conventions, but it's 2013, the web has changed, and what was
reasonable a decade ago is not necessarily reasonable today.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to