Page MenuHomePhabricator

WikiDev 16 working area: User interface presentation
Closed, ResolvedPublic


This is a working area for Wikimedia-Developer-Summit-2016.

Central problem

How to we make our software beautiful and joyful to use? How can we allow more fluid collaboration between designers and user interaction experts, and provide for safe experimentation as well as providing a smooth glidepath for successful experiments to graduate to mainstream usage in our deployed software?

Main session: Robertson 1: Monday, 11:30am

General discussion of our 2016 strategy for dealing with our central problem.

The goal of this session will be to capture a document that can be the first wiki draft as a charter for this area. Session agenda and minutes

Summary of the other session priorities

Prioritization list as of 2015-12-09 from @Krinkle and @Volker_E:

Must have:

Nice to have:

Less important:

Not at summit:

Other working areas (and the meta conversations about the idea of working areas) can/should be found here: T119018: Working groups/areas for macro-organization of RfCs for the summit

Related Objects

Event Timeline

RobLa-WMF claimed this task.
RobLa-WMF raised the priority of this task from to Needs Triage.
RobLa-WMF updated the task description. (Show Details)

I'd like to nominate T112984: Real Time Collaborative Editing, and T113004: Make it easy to fork, branch, and merge pages (or more), and T114454: [RFC] Visual Templates: Authoring templates with Visual Editor as "secondary" proposals to watch. Implementation of these would require "user interaction experiments" of the sort which seem to be contemplated by this working group, and we certainly wouldn't want to push forward with them without UX input.

(There are likely other summit proposals which this working group should keep a similar eye on; I haven't audited the entire set of proposals, I'm just listing the ones I'm personally familiar with/involved in.)

RobLa-WMF added a project: Design.
RobLa-WMF set Security to None.

I think this is a great area for the Front-end-Standards-Group to own. @Volker_E, is this something y'all can take on?

RobLa-WMF added a subscriber: Krinkle.

We spoke about this at the 2015-12-02 Front-end Standards Group meeting. @Volker_E agreed to take ownership, with the caveat that he'll need help in order to do this task well. @Krinkle volunteered to help out.

I think T114065: The future of MobileFrontend is a big deal, completely possible, and something that would benefit from discussion at the conference where it can get noticed by a wider audience who may be willing to pitch in with the refactorings that are needed. It would be especially useful if that discussion made the benefits of doing the work more visible to the Product Managers that may be present. I think this is often seen as a "developers want to pay down tech debt" topic rather than a "core features that move us towards first class non-traditional device support".

From @Volker_E and myself from a UI-Standardization and Front-end-Standards-Group perspective.

Must have:

Nice to have:

Less important:

Not at summit:

@Volker_E and @Krinkle: Excellent work on the first pass! This is really helpfully and clearly expressed. I copied and pasted your current version into the description, but please refine it as the discussion progresses.

FYI, I'm working on a very drafty-draft of the schedule now. See Monday 2016-01-04. In particular, my current bias is to hold the big room for this area at 2pm in the first version of the schedule. You all may choose to address the elephant in the room at this session, or you might instead choose to make it lightning talk city. We'll be refining this part of the schedule in this task.

Qgil triaged this task as Medium priority.Dec 11 2015, 8:11 AM

We talked about this in the Frontend Standards Group meeting this morning (notes will be posted to FSG/2015-12-16). I suggested that we might be combining skinning/presentation - possible combination of

  • T114071: Let's discuss the skin creation process
  • T114065: The future of MobileFrontend

...and that the people interested in this area may decide to use the Monday User Interface spot to talk through this one. Timo pointed out that any next generation skinning process would need to support the Mobile Frontend case, so that aspect of the combination is good, but there are other items in the MobileFrontend task that could be distractions from the overall skinning process. Having a smaller breakout session for "MobileFrontend other stuff" could work.

Per @cscott's edit from earlier today (schedule edit), he's no longer running a conflicting session.

A few questions we explored during this session:

  • What are we trying to solve here? Trevor pointed out this question: How can we change things without breaking everything?
  • Is the skin layout stable? Jiang from Google pointed out that it's hard to get infoboxes, and Timo pointed out that infoboxes aren't recognized in MediaWiki.
  • Semantic annotations? Jiang poitns out Wikipedia is multilingual. RTL vs LTR
  • Skins and mobile: is the goal to fix skins so that we don't have to hack on things like mobile frontend other methods? Next 3-5 years for skins perhaps?
  • What/who are we going to optimize for? Trevor points out "we don't know; lots of ideas"

More detailed notes here:

Real-time notes:

Take away points:

  • Improve backend methods that Skins use and create methods where missing. Move away from "blobby" datavars that can only be embedded. These methods should expose actual data instead of just html blobs.
  • Encourage skins to theme OOUI. Allow skins to provide an OOUI theme.
  • Extensions to adopt OOUI and should use less-variables from core to make them look "right", without hardcoding details of specific any skins or themes.
  • Need more methods like addPortletLink(). They should be provided and maintained by the skin (mw.skins) instead of mw.util. Exposed without requiring gadgets/extensions to hardcode any html when extending interfaces.
  • Allow wiki templates to add CSS to a page.
  • Wiki templates and Lua modules to use OOUI. (There are WIP patches introducing something like <button> and <icon> tags in wikitext, rendering OOUI icons and buttons. Make usable from Lua. Security for WMF production?)
  • Expose Less variables to MediaWiki:Common.css (.less) and gadgets. Allows them to make components that "fit in" with all current and future skins. Mobile friendly.
  • Make infobox, nav boxex etc. page components that are expanded by post-processing (e.g. <mw-infobox>). Not as part of wikitext parse. Reduces cache fragmentation and rendering inconsistencies after changes.
  • Standardise mark up for things like infoboxes, nav boxes etc. across projects/langs wikis. Does not require skin rendering or wiki specific styles to change per se.


  • Treat as first-class citizens: Apps, mobile web, desktop web, logged-in users. All with the same infrastructure and performance.
  • Ability to change skins without breaking extensions and gadgets. Provide page-level APIs instead of HTML or DOM being the API.
  • Avoid parser cache corruption and inconsistency when skins change. (Relates to T114542). Skin being a run-time layer that is not stuck in html page cache.

Action items with owners: (from T114071: Let's discuss the skin creation process)

  • Establish the scope of a skin, not what it currently is, but what it should be
  • Make themes (extension:theme style) happen with a practical API!

@GWicke, @Volker_E, and I had an impromptu meeting yesterday to discuss how this area might be part of the transition planned in T124504: Transition WikiDev '16 working areas into working groups and RFC @GWicke drafted in T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams"). I don't think we reached consensus in that meeting on the subject. @GWicke seemed skeptical, but we agreed it would be best if he expressed his concerns here. Gabriel?

Closing this as resolved.
The work is to be continued in the tasks like T114071 and the connection between ArchCom and Front-end-Standards-Group remains strong on a topics-specific-level.