CCing the design list.
Matt Flaschen
On 11/18/2013 04:41 AM, Gerard Meijssen wrote:
> Hoi,
> In the latest hack by Magnus, he has expanded the search capability to
> Wikidata so that you will get automatically generated descriptions but also
> a link to Commons, a link to the Wikipedias and a link to the Reasonator.
>
> The last bit is extra special because it will show you information in the
> language of the Wiki with a fall back to English. At this stage Reasonator
> only works for people. (ie "is a" "human").
>
> What we would like is to have a nice logo for the Reasonator. it should
> look good as an icon in the search and it should look good on a bigger
> scale. I asked Lydia and, she may throw in a Wikidata T-shirt if she likes
> the result.
>
> I blogged about all this, [1] and, there is a link included that explains
> how to add the search capability to your Wikipedia profile.
> Thanks,
> Gerard
>
> [1]
> http://ultimategerardm.blogspot.sk/2013/11/ask-and-it-will-be-given-to-you-…
>
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
Amire recently brought up an issue with the existing styling of the
profile page [1]. Usernames in MediaWiki land are case-sensitive so
the user "Jdlrobson" is different from "jdlrobson" (yes this is
bizarre but this is the way it is).
On the profile page the design relies on the username being the
heading and being uppercase which is misleading. To add to this, to
quote Amire word for word "Furthermore, applying uppercase to any
alphabets except Latin, Cyrillic, Greek, Armenian and Georgian does
pretty much nothing. This means that for usernames in Chinese, Thai,
Hindi, Arabic and many other languages this style definition is
meaningless.
Finally, in Turkish and Azeri the letter 'i' changes somewhat
unexpectedly with the uppercase transform. It's a minor issue, but an
issue nevertheless.
"
So I've been noticing a lot of our designs use uppercase text and it
would be good to question when it is okay to use uppercase and if we
should be using it (a lot of people don't like the idea that THE
COMPUTER IS SHOUTING AT ME!)
Would be interested in your thoughts so this issue doesn't come up
again (also would be worth documenting on the upcoming style guide
[2])
[1] https://m.mediawiki.org/wiki/Special:UserProfile/Jimbo_Wales
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=56705
We had an interesting discussion in #wikimedia-mobile today. A user
came into the channel and made some comment about "nothing loads on
mobile, afaik it doesnt even allow logging in"
At first I thought he/she was talking about the app but as we talked
some more it became clear he/she hadn't realised the hamburger icon
was clickable and had assumed it was part of the search feature.
May and I tried to probe a bit more to understand whether it's a
cultural thing (e.g. maybe the hamburger icon is only recognisable in
North America/Western Europe). Alas, he/she then got very defensive
and angry and for some reason didn't want to talk about it.
He did however mention she/he wanted a help page but when I asked
where that would be discovered he went into radio silence.
I know the design team have been looking to move away from the
hamburger icon and after talking with May we reckon it might be useful
to run a few A/B tests around it to see if it becomes 'more clickable'
if
* a divider is present
* if we try effects on the icon to make it look more tappable
* If it changes to an icon other than the hamburger
It also suggests we may want to think about how we surface a help
feature to these users... putting it in the hamburger menu itself
might not be a good idea..
Most Wikimedia sites use the mediawiki default of an Arrow ↑ to backlink
from citation-contents to the superscripted number/letter.
English Wikipedia changed the default in 2006, to use a caret ^ and a
few dozen other wikis have copied that.
We'd like to examine the problems with the Arrow, to see if they can be
fixed.
We need help browser-testing and diagnosing and fixing the problem(s).
This may have strong relevancy to the Typography Update in Beta Features.
I've tried to summarize everything so far, at
https://en.wikipedia.org/wiki/Help_talk:Cite_messages#Testing_and_summary_s…
Thanks!
Quiddity
Today was the MediaWiki.ui hack day, and we briefly discussed the Vector
typography refresh that's in BetaFeatures right now.
Several people expressed frustration with the choice to make the sidebar
and personal toolbar links smaller size, as well as the grey text used
throughout. Our text size already pretty small, and frankly making links
greyed out like that violates basic Web usability.[1]
The sidebar color and sizing is a major change that keeps me from opting in
to the beta on desktop, despite the fact that I have personally used and
enjoyed a very similar font stack across wikis for months.[2] Editors use
these two toolbar areas many many times a day when editing, and we're
making their life harder with this change.
Despite the above objections, I agree with the reasoning behind the change,
which is to put content first in order of priority. Even if we use the
toolbars all the time, content comes first in the encyclopedia. So I'd like
to propose an alternative solution to this: bumping up the content text
size to 1.1em, and leaving the rest at the smaller .8 em. On Chrome and
Firefox, OSX this computes to a page content size of 14px.
I made quick gallery of what this looks like on a stub, the Main Page,
Portal:Current events, a long article, and a Talk page. It's at
http://imgur.com/a/yXVTo
If you play around with this yourself, be sure to apply the sizing only to
mw-content-text only, not the body, or else everything will blow up in
size. ;)
1. http://www.nngroup.com/articles/guidelines-for-visualizing-links/
2. https://en.wikipedia.org/wiki/User:Steven_Walling/vector.css
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
Only read this today, but I completely agree.
Ryan Kaldari wrote:
> I've noticed that the majority of designs I've seen from the design
> team in the past year have featured light grey text (frequently
> #CCCCCC) on a white background. Although I understand the need to make
> non-essential text less prominent, having text that is barely or not
> at all readable to a large percentage of the population seems like a
> bad idea. One of the main differences between designing for Wikipedia
> and designing for other sites is that Wikipedia strongly values
> accessibility. I know that the design team is very conscious of
> color-blindness in its designs, but poor vision in general is a much
> more common problem and should arguably be given more consideration
> than color-blindness.
>
> Personally, I would suggest that we avoid using light grey on white
> text or grey on grey text and try to maintain a minimum level of text
> contrast. If that doesn't seem realistic, I would at least like to see
> us avoid low-contrast text at small font sizes. What are other
> people's thoughts on this?
>
> Ryan Kaldari
Hello!
Me and May have been experimenting with different ways of finding
articles related to the one the user is currently reading. This is a
feature we are considering for the mobile app - to make it simple to
keep going through to related articles after reading the current one.
Mediawiki doesn't offer any such functionality, so we've to 'cheat'.
I have written a quick userscript to test out the different methods of
finding 'related' articles. You can enable this on your logged in
desktop english wikipedia account by:
1. Going to this page: https://en.wikipedia.org/wiki/Special:MyPage/common.js
2. Add this line to it: importScript("User:Yuvipanda/lost.js");
3. Save the page!
Now, you can go to any wikipedia article and three buttons should show
up under the title. If they don't, do a hard refresh (cmd + shift + r
in OS X), and they then should. The first button does a category based
related/random article, the second one a link based, and a third one
(when it appears) a slightly more involved link based related/random
article one. We're doing this to iterate quickly (the current stuff
took me less than an hour to build) on the various ways to determine
which related article to show.
Do take a look, click around a little and get lost, and tell us which
method you prefer!
Thanks :)
--
Yuvi Panda T
http://yuvi.in/blog
[Please CC me on answers as I'm not subscribed.]
Hi,
I plan to enable a guided bug entry form on Wikimedia Bugzilla for
newbies, to make reporting issues slightly easier. It can be seen on
http://boogs.wmflabs.org/enter_bug.cgi?product=Wikimedia&format=guided
Login: test(a)test.wmflabs
Password: testtest
Is this utterly horrible and unusable, or can I deploy it on
bugzilla.wikimedia.org without making designers scream and ignore me for
the rest of my life? The CSS isn't great (at least it *is* CSS now,
sigh), but I needed to start somewhere.
Thanks in advance,
andre
PS: Quick'n'dirty CSS recommendations are also welcome.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Agora specs[1] introduce expanded button semantics, but the "Buttons"
visuals on p. 3 don't name or explain them.
I added that image and some explication to the existing page "Patterns and
components"[2]
<mildflame on>Don't ignore existing specs just because you didn't work on
them! Update pages when designs change, don't leave them to rot and
mislead.</mildflame>
Because the semantics are changed, some current styles in mediawiki.ui
don't cleanly map:
* mw-ui-primary (the main button, e.g. [Login])
* mw-ui-constructive (an alternative, e.g. "Don't have an account? [Join
Wikipedia]" button)
The new specs distinguish continue and completion actions for the primary
button, and a constructive alternative is just a plain button.
mw-ui-primary can either remain the style for the complete form action
(changing from blue to green!) or be a deprecated synonym for a new
mw-ui-completion style, since I don't think any multi-step forms use Agora
yet. I think mw-ui-constructive becomes a deprecated no-op.
Flow's CSS uses "mw-ui-button mw-ui-text" for actions that don't appear as
a button (the two top rows).
[1] https://www.mediawiki.org/wiki/File:Agora_specs.pdf
[2]
https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_com…
--
=S Page Features engineer