Talk:Requests for comment/Redo skin framework

Feedback

Re: redoing the skins system: yes, please! Even as a draft, I think this RFC looks very good. Implementing this RFC is a goal for 2014? (cc: Dantman, Isarra, Matma Rex) --MZMcBride (talk) 01:56, 17 April 2014 (UTC)

I can't speak to official resource allocation, but I'm pretty sure that if I could peel away some time this summer or fall from VisualEditor and pair with someone who might have more backend focus to compliment my skillset (as Roan did with ResourceLoader) it could certainly be accomplished this year. I would really like to see that happen, so that is essentially going to be my pitch should this gain some momentum. I'm aware of the work you have in mind this summer, as far as reorganizing skins, and I think this work would need to be synchronized with that as well. Trevor Parscal (talk) 07:18, 17 April 2014 (UTC)

Oh gods I hope this happens. -— Isarra ༆ 00:26, 30 April 2014 (UTC)

I second MZMcBride's "yes, please!". I think this is a great RFC and it has my full support. It

• has been needed for a long time
• has the potential to affect a great many fringe-developers (skinning is usually my first foray into a new project)
• has a clearly defined goal
• is generally awesome

--Daniel Renfro 17:18, 16 June 2014 (UTC)

Jack Phoenix would be a good one to get involved too, since he's probably the single most active developer of skins these days. He'd both have an idea of what we need and perhaps how it could be done, and what we already have that does work. -— Isarra ༆ 00:26, 30 April 2014 (UTC)

I'm still working on the general when and less on the detailed how. but indeed I will be pulling in active skin developers. When Catrope and I made ResourceLoader we made a very detailed proposal, got feedback, had many discussions with people both in the front-end space and otherwise, and eventually produced something that met everyone's needs as much as possible. We also picked up help from people like Krinkle who became major contributors and later became maintainers. I believe this process was successful, and plan to do something very similar with skins. I will make sure to get in touch with Jack Phoenix as things progress, but I will also be reaching out more generally for others as well. Trevor Parscal (talk) 15:47, 23 May 2014 (UTC)

As a developer working for a company that does a lot of MediaWiki customizations and skinning I would really appreciate a proper redo of the skin system. The RFC sounds pretty exciting and I want to express my support for it.
Looking at all the suff that's going in this area (UX Standardization, Agora, MediaWiki UI, Mobile Frontend, Knockout/TAssembly, Winter, ...) I think this has to be well coordinated.
I'd love to see a good implementation of a modern templating engine (like Knockout, mentioned below), a good seperation of presentation layer from business logic and a predefined set of styleable components ("widgets"), but I'm a litte afraid that this all might be too much to be a realistic goal. But on the other hand, maybe it's not. --Osnard (talk) 06:10, 21 July 2014 (UTC)

Relationship to OutputPage RFC

Hi Trevor, thanks for submitting this! This seems like a direction we pretty clearly need to go in. Do you see this RFC being completely complementary to the OutputPage refactor proposal (which could still continue to proceed independently), or something that would need to be accounted for in any rework of OutputPage? -- RobLa-WMF (talk) 19:18, 17 April 2014 (UTC)

I will have to familiarize myself with the OutputPage refactor proposal when I return to work (on vacation right now) to answer this accurately, but I believe that the benefits of doing them in tandem are surely going to be offset by the slowness of needing consensus on the design of both changes to proceed with any. If I could advise on the output page stuff I believe we can gain better separation without slowing things down. Trevor Parscal (talk) 15:42, 23 May 2014 (UTC)

Links to stuff

Add items here! (And remove items once they're added to the RfC itself, or if not useful/pertinent). HTH. –Quiddity (talk) 19:30, 25 June 2014 (UTC)

• Separating skins from core MediaWiki (and /Progress) which is part of the removal of Manual:Skin autodiscovery
• VisualEditor/Skin requirements
• Manual:Gallery of user styles
• Category:Skinning - Examples and sources of inspiration
  • Chameleon Skin by Stephan Gambke - Nice server side component model, XML based skin declaration.
  • Booty/Skinny by Andru Vallance - Good approach to split monolitic structure into sub-template files
• Developer hub#Help for skin developers
• Layout architecture of MediaWiki pages
• Design Team
  • UX standardization
  • Agora/Engineering
  • Wikimedia Foundation Design/status
  • Trello: Mediawiki.ui
• Category:Skin extensions
• Category:Design audit
• Architecture meetings/RFC review 2014-06-20 - Discussion of revamping MediaWiki's skin systems: Trevor Parscal's "Redo skin framework" and Bartosz Dziewoński's "Separating skins from core MediaWiki" work
• https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-25-17.30.log.html (pending onwiki page creation)
• Requests for comment/HTML templating library
  • Requests for comment/HTML templating library/Knockoff - Tassembly
• Architecture Summit 2014/RFC clusters (probably many?)
• https://xkcd.com/927/

June 25th meeting

IRC log from the 25 June 2014 meeting. Sharihareswara (WMF) (talk) 18:57, 7 July 2014 (UTC)

Problem statement, Goals / Requirements, existing vs. new solutions

I think it would be useful to put more effort into making the problem statement more precise, and explicitly define the goals and requirements of this RFC. These can then be discussed on their own merits.

With an agreement on the goals & requirements it then becomes easier to evaluate existing and new solutions. I would love to see such a discussion in this RFC as well, ideally with sufficient detail on new proposed solutions to allow at least a cursory evaluation. -- Gabriel Wicke (GWicke) (talk) 21:06, 9 July 2014 (UTC)

I'm sorry you didn't find the problem statement clear. I think other people did, so maybe you could ask a more specific question about it and I could do my best to answer it. The page got modified by a lot of people and much of the information was contradictory or generally incorrect. I have just gone through the entire proposal and ensured it is correct and I believe complete enough for this early stage. Please give it another read and let me know if you have additional questions.Trevor Parscal (talk) 04:07, 10 July 2014 (UTC)

Right now it's a bit confusing because we launch right in to specifics about the HTML output and APIs. That's not really a general problem statement. Perhaps we could begin with a summary/thesis statement, like "The structure of MediaWiki skins is highly inflexible, and is often dependent on direction manipulation of HTML output, rather than through well-designed APIs. This lack of abstraction results in a skin architecture that is brittle and ultimately deters developers from creating great new skins." That could be wrong, but I'm following Cunningham's Law here. ;) Steven Walling (WMF) • talk 17:46, 10 July 2014 (UTC)

In addition to Steven's point, I still think the goals of this RFC deserve to be more clearly defined in its own section. The 'principles' section at the end of the RFC has some of this material, but arguably also contains some of the proposed solution. Maybe you could move this between 'Problem' and 'Solution' and trim it down to the bare goals? In my experience, a good benchmark for a goal is whether it is useful to evaluate potential solutions. Basically 'what do we want to achieve', not 'how'. -- Gabriel Wicke (GWicke) (talk) 19:20, 10 July 2014 (UTC)

What's the value to end-users?

To piggy back a bit off of Gabriel's question to more clearly understand the problem, I'd like to better understand what the problem is that this resolves from the user's perspective. Is this RFC just resolving problems for the engineers who work on Mediawiki skins, or does this provide value to our users? To engineers, I think there is an intuitive understanding of how this RFC benefits our end users, however I think if this RFC would be stronger if it were framed from the perspective of delivering value to our users - rather than just repaying technical debt. I think this could be achieved by something along the lines of making the end goal of this RFC to be delivering a responsive skin for Mediawiki. A requirement of delivering a responsive skin could (and should) be the deeply needed reworking of the skin framework. I think approaching it from this perspective - letting the thing the user interacts with drive the technical requirements - will set this project up to more successfully 'break the silos' we all keep talking about internally. With up-front design and product involvement, and with an approach of iteratively and frequently delivering a responsive skin (and validating the decisions made as we go), we would be more certain earlier on that the work we put into this project is worthwhile and truly serves end-users. Further, driving this from the perspective of the users helps everyone working on this project better empathize with our users, which has the benefit of calibrating work against users' needs - ideally ensuring that we are not spending effort on things that are less or not valuable to them. Arthur Richards (talk) 21:24, 10 July 2014 (UTC)

This RFC does not propose to change anything that end-users will be aware of, so it essentially provides no value to them immediately. However by paying off this technical debt, we can make it easier to make changes that do provide value to end users.Trevor Parscal (talk) 22:37, 10 July 2014 (UTC)

July 10 IRC RFC review meeting

Architecture_meetings/RFC_review_2014-07-10

Prototyping Alternative Solutions

During the July 10th IRC meeting, Tim Starling mentioned prototyping alternative solutions. I'm excited about this because I have experience with some technologies that partially solve the problem described by this RFC. I would like to prototype an alternative solution and help enlighten the eventual decision. If anyone's interested, please encourage me to go further.

So I follow and agree with the solution to the described problem. But I wonder if the described problem is too tied to the current implementation. It may be useful to describe in general the problem that our skinning system has to solve. For example, what level of user interaction does it have to deal with? The CSS can be responsive to render on mobile but how responsive do the widgets have to be? Should they be able to simplify their interactivity for example? I feel that details like this would help inform a better design. But, assuming the problem is still vague, here's where I differ in thinking about a solution.

The main problem I have is with eventing. I believe events complicate code and Reactive programming is becoming a popular alternative. So I agree with the first paragraph of the solution as written, very well put. Skins are collections of widgets, and widgets are extensible and decoupled from the world via APIs. But, in my experience, relying on an event bus to do the communication complicates code needlessly. Basically, you have to keep making it explicit that you care about the model updating the output and vice versa. So there are a few solutions to this, and the one I'm most familiar with is knockout. Knockout is not opinionated and can be used as a library that provides some basic primitives which partially solve our problem. A knockout component is basically a widget and knockout subscribables allow fine grained control of reactivity. For example, a pureComputed property goes to sleep when nobody is actively looking for it to change, improving performance. Reactive programming is not without its faults, but I think it's different enough from the proposed solution to warrant a prototype. So, is anyone else interested? DAndreescu (talk)

As mentioned above I'd love to see a Knockout implementation. If Tim Starling encurages prototyping and you have the time for it I think you should do it. In this context an eye should be kept on Gabriel Wicke's TAssembly. --Osnard (talk) 06:00, 21 July 2014 (UTC)

What's the status?

After the two skin discussions above, redo skins became a topic for the Frontend standards group. The last meeting I can see is Frontend standards group/2014-10-09-Weekly#Trevor:_Skin_refactor. There is no phabricator task for the work as far as I can tell. -- SPage (WMF) (talk) 18:53, 9 June 2015 (UTC)