I've updated the MW UI demo site (http://mwui.wmflabs.org/wiki/Main_Page) and enabled $wgUseMediaWikiUIEverywhere = true; (the global used by Jon's blanket MW UI change).
Basically, we want to test this version for a while, then make it the only version. So please click around on http://mwui.wmflabs.org/wiki/Main_Page (e.g. try editing http://mwui.wmflabs.org/wiki/Lorem_ipsum, among many other possibilities).
Thanks,
Matt Flaschen
Thanks Matt, the problem with this approach is I don't have an account and I'm too lazy to make yet another one and I am going to forget the URL in a weeks time, so I worry about the coverage this will get from designers/devs. :)
Ideally I'd love to see this on beta labs in some form. Please see my email subject "MediaWiki UI is broken - let's fix it." (Matt thanks for your reply).
On Mon, Aug 18, 2014 at 5:16 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
I've updated the MW UI demo site (http://mwui.wmflabs.org/wiki/Main_Page) and enabled $wgUseMediaWikiUIEverywhere = true; (the global used by Jon's blanket MW UI change).
Basically, we want to test this version for a while, then make it the only version. So please click around on http://mwui.wmflabs.org/wiki/Main_Page (e.g. try editing http://mwui.wmflabs.org/wiki/Lorem_ipsum, among many other possibilities).
Thanks,
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 08/18/2014 08:36 PM, Jon Robson wrote:
Thanks Matt, the problem with this approach is I don't have an account and I'm too lazy to make yet another one and I am going to forget the URL in a weeks time, so I worry about the coverage this will get from designers/devs. :)
I've enabled anonymous editing. Also, feel free to make and use throw-away accounts (it's still necessary to test certain things).
As far as the name, I'm not sure how to make that one more memorable. :)
I'll forward my previous email to Wikitech as well.
Matt Flaschen
I added some links to the Main Page at http://mwui.wmflabs.org/wiki/Main_Page pointing towards basic demos of the UI changes. Hope that's ok.
Is there a rough ETA for the radio-button and drawer-menu changes? Those seem to be the two most confusingly-contrasting old UI elements, in most special pages.
On Mon, Aug 18, 2014 at 8:25 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/18/2014 08:36 PM, Jon Robson wrote:
Thanks Matt, the problem with this approach is I don't have an account and I'm too lazy to make yet another one and I am going to forget the URL in a weeks time, so I worry about the coverage this will get from designers/devs. :)
I've enabled anonymous editing. Also, feel free to make and use throw-away accounts (it's still necessary to test certain things).
As far as the name, I'm not sure how to make that one more memorable. :)
I'll forward my previous email to Wikitech as well.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Matt,
This is very helpful, thank you.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Tue, Aug 19, 2014 at 9:54 AM, quiddity pandiculation@gmail.com wrote:
I added some links to the Main Page at http://mwui.wmflabs.org/wiki/Main_Page pointing towards basic demos of the UI changes. Hope that's ok.
Is there a rough ETA for the radio-button and drawer-menu changes? Those seem to be the two most confusingly-contrasting old UI elements, in most special pages.
On Mon, Aug 18, 2014 at 8:25 PM, Matthew Flaschen <mflaschen@wikimedia.org
wrote:
On 08/18/2014 08:36 PM, Jon Robson wrote:
Thanks Matt, the problem with this approach is I don't have an account and I'm too lazy to make yet another one and I am going to forget the URL in a weeks time, so I worry about the coverage this will get from designers/devs. :)
I've enabled anonymous editing. Also, feel free to make and use throw-away accounts (it's still necessary to test certain things).
As far as the name, I'm not sure how to make that one more memorable. :)
I'll forward my previous email to Wikitech as well.
Matt Flaschen
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
Ok, I've been thinking about this for a bit. my suggestion is this…
We create 3 more controls
- Dropdown https://trello.com/c/bdpbPSZT/4-drawer-menu (can Juliusz's work on compact person bar be componentized?) - Search Field https://trello.com/c/MC8ovuyw/2-advanced-input-fields - Radio Button https://trello.com/c/df2N2KJx/8-radio-buttons
Finalize 2 controls
- Check box (disabled state, disabled checked) - Vform (vertical padding)
Then let's make a Beta feature to allow people to test and see medaiwiki.ui in context in vector(at least) and report problems.
I'd love to be able to provide a fixed element on screen that allows someone to quickly and easily report problems with a control on a particular page (isn't using mediawiki.ui style, isn't using right type (progressive, constructive, destructive) and right style normal, quiet, etc. and any issues around order or logic, e.g. on WTE Save should be the rightmost according to mediawiki.ui guidelines and there are too many Primary style buttons.
*Jon*, perhaps you could brainstorm a fixed header element that allows someone to report an issue on their current page that generates bug reports or emails or something along those lines?
Is there any way we could accelerate fixes reported by users more than our normal time span of 2-3 weeks? cc'ing *Greg* for his thoughts here about a way to do this without breaking things.
This won't be our first Beta feature that is more for learning and testing with no plans to graduate but we should be clear that that's what its for in the description on the beta page, so people can give helpful and constructive feedback knowing that it will be an iterative process.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Tue, Aug 19, 2014 at 11:10 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Matt,
This is very helpful, thank you.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Tue, Aug 19, 2014 at 9:54 AM, quiddity pandiculation@gmail.com wrote:
I added some links to the Main Page at http://mwui.wmflabs.org/wiki/Main_Page pointing towards basic demos of the UI changes. Hope that's ok.
Is there a rough ETA for the radio-button and drawer-menu changes? Those seem to be the two most confusingly-contrasting old UI elements, in most special pages.
On Mon, Aug 18, 2014 at 8:25 PM, Matthew Flaschen < mflaschen@wikimedia.org> wrote:
On 08/18/2014 08:36 PM, Jon Robson wrote:
Thanks Matt, the problem with this approach is I don't have an account and I'm too lazy to make yet another one and I am going to forget the URL in a weeks time, so I worry about the coverage this will get from designers/devs. :)
I've enabled anonymous editing. Also, feel free to make and use throw-away accounts (it's still necessary to test certain things).
As far as the name, I'm not sure how to make that one more memorable. :)
I'll forward my previous email to Wikitech as well.
Matt Flaschen
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 Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Then let's make a Beta feature to allow people to test and see medaiwiki.ui in context in vector(at least) and report problems.
+1
Let's please be careful with piecemeal deployments at this point, and make sure anything that goes out is scheduled and understood. I don't think any of the prod changes so far have been problematic, but big change like having the blue focus bar in the textareas really need to be carefully considered if/before they go live.
On Thu, Aug 21, 2014 at 1:45 PM, Erik Moeller erik@wikimedia.org wrote:
Let's please be careful with piecemeal deployments at this point, and make sure anything that goes out is scheduled and understood. I don't think any of the prod changes so far have been problematic, but big change like having the blue focus bar in the textareas really need to be carefully considered if/before they go live.
Big +1 here. Will try to help make sure we are more considered when it comes to deployments of additional updates here.
On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Ok, I've been thinking about this for a bit. my suggestion is this…
We create 3 more controls
(can Juliusz's work on compact person bar be componentized?)
- Search Field https://trello.com/c/MC8ovuyw/2-advanced-input-fields
- Radio Button https://trello.com/c/df2N2KJx/8-radio-buttons
Finalize 2 controls
- Check box (disabled state, disabled checked)
- Vform (vertical padding)
Then let's make a Beta feature to allow people to test and see medaiwiki.ui in context in vector(at least) and report problems.
I'd love to be able to provide a fixed element on screen that allows someone to quickly and easily report problems with a control on a particular page (isn't using mediawiki.ui style, isn't using right type (progressive, constructive, destructive) and right style normal, quiet, etc. and any issues around order or logic, e.g. on WTE Save should be the rightmost according to mediawiki.ui guidelines and there are too many Primary style buttons.
*Jon*, perhaps you could brainstorm a fixed header element that allows someone to report an issue on their current page that generates bug reports or emails or something along those lines?
Is there any way we could accelerate fixes reported by users more than our normal time span of 2-3 weeks? cc'ing *Greg* for his thoughts here about a way to do this without breaking things.
This won't be our first Beta feature that is more for learning and testing with no plans to graduate but we should be clear that that's what its for in the description on the beta page, so people can give helpful and constructive feedback knowing that it will be an iterative process.
Like Erik said, we need to not be in a rush here. This thing is kind of a mess and needs some basic design review first, before we charge ahead with expanding the scope into new controls or a reporting tool like you suggested. I also am very uncomfortable saying we should release a Beta Feature we don't intend to graduate.
Steven, from the very beginning of Beta Features we acknowledged their would be Beta Features that were only for experimenting and exploring, that they wouldn't graduate. So this isn't a concern of mine. I think the only way we'll be able to get a good solid review of the controls, both internally and from users is to package it up as a beta feature and let people use the real production site with all the new controls in place. Matt's test instance is great but won't serve the same purpose.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Thu, Aug 21, 2014 at 1:55 PM, Steven Walling swalling@wikimedia.org wrote:
On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Ok, I've been thinking about this for a bit. my suggestion is this…
We create 3 more controls
(can Juliusz's work on compact person bar be componentized?)
- Search Field https://trello.com/c/MC8ovuyw/2-advanced-input-fields
- Radio Button https://trello.com/c/df2N2KJx/8-radio-buttons
Finalize 2 controls
- Check box (disabled state, disabled checked)
- Vform (vertical padding)
Then let's make a Beta feature to allow people to test and see medaiwiki.ui in context in vector(at least) and report problems.
I'd love to be able to provide a fixed element on screen that allows someone to quickly and easily report problems with a control on a particular page (isn't using mediawiki.ui style, isn't using right type (progressive, constructive, destructive) and right style normal, quiet, etc. and any issues around order or logic, e.g. on WTE Save should be the rightmost according to mediawiki.ui guidelines and there are too many Primary style buttons.
*Jon*, perhaps you could brainstorm a fixed header element that allows someone to report an issue on their current page that generates bug reports or emails or something along those lines?
Is there any way we could accelerate fixes reported by users more than our normal time span of 2-3 weeks? cc'ing *Greg* for his thoughts here about a way to do this without breaking things.
This won't be our first Beta feature that is more for learning and testing with no plans to graduate but we should be clear that that's what its for in the description on the beta page, so people can give helpful and constructive feedback knowing that it will be an iterative process.
Like Erik said, we need to not be in a rush here. This thing is kind of a mess and needs some basic design review first, before we charge ahead with expanding the scope into new controls or a reporting tool like you suggested. I also am very uncomfortable saying we should release a Beta Feature we don't intend to graduate.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Steven, from the very beginning of Beta Features we acknowledged their would be Beta Features that were only for experimenting and exploring, that they wouldn't graduate. So this isn't a concern of mine. I think the only way we'll be able to get a good solid review of the controls, both internally and from users is to package it up as a beta feature and let people use the real production site with all the new controls in place. Matt's test instance is great but won't serve the same purpose.
Having a new feature we want to try and test but then decide not graduate is one thing. Nearby for Desktop was a good example of this. But releasing a beta feature we definitely never intend to graduate is just silly and a waste of resources. We want everything to look and feel consistent, hopefully with the nascent mediawiki.ui style as the standard. We mostly definitely do want to graduate new button and form styles to all core forms. It's actually one of the main complaints from the community early on in the process, that we were doing things in a piecemeal fashion.
Before we push out a production beta feature, we still have work we can and should do to clean up button and form styles in mediawiki.ui, which we can use Labs for. For instance, the crappy typography in the buttons which is off-specification, the lack of appropriate padding for buttons, the messy state of the wikitext edit form with mw.ui controls, the inconsistent style of placeholders, and lots more.
Yes, I agree completely, we need to do a lot of cleanup to what we have before any major public release, and we also need a logical place to corral things before a release that we can evaluate everything in tandem. We can discuss whether this is a beta feature or a test server.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Thu, Aug 21, 2014 at 3:28 PM, Steven Walling swalling@wikimedia.org wrote:
On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Steven, from the very beginning of Beta Features we acknowledged their would be Beta Features that were only for experimenting and exploring, that they wouldn't graduate. So this isn't a concern of mine. I think the only way we'll be able to get a good solid review of the controls, both internally and from users is to package it up as a beta feature and let people use the real production site with all the new controls in place. Matt's test instance is great but won't serve the same purpose.
Having a new feature we want to try and test but then decide not graduate is one thing. Nearby for Desktop was a good example of this. But releasing a beta feature we definitely never intend to graduate is just silly and a waste of resources. We want everything to look and feel consistent, hopefully with the nascent mediawiki.ui style as the standard. We mostly definitely do want to graduate new button and form styles to all core forms. It's actually one of the main complaints from the community early on in the process, that we were doing things in a piecemeal fashion.
Before we push out a production beta feature, we still have work we can and should do to clean up button and form styles in mediawiki.ui, which we can use Labs for. For instance, the crappy typography in the buttons which is off-specification, the lack of appropriate padding for buttons, the messy state of the wikitext edit form with mw.ui controls, the inconsistent style of placeholders, and lots more.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Personally I would urge much focus. Creating a beta feature with a "fixed header element that allows someone to report an issue on their current page" seems like overkill. It solves a problem the beta feature discussions forums already solve and I'm already stretched thin in what I am being asked to do.
The only real reason to have a beta feature here is if we plan on enabling mediawiki ui form elements everywhere, which is what I thought we were working for. This would be a super simple beta feature to knock up as currently it is only turning on a global variable, the only hard bit creating an image for it to show up on the beta features preference page.
I worry that currently no one is looking at the website Matt setup, so I'd be keen to explore a way of getting this project more visibility and keep it moving whilst there is still momentum.
On Thu, Aug 21, 2014 at 3:36 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Yes, I agree completely, we need to do a lot of cleanup to what we have before any major public release, and we also need a logical place to corral things before a release that we can evaluate everything in tandem. We can discuss whether this is a beta feature or a test server.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Thu, Aug 21, 2014 at 3:28 PM, Steven Walling swalling@wikimedia.org wrote:
On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Steven, from the very beginning of Beta Features we acknowledged their would be Beta Features that were only for experimenting and exploring, that they wouldn't graduate. So this isn't a concern of mine. I think the only way we'll be able to get a good solid review of the controls, both internally and from users is to package it up as a beta feature and let people use the real production site with all the new controls in place. Matt's test instance is great but won't serve the same purpose.
Having a new feature we want to try and test but then decide not graduate is one thing. Nearby for Desktop was a good example of this. But releasing a beta feature we definitely never intend to graduate is just silly and a waste of resources. We want everything to look and feel consistent, hopefully with the nascent mediawiki.ui style as the standard. We mostly definitely do want to graduate new button and form styles to all core forms. It's actually one of the main complaints from the community early on in the process, that we were doing things in a piecemeal fashion.
Before we push out a production beta feature, we still have work we can and should do to clean up button and form styles in mediawiki.ui, which we can use Labs for. For instance, the crappy typography in the buttons which is off-specification, the lack of appropriate padding for buttons, the messy state of the wikitext edit form with mw.ui controls, the inconsistent style of placeholders, and lots more.
-- 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 Fri, 22 Aug 2014 00:40:32 +0200, Jon Robson jdlrobson@gmail.com wrote:
Personally I would urge much focus. Creating a beta feature with a "fixed header element that allows someone to report an issue on their current page" seems like overkill. It solves a problem the beta feature discussions forums already solve and I'm already stretched thin in what I am being asked to do.
The only real reason to have a beta feature here is if we plan on enabling mediawiki ui form elements everywhere, which is what I thought we were working for. This would be a super simple beta feature to knock up as currently it is only turning on a global variable, the only hard bit creating an image for it to show up on the beta features preference page.
I worry that currently no one is looking at the website Matt setup, so I'd be keen to explore a way of getting this project more visibility and keep it moving whilst there is still momentum.
A number of critical issues with new layout were identified (e.g. on action=delete, action=history, Special:Log, …). Are these being worked on or tracked somewhere? I think we should fix the obvious problems before we start even talking about making this a BetaFeature, or we risk the communities rightfully raging at us for deploying completely broken software again.
Bartosz, good point, should we at least interally consider using the Audit column or a new column in https://trello.com/b/EXtVTJxJ/mediawiki-ui to track issues or would people prefer individual bugs?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Thu, Aug 21, 2014 at 3:43 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Fri, 22 Aug 2014 00:40:32 +0200, Jon Robson jdlrobson@gmail.com wrote:
Personally I would urge much focus. Creating a beta feature with a "fixed
header element that allows someone to report an issue on their current page" seems like overkill. It solves a problem the beta feature discussions forums already solve and I'm already stretched thin in what I am being asked to do.
The only real reason to have a beta feature here is if we plan on enabling mediawiki ui form elements everywhere, which is what I thought we were working for. This would be a super simple beta feature to knock up as currently it is only turning on a global variable, the only hard bit creating an image for it to show up on the beta features preference page.
I worry that currently no one is looking at the website Matt setup, so I'd be keen to explore a way of getting this project more visibility and keep it moving whilst there is still momentum.
A number of critical issues with new layout were identified (e.g. on action=delete, action=history, Special:Log, …). Are these being worked on or tracked somewhere? I think we should fix the obvious problems before we start even talking about making this a BetaFeature, or we risk the communities rightfully raging at us for deploying completely broken software again.
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Personally I'd like bugs raised, the problem is where to raise them. They are currently not visible anywhere to anyone who is not a developer, this is why I was keen to get it running on betalabs.
Some of the issues Bartosz mentions are fixed here: https://gerrit.wikimedia.org/r/154121 https://gerrit.wikimedia.org/r/154125
On Thu, Aug 21, 2014 at 3:47 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Bartosz, good point, should we at least interally consider using the Audit column or a new column in https://trello.com/b/EXtVTJxJ/mediawiki-ui to track issues or would people prefer individual bugs?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M +1 415 609 4043 \ @jaredzimmerman http://loo.ms/g0
On Thu, Aug 21, 2014 at 3:43 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Fri, 22 Aug 2014 00:40:32 +0200, Jon Robson jdlrobson@gmail.com wrote:
Personally I would urge much focus. Creating a beta feature with a "fixed
header element that allows someone to report an issue on their current page" seems like overkill. It solves a problem the beta feature discussions forums already solve and I'm already stretched thin in what I am being asked to do.
The only real reason to have a beta feature here is if we plan on enabling mediawiki ui form elements everywhere, which is what I thought we were working for. This would be a super simple beta feature to knock up as currently it is only turning on a global variable, the only hard bit creating an image for it to show up on the beta features preference page.
I worry that currently no one is looking at the website Matt setup, so I'd be keen to explore a way of getting this project more visibility and keep it moving whilst there is still momentum.
A number of critical issues with new layout were identified (e.g. on action=delete, action=history, Special:Log, …). Are these being worked on or tracked somewhere? I think we should fix the obvious problems before we start even talking about making this a BetaFeature, or we risk the communities rightfully raging at us for deploying completely broken software again.
-- Matma Rex
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/21/2014 06:54 PM, Jon Robson wrote:
Personally I'd like bugs raised, the problem is where to raise them.
I prefer we continue to use Bugzilla for this (if something is still untracked as far as you know, please file).
They are currently not visible anywhere to anyone who is not a developer, this is why I was keen to get it running on betalabs.
We've already had feedback from non-developers. That said, I agree more work is needed.
Matt Flaschen
On 25 Aug 2014 17:12, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 08/21/2014 06:54 PM, Jon Robson wrote:
Personally I'd like bugs raised, the problem is where to raise them.
I prefer we continue to use Bugzilla for this (if something is still
untracked as far as you know, please file).
Sure.
But which component/product? That's not clear to me. Each bug will also have to explain how to turn these styles on.
They are currently not visible anywhere to anyone who is not a developer, this is why I was keen to get it running on betalabs.
We've already had feedback from non-developers. That said, I agree more
work is needed.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
m
On Tue, 26 Aug 2014 04:14:19 +0200, Jon Robson jdlrobson@gmail.com wrote:
But which component/product? That's not clear to me. Each bug will also have to explain how to turn these styles on.
Two such bugs have been filed today in MediaWiki → Skin and page rendering, so I guess that's a good place. We could also have a separate component for MediaWiki UI created, that might actually make it easier to track these issues.
Thanks Bartosz. I think a MediaWiki UI component would actually make a lot of sense. If no one objects I'll talk to Andre about getting one setup.
On Tue, Aug 26, 2014 at 7:07 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 26 Aug 2014 04:14:19 +0200, Jon Robson jdlrobson@gmail.com wrote:
But which component/product? That's not clear to me. Each bug will also have to explain how to turn these styles on.
Two such bugs have been filed today in MediaWiki → Skin and page rendering, so I guess that's a good place. We could also have a separate component for MediaWiki UI created, that might actually make it easier to track these issues.
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, 26 Aug 2014 21:48:23 +0200, Jon Robson jdlrobson@gmail.com wrote:
Thanks Bartosz. I think a MediaWiki UI component would actually make a lot of sense. If no one objects I'll talk to Andre about getting one setup.
For the record, this has been done.
On 08/21/2014 06:28 PM, Steven Walling wrote:
We mostly definitely do want to graduate new button and form styles to all core forms.
I agree. I want to help fix the current issues with the "wgUseMediaWikiUIEverywhere true" mode, but I also want to get rid of that feature flag soon (making true the new behavior). Both are priorities.
Matt Flaschen
On 08/19/2014 06:29 PM, Jared Zimmerman wrote:
Then let's make a Beta feature to allow people to test and see medaiwiki.ui in context in vector(at least) and report problems.
I don't have a strong position either way on this yet. However, we need to be clear that not every incremental improvement to the UI is going to go through the Beta Feature cycle.
For example, say we do those three controls (plus what we already have) as part of the big rollout. I would not think e.g. a new <input type="number"> control, or enhancements to the existing MW UI controls, should have a whole Beta Feature cycle.
I'd love to be able to provide a fixed element on screen that allows someone to quickly and easily report problems with a control on a particular page (isn't using mediawiki.ui style, isn't using right type (progressive, constructive, destructive) and right style normal, quiet, etc. and any issues around order or logic, e.g. on WTE Save should be the rightmost according to mediawiki.ui guidelines and there are too many Primary style buttons.
If we want to work on this, I suggest we improve the existing mediawiki.feedback.
This won't be our first Beta feature that is more for learning and testing with no plans to graduate but we should be clear that that's what its for in the description on the beta page, so people can give helpful and constructive feedback knowing that it will be an iterative process.
To be clear, I do intend this to be finalized or be rolled back relatively soon. We are currently using a global variable, and two code paths in various places. This is a compromise we arrived at as an incremental solution (so we can work on it without continually amending one big patch).
However, I want to get rid of $wgUseMediaWikiUIEverywhere (keeping the new MW UI controls). Also, I don't support doing such a global for all cases. It was appropriate in this case (which has major impacts on e.g. the edit form), but that doesn't mean it necessarily would be in a future case (where e.g. we add one or two controls).
Matt Flaschen