The whole point of having a living style guide was to prevent the endless
proliferation of outdated MediaWiki style guides (as we were creating about
1 a year for a while). Now we're somehow doing the same thing yet again. Is
it really impossible for us to stick to a single style guide?
On Fri, Jan 30, 2015 at 4:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:
> Hi.
>
> Re: https://www.mediawiki.org/wiki/Design/Living_style_guide
>
> This page is kind of sad right now. It references
> <http://tools.wmflabs.org/styleguide> pretty heavily, but my understanding
> from <https://phabricator.wikimedia.org/T88036> is that
> <http://living-style-guide.wmflabs.org> is the actual style guide now? I'm
> not really sure and I'm worried that if I can't keep up, nobody else
> stands a chance! ;-) But really, we want to make sure everyone is
> discussing the same project.
>
> It would be great if someone more knowledgable than me (about the living
> style guide!) could update the wiki page and the description of
> <https://phabricator.wikimedia.org/tag/living-style-guide/>, at least with
> the best URL, if tools.wmflabs.org/styleguide is no longer it.
>
> MZMcBride
>
>
>
> _______________________________________________
> Design mailing list
> Design(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
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#Fr…
On Thu, Jan 8, 2015 at 2:33 AM, Timo Tijhof <ttijhof(a)wikimedia.org> wrote:
> A few quick thoughts:
>
> * 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.
>
>
> On 8 Jan 2015, at 04:18, S Page <spage(a)wikimedia.org> wrote:
>
> (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
>
>
>
Hi my name is Marty Anderson and I subscribed to your Design program some time ago thinking I could learn how to design my own software, what was I thinking. I’m currently working on a project and I was wondering wether you would like to be involved.
Regards
Marty Anderson
(I've CC'd the design-list, for all of these ideas. Design: please see the
earlier part of this thread (7 msgs) for more context, at
https://lists.wikimedia.org/pipermail/wikitech-l/2014-December/079793.html)
On Fri, Dec 19, 2014 at 8:15 PM, Krinkle <krinklemail(a)gmail.com> wrote:
> I'm not sure we should implement collapsible sections for desktop.
>
> If built and instrumented, one may find that users use it a fair bit and
> it may be better-than-nothing as solution for certain use cases. But I
> don't think collapsible sections would be an adequate feature for those use
> cases.
>
> Our table of contents is in desperate need of improvement. Having that be
> more accessible throughout the reading experience would be a big step
> forward[1] (much like the Wikipedia iOS app). Having a proper TOC means
> users don't have to collapse/expand anything.
>
> This would allow users to have a birds eye view of the document at all
> times, jump to any section at any time, whilst still being able to scroll
> through the document top to bottom as one would expect.
>
> From a performance viewpoint (as opposed to usability) we can still do
> optimisations such as not loading images until a section is accessed
> (lazy-load).
>
> -- Krinkle
>
> [1] Different ideas around an "aside"-accessible table of contents:
> * http://underscorejs.org/
> * Wikipedia iOS App: http://i.imgur.com/Sg0pqsg.jpg
> * User manual: http://asciidoctor.org/docs/user-manual/
>
>
Re: Collapsible - I strongly agree that collapsing content is potentially
harmful, and should be avoided as much as possible. It increases the
effort required to see content, and thereby reduces the likelihood of any
given section being seen. This is bad for readers (harder to access
knowledge), and bad for editors/potential-editors (harder to spot
errors/vandalism during casual reading). It goes for article content as
well as navigational elements and metadata. Footer-navboxes are frequently
collapsed, and I think this has established a harmful precedent. (See also
[[Linus's Law]], "given enough eyeballs, all bugs are shallow". We need
more eyeballs, not less.)
Re: ToC improvements - Agreed. As always, the difficulty is with fitting it
in somewhere, given the diversity of screen/browser-window sizes that each
user has or prefers. It would be especially useful on long articles, but it
would also take up the most space there. I'm not sure where the most recent
brainstorming and notes are, regarding the standard mediawiki sidebar? I
know it's been discussed a *lot* over the years...
Re: "birds eye view" - I really like this idea, taken to the 'completism'
level...
A number of text/code editors, have a "minimap" attached to the side.
http://did2memo.net/wp-content/uploads/2013/01/minimap-in-sublime-text-2.pnghttp://i.imgur.com/OIhkpfA.pnghttp://notepad-plus-plus.org/assets/images/docMap.png
It works as an enhanced-scrollbar, and as an overview, and it shows
text-selections from ctrl-F.
I think something similar to this would potentially help us:
* To better understand the scope of an article/section/entry, upon first
loading the page.
* As editors, to find & refine wall-of-text paragraphs.
* Encourage light-readers to scroll more, particularly if they see
thumbnails of images - in the same way that good textbooks can use images
as content-hooks.
* more?
It would need Increased font size for headings, to enable ToC-like
functionality. And some sort of minimal-version, for users who find
animated-aspects too distracting. What else?
It might be too complicated to be a global default (UX-wise, and/or
Performance-wise), but I'd love to see something like this as an option
(toggle or preference or gadget).
HTH. --Quiddity
(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
Hello Everyone,
It's my great pleasure to welcome Michelle Nguyen to the User Experience
team. Michelle joins us from Tenderloin Economic Development Project[1],
where she was a Marketing Communications Specialist and a Graphic Designer.
At TEDP, Michelle redesigned their website and was responsible in
maintaining their social media networks and online presence. She also
served as a community advocate with Mid-Market tech companies and
Tenderloin business owners, and in turn successfully developed Tasting the
Tenderloin - a series of lunches held at restaurants within the
neighborhood. Attendees and sponsors came from One Kings Lane, PeerSpace,
Spotify, Square, WeWork, and Zendesk.
Michelle joins the Wikimedia Foundation as a Visual Design Fellow, and will
be working on projects related to the User Interface standardization and
providing visual design support for other team projects.
Michelle graduated from San Francisco State University with a Bachelor of
Science in Visual Communication Design in 2012. Since graduation, she has
been working as a freelance designer in the realm of branding, animation,
and signage[2].
She is excited to be part of the Wikimedia Foundation’s mission. When she
is not at work, Michelle practices hand lettering styles, bike and
skateboard around the city, and nerd out on vegan recipes (even though she
eats everything including pork blood and duck embryos).
[image: Inline image 1]
Michelle will start today, Jan 6 working from the SF office, and will be
seated next to May on the 3rd floor. She will be working here with us
through July. Please come say Hi!
[1] www.tedpsf.org
[2] michellemeng.com
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0>
Hi all,
The Wikimedia Foundation's Design Research team,[1] Abbey Ripstra and Daisy
Chen, are looking for people to participate in research about editing.
They want to talk with both experienced editors and new editors to better
understand what you do, how you do it, what is difficult and what works
well with editing tools.
Currently, they're doing some hour-long research interviews over Google
Hangouts.
In the future, there will be other types of research programs, probably
including a card sorting task to determine how editing tools and tasks
could be organized to suit you best.
If you would like to hear about opportunities to participate in user-based
research, please sign up here:
https://wikimedia.qualtrics.com/SE/?SID=SV_6R04ammTX8uoJFP
This is a small survey to fill out so the research team knows a little bit
about your experience level and how to contact you to invite you to
research. You can always opt out again, and signing up does not obligate
you to participate.
Thank you!
[1] https://www.mediawiki.org/wiki/Design/Research
--
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation
