[17:30:56] <wm-labs-meetbot> Meeting started Wed Jun 25 17:30:56 2014 UTC and is due to finish in 60 minutes. The chair is Eloquence. Information about MeetBot at http://wiki.debian.org/MeetBot.
[17:30:57] <wm-labs-meetbot> The meeting name has been set to 'mediawiki_core_front_end_code_standardization_meeting__see_https___www_mediawiki_org_wiki_project_calendar'
[17:33:45] <Krinkle> (with 1.5 ear and 1 leg; sharing with another room)
[17:33:46] <Eloquence> Timo == Krinkle
[17:33:49] <TocToc> ah
[17:33:54] <superm401> Hey everyone.
[17:34:00] <superm401> Me == Matt Flaschen
[17:34:02] * jorm yawns.
[17:34:03] <marktraceur> Gosh, Eloquence, use real names. Government names are too ambiguous.
[17:34:21] <TocToc> krinkle|detached
[17:34:34] <Krinkle> My detached self is not available right now, please try again later.
[17:34:43] <TocToc> ah
[17:34:52] * RoanKattouw waves
[17:34:54] <Eloquence> Hi everyone. This is the meeting to discuss how we can make MW core's front-end support more sane in coming months.
[17:35:01] <jorm> Jared is at G/IO, so I'm repping design.
[17:35:16] <TocToc> krinkle: home-wiki?
[17:35:37] <marktraceur> I'd like to state my utter bemusement at this "silo-breaking" meeting being scheduled at the same time as Scrum of Scrums ;)
[17:35:40] <Krinkle> meta, commons, nlwiki
[17:35:44] <TocToc> ah
[17:35:50] <RoanKattouw> marktraceur: Yeah that surprised me too
[17:35:50] <TocToc> meta?
[17:35:53] <TocToc> commons?
[17:35:57] <TocToc> nlwikip?
[17:36:09] <TrevorParscal> Hello all
[17:36:10] <jdlrobson2> :)
[17:36:16] <superm401> TocToc, the scheduling. Not a big deal, though, in the grand scheme.
[17:36:17] * MatmaRex lurks
[17:36:24] <Eloquence> I'd like to get two things out of this meeting: 1) A shared understanding of some of the scope of work that Krinkle, TrevorP & RoanKattouw want to take on, especially with a focus on delivering a more consistent experience across devices
[17:36:47] <Eloquence> 2) A sense who else from WMF and the larger volunteer community wants to participate in this effort.
[17:36:59] <Eloquence> I'm guessing 1) will inform 2), so I suggest we start there.
[17:37:34] * marktraceur makes sure spagewmf and ebernhardson are paying attention
[17:37:50] <Eloquence> Krinkle, do you want to take a crack at explaining some of the concrete problems you're looking to solve? I'm personally very interested in seeing jQuery UI get deprecated sooner or later, is that something you're targeting?
[17:37:59] <Eloquence> Ah hi TrevorParscal :)
[17:38:02] <Eloquence> Same goes for you :)
[17:38:13] * jdlrobson2 wants to voice his concern about a single team taking on the entire frontend architecture and strongly push for more intermingling of teams but is going to be quiet and listen to the proposal before judging any more
[17:38:24] <TrevorParscal> I have been very clear that I believe this is going to be a multi-step process, the first steps being unifying technologies, and dealing with UX inconsistencies along the way when needed, and then doing a more general UX overhaul later on
[17:38:31] <Eloquence> jdlrobson2, yep absolutely -- this is why I wanted us to have this conversation
[17:38:47] <TrevorParscal> everyone is solving the same problems slightly differently, and we must put an end to that
[17:39:02] <James_F> jdlrobson: The single team of Platform, Editing and Mobile? I'm confused…
[17:39:17] <jdlrobson> TrevorParscal: sure. Do you not think this is because we are so reluctant to put things into core, so instead work in physical silos that we call extensions?
[17:39:20] <TrevorParscal> no matter what approach is used, until we are all using the same approach, making UX changes are going to be unnecessarily difficult
[17:39:26] <superm401> James_F, hmm, all the people Eloquence named are VE?
[17:39:26] <Krinkle> Eloquence: Yes, the idea is to phase out jQuery UI as it isn't meeting our needs.
[17:39:40] <jdlrobson> James_F: what superm401 said.
[17:39:42] <RoanKattouw> superm401: He neglected to mention kaldari who we roped in
[17:39:47] <Krinkle> For this to be a success we need OOjs UI to be further mature
[17:39:49] <marktraceur> superm401: "Editing"
[17:39:50] <RoanKattouw> (And joined the channel on cue)
[17:40:01] <TrevorParscal> jdlrobson: no, it is because we need to all work together on a common UI framework, which can exist anywhere, we just need to work together on it
[17:40:02] <Eloquence> Hi kaldari \o/
[17:40:03] * gwicke welcomes a stronger mandate for actual architectural work in this area; the evaluation of our html templating work has been pretty slow as other tasks always seem to take precedence in feature teams
[17:40:06] <kaldari> Hello!
[17:40:10] <James_F> superm401: Krinkle is moving to Platform (and has been there effectively for over a year). Mobile input from kaldari and jgonera is a key part of the work.
[17:40:27] <Krinkle> Among that I think is a base stylesheet in OOjs UI that will work without javascript using simple html.
[17:40:42] <TocToc> Krinkle: #koffieverslaafd
[17:40:43] <Krinkle> That would enable us to adopt OOjs UI styles in our overall interface.
[17:40:46] <jorm> So, is this going to be a thing where the team disappears for a couple months and then comes back and tells everyone "this is what you're going to use and this is what its going to look like?"
[17:40:54] <jdlrobson> TrevorParscal:... which is a side effect of having nothing useful to work of in core / a shared repository and all of us starting building big frontend systems at the same time :)
[17:41:05] <TrevorParscal> Krinkle: yes, I've begun that work (server side static OOUI compatible output) and that will continue again starting next week
[17:41:07] <Eloquence> All - is targeting deprecation of jQuery UI in favor of an evolving mediawiki.ui framework within a quarter feasible/desirable?
[17:41:11] <Eloquence> jorm, no :)
[17:41:14] <moizsyed> JZimmerman just mentioned that hes having connectivity issues, but will join shortly
[17:41:30] <jdlrobson> I think deprecation of jQuery UI would be a great starting point.
[17:41:35] <TrevorParscal> jdlrobson: indeed, no blame here, I'm suggesting we can get out of this mess by unifying our efforts starting now
[17:41:37] <Krinkle> mediawiki.ui as its core is essentially obsolete.
[17:41:39] <superm401> jdlrobson, I consider it already deprecated.
[17:41:52] * violetto waves hello at everyone
[17:41:53] <StevenW> Agreed about ditching jQuery UI
[17:41:56] <jorm> how so is mediawiki.ui obsolete?
[17:42:05] <superm401> Krinkle, as what's core?
[17:42:12] <Krinkle> at its core(
[17:42:12] <jdlrobson> Krinkle: yeh please explain and clearly define what you refer to as mediawiki.ui
[17:42:32] <StevenW> Krinkle: saying stuff like that is liable to make the whole effort more political.
[17:42:33] <jdlrobson> in my eyes mediawiki.ui is actively being worked on but it may be going under a different name
[17:42:46] <StevenW> mediawiki.ui is in core, mobile and desktop products use it.
[17:42:50] <MatmaRex> mediawiki.ui as the thing that's in core looks pretty abandoned to me too
[17:42:58] <Krinkle> With mediawiki.ui I mean the group of less stylesheets we have in core that define style for a few random things like buttons and other interface components.
[17:43:02] <James_F> Could everyone let TrevorParscal actually say what he's working on first before you all jump in and second-guess?
[17:43:03] <superm401> MatmaRex, it's not abandoned, but it's also not being quickly enhanced.
[17:43:10] <Krinkle> That look and feel is not obsolete per se, its implementation merely.
[17:43:13] <jorm> right. mediawiki.ui is referred to as Agora in many areas, and that has active development.
[17:43:17] <superm401> Which is because it's no one's job, and no one has broken off from their regular job to do it.
[17:43:28] <kaldari> Eloquence: I would be hesitant to think about deprecating jQuery UI until we have more buy-in to mediawiki.ui/oo-ui. There's still a fair amount of software using jQuery UI, and we need to make sure the migration path has matured somewhat.
[17:43:36] <jdlrobson> I think it would help in this conversation to not refer to technologies and instead refer to problems
[17:43:37] <TrevorParscal> superm401: but I am trying to do just that
[17:43:41] <MatmaRex> superm401: as i said, it looks pretty abandoned. no one actually uses that (only things on top of it), and no one responds to patches
[17:43:46] <Krinkle> It can become a theme for oojs-ui. It'd be the same but without being different. Whether it hinges in one direction or the other we can resolve later, but we wouldn't have separate stylesheets to maintain.
[17:43:47] <Eloquence> kaldari, agreed -- I'm looking at the goal more as a forcing function to scope the work.
[17:43:47] <jdlrobson> so no more mention of OOJS/MediaWiki UI please
[17:43:51] <superm401> MatmaRex, not true, we use it.
[17:43:56] <MatmaRex> okay.
[17:44:00] <TrevorParscal> I am spending 80% of my time for the next 2 months working on UI standardization and the new skin system (which will coincide)
[17:44:30] <jorm> are we then going to spend a great deal of time writing stylesheets to make ooui look and behave like agora as specced?
[17:44:58] <Eloquence> TrevorParscal, can you explain what "UI standardization" means in this context?
[17:45:18] <Krinkle> OOjs UI doesn't "look" like anything at its core. It's a framework defining html structure with javascirpt classes to enhance/manage those. It can be themed to look however you like.
[17:45:19] <TrevorParscal> Whatever the design of the day is, once we are using common software, it will be trivial to restyle everything at once
[17:45:21] <moizsyed> *agrees with jdlrobson, identify problems first, then the solutions*
[17:45:25] <StevenW> merging the two styles is actually not terribly hard I think. As Krinkle said, mediawiki.ui is much smaller. It's just button and form styles right now.
[17:45:35] <jdlrobson> Eloquence: TrevorParscal please. And also TrevorParscal: I hope that you will be doing that with support from representative people in every team with a frontend interest? not just solo you.
[17:45:37] <Krinkle> The MediaWiki theme would presumably look like mediawiki.ui or agora or apex or what have you this time.
[17:45:38] <superm401> TrevorParscal, I think we should decide right now, the design of the day is Agora.
[17:45:44] <superm401> i.e. how mediawiki.ui looks.
[17:45:51] <superm401> We don't need to rearchitect and re-design at the same time.
[17:45:53] <jorm> is there a reason why we can't start and do the active development using the Agora styles?
[17:45:53] <jdlrobson> please can we avoid talking about technologies. PLEASE PLEASE PLEASE. problems first.
[17:46:15] <RoanKattouw> superm401: That's not being proposed. And also you contradict yourself
[17:46:20] * Nikerabbit wonders how the grid and html templating work will fit into this ui work?
[17:46:31] <superm401> RoanKattouw, how am I contradicting myself?
[17:46:37] <RoanKattouw> superm401: You want to not rearchitect and redesign at the same time, yet you insist we set the design in stone Right Now
[17:46:46] <kaldari> Krinkle: Why would there be a "MediaWiki" theme?
[17:46:48] <RoanKattouw> The scope of this project does not include redesigning anything
[17:46:48] <TrevorParscal> The reason I never proposed to change how any products work, is because I want to be effective in unifying the technologies without the friction of changing designs
[17:46:50] <superm401> RoanKattouw, the current design is mediawiki.ui; so I'm not proposing a redesign.
[17:46:53] <RoanKattouw> It's design-agnostic
[17:46:59] <TrevorParscal> Indeed, as it should be
[17:47:01] <superm401> I'm proposing the same design with a different arch
[17:47:03] <James_F> superm401: Implementing mediawiki.ui/Agora is a re-design for ~80% of the tools actually used.
[17:47:06] <Krinkle> kaldari: Because without it there'd be no looks at all. It'd be a collapsed soup of empty boxes and text.
[17:47:07] <RoanKattouw> Step one is unify the technology
[17:47:09] <jorm> everyone says "design agnostic". that's not answering myquestion.
[17:47:09] <James_F> superm401: That's violating your own suggestion.
[17:47:13] <superm401> It can still be skinnable, but I'm talking about the default skin.
[17:47:18] <RoanKattouw> Once that is done, we can start worrying about what things should actually look like
[17:47:22] <MatmaRex> jorm: define 'agora styles'
[17:47:31] * jdlrobson sigh
[17:47:36] <MatmaRex> jorm: i think i follow every public list imaginable, and i have no idea what you mean
[17:47:45] <MatmaRex> i had a grasp a few months ago but then it changes again
[17:47:45] <jorm> my question is: Are we going to spend a lot of resources building this and using a design that we, the Foundation, will not be using, only to have to spend resources to update and style it to the Agora styles that we will be using?
[17:47:58] <marktraceur> /topic frontend spleen-venting about various UI frameworks
[17:48:04] <Eloquence> jdlrobson, the biggest problem, as I understand it: We have inconsistent template, dialog widgeting libraries across different applications/extensions
[17:48:09] <jorm> citation needed about what?
[17:48:18] <kaldari> Krinkle, TrevorParscal: Does Trevor's skin revamping involve extending oo-ui, or is it specific to MediaWiki?
[17:48:27] <kaldari> or both?
[17:48:31] <jorm> The design team has standardized on Agora. There's no real citation needed about that.
[17:48:40] <jdlrobson> Eloquence: okay, so can we identify what this UI standardisation team would be looking at and timebox it so we can have a more focused conversation?
[17:48:44] <superm401> Agreed with jorm
[17:48:50] <superm401> It's not implemented fully, but the design is decided.
[17:48:52] <Eloquence> jdlrobson, yeah.
[17:48:56] <TrevorParscal> The drama surrounding restyling is apparent in this very meeting
[17:49:00] <James_F> jorm: Shipped code is shipped. Everything else is just Photoshop.
[17:49:01] <jdlrobson> as right now the goal is too fluffy.
[17:49:02] <StevenW> So we've talked about deprecating jQuery UI. TrevorParscal: what do you think the first steps are to get the code standardized?
[17:49:05] <TrevorParscal> Can we stop talking about something that is out of scope please
[17:49:12] <jorm> Ah. So we're back to that argument.
[17:49:14] <jdlrobson> TrevorParscal: it would help to define the scope :)
[17:49:17] <MatmaRex> jorm: is the standard public?
[17:49:18] <Eloquence> jdlrobson, to be clear, I agree with TrevorParscal that we shouldn't be too focused on styling here.
[17:49:19] <MatmaRex> can i see it?
[17:49:24] <MatmaRex> whatever standard you have :)
[17:49:28] <jorm> So the goal here, as I can see it, is "make everything look like Visual Editor"
[17:49:32] <jorm> that's what I'm hearing.
[17:49:36] <StevenW> No
[17:49:38] <James_F> jorm: Then you're not listening.
[17:49:39] <TrevorParscal> Not at all
[17:49:59] <TrevorParscal> Please let me talk for just a sec
[17:50:00] <James_F> jorm: The goal is "make everything use the same technology, so skinning can be applied consistently whatever that skin is".
[17:50:16] <Eloquence> ^^ Please allow TrevorParscal to state his proposal clearly.
[17:50:24] <Krinkle> kaldari: MediaWiki skin refactor is imho a separate and unrelated endavour from unifying the ui library.
[17:50:30] <TrevorParscal> VisualEditor's design is changing to converge with mobile, it is not a fixed thing, we are not proposing a design change
[17:50:45] <Krinkle> kaldari: The MediaWiki skin system is mostly server-side logic and how the html templates come together. That last part is where there's a bit of overlap.
[17:50:52] <gwicke> an RFC with some more detail could be helpful to inform the discussion
[17:51:06] * jdlrobson asks everyone to be silent for a bit and let TrevorParscal speak but nods at gwicke's comment
[17:51:27] <Krinkle> And of course the visual looks, the MediaWiki skin Wikimedia uses would initialise the ui library with a matching stylesheet
[17:51:37] <TrevorParscal> The skin work will be important to UI standardization, because it will use the same technologies
[17:51:44] <Krinkle> Not like now where mediawiki.ui looks lika Agora but thrown inside of Vector
[17:51:46] <TrevorParscal> The skins will not change in their appearance
[17:51:58] <Krinkle> with still regular html form fields in between.
[17:51:59] <TrevorParscal> but their construction will change, and we will have clear APIs for them
[17:52:10] <StevenW> That's the first thing you want to tackle?
[17:52:34] <TrevorParscal> The process I am proposing is:
[17:52:35] <Isarra> You need to tackle that before you can effectively approach anything else.
[17:52:51] <TrevorParscal> 1. Create a server side approach to generating UI controls
[17:53:24] <TrevorParscal> 2. Use this approach to build a skin system and port existing skins, learning all of it's problems along the way and refining it through actual implementation
[17:54:12] <TrevorParscal> 3. (simultaneous with 2) working with Mobile to port mobile front-end to the extend that it differs with the approach created in step 1
[17:54:19] <Krinkle> The main thing that this would allow is separation of concerns. Right now MediaWIki general output, skin and extensions all append html to the output buffer
[17:54:53] <TrevorParscal> The result will be all skins, including mobile, will use a common UI framework, which can be styled and controlled enough to satisfy all existing skins and mobile
[17:54:54] <superm401> That brings up an important issue, extension back-compatibility (to the extent appropriate, i don't necessarily expect 100%)
[17:55:07] <TrevorParscal> Eloquence: the skins made up if widgets, yes
[17:55:36] <Krinkle> there is no encapsulation, re-using or control over what owns what. Refactoring that to use a consistent html building interface would open up lots of doors and simplify our code base. One of the many things (far future) is it would allow a pure ajax navigation mode where the server can serve the base interface and everything else is loadeable via templates
[17:55:59] <TrevorParscal> superm401: Skin hooks may be something we can keep functioning, some maybe not, javascript things like addPortlet link will probably be made to work but be deprecated in favor of a new API
[17:56:11] <Isarra> What are widgets?
[17:56:36] <TrevorParscal> They are objects that control a view through an API
[17:56:53] <Eloquence> TrevorParscal, You want to port _all_ existing skins to the new framework? Or just Vector/Monobook?
[17:56:55] <TrevorParscal> so, instead of accessing the HTML directly to make modifications, you would access an object that controls that HTML
[17:57:07] <gwicke> TrevorParscal: so not the model?
[17:57:13] <kaldari> TrevorParscal: So what provides the model in this scenario?
[17:57:14] <Isarra> Interesting.
[17:57:19] <TrevorParscal> Eloquence: I think we can do all 4
[17:57:27] <James_F> TrevorParscal: *5.
[17:57:40] <TrevorParscal> In the case of a skin, the widgets would be using a model to control their display
[17:57:41] <James_F> TrevorParscal: Vector, Monobook, Minerva and the other two.
[17:58:00] <TrevorParscal> but that is a matter of rigging, not all use of widgets must require a model, but it is usually best
[17:58:07] <Krinkle> And by 'we' we mean, the developers. I think we can do Vector as a first story. Considering we won't be the primary maintainers of the skins themselves, it is important their maintainers are faimilar with this
[17:58:20] <Krinkle> Having them do it after our example for Vector would be useful. There's no reason to do it alone.
[17:58:35] <TrevorParscal> I agree that we won't do all 4 simultaneously
[17:58:52] <TrevorParscal> but there's no reason to only do half of them
[17:58:59] <Guerillero> If you DC monobook you will have torches and pitchforks on your doorstep
[17:59:12] <gwicke> TrevorParscal: I asked this before, but I think it would be really useful if you could work out the reasons for rejecting frameworks like Angular & KnockOut, which both provide widget-like functionality & reactivity
[17:59:16] <Ironholds> Guerillero, nobody said monobook was being DCd, the internal structure will change, I think
[17:59:33] <Eloquence> TrevorParscal, how does this help us get to a more multi-device development approach across features?
[17:59:38] <Krinkle> TrevorParscal: 2 of those 4 are no longer in mediawiki core though. So it becomes tricker to say 'all'.
[17:59:49] <TrevorParscal> gwicke: for the last time, I'm not "rejecting" anything, we are operating under the same principals here
[17:59:53] <Krinkle> TrevorParscal: I guess you mean the 2 in core and the skin extensions wmf has deployed?
[18:00:07] <Eloquence> Will we make it a design goal for this new skin/widget framework to be fully responsive to different device capabilities and screen sizes from the start?
[18:00:13] <gwicke> TrevorParscal: so using those is one possibility you are considering?
[18:00:14] <MatmaRex> Krinkle: the other two won't be in core either in… two months? tops (i hope)
[18:00:23] <TrevorParscal> Krinkle: I think we can sort out which ones later, but sure
[18:00:43] <TrevorParscal> Eloquence: only if we create a new skin
[18:00:57] <RoanKattouw> Eloquence: Even if not; one problem with mobile support currently is that mobile stuff uses different technologies for /everything/
[18:00:59] <kaldari> TrevorParscal: Why not just have data models accessible via API and a skin system that maps those models to templates? What do the widgets provide?
[18:01:03] <TrevorParscal> Eloquence: I think we need a responsive skin, I started work on one called Apex, it needs more work, but it is fully responsive
[18:01:10] <RoanKattouw> It's hard for me to delve into mobile code because it uses totally different frameworks
[18:01:14] <TrevorParscal> but again, that is out of the scope I think, for now
[18:01:23] <Eloquence> TrevorParscal, I'd like to understand your 3) a little bit better
[18:01:33] <Eloquence> and this is where I think we get into the actual de-siloing part of the conversation
[18:01:35] <RoanKattouw> And so it's natural that only mobile devs work on making things work on mobile, while e.g. VE devs don't do as much work on mobile VE
[18:01:43] <Eloquence> I understand jdlrobson has been working on a responsive skin called Minerva
[18:01:48] <kaldari> I guess I still don't understand exactly what widgets are :P
[18:01:48] <Eloquence> and you've been working on a responsive skin called Apex
[18:01:56] <gwicke> kaldari: my understanding of this definition of widgets is that they are equivalent to high-level templates basically, with partials that you can override to modify just some part of the rendering
[18:01:57] <jdlrobson> Eloquence: Minerva is the name of the mobile skin.
[18:02:02] <jdlrobson> nothing more to be clear :)
[18:02:06] <TrevorParscal> Eloquence: sure, Mobile uses it's own system to produce Minerva
[18:02:16] <Eloquence> jdlrobson, *nod*
[18:02:18] <superm401> gwicke, my understanding is a widget is a living template where you can change it by calling methods.
[18:02:21] <jdlrobson> TrevorParscal: not true. We extend the Skin class in core
[18:02:41] <jdlrobson> I've also been working with jorm on Winter and playing with how Minerva might play with that.
[18:02:43] <Eloquence> and jorm has been working on a (now) responsive prototype called Winter, which is increasingly sync'd up with the Mobile efforts.
[18:02:51] <TrevorParscal> I get why they did that, but we shouldn't have multiple systems, and we need to unify them, and if the system we use doesn't work in the case of mobile we need to go back to the drawing board
[18:03:08] <jdlrobson> We have a prototype of Winter that is the mobile skin on a small resolution.
[18:03:18] <gwicke> superm401: I'm not sure on that, as it sounds like it could re-create the problems around update stability & model separation that reactive frameworks set out to solve
[18:03:18] <violetto> TrevorParscal, what are widgets?
[18:03:20] <Eloquence> jdlrobson, is that online yet?
[18:03:26] <jdlrobson> Eloquence: in a very broken form
[18:03:28] <TrevorParscal> violetto: scroll back
[18:03:43] <StevenW> So what do we think the timeline is for 1-4?
[18:03:57] <TrevorParscal> jdlrobson: I'm not accusing you of anything, you guys are using a templating system (afaik) which others are not
[18:04:18] <jdlrobson> TrevorParscal: i didn't realise i was being accused... all I was saying is the Minerva skin is a true skin
[18:04:23] <jdlrobson> we have a few hooks that mess with the content though.
[18:04:29] <TrevorParscal> StevenW: I'm starting next week, I have 2 months, I don't know how much progress I will make, but the less scope creep the better
[18:04:31] <Eloquence> jdlrobson, jorm - my understanding of the Winter<->Minerva efforts is that they're intended to help guide the way into the direction of a more consistent mobile/desktop experience by enabling users to try it out as a skin, and rethinking desktop functionality in that context, correct?
[18:04:36] <StevenW> Okay.
[18:04:37] <kaldari> TrevorParscal, superm401, gwicke: So a widget is basically a controller and possibly a set of generic template partials as well?
[18:04:43] <jorm> Yes.
[18:04:45] <jdlrobson> Flow is also using templating and using a very similar architecture to mobile. I'm working with the Flow team now to bring our architectures as closely aligned as possible.
[18:04:59] <jorm> fix core design problems in desktop; provide guidance with mobile.
[18:05:13] <spagewmf> TrevorParscal , AIUI so your "1. Create a server side approach to generating UI controls" shows up in skins, then in mobile, and then it's available for extensions like Flow, MultimediaViewer, etc. to use?
[18:05:19] <TrevorParscal> kaldari: it's more of a view+controller, but yes
[18:05:28] <StevenW> My guess would be that two months is enough time for us to complete the work on a server side approach to generating UI controls. But porting all skins to that seems harder.
[18:05:28] <Eloquence> jdlrobson, TrevorParscal, kaldari - can we bring the Minerva efforts in Mobile in line with the Skin Framework work that TrevorParscal is proposing? Understanding that the framework will need to evolve to support it?
[18:05:46] <jdlrobson> jorm: Eloquence exactly. I'm not sure what the end result will be - Minerva, Winter, Minervector,, Minerwinterector, Spring.. I don't really care what it's called but it's about getting to that unified skin.
[18:05:57] <kaldari> TrevorParscal: I would hope that most of the view would belong to the skins rather than the widgets, but maybe I'm not understanding the relationship there very well.
[18:06:03] <Eloquence> Minervapex, apparently ;)
[18:06:12] <StevenW> But if we get to a point where there are both server and client side implementations we can skin however we like, then we will be one big step closer to standardization.
[18:06:19] <superm401> I think I agree with TrevorParscal that re-doing the skin frameworks is more realistic if initially the same skins are available afterwards on WMF cluster.
[18:06:22] <jdlrobson> Eloquence: well this is what I'm saying. Minerva /is/ inline with the skins in core already. The only major difference is section collapsing support which is hacked in for mobile.
[18:06:23] <marktraceur> Minervectobook
[18:06:48] <jdlrobson> So whatever TrevorParscal does to Vector should easily also be compatible with Minerva
[18:06:51] <Guest74103> Noo, no more *book
[18:07:01] <TrevorParscal> jdlrobson: excuse my lack of knowledge of Minerva, but I'm lumping in other features here
[18:07:12] <RoanKattouw> jdlrobson: Ideally, what TrevorParscal does to the skin system will make minvera work better
[18:07:20] <jdlrobson> TrevorParscal: this is why i hate buzz words :)
[18:07:24] <RoanKattouw> e.g. removing awkward hacks that you guys have to do
[18:07:25] <Eloquence> jdlrobson, *nod* I think TrevorParscal is proposing to move to a widget-driven approach (both client-side and server-side) that would give MW core a better standard way to build skins with consistent behaviors across them.
[18:07:45] <TrevorParscal> The goal is to unify existing efforts, take the best parts of everyone's projects and combine them together
[18:07:46] <jdlrobson> RoanKattouw: well the main need for mobile would be by modelling a Page and allow us to render sections differently
[18:07:52] <jdlrobson> e.g. with the collapsing behaviour
[18:08:02] <James_F> jdlrobson: That sounds totally achievable.
[18:08:25] <Isarra> Getting a unified main skin for wikimedia projects is certainly something we all want, but please remember that whatever base system you come up with needs to also work with other skins.
[18:08:36] <Krinkle> achievable, and likely not part of the Skin system.
[18:08:47] <kaldari> jdlrobson, TrevorParscal: Agreed. The biggest headache for mobile is the lack of a structured page model
[18:08:50] <jdlrobson> Use of models would be really useful for skins both frontend and backend e.g. Page( { title: 'Foo', sections: [ { title: 'Section 1', html: '...' } ] }
[18:09:11] <TrevorParscal> Isarra: indeed, that is the objective and the proof of my commitment to that is my intent to port multiple skins, and learn along the way (as previously stated)
[18:09:11] <Krinkle> jdlrobson: exactly.
[18:09:23] <gwicke> jdlrobson: +1 on models & data APIs
[18:09:25] <gwicke> I think that's the bit we all agree on
[18:09:26] <MatmaRex> (yesplease, let's please forget Skin/SkinTemplate and make something new from scrathc)
[18:09:38] <jdlrobson> MaxSem mobileview api is what we currently use to do that
[18:09:46] <Isarra> TrevorParscal: <3
[18:09:50] <TrevorParscal> all the planning in the world does not protect you from getting it wrong, only implementation will ever be able to expose the errors in your plan
[18:10:03] <StevenW> :)
[18:10:04] <Isarra> What MatmaRex said.
[18:10:07] <Eloquence> it seems that any technical points of contention are best resolved in having strong mobile participation in this effort.
[18:10:28] <kaldari> Eloquence: And good documentation at the RfC :)
[18:10:36] <Eloquence> *nod*
[18:10:38] <gwicke> +1
[18:10:38] <TrevorParscal> And a mobile contribution has been requested since the beginning
[18:10:51] <superm401> Eloquence, to the extent that it affects regular front-end "apps" (Flow, GuidedTour, GettingStarted, Echo), it needs all-team participation.
[18:11:00] <Eloquence> I understand kaldari, you are interested in being part of this effort - other folks from the mobile side of things?
[18:11:04] <superm401> Or at least all teams need to be closely informed.
[18:11:05] <kaldari> Mobile is definitely interested in collaborating
[18:11:25] <kaldari> jgonera is also interested in collaborating on it I believe
[18:11:30] <Eloquence> superm401, yes, absolutely. I think TrevorParscal's suggesting though to help bring some core technologies to maturity and then let organic adoption take root
[18:11:32] <Isarra> Are there any goals to try to involve third-party projects in the effort? Given that there are thousands of skins out there already, it would be nice if we could come up with something that will mean that we will have a working system moving forward that will enable projects to do one last update and put their skinning problems behind them.
[18:11:40] <spagewmf> superm401: my point/question it sounds like this won't affect front-end "apps" for a while, because its skins then mobile then ??
[18:11:47] <MatmaRex> superm401: volunteers need to be informed too. i suggest wikitech-l :)
[18:11:54] <jgonera> I'm lagging behind in discussion, I was not aware it started at the same time as Scrum of Scrums...
[18:12:01] <Eloquence> jgonera, sorry about that!
[18:12:03] <gwicke> I'm interested in collaborating from the reactive templating side of things
[18:12:15] <gwicke> but am not sure whether that's already ruled out or not
[18:12:17] <jdlrobson> So my main concern is Trevor/VisualEditor team members working on his own doing this. Solo efforts never really work. Ideally this needs to be done as part of a team effort with clear goals and members from across the organisation. Is it time we had a skin team?
[18:12:38] <James_F> jdlrobson: It's called "Platform".
[18:12:40] <Eloquence> jdlrobson, I think at minimum this would right now be TrevorParscal Krinkle RoanKattouw kaldari
[18:12:41] <TrevorParscal> I never suggested solo effort
[18:12:52] <Isarra> A skin team would just mean a solo effort by that skin team instead of by the VE team or whatever.
[18:13:13] <Eloquence> jdlrobson, you are already assigned to Flow for the quarter -- perhaps you can keep a foot in this effort to ensure we can start thinking about Flow using it when it makes sense?
[18:13:28] <chrismcmahon> I would like to see incremental work available steadily over time in public on beta labs. Releasing this as a "big bang" seems like it would be risky.
[18:13:33] <Krinkle> It was mentioned before, but while it can be hard to see, I wouldn't consider this a VE initiative. The engineers you speak of were in different parts of the organisation and drawn into VE
[18:14:05] <superm401> I agree with chrismcmahon, though this is hard for any re-architecture.
[18:14:11] <TrevorParscal> I believe that Roan (backend), Timo (platform), Kaldari (features/mobile) and I (features/ve) represent a pretty broad range of experience and use cases
[18:14:14] <superm401> Also strongly agree with MatmaRex about keeping this all on public lists.
[18:14:29] <Eloquence> I also think doing this work in mediawiki/core will inherently make it easier for front-end developers across the org to pay attention to it
[18:14:41] <StevenW> So at what point do we need to get UX team representation involved?
[18:14:51] <MatmaRex> Eloquence: +1
[18:15:13] <TrevorParscal> StevenW: there will be some involvement needed throughout the process, but probably more and more as we finish
[18:15:14] <Isarra> Doing it in core will also make it easier for third-party developers.
[18:15:14] <jdlrobson> So my main concern here is that we are taking 3 members from a single team that have been working with their own technologies, and that the solution might be biased in favour of VisualEditor and those technologies and not think totally about Flow, Fundraising, Multimedia team, Mobile etc.. when this is something that touches a key part of our infrastructure.
[18:15:21] <James_F> StevenW: They're already involved. Much of the OOUI design work is led by kaity|away for example.
[18:15:42] <Eloquence> jdlrobson, how do you suggest to solve for that anticipated bias?
[18:15:43] <James_F> jdlrobson: Yes. You've only said that 10 times. :-)
[18:15:43] <jorm> jdlrobson++
[18:15:44] <MatmaRex> jdlrobson: VisualEditor is one of the few things that actually work with core MediaWiki and not against it…
[18:15:45] <marktraceur> I've been involved as a downstream user for a while, so have tgr and gi11es
[18:15:47] <superm401> Agree with Eloquence it has to be in core.
[18:15:53] <superm401> We don't want two skin systems.
[18:16:03] <jdlrobson> James_F: well i was worried i wasn't getting heard.
[18:16:06] <StevenW> But it doesn't sound like there is anyone dedicated to it, like kaldari will be from mobile
[18:16:07] <jgonera> Honestly, I'm at 10:50 now and I am not sure what is the point of this meeting at this point of the time. I think we need a clearly defined proposal/RFC before discussing anything. We also should have an agenda that everyone reads before a meeting like that. Right now I see this as a stream of random ideas from a dozen of people at the same time (unless something changed between 10:50 and now).
[18:16:19] <kaldari> jgonera: +1
[18:16:25] <MatmaRex> jdlrobson: personally i see no one who could be a better core team for this than the people already mentioned :)
[18:16:27] <gwicke> +1
[18:16:42] <kaldari> MatmaRex: Mobile?
[18:16:42] <Isarra> +1
[18:16:51] <Dantman> MatmaRex: With some of the Vector specific stuff I've seen in VE I don't really agree.
[18:16:55] <Nikerabbit> will this work be based on grid and html templating RFCs or something else?
[18:17:02] <TrevorParscal> I promise I will work on the RFC this week to help clarify the proposed work
[18:17:06] <shahyar> jgonera: I have just caught up on the log and feel the same way.
[18:17:15] <Isarra> Mobile isn't core, though. Which is something that really needs to be fixed, incidentally.
[18:17:20] <shahyar> this meeting has resulted in nothing but bickering and attempts at evangelizing various things.
[18:17:38] <shahyar> can we sit down and discuss what our issues are, first and foremost?
[18:17:40] <Eloquence> jgonera, this would be in partnership potentially with kaldari from mobile and others who are interested.
[18:17:54] <gwicke> Eloquence: there's too little detail in the RFC currently to actually evaluate it
[18:17:55] <Eloquence> as well as RoanKattouw & Krinkle
[18:17:56] <shahyar> this is exactly what happened at the architecture summit
[18:17:58] <MatmaRex> Nikerabbit: grid doesn't look very related to me
[18:18:05] <Eloquence> gwicke, fair point but it's a start :)
[18:18:13] <James_F> Dantman: Could you follow-up offline with me about "Vector specific stuff" in VE? There shouldn't be any.
[18:18:23] <Eloquence> So, concrete actions suggested:
[18:18:30] <MatmaRex> Dantman: i've looked and haven't seen much. what VE requires of skins is even documented somewhere
[18:18:34] <jgonera> Eloquence, I understand that, but this RfC is an early draft, almost a stub I'd say. And I'm not blaming anyone, that's fine. I'm just saying that we should iron it out more before starting a discussion.
[18:18:46] <Isarra> Grid may be related, but it'd exist on a higher level than this, I think. This is... like foundation, or something. The grid would be the wall frame or something.
[18:19:04] <spagewmf> Eloquence, TrevorParscal : at what point is this something that extensions can consider using?
[18:19:21] <TrevorParscal> As soon as it is in core I would imagine
[18:19:31] <kaldari> spagewmf: It will have to be from the start if we want it to be interoperable with MobileFrontend
[18:19:34] <James_F> Isarra: Nicely put.
[18:19:45] <Eloquence> 2) Everyone to review RFC, determine participation from other teams in this effort once points of contention have been resolved.
[18:19:56] <superm401> TrevorParscal, I'd also like more clarity on how it affects regular UI extensions (I understand roughly how it affects skins outside core).
[18:20:03] <TrevorParscal> I am modeling the proposed process on the success of ResourceLoader, we evaulated everyone's needs, came up with a solution, created it, refined it, merged it, deployed it, and then over time more and more people used it - now it is universally used
[18:20:09] <gwicke> TrevorParscal: I'd like to see some discussion of the interface style in there, as well as a comparison with other options that were considered
[18:20:17] <Eloquence> jdlrobson, does that sound reasonable?
[18:20:37] <TrevorParscal> gwicke: I'm not changing the style of anything
[18:20:54] <RoanKattouw> TrevorParscal: I think he means programming interface style rather than UI style
[18:20:57] <RoanKattouw> Words are confusing :)
[18:20:59] <gwicke> TrevorParscal: interface as in API
[18:21:00] <TrevorParscal> ah, yes
[18:21:25] <gwicke> especially, how will this look compared to the model-driven candidates?
[18:21:30] <TrevorParscal> I will be sure to tackle that - but it will be speculation and open for discussion
[18:21:35] <kaldari> Understanding the scope of the API will be useful
[18:21:48] <TrevorParscal> gwicke: again, this is model driven, it's the same thing
[18:22:18] <gwicke> ok, to me that wasn't clear so far, especially not from the RFC
[18:22:23] <TrevorParscal> My first steps will be evaluating what people are already doing and finding common ground
[18:22:45] <TrevorParscal> The reason I don't have a large spec on the RFC is because it would be premature to declare a solution
[18:22:59] <TrevorParscal> As I make more progress, more will be on the RFC
[18:23:02] <gwicke> spelling out examples might also avoid misunderstandings with different definitions of widget or model-driven
[18:23:27] <jorm> That strikes me as putting the horse before the cart.
[18:23:32] <shahyar> From what I can see, there’s three key issues at hand. 1) Styling standardization. Too much of MediaWiki and Wikipedia are using vastly different, often outdated designs, which results in poor UX. 2) Markup standardization. Lack of coherence on how to interact with the DOM, base classes to use, and general framework results in every product being totally different syntactically. 3) JavaScript standardization. This is the worst of the bunch. We ha
[18:23:33] <shahyar> LOT of code being reinvented over and over on every product. Almost zero collaboration between teams on this front, with everyone proposing their own half-hearted solutions.
[18:24:19] <TrevorParscal> Indeed, the point is to begin the process of standardizing
[18:24:26] <shahyar> I think we need to focus on breaking down each problem into subcategories, and then everyone should propose their solutions for each.
[18:24:28] <RoanKattouw> But from the bottom up
[18:24:30] <spagewmf> speaking of UI style, this doesn't address in the short-term the under-resourced meat and potatoes work of improving the Agora UX and making consistent use of its CSS styles.
[18:24:38] <gwicke> shahyar: we were discussing Trevor's first step here, which was about technical standardization without styling changes
[18:24:48] <RoanKattouw> So, fix architecture/code problems first, then that makes fixing styling inconsistencies easier
[18:24:49] <TrevorParscal> I know that as we bring more and more products together, we will realize that the first stab was wrong, and we will continually adapt
[18:24:54] <shahyar> gwicke: I am entirely okay with that, but we’re looking at this far too generically.
[18:24:55] <quiddity> +1 for examples. They almost always help, everything.
[18:25:25] <shahyar> We need to start with big aspects (ie. JavaScript) and then break that down into individual issues we have re:standardization.
[18:25:26] <superm401> shahyar, I think we're pretty clear what the problems are architecturally.
[18:25:36] <superm401> Too many different systems: OOJS, mediawiki.ui, Handlebars, etc.
[18:25:47] <superm401> + vanilla (not any of above).
[18:25:59] <Isarra> So now we need one architecture to rule them all.
[18:26:03] <Eloquence> :)
[18:26:05] <MatmaRex> shahyar: what do you actually mean by "JavaScript"? the scripts that do what?
[18:26:14] <shahyar> superm401: Are we? I think we’re clear that there are problems on a high level, but we aren’t listing each individual issue separately.
[18:26:32] <moizsyed> shahyar: we should have a trello for this ;)
[18:26:32] <Isarra> At this point, do we even care what the individual issues are?
[18:26:44] <Eloquence> shahyar, I think creating gravity in MW core for a standard widget library and skin framework _is_ a good way to begin the process
[18:26:59] <Eloquence> as long as this is an effort that has buy-in technically from the different teams
[18:27:00] <MatmaRex> shahyar: if you mean interacting with the existing UI (like addPortletLink, watchlist star behavior), then it doesn't make sense to talk about that without talking aobut the underlying HTML
[18:27:27] <kaldari> Eloquence: I would also say that improving our APIs to be more model-based is an important part
[18:27:28] <MatmaRex> shahyar: and trevor's widgets are exactly that: code in PHP and JS that both works on common generated (and dynamic) HTML
[18:27:31] <Eloquence> TrevorParscal, when do you suggest we come together again to review a more detailed technical proposal?
[18:27:37] <superm401> Vote agains doing this on Trello; prefer Bugzilla since it affects so many different teams.
[18:27:41] <TrevorParscal> In 2 weeks
[18:27:45] <MatmaRex> TrevorParscal: correct me if i'm wrong :)
[18:27:51] * Krinkle catches up
[18:27:53] <TrevorParscal> I will be using bugzilla
[18:28:07] <TrevorParscal> MatmaRex: you are right, as usual
[18:28:08] <marktraceur> Yeah, wasn't this meeting about *breaking* silos, not creating them?
[18:28:19] <gwicke> MatmaRex: there's many solutions like that around; the interesting bit is how the rendering reacts to changes in the model for example
[18:28:20] <shahyar> MatmaRex: Right, which is why I mentioned styling and markup first.
[18:28:22] <MatmaRex> (by which i mean bugzilla :) )
[18:28:28] <Eloquence> marktraceur, I think everyone's on the same page :)
[18:28:29] <Isarra> This also affects people outside of Wikimedia. Please, PLEASE do not take this somewhere they can't go.
[18:28:32] <James_F> superm401: +1
[18:28:33] <MatmaRex> shahyar: but styling is not necessarily relevant
[18:28:36] <Krinkle> So a lot of this is personal taste. I think we need to not forget that nothing will be done without peer-review and proven in the field. If something isn't working, if there's bugs or issues or flaws. Anyone can point this out and it will be heard and acted on.
[18:28:41] <jgonera> We are going to use bugzilla for what exactly? It's a bug reporting tool, not a planning tool.
[18:28:46] <MatmaRex> shahyar: swapping CSS styles is very easy
[18:28:52] <MatmaRex> (relatively speaking)
[18:28:59] <Eloquence> jgonera, it can be used as a planning tool for now. let's not bikeshed on this aspect.
[18:29:01] <TrevorParscal> Again, I will be using the normal channels, Bugzilla, mailing lists, IRC, etc. No trello or GoogleDocs
[18:29:25] <RoanKattouw> You know, there's this wonderful planning technology
[18:29:27] <RoanKattouw> It's called a wiki page
[18:29:29] <Eloquence> lol
[18:29:31] <shahyar> lol
[18:29:32] <jgonera> Eloquence, is there going to be a new project on Bugzilla where we will file "bugs"?
[18:29:35] <moizsyed> RoanKattouw: haha
[18:29:36] <RoanKattouw> We make this software called MediaWiki, maybe we should use it
[18:29:38] <jdlrobson> Anyway, I'd really like to hear some concrete problems about what we are trying to solve so we know what we are trying to achieve and know when we have achieved it. I'd strongly recommend pulling in someone like awjr to facilitate this conversation and work. So far this discussion is far too chaotic.
[18:29:40] <Isarra> TrevorParscal, RoanKattouw: I love you guys.
[18:29:44] <Krinkle> I suggest Trello
[18:29:47] <Krinkle> (just trolling)
[18:29:49] <marktraceur> RoanKattouw: Don't be silly, nobody actually uses MediaWiki
[18:29:53] <shahyar> MatmaRex: I disagree. A lot of what I’ve seen here fails to address key issues with how styles would apply to markup. If we’re talking about the actual stylesheets, then I agree with you. However, when I say markup, I mean markup with proper classes, names, data attributes, etc.
[18:29:57] <TrevorParscal> RoanKattouw: yeah, sorry, also I will be using the Wiki a lot
[18:30:02] <RoanKattouw> jgonera correctly points out BZ isn't great as a planning tool
[18:30:05] <moizsyed> RoanKattouw: can we move this discussion to a talk page please
[18:30:13] <Guerillero> RoanKattouw: that may have made my day
[18:30:19] <shahyar> In addition, a lack of templating coherence adds to our problem with markup.
[18:30:20] <MatmaRex> marktraceur: onbody actually writes it, in fact.
[18:30:24] <MatmaRex> (and that's sad.)
[18:30:28] * RoanKattouw starts communicating with moizsyed on his talk page, entirely in templates
[18:30:37] <moizsyed> lol
[18:30:44] <Eloquence> jdlrobson, the proposal is to reconvene to discuss the next iteration of the proposal by TrevorParscal Krinkle RoanKattouw kaldari
[18:30:53] <MatmaRex> shahyar: of course, markup includes classes and stuff like this, i thought that was obvious :)
[18:31:09] <shahyar> While we aren’t using it yet (Flow uses Handlebars for both server-side and client-side markup), I am a big fan of gwicke’s approach to templating.
[18:31:09] <Isarra> shahyar: There are different levels of what goes into the user-facing interface. What you describe is generally a much higher level than this, but depends on the low-level developer-facing interfaces being sane.
[18:31:11] <Eloquence> jdlrobson, I'm happy to have awjr or anyone else as a co-facilitator. I think there's going to be some inherent chaos which is reflective of where things are right now -- we'll get past that point, don't worry :)
[18:31:18] <Isarra> We're trying to make those actually sane, because currently THEY'RE HORRIBLE.
[18:31:22] <TrevorParscal> We need to stop using HTML as out API, bottom line - all this talk of classes and attributes is off topic
[18:31:27] <Isarra> Or something along those lines.
[18:31:39] <MatmaRex> shahyar: it really doesn't matter what style is used at first, or if there's even a consistent style – as long as there is *a* style that interacts with CSS classes in the markup, all will be well
[18:31:49] <jgonera> I know it's hard, but try to resist exercising your sense of humor, there are way too many people here to add even more messages that are not bringing us closer to some consensus.
[18:31:53] <MatmaRex> shahyar: and more classes can be added if it turns out later that they are needed
[18:31:57] <shahyar> TrevorParscal: 100% agreed about API, not so much about classes and attributes.
[18:31:58] <MatmaRex> iteration etc etc
[18:32:11] <moizsyed> Eloquence: awjr will be a great addition for this team
[18:32:22] <jgonera> +1 for including awjr
[18:32:23] <awjr> ftr, i am happy to help however i can in this area :) i'm in transit now though so only vaguely paying attn to this conversation
[18:32:30] <superm401> +1 to having some facilitation.
[18:32:31] <awjr> and thanks for the votes of confidence :D
[18:32:35] <Eloquence> thanks awjr :)
[18:32:38] <James_F> awjr: You know not to what you've signed up. :-)
[18:32:44] <Eloquence> heh
[18:32:57] <shahyar> Welcome to the Thunderdome.
[18:32:59] <Krinkle> shahyar: I agree. I'm very much interested to see more focus on keeping our HTML in better shape in the first place.
[18:33:02] <awjr> James_F i rarely do ;)
[18:33:17] <spagewmf> Eloquence: I applaud TrevorParscal's goal and support it, but meanwhile there's an under-resourced effort to provide and use CSS classes that deliver a consistent UI to the mess of HTML we have today.
[18:33:22] <jdlrobson> i think we should come back to this converastion with a clear agenda and proposal. We seem to be talking about 101 different things. The only thing we all seem to agree on is the skin system is a mess and that we need to start using Models.
[18:33:23] <rmoen> Hey all, just getting here. Reading the beginning was a bit painful.
[18:33:24] <Krinkle> Tends to simplify stylesheets, make them more affective in cascading styles, and reduces computation in javascript.
[18:33:32] <rmoen> TrevorParscal: +1 standardizing our server side output
[18:33:36] <superm401> spagewmf yes, and I don't think anyone's proposing to resource that right now.
[18:33:42] <rmoen> looking forward to further discussions.
[18:34:00] <Isarra> Krinkle: Hopefully having a framework to do the html itself will prevent folks from adding it willy-nilly, thus cleaning it up.
[18:34:03] <moizsyed> I need to leave for now, but will this conversation be documented anywhere?
[18:34:06] <superm401> jdlrobson, I think the initial three steps (above) are pretty clear; after that, not as much.
[18:34:14] <Eloquence> spagewmf, superm401 - understood. I want to hear from the folks doing the work on the skin framework how they propose to sequence things; will follow up.
[18:34:17] <Isarra> Specifically paying attention there would probably be good.
[18:34:25] <Eloquence> OK - we're going to wrap up for now.
[18:34:39] <Eloquence> Thanks for participating in the conversation so far - we'll reconvene around Trevor's more detailed proposal.
[18:34:49] <jdlrobson> but superm401 it's hard to gauge what the end user value of that move is. It needs to be done but what does the user get out of it?
[18:34:49] <Eloquence> and by "Trevor" I mean everyone else involved, as well.
[18:34:50] <rmoen> James_F: awesome.
[18:34:55] <moizsyed> Team Trevor
[18:34:56] <gwicke> James_F: so it sounds like you have determined that you need to write a new thing, rather than use something existing?
[18:35:00] <rmoen> Trevor = everyone ;)
[18:35:05] <jdlrobson> superm401: I'm finding it hard to know what the most important problems to focus are on right yet. We should be driven by real world problems not by code embarrasment.
[18:35:15] <gwicke> if so, I'd be interested in reading the rationales for that
[18:35:18] <James_F> gwicke: New? I'm confused. We're talking about extending an existing technology…
[18:35:54] <Krinkle> Isarra: Yep, I think the main flow in the new system will be that you can't write html to the buffer directly.
[18:36:09] <TrevorParscal> I look forward to getting more input as I expand the RFC
[18:36:09] <Krinkle> Isarra: It has to be an object of sorts, thus naturally requiring it to be balanced.
[18:36:13] <superm401> jdlrobson, there are various real world problems
[18:36:23] <gwicke> James_F: my understanding is that OOUI is not a reactive framework in the common model-driven sense
[18:36:26] <gwicke> where the model is plain data
[18:36:34] <Isarra> Krinkle: Aye... which will also mean there will need to be a sensible way to create new objects which aren't already defined, though.
[18:36:34] <superm401> 1. Developers have to learn multiple different technologies (mediawiki.ui, maybe jquery.ui. OOJS, HTML::/XML::), etc.
[18:36:40] <quiddity> moizsyed, yes, this channel is logged, and the log for this meeting will be specifically linked on mediawiki, from the RfC's page
[18:36:45] <superm401> 2. Skins use different output HTML and we use HTML as an API.
[18:36:48] <Isarra> Since there's no way a system's going to cover everything people need.
[18:36:51] <moizsyed> thanks quiddity
[18:36:53] <Eloquence> I appreciate everyone's patience and continued engagement in this conversation. :)
[18:36:56] <jdlrobson> LOUUUDDD NOISSEESSS
[18:36:57] <TrevorParscal> gwicke: OOUI is not a framework, but it could be a part of one - and nobody is calling OOUI a framework
[18:37:02] <superm401> 3. Insufficient features in mediawiki.ui
[18:37:05] <gwicke> James_F: but it sounds like that's something that you plan to develop
[18:37:09] <Eloquence> At this point, the meeting is over, but everyone's welcome to continue to chat here.
[18:37:10] <superm401> 4. Skin API widely believed to need overhaul.
[18:37:23] <superm401> Also, fixing technical debt *is* a feature, since it improves future productivity.
[18:37:31] <Eloquence> #endmeeting
[18:37:32] <wm-labs-meetbot> Meeting ended Wed Jun 25 18:37:31 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
