[Design] is mediawiki.ui deprecated?

[S Page]

(I couldn't find a list for "Frontend standards group" and I'm not sure if
all its engineers are on the design list.)

I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the
mediawiki.ui style, but then it went topsy-turvy:

*spagewmf* I missed that VisualEditor is now using the mediawiki.ui style
formerly known as "Agora"
*James_F* No, we are not.
Agora and MediaWiki.ui are both previous designs. This one is different,
apparently.
Don't ask me how. :-) It's mostly similar, at least.
It's the MediaWiki Theme for OOjs UI.

*spagewmf* How is WMF keeping the "simple" mw-ui-button mw-ui-constructive
and OOjs UI's more elaborate oo-ui-widget > oo-ui-buttonElement
oo-ui-flaggedElement-constructive CSS in sync? Are we able to share LESS
rules?
*James_F* MW UI isn't being kept in sync with the new design, I believe. I
don't think it's credible to try to marry the technologies together with
shared files – it'd be a huge amount of work for a short-term hack.

*spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse,
e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be
very cool for pages to have OOjs UI gadgets someday.
*James_F* Well, tough. :-) MW-UI won't be around for much longer.


How soon is "short-term" and "not much longer"? It's less than a year since
mediawiki.ui.button made it into the default set of page modules and the Living
Style Guide <http://tools.wmflabs.org/styleguide/desktop/section-2.html>
appeared. Are devs going to continue working on $wgUseMediaWikiUIEverywhere
to deliver UX consistency?

I understand the approach espoused by the Frontend standards group
<https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI
<https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to see
Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a long
time before the 15 extensions using mediawiki.ui have all transitioned to
OOjs UI.

I look forward to the "Frontend standards" session at the developer
summit. “The future has arrived — it’s just not evenly distributed yet.”

Cheers,
--
=S Page WMF Tech writer

[Steven Walling]

Post by S Page
(I couldn't find a list for "Frontend standards group" and I'm not sure if
all its engineers are on the design list.)
I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the
*spagewmf* I missed that VisualEditor is now using the mediawiki.ui
style formerly known as "Agora"
*James_F* No, we are not.
Agora and MediaWiki.ui are both previous designs. This one is different,
apparently.
Don't ask me how. :-) It's mostly similar, at least.
It's the MediaWiki Theme for OOjs UI.
*spagewmf* How is WMF keeping the "simple" mw-ui-button
mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget >
oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are
we able to share LESS rules?
*James_F* MW UI isn't being kept in sync with the new design, I believe.
I don't think it's credible to try to marry the technologies together with
shared files – it'd be a huge amount of work for a short-term hack.
*spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse,
e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be
very cool for pages to have OOjs UI gadgets someday.
*James_F* Well, tough. :-) MW-UI won't be around for much longer.

Yeah this is a little weird to hear. I haven't heard a single email on
Wikitech-l or this list about progress toward deprecation. If the new
themes for OOjs UI now match the Living Style Guide contents to the extent
that it's no longer necessary, that's awesome progress. But it would be
good to hear some public communication about any evolution of the standards
and where we're at.

Post by S Page
How soon is "short-term" and "not much longer"? It's less than a year
since mediawiki.ui.button made it into the default set of page modules and
the Living Style Guide
<http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared.
Are devs going to continue working on $wgUseMediaWikiUIEverywhere to
deliver UX consistency?
I understand the approach espoused by the Frontend standards group
<https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI
<https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to
see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a
long time before the 15 extensions using mediawiki.ui have all transitioned
to OOjs UI.
I look forward to the "Frontend standards" session at the developer
summit. “The future has arrived — it’s just not evenly distributed yet.”
Cheers,
--
=S Page WMF Tech writer
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[Trevor Parscal]

Timo is spot on, as usual. Everything he said, I am being completely.

Additionally, the lack of public communication is not an oversight. It's
planned, and we are on schedule. Give it a week. Documentation is already
being moved to the wiki over the next few work days[1], the finishing
touches are waiting to be merged for the PHP implementation[2], the first
interfaces are being converted[3] the template stuff is stalled on the Flow
team conforming their code to upstream light-n-candy[4].

Also, high-level notes about our activities were discussed October's
monthly engineering report[5].

- Trevor

[1] http://www.mediawiki.org/wiki/OOjs_UI/Documentation
[2] https://gerrit.wikimedia.org/r/#/c/182875/
[3] https://gerrit.wikimedia.org/r/#/c/183390/
[4] https://phabricator.wikimedia.org/T75440
[5]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/October#Front-end

* One could argue the mediawiki.ui implementation was never destined to
become a standard/default implementation to begin with. The design is
staying (or that direction at least), but not the implementation. However
that didn't prevent people from using those classes outside the intended
usage area (e.g. selected areas in core and certain extensions that need
the look and feel now, while OOjs UI was being worked on). I warned against
this when it was added to the default page modules, but alas. I guess
people either didn't realise what it meant or are okay with having to
migrate twice (once to mw.ui.less and now to oojs-ui).
* The factor of how easy a class is for a human to grok is mostly
irrelevant. OOjs UI's API isn't single classes. The HTML isn't meant to be
written by hand on a page.[2] To achieve the features we need and, more
importantly, browser support; a single element with some classes doesn't
suffice. The browser's themselves have a lot more than one element, too.
They just hide it via ShadowDOM.[1] Until we can either reliably use CSS3
and CSS4 features or HTML5 Web Components across browsers, we'll need most
widgets to be two or three elements in the public DOM. Another reason for
not maintaining such HTML by hand is because it can change and you'll want
to keep maintenance central and minimal for when that happens. We'll keep
breaking changes to a minimum (especially those requiring html changes),
but expect them to happen (especially in the first year).
* Perhaps we should freeze mediawiki-ui. Then keep around until we're
comfortable removing it. No new features, design syncs or other changes.
Focus efforts on OOjs UI, and slowly migrate towards that. Including OOjs
UI "no-js" entry point where a lighter html footprint is required.
— Timo
[1] Here's an example of Chrome rendering a simple input field with
placeholder and a number input field, exposing the internal elements the
browser utilises to render it: Loading Image...
[2] This is easy for JS and PHP, but for wiki pages the community should
use an abstraction for that html. Templates or Lua modules are the
appropriate venue for that.
(I couldn't find a list for "Frontend standards group" and I'm not sure if
all its engineers are on the design list.)
I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the
*spagewmf* I missed that VisualEditor is now using the mediawiki.ui
style formerly known as "Agora"
*James_F* No, we are not.
Agora and MediaWiki.ui are both previous designs. This one is different,
apparently.
Don't ask me how. :-) It's mostly similar, at least.
It's the MediaWiki Theme for OOjs UI.
*spagewmf* How is WMF keeping the "simple" mw-ui-button
mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget >
oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are
we able to share LESS rules?
*James_F* MW UI isn't being kept in sync with the new design, I believe.
I don't think it's credible to try to marry the technologies together with
shared files – it'd be a huge amount of work for a short-term hack.
*spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse,
e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be
very cool for pages to have OOjs UI gadgets someday.
*James_F* Well, tough. :-) MW-UI won't be around for much longer.
How soon is "short-term" and "not much longer"? It's less than a year
since mediawiki.ui.button made it into the default set of page modules and
the Living Style Guide
<http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared.
Are devs going to continue working on $wgUseMediaWikiUIEverywhere to
deliver UX consistency?
I understand the approach espoused by the Frontend standards group
<https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI
<https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to
see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a
long time before the 15 extensions using mediawiki.ui have all transitioned
to OOjs UI.
I look forward to the "Frontend standards" session at the developer
summit. “The future has arrived — it’s just not evenly distributed yet.”
Cheers,
--
=S Page WMF Tech writer

[Ryan Kaldari]

Regardless of the implementation, which of the actual styles are we
standardizing on? In other words, should we be migrating OOjs UI's styles
to match mediawiki-ui or should we be migrating mediawiki-ui's styles to
match OOjs UI? If the answer is 'neither', I hope people realize that means
that we will have 4 conflicting UI styles in MediaWiki for the forseeable
future:
* OOjs UI styles (i.e. Trevor's styles)
* mediawiki-ui styles (i.e. Jared and May's styles)
* jQuery UI/old-Agora styles (i.e. Brandon's styles)
* default MediaWiki element styling (skins)

Kaldari

Post by Trevor Parscal
Timo is spot on, as usual. Everything he said, I am being completely.
Additionally, the lack of public communication is not an oversight. It's
planned, and we are on schedule. Give it a week. Documentation is already
being moved to the wiki over the next few work days[1], the finishing
touches are waiting to be merged for the PHP implementation[2], the first
interfaces are being converted[3] the template stuff is stalled on the Flow
team conforming their code to upstream light-n-candy[4].
Also, high-level notes about our activities were discussed October's
monthly engineering report[5].
- Trevor
[1] http://www.mediawiki.org/wiki/OOjs_UI/Documentation
[2] https://gerrit.wikimedia.org/r/#/c/182875/
[3] https://gerrit.wikimedia.org/r/#/c/183390/
[4] https://phabricator.wikimedia.org/T75440
[5]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/October#Front-end

* One could argue the mediawiki.ui implementation was never destined to
become a standard/default implementation to begin with. The design is
staying (or that direction at least), but not the implementation. However
that didn't prevent people from using those classes outside the intended
usage area (e.g. selected areas in core and certain extensions that need
the look and feel now, while OOjs UI was being worked on). I warned against
this when it was added to the default page modules, but alas. I guess
people either didn't realise what it meant or are okay with having to
migrate twice (once to mw.ui.less and now to oojs-ui).
* The factor of how easy a class is for a human to grok is mostly
irrelevant. OOjs UI's API isn't single classes. The HTML isn't meant to be
written by hand on a page.[2] To achieve the features we need and, more
importantly, browser support; a single element with some classes doesn't
suffice. The browser's themselves have a lot more than one element, too.
They just hide it via ShadowDOM.[1] Until we can either reliably use CSS3
and CSS4 features or HTML5 Web Components across browsers, we'll need most
widgets to be two or three elements in the public DOM. Another reason for
not maintaining such HTML by hand is because it can change and you'll want
to keep maintenance central and minimal for when that happens. We'll keep
breaking changes to a minimum (especially those requiring html changes),
but expect them to happen (especially in the first year).
* Perhaps we should freeze mediawiki-ui. Then keep around until we're
comfortable removing it. No new features, design syncs or other changes.
Focus efforts on OOjs UI, and slowly migrate towards that. Including OOjs
UI "no-js" entry point where a lighter html footprint is required.
— Timo
[1] Here's an example of Chrome rendering a simple input field with
placeholder and a number input field, exposing the internal elements the
browser utilises to render it: http://i.imgur.com/CWQ2Htj.png
[2] This is easy for JS and PHP, but for wiki pages the community should
use an abstraction for that html. Templates or Lua modules are the
appropriate venue for that.
(I couldn't find a list for "Frontend standards group" and I'm not sure
if all its engineers are on the design list.)
I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the
*spagewmf* I missed that VisualEditor is now using the mediawiki.ui
style formerly known as "Agora"
*James_F* No, we are not.
Agora and MediaWiki.ui are both previous designs. This one is different,
apparently.
Don't ask me how. :-) It's mostly similar, at least.
It's the MediaWiki Theme for OOjs UI.
*spagewmf* How is WMF keeping the "simple" mw-ui-button
mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget >
oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are
we able to share LESS rules?
*James_F* MW UI isn't being kept in sync with the new design, I
believe. I don't think it's credible to try to marry the technologies
together with shared files – it'd be a huge amount of work for a short-term
hack.
*spagewmf* The mw-ui- classes are a lot easier for humans to
grok/reuse, e.g. https://en.wikipedia.org/wiki/Template:Clickable_button
It could be very cool for pages to have OOjs UI gadgets someday.
*James_F* Well, tough. :-) MW-UI won't be around for much longer.
How soon is "short-term" and "not much longer"? It's less than a year
since mediawiki.ui.button made it into the default set of page modules and
the Living Style Guide
<http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared.
Are devs going to continue working on $wgUseMediaWikiUIEverywhere to
deliver UX consistency?
I understand the approach espoused by the Frontend standards group
<https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs
UI <https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited
to see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be
a long time before the 15 extensions using mediawiki.ui have all
transitioned to OOjs UI.
I look forward to the "Frontend standards" session at the developer
summit. “The future has arrived — it’s just not evenly distributed yet.”
Cheers,
--
=S Page WMF Tech writer

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

[Trevor Parscal]

Replies inline. Hopefully some useful clarification.

<snip>
* OOjs UI styles (i.e. Trevor's styles)
* mediawiki-ui styles (i.e. Jared and May's styles)

MediaWiki UI is a transitional system which has allowed interfaces to be
modernized and the design work to be iterated on, in context, before OOjs
UI was ready for use. There shouldn't be any significant differences
between MediaWiki UI and OOjs UI, but where there is a difference we should
seek to make both systems look the same where possible until MediaWiki UI
is no longer in use. OOjs UI within MediaWiki is using the theme designed
by May, implemented by Prateek with some help from me. They are not my
styles.

* jQuery UI/old-Agora styles (i.e. Brandon's styles)

The new styles have not been back-ported to jQuery UI, and I don't believe
there's any plan to do so. The objective is instead to stop using jQuery UI
and replace those interfaces with their OOjs UI equivalents over time.
Unfortunately jQuery UI is difficult to theme, which is actually one of the
many reasons we have decided to move away from it.

* default MediaWiki element styling (skins)
Default MediaWiki styling (per skin) is really the lack of styling in
practice because none of our skins provide styled form controls or other
reusable widgets.

- Trevor

[Ryan Kaldari]

Here's a quick audit of potential issues/blockers for OOJS migration:

Elements in mediawiki-ui that are missing in OOJS UI:
* stackable "block" buttons (needed for MobileFrontend)
* big buttons (used by UploadWizard)
* large inputs (used in Flow)
* anchors (used in MobileFrontend)

Elements in jQueryUI that are missing in OOJS UI:
* datepicker (used by UploadWizard)
* multi-select (used by CentralNotice)

Styles which do not match between mediawiki-ui and OOJS UI:
* constructive, destructive, progressive buttons - Which styles do we want
to use?
* frameless constructive, destructive, progressive buttons - Which styles
do we want to use?
* disabled buttons - The disabled buttons in OOJS UI are difficult to read.
They should probably adopt mediawiki-ui's disabled style.
* standalone icon buttons - much smaller in OOJS UI, we probably need two
different size options.

Can't tell if styles match due to OOjs living style guide entries that
aren't actually living (uses screenshots instead):
* ButtonGroupWidget
* PopupButtonWidget
* ButtonInputWidget
* FormLayout
* PanelLayout
* Dialog
* ProcessDialog
* MessageDialog

Kaldari

Post by Trevor Parscal
Replies inline. Hopefully some useful clarification.

<snip>
* OOjs UI styles (i.e. Trevor's styles)
* mediawiki-ui styles (i.e. Jared and May's styles)

MediaWiki UI is a transitional system which has allowed interfaces to be
modernized and the design work to be iterated on, in context, before OOjs
UI was ready for use. There shouldn't be any significant differences
between MediaWiki UI and OOjs UI, but where there is a difference we should
seek to make both systems look the same where possible until MediaWiki UI
is no longer in use. OOjs UI within MediaWiki is using the theme designed
by May, implemented by Prateek with some help from me. They are not my
styles.

* jQuery UI/old-Agora styles (i.e. Brandon's styles)

The new styles have not been back-ported to jQuery UI, and I don't believe
there's any plan to do so. The objective is instead to stop using jQuery UI
and replace those interfaces with their OOjs UI equivalents over time.
Unfortunately jQuery UI is difficult to theme, which is actually one of the
many reasons we have decided to move away from it.
* default MediaWiki element styling (skins)
Default MediaWiki styling (per skin) is really the lack of styling in
practice because none of our skins provide styled form controls or other
reusable widgets.
- Trevor
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[Ryan Kaldari]

Forget to mention that CentralNotice is also using jQuery UI date-picker.

Post by Ryan Kaldari
* stackable "block" buttons (needed for MobileFrontend)
* big buttons (used by UploadWizard)
* large inputs (used in Flow)
* anchors (used in MobileFrontend)
* datepicker (used by UploadWizard)
* multi-select (used by CentralNotice)
* constructive, destructive, progressive buttons - Which styles do we want
to use?
* frameless constructive, destructive, progressive buttons - Which styles
do we want to use?
* disabled buttons - The disabled buttons in OOJS UI are difficult to
read. They should probably adopt mediawiki-ui's disabled style.
* standalone icon buttons - much smaller in OOJS UI, we probably need two
different size options.
Can't tell if styles match due to OOjs living style guide entries that
* ButtonGroupWidget
* PopupButtonWidget
* ButtonInputWidget
* FormLayout
* PanelLayout
* Dialog
* ProcessDialog
* MessageDialog
Kaldari

Post by Trevor Parscal
Replies inline. Hopefully some useful clarification.

<snip>
* OOjs UI styles (i.e. Trevor's styles)
* mediawiki-ui styles (i.e. Jared and May's styles)

MediaWiki UI is a transitional system which has allowed interfaces to be
modernized and the design work to be iterated on, in context, before OOjs
UI was ready for use. There shouldn't be any significant differences
between MediaWiki UI and OOjs UI, but where there is a difference we should
seek to make both systems look the same where possible until MediaWiki UI
is no longer in use. OOjs UI within MediaWiki is using the theme designed
by May, implemented by Prateek with some help from me. They are not my
styles.

* jQuery UI/old-Agora styles (i.e. Brandon's styles)

The new styles have not been back-ported to jQuery UI, and I don't
believe there's any plan to do so. The objective is instead to stop using
jQuery UI and replace those interfaces with their OOjs UI equivalents over
time. Unfortunately jQuery UI is difficult to theme, which is actually one
of the many reasons we have decided to move away from it.
* default MediaWiki element styling (skins)
Default MediaWiki styling (per skin) is really the lack of styling in
practice because none of our skins provide styled form controls or other
reusable widgets.
- Trevor
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[Trevor Parscal]

As a general rule, we've not added widgets to OOjs UI until we had an
actual use for them, so indeed there are some missing pieces, which when an
application starts using the library should be added.

Any differences between OOjs UI and MediaWiki UI should be reported as bugs
and assigned to Prateek, who I've added to this thread. Again, I got him
started, but the OOjs UI theme is not intended to diverge from, but rather
be perfectly in step with, the latest from the design team. If one of the
libraries is being neglected that's a bug not a design.

We, as an organization, need to converge our engineering practices so that
all of our products are written using the same libraries, use the same
patterns, are documented in the same places and share as much of everything
as possible between them. The state of things suggests that the lack of
one-true-standard has not led us to converge naturally, so we've now
instated one. We need everyone to participate in improving it so it can
serve more use cases, run on more devices, look better, load faster and
generally suck less.

Ryan has done a great job of identifying some of the steps that will be
involved here. It would be really excellent if we could start seeing some
boards in Phabricator around steps to get each product to that point.

- Trevor

Post by Ryan Kaldari
Forget to mention that CentralNotice is also using jQuery UI date-picker.

Post by Ryan Kaldari
* stackable "block" buttons (needed for MobileFrontend)
* big buttons (used by UploadWizard)
* large inputs (used in Flow)
* anchors (used in MobileFrontend)
* datepicker (used by UploadWizard)
* multi-select (used by CentralNotice)
* constructive, destructive, progressive buttons - Which styles do we
want to use?
* frameless constructive, destructive, progressive buttons - Which styles
do we want to use?
* disabled buttons - The disabled buttons in OOJS UI are difficult to
read. They should probably adopt mediawiki-ui's disabled style.
* standalone icon buttons - much smaller in OOJS UI, we probably need two
different size options.
Can't tell if styles match due to OOjs living style guide entries that
* ButtonGroupWidget
* PopupButtonWidget
* ButtonInputWidget
* FormLayout
* PanelLayout
* Dialog
* ProcessDialog
* MessageDialog
Kaldari

Post by Trevor Parscal
Replies inline. Hopefully some useful clarification.

<snip>
* OOjs UI styles (i.e. Trevor's styles)
* mediawiki-ui styles (i.e. Jared and May's styles)

MediaWiki UI is a transitional system which has allowed interfaces to be
modernized and the design work to be iterated on, in context, before OOjs
UI was ready for use. There shouldn't be any significant differences
between MediaWiki UI and OOjs UI, but where there is a difference we should
seek to make both systems look the same where possible until MediaWiki UI
is no longer in use. OOjs UI within MediaWiki is using the theme designed
by May, implemented by Prateek with some help from me. They are not my
styles.

* jQuery UI/old-Agora styles (i.e. Brandon's styles)

The new styles have not been back-ported to jQuery UI, and I don't
believe there's any plan to do so. The objective is instead to stop using
jQuery UI and replace those interfaces with their OOjs UI equivalents over
time. Unfortunately jQuery UI is difficult to theme, which is actually one
of the many reasons we have decided to move away from it.
* default MediaWiki element styling (skins)
Default MediaWiki styling (per skin) is really the lack of styling in
practice because none of our skins provide styled form controls or other
reusable widgets.
- Trevor
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

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