 Hello. Hello. Please take your seats. Try to pause the discussions that you're in. And let's get started with our next working area, the user interface presentation. We have already set up. So, our facilitation meeting style is the field narrowing one. We will give a short introduction to the tasks and sessions that we will carry on in this discussion. And we have chosen Rowan as our scribe person. Pratik as our timekeeper, facilitating is Tima and myself. And Katekeeper is John Katz over there. So, let's get this started. Tima? Okay. So, welcome everyone. We'll be continuing off mostly from the previous session talking about the future of our content presentation. I'll briefly present the agenda for this session. So, first off, I'd like to summarize a little bit of the previous session. Then I'll mention some of the previous sessions that are very much related to this, which we won't be discussing in this session. And then the actual main topic that I'd like to discuss here, which is the skin system and how this will fit in with the new generation of content loading. So, the related sessions. So, the previous one, very much, I'm missing my notes here, I see. I'll just summarize it. So, we've previously discussed, in the previous session in case you missed it, the future of the next generation of content loading, which might involve something like service worker, an API-driven front-end slides are not yet online. I'll publish them after. And it's only a few slides to assist the introduction of this mostly be a discussion. So, yeah. So, the previous session in summary, basically what it proposes is that we will be having a Node.js service on the back end that will compose the skin, the page content from REST Base, for example, and compose them into one page content for the user. And what we'll be focusing on here is how that fits in with the skin creation process. The skin creation process itself has another session tomorrow at 10 a.m. in Robertson 2, which is right behind that wall. And, later in that day, there's also another session about the image styles. So, with a lot further ado, let's get into the skin system. As Wilco mentioned, this is a field-nearrowing discussion, so we're mostly wanting to get feedback of what people have as different ideas and to try and see what the best ones are and how we can potentially move forward with that. To get it started, I'd like to mention a few use cases and a few restrictions that we might want to put on this to help us sort of narrow down where we want to focus on. So, first of all, I would like us to think about treating various use cases as first-class citizens in this new system. So, we have a few different use cases. We have mobile apps, we have mobile front-end, and we have logged out users. Sorry, that should be logged in users. My apologies. Right now, they go through very different processes to get their content delivered, and ideally, in this new system, they will be able to go through the same stack where, as a logged-in user or a logged-out user, whether on mobile or not, you're going through the same system and you get the same benefits of composition and performance, most importantly, which is also affected by things like latency, being able to run in the HDS centers rather than only in the main data center and the various aspects of that. We have to be able to separate these things. There are various restrictions that we have to put in place. None of these are definite. They're just proposed restrictions to keep us thinking in the right direction. One is, we will probably will not be able to support global PHP hooks. The idea of having an extension hook into somewhere and be able to modify anything on the page, skin, user page, whatever it might be, that would have to be probably more declarative in a way that you can interpret in a separate process, not necessarily in a separate process, but with the ability to do it in a separate process. We might want to consider something like a lightweight template syntax for skins. Consider the possibility of using Mustache and think about, can we actually reproduce vector with Mustache? Is it advanced enough? Can we support everything? We'll probably have to be very low complexity, again, very declarative. Mustache does have some if conditions and repeats. There's a lot of features that we can leverage there, but we have to really rethink this and how we can compose these kind of things. Again, as previously discussed, API-driven development. The skin would have access to the APIs, but only the APIs. There's no special querying to get this extra bit of information. It would need to be in the main page load and then the skin can use it. This again goes back to treating apps as first-class citizens. For example, right now, the mobile apps have their own API to get all the bits they need because the main API doesn't give them what they want. Again, for further parties. If we adhere to all these restrictions, I think we won't have much concern with third parties because it will be able to be very low complexity. We can terribly reproduce that same layer as a separate PHP class that would do the same thing. Those are my notes to get us in the right direction. Sounds good. Can we share the etherpad just on the screen? We were mirroring the screens of the etherpad as well to give you guys the notes. We would like to get from you, audience, some inputs on what is your state of current problems you're facing, current issues you're running into to see where we are at and what the focus, where our focus should go. Please share your inputs on the ideas that we gathered here. Alright, I'll talk if nobody else will. Some of the things that I just put, that were part of this time here that I wanted to see if, just ask the question, and maybe I'm just not up to date. Future of Mobile Frontend is a presentation that we did not explicitly schedule but it's one that could very easily be an unconference one. Does that one deserve unconference time? From our perspective, that is a very highly requested issue and we should definitely think about an unconference meeting agenda, meeting point. The same holds true for the others as well, like the vision for templates, Wikii 2x20. The future of Mobile Frontend, for the aspect of it regarding how it can fit in as a skin in a scalable and maintainable manner in this new system, I would like it to include in this session. This is very much what we're talking about today. It is one of the three use cases I mentioned. The other topics that were listed, we weren't able to fit in the schedule as their own main track session, but if people are interested in them, we should definitely schedule an unconference. I'll just list them briefly. I can cut and paste them in the notes as well, by the way. I've got it right in front of me. Future of Mobile Frontend, the vision for templates, Wikii 2x20, real-time collaborative editing, and then making it easy to fork, branch, and merge pages. I think those are all Scots, but I'm not positive about that. Is Scott here? Yes, he is. There we go. Can you step out the microphone? The middle two are mine. The last one was merged from, I forget who originally proposed that, but I certainly have ideas. Sorry, do you want me to promo them briefly? Given that we won't be able to spend much time in this session, I'd say take a minute or two to maybe pitch them and encourage people to schedule an unconference. Okay, so I'm going to skip the skin. Okay, well, I think the skin creation process has sort of been promoted in the last session in terms of refactoring it to a point where we can more clearly separate the skin creation from media Wikii Core, and that will allow a lot more user interface experiments, I think, which would be a good thing and sort of relevant for this topic. So when people say it would be great if our user interface looked like X, we should think about the ways in which why we can't just make that so and then figure out if there's a refactoring we can do. Vision for templates. Fundamentally, a lot of our core, even our core appearance, what an info box looks like, what an avbox looks like, comes down to sort of extensive use of templates. And with projects like Visual Editor, we're kind of getting to a two-track user system where power users can really influence anything by editing the Wikii text, but we're allowing most users to edit only a small subset of our site. And so the sort of new ideas for templates sort of figures out if there's a way we can push forward what the user experience for editing templates is, like, can we give people a graphic editor? Can we do other things? Some of the metadata markup for templates, which lets you edit slots and templates and visual editors kind of related to that. Can we push forward the user interface or the user experience for editing a page which contains lots of templates? And real-time collateral of editing. Yeah, so I would really love to hear from lots of people about that because it seems to me that if we actually wanted to do real-time editing like Google Doc style editing of an article, just the technical implementation is kind of the least part of that. All the user experience on the site changes, and there's a lot of really important social issues that change. Like, how do we prevent people from stalking? Like, if you can find and ask somebody to collaborate with you on a page, then we suddenly have to worry about people being harassed by requests to edit pages, like request to edit pornographic pages or something, right? Like, there's all sorts of new problems that can occur. So I think that really requires a more holistic discussion, and I don't have the answers to it, which is why I'd love to talk to people who have some of the answers I don't of what chat would look like, what collaborative groups would look like. We sort of have the foundations with Wiki projects, but I haven't personally done a lot of editing with Wiki projects before, so I'd love to hear people who are involved in a Wiki project. Does that help you find people who are also interested in editing the same articles? How would you arrange a group editing session with your project? That sort of thing. And then I was halfway through a talk on the Etherpad. So there's this other separate question about, like, what revisions actually look like in the backend database. And I think that's not in scope for this session. What's in scope for this session is the user experience part of it. Like, if there's an edit conflict, how would we like it to look? If there's a complicated, you know, lots of people, five people edit this page in a group session, they all committed a version, like, how do we present that in the history? Like, so from the user perspective, what are the sort of new interface ideas that we need to sort of start thinking about to allow better collaboration models? Or not better, you know, different collaboration models. Okay, so I see... Yeah, and so that was kind of the... The 113 is that last part of it. So we'll punt the backend part of that in terms of what page revisions look like to a different session. But for the purposes of this session, you know, we'd be talking about, like, what these forks would look like to a user. How, you know, yeah. Okay, so I see several people are interested in this, so I'll just go to Scott and schedule an unconfined session. Yeah, I guess maybe the Etherpad is actually a good place. If you jot your names down there, at least when I get to, like, a sort of minimum quota, I'll be more inclined to figure out how to schedule a session for it. Yeah, that sounds like a good idea. So let's put our names in the sessions behind that to see how much interest we have here because of the diverse group of people and also lots of different sessions possible. So I'd like to maybe provoke some people in the audience to better respond to proposed ideas. So let's propose something completely radical and random. Let's say we were to rewrite the skin system as a declarative syntax in JSON with some moustache files and then that would be the new vector skin. What would your thoughts be if we were to do that? This is just one random idea. So get started. Sounds interesting. Actually, yeah, my name is Trevor Pascal. So actually, I think the main thing I wanted to kind of say was that there's a fundamental problem that needs to be solved sort of before we can fix the skin system. I was going to rewrite the skin system, like, I guess, a couple of years ago or a year ago or so now. I got, like, really distracted with visual editor. And the thing that was keeping me back was actually that we need to have a separate, like, a separation of all of the things that make the skin contain what it contains. Because right now there's just a lot of really nasty hooks that sort of inject HTML and that type of thing that determine what links are available to what user in which situation, things like that. And when you really get down to it, vector and monobook are pretty much the same technically. But they both depend on this sort of, these blobs of HTML to determine what links are available to people at what times and what permissions they have. And so there's like a fundamental thing. I know you kind of called it out as like, oh, it'll be API driven. But like that API can be done. And monobook and vector could use that API internally using FOA requests or whatever, whatever routing you want to do. Without making any changes at all to the skin. And that's a blocker for moving in this direction at all. Because as long as we're still dependent on those HTML blobs being generated by this like crazy system that we have right now, we can't really move far away. I mean, that's one of the reasons why vectors so much like monobook is it was as far as we could take it. And it hasn't really changed since. And I mean, I wrote vector in 09. So it's pretty much stagnant. May I ask for a moment how many of you folks have ever tried to write a skin or to develop a skin within foundation? And so all of you people and then like, okay, that's a few. And so non foundation members. All right. Okay. Super popular. The problem is, no matter what we do, we need to fix the back end first. It's too high. Sorry. You have to kind of go to your turn around. It's a bit wiggly. You can also pick it out if you want. Right. But yes. So just following up on what Trevor said, which is what? For the recording. It's great if we have you on the recording. Okay. I don't know. Oh, right. My name. State your name and rank, please. Yes. And yeah. So basically it's just what Trevor said. We need to fix the back end before we do anything. And once we have that done, something like this could work well or something else. It doesn't really matter. The back end is a huge mess. And it's blocking everything. So he was saying that vector, as far as we can go, we can go further, but it gets exponentially more messy at that point. So. Well, I think we're in a bit of a paradox between the back end and front end. So on the one hand, we want to change. I would like a little bit more specific input for me if you'd like. So what specifically about the back end? I mean, I know what's broken, but I'd like to discuss it more robustly. So what specifically about the back end is broken. It makes it difficult. That is a problem too. We don't really know where the difference between back end and front end is, which has probably come up a lot already. But there's things where you have to deal with multiple different classes in order to make a skin. And there's a skin class. It's a skin template class. There's a base template class. I don't even know how they all interact. And I was using all of them. And then there's a lot of things that are just plain not supported. So you want to get categories, but you have to query the database if you want to format them, which you think categories would be something you just have. And we don't even know what all we want in a skin, even though they should usually be pretty similar. Yeah. So first that would be to generalize some of the abstract methods we have in skins that return HTML to also return the data and then have an abstraction method. Well, first we should write the methods. They don't exist for a lot of things. Right. They could pass as template variables. Right. But there's going to be a whole session on this later. So I should go too much into it. Sorry. Hey, I'm Brian. I'm sorry. You were finished? Okay. Yeah. I'm Brian, I was developer. First I want to say that it's very encouraging to see this effort start to take shape. I'm in general very much in favor of consolidating architectures and refactoring or moving technical debt. But that said, I was hoping you guys can maybe elaborate a little bit more, perhaps for other people in the room, besides me that are not as familiar with the actual use cases for skins and just from a user or like product domain perspective. What is the separation of concerns between the visual aspects of an article from a skins perspective versus the editor? For example, some of the things that the iOS app does as a quote skin and quote is try to make images take up the entire width of the page, collapse certain sections of the article, move different parts of the page around. As an organization, as a platform, as a content site, what is the actual, I don't want to say a line, but what is the relationship between how we render and present content on the site versus how editors author that content including like, oh, I want this image to float to the left or I want this to be a gallery of images or, you know, et cetera, et cetera. And how do we as providers with that platform impose constraints so that we can enforce things like images rendering performantly on various network connections or RTL support and things of that nature? Yeah, so one of the strengthens and at the same time weaknesses of Media Wiki is the possibility for editors to imply to add a lot of markup and that is an issue that as a skin creator, you have to always be aware of and there's not like an easy separation of content and skin, so to say, skin in the sense of markup, of Tom markup. And what we definitely have to figure out is where to put the boundaries and how to, and therefore your question is exactly pointing at this area, where to put the boundaries and how to best give editors all the freedom and still have all the possibilities that we as experts in installing and markup can come up with. Right, so I guess just to follow up on that briefly, how much does this then, people have mentioned technical blockers for this initiative, it seems to me you need to define the inputs to the skin system by drawing that boundary before you can define what a skin is since you don't even really know what all a skin should or should not do. By the same token, is this at all related to or should it be related to or merged with the UI standardization effort we can say this is how, like this is the baseline for how Wikipedia articles are presented. And this is also specific to Wikipedia, I'm assuming. So I want to tie a few connections to related subjects. So one is there's a separate talk, a separate session tomorrow about semantic image style and beautiful layout. And a lot of what that touch on, a separate session for semantic image styles and beautiful layout. I added it to the top of the adiff pad just now. And a lot of what that will touch on is what you're saying. Authors right now have a lot of control over the layout and styles of individual page components. And they're not really recognized as page component by the media system, they're just part of the page. Even sections aren't really very strictly recognized. It's quite difficult to separate these pieces of content for an API consumer, it's just a mobile app, to then inject things in the middle of a table of contents, you have to hijack the other one out and insert your own and things like that. Or just be able to compose the page in general. Right, so I think one of the things that we will probably want to have is a better separation between types of entities that are on a page without necessarily having to declare them as a template. This is tricky, I think from a historical perspective it's been difficult for me to approach the foundation to make an extension, rather you just create another template. But this then imposes a restriction that the output of the template is fixed. So there's no variation for different skins or different view ports, it is what it is. Whereas an extension would have more flexibility in how to declare these things. So I think we'll talk more about that in a beautiful layout session tomorrow. On the other side you also have a lot of markers like how to style a button, how to style highlighted rows in a table and again those are all traditionally done as inline styles. And I think we're getting a little bit better at that now over the past few years where we're more encouraging things like using CSS for this. But this is still very unattractive because it requires using common.css to do this or adding a gadget by default which is then a lot tricky for the mobile app to get it to render it using an HTML parser or be able to apply CSS to it very freely. So you then have also a semantic image match of even if you get the styles in, you still can't vary the styles or know what they actually mean. Right, so just to kind of wrap that all up you're saying for figuring out the issue or to discuss more the issue of like where that line is drawn go to the semantic image and beautiful layout talk because that's where you're going to go. So what we're going to talk about is the midwakey skin class does have some miraculous methods that do some kind of page component system. So one of them is the linker methods which have actually been moved out recently but they used to be in the skin class which would allow the skin to control what a link looks like and what a thumbnail looks like. This was then decided to be a bad idea so we moved it out to a different system which we may want to extend and further build upon this idea of a skin being able to provide hooks for like this is the data and give me some HTML back to render that type of data without the page knowing about it. But that of course then complicates things because as being part of the page output you can then no longer cache it in a skin agnostic way which is the main reason why we moved it out of the skin because ideally the page content is one blob but again there's another one. My name is Pratik Saxena. There's this one issue about skins that really confuses me and I wanted to highlight it. So extensions add a lot of user interface and some extensions use OUI or some other UI library to do that and ideally you would want the skin to be able to change the way the UI of the extension looks as well because it has UI components that should look the same as the skin does and right now if all extensions end up looking the same it is first write a media wiki skin and then write an OJS UI team that matches your skin. Is that something that will continue to happen or do we have ideas apart from that? So I'm from the UI extension team and there are currently ideas around that to provide an easier way to influence that but none of those because it's like a very complex layer solution that we provide right now none of those is in a stadium where we can say this seems promising enough. We are aware of that problem and we try to figure out the way but it's again like you said we are we are we need to find boundaries and we need to find guidelines for extension developers how to best interact with our components and provide a user interface that is one of a kind. Right, it's just that like we're talking about one aspect of skins where it is right now to develop skins because they're not actually skins they're extensions and there's the other aspect that it can never be as simple as writing a WordPress theme because you'll have so many components that you'll have to take care of or are we deciding that there are certain pages that the skin just never affects and only use whatever interface that they made initially like an admin back end so the thing is yes so the thing is I coming from the WordPress side I don't think that writing skins is especially easily on WordPress it's just different the ways that we are the ways of content creation that we have within MidaViki are completely different and have a lot of of boundaries already included so from from an architecture perspective we should make those boundaries clearer and easier for extension developers and also for skin creators but that takes some effort thank you I would like to add a little bit to that because I just forgot my point I'll do it later what is your time? Trevor? Yeah, sorry I would actually suggest that having done some WordPress themes myself they don't even have a way for WordPress plugins to automatically match a skin I think actually it's probably a good thing for us if extensions were using some sort of standard library like OUI because then as long as the theme provides an OUI theme as long as our skin provides an OUI theme then they will match even if the person who made that extension had never used that skin before that's actually a solution to a problem that WordPress has the thing I really wanted to say though is that you were sort of saying like what if we did this crazy thing where it was like this declarative thing and I just kind of wanted to bring the light that our skin right now is sitting on what isn't really an API and that's a problem so we were talking about that earlier we really need to have an API that our skin sits on but we need to also remember that our skin itself is an API or isn't really an API and people end up just using the HTML markup as an API and that's again one of the reasons why we can't move very quickly is because any time you change the markup it breaks everything and so as long as we're still using the HTML markup as the API which to be fair we haven't really provided anything else so we can't really criticize people for using it that's going to be another problem so as much as on the bottom end we need to worry about the API and separate things there we also need to make sure that any skin system that we implement provides top level API for gadgets and extensions to go in and modify and augment the skin in a generic way so that the same extension and gadget can work on any skin without having to be uniquely modified so the the thing that you're referring to as being breaking is gadgets I just wanted to clarify that well extensions do it too a lot so on the server side they would add arbitrary HTML without using the correct templates and on the client side the same thing so I just want to compare a little bit more with the WordPress so like in theory we could make a theme system more like WordPress it's not that we can't it's just that we actually if you think about it a little bit more we don't want that because if you look at what WordPress does it wraps the arbitrary content and it kind of is the same for all themes and the problem that we are addressing here specifically that we actually want to vary the content between different skins very often at least have some hooks into how specific components are rendered we don't necessarily want it to arbitrarily change the content and that is the fundamental difference where we're having lots of difficulty and also influence from user preferences for example the other thing I want to refer to is the OEI component so a bit of a paradox that we have right now is if an extension wants to use OEI and the component that they want to use doesn't exist yet they either add it in core and everything works works fine or they add it in the extension in which case it might not be as generic as it should be but I think we're getting a little bit better at that now because we need to now share the less variable context as in less parser context between extensions and core which means even if they write their own components they could in theory if we improve further upon this idea they could write components that actually work very well with the other components in the same mix between extensions I just think OEI could be a lot easier to theme and I just think it would be better for us to spend more effort trying to get OEI to be easier to theme than to try and figure out how to never theme OEI so so I'm James Hare and I'm asking in the context of wiki projects which you brought up earlier and one of the things with wiki projects is that they have very user needs like to the extent that what is currently baked into media wiki is not very ideal for designing wiki projects and for us to have created an extension would have been overkill or at least it wouldn't have worked on our product timeline and at the same time we can't like do we can't do site-wide CSS and we can't do site-wide JavaScript because our specific application that only applies to a very specific subset of users would be available to every single person who visits Wikipedia which would just be a huge waste of bandwidth and resources and gadgets are okay but gadgets you have to have them turned on by default in order for them to be useful and that creates a whole political battle that most of the time isn't worth the effort it's also not what they're designed for and so really I just want to be the ability to have sort of bespoke interfaces on very specific situations to address specific needs and this is not something that media wiki may not always be able to address in advance and so it's what I'm interested in is making it easier so that if I invest resources in coming up with a design for collaborative interfaces as it were just simply beyond what I can just do in templates something that allows me to use CSS and JavaScript to greatly enhance user experience I want to be able to have these domains that make use of this custom interface and I want it to be easy to deploy and I don't want it to be caught up in garret hell as it were so anything that would allow anything that allows us to address very specific use cases in media wiki and create custom user experiences around that would be most useful we should have a long in length discussion later I would love to hear from your catch-ups that you tried to accomplish tomorrow at 11.30 I did tomorrow at 11.30 if there is still room on the schedule I haven't had a chance to check yet is our session on wiki projects and coordinating with overall software development because what we found in coming up with the new wiki project tools and interfaces is that we are kind of doing stuff that should be done in media wiki but we are kind of doing it on the side and so we are not getting the best outcome for it because really what we should be doing is just extending media wiki but instead we are relying on the existing system which works it just doesn't work well with with current architecture we see a lot of authors who are trying to implement some special ideas that they don't have fulfilled by out of the box media wiki and then they are working with inline styles on a very complex it's like very complex solutions to sometimes very low level needs and this is a big issue that we try to care about much more in the upcoming weeks and month and I would love to get into a discussion with you with my team colleague and see what your problems are very good, thank you Hi, Derek Yellen or the DJ Scott wanted to know a few specific examples for what James problem was so I hope that James can return with Scott here on that one thing that I want to well one thing, a couple of things that I want to say we should of course not forget that it's whatever we're talking about here we have to remember that it's a very very very old system, like it's one of the first things of media wiki that was written the skin system and everything that connects with it and it's probably also the one that was most neglected because we got away with it for so long so let's also be positive, I mean we we did achieve a whole lot over the past five years in being able to vary skins and styles and all that it's just very very complicated but we've also still got a lot of crown to cover so looking at mobile frontend for instance there's a whole lot of styles and style directives that we could easily incorporate into different parts of existing skins but we've not done it yet we've not made those elements part of the core style sheets and the core style schemas that we have and we should there's a lot of options but a lot of this stuff is not documented or it's not documented well enough and it's understandable why that is so because again it's very complicated it's very difficult to properly communicate how to make these extensions and how to get them deployed on media wiki or at least wiki media media wiki but it's doable if we spend a lot more time on it so the question is more like do we want to solve it I think because a lot of what I'm seeing is that it basically gets ditched for higher priority elements goals that we want to reach so I think it's more a question of do we want to fix it and do we want to enable the people who want to fix it do we want to enable them to fix it themselves and to sort of come back for instance to the issue that James was running into with the wiki projects it's something that we've seen on a lot of areas that are skins for off the content and the content itself uses a lot of inline styling right now and the reason it does that is because you cannot imagine because I'm from the English Wikipedia I know all of these areas you cannot imagine the amount of styling that is hidden away inside content right now and you cannot pull all of that into like you would send 5 megabytes of style sheets towards everyone so I think that one of the things that we keep coming back to is that we really need templated styles there needs to be a connection between a template and a style that goes with it because there's no way that you are ever going to make a skin that will adapt to all situations you might like squeeze it into something that's acceptable for your format but you will not be able to anticipate all the ways that content creators will want to influence style and will need to have to influence style so that's something that we it's something that we have to solve it's the only way and the one last point that I want to address is that the thing that keeps coming up with the skins is that basically we have two skins we have the visual skin and the layout skin right now it's a GML layout skin that's a concept that's not very familiar in a lot of different systems I've been wondering whether or not we should not just decouple those two so that you would have like visual styles as WordPress mostly has versus layout skins because now we have vector which is basically both and monobuck which is basically both whereas monobuck and vector actually share a lot but and then what you see is that a lot of people try to fix this by just fixing vector, the HTML vector or whatever they run into problems when the next version of Maniwiki is released because everything we changed was not documented so I think we need to create better separation there and also be better in creating stable API interfaces for that and testing them actually because it's one of the oldest parts of the system it's not tested, it's not being tested it's so every time we have a Maniwiki update we break something, we promise backwards compatibility that we don't deliver often and then it's logical that you'll get into a skin nightmare and that's what I wanted to say those are all very valid points for the first one about we share styles we have styles now in mobile skin that should go into core so I think we have to be very careful on what is in core and how it interacts with extensions, skins so the problem that we've heard here is that in contrast to for example wordpress a Maniwiki skin has to care about back end and front end so to say back end and front end it has to fulfill a lot of things out of the box already so it's a pretty big thing if you're a skin developer that is one of the things you can't break it down to a certain point you have to in order to make your skin somehow workable fulfill all the needs which is crazy and breaking that down into a more modularized way and still providing it for all extension developers would be the wished outcome so as for your other points as Foko said for mobile front end there's definitely a lot of things that we can move into core one of the things I like about the front end of mobile front end which itself also describes that there's a problem between front end and front end is that so for example the table of contents is a page component in mobile front end is a JavaScript module that is an idea that we could use in core like imagine the table of contents in core and OUI widget and also I want to emphasize here that using OUI doesn't go hand in hand with changing how it looks it's just a technique to use how to actually generate the HTML it doesn't say that we change the looks of anything it does open the doors to do that when we want to in a much more scalable fashion but it's not a prerequisite we can make OUI cells be anything they want to be so that would be one way we could potentially improve the situation if we imagine that the OUI contents and the table of contents in OUI widget like that could solve a lot of problems potentially and it would allow skins to vary them but using CSS only without changing the HTML and I think that's a direction we should try to explore in more areas of the skin is to less encourage changing the HTML to change the styling and rather improve our HTML to be more adaptive to those things there is limitations there there will be exceptions probably but core components that are part of the page I think it might work and that also raises the question do we want on wiki templates to use OUI more I've seen a few uses of it mostly when it comes to buttons we can make a comment on their main page I believe but would we want English Wikipedia to use OUI in the infobox template like what does that entail what does that trigger we can use Lua modules for that and the integration of that HTML there have been some initiatives there that I think are really interesting to explore okay so this wasn't actually what I came up here to talk about but to follow up on what DJ was saying it's not so much that there's a visual skin and an HTML layout skin there's a page layout and then there's components and both of these add up into what you have this visual and maybe we do need to separate them out that actually might help a lot but yeah and more to the point though or whatever my point was anyway we have skin styles, we have JSUI styles we have styles coming from extensions we have styles just everywhere something we really need to fix is we need something to actually own all of these styles in one place regardless of which thing it is we need to have it as one thing that's easy to work with this won't cover the page layout but it will cover the components it may be able to govern aspects of the layout so it will still go together that well I don't know the point is we need it in one place and if you're trying to make a OUI theme and a skin theme as separate things that's just you can't maintain that long term and that's not even all the different things you need to work with in order to make it work so if I understand it correctly everything besides page layout should be every styles besides page layout should be in one single place because you will always have media wiki software from my perspective if we allow it we will always have authors, editors introducing their styles and there are things that can be reused in all these different things but still you won't fulfill all needs out there but if we can figure out what tends to be common if we can distill down what the different OUI themes are into what they're actually defining that would simplify them a lot too and that might be a good place to start because then the templates could reuse the same values the skin could reuse those values within so if we can't centralize the CSS itself we can at least centralize the input variables for the CSS we can set the values so I think it's not scalable to have all page components be in one place because some of them come from extensions but at least those extensions should be reusing individual aspects of the page components that we have in core but we do need proper APIs to define that this is a blah object this is a whatever and stuff like that I have another point that's alright see Scott was asking about specific examples for WikiProject X it was up there more but I guess one of the main things we ran into was that there was no way to make it support mobile you need to have actual style sheets for the different resolutions for that and the only way to do that is to add it with JavaScript that requires a gadget that's not really what gadgets are for and we really need some way on the Wiki itself to make things responsive yeah I've seen those templates and they also result in the flash upon our content can they trigger after the two step rocket expands like a minute later into the page yeah and if you want another example there's also when you've got gadgets that you're building upon so you've got a generic gadget then you're building upon that gadget with a new thing and that makes a mess of the interface cases so making something responsive sounds very good and I would love to say yes this is the way to go the issue coming from a user experience side is that we are coming from an architecture that was desktop first and if we are implementing for example tables in media wiki this is even if we come up with simple styles it's not a real responsive or even a mobile first design it's just trying to transform something desktopy into a mobile experience which is horrible from a user experience that's not what we're trying to do though we just had a bunch of things on the page and we wanted them to show up in different places depending on the device I'm thinking about current implementations where we want to focus on how to best come up with a responsive solution the thing is that there is not if you don't involve design if you don't involve design research in those things then you will come up with a solution that doesn't really benefit your users without having clear research outcome does it benefit the users to actually be able to see everything on the page nope because you have for example super long table outcomes or vertical I think maybe we can table this part of the conversation I'm not going to transcribe you guys are arguing about design research we have 25 more minutes I'm going to ask anyone who hasn't had a chance to say their piece to get in line now or wait for one of the other sessions I also see that C Scott is making good use of etherpad communication so if you're not one for talking into a microphone definitely jump in use some bright colors so that the moderators or the folks moderating can see Hi, I'm Steven I'm an Android developer about ten years ago I worked on a WordPress theme very small and I don't think some of the comparisons to WordPress theming are necessarily fair for my community blog there was only like a thousand posts and so I was able to work on a skin for that with the idea that posts will look like this and I didn't have to support a whole lot of special pages with skinning it feels more like it has to support all of Wikipedia the other thing that worked really well with WordPress for me was even at that time there were many many not just like good looking but like beautiful looking examples that you could look at the source code for and pull little bits and pieces from and I'm not I'm not sure that that's true for Media Wiki at a previous role I just really wanted to have a company and media Wiki installation and that proved to be pretty difficult I didn't want a whole lot but what I did implement from the vector theme felt more like an embarrassing hack job and I I felt that styling individual pages with Wiki text was way easier I'm not sure that maybe that is very valuable but I thought the comment was worth making thank you so one question I had during this discussion so far is do we see skins as the visual representation only or do we see skins as a mechanism to adapt to different devices and network conditions and so on so that basically speaks to should we aim for one responsive skin that adapts to the user's device and network conditions and where the skin part is basically how it looks and the theme the look is very consistent between mobile and desktop or do we mix it to I think a lot of the discussion about the components and being able to swap out different parts both in this session and in the previous session actually aim more for the responsive part where you swap out this one component for a lighter weight version or you emit it all together and you see components more as a high level unit of composition within and inside of these components there might be templating or extensions or other code that runs another remark I wanted to make is that there's a lot of overlap between the content and the skinning actually in this because we're talking about NAF boxes and we're talking about NAF boxes those are all content concepts but they're also very relevant for skins and so maybe there's actually a shared need for these components between those two areas that could be exploited to your first comment that is what I wanted to say so just because we make something visible in mobile it doesn't make it good usable easily so we have to if we want to make progress on that side that we are coming from a content side that we decide is the content necessary for a mobile user who has different needs, different wishes with interaction from the side which plays into the same area like the section element discussion do we need table of contents and introduction of the side as first view and then go for the full content later so I'm not I can't answer that question right now if we want to go there but this is actually the crucial point for me do we want responsive skins or do we want like different outcomes for mobile users and desktop users for example so I think that we've been talking a lot about basically different strategies to solve a problem without really talking about what the problem is and I would suggest that the problem is that we need to be able to change things without breaking everything and I went through changing from monobuck to vector and we broke everything and then had to go through cleaning it all up and it was really it was very it was very complicated and it caused a lot of stress for people and it was so stressful for me I actually like took a break from front end and like wrote resource loader with Roan like I hated doing front end for a while it's I know why people don't write skins and so like I think there's a lot of really good strategies here for how to achieve that but I just kind of want to at least posit that as potentially that is the strategic problem we're trying to solve and not get too caught up in one solution or another but just really like try and build some agreement around that if other people feel differently or feel the same Thanks I'm Scott McLeod from World University in School which is Creative Commons licensed I'm interested in the sort of out of the box brainstorming way 10 years ahead roadmap kind of question where this user interface conversation will go in terms particularly of brainwave headsets both into virtual worlds but perhaps even studying or Wikimedians Wikipedians and perhaps with intermediate roadmap steps in terms of many languages the 300 languages that Wikipedia is in and where the Wikimedia or media wikis heading in those anticipatory kind of is there a forking moment right now where you would choose one path so the rebuilding that the previous speaker just mentioned you know might be avoided so I didn't get quite the beginning of that could you repeat that so where particularly with brainwave headsets is user interface media wiki going 10 years out would it be a Q item in wiki data would it be a specific language differential link relative to the wiki data Q item for example so you have sensors on your brain you would be going through user interface in media wiki either into a virtual world or back to into your own brain and user sort of research brain research at MIT OpenCourseWare for example schools I'm not sure how to answer I think if you're referring to how the navigation model would work within media wiki as a user how you can find and explore different pieces of content that are related I'm not sure exactly how that ties into the skin process are you saying that that's an obstacle we should try to overcome or is that a use case we should consider and how to compose the skin so in my brainstorming roadmap ahead question I'm curious where the laying out of media wikis next steps will lead in terms of subsequent perhaps skins but perhaps more generally user interface questions that lead to other kinds of sort of interactivity that might so I'm not sure I'm answering your question but that is my question I think I can take a stab at this which is that we are not generally pioneers in terms of new interaction paradigms I would say that the brain wave headsets are probably further out than we're thinking I would say that probably what we're thinking about is VR and as of yet we don't have a roadmap for how we're going to be adapting our content or navigation schema for that particular user interface or set of user interfaces so I would say that the brain wave stuff is probably even further out so we don't but if you have ideas around when you think the timing is for that we'd be all ears thanks keeper to chum in here I think it also ties in with the wiki data and the discovery initiatives to really encourage that kind of interaction and I think that the improved skin system would allow for those things to be more easily developed without having to overcome the problem of how you can actually expose this to the user without having to bust through all of these different layers so right now even if our backend infrastructure and the elastic search and the different indexes that we have would allow that it would still be extremely difficult to actually present this to the user right now it would probably be a separate tool in two labs simply because you want to bypass all of this because it's such a big obstacle so in a way this is a prerequisite to that as well and an enabling factor to allow that in the future Hi, my name is Jiang I'm also from Google and since all the discussions so far are focused on changing the skin and I'm trying to use case that we actually want skin as stable as possible to give you an example we used to think about to use the layout to detect info box because in different languages info box are using marked out using different text and we want to find out a generic way to detect info box in different languages and we once think about trying to identify info box by using the location in the browser so we actually do not know if the skin layout is stable or not if we come up with some heuristic algorithm by detecting info box from the browser location how stable our algorithm could be Yeah, I can very much empathize with your pain in that area so we've seen this happen from time to time when we make external changes to the skin either intentional or unintentional for various reasons and how this affects Google search results like having edit links show up in the search excerpt or things like that that I imagine might be hard coders like an exception for Wikipedia, I'm not sure but I think having a more well-defined page component system would probably be very useful for you in that case so you wouldn't necessarily need to go through the HTML of the skin, you would be able to either fetch data points from Wikidata directly or use the abstract HTML which doesn't have the skin layout around it so it would simplify things a lot I imagine and also you would benefit from accessing content that is unexpanded, so instead of having a different table you'd have something like that your issue is actually very similar to the problem that Trevor brought up about gadgets needing a stable API as well and so we are thinking about wrapping info boxes in something like an info box component tag so it's easy to identify but we will need metadata for that possibly in template data where we have a mechanism for that but we have that need as well so I think we should talk and it also brings up the fact that info boxes, as crazy as it might sound are actually not an entity in MediaWiki or in an extension, there is no info box tag or an extension it's all user based, it's a template that happens to look like an info box it might as well present an image of a pony we don't actually, it's not recognized in any way inside the system both from the users or from the developers point of view, it's just a table that happens to look like what we now know as an info box and that is I think even lower layer barrier that we actually need to recognize which is to implement info boxes as a more recognized entity across wikis a lot of that has been deferred I think into superiority in favor of wiki data which bypasses some of these problems in a more machine readable way which is actually even better I imagine but even from UI point of view it's still very much beneficial to send out as info boxes even if they have to look differently I find it very difficult to believe that we need to vary the HTML on that I will scroll down Scott, sorry yes, so I think info box is just an example that the UI layout can be, if UI layout is stable enough we can come up with some puristic that cross languages other examples are like head notes, mailbox topic, the table content so long as there is some common structure no matter it's in DOM tree or it's in the UI layout we could come out some puristic to make the machine really be intelligent are there kind of like semantic annotations that would help you out in your work that kind of come to mind so regarding the semantic annotation the problem we are facing is that Wikipedia is natively multi-lingual and it's really hard for us to have one algorithm processing different languages and then you have also the fact that we actually keep changing even the English implementation as well that was actually my next question and apologies if I kind of missed it but like how does the multi-lingual aspect play into this like an open-ended question like what is like your best thinking on it so try to come up with some examples of what you think what you are right so there are differences between the different Wiki projects and the way that stuff is processed in a per-language context does very pretty widely like does the sort of solution that you're talking about or like this general way of thinking help to address that does it help to bring uniformity to the language stuff or is I guess like the language specific stuff something we can't actually solve so there's like a few different aspects to that the most prolific one the LTR versus RTL right to left languages is solved pretty well in the case of interface problems you have like length overflowing content in gadgets and interfaces which we take care of when it comes to parsing issues like said before that is a whole it's a big complex topic that for example in the work discovery is currently targeted how to interact with search in multilingual environments but it's this is a big thing where we are partly pioneering in solutions is this makes sense there's like kind of dealing with it from an interaction pattern standpoint and also dealing with like the latent semantic meaning which is probably yeah it's a harder problem to solve I just wasn't sure where we were at with that thanks I would like to add one comment the etherpad informs us we have five minutes before food I'm assuming it was written in 1240 so that makes it three minutes before lunch I'll add one comment and then wrap things up and maybe allow one last round of questions if we can so for the multilingual stuff we would do better to bypass the language problem and instead focus on the community problem because things vary across languages and there are some things specific to particular languages but I think that is mostly a separate problem that the seven percent were currently solving some that were not but I think if we would solve the problem of things varying over time even within a language we automatically also solve the problem of being different between different projects and different languages so I what's that why is that I see what you mean, yeah you weren't thinking of particular languages that wouldn't be covered okay, yeah so I made some takeaway points and feel free to add things here is this a summary? let us have one more question a very fast one this is just kind of trying to bring back Trevor's thing and both Scots and just in general I guess my question is it seems like when mobile came along skins were not sufficient for developing mobile so there was these two alternate solutions created which is the apps to choose native components or a mix of native and on-device HTML parsing stuff and then mobile front end and I guess my question is is the goal here to fix that and to not have that happen again or to the brainwaves and just other things if we're going to five years from now the new thing is I can't predict now how do we keep skins from just continuing to be a solution that gets weird stuff hacked on, I don't know that's the general do we want skins? I guess for the next three to five years we want skins so I'm feeling like we're running out of time there's two more people how we should keep it up seriously because people getting hungry we're running out of lunchtime okay so please okay I'm Jack Taylor Mr. Stradivarius I was just going to talk about the info box thing we're talking about separating the info boxes from the content so we're talking about separating the info boxes and but there's a lot of the issues as well social issues that we need to think about at the moment we have something like 1000 info box templates on the English Wikipedia and they all have their own logic built into them and often they're created by people who don't really know template programming that well so moving them to Lua or other systems would be we might get a lot of blowback from that but we think about when we think about converting all these info boxes to the system we're going to have to be careful that's all I wanted to say I just have a really quick comment so like whoever ends up working on this my advice is just that you can't optimize for everything and right now we've sort of optimized for nothing I think it's great if we optimize for something but we need to be really deliberate about what we optimize for and just ease of use for developers fine let's just like call that out and say we're going to try and make our lives really easy and it's going to suck for everything else or if it's going to be maximum device compatibility or maximum amount of responsiveness or whatever it is but I think that there needs to be there needs to be like a stated problem and a state solution but also like what it is that we are actually trying to optimize for in the way we solve it and I think that's really going to guide us to the right solution there's tons of really cool ideas up here but all of them are sort of optimizing for different things so we just need to be deliberate about that and I don't even know what that is yet but that's I think it's an important conversation to have so I'm very happy that all of you joined for this session and I'm looking forward to the next two thanks Timo and thanks participants here in the room and elsewhere we're going to have those three related sessions follow-up sessions and yeah, thank you very much