[Design] mwui.wmflabs.org reactivated, showing upcoming MW UI styles ($wgUseMediaWikiUIEverywhere = true; )

[Matthew Flaschen]

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

[Jon Robson]

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

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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Matthew Flaschen]

Post by Jon Robson
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

[quiddity]

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 at wikimedia.org>

Post by Matthew Flaschen

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140819/b1d508b3/attachment.html>

[Jared Zimmerman]

Matt,

This is very helpful, thank you.



*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

Post by quiddity
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 at wikimedia.org

Post by Matthew Flaschen

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140819/079115eb/attachment.html>

[Jared Zimmerman]

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 [phone] \\ @jaredzimmerman <http://loo.ms/g0>



On Tue, Aug 19, 2014 at 11:10 AM, Jared Zimmerman <

Post by Jared Zimmerman
Matt,
This is very helpful, thank you.
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

Post by quiddity
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 <

Post by Matthew Flaschen

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140819/9def3904/attachment.html>

[Erik Moeller]

On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman

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.

[Steven Walling]

Post by Erik Moeller
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.

[Steven Walling]

On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman <

Post by Jared Zimmerman
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.

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.

[Jared Zimmerman]

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 [phone] \\ @jaredzimmerman <http://loo.ms/g0>



On Thu, Aug 21, 2014 at 1:55 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman <

Post by Jared Zimmerman
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.

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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140821/453254d5/attachment-0001.html>

[Steven Walling]

On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman <

Post by Jared Zimmerman
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.

[Jared Zimmerman]

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 [phone] \\ @jaredzimmerman <http://loo.ms/g0>



On Thu, Aug 21, 2014 at 3:28 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman <

Post by Jared Zimmerman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140821/180e1818/attachment.html>

[Jon Robson]

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 <

Post by Jared Zimmerman
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
On Thu, Aug 21, 2014 at 3:28 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman <

Post by Jared Zimmerman
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Bartosz Dziewoński]

Post by Jon Robson
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.

[Jared Zimmerman]

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 [phone] \\ @jaredzimmerman <http://loo.ms/g0>



On Thu, Aug 21, 2014 at 3:43 PM, Bartosz Dziewoński <matma.rex at gmail.com>

Post by Jon Robson
Personally I would urge much focus. Creating a beta feature with a "fixed

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140821/7de8f554/attachment.html>

[Jon Robson]

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 <

Post by Jared Zimmerman
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
On Thu, Aug 21, 2014 at 3:43 PM, Bartosz Dziewoński <matma.rex at gmail.com>

Post by Jon Robson
Personally I would urge much focus. Creating a beta feature with a "fixed

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Matthew Flaschen]

Post by Jon Robson
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).

Post by Jon Robson
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

[Jon Robson]

Post by Matthew Flaschen

Post by Jon Robson
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.

Post by Matthew Flaschen

Post by Jon Robson
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.

Post by Matthew Flaschen
Matt Flaschen
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/design/attachments/20140825/c318a73c/attachment.html>

[Bartosz Dziewoński]

Post by Jon Robson
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.

[Jon Robson]

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.

Post by Jon Robson
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 at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Bartosz Dziewoński]

Post by Jon Robson
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.

[Matthew Flaschen]

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

[Matthew Flaschen]

Post by Jared Zimmerman
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.

Post by Jared Zimmerman
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.

Post by Jared Zimmerman
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