Mobile is experimenting with showing a small banner at the top of the main
page that prompts logged in editors to help a page in need of new links:
https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=beta
I think this is _great_ and started playing with it on the train with
nothing to do.
Two improvements need to be made though:
1) It's difficult to know what to link to. I wrap words which I feel should
be existing wiki pages but I pretty much have to guess or open a new window
to check those. Some kind of search interface or link validation
tool/corrector would be useful.
2) Since red links are turned off in the editor preview it can be tricky to
know whether I caused a typo or linked correctly if new to wiki text. This
is a bad first time user experience. Some kind of validation step or
feedback when I create red links in the editor itself would be useful. We
should at very least enable red links in the editor preview.
On a side note:
I really think we should give more priority to enabling new page creation
on enwiki to help those sort of experiences before continuing down this
path of encouraging new editors. People could start drafts, start pages
with photos. This seems like a really useful focus of time.
http://designatwikipedia.tumblr.com/post/62048718932/thoughts-on-humanizing…
"With humanizing articles, we have two objectives:
-Creating awareness about the editors and their interests on Wikipedia.
-Promoting connections within the community using shared interests."
The post shares some ideas and mockups and notes, "While the details are
being refined, comments on the general direction towards contributions
or alternate ideas would be super appreciated."
(By the way, after this email, I'm unsubscribing from the design list as
I prep for my sabbatical - more info at
http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071542.html
. If you need to talk about Wikimedia technical community stuff or
communication before January, please consult Quim Gil, qgil at wikimedia
dot org, or Guillaume Paumier, gpaumier at wikimedia dot org. Thanks!
Looking forward to coming back in January.)
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
In the old days (2011), the WMF had design guidelines that discussed
accessibility issues such as appropriate font sizes, use of colors, and
text contrast. These guidelines were later replaced with the Agora
guidelines (https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design)
which specify only that "We must enable access for users with impairments."
Accessibility is central to our mission as an organization and very
important to our community. In fact the en.wiki community has enacted their
own comprehensive accessibility guidelines for content:
https://en.wikipedia.org/wiki/Wikipedia:Accessibilityhttps://en.wikipedia.org/wiki/Wikipedia:Accessibility_dos_and_don'ts
Mediawiki developers also have a set of published accessibility guidelines:
https://www.mediawiki.org/wiki/Accessibility_guide_for_developers
The issue of accessibility in MediaWiki UX design has been raised numerous
times in the recent past, most commonly in regard to font sizes and colors.
I'm personally aware of it coming up at least 5 times in the past year
(Typography Refresh, Flow, Echo, Mobile, NavPopups). Rather than rehashing
the same discussions each time, I would encourage the design team to come
up with a new set of accessibility guidelines that everyone can refer to
and agree on. I would encourage stealing ideas from the en.wiki guidelines
and the WCAG guidelines (http://www.w3.org/TR/UNDERSTANDING-WCAG20/). I
would also suggest that the design team invest in a pair of scratched-up
coke-bottle glasses that each design mock-up can be tested with :)
Ryan Kaldari
> -
> > >
> > > What's the Publish/Discuss/Translate/etc blocks for? They look like
> > > navigation but don't seem to go anywhere or correspond to anything.
> >
> > They attempt to summarize the best features that MediaWiki can offer.
> > Indeed, there are no detailed product descriptions to link to, but this
> > is because we don't have them. I would say this is better than nothing.
> > Currently you either know what MediaWiki plus selected extensions can
> > offer, or you guess it by becoming a Wikipedia power user, or you need
> > to connect many pages in mediawiki.org.
>
When i read that page it makes it seem like these features are available
out of the box, which is kind of misleading. In particular claiming we have
wysiwyg editing without mentioning visual editor is extremely difficult to
install doesnt seem like a good idea.
Personally i thought the translate box meant that the mediawiki interface
is translated into many languages (something we can certainly brag about).
Overall i like the idea of the redesign that you have in the uploaded file.
> > > Bugzilla should have a prominent link. Sysadmins and other users who
> > > found bugs are not necessarily looking to 'get involved'. They found
> > > bugs and want to report them or find fixes. They're looking for a bug
> > > thing. Where is that?
>
+1 bugzilla is very important for downstream users who have bugs.
> > "Support" links to https://www.mediawiki.org/wiki/Project:Support_desk ,
> > which is where many MediaWiki sysadmins go when they have/find problems.
> > Bugzilla is not visibly featured there, and it probably should be.
Getting support is different from filing bugs.
-bawolff
<quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100">
> And surely, before WMF/"MediaWiki" tell the world that no free fonts
> of good quality exist, there will be some document detailing exactly
> why and based on what arguments/data/research the numerous free
> alternatives were all rejected? Free fonts developers are an
> invaluable resource for serving Wikimedia projects' content in all
> languages, we shouldn't carelessly slap them in their face.
I just skimmed the entire thread again, and yes, this has been requested
a few times but no one from the WMF Design team has responded with that
analysis (or if would respond with an analysis). The first time it was
requested the person was told to ask the Design list, then the next
message CC'd the design list, but no response on that point.
I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
nor it's talk page. Nor
https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography
cc'ing the Design list :)
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
This is really a UX question, not design per se.
https://gerrit.wikimedia.org/r/#/c/104926/ (an under-review change) adds
a warning if you choose a username that needs to be
reformatted/canonicalized. For example, "my username" is changed to "My
username".
It displays the warning, puts the new username ("My username") in the
box, then you have to retype your password (twice), then press enter to
confirm.
The main potential benefit, as I see it, is that if you don't like "My
username" (the reformatted version), you can choose a different username
entirely.
User experience feedback would be welcome; you can post on the change or
here.
Matt Flaschen
On Mon, Feb 17, 2014 at 12:38 PM, Steven Walling
<steven.walling(a)gmail.com>wrote:
> Sacrificing the readability and beauty of content for
> most users because there is no universally perfect solution is the kind of
> hard-line approach that limits the reach of FOSS, and ultimately undermines
> our goal of making something the entire world can use and enjoy.
I need to challenge the assertion that this is about most users. Here's my
understanding of the status quo: for prose, we currently specify the
neutral and non-descript "sans-serif". This results in the following fonts
on the default install on these platforms if I've done my homework
correctly:
* MS Windows: Arial(?)
* Mac: Helvetica
* Ubuntu/Firefox: DejaVu Sans (presumably other Linux variants are similar)
* Ubuntu/Chrome: Liberation Sans
* Android: Roboto
* iOS: Helvetica(?)
Note that the differences between Firefox and Chrome on Linux seem to stem
from Firefox using the OS standard font resolution mechanism, and Chrome
having a built-in heuristic that seems to be very heavily biased toward
Liberation Sans.
Under the new "Helvetica Neue", Helvetica, Arial, sans-serif font stack, we
get:
* MS Windows: Arial(?)
* Mac: Helvetica Neue
* Ubuntu/Firefox: Nimbus Sans L (Helvetica substitute)
* Ubuntu/Chrome: Liberation Sans (Helvetica and Arial substitute)
* Android: Roboto
* iOS: Helvetica Neue
This doesn't seem like a satisfying leap forward, given the level of
disruption.
* By our numbers[1], a plurality of our users are using MS Windows still
(and probably a majority of those using the desktop site). They got Arial
before, and they get Arial now.[2] The only way they improve their
experience is to buy Helvetica Neue or buy a product that includes
Helvetica Neue. Moreover, it's quite possible that MS Windows users will
get a crappy experience with Helvetica if they have an old Type 1 version
of it installed on their system.[3]
* It looks like this causes shift from Helvetica and Helvetica Neue on Mac
and iOS, which would seem to be to be pretty subtle. How big is the
difference on the site? I don't have access to a Mac at home, so I can't
see the difference myself, but the available screenshots don't present a
noticeable difference to me.
* If cross-platform consistency is the goal, I think this misses the mark.
In particular, Android would still be using Roboto, which has quite
different metrics than the Helvetica/Arial set of fonts. Additionally, we
still end up with a difference between our two most popular Linux browsers,
which while not as large as before, still seems unnecessary.
Here is what seems to be a reasonably well-researched article where the
author has clearly put a lot of thought into the cross-platform experience,
with the added bonus that it proposes use of free (libre) fonts:
http://www.grputland.com/2013/11/multiplatform-helvetica-like-font-stack.ht…
tl;dr: His stack still lists HelveticaNeue as the first font, but proposes
Arimo as a web font which may well look better on MS Windows. Arimo ships
with ChromeOS.
I believe it is worth more research on replacements for free and better
alternatives to Arial, because it would seem to me that it's not hard to do
better. While it's unlikely that most MS Windows users will install Arimo,
it sends a way better message if we can say "to make your Wikipedia reading
experience better, download and install the free font Arimo" than it does
to say "to make your Wikipedia experience better, please purchase Helvetica
Neue for the low low price of $29.95". Furthermore, it may be worth it to
try out the web font mechanism, and we might even be able to talk Mozilla
and/or Google into shipping a free font or two with the browser so as to
get some real install penetration with these fonts.
In general, it feels as though this iteration is centered around only
making the experience for Apple products better, while trying not to break
the experience on other platforms, which feels like a low bar. It's not
entirely clear how much hands-on effort the User Experience team has put
into Windows, Android tablets, ChromeOS, or other Linux desktops, or what
the team's goals are for those platforms. The fact that much of the
rationale for the new design centers around greater use of Helvetica Neue
specifically (which is not free, and is only available to a minority of our
users) is annoying to me, and that seems to be where a lot of the
frustration from others comes from as well.
Rob
[1]
http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm
[2] I don't have a modern system with Windows 7 or 8 on it, so I don't
know if they've switched to Segoe as the default. If so, we may be making
an unintentional downgrade to Arial with our new choice.
[3]
http://stackoverflow.com/questions/15011653/internet-explorer-automatically…