Yes, abstraction is a great way to provide a simple interface to a subset
of the functionality of a complex system of such a simple interface is
needed.
If the simplified tool that designers want can be provided by abstracting a
subset of OOjs UI, I think that's neat. We just need to understand that the
simplified library should be built from the full library - not the opposite.
Simple problems naturally suggest simple solutions, making a complex
solution like OOjs UI initially appear to be unnessecary. However as those
problems inevitably grow in complexity; the functionally that OOjs UI
already offers, or supports being added relatively easily, starts to become
critical.
- Trevor
On Wednesday, November 11, 2015, S Page <spage(a)wikimedia.org> wrote:
On Wed, Nov 4, 2015 at 9:49 AM, Bartosz Dziewoński
<matma.rex(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matma.rex@gmail.com');>> wrote:
Yeah, I was under the mistaken assumption that this is meant to be used
in MediaWiki code, in production, and not as a mockup tool. ...
It seems that the goal was to bring Bootstrap as close to OOjs UI
MediaWiki theme as possible,
I'm still confused. Comparing
http://wikimedia-ui.wmflabs.org/ with
https://doc.wikimedia.org/oojs-ui/master/demos/ :
* The colors are different. button-type="primary" is a different blue
#165C91 than OOjs UI and MediaWiki.ui's #347BFF
* The semantics are different. In wikimedia-ui, button-type="primary"
makes it blue, but in OOjs UI/MediaWiki UI, "primary" isn't a color,
it's
the indicator that this is the one button that gets a colored background. I
don't see a way in wikimedia-ui to produce a colored non-primary button.
* The icons are different. No Alert, Clear, Help, Settings,
OngoingConversation, etc. Even matching icons have different names:
magnifying-glass vs. search.
* Buttons that aren't bold is quite a change.
So wikimedia-ui lets you mock up something rich and complex, but the
simple things in it are different than what OOjs UI and MediaWiki UI
produce. May, are these differences intentional? Can this library pull in
some MediaWiki CSS with a load.php call for some basic consistency?
On Wed, Nov 4, 2015 at 9:04 AM, Trevor Parscal <tparscal(a)wikimedia.org
<javascript:_e(%7B%7D,'cvml','tparscal@wikimedia.org');>>
wrote:
1. ...
2. The kinds of controls that can be expressed in plain HTML/CSS is a
fraction of what can be expressed using OOjs UI or any other
JavaScript-based approach. Even simple things, like designing a type-ahead
feature, can't be done using HTML/CSS alone.
This leads me to feel strongly that this while it might be cool for the
production library (OOjs UI) to be used in some way to make the designer's
work easier, it's not required ...
Sure, but how cool would it be if OOjs UI were expressible as
WebComponent-ish things. view-source:
http://munmay.com/mwui/mw/elements.html is somehow turning tags like
<wikicard> into HTML elements, so its <button> could write out the divs and
spans of OOjs UI elements (or at least the basic "mw-ui-button
mw-ui-progressive" classes of MediaWiki UI). If you look at the source of
Andrew Garrett/Prateek Saxena's LSG [1], you see it's full of, e.g.
<ooui-demo type="button">
{
"label" : "Normal Button",
"flags": ["constructive", "primary"],
}
</ooui-demo>
and the <ooui-demo> parser tag turns that into an actual live OOjs UI
button [2]. I don't know if any next-gen HTML <buzzword> library works like
that. It's challenging, but HTML mockups don't have to be so divorced from
the real OOjs UI.
Cheers,
[1]
http://livingstyleguide.wmflabs.org/wiki/OOjs_UI/Widgets/Buttons_and_Switch…
[2] I just noticed MatmaRex is working on
https://phabricator.wikimedia.org/T101666 "Create parser tag(s) that
render OOUI PHP widgets" \o/ ! Whatever syntax that uses probably will be a
better example of representing OOjs UI.
--
=S Page WMF Tech writer