MediaWiki

Architecture meetings/RFC review 2014-06-20

< Architecture meetings

18:00 UTC, Friday, 20 June, at #wikimedia-office connect.

Topics

edit

Today's topic: revamping MediaWiki's skin systems

Summary and logs

edit
  • Trevor's "Redo skin framework" proposal (sumanah, 18:31:08)
    • LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework (sumanah, 18:31:16)
    • https://gerrit.wikimedia.org/r/#/c/138368/ as an example: <MatmaRex> sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc. (sumanah, 18:32:22)
    • I really like the idea of taking generic info and flowing it into customizable/subclassable widgets (brion, 18:39:24)
    • (controller, controller/view, whatever) APIs though. (sumanah, 18:57:41)
    • <kaldari> TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though. (sumanah, 18:57:48)
    • ACTION: MatmaRex’s patches need review (brion, 18:58:06)
    • ACTION: MatmaRex to send to wikitech-l list of skin patches that additionally need review (sumanah, 18:58:35)
    • AGREED: <TrevorParscal> I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off; that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback (sumanah, 18:59:09)
    • ACTION: mobile web team should have a hand in this since it’s the main alt skin WMF uses internally (brion, 19:03:03)
    • goal of at least 2 WMF teams using this as a measure of success. <tfinc> MatmaRex: would be great to see community use as a barometer for success (sumanah, 19:03:04)
    • ACTION: mobile apps also interested in possible overlap with extensions and meta things (links etc) (brion, 19:03:16)
    • watch for more fleshing out of the RfC in the next week! (sumanah, 19:03:19)


Meeting ended at 19:03:52 UTC.


Action items

edit
  • MatmaRex’s patches need review
  • MatmaRex to send to wikitech-l list of skin patches that additionally need review
  • mobile web team should have a hand in this since it’s the main alt skin WMF uses internally
  • mobile apps also interested in possible overlap with extensions and meta things (links etc)


Action items, by person

edit
  • MatmaRex
    • MatmaRex’s patches need review
    • MatmaRex to send to wikitech-l list of skin patches that additionally need review
  • **UNASSIGNED**
    • mobile web team should have a hand in this since it’s the main alt skin WMF uses internally
    • mobile apps also interested in possible overlap with extensions and meta things (links etc)



Full log

edit
Meeting logs


18:00:10 <sumanah> #startmeeting Skins revamp | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours
18:00:10 <wm-labs-meetbot> Meeting started Fri Jun 20 18:00:10 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:10 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:10 <wm-labs-meetbot> The meeting name has been set to 'skins_revamp___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'
18:00:18 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20
18:00:28 <sumanah> #info Today we're talking about revamping MediaWiki's skins systems. I scheduled this before Erik sent out the note http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/077227.html about next week's front-end standardization chat.
18:00:44 <sumanah> First we'll be talking about MatmaRex's work, then Trevor's
18:00:53 <sumanah> #info FYI, next week we'll have that frontend architecture discussion here in #wikimedia-office 5:30 PM UTC on 25 June.
18:01:10 <sumanah> and 1 more thing
18:01:27 <sumanah> #info next week's regular RfC chat on IRC will be about https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes - which has multimedia implications
18:01:30 <Deskana> I have questions! But I will be back in 5 minutes. :)
18:01:35 <sumanah> but first, MatmaRex
18:01:42 <sumanah> #topic Bartosz Dziewoński's "Separating skins from core MediaWiki" work, including several patchsets that need review:
18:01:56 <sumanah> #link https://bugzilla.wikimedia.org/show_bug.cgi?id=65748
18:02:14 <sumanah> #link https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki
18:02:27 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20#Topics - that's where I listed the links to some changesets that need review:
18:02:38 <sumanah> (prepare for paste spam)
18:02:45 <sumanah> https://gerrit.wikimedia.org/r/136531  SkinTemplate: Move $stylename to Skin and soft-deprecate
18:02:45 <sumanah> https://gerrit.wikimedia.org/r/138652 Support for enabling skins in the installer
18:02:45 <sumanah> https://gerrit.wikimedia.org/r/135413 Separate Vector skin from core
18:02:45 <sumanah> https://gerrit.wikimedia.org/r/138795 Separate MonoBook skin from core
18:02:45 <sumanah> https://gerrit.wikimedia.org/r/138368 Stop using a suboptimal structure for Vector's variants menu
18:02:47 <sumanah> https://gerrit.wikimedia.org/r/138369 Stop using a suboptimal structure for Vector's variants menu (cont.)
18:02:50 <sumanah> https://gerrit.wikimedia.org/r/136615 SpecialVersion: Show 'Skins' and 'Extensions' in separate sections
18:03:46 <sumanah> Who here has read or commented on any of those - MatmaRex's proposal or one of the changesets?
18:04:00 <Deskana> I've read MatmaRex's proposal and I love it.
18:04:17 <Deskana> I read it and went "Wait, we HAVEN'T already done that?"
18:05:29 <Deskana> Are you mostly just waiting for code review?
18:05:29 <MatmaRex> haha :D
18:05:32 <sumanah> ashley, RoanKattouw, bawolff, I presume you've looked at a bit?
18:05:32 * bawolff wants us to continue shipping all existing skins (or at least a selection) with the tarball
18:05:39 <bawolff> otherwise, sounds great
18:05:54 <sumanah> hexmode: ^ do you have thoughts on bawolff's point there?
18:06:00 <MatmaRex> Deskana: mostly yes, but i still have a lot of stuff to do left
18:06:03 <ashley> aye, I've also read the proposal and as said, it's awesome :)
18:06:18 <Deskana> bawolff: I see no reason why we wouldn't do that, personally.
18:06:32 <MatmaRex> bawolff: so do i! but not entangled with core, and instead just like we ship extensions
18:06:42 <bawolff> yep, that sounds good to me
18:06:48 <Deskana> bawolff: The fact that the skins are now modular and separated from core is purely a technical code quality thing. It has nothing to do with our decisions on what skins we ship as default.
18:06:50 <ashley> skins are somewhat of an obscure area with a high bus factor and as such, it can -- and will -- make upgrading painful for third-party users using a custom skin (or, god forbid, a third-party instance that has *multiple* custom skins); nice to see it finally getting some attention from an experienced dev :)
18:07:15 <Deskana> MatmaRex: Okay, well, I'm not an engineer so I can't do that review myself, but I'll try prodding a few different channels for some review.
18:07:35 <bawolff> MatmaRex: To clarify (I skimmed very quickly) is vector going to move out of core too?
18:07:37 <MatmaRex> i'm not sure how the tarballs were built so far, but it can't possibly be hard to extend the tools to also bundle skins and not just extensions
18:07:40 <MatmaRex> bawolff: yes
18:07:53 <sumanah> Jon Robson and Ori Livneh are MatmaRex's GSoC mentors and are prime candidates for prodding for code review, Deskana ;-)
18:07:57 <bawolff> because I'm not sure how I feel about that, as then MediaWiki becomes unusable if 0 skins are installed
18:07:58 <MatmaRex> or most of all, even. it's the most problematic right now
18:08:17 <bawolff> and vector is the current fallback if an invalid skin name is specified
18:08:22 <MatmaRex> bawolff: i'm planning a minimal fallback skin instead of vector
18:08:29 <sumanah> hi jdlrobson2 - http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt is the logs so far, including us talking about prodding you for code reivew ;-)
18:08:38 <MatmaRex> so that MW doesn't fall over, and instead displays a friendly message that you should probably install some skins
18:08:42 <bawolff> Awesome :)
18:08:48 <RoanKattouw> sumanah: I like the principles behind MatmaRex's proposal, but I don't know enough about the skin system to judge the details
18:08:53 <jdlrobson2> yup it's on my review to do list
18:08:53 <mutante> could "nostalgia" be the fallback when 0 skins are installed?
18:09:07 <MatmaRex> mutante: heh
18:09:07 <^d> nostalgia doesn't exist in core either.
18:09:08 <TrevorParscal> My main comment is that the area you mention in step #1, about client side Skin API, I would like to work together on that, because it's an essential part of what my skin proposal does
18:09:27 <bawolff> Long live "standard"
18:09:28 <MatmaRex> the fallback skin will probably look pretty close to nostalgia (as in, having alost no CSS)
18:09:33 <MatmaRex> almost*
18:09:37 <gwicke> bawolff: +1 ;)
18:09:46 <MatmaRex> mutante: nostalgia actually requires a surprising amount of code to run right now
18:10:02 <mutante> MatmaRex: i just saw "In MediaWiki 1.24 it will come back - no longer as an extension, but as a real skin - with several improvements. See git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Nostalgia"
18:10:16 <MatmaRex> it has an entire layer on top of regular skin stuff that provides backwards-compatibility with, like, MW 1.5
18:10:17 <mutante> and that link is Not Found
18:10:22 <sumanah> MatmaRex: how long have you been waiting for code review? are there patches that need attention & you are blocked waiting for review?
18:10:24 <MatmaRex> mut
18:10:32 <jzimmerman> What is the rational for not including just a single default skin in the download and having a mechninism to download other skins on demand?
18:10:33 <MatmaRex> mutante: oh, that's interesting, but i didn't do that :P
18:10:57 <jzimmerman> I think the first time user experience is important to have a usable skin without configuration
18:10:57 <mutante> MatmaRex: gotcha
18:10:58 <TrevorParscal> MatmaRex: also, in removing skinStyles, your proposed inversion is interesting, but we need to make sure there's a way for a skin to provide a style for a feature, which prevents the feature from loading it's default style, or we will end up with really ugly CSS overriding hell
18:11:10 <MatmaRex> sumanah: the ones you linked. i'm not really blocked per se, but not having them merged does make further progress a bit more difficult
18:11:31 <kaldari> MatmaRex, sumanah: Is there anywhere I could get a tl;dr version of MatmaRex's work so far and what he has in mind? Is it part of what Trevor is proposing or separate?
18:11:39 <sumanah> separate
18:11:44 <MatmaRex> jzimmerman: what's the rationale for doing that? also, no one has implemented such a system yet
18:11:51 <bawolff> jzimmerman: you mean download on demand from the web interface? because there's technical reasons why that's scary (requiring write access to php files from the webserver)
18:11:57 <MatmaRex> jzimmerman: i'm not touching these areas right now anyway :)
18:12:25 <TrevorParscal> kaldari: there's only a small amount of overlap, and I'm asking he work together with me there, or skip it for now
18:12:30 <Deskana> I think jzimmerman's point is that we should have the default skin be something that's pretty usable, like Vector.
18:12:30 <jzimmerman> @bawolff yes, exactly
18:12:34 <Deskana> As opposed to a stripped down skin.
18:12:35 <MatmaRex> kaldari: the bold parts on https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki ? :)
18:12:35 <sumanah> btw I want to thank jzimmerman and Deskana especially for coming to this chat - important to get more perspectives on this stuff
18:12:45 <jzimmerman> @Deskana, yes, correct
18:12:57 <Deskana> It's not about the download mechanism at all.
18:12:58 <MatmaRex> Deskana: the default in the tarball will still be vector
18:13:05 <MatmaRex> the default in WMF environment too
18:13:31 <MatmaRex> only installation from git will be affected in any way (unless we decide to use submodules, in which case it won't be affected either)
18:13:42 <Deskana> MatmaRex: So the "default skin" (i.e. it comes in the distro as the default) is Vector, and you'll only be served Nostalgia if you intentionally rip out Vector and don't put anything else in there.
18:13:46 <mutante> wow, i didn't know we have an entire namespace "Skin_talk:" on mw.org
18:13:46 <Deskana> MatmaRex: Is that right?
18:13:54 <moizsyed> so people will be downloading a default skin (vector) when installing for first time?
18:13:58 <jzimmerman> vector, or whatever, my point being that there is a fully functianly default skin, not something that looks like a webpage where the css didn’t load right
18:14:07 <sumanah> MatmaRex: (my rule of thumb is that when my mentee asks for me to review something, I do it within 2 business days. so I think you should bug your mentors if your patchsets aren't reviewed by Wednesday. ;-) )
18:14:08 <bawolff> MatmaRex: Will there be backwards compat concerns with tarball users (Users upgrade MW by replacing entire directory, suddenly skins are gone)
18:14:35 <MatmaRex> TrevorParscal: what i had in mind was basically a hook that will let you mangle wgResourceModules in certain limited ways
18:14:52 <RoanKattouw> It sounds to me like it is possible for the release managers to release tarballs that include Vector and/or other skins and provide a smooth upgrade experience
18:14:55 <MatmaRex> Deskana: not Nostalgia, but rather a "nostalgia", but yes.
18:15:01 <RoanKattouw> What the tarball actually ships with is up to the release managers
18:15:04 <TrevorParscal> MatmaRex: It think you are on the right track there
18:15:06 <MatmaRex> moizsyed: no, it will be included in the download
18:15:07 <sumanah> #idea <RoanKattouw> It sounds to me like it is possible for the release managers to release tarballs that include Vector and/or other skins and provide a smooth upgrade experience
18:15:27 <MatmaRex> jzimmerman: as i said, vector will continue to be the default for normal users
18:15:33 <Deskana> jzimmerman: So we're fine from a UX perspective then. A Nostalgia-like skin is only served if someone intentionally fucks with their install by ripping out every single skin and putting nothing in there.
18:15:34 <moizsyed> MatmaRex: ok that sounds good
18:15:36 <RoanKattouw> So I think we should not sidetrack this conversation with release matters
18:15:44 <TrevorParscal> agreed
18:15:45 <Deskana> jzimmerman: And if they're at the point of doing that, then they're beyond our ability to help anyway. :P
18:15:57 <TrevorParscal> and, he says clearly is he not changing skins, adding or removing skins, etc.
18:16:02 <MatmaRex> bawolff: with the tarball? nothing quite like that, no
18:16:15 <MatmaRex> bawolff: unless you mean the part where we remove autodiscovery support for custom skins
18:16:32 <Deskana> TrevorParscal, RoanKattouw: Us non-technical folks are asking these questions to make sure we understand. We're not trying to divert the conversation. :)
18:16:32 <MatmaRex> bawolff: in which case there are deprecation warnings in 1.23 and 1.24, but after that the skins disappear unless you fix them, yes
18:16:33 <gwicke> TrevorParscal: can you talk a bit about where you see the separation between skin & data APIs?
18:16:33 <jzimmerman> does this mean “Nostalgia” will need to be maintained beyond what it is (or isn’t) now?
18:16:53 <MatmaRex> bawolff: i prepared a migration guide, though, a few people used it already, commented and liked it :)
18:17:02 <TrevorParscal> one sec, running upstairs
18:17:08 <MatmaRex> bawolff: https://www.mediawiki.org/wiki/Manual:Skin_autodiscovery
18:17:09 <kaldari> gwicke: I thought we weren't discussing Trevor's proposal yet
18:17:09 <bawolff> MatmaRex: I'm assuming that when the skins are separate, they would get enabled in the installer like extensions (There's a check box for which to enable)
18:17:16 <sumanah> #info <TrevorParscal> My main comment is that the area you mention in step #1, about client side Skin API, I would like to work together on that, because it's an essential part of what my skin proposal does
18:17:22 <bawolff> and yes skin autodiscovery is evil and needs to die
18:17:25 <MatmaRex> RoanKattouw: yes, that's exactly what i want
18:17:26 <sumanah> #info <TrevorParscal> MatmaRex: also, in removing skinStyles, your proposed inversion is interesting, but we need to make sure there's a way for a skin to provide a style for a feature, which prevents the feature from loading it's default style, or we will end up with really ugly CSS overriding hell
18:17:32 <gwicke> kaldari: ah, I thought it was a mix at this point; later then
18:17:52 <Deskana> jzimmerman: My understanding is no. It's not actually Nostalgia, just Nostalgia-like with highly stripped down CSS. We don't "support it" because it's just the fallback for what happens if you're fucking with MediaWiki in ways you shouldn't.
18:18:02 <MatmaRex> bawolff: yes, and i have a pending patch for that :)
18:18:14 <Deskana> jzimmerman: Basically, a fallback to avoid crashes, as opposed to intended usable functionality.
18:18:24 <MatmaRex> bawolff: https://gerrit.wikimedia.org/r/#/c/138652/
18:18:27 <Deskana> jzimmerman: (If I'm understanding correctly)
18:18:30 <jzimmerman> Deskana: thanks, i understand now
18:18:33 <bawolff> MatmaRex: So if someone upgraded their wiki by wholesale replacing mediawiki directory (which is common), they never run the installer, they never have an oportunity to "enable" the newly separated out skins, and if they were using a different skin suddenly it wont work
18:18:38 <ashley> MW should be "usable" without any extensions or skins, it's just not very good as such ;-)
18:18:49 <MatmaRex> Deskana: jzimmerman: exactly, yes
18:18:57 <kaldari> Trevor just arrived at the office
18:19:01 <sumanah> ashley: should it?
18:19:05 <sumanah> ;-)
18:19:14 <ashley> chances are you'll always want certain extensions (ParserFunctions, CheckUser, Scribunto?, etc.), and likewise, you probably want certain skins, too (MonoBook, maybe Vector, etc.)
18:19:17 <MaxSem> should!
18:19:29 <MatmaRex> bawolff: yes, that's a concern, and i considered what to do
18:19:42 <jzimmerman> MatmaRex: your proposal does not include any type of web interface for installing non-default skins at this point?
18:19:42 <MatmaRex> bawolff: basically we can do one of the two things to be as user-friendly as possible
18:19:58 <parent5446> I don't think it necessarily should. The idea of a modular Wikipedia is hopefully a goal we are aiming toward.
18:20:03 <MatmaRex> either we keep a very limited form of autodiscovery that will load the four "former core" skins if they are present
18:20:14 <TrevorParscal> I'm back
18:20:18 <MatmaRex> or we just displays warnings if there are skins which are installed but not enabled
18:20:19 <TrevorParscal> sorry for the disconnect
18:20:29 <sumanah> (btw MatmaRex thank you for letting us have this chat on a Friday night your time so San Franciscans can do it during their workday - I appreciate that)
18:20:32 <MatmaRex> (e.g. in update.php, or in the fallback skin if it's used)
18:20:32 * TrevorParscal is at his desk now
18:20:46 <sumanah> TrevorParscal: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt in case you missed anything, although I didn't see any disconnects
18:20:49 <MatmaRex> i'm leaning towards the second way, i think daniel friesen suggested the first
18:20:58 <ashley> jzimmerman: "web installers" of any kind are considered somewhat evil, as bawolff mention earlier, for various reasons (security/perms, etc.); I mean, I'd *love* if the installer would auto-generate LocalSettings.php *and* place it in the correct location, but instead it prompts you to download the autogenerated LS and put it in the correct dir
18:21:20 <moizsyed> thanks MatmaRex and sumanah for setting this up!
18:21:32 <Deskana> jzimmerman: I think that's a totally separate issue.
18:21:36 <kaldari> MatmaRex: Would there be a way for an extension to force enabling of a skin, for example, MobileFrontend is useless without enabling the Minerva skin.
18:21:39 <Deskana> jzimmerman: Outside the scope of MatmaRex's work.
18:21:40 <MatmaRex> jzimmerman: it will only work the way installing extensions works now. it will not download them for you, but it will enable them if they are already downloaded
18:21:47 <jzimmerman> I ask because MatmaRex mentioned a modern skinning system, and that’s how that work in most modern CMS
18:21:51 <MatmaRex> sumanah: (it's just early evening :) )
18:21:52 <Deskana> jzimmerman: It just so happens that his work makes it easier to do web installers, but that's tangential.
18:21:54 <bawolff> MatmaRex: I guess we could just put it very big in the Release notes too
18:21:57 <parent5446> kaldari: Dependency management. An entirely different issue
18:22:09 <Deskana> (again, if I'm understanding correctly)
18:22:12 <parent5446> Probably through Composer
18:22:14 <MatmaRex> kaldari: sure, just the way it works now
18:22:18 <bawolff> jzimmerman: Well there's multiple dimensions of "modern"
18:22:38 <ashley> MediaWiki is not technically a content management system, although it does a better job at that than most CMSes :p
18:22:45 <MatmaRex> kaldari: $wgValidSkinNames (which you must be using now) stays and becomes *the* way to add new skins
18:22:49 <bawolff> I think in this context modern is for the technical back-end, not the user management interface
18:23:08 <jzimmerman> bawolff: thats too bad ;)
18:23:13 <MatmaRex> bawolff: i will make release notes, yes
18:23:22 <MatmaRex> bawolff: it's on mw.org pages for the releases too
18:23:24 <sumanah> I wish Hershberger or Glaser were here
18:23:30 <kaldari> MatmaRex: Ah cool, then we're already doing it the way you envision on mobile :)
18:23:32 <MatmaRex> (well, on the page for 1.23 now, it will be on 1.24 and 1.25 too)
18:23:35 * sumanah pings hexmode again
18:23:51 <sumanah> ok, in a few minutes I want to switch over to talking to Trevor'
18:23:56 <sumanah> talking about Trevor's proposal
18:24:08 <RoanKattouw> So, I have a question
18:24:11 <sumanah> are there any last action items or facts to highlight?
18:24:11 <MatmaRex> kaldari: yes, i just want to abandon the old way dating back to MW 1.5 (or something) and only leave the "new" way which dates back to 1.12
18:24:12 <RoanKattouw> About the skinStyles thing
18:24:32 <MatmaRex> kaldari: all reasonably up-to-date third-party skins are using it already, too
18:24:32 <bawolff> jzimmerman: Although we also have to keep in mind our average users. Compared to say wordpress where we have single user controlled application, mediawiki installs tends to be maintained by "expert" users for a specific community
18:24:39 <RoanKattouw> I think in general, the notion that a skin should know about modules and style them (the proposed notion) makes more sense than a module knowing about a skin (the current notion)
18:24:43 <RoanKattouw> so that's good
18:24:46 <bawolff> jzimmerman: So in that context skin auto-install sort of makes less sense
18:24:49 <RoanKattouw> But I wonder how we'll do this for extensions
18:24:56 <bawolff> [although that's getting a bit off topic]
18:25:00 <RoanKattouw> For instance, the VisualEditor integration module has skin-specific styles
18:25:17 <MatmaRex> RoanKattouw: there's no reason why we can't keep supporting skinStyles
18:25:32 <MatmaRex> (unless you have an idea for a better system)
18:25:32 <RoanKattouw> We can't really put those styles in the skins, because VE is an extension and not part of core, so in most cases we'd want that to live in the extension
18:25:37 <RoanKattouw> Hmm
18:25:40 <jzimmerman> bawolff: have we though that *may* be a reason for less uptake than more user friendly CMSes?
18:25:42 <RoanKattouw> Yeah supporting skinStyles sounds fine
18:25:53 <TrevorParscal> Right, I mean we wouldn't want to bloat the skins with styles for every module
18:26:01 <RoanKattouw> It doesn't feel amazingly optimal to me but I have no grand ideas for a better system
18:26:15 <MatmaRex> RoanKattouw: like i mentioned earlier, what i want is basically a hook that will let you modify parts of $wgResourceModules
18:26:19 <bawolff> jzimmerman: Oh probably is. Buts its hard to be all things for all users
18:26:21 <jzimmerman> MatmaRex: before swe switch topics did you get all of your high priority questions or issues raised/answered?
18:26:29 <RoanKattouw> MatmaRex: Yeah that makes a lot of sense
18:26:40 <TrevorParscal> I'm in favor of allowing a new way, for the skin to provide a style for a module, which essentially adds a skinStyle entry to a module
18:26:43 <MatmaRex> RoanKattouw: in fact, passing $skinname and &$wgResourceModules['module']['skinStyles'] was one of my ideas
18:26:45 <TrevorParscal> but not getting rid of skin styles
18:26:48 <RoanKattouw> There's another use case I have for that too, so I look forward to that happening
18:27:16 <MatmaRex> jzimmerman: hey, i'm the one *answering* the questions here ;) (and i hope i didn't miss any)
18:27:44 <TrevorParscal> MatmaRex: I think you are good so far
18:27:50 <kaldari> TrevorParscal: personally I would prefer getting rid of skin-styles. I like the inversion idea.
18:28:03 <TrevorParscal> I think both have a use case
18:28:33 <sumanah> As a reminder, perhaps the single best thing y'all can do to help Bartosz's work move forward is to give code review comments - https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20#Topics has a list of some outstanding patchsets
18:28:41 <jzimmerman> MatmaRex: sometimes we teach by asking questions rather than answering them
18:28:41 <MatmaRex> it generally makes sense to use skinStyles in the extension was written later than the skin, and "the new way" if the skin was written after the extension
18:28:52 <parent5446> I think it is pretty trivial for an extension to use some hook right before render to see what the skin is and add extra modules if necessary.
18:28:59 <MatmaRex> oh yeah, totally do review my patches y'all! :D
18:29:13 <kaldari> TrevorParscal: although having extensions/skins be able to dynamically add skinstyles would probably solve the problem as well
18:29:13 <parent5446> I don't see any specific reason to continue maintaining skinStyles. There are definitely other solutions.
18:29:34 <TrevorParscal> kaldari: yes
18:29:35 <sumanah> MatmaRex: can you pick 2 patches you would love to have merged *today*?
18:29:53 <sumanah> #info discussion of skinStyles - future of promise or future of peril?
18:30:10 <sumanah> brion:  http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt
18:31:02 <brion> thx
18:31:08 * sumanah switches topics
18:31:08 <sumanah> #topic Trevor's "Redo skin framework" proposal
18:31:16 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework
18:31:21 <sumanah> ok gwicke - you had some thoughts?
18:31:22 <MatmaRex> sumanah: pick any :)
18:31:31 <kaldari> TrevorParscal: The RFC that you posted doesn't really explain exactly what a widget is or how it would be implemented. It just says that widgets are "server and client side objects which render/manage discrete elements on the page." My hope is that widgets are essentially data objects that include all the information about an element (for example the personal toolbar) and are accessible to both the server and client-side via APIs. The skins wo
18:31:31 <kaldari> consist of a controller that defines which widgets are used by that skin, a set of widget HTML templates for rendering the elements using the widget data, and CSS for styling that HTML. Is that close to what you have in mind as the implementation? If not, could you elaborate on the implementation (preferably using examples)?
18:31:31 <sumanah> MatmaRex: no, I'm asking you.
18:31:51 <sumanah> MatmaRex: if you pick 2 and ask people to look at them today, it's a lot easier. trust me
18:31:57 <MatmaRex> sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc.
18:32:03 <MatmaRex> one of mine is https://gerrit.wikimedia.org/r/#/c/138368/
18:32:21 <MatmaRex> there are several more by other people which i'd also like merged before i move out the skins, but i don't have links handy
18:32:22 <sumanah> #info https://gerrit.wikimedia.org/r/#/c/138368/ as an example: <MatmaRex> sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc.
18:32:29 <TrevorParscal> OK, so before we go on, let me define widget, in this context, so we don't go around in circles
18:32:34 <sumanah> MatmaRex: will you reply to wikitech-l with the links after this mtg?
18:32:37 <MatmaRex> can do
18:32:40 <sumanah> thx
18:32:42 * MatmaRex listens to TrevorParscal now
18:32:46 <ashley> I'm totally {{for}} redoing the skin system, but please please please also build a detailed migration guide -- I've had to update 10+ skins way too many times over subtle, badly-documented core MW changes that just happened to break stuff
18:32:47 * sumanah also listens
18:33:51 <TrevorParscal> A widget, is an object (in PHP or JavaScript) which represents a user interface control and, throughout the lifetime of the program, provides an API for interacting with and modifying that control
18:34:11 <gwicke> so it's a push model?
18:34:22 <gwicke> rather than a dependency tracking model?
18:34:33 <TrevorParscal> this is distinct from a template, which is is a unidirectional process
18:34:54 <parent5446> I think this RFC needs some sort of sequence diagram illustrating exactly what interactions are happening between the different skin components.
18:35:12 <gwicke> TrevorParscal: so you see KnockoutJS & Angular as unidirectional?
18:35:14 <TrevorParscal> A widget could use a template to render itself, but it would also abstract the the updating of information in the rendering, so you have a consistent API between creation and modification
18:35:37 <TrevorParscal> gwicke: are you here to troll me?
18:35:49 <gwicke> I'm seriously curious
18:36:31 <gwicke> I'm trying to work out what the difference in functionality is between reactive frameworks & widgets
18:36:33 <TrevorParscal> to the extend that KnockoutJS and Angular provide a persistent API for modifying rendered contents, they are effectively widgets and there is no difference
18:36:39 <parent5446> TrevorParscal: Do skins own the widgets? Or are they inserted into the skin by other components?
18:36:43 <kaldari> TrevorParscal: But I assume the skin would define which template the widget uses to render itself, correct?
18:37:40 <TrevorParscal> The skin would take data (navigation items, user information and content) and pass that data into widgets, which the skin can arrange
18:37:57 <TrevorParscal> the skin can also subclass standard widgets, to influence their rendering and behavior
18:38:27 <kaldari> So every widget will have a default rendering separate from the skins?
18:38:36 <TrevorParscal> a standard set of widgets, designed to present navigation, content and user information, would be provided, and each skin would subclass them as needed
18:38:44 <brion> let’s take a concrete example — say, “language links” <- would this be its own widget?
18:39:02 <TrevorParscal> yes
18:39:02 <kaldari> yes, an example would help greatly
18:39:07 <Deskana> So to test my understanding, MatmaRex's proposal is making skins modular rather than baked into core, and Trevor's proposal is about making skins themselves be part of a more generic framework?
18:39:11 <TrevorParscal> the input is the list of languages
18:39:17 <parent5446> OK, this proposal makes complete sense. Basically it's a modularization of the skinning engine, allowing separate overriding of rendering for specific components.
18:39:24 <brion> #info I really like the idea of taking generic info and flowing it into customizable/subclassable widgets
18:39:33 <Deskana> Okay, I explained that poorly.
18:39:52 <Deskana> Like there's a skin object with certain functions and parameters, and other skins extend that.
18:40:02 <Deskana> Rather than... well, whatever clusterfuck we've got now.
18:40:03 <TrevorParscal> The other side of this, is that on the client, we could also have a generic API for interacting with these standard widgets
18:40:04 <gwicke> TrevorParscal: so is the main difference between reactive templating & widgets subclassing vs. swapping partials?
18:40:26 <Deskana> I heard something about Vector extending Monobook the other day and I nearly cried.
18:40:35 <TrevorParscal> they are different approaches to the same effects, no?
18:40:45 <ashley> Deskana: Modern extends MonoBook ;-)
18:40:50 <brion> +1 for a clean client-side JS API
18:40:50 <TrevorParscal> Vector is a copy/paste/tweak of monobook
18:41:14 <Deskana> Oh dear.
18:41:32 <jzimmerman> TrevorParscal: will this have the side effect of forcing us to be better at dogfooding our own APIs and not using private methods for actions that don’t go through APIs or no change there?
18:41:48 <TrevorParscal> the client side API would be able to add a navigation item, or a personal tool, or whatever - a skin that changes how a widget works would also provide a handler on the client for modifying it, thus the persistent abstraction to modifying the rendering
18:42:02 <Deskana> I must've missed the lecture about how CopyPasteTweak is a valid alternative to object oriented programming. :P
18:42:17 <gwicke> TrevorParscal: so is the API model-driven, or more imperative?
18:42:27 <James_F> brion: We can give you a quick spin through OOUI development if you're curious at some point. (Offer goes for everyone, and the Wikimania presentation will have a prepared walk-through.)
18:42:40 <brion> James_F: i’d love a brown bag session or something sometime
18:42:46 <ashley> Deskana: it's "thanks" to the atrocity called SkinTemplate and mistakes made many, many years ago regarding MW's skinning system...
18:43:09 * brion takes blame for SkinTemplate but shares some of it with gwicke ;)
18:43:22 * gwicke hides
18:43:24 <TrevorParscal> jzimmerman: I think it will, I understand the problem as "this extension has to modify the skin, so it has 3 special cases for 3 skins and the rest are not supported" and we will be saying "this extension has to modify the skin, so we will use this standard API that all skins implement"
18:43:43 <Deskana> brion: I don't think anyone's out to blame anyone. MediaWiki is a fantastic innovation. It's just not scaled over time as well as we'd hoped.
18:43:47 <Deskana> brion: You're to be commended, not blamed.
18:43:49 <brion> :D
18:43:50 <TrevorParscal> ok, so another point that is central to this design
18:43:58 <TrevorParscal> so far, we have used our HTML output as the API
18:44:18 <TrevorParscal> some skins will have slightly different output to achieve cross browser compatibility for their varied designs
18:44:29 <TrevorParscal> aka. the CSS zen garden is a garden of lies
18:44:44 <gwicke> he!
18:44:46 <brion> heh
18:44:49 * Deskana adds that to the Bugzilla quips.
18:44:52 <bawolff> lol
18:44:53 <TrevorParscal> the approach I am proposing moves the API to JavaScript instead
18:45:04 <gwicke> a bit ironic given that CSS support is so much better these days
18:45:05 <TrevorParscal> where we can provide enough abstraction
18:45:09 <gwicke> than it used to be around 2004
18:45:31 <brion> css is great at many things, but it can’t, say, turn Vector into MobileFrontend or vice versa
18:45:55 <TrevorParscal> gwicke: we can talk later about some of the things that are STILL not fixed across browsers, don't believe the hype
18:45:56 <gwicke> yeah, it mainly can't change the position in the render flow
18:46:00 <kaldari> TrevorParscal: So how would widgets work without Javascript? Or does this solution require JS?
18:46:02 <RoanKattouw> Imagine how much it was a lie back in 2004 then :)
18:46:12 <ashley> what do you mean by "slightly" different output? various third-party skins are *entirely* different from core skins...modern might be a remodeled MonoBook, and Vector might be sorta based on MonoBook, but that doesn't mean all skins out there are like that...
18:46:29 <gwicke> RoanKattouw: it required a bunch of cursing and elbow grease
18:46:30 <TrevorParscal> kaldari: it would only require javascript to modify the skin dynamically on the client
18:46:42 <TrevorParscal> which requires JavaScript anyway
18:46:56 <TrevorParscal> modifications to be done on the server can be done through a similar (nearly identical) API in PHP
18:47:13 <TrevorParscal> depending on the feature you are trying to write, you may make some modifications on the server, client or both
18:47:41 <gwicke> TrevorParscal: where do you see the main difference vs. the Knockout ideas we've been pushing?
18:47:49 <James_F> (This API is waiting for the new version of PHP to do live on the WMF servers, right?)
18:48:03 <TrevorParscal> That this is based on object oriented programming
18:48:32 <gwicke> I see, so subclassing vs. partial substitution
18:48:44 <TrevorParscal> again, different approaches to the same end
18:48:53 <kaldari> TrevorParscal: so can you eloborate on what sort of functions/data will be included within the widget object? It sounds like it will include some aspects of model, view, and controller, which concerns me a bit. Feel free to use the Languages Links as an example.
18:48:56 * MatmaRex likes what TrevorParscal is saying
18:49:05 <TrevorParscal> I believe that we already use object oriented programming throughout both client and server, and it is comfortable, powerful and convenient
18:49:35 <Deskana> The non-technical Deskana is still trying to fully understand Trevor's proposal.
18:49:45 <brion> for feeding data into the widgets, are we thinking model objects, or structured arrays?
18:49:51 <TrevorParscal> kaldari: as with most user interfaces, the design is more like model + (view/controller), where view and controller are merged a bit
18:49:54 <Deskana> So it's about taking our horrible mess of a skin system and making it object oriented instead?
18:50:12 <brion> Deskana: at least, we would have smaller messes which could be more easily cleaned up :D
18:50:21 <gwicke> TrevorParscal: so the interface will be the model, as in reactive?
18:50:30 <Deskana> brion: I support minimisation of messes. :P
18:50:31 <TrevorParscal> I'm pretty open to using objects, but there would need to be good reason for it, structured arrays are cool too
18:50:32 <parent5446> Deskana: "object oriented" is kind of a broad term. Some people consider the current system "object oriented"
18:50:36 <MatmaRex> TrevorParscal: so for example, we would have a widget for a "portlet link", and the skin would have to provide a PHP and JS API for the equivalent of the mw.util.addPortletLink() function / PersonalUrls and similar hooks?
18:50:56 <parent5446> TrevorParscal: Objects (well, classes) have interfaces that can be enforced. Structured arrays do not.
18:50:59 <TrevorParscal> gwicke: the interface is not the model, it's literally the view
18:51:00 <Deskana> parent5446: From what I've heard, the current skin system is a bastardisation of object orientation.
18:51:10 <parent5446> :P Yeah that fits it perfectly
18:51:27 <gwicke> TrevorParscal: what's the motivation for giving up the model / view separation?
18:51:54 <TrevorParscal> MatmaRex: we can discuss the details of the API, but essentially yes, there would be a standard way of interacting with all parts of the skin
18:51:55 <gwicke> or perhaps more accurately, the 'drive everything from the model' paradigm
18:52:08 <Deskana> Sure, you can call it object orientation because it has the word "extends" in it, but "Vector extends Monobook" makes about as much sense as "Apple extends Orange".
18:52:19 <TrevorParscal> to some degree addPortletLink does this, of course if you read it's contents you will see why we should have skins provide implementations separately
18:52:20 <kaldari> I would also like to see an implementation that has good separation of concerns and a cleaner MVC separation.
18:52:28 <Deskana> I think I understand now.
18:52:31 <sumanah> we have about 8 min left, in case people want to wrap up and leave #info lines with their summary thoughts
18:52:31 <TrevorParscal> gwicke: nobody is talking about doing that
18:52:37 <MatmaRex> Deskana: i think what TrevorParscal is proposing is like the current system, but done well instead ;)
18:52:53 <MatmaRex> (more complicated internally, too, but also more flexible)
18:52:54 <gwicke> TrevorParscal: the addPortlet thing would be a departure IMO
18:53:04 <TrevorParscal> Indeed, MatmaRex sees that I am not revolutionizing, I am refactoring
18:53:34 <gwicke> in a model-driven reactive framework you'd just add a member to some portlet array instead
18:53:39 <TrevorParscal> the approach I wish to take is based on continuing good patterns, and cleaning up bad ones
18:53:50 <TrevorParscal> gwicke: I'm not able to do this with you right now
18:53:53 <parent5446> sumanah: somebody should establish some action items as to what the next steps for this RFC are
18:53:57 <brion> TrevorParscal: are there any ‘baby steps’ we can make on prototypnig this?
18:54:11 <brion> such as starting up a widget api and sticking it into a current skin as an example?
18:54:28 <kaldari> TrevorParscal: That makes sense I guess. My ideal vision would probably require rewriting MediaWiki from scratch ;)
18:55:03 <TrevorParscal> I think that if we can be preceptive enough to come up with a good API before rebuilding how skins construct themselves, that would be nice - again we will need to come up with an API that will work similarly on the server (ideally)
18:55:09 <gwicke> TrevorParscal: alright, would be nice if you could detail / motivate the differences a bit in the RFC though
18:55:18 <TrevorParscal> kaldari: one step at a time, but mine too
18:55:35 <brion> all in good time :D
18:56:07 <TrevorParscal> gwicke: I am happy to get into greater detail on the RFC, but you are asking questions that are more about implementation than API, and I believe this is a better time to talk about how people would interact with the system than how the system works internally
18:56:41 <TrevorParscal> any sufficient level of abstraction should be able to have it's implementation changed out without the API changing
18:56:41 <Deskana> I'd like to thanks MatmaRex, TrevorParscal and everyone else for explaining their projects to me in terms I can understand. :)
18:56:42 <gwicke> TrevorParscal: my question is actually mostly about the API style
18:56:48 <gwicke> not about the implementation
18:57:08 <MatmaRex> :)
18:57:09 <TrevorParscal> I fail to understand how, but we can talk another time perhaps? we have 3 minutes left
18:57:11 <kaldari> TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though.
18:57:28 <gwicke> kaldari: +1
18:57:38 <brion> any action items for moving forward?
18:57:41 <sumanah> #info (controller, controller/view, whatever) APIs though.
18:57:44 <sumanah> whoops
18:57:48 <sumanah> #info <kaldari> TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though.
18:57:51 <MatmaRex> brion: get someone to review my patches. :>
18:58:03 <TrevorParscal> I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off
18:58:06 <brion> #action MatmaRex’s patches need review
18:58:32 <gwicke> TrevorParscal: yeah, +1 on that
18:58:34 <TrevorParscal> that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback
18:58:35 <sumanah> #action MatmaRex to send to wikitech-l list of skin patches that additionally need review
18:58:35 <brion> nice
18:58:41 <kaldari> TrevorParscal: +1
18:58:58 <sumanah> I'm gonna #agreed that
18:59:09 <sumanah> #agreed <TrevorParscal> I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off; that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback
18:59:09 <TrevorParscal> again, this is a detail I feel is important to include in the RFC, but I feel like the API on the client and server is probably not affected by it
18:59:36 <gwicke> the model basically becomes the API
18:59:41 <tfinc> reading the backscroll here i can see that we've spent a lot time within finer grained details, implementation, etc. what are the overlaps with working with existing teams to allow them to guide this project along ?
18:59:43 <sumanah> do people have any requests for Trevor that we should mark as action items? or TrevorParscal do you have any requests for the group? for info?
18:59:51 <TrevorParscal> So, the plan is that I will be spending 80% of my time during July and August working on this, and other UI standardization work
19:00:20 <parent5446> I think an action item is just there needs to be a more concrete description of what the API structure is going to look like, and how it is going to behave both server-side and client-side.
19:00:41 <sumanah> brion: do you agree?
19:00:53 * sumanah knows we need to wrap up in a minute
19:00:54 <TrevorParscal> tfinc: yes, thank you for bringing it back to higher level questions - my objective is to deprecate but still support existing methods of modifying skins (addPortletLink) and port all existing skins
19:00:59 <gwicke> TrevorParscal: I think it would also be interesting on the RFC to have information on why you feel that reactive frameworks don't address our needs
19:01:06 <TrevorParscal> teams should be minimally affected by the shift
19:01:08 <kaldari> TrevorParscal: Of course not everything that might be requested by the client can be known in advance by the server though, so it's still important to have model-based APIs available to the client.
19:01:23 <tfinc> ultimately the framework, standardization, etc can be as beautiful as we want it but if only a single team uses it then we haven't hit our goal
19:01:36 <TrevorParscal> but I would like to specifically work with Mobile to see how we can ensure the design makes it possible for MobileFrontend to get converted as well
19:01:44 <brion> *nod*
19:01:47 <TrevorParscal> by existing skins, I mean the 4 in production
19:01:50 <MatmaRex> tfinc: don't forget non-WMF usage
19:01:59 <tfinc> thus i put a goal of *2* teams using it as a sign of success
19:02:01 <Deskana> brion: How does this tie into apps? Does it?
19:02:03 <TrevorParscal> and the goal is also to get MobileFrontend as well - which is part of the UI standardization goals anyway
19:02:03 <brion> i’m also curious if there’ll be any overlap with apps extra metadata
19:02:06 <MatmaRex> i can see this being used by and loved by third-party skin developers
19:02:08 <James_F> tfinc: Absolutely.
19:02:18 <brion> Deskana: potentially extensiony things could have to integrate with the apps and we’d want to plan for that yeah
19:02:21 <sumanah> ashley: looking forward to your continued involvement as a rep of the non-WMF MediaWiki-running community
19:02:37 <tfinc> MatmaRex: would be great to see community use as a barometer for success
19:02:38 <gwicke> brion: there's a lot of overlap there
19:02:44 <kaldari> tfinc: +1
19:03:00 <TrevorParscal> we are 2 minutes over, I am going to be fleshing out the RFC in the next week
19:03:03 <brion> #action mobile web team should have a hand in this since it’s the main alt skin WMF uses internally
19:03:04 <sumanah> #info goal of at least 2 WMF teams using this as a measure of success. <tfinc> MatmaRex: would be great to see community use as a barometer for success
19:03:09 <tfinc> thank you TrevorParscal
19:03:16 <brion> #action mobile apps also interested in possible overlap with extensions and meta things (links etc)
19:03:19 <sumanah> #info watch for more fleshing out of the RfC in the next week!
19:03:25 <TrevorParscal> I'm happy to meet with people on IRC or in person about this work, and I will be publishing plans for it publicly both on wiki and on list
19:03:34 <Deskana> brion: Cool. So not much for us to worry about just yet.
19:03:40 <TrevorParscal> not yet
19:03:41 <James_F> Deskana: One of the VE team has made a (non-MW) app using OOUI; might be worth discussing if it's useful.
19:03:47 <sumanah> ok, I'm callin' it. Thanks all
19:03:51 <kaldari> TrevorParscal: Thanks Trevor, look forward to seeing more info in the RfC :)
19:03:52 <sumanah> #endmeeting
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-06-20&oldid=5068591"