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.
Hi Steven
On Tue, Jul 29, 2014 at 1:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Yes, I'm sure there will be some teething problems but right now I think getting our teams using standard UI elements and site consistency should be the top priority.
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.
I'm working on a fix as we speak.
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.
Can you give some example pages of this?
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.
I will let designers comment on that
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):
Please please please someone find a way to auto-update this. This is supposed to be a living style guide and that's embarrassing :) Any takers?
On a side note: whether we decide to stick with the design or not, we only now need to change it in one place and I think that's awesome.
PS. Please make mediawiki ui checkboxes happen: https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have BetaFeatures, core and other extensions using the same checkbox element!
On Tue, Jul 29, 2014 at 5:43 PM, Jon Robson jdlrobson@gmail.com wrote:
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.
Can you give some example pages of this?
Login form, which has a checkbox. You can also tab through any page until you get to something that's not a text field. With the text field blue bar, blue outline glow, and the hover state for mw.ui buttons, we've three wildly different indicators going on.
The simple fix here is to revert everything to use the normal blue outline, which is way less distracting.
https://gerrit.wikimedia.org/r/150464 Fixes captcha PS. Are we aware account creation is impossible without JavaScript on desktop (on mobile it is fine..)..?
On Tue, Jul 29, 2014 at 5:43 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Steven
On Tue, Jul 29, 2014 at 1:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Yes, I'm sure there will be some teething problems but right now I think getting our teams using standard UI elements and site consistency should be the top priority.
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.
I'm working on a fix as we speak.
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.
Can you give some example pages of this?
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.
I will let designers comment on that
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):
Please please please someone find a way to auto-update this. This is supposed to be a living style guide and that's embarrassing :) Any takers?
On a side note: whether we decide to stick with the design or not, we only now need to change it in one place and I think that's awesome.
PS. Please make mediawiki ui checkboxes happen: https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have BetaFeatures, core and other extensions using the same checkbox element!
Also https://gerrit.wikimedia.org/r/150465
In terms of checkbox glow, that goes away when merging the mw-ui-checkbox patch.
I'd rather not do any reverts the process so far has already been painful and I think it would be better to put up with pain and work towards a long term solution then worry about more short term inconsistencies.
On Tue, Jul 29, 2014 at 6:36 PM, Jon Robson jdlrobson@gmail.com wrote:
https://gerrit.wikimedia.org/r/150464 Fixes captcha PS. Are we aware account creation is impossible without JavaScript on desktop (on mobile it is fine..)..?
On Tue, Jul 29, 2014 at 5:43 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Steven
On Tue, Jul 29, 2014 at 1:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Yes, I'm sure there will be some teething problems but right now I think getting our teams using standard UI elements and site consistency should be the top priority.
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.
I'm working on a fix as we speak.
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.
Can you give some example pages of this?
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.
I will let designers comment on that
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):
Please please please someone find a way to auto-update this. This is supposed to be a living style guide and that's embarrassing :) Any takers?
On a side note: whether we decide to stick with the design or not, we only now need to change it in one place and I think that's awesome.
PS. Please make mediawiki ui checkboxes happen: https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have BetaFeatures, core and other extensions using the same checkbox element!
-- Jon Robson
On Tue, Jul 29, 2014 at 6:43 PM, Jon Robson jdlrobson@gmail.com wrote:
I'd rather not do any reverts the process so far has already been painful and I think it would be better to put up with pain and work towards a long term solution then worry about more short term inconsistencies.
Sure, I'm all for followup patches rather than reverts. Improve what can be improved, and remove what can't. But the current forms are a mess. The usability and aesthetics of login and signup directly impact our highest priorities as an organization, so it's not okay to let them degrade in the name of hypothetical future improvements.
On Tue, Jul 29, 2014 at 7:03 PM, Steven Walling swalling@wikimedia.org wrote:
Sure, I'm all for followup patches rather than reverts. Improve what can be improved, and remove what can't. But the current forms are a mess. The usability and aesthetics of login and signup directly impact our highest priorities as an organization, so it's not okay to let them degrade in the name of hypothetical future improvements.
I agree we have to be wary about consistency. I'm not sure putting these kinds of changes on the release train incrementally is the way to go -- perhaps having a test instance in Labs run a WIP changeset or branch til we're happy with it, including things like RTL testing?
We do have a bit more time since the release train is slowing down over the Wikimania period, AIUI.
With that said, kudos for moving this forward :)
Erik
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Flow doesn't use overrides on top of mediawiki.ui (except for mw-ui-button, which only started recently). We wrote all mw-ui components independently of Core, using a flow-ui prefix -- including a rewrite of mw-ui-button, which I felt had become too messy and confusing. When I felt that the flow-ui versions had reached a certain level of maturity, I'd put them for review into Core's gerrit as mw-ui components.
On Tue, Jul 29, 2014 at 11:16 PM, Erik Moeller erik@wikimedia.org wrote:
I agree we have to be wary about consistency. I'm not sure putting these kinds of changes on the release train incrementally is the way to go -- perhaps having a test instance in Labs run a WIP changeset or branch til we're happy with it, including things like RTL testing?
This is specifically the reason I was using Flow as the testbed to develop and iterate upon the mw-ui components. However, I think my team jumped the gun on putting this into Core without fully testing all of the use cases. I take responsibility for this, as I should have been more careful to a) include i18n people in the design mocks, and b) thoroughly test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit, to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language), before approving a merge to Core. For these mediawiki.ui design goals to succeed, we'll need to make sure we have our primary bases covered via these teams.
--Shahyar
On Tue, Jul 29, 2014 at 10:08 PM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
This is specifically the reason I was using Flow as the testbed to develop and iterate upon the mw-ui components. However, I think my team jumped the gun on putting this into Core without fully testing all of the use cases. I take responsibility for this, as I should have been more careful to a) include i18n people in the design mocks, and b) thoroughly test any current uses of affected mw-ui components being moved to Core.
In this case, it's not just any one person's process failure. Jon did come to Matt and I, we also didn't fully realize the implications and test things properly. In the meantime, we have plenty of time to clean up some things, since it doesn't look like this will go out with 1.24wmf15? After that release to the wikis this week, deployments will get frozen until after Wikimania.
Going forward, I think we will need to shift from a single +2 in gerrit, to
a +1 from several teams (perhaps Flow, Growth, Mobile, and Language), before approving a merge to Core. For these mediawiki.ui design goals to succeed, we'll need to make sure we have our primary bases covered via these teams.
Something like this would be good for a shared library. In our retrospectives (notes at Growth/Retrospectives on mediawiki.org) we already committed to giving people a heads up about large mediawiki.ui changes before we submit them, so that y'all can comment.
Yeah the input case was a kind of weird one as there was undocumented use of mw-ui-input throughout mediawiki in Special:Search and Special:UserLogin (it was in the less file and in usage but not in the style guide). May has suggested linking to live examples in future which I think will help with this.
I think as a rule we should all get into the habit of making MediaWiki ui the de facto place for new components and ensuring documentation of when and how to use is kept to standards. I like the idea of each change requiring a +1 from the main teams that use it (which I think are Flow, Growth and Mobile correct me if wrong). e.g. +3 :) I'm happy to see mobile, Flow and growth caring about the same problems and things getting merged more rapidly then we have done previously. I'm keen to keep this momentum.
Maybe its worth getting together people not going to Wikimania and getting mw-ui-input styling resolved in a way that makes everyone happy and keeps the solution generalised and consistent ?
We may also want to consider a beta concept of mediawiki ui that allows us to hide experimental styling behind additional modifier classes. I'm keen for teams to rapidly prototype and experiment with new design ideas but to do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button On 29 Jul 2014 22:08, "Shahyar Ghobadpour" sghobadpour@wikimedia.org wrote:
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Flow doesn't use overrides on top of mediawiki.ui (except for mw-ui-button, which only started recently). We wrote all mw-ui components independently of Core, using a flow-ui prefix -- including a rewrite of mw-ui-button, which I felt had become too messy and confusing. When I felt that the flow-ui versions had reached a certain level of maturity, I'd put them for review into Core's gerrit as mw-ui components.
On Tue, Jul 29, 2014 at 11:16 PM, Erik Moeller erik@wikimedia.org wrote:
I agree we have to be wary about consistency. I'm not sure putting these kinds of changes on the release train incrementally is the way to go -- perhaps having a test instance in Labs run a WIP changeset or branch til we're happy with it, including things like RTL testing?
This is specifically the reason I was using Flow as the testbed to develop and iterate upon the mw-ui components. However, I think my team jumped the gun on putting this into Core without fully testing all of the use cases. I take responsibility for this, as I should have been more careful to a) include i18n people in the design mocks, and b) thoroughly test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit, to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language), before approving a merge to Core. For these mediawiki.ui design goals to succeed, we'll need to make sure we have our primary bases covered via these teams.
--Shahyar
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
A few small issues…
- The Vform button doesn't seem to have any vertical padding - the create account button on the login page bottom hover bezel is weirdly thin and inconsistent - checkbox isn't mv.ui style yet even though its appearing in the living style guide
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Tue, Jul 29, 2014 at 11:07 PM, Jon Robson jrobson@wikimedia.org wrote:
Yeah the input case was a kind of weird one as there was undocumented use of mw-ui-input throughout mediawiki in Special:Search and Special:UserLogin (it was in the less file and in usage but not in the style guide). May has suggested linking to live examples in future which I think will help with this.
I think as a rule we should all get into the habit of making MediaWiki ui the de facto place for new components and ensuring documentation of when and how to use is kept to standards. I like the idea of each change requiring a +1 from the main teams that use it (which I think are Flow, Growth and Mobile correct me if wrong). e.g. +3 :) I'm happy to see mobile, Flow and growth caring about the same problems and things getting merged more rapidly then we have done previously. I'm keen to keep this momentum.
Maybe its worth getting together people not going to Wikimania and getting mw-ui-input styling resolved in a way that makes everyone happy and keeps the solution generalised and consistent ?
We may also want to consider a beta concept of mediawiki ui that allows us to hide experimental styling behind additional modifier classes. I'm keen for teams to rapidly prototype and experiment with new design ideas but to do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button On 29 Jul 2014 22:08, "Shahyar Ghobadpour" sghobadpour@wikimedia.org wrote:
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Flow doesn't use overrides on top of mediawiki.ui (except for mw-ui-button, which only started recently). We wrote all mw-ui components independently of Core, using a flow-ui prefix -- including a rewrite of mw-ui-button, which I felt had become too messy and confusing. When I felt that the flow-ui versions had reached a certain level of maturity, I'd put them for review into Core's gerrit as mw-ui components.
On Tue, Jul 29, 2014 at 11:16 PM, Erik Moeller erik@wikimedia.org wrote:
I agree we have to be wary about consistency. I'm not sure putting these kinds of changes on the release train incrementally is the way to go -- perhaps having a test instance in Labs run a WIP changeset or branch til we're happy with it, including things like RTL testing?
This is specifically the reason I was using Flow as the testbed to develop and iterate upon the mw-ui components. However, I think my team jumped the gun on putting this into Core without fully testing all of the use cases. I take responsibility for this, as I should have been more careful to a) include i18n people in the design mocks, and b) thoroughly test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit, to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language), before approving a merge to Core. For these mediawiki.ui design goals to succeed, we'll need to make sure we have our primary bases covered via these teams.
--Shahyar
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Also I noticed
- The new input indicator is using a different blue ( I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=69040 ). It was never spec'd! - When you stack mw-ui-input-large and plain mw-ui-input , the left margin indents don't match, see at http://tools.wmflabs.org/styleguide/desktop/section-1.html . The text input and textarea in Flow "Start a new topic" are aligned.
On Mon, Aug 18, 2014 at 1:04 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
A few small issues…
- The Vform button doesn't seem to have any vertical padding
- the create account button on the login page bottom hover bezel is
weirdly thin and inconsistent
- checkbox isn't mv.ui style yet even though its appearing in the
living style guide
On Tue, Jul 29, 2014 at 11:07 PM, Jon Robson jrobson@wikimedia.org wrote:
I like the idea of each change requiring a +1 from the main teams that use it (which I think are Flow, Growth and Mobile correct me if wrong).
Yeahhh, that would definitely be worth considering – I just noticed this change show up on the mobile site, and it has a few mobile-specific bugs that need to get ironed out (I reported the issues on BZ: https://bugzilla.wikimedia.org/show_bug.cgi?id=69724).
Always good to get at least one MFE engineer's eyes on any change likely to affect mobile before it gets merged; it's either that or the much more ambitious goal of getting every WMF engineer to remember to test user-facing changes vigorously on phones and tablets (which I do hope we'll get to one day...) ;)
e.g. +3 :) I'm happy to see mobile, Flow and growth caring about the same problems and things getting merged more rapidly then we have done previously. I'm keen to keep this momentum.
Maybe its worth getting together people not going to Wikimania and getting mw-ui-input styling resolved in a way that makes everyone happy and keeps the solution generalised and consistent ?
We may also want to consider a beta concept of mediawiki ui that allows us to hide experimental styling behind additional modifier classes. I'm keen for teams to rapidly prototype and experiment with new design ideas but to do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button On 29 Jul 2014 22:08, "Shahyar Ghobadpour" sghobadpour@wikimedia.org wrote:
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling swalling@wikimedia.org wrote:
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.
Flow doesn't use overrides on top of mediawiki.ui (except for mw-ui-button, which only started recently). We wrote all mw-ui components independently of Core, using a flow-ui prefix -- including a rewrite of mw-ui-button, which I felt had become too messy and confusing. When I felt that the flow-ui versions had reached a certain level of maturity, I'd put them for review into Core's gerrit as mw-ui components.
On Tue, Jul 29, 2014 at 11:16 PM, Erik Moeller erik@wikimedia.org wrote:
I agree we have to be wary about consistency. I'm not sure putting these kinds of changes on the release train incrementally is the way to go -- perhaps having a test instance in Labs run a WIP changeset or branch til we're happy with it, including things like RTL testing?
This is specifically the reason I was using Flow as the testbed to develop and iterate upon the mw-ui components. However, I think my team jumped the gun on putting this into Core without fully testing all of the use cases. I take responsibility for this, as I should have been more careful to a) include i18n people in the design mocks, and b) thoroughly test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit, to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language), before approving a merge to Core. For these mediawiki.ui design goals to succeed, we'll need to make sure we have our primary bases covered via these teams.
--Shahyar
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 08/18/2014 07:44 PM, Maryana Pinchuk wrote:
Always good to get at least one MFE engineer's eyes on any change likely to affect mobile before it gets merged; it's either that or the much more ambitious goal of getting every WMF engineer to remember to test user-facing changes vigorously on phones and tablets (which I do hope we'll get to one day...) ;)
It's Jon's change (https://gerrit.wikimedia.org/r/#/c/149173/). However, I do respect your point about testing on mobile.
Matt Flaschen
Yeh that was my fault. The issue with MobileFrontend is there are various places, login form included that monkey patch core functionality. One of my goals this year is to eradicate those, so styling for mobile becomes less difficult. I've submitted a patch to fix that [1]. Echo is another one and I'm working with BSitu to sort this out.
This bug [2]] is also another great example of where mobile is currently doing its own thing and not using MediaWiki UI where it possibly should be.
/me imagines a situation where all the teams put their rings together and become code merging power rangers
[1] https://gerrit.wikimedia.org/r/154979 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=69487
On Mon, Aug 18, 2014 at 5:10 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/18/2014 07:44 PM, Maryana Pinchuk wrote:
Always good to get at least one MFE engineer's eyes on any change likely to affect mobile before it gets merged; it's either that or the much more ambitious goal of getting every WMF engineer to remember to test user-facing changes vigorously on phones and tablets (which I do hope we'll get to one day...) ;)
It's Jon's change (https://gerrit.wikimedia.org/r/#/c/149173/). However, I do respect your point about testing on mobile.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Jul 29, 2014 at 6:36 PM, Jon Robson jdlrobson@gmail.com wrote:
PS. Are we aware account creation is impossible without JavaScript on desktop (on mobile it is fine..)..?
I just created "User:Test user 239f23f0" with JavaScript disabled in Safari. However, it looks like there's a bug where, if you have JS off and you hit Enter instead of clicking the submit button, you get sent to search. Ugh. Filing now...