Maybe it's just me, but the new disabled checkbox doesn't look disabled to
me:
https://tools.wmflabs.org/styleguide/desktop/section-5.html
The normal convention for making a form element disabled is to make it
faded out (<100% opacity), not giving it a gray fill.
I have no idea where this design came from or who is responsible for it,
but I was wondering if the design team could revisit it.
Thanks!
Ryan Kaldari
Hi all,
In the interest of closer collaboration, Jon and Matt have merged a patch
to upstream new mw-ui-input styles, which I believe originated in Flow.
It's at https://gerrit.wikimedia.org/r/#/c/149173/
I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion. However, with the new input styles going out
on desktop search, log in, and create account there are some design issues
we need to resolve.
1. This appears to have caused a regression, where the CAPTCHA input
field on create account is not styled correctly. It's now way too small for
the container.
2. We now have multiple indicator styles showing up. In form fields, the
blue bar on the left appears. On elements like page links and checkboxes,
the softer blue outline appears. This mixed experience is distracting.
3. The left-aligned blue bar is way too close to the cursor, and makes
it harder to see where it is. In an RTL language like Hebrew, the blue bar
overlaps entirely with the cursor.
You can see all of these by checking out the relevant forms on Beta Labs
right now. You can see the previous forms on English Wikipedia, or via the
style guide (which hasn't been updated yet):
http://tools.wmflabs.org/styleguide/desktop/section-3.html
Overall, the issues identified lead me to believe this new input indicator
is the wrong way to go for now. This is particularly true when you consider
that previously one input indicator was applied to all elements
consistently, and with the new style you see both the blue outline and the
new in-field indicator depending on which element type you're selecting.
I'm okay updating form-by-form with mediawiki.ui, but the forms themselves
cannot be sloppy like this.
On a related issue, but not caused by the latest updates: we need to sort
out what the type styles are for forms and buttons. Right now I am getting
the system font of Lucida Grande. That doesn't appear to meet the spec,
according to the Trello card mocks like https://trello.com/c/8FOi1X1x and
https://trello.com/c/4TfdOik8. Let's update so at least we're using the
plain sans-serif, so the user is not getting a mix of different sans-serifs
on one form.
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
tldr: Help me find a way forward to get the inadequacies of MediaWiki
UI in front of people and get those issues addressed so we have a more
consistent MediaWiki;
####
I wrote a patch which applies MediaWiki UI everywhere and got merged [1].
It highlights lots of issues [2] with it in existing form.
I've enabled it by default on MobileFrontend for mobile pages [3],
since most pages didn't load any styles by default for desktop special
pages.
I'm getting early indication this is a useful technique as already I'm
hearing issues about certain pages from Matt Flaschen.
I would thus like to find a way to get this global enabled safely in a
desktop environment. My hunch is that if we make these issues more
visible to developers, designers and product owners, on the long term
we will get much more consistency.
There are 4 ways we can do this desktop enabling:
1) Create a beta feature that turns the styles on. e.g. UI refresh
2) Enable it on betalabs, so we are constantly reminded about the
brokenness. e.g. https://gerrit.wikimedia.org/r/154972
3) Run on a separate test instance.
4) Drop the global and just do it in desktop
My worry about 3 is it won't get used, bugs won't get filed. Nothing
will change.
Matt raised a valid concern about 2 in that betalabs should reflect
our code going out to production, but I personally think it is the
best place to do this and since we are only changing classes I believe
disruption will be relatively minimal.
1 has the advantage of getting us feedback from more people and for
projects to begin using it on content pages if they so wish.
4 is scary and is likely to be a bumpy ride as there are lots of
issues, although on the plus side I imagine would trigger lots of
follow up patches. It is not an approach we have ever tried in
conservative MediaWiki land :)
[1] https://gerrit.wikimedia.org/r/150635
[2] Issues:
* Certain elements have been designed for a specific use case and
don't really work outside that use case e.g. the mediawiki ui
checkboxes are too big, especially when used alongside others.
* The blue bar on the left of input fields sometimes
* We've never done an audit of forms to clarify which forms are
destructive or constructive.
* Some forms have unnecessary buttons e.g. the cancel button in
http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:ChangeEmail
* Some forms have constructive buttons instead of destructive.
* Certain elements are not featured in mediawiki ui (select elements
and radio inputs most notably)
[3] https://gerrit.wikimedia.org/r/150636
Hi,
This is a follow-up to Brandon's Wikimania talk about Winter.
Winter has an important concept of "the right rail". I like the "rail" part
of the name, because it's a nice departure from "bar", but the "right" part
is wrong for several reasons:
1. It's "left" in Arabic.
2. It can be misunderstood as "correct".
3. Most importantly, it doesn't say what is the rail for.
What is it for, really? Data, tools, info, navigation, aids, knowledge,
gallery? I don't have a strongly preferred name myself. "Tools" is pretty
close, but an infobox is not exactly a tool. Other suggestion are welcome.
I should also mention that we have a pretty similar bar (rail? column?) in
the ContentTranslation extension. It shows information about words,
translations, and tools to control the machine translation. In the Language
team we usually call it the "tools column".
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Just an idea inspired by Brandon's Wikimania talk and some discussions at
Wikidata-L: We can completely remove infobox templates. More precisely, the
templates may stay, but the code that places them in the article can be
removed.
Let me explain: Wikidata makes it possible to write an infobox without any
parameters - just {{Infobox settlement}} without any |, = and all that.
Wikidata even has a property called "infobox's main topic", a kind of
"meta-property" that can automatically identify which infobox does the
article need, so that you can simply say something like {{Infobox}}. This
is implemented in the Russian Wikipedia using
https://ru.wikipedia.org/wiki/Module:Universal_infocard , which is used on
hundreds of articles there. So it hasn't replaced the usual templates yet,
but the theoretical possibility is there.
Thus, the only thing left to the editor's discretion is where to place the
infobox.
This, however, can be handled by Winter. Winter puts infobox-like
information on the info rail*, and if we plan to be bold enough to take it
completely out of the article's prose flow, why not just remove it from the
article completely? If an article has an appropriate infobox template, it
is shown on the info rail, and that is it. (The Community will then ask for
the __NOINFOBOX__ magic word, but that's a minor thing.)
Thoughts?
* That's how I call the "right rail" until there is consensus on a better
name. See
http://lists.wikimedia.org/pipermail/design/2014-August/001897.html
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi Abbey!
The following 2 devices are on your table with current store versions
Design Team - IPOD 1
Design Team - LG Android 1
There may be an IOS update next week, Moiz can keep you posted on that.
Thanks
Vibha
----
Vibha Bamba
Senior Designer | WMF Design