I'm committed to killing the global variable $wgUseMediaWikiUIEverywhere Prateek asked me today how he could help so in case it is not clear this is how developers/designers can help.
Essentially as a first step we need to identify problems with form interfaces across MediaWiki and fix them.
1) Enable MediaWiki UI everywhere
Developers: Add $wgUseMediaWikiUIEverywhere=true into your LocalSettings Non-developers: Explore http://mwui.wmflabs.org/wiki/Main_Page or http://en.m.wikipedia.beta.wmflabs.org/ (the mobile site already enables these to be the default)
2) Navigate around the site and make a note of interfaces that look wrong. Please file bugs against them here [1] * Places where buttons are constructive when they should be destructive / progress * Take screenshots of interfaces that look cluttered/cramped. * Identify pages which do not use MediaWiki UI styles at all
3) Let's fix the bugs
4) When this is all done, we will need to engage the community/communicate this change. We might need to run a beta feature. I'm hoping Jared or Steven can oversee this. Alternatively we might just want to turn it on if we do not consider it a massive change.
[1] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component...
On Thu, Sep 4, 2014 at 4:24 AM, Jon Robson jrobson@wikimedia.org wrote:
- Enable MediaWiki UI everywhere
Developers: Add $wgUseMediaWikiUIEverywhere=true into your LocalSettings Non-developers: Explore http://mwui.wmflabs.org/wiki/Main_Page or http://en.m.wikipedia.beta.wmflabs.org/ (the mobile site already enables these to be the default)
- Navigate around the site and make a note of interfaces that look wrong.
Please file bugs against them here [1]
- Places where buttons are constructive when they should be
destructive / progress
- Take screenshots of interfaces that look cluttered/cramped.
- Identify pages which do not use MediaWiki UI styles at all
Let's fix the bugs
When this is all done, we will need to engage the
community/communicate this change. We might need to run a beta feature. I'm hoping Jared or Steven can oversee this. Alternatively we might just want to turn it on if we do not consider it a massive change.
Is there a good forum for us to engage and recommend how community members can get involved with at Step #1 ? That feels like it would give us the sense of scale and community participation from the beginning.
CC'ing Rachel to see what she thinks
--tomasz
Thanks, Jon, for continuing to keep the pressure on.
The appearance/size change for e.g. checkboxes is very noticeable, and right now it's inconsistent with other controls that are nearby, like radiobuttons and dropdowns. The first thing is to actually finish the style guide and consistently apply it. http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete right now, when can we expect an updated version, or is there another one I should be looking at?
Thanks, Erik
On Fri, Sep 5, 2014 at 2:08 PM, Erik Moeller erik@wikimedia.org wrote:
The appearance/size change for e.g. checkboxes is very noticeable, and right now it's inconsistent with other controls that are nearby, like radiobuttons and dropdowns. The first thing is to actually finish the style guide and consistently apply it. http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete right now, when can we expect an updated version, or is there another one I should be looking at?
This is a situation that's partially a consequence of how we've decided to generate the living style guide. It only reflects what is in the codebase now really, so it doesn't (and really can't) contain style guidelines for future iterations on other controls.
The best place to see proposed designs is the Trello board for mediawiki.ui (https://trello.com/b/EXtVTJxJ). When things are finalized enough on the UX side to more seriously request Jared is pushing them to Bugzilla.
Thanks Steven thats correct. The greatest strength and weakness of the LSG is the same things, we'll know when you can use something in production and when it breaks, but we can't show it "live" until its in core.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Fri, Sep 5, 2014 at 2:50 PM, Steven Walling swalling@wikimedia.org wrote:
On Fri, Sep 5, 2014 at 2:08 PM, Erik Moeller erik@wikimedia.org wrote:
The appearance/size change for e.g. checkboxes is very noticeable, and right now it's inconsistent with other controls that are nearby, like radiobuttons and dropdowns. The first thing is to actually finish the style guide and consistently apply it. http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete right now, when can we expect an updated version, or is there another one I should be looking at?
This is a situation that's partially a consequence of how we've decided to generate the living style guide. It only reflects what is in the codebase now really, so it doesn't (and really can't) contain style guidelines for future iterations on other controls.
The best place to see proposed designs is the Trello board for mediawiki.ui (https://trello.com/b/EXtVTJxJ). When things are finalized enough on the UX side to more seriously request Jared is pushing them to Bugzilla.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
We already seem very stretched and code review is slow. I would like us to exercise caution on adding new things to the styleguide. Most of the work so far has been moving existing components from repositories into core so that other teams can share their work.
I don't think we should be adding new components without delivering user value. We should be looking to build new components first as and when needed in our projects whether it be mobile, VE, Flow, Multimedia work etc..
I really would encourage us to focus on forms and the bare minimum needed to get this out into production.
Radio buttons and <select> menus seem like the missing pieces of the puzzle right now that will make the LSG seem more complete and help us push through these form designs. I'd really encourage us to focus on getting those through - are there any teams currently needing these or is this likely to be a 20% type project?
Jon
On Fri, Sep 5, 2014 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks Steven thats correct. The greatest strength and weakness of the LSG is the same things, we'll know when you can use something in production and when it breaks, but we can't show it "live" until its in core.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Fri, Sep 5, 2014 at 2:50 PM, Steven Walling swalling@wikimedia.org wrote:
On Fri, Sep 5, 2014 at 2:08 PM, Erik Moeller erik@wikimedia.org wrote:
The appearance/size change for e.g. checkboxes is very noticeable, and right now it's inconsistent with other controls that are nearby, like radiobuttons and dropdowns. The first thing is to actually finish the style guide and consistently apply it. http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete right now, when can we expect an updated version, or is there another one I should be looking at?
This is a situation that's partially a consequence of how we've decided to generate the living style guide. It only reflects what is in the codebase now really, so it doesn't (and really can't) contain style guidelines for future iterations on other controls.
The best place to see proposed designs is the Trello board for mediawiki.ui (https://trello.com/b/EXtVTJxJ). When things are finalized enough on the UX side to more seriously request Jared is pushing them to Bugzilla.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
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 09/08/2014 11:04 PM, Jon Robson wrote:
Radio buttons and <select> menus seem like the missing pieces of the puzzle right now that will make the LSG seem more complete and help us push through these form designs. I'd really encourage us to focus on getting those through - are there any teams currently needing these or is this likely to be a 20% type project?
I'm not sure these should be a blocker for rolling turning wgUseMediaWikiUIEverywhere to true.
We never said we were going to do all the controls before setting it to true. The more important goal is to be horizontally consistent (i.e. all pages use the controls that exist). This should be a focus.
Matt Flaschen
On Mon, Sep 8, 2014 at 8:04 PM, Jon Robson jdlrobson@gmail.com wrote:
We already seem very stretched and code review is slow. I would like us to exercise caution on adding new things to the styleguide. Most of the work so far has been moving existing components from repositories into core so that other teams can share their work.
I don't think we should be adding new components without delivering user value. We should be looking to build new components first as and when needed in our projects whether it be mobile, VE, Flow, Multimedia work etc..
I really would encourage us to focus on forms and the bare minimum needed to get this out into production.
I 100% agree with the above Jon.
Erik is right that the new checkboxes look weird next to the old style controls, such as on Preferences. Since we don't want to add new controls that teams don't yet need, why don't we just remove the checkboxes for now, and just focus on getting text input + button styles out the door?
Radio buttons and <select> menus seem like the missing pieces of the puzzle right now that will make the LSG seem more complete and help us push through these form designs. I'd really encourage us to focus on getting those through - are there any teams currently needing these or is this likely to be a 20% type project?
Rather than restyle more elements, let's just reduce scope rather than cause creep.
On Mon, Sep 8, 2014 at 11:36 PM, Steven Walling swalling@wikimedia.org wrote:
Erik is right that the new checkboxes look weird next to the old style controls, such as on Preferences. Since we don't want to add new controls that teams don't yet need, why don't we just remove the checkboxes for now, and just focus on getting text input + button styles out the door?
That would work for me. They (new checkboxes) are used in a few places that were actually designed for them, notably Beta Features, perhaps others? We would want to continue to explicitly apply the styles in those places.
If we can't do that, I'm with Jon that the inconsistency with other controls right next to them in a few contexts is a blocker.
Erik is right that the new checkboxes look weird next to the old style controls, such as on Preferences. Since we don't want to add new controls that teams don't yet need, why don't we just remove the checkboxes for now, and just focus on getting text input + button styles out the door?
I'm fine with this. If we want to do this we should setup a tracking bug to make mw-ui-input the default and attach all the relevant bugs. We can use the $wgUseMediaWikiUIEverywhere global for checkboxes, and then later select and radio buttons.
Reducing scope anywhere we can is great. I'm confident that once these controls become more visible in more places we will see development on MediaWiki UI speed up. .
Note there are various patches that fix a lot of issues raised in bugs that are sitting there waiting for review.
https://bugzilla.wikimedia.org/buglist.cgi?bug_severity=blocker&bug_seve...
On Tue, Sep 9, 2014 at 1:59 PM, Jon Robson jdlrobson@gmail.com wrote:
Erik is right that the new checkboxes look weird next to the old style controls, such as on Preferences. Since we don't want to add new controls that teams don't yet need, why don't we just remove the checkboxes for now, and just focus on getting text input + button styles out the door?
I'm fine with this. If we want to do this we should setup a tracking bug to make mw-ui-input the default and attach all the relevant bugs. We can use the $wgUseMediaWikiUIEverywhere global for checkboxes, and then later select and radio buttons.
Reducing scope anywhere we can is great. I'm confident that once these controls become more visible in more places we will see development on MediaWiki UI speed up. .
On 09/05/2014 05:50 PM, Steven Walling wrote:
On Fri, Sep 5, 2014 at 2:08 PM, Erik Moeller <erik@wikimedia.org mailto:erik@wikimedia.org> wrote:
The appearance/size change for e.g. checkboxes is very noticeable, and right now it's inconsistent with other controls that are nearby, like radiobuttons and dropdowns. The first thing is to actually finish the style guide and consistently apply it. http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete right now, when can we expect an updated version, or is there another one I should be looking at?This is a situation that's partially a consequence of how we've decided to generate the living style guide. It only reflects what is in the codebase now really, so it doesn't (and really can't) contain style guidelines for future iterations on other controls.
Yes, there are some small things missing from the style guide (e.g. vform stuff).
However, it's mostly complete. This means it reflects what's actually implemented.
Of course, there's always new features we want to develop, but the style guide shows what we have now.
Matt Flaschen
On 09/04/2014 07:24 AM, Jon Robson wrote:
- Navigate around the site and make a note of interfaces that look wrong.
Please file bugs against them here [1]
Also, if you think it should block the $wgUseMediaWikiUIEverywhere=true rollout, mark it as a blocker of https://bugzilla.wikimedia.org/show_bug.cgi?id=70424
Thanks,
Matt Flaschen
Jon, at the moment I'm only considering radio, toggle(currently mobile only), combo, and dropdown to be blockers. There are a lot of special and one off controls that we will no doubt need to be in order to call things complete, we'll get there, I'm confident.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Mon, Sep 8, 2014 at 10:28 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/04/2014 07:24 AM, Jon Robson wrote:
- Navigate around the site and make a note of interfaces that look wrong.
Please file bugs against them here [1]
Also, if you think it should block the $wgUseMediaWikiUIEverywhere=true rollout, mark it as a blocker of https://bugzilla.wikimedia. org/show_bug.cgi?id=70424
Thanks,
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Monday, September 8, 2014, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Jon, at the moment I'm only considering radio, toggle(currently mobile only), combo, and dropdown to be blockers. There are a lot of special and one off controls that we will no doubt need to be in order to call things complete, we'll get there, I'm confident.
Jared,
Like Matt pointed out already, the goal here is horizontal consistency. That means correct application and necessary tweaking of the mediawiki.ui controls *we already have* across the board. The scope should not include building new controls.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Mon, Sep 8, 2014 at 10:28 PM, Matthew Flaschen <mflaschen@wikimedia.org javascript:_e(%7B%7D,'cvml','mflaschen@wikimedia.org');> wrote:
On 09/04/2014 07:24 AM, Jon Robson wrote:
- Navigate around the site and make a note of interfaces that look
wrong. Please file bugs against them here [1]
Also, if you think it should block the $wgUseMediaWikiUIEverywhere=true rollout, mark it as a blocker of https://bugzilla.wikimedia. org/show_bug.cgi?id=70424
Thanks,
Matt Flaschen
Design mailing list Design@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/design
Perhaps I misunderstood, Matt did you mean controls we've already built in mediawiki.ui or controls that exist within Mediawiki?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Mon, Sep 8, 2014 at 10:47 PM, Steven Walling swalling@wikimedia.org wrote:
On Monday, September 8, 2014, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Jon, at the moment I'm only considering radio, toggle(currently mobile only), combo, and dropdown to be blockers. There are a lot of special and one off controls that we will no doubt need to be in order to call things complete, we'll get there, I'm confident.
Jared,
Like Matt pointed out already, the goal here is horizontal consistency. That means correct application and necessary tweaking of the mediawiki.ui controls *we already have* across the board. The scope should not include building new controls.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Mon, Sep 8, 2014 at 10:28 PM, Matthew Flaschen < mflaschen@wikimedia.org> wrote:
On 09/04/2014 07:24 AM, Jon Robson wrote:
- Navigate around the site and make a note of interfaces that look
wrong. Please file bugs against them here [1]
Also, if you think it should block the $wgUseMediaWikiUIEverywhere=true rollout, mark it as a blocker of https://bugzilla.wikimedia. org/show_bug.cgi?id=70424
Thanks,
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 09/09/2014 01:57 AM, Jared Zimmerman wrote:
Perhaps I misunderstood, Matt did you mean controls we've already built in mediawiki.ui or controls that exist within Mediawiki?
I agree with Steven's perspective. In my opinion, the blockers should be:
1. A control we have (e.g. checkbox) that is not being used yet on a particular page. 2. A bug or bad interaction in an existing control (e.g. there is a bug that the textarea control looks broken with WikiEditor, which is installed and used by default in production)
We intend to keep moving (continuing to improve the UX and add controls or restyle legacy controls) after this is set to true.
Matt Flaschen
I've setup https://bugzilla.wikimedia.org/show_bug.cgi?id=70913
On Mon, Sep 15, 2014 at 8:04 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/09/2014 01:57 AM, Jared Zimmerman wrote:
Perhaps I misunderstood, Matt did you mean controls we've already built in mediawiki.ui or controls that exist within Mediawiki?
I agree with Steven's perspective. In my opinion, the blockers should be:
- A control we have (e.g. checkbox) that is not being used yet on a
particular page. 2. A bug or bad interaction in an existing control (e.g. there is a bug that the textarea control looks broken with WikiEditor, which is installed and used by default in production)
We intend to keep moving (continuing to improve the UX and add controls or restyle legacy controls) after this is set to true.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design