[Design] Find code for graphics

[Moushira Elamrawy]

Hello folks,

Did you see this before? http://wikimedia-ui.wmflabs.org ..a simple way
to get the code for the graphics you want. Very neat. Helps us all build
a clean and visiually unified look of pages.

I spotted it in the In the recent discovery and reading showcae [0]. Bravo
and thanks to May Tee-Galloway :)


Best,
Moushira

[0]

[Bartosz Dziewoński]

It's neat indeed, but…

Helps us all build a clean and visiually unified look of pages.

That page does not look visually unified with any of the Wikipedia pages
I've seen. In fact, it just looks like Bootstrap.

Can't we focus on a *single* styling guide instead of creating more
incompatible ones? :(

[Trevor Parscal]

There's been a lot of discussion in some meetings around "UI
Standardization". Here's my view I've expressed:

1. I will always be in support of designers having whatever tool is
needed for them to be able to mockup their work in HTML/CSS. I believe that
working in this format is beneficial to communication, collaboration and
quality.
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 and in no way should the designer's tool
direct the implementation of OOjs UI or any production software.

- Trevor

It's neat indeed, but


Helps us all build a clean and visiually unified look of pages.

That page does not look visually unified with any of the Wikipedia pages
I've seen. In fact, it just looks like Bootstrap.
Can't we focus on a *single* styling guide instead of creating more
incompatible ones? :(
--
Bartosz Dziewoński
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[Bartosz Dziewoński]

Post by Trevor Parscal
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 and in no way should the
designer's tool direct the implementation of OOjs UI or any production
software.

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. Sorry about
that.

It seems that the goal was to bring Bootstrap as close to OOjs UI
MediaWiki theme as possible, since Bootstrap-using code is easy to write
in plain HTML, and it does look like it'll be excellent for quick
mockups. Yay!

[S Page]

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?

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_Switches?action=edit
[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.

[Trevor Parscal]

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

Post by S Page

Post by Bartosz Dziewoński
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
* 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,
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?

Post by Bartosz Dziewoński
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
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_Switches?action=edit
[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

[Prateek Saxena]

Post by S Page
Sure, but how cool would it be if OOjs UI were expressible as
WebComponent-ish things…

I have been considering the WebComponent approach since before we
decided OOjs UI to be our go to UI library, but it obviously isn't
ready to be our main UI technology. Iteratively adding a WebComponent
layer to OOjs UI shouldn't be hard but I have mixed feelings about it
[1]:
* Lack of support [2]. We'll still need parser tags to consistently
support these tags.
* Maintainability.
* Choice of polyfill and/or library, brick/polymer.

It does solve the UI prototyping problem, but I wonder if its worth the effort.

—prtksxna

[1] I am super excited about WebComponents but want to hold myself back.
[2] http://caniuse.com/#search=web%20components