[17:56:53] OK, talking about skin revamp here in 5 min https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20 [17:57:12] hello [17:57:19] Hi TrevorParscal [17:57:27] hi MatmaRex [17:57:38] hi [17:57:46] * ashley waves at everyone [17:58:03] Hi ashley! [17:58:13] Can we talk about the skin stuff second? I'm in the car on my way in, and I have internet connectivity, but in about 10 minutes I will have to walk upstairs [17:58:27] TrevorParscal: yes, we can talk about your skin proposal 2nd [17:58:32] thank you [17:58:38] about time the skin system gets the lovin' it needs ;-) [17:58:41] :) [18:00:10] #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] 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] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [18:00:10] 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] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20 [18:00:28] #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] First we'll be talking about MatmaRex's work, then Trevor's [18:00:53] #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] and 1 more thing [18:01:27] #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] I have questions! But I will be back in 5 minutes. :) [18:01:35] but first, MatmaRex [18:01:44] #topic Bartosz Dziewoński's "Separating skins from core MediaWiki" work, including several patchsets that need review: [18:01:56] #link https://bugzilla.wikimedia.org/show_bug.cgi?id=65748 [18:02:14] #link https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki [18:02:27] #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] (prepare for paste spam) [18:02:45] https://gerrit.wikimedia.org/r/136531 SkinTemplate: Move $stylename to Skin and soft-deprecate [18:02:45] https://gerrit.wikimedia.org/r/138652 Support for enabling skins in the installer [18:02:45] https://gerrit.wikimedia.org/r/135413 Separate Vector skin from core [18:02:45] https://gerrit.wikimedia.org/r/138795 Separate MonoBook skin from core [18:02:45] https://gerrit.wikimedia.org/r/138368 Stop using a suboptimal structure for Vector's variants menu [18:02:47] https://gerrit.wikimedia.org/r/138369 Stop using a suboptimal structure for Vector's variants menu (cont.) [18:02:50] https://gerrit.wikimedia.org/r/136615 SpecialVersion: Show 'Skins' and 'Extensions' in separate sections [18:03:46] Who here has read or commented on any of those - MatmaRex's proposal or one of the changesets? [18:04:00] I've read MatmaRex's proposal and I love it. [18:04:17] I read it and went "Wait, we HAVEN'T already done that?" [18:05:29] Are you mostly just waiting for code review? [18:05:29] haha :D [18:05:32] 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] otherwise, sounds great [18:05:54] hexmode: ^ do you have thoughts on bawolff's point there? [18:06:00] Deskana: mostly yes, but i still have a lot of stuff to do left [18:06:03] aye, I've also read the proposal and as said, it's awesome :) [18:06:18] bawolff: I see no reason why we wouldn't do that, personally. [18:06:32] bawolff: so do i! but not entangled with core, and instead just like we ship extensions [18:06:42] yep, that sounds good to me [18:06:48] 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] 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] 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] MatmaRex: To clarify (I skimmed very quickly) is vector going to move out of core too? [18:07:37] 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] bawolff: yes [18:07:53] Jon Robson and Ori Livneh are MatmaRex's GSoC mentors and are prime candidates for prodding for code review, Deskana ;-) [18:07:57] because I'm not sure how I feel about that, as then MediaWiki becomes unusable if 0 skins are installed [18:07:58] or most of all, even. it's the most problematic right now [18:08:17] and vector is the current fallback if an invalid skin name is specified [18:08:22] bawolff: i'm planning a minimal fallback skin instead of vector [18:08:29] 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] so that MW doesn't fall over, and instead displays a friendly message that you should probably install some skins [18:08:42] Awesome :) [18:08:48] 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] yup it's on my review to do list [18:08:53] could "nostalgia" be the fallback when 0 skins are installed? [18:09:07] mutante: heh [18:09:07] <^d> nostalgia doesn't exist in core either. [18:09:08] 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] Long live "standard" [18:09:28] the fallback skin will probably look pretty close to nostalgia (as in, having alost no CSS) [18:09:33] almost* [18:09:37] bawolff: +1 ;) [18:09:46] mutante: nostalgia actually requires a surprising amount of code to run right now [18:10:02] 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] it has an entire layer on top of regular skin stuff that provides backwards-compatibility with, like, MW 1.5 [18:10:17] and that link is Not Found [18:10:22] 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] mut [18:10:32] 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] mutante: oh, that's interesting, but i didn't do that :P [18:10:57] I think the first time user experience is important to have a usable skin without configuration [18:10:57] MatmaRex: gotcha [18:10:58] 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] 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] 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] separate [18:11:44] jzimmerman: what's the rationale for doing that? also, no one has implemented such a system yet [18:11:52] 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] jzimmerman: i'm not touching these areas right now anyway :) [18:12:25] 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] I think jzimmerman's point is that we should have the default skin be something that's pretty usable, like Vector. [18:12:30] @bawolff yes, exactly [18:12:34] As opposed to a stripped down skin. [18:12:39] kaldari: the bold parts on https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki ? :) [18:12:39] 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] @Deskana, yes, correct [18:12:57] It's not about the download mechanism at all. [18:12:58] Deskana: the default in the tarball will still be vector [18:13:05] the default in WMF environment too [18:13:31] 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] 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] wow, i didn't know we have an entire namespace "Skin_talk:" on mw.org [18:13:46] MatmaRex: Is that right? [18:13:54] so people will be downloading a default skin (vector) when installing for first time? [18:13:58] 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] 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] MatmaRex: Will there be backwards compat concerns with tarball users (Users upgrade MW by replacing entire directory, suddenly skins are gone) [18:14:35] TrevorParscal: what i had in mind was basically a hook that will let you mangle wgResourceModules in certain limited ways [18:14:52] 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] Deskana: not Nostalgia, but rather a "nostalgia", but yes. [18:15:01] What the tarball actually ships with is up to the release managers [18:15:04] MatmaRex: It think you are on the right track there [18:15:06] moizsyed: no, it will be included in the download [18:15:07] #idea 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] jzimmerman: as i said, vector will continue to be the default for normal users [18:15:33] 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] MatmaRex: ok that sounds good [18:15:36] So I think we should not sidetrack this conversation with release matters [18:15:44] agreed [18:15:45] jzimmerman: And if they're at the point of doing that, then they're beyond our ability to help anyway. :P [18:15:57] and, he says clearly is he not changing skins, adding or removing skins, etc. [18:16:02] bawolff: with the tarball? nothing quite like that, no [18:16:15] bawolff: unless you mean the part where we remove autodiscovery support for custom skins [18:16:32] 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] 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] TrevorParscal: can you talk a bit about where you see the separation between skin & data APIs? [18:16:33] does this mean “Nostalgia” will need to be maintained beyond what it is (or isn’t) now? [18:16:53] bawolff: i prepared a migration guide, though, a few people used it already, commented and liked it :) [18:17:02] one sec, running upstairs [18:17:08] bawolff: https://www.mediawiki.org/wiki/Manual:Skin_autodiscovery [18:17:09] gwicke: I thought we weren't discussing Trevor's proposal yet [18:17:09] 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] #info 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] and yes skin autodiscovery is evil and needs to die [18:17:25] RoanKattouw: yes, that's exactly what i want [18:17:26] #info 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] kaldari: ah, I thought it was a mix at this point; later then [18:17:52] 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] bawolff: yes, and i have a pending patch for that :) [18:18:14] jzimmerman: Basically, a fallback to avoid crashes, as opposed to intended usable functionality. [18:18:24] bawolff: https://gerrit.wikimedia.org/r/#/c/138652/ [18:18:27] jzimmerman: (If I'm understanding correctly) [18:18:30] Deskana: thanks, i understand now [18:18:33] 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] MW should be "usable" without any extensions or skins, it's just not very good as such ;-) [18:18:49] Deskana: jzimmerman: exactly, yes [18:18:57] Trevor just arrived at the office [18:19:01] ashley: should it? [18:19:05] ;-) [18:19:14] 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] should! [18:19:29] bawolff: yes, that's a concern, and i considered what to do [18:19:42] MatmaRex: your proposal does not include any type of web interface for installing non-default skins at this point? [18:19:42] bawolff: basically we can do one of the two things to be as user-friendly as possible [18:19:58] I don't think it necessarily should. The idea of a modular Wikipedia is hopefully a goal we are aiming toward. [18:20:03] either we keep a very limited form of autodiscovery that will load the four "former core" skins if they are present [18:20:14] I'm back [18:20:18] or we just displays warnings if there are skins which are installed but not enabled [18:20:20] sorry for the disconnect [18:20:29] (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] (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] 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] i'm leaning towards the second way, i think daniel friesen suggested the first [18:20:58] 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] thanks MatmaRex and sumanah for setting this up! [18:21:32] jzimmerman: I think that's a totally separate issue. [18:21:36] 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] jzimmerman: Outside the scope of MatmaRex's work. [18:21:40] 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] I ask because MatmaRex mentioned a modern skinning system, and that’s how that work in most modern CMS [18:21:51] sumanah: (it's just early evening :) ) [18:21:52] jzimmerman: It just so happens that his work makes it easier to do web installers, but that's tangential. [18:21:54] MatmaRex: I guess we could just put it very big in the Release notes too [18:21:57] kaldari: Dependency management. An entirely different issue [18:22:09] (again, if I'm understanding correctly) [18:22:12] Probably through Composer [18:22:14] kaldari: sure, just the way it works now [18:22:18] jzimmerman: Well there's multiple dimensions of "modern" [18:22:38] MediaWiki is not technically a content management system, although it does a better job at that than most CMSes :p [18:22:45] kaldari: $wgValidSkinNames (which you must be using now) stays and becomes *the* way to add new skins [18:22:49] I think in this context modern is for the technical back-end, not the user management interface [18:23:08] bawolff: thats too bad ;) [18:23:13] bawolff: i will make release notes, yes [18:23:22] bawolff: it's on mw.org pages for the releases too [18:23:24] I wish Hershberger or Glaser were here [18:23:30] MatmaRex: Ah cool, then we're already doing it the way you envision on mobile :) [18:23:32] (well, on the page for 1.23 now, it will be on 1.24 and 1.25 too) [18:23:36] * sumanah pings hexmode again [18:23:51] ok, in a few minutes I want to switch over to talking to Trevor' [18:23:56] talking about Trevor's proposal [18:24:08] So, I have a question [18:24:11] are there any last action items or facts to highlight? [18:24:11] 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] About the skinStyles thing [18:24:31] kaldari: all reasonably up-to-date third-party skins are using it already, too [18:24:32] 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] 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] so that's good [18:24:46] jzimmerman: So in that context skin auto-install sort of makes less sense [18:24:49] But I wonder how we'll do this for extensions [18:24:56] [although that's getting a bit off topic] [18:25:00] For instance, the VisualEditor integration module has skin-specific styles [18:25:17] RoanKattouw: there's no reason why we can't keep supporting skinStyles [18:25:32] (unless you have an idea for a better system) [18:25:32] 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] Hmm [18:25:40] bawolff: have we though that *may* be a reason for less uptake than more user friendly CMSes? [18:25:42] Yeah supporting skinStyles sounds fine [18:25:53] Right, I mean we wouldn't want to bloat the skins with styles for every module [18:26:01] It doesn't feel amazingly optimal to me but I have no grand ideas for a better system [18:26:15] RoanKattouw: like i mentioned earlier, what i want is basically a hook that will let you modify parts of $wgResourceModules [18:26:19] jzimmerman: Oh probably is. Buts its hard to be all things for all users [18:26:21] MatmaRex: before swe switch topics did you get all of your high priority questions or issues raised/answered? [18:26:29] MatmaRex: Yeah that makes a lot of sense [18:26:40] 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] RoanKattouw: in fact, passing $skinname and &$wgResourceModules['module']['skinStyles'] was one of my ideas [18:26:45] but not getting rid of skin styles [18:26:48] There's another use case I have for that too, so I look forward to that happening [18:27:16] jzimmerman: hey, i'm the one *answering* the questions here ;) (and i hope i didn't miss any) [18:27:44] MatmaRex: I think you are good so far [18:27:50] TrevorParscal: personally I would prefer getting rid of skin-styles. I like the inversion idea. [18:28:03] I think both have a use case [18:28:33] 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] MatmaRex: sometimes we teach by asking questions rather than answering them [18:28:41] 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] 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] oh yeah, totally do review my patches y'all! :D [18:29:13] TrevorParscal: although having extensions/skins be able to dynamically add skinstyles would probably solve the problem as well [18:29:13] I don't see any specific reason to continue maintaining skinStyles. There are definitely other solutions. [18:29:34] kaldari: yes [18:29:35] MatmaRex: can you pick 2 patches you would love to have merged *today*? [18:29:53] #info discussion of skinStyles - future of promise or future of peril? [18:30:10] brion: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt [18:31:02] thx [18:31:08] * sumanah switches topics [18:31:08] #topic Trevor's "Redo skin framework" proposal [18:31:16] #link https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework [18:31:21] ok gwicke - you had some thoughts? [18:31:22] sumanah: pick any :) [18:31:31] 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] 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] MatmaRex: no, I'm asking you. [18:31:51] MatmaRex: if you pick 2 and ask people to look at them today, it's a lot easier. trust me [18:31:57] 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] one of mine is https://gerrit.wikimedia.org/r/#/c/138368/ [18:32:21] 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] #info https://gerrit.wikimedia.org/r/#/c/138368/ as an example: 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] OK, so before we go on, let me define widget, in this context, so we don't go around in circles [18:32:34] MatmaRex: will you reply to wikitech-l with the links after this mtg? [18:32:37] can do [18:32:40] thx [18:32:42] * MatmaRex listens to TrevorParscal now [18:32:46] 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] 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] so it's a push model? [18:34:22] rather than a dependency tracking model? [18:34:35] this is distinct from a template, which is is a unidirectional process [18:34:54] I think this RFC needs some sort of sequence diagram illustrating exactly what interactions are happening between the different skin components. [18:35:12] TrevorParscal: so you see KnockoutJS & Angular as unidirectional? [18:35:14] 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] gwicke: are you here to troll me? [18:35:49] I'm seriously curious [18:36:31] I'm trying to work out what the difference in functionality is between reactive frameworks & widgets [18:36:33] 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] TrevorParscal: Do skins own the widgets? Or are they inserted into the skin by other components? [18:36:43] TrevorParscal: But I assume the skin would define which template the widget uses to render itself, correct? [18:37:40] 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] the skin can also subclass standard widgets, to influence their rendering and behavior [18:38:27] So every widget will have a default rendering separate from the skins? [18:38:36] 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] let’s take a concrete example — say, “language links” <- would this be its own widget? [18:39:02] yes [18:39:02] yes, an example would help greatly [18:39:07] 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] the input is the list of languages [18:39:17] 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] #info I really like the idea of taking generic info and flowing it into customizable/subclassable widgets [18:39:33] Okay, I explained that poorly. [18:39:52] Like there's a skin object with certain functions and parameters, and other skins extend that. [18:40:04] Rather than... well, whatever clusterfuck we've got now. [18:40:04] 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] TrevorParscal: so is the main difference between reactive templating & widgets subclassing vs. swapping partials? [18:40:26] I heard something about Vector extending Monobook the other day and I nearly cried. [18:40:35] they are different approaches to the same effects, no? [18:40:45] Deskana: Modern extends MonoBook ;-) [18:40:50] +1 for a clean client-side JS API [18:40:50] Vector is a copy/paste/tweak of monobook [18:41:14] Oh dear. [18:41:32] 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] 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] I must've missed the lecture about how CopyPasteTweak is a valid alternative to object oriented programming. :P [18:42:17] TrevorParscal: so is the API model-driven, or more imperative? [18:42:27] 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] James_F: i’d love a brown bag session or something sometime [18:42:46] 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] 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] 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] brion: You're to be commended, not blamed. [18:43:49] :D [18:43:50] ok, so another point that is central to this design [18:43:58] so far, we have used our HTML output as the API [18:44:18] some skins will have slightly different output to achieve cross browser compatibility for their varied designs [18:44:29] aka. the CSS zen garden is a garden of lies [18:44:44] he! [18:44:46] heh [18:44:49] * Deskana adds that to the Bugzilla quips. [18:44:52] lol [18:44:53] the approach I am proposing moves the API to JavaScript instead [18:45:04] a bit ironic given that CSS support is so much better these days [18:45:05] where we can provide enough abstraction [18:45:09] than it used to be around 2004 [18:45:33] css is great at many things, but it can’t, say, turn Vector into MobileFrontend or vice versa [18:45:55] 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] yeah, it mainly can't change the position in the render flow [18:46:00] TrevorParscal: So how would widgets work without Javascript? Or does this solution require JS? [18:46:02] Imagine how much it was a lie back in 2004 then :) [18:46:12] 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] RoanKattouw: it required a bunch of cursing and elbow grease [18:46:30] kaldari: it would only require javascript to modify the skin dynamically on the client [18:46:42] which requires JavaScript anyway [18:46:56] modifications to be done on the server can be done through a similar (nearly identical) API in PHP [18:47:13] depending on the feature you are trying to write, you may make some modifications on the server, client or both [18:47:41] TrevorParscal: where do you see the main difference vs. the Knockout ideas we've been pushing? [18:47:49] (This API is waiting for the new version of PHP to do live on the WMF servers, right?) [18:48:03] That this is based on object oriented programming [18:48:32] I see, so subclassing vs. partial substitution [18:48:44] again, different approaches to the same end [18:48:53] 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] I believe that we already use object oriented programming throughout both client and server, and it is comfortable, powerful and convenient [18:49:35] The non-technical Deskana is still trying to fully understand Trevor's proposal. [18:49:45] for feeding data into the widgets, are we thinking model objects, or structured arrays? [18:49:51] 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] So it's about taking our horrible mess of a skin system and making it object oriented instead? [18:50:12] Deskana: at least, we would have smaller messes which could be more easily cleaned up :D [18:50:21] TrevorParscal: so the interface will be the model, as in reactive? [18:50:30] brion: I support minimisation of messes. :P [18:50:31] 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] Deskana: "object oriented" is kind of a broad term. Some people consider the current system "object oriented" [18:50:36] 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] TrevorParscal: Objects (well, classes) have interfaces that can be enforced. Structured arrays do not. [18:51:02] gwicke: the interface is not the model, it's literally the view [18:51:02] parent5446: From what I've heard, the current skin system is a bastardisation of object orientation. [18:51:10] :P Yeah that fits it perfectly [18:51:27] TrevorParscal: what's the motivation for giving up the model / view separation? [18:51:54] 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] or perhaps more accurately, the 'drive everything from the model' paradigm [18:52:08] 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] 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] I would also like to see an implementation that has good separation of concerns and a cleaner MVC separation. [18:52:28] I think I understand now. [18:52:31] we have about 8 min left, in case people want to wrap up and leave #info lines with their summary thoughts [18:52:31] gwicke: nobody is talking about doing that [18:52:37] Deskana: i think what TrevorParscal is proposing is like the current system, but done well instead ;) [18:52:53] (more complicated internally, too, but also more flexible) [18:52:54] TrevorParscal: the addPortlet thing would be a departure IMO [18:53:04] Indeed, MatmaRex sees that I am not revolutionizing, I am refactoring [18:53:34] in a model-driven reactive framework you'd just add a member to some portlet array instead [18:53:39] the approach I wish to take is based on continuing good patterns, and cleaning up bad ones [18:53:50] gwicke: I'm not able to do this with you right now [18:53:53] sumanah: somebody should establish some action items as to what the next steps for this RFC are [18:53:57] TrevorParscal: are there any ‘baby steps’ we can make on prototypnig this? [18:54:11] such as starting up a widget api and sticking it into a current skin as an example? [18:54:28] TrevorParscal: That makes sense I guess. My ideal vision would probably require rewriting MediaWiki from scratch ;) [18:55:03] 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] TrevorParscal: alright, would be nice if you could detail / motivate the differences a bit in the RFC though [18:55:18] kaldari: one step at a time, but mine too [18:55:35] all in good time :D [18:56:07] 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] any sufficient level of abstraction should be able to have it's implementation changed out without the API changing [18:56:41] I'd like to thanks MatmaRex, TrevorParscal and everyone else for explaining their projects to me in terms I can understand. :) [18:56:42] TrevorParscal: my question is actually mostly about the API style [18:56:48] not about the implementation [18:57:08] :) [18:57:09] I fail to understand how, but we can talk another time perhaps? we have 3 minutes left [18:57:11] 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] kaldari: +1 [18:57:38] any action items for moving forward? [18:57:41] #info (controller, controller/view, whatever) APIs though. [18:57:44] whoops [18:57:48] #info 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] brion: get someone to review my patches. :> [18:58:03] 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] #action MatmaRex’s patches need review [18:58:32] TrevorParscal: yeah, +1 on that [18:58:34] 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] #action MatmaRex to send to wikitech-l list of skin patches that additionally need review [18:58:35] nice [18:58:41] TrevorParscal: +1 [18:58:58] I'm gonna #agreed that [18:59:09] #agreed 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] 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] the model basically becomes the API [18:59:41] 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] 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] 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] 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] brion: do you agree? [19:00:53] * sumanah knows we need to wrap up in a minute [19:00:54] 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] 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] teams should be minimally affected by the shift [19:01:08] 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] 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] 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] *nod* [19:01:47] by existing skins, I mean the 4 in production [19:01:50] tfinc: don't forget non-WMF usage [19:01:59] thus i put a goal of *2* teams using it as a sign of success [19:02:01] brion: How does this tie into apps? Does it? [19:02:03] and the goal is also to get MobileFrontend as well - which is part of the UI standardization goals anyway [19:02:03] i’m also curious if there’ll be any overlap with apps extra metadata [19:02:06] i can see this being used by and loved by third-party skin developers [19:02:08] tfinc: Absolutely. [19:02:18] Deskana: potentially extensiony things could have to integrate with the apps and we’d want to plan for that yeah [19:02:21] ashley: looking forward to your continued involvement as a rep of the non-WMF MediaWiki-running community [19:02:37] MatmaRex: would be great to see community use as a barometer for success [19:02:38] brion: there's a lot of overlap there [19:02:44] tfinc: +1 [19:03:00] we are 2 minutes over, I am going to be fleshing out the RFC in the next week [19:03:03] #action mobile web team should have a hand in this since it’s the main alt skin WMF uses internally [19:03:04] #info goal of at least 2 WMF teams using this as a measure of success. MatmaRex: would be great to see community use as a barometer for success [19:03:09] thank you TrevorParscal [19:03:16] #action mobile apps also interested in possible overlap with extensions and meta things (links etc) [19:03:19] #info watch for more fleshing out of the RfC in the next week! [19:03:25] 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] brion: Cool. So not much for us to worry about just yet. [19:03:40] not yet [19:03:41] 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] ok, I'm callin' it. Thanks all [19:03:51] TrevorParscal: Thanks Trevor, look forward to seeing more info in the RfC :) [19:03:52] #endmeeting [19:03:52] Meeting ended Fri Jun 20 19:03:52 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [19:03:52] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-20-18.00.html [19:03:52] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-20-18.00.txt [19:03:52] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-20-18.00.wiki [19:03:52] Thanks sumanah! [19:03:53] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-20-18.00.log.html [19:03:53] \o/ [19:04:40] aye, would be nice to get some of the third-party instances running on custom, non-FOSS skins to open up & modernize their codebases :) [19:05:11] ashley: You mean, not MW 1.19? :-) [19:05:20] more like not MW 1.13 ;) [19:06:58] MatmaRex: or 1.3...yes, I once saw such an instance *online* (though admittedly it didn't have a custom skin, but ugh, still) [19:18:48] gwicke, is there a particular part of Parsoid review meeting I should be interested in? [19:22:57] jgonera: we'll chat about using Parsoid HTML for normal page views, and I figured that you might be interested from a mobile POV [19:23:39] gwicke, I see, will that discussion happen in the first half of the meeting or later on? [19:27:10] jgonera: later on [19:27:20] second half I suspect [19:27:41] here's the slides: https://docs.google.com/presentation/d/1KZXEVPE3EDPDvfRzFqlaVzxCSWisr99Hcyakglf0qF8/edit?usp=sharing [19:28:11] thanks gwicke