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
It's neat indeed, but…
On 2015-11-04 13:59, Moushira Elamrawy wrote:
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? :(
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
On Wed, Nov 4, 2015 at 5:39 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
It's neat indeed, but…
On 2015-11-04 13:59, Moushira Elamrawy wrote:
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 Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 2015-11-04 18:04, Trevor Parscal wrote:
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!
On Wed, Nov 4, 2015 at 9:49 AM, Bartosz Dziewoński 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@wikimedia.org wrote:
- ...
- 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_Switche... [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.
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@wikimedia.org wrote:
On Wed, Nov 4, 2015 at 9:49 AM, Bartosz Dziewoński <matma.rex@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@wikimedia.org javascript:_e(%7B%7D,'cvml','tparscal@wikimedia.org');> wrote:
- ...
- 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_Switche... [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
On Wed, Nov 11, 2015 at 1:59 PM, S Page spage@wikimedia.org wrote:
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