 So good afternoon. I'm glad you're all here. Today we're going to be talking about the Drupal 8 mobile initiative. We, Lewis and I, really want to make this an interactive discussion. You get to talk about things that you want to see in Drupal 8, things that you want to help with in Drupal 8, problems you're seeing in Drupal 7 mobile experiences and mobile solutions, and we'll be talking about sort of the goals of the initiative so far, and I'd just like to say that the goals of the initiative are driven by the community needs and by community participation. So I'm John Albin Wilkins. Hi, I'm Lewis Nyman. I work for Cap Gemini. I'm a designer and a front-end developer. Yeah, I suppose I should say who I work for too. I work for Pralenture.net. They're a Chicago-based company, a great group of people. So the Drupal 8 mobile initiative is a specific initiative within the Drupal 8 sphere. There are about six initiatives right now for Drupal 8 dealing with the various sort of key features that Dries would like to see in Drupal 8, and as you saw from his keynote on Tuesday, he's really, really wants Drupal 8 to be mobile-friendly, and that's one of my goals too, and when you start thinking about what does that mean, you have to look at sort of how mobile solutions are being built right now, and there are a lot of different ways of doing stuff. There's native apps. There's HTML5 web apps. There are sort of the mobile sites, desktop sites, switching back and forth between domains. There's responsive design. There's also something, Roblusky coined as a REST, responsive design plus server-side components. Drupal 8 should be able to support all of those. There's no reason we should choose one over the other, because we want it to be a generalized platform that can work for anybody, right? And when you start looking at the sort of things that we need in Drupal 8, basically it comes down to we need web services, HTML5, and those are actually underneath existing initiatives. There's a web services initiative and core context, which is, you probably heard it called Whiskey. You saw Larry Garfield in the blue shirt on the video on Dries' keynote. He's running that, and Jason is running the HTML5 initiative. We're working very closely with other initiatives because our goals sort of overlap. So the only way that Drupal 8 will succeed as a mobile-friendly platform is evolve our initiatives succeed. So those first two points are under different initiatives, but feel free to talk about anything mobile, because like I said, we're working together. So even if it's not technically within the bit that I'm leading, it doesn't really matter. I'll talk to Larry or talk to Jason. We'll get it all sort of sorted out. So the things that are actually under the mobile initiative are responsive themes, converting all the existing themes to be responsive front and performance because it's so crucial to having a mobile solution. And documentation, this is one because mobile is so new. Everybody's sort of learning stuff right now. They're still trying to figure stuff out. And one great way to participate as a new person in the mobile sphere is as you figure stuff out to write it down. So we started a documentation guide on Drupal.org for anything mobile. And it's got native app stuff. It has web app, responsive design, front end performance, all of that stuff is on there. And anybody of any experience level can contribute to documentation. And then the last thing is actually the one of the most, this is the first thing that you see when you install a Drupal site is the admin side. The admin screen is setting it up. So a big part of my work has been on the admin interface of Drupal. And so as well as making Drupal a good framework, a good tool for making mobile apps, it should also be a good mobile app in itself. So we've been doing a lot of work rethinking Drupal's admin interface. So it's usable on small screens and touch screen devices. So when we release Drupal 8, you can offer this to your clients as a CMS, but they can use anywhere they want. And it's also great for us because I was always in a lot of situations where my freelance clients were emailing me or texting me saying, I broke something, please fix it now. And I wasn't always at my computer. So I was back in Drupal 6 when I was trying to use a tiny little phone to make some changes and it was an absolute pain. So, yeah, I really come around on that, the mobile friendly admin side because at first I was like, wow, that sounds kind of hard. I'm not sure if we necessarily need to do that. But it really, it's the first thing you see. And just like with Drupal 7 where we replaced all the crappy things that were in Drupal 6 because it was, you know, first thing as a designer you saw when you installed Drupal 7, the themes were much better. Same thing with the administrative interface for Drupal 8. We want that to be a mobile friendly experience right out of the box and go, hey, look at this. This is nice. First impression to matter. So that's why it's important that this part is the Drupal 8 solution. Yeah, and it's actually been really interesting if you approach the design of the CMS from a mobile-first perspective because it's kind of forcing us to rethink Drupal's interface with more simplicity, which, and some of those like, some of those efforts have actually fallen back into the desktop design as well. Yeah. I just want to point out that the initiative home page basically is on groups.drupal.org slash mobile slash Drupal dash 8 there. And that's where there's a list of all of the, there's a link to like the documentation page. There's a strategy page there as well. There's the list of all the actual issues and the issue queue that are related to the mobile initiative. And we have postings about regular office hours and IRC meetings that we have. But I really want people to like jump up now and start asking questions about, and are making comments about your mobile experiences in Drupal 7 and also things that you want to see or questions you have about the initiative. So. Ah. Whoops. You are right. Let me fix that slide right now. Thank you. Yeah. There's a microphone in the center. That might help you. Well, I can repeat the question because of recording. So the question was, what's your definition of a mobile device? And where did tablets fit in the equation? So you want to go for it? That's a really interesting question because the term mobile could be interpreted by so many people as different things. It used to mean a mobile phone, but the definition of that keeps changing every year. Or we could interpret it to mean a mobile device, the one that you carry around with you. And if you think of it in a broader definition like that, then it includes, you know, phones, tablets, e-readers, really anything that laptop. Well, yeah, it has to work on them as well. But there's really so many factors that affect devices nowadays. It's really hard to put them in classes like this is a mobile, this is a tablet because there's so much in between those two definitions. Yeah. I think as far as the initiative goes, we're looking at making sure that Drupal works with, you know, different size screens, so smaller screens than we've traditionally been sort of targeting as well as touch interfaces. And those sort of device capabilities that we're targeting can apply to whatever the actual device happens to be, right? Because it's important that you sort of think about device capabilities instead of actual devices. So. Right, especially because Drupal 8 isn't going to come out for another year. Yeah. And then a slice band is going to be, you know, at least another five, right? So we can't really be thinking about what devices do now. We just have to think about what they could do or just do as much feature detection as possible. You don't have to come up. You can just sort of, yeah. The back end of Drupal is very sort of heavy, the stack. And that the back end performance is also a big consideration. So I will agree with you and also sort of counter to in that when you look at sort of the traditional waterfall graphs of loading a particular web page, there's, you know, so many seconds for how long it takes for the HTML to load. And then all of the assets, the images, the JavaScript, the CSS, those always take much longer than that initial HTML page because it's just one HTTP request for the HTML page and it's multiple HTTP requests. So there's a lot of back and forth between the servers and you take much longer for that stuff to go out. So that's why it's actually an easier way to optimize your site is to focus on front end performance, you know, but this is a part where I agree with you now. That was the counter and now is that you can come to the agreement. You're absolutely right. Yes. Yeah. So the web services initiative is absolutely looking at that issue because they agree that the Drupal stack is very heavy and has the bootstrap in Drupal 7 is complicated. I don't fully understand it. So they're working on revamping that in order to be able to basically request what we now think of as a page that you would be able to request basically pieces of a page and be able to get that much quicker and that's part of the conversion to symphony using the symphony components. So I'm hoping the web services initiative will succeed and improve massively the back end performance of Drupal in the white back there. Do you see background images? Adaptive images. Okay. Go ahead. Yes. No, I come. Sorry. So for the people watching the video, the comment, the question first was, are we looking at adaptive images for Drupal 8? And then there was also a comment about, oh, a question about whether or not the initiative included Drupal.org improvements in order to make it mobile friendly because the Drupal.org website is not currently very friendly. And he commented saying that, you know, Dries' comment about nobody posts screenshots of iPhones. Well, nobody posts screens of iPhones because iPhone users can't use Drupal.org comments very well. I've tried that, tried to go through the issue queue in the Drupal 8 initiative and use it from a phone. It's really hard. And technically it's not part of the initiative because we're focused on Drupal 8 code and not Drupal infrastructure code, but it's something, it's one of those sort of tangential things that I feel like talking about Drupal 8 mobile initiative sort of kicks off a discussion about Drupal.org infrastructure and I've seen some sort of action being started to take. So you can actually find there's a, there is, there are a couple issues right now on the issue queue for Drupal.org infrastructure talking about improving the, you know, being able to like post comments on issues from your phone, for example, making the entire site more responsive. I feel like we can get the issue queue stuff done a bit quicker than the entire, make the entire theme responsive, right? But, and then with adaptive images, yeah, we're definitely looking at that. Adaptive images is a really complex problem. If you look at the web design community in general, this is a big discussion and there's no perfect solution, right? So Jason Grigsby gives a great discussion of the problem space of adaptive images. So if you're not familiar with all of the sort of cookie and JavaScript and browser pre-fetching issues about around images, if you go to cloud4.com slash blog, you can find the, the post that he did last, I want to say November-ish time frame about responsive images that are excellent to describe the problem space. So with Drupal 8, basically we're watching sort of the development of Drupal 7 contrib modules for responsive images. We're also watching the greater design, web design community to see what solutions they come up with. I'm part of the, there's a W3C group now talking about responsive images around the, the picture tag, this proposal. We're, we're watching everything and we're going to try to pick the best solution for Drupal 8. Right now, I, of the solutions that have been proposed, Matt Wilcox has an adaptive images solution which I think is the, would be the best fit for Drupal in, in the way that Drupal works. So there might be other solutions that work better for other types of systems, but I think that one will work best for Drupal. That's what I'm kind of leaning towards, but it's, it's a little early to, but it's something that if people want to start working on that, to give us a leg up on those particular issues, that would be great. So like, if you want, let me jump over to, I don't know what you're doing. Can I just quickly jump to, back to the Drupal.org question? If you've seen the Drupal Association's roadmap for this year, it's on their list to make Drupal.org responsive. So it's probably going to be one of those things where they pay an agency to just get it done. I can't speak for them, obviously. Yeah. And I'd like to say, if there's stuff that you guys would love to participate in, we're actually doing a mobile initiative Sprint on Friday. And it's actually in this room. So, and it starts at nine. If you've been out partying the night before, you don't have to show up till noon, but, you know, we'll be here most of the day. So, oh, yeah. So funny you should ask, you know, I'll let you start. You were just looking at this. Yeah. So it's responsive tables is so dependent on the content you have in them. There's been lots of examples of reflowing the layout or hiding some of the columns that only works for certain kinds of data. In some situations, some people have said that it's better to show the content in a graph or in a list format. So in some cases, the table market is only going to get you so far, especially for smaller screens. So possibly some of the solutions here might have to be in JavaScript or server side to completely reformat the data to be more friendly for smaller screens, but it really does depend on the content you're showing. Yeah. Yeah. So the permissions page is a bit like a black hole on desktop. So for mobile, I'm kind of leaving that near the end and do everything else first, because if I get drawn into that, then nothing else will get done. We'll spend the whole year trying to work that page out. But for other pages, we have like listings of content or lists of menus or content types. They're all set in tables and I'm actually thinking that really we can probably set them in ULs and get away with it. By the way, if there's any UX people here and you would love a challenge, we have this permissions page that really needs some love. Next year. So the question was that a lot of the newer phones support HTML5, which are great as far as having nice or rich widgets, et cetera, for applications. And the question was what about older phones that don't support HTML5 or older feature phones? So the nice thing that, do you want to talk about it? Well, I was just going to say progressive enhancement, progressive enhancement, progressive enhancement all the way. So we're going to design a nice interface with touch screen devices, but it's all going to be done conditionally. So we're only going to load a touch family interface if there's actually touch screens available to take a bunch of it, otherwise we're just going to keep it really basic for dumb phones. Yeah, in addition to that though, the creators of the HTML5 spec have been keeping that in mind. So any HTML5 element that you use is sort of especially form widgets. They are all backwards compatible with old browsers in that if you pick a date HTML5 picker, it'll just revert to like a, I think it's a text area or something like that. It just becomes a basic text area on any browser that doesn't understand it, because it's a type, so it's input type, I forget what it is, date, right? So if it doesn't understand the type, it still displays the widget, but it just uses its default, which is text. It does a text input. It's really great that the design of the HTML5 spec was made to gracefully degrade for devices or browsers that don't understand it. So luckily Drupal doesn't really have to do with the progressive enhancement that Lewis was talking about. I thought I saw some other hands, but I've lost who was holding up their hands. You're just drinking water. So let me talk briefly about some of the responsive stuff that we're working on. We've already dropped Garland from Drupal 8, so that's part of Drupal 8. So that means the themes that are left are Stark, Seven, and Bartik. We're going to be converting all of those to be responsive. The first one we're tackling, of course, is Stark, because it's our lean theme that only has a little bit of layout CSS. So we've just finished doing that and sort of in the RTB-CQ now waiting for some sort of core committers to review it and get it into core. But Luke Robluski actually did a post last week about multi-device layout pattern that he saw. And it turns out that this is the pattern that's going to be for Stark. So basically you've got your main content here, first sidebar, second sidebar, and it gets smaller, the second sidebar drops down to here. When the second sidebar drops down to here, rather than just having the blocks be super wide across, which is effectively a three-column grid, we are laying out the blocks that are in that region in a three-column grid. So the first block, the third block, fourth block, fifth block, sixth block, you know, on down like that. And then this is just a regular sort of mobile single column there. This is it's sort of neat to see the work that we did fit in nicely with what Luke was noticing in the responsive layouts. But I actually gave a talk yesterday about the limitations of region-based layouts and there's only so much you can do from a from a theme that is going to be sort of distributed to end users where you don't know what the end user is actually going to what they don't know, we don't know what content they're actually going to put into those themes, right? So the most ideal way of doing responsive site is really dependent on what type of content you have in your sidebars for example, what type of content do you have everywhere, right? So we're sort of stuck with trying to do a sort of generic responsive layout that's based on regions and you know, I talked about how yesterday how you can if you're doing a custom theme for your own site it's possible to do basically field-based layouts which are much more interesting but can be really tailored to the specific needs of the site and the next step in my thinking is that I don't know how you could do field-based layouts when you don't know what kind of fields the particular site is going to have when you don't know the end use case, so I would love if everybody here who's interested in responsive design started thinking about that issue as well or maybe I'm just overthinking it Does anybody have any comments about this pattern or doing region-based responsive layouts? Sorry, what was that? It reacts to right to left in the traditional way that websites should do right to left in that the entire layout is flipped in addition to the language being right to left, the layout gets flipped right to left that's the way we wrote it the first dark already it has that built in was it about RTL? Well, actually in this first one this is the first sidebar the first sidebar would actually be over here and the second sidebar would be over here because as you're reading right to left and that's the second sidebar and then here the content would be over here the first sidebar would be here and the second sidebar would still be in the same place you're right so the blocks instead of being from left to right laid out in this three column grid would also be right to left so one, two, three, four, five, six yeah sorry I got the first part of it then I missed the second part the question was do we put the media queries bake them into the CSS or are they some otherwise exposed inside settings or well I guess it would have to be through settings because like omega and adaptive themes expose the actual breakpoints inside the settings correct? so there are two issues there should we have some sort of settings in Drupal 8 core for breakpoints and how's it best to do that Stark is designed to show off Drupal's default markup that's what it's basic purpose is the layout has always been just to show you an example basically of how you can lay out your site it wasn't really meant to be something that's super flexible or reusable you can reuse it you can modify it to do what you want but that isn't sort of the goal of having the layout for Stark so having settings for Stark for where the breakpoints are I don't think it's a particularly it's interesting the comment was could you do it in a way such that Stark's work can be sort of reused for Bartek I hadn't really given that much thought the themes are so so different that I'm not sure there's not really a whole lot of work in Stark so I think that the amount of CSS is in Bartek already you basically have to look start with that the way it is now and start with that code rather than try and reuse some of the stuff that's in Stark so in regards to the settings one of the problems from a front end performance issue is that if you have your media query inside the link tag or inside the media attribute of the at import that's a bad performance hit and the reason for that is because it breaks it conflicts with Drupal's CSS aggregation because it can only aggregate files that have the same media type so each media query that's in a media attribute means a separate aggregate file and a separate HTTP request so the way that we've handled it for Stark is that yes the media query is actually baked into the layout.css file because there's no performances so putting a setting in we would have to look at we would have to figure out a way to avoid that performance problem just a second let me recap first and then you can ask the question because this is for the video so I don't forget everything she said so pointed out that a lot of times looking at this region based layout if you put navigation in the second sidebar when you start getting to some of these other responsive designs where the navigation basically drops below everything else it can really sort of wreak havoc with the user experience and make it difficult for a user and some mobile sites have a button at the top that allow you to get to the navigation easily and now the question so the question is what solutions can we come up with in Drupal 8 I would love to have you to think about that and maybe help come up with some of the solutions one of the things that I've been thinking about a little bit is that we do have a skip to navigation button that's in all of our markup it's in the html.tpl file right now it's basically hidden unless it gets keyboard focus you could write some css so that it was exposed as a button to jump to the navigation for mobile sites I really like that solution because it's a sort of accessibility and mobile win at the same time so that would be one way that you could do it and as far as start goes the issue is when you add a menu to a region the markup that comes on html.tpl doesn't necessarily know what's the name of the menu and which menu is important so it doesn't know which block it should be jumping to so that's really tricky for a theme that's distributed and we don't know what blocks are going into the actual regions but yeah so the the question the comment was could you put the second sidebar instead of below it put it up at the top is that what you were saying there's some interesting things that you can do with responsive layouts that are not necessarily obvious if I would recommend actually I gave maybe talked about this for about 20 minutes of my session yesterday when the video comes out watch that it should help you sort of figure out or help to figure out sort of responsive layout things because these three elements the first sidebar second sidebar and content are next to each other in the source order there are some things you can do to push those around and make them appear to be out of order even though it has a certain order in the html I've talked about when you're creating basically rows inside your grid each group of elements that are in a single row should be next to each other in the source order and so since these are all three next to each other you can rearrange them within that row the thing that you can't do unless you like use some fancy it's very tricky to try and get CSS to almost disobey the html source order I think I've seen a couple of them using display table and display table header to try and move stuff above to the top which is a bit of a hack but I think the flexbox spec for CSS3 is really powerful and once that's fully supported then you can do some really powerful stuff with it yeah that's another option the more complicated issue we still don't know what blocks and what regions are most important for the particular user who's using the theme so we can't it's just too difficult to know it's possible if you wanted to have multiple layouts that the user could pick from if somebody wanted to work on that as an issue for a start so you could say I want to use this kind of responsive layout I would totally be up for that I would need to argue a little bit with a web chick I think but I'd be willing to argue with her in order to get that well the question was do I mean the mobile user when I talk about what's most important or the developer what things are most important that's an excellent reminder that you should always think about your users first it's what the users think what's most important that should be near the top in your source order those are the most important things that's why they came to your site but from a site builder standpoint the theme doesn't we're going to assume that the site builder knows to respect the users so as a sort of generic theme we have no way of knowing what blocks what important things get put into what places because we come with a default set of blocks like the main content and some menus and stuff like that but the site builder can move that stuff around and that doesn't necessarily it won't necessarily be where Drupal initially places it so that's the sort of crux of the matter yeah okay I misunderstood then okay yeah I did misunderstand so you're asking whether I meant for the settings of the layout settings whether it was per user or actually what I was referring to was per site builder I mean per site right so the site builder says oh I want to use this layout for the site rather than the default layout and that would be based on because the site builder knows where did I stick this stuff which layout, responsible layout sorry yes I know you guys have more comments tell me, tell us about some of the Drupal 7 stuff that you've done that you think is interesting or that you think is really painful or hard because knowing the things that are causing you pain is really helpful because then we can put some bandits on it or fix it or whatever I'll just throw up here one of the things that I find painful is the field TPL it would be really nice to have a much leaner markup coming out of Drupal because that's a front end performance problem too many markup means extra K of downloading so I think there's a lot of improvement that we can do on this if there are people who would like to work on this particular problem I would say take a look at the Fences module in Drupal 7 and see what that kind of does and you can certainly try to maybe make its solution better or work on your own solution and maybe we can sort of solve this sort of field markup problem in Drupal 8 I would love to see some solution for that in Drupal 8 technically that would be part of the HTML5 initiative but like I said we're not really worried about which issue goes in which initiative these are mobile issues and let's get them solved so let me do the question first the comment was in Drupal there's nested menus and how do you sort of best support a user interface inside mobile devices is that correct? yeah so what we've done for the admin interface is really common in mobile OSs to have nested navigation using either accordions that hide and show the sub items or actually having separate screens for each one those are some of the techniques they use to communicate the information yeah, yeah that's really common on iOS is a great example they use separate screens for each nested set of items are there people here UX people or just sort of usability people that want to talk about the admin interface and improving that you've got a prototype of what the Drupal 8 backend might look like why don't we show that right now so I can begin this with a quick story about a year ago when I was really young and naive I wasn't really into core development or anything like that and at the time the responsive web design was cool so I was like oh I know let's make the 7th thing responsive that'd be fun so when we got into it we actually realized that the admin interface in Drupal was really bad on mobile phones so instead of jumping into the issue queue we decided to take a step back and in DrupalCon London we did a 80 sprint where we got tons of devices together and we saw where the pain points were and we got a lot of bad stuff out of that and since then what we've been trying to do is instead of committing issues into core is design a prototype in static HTML of how it could work on small and touch screen devices and the benefits to that is that we don't have to write a lot of PHP to change the interface which is great because it's suck at PHP so it's really easy to contribute and it kind of avoids having bike share discussions on how we implement a certain feature we can just focus on how it works to the user and the other good thing about having a proper usable prototype is people can get it out on their phones and they can use it and they can touch it and swipe through it and see how it feels so this here is the third iteration of the prototype which focuses on navigating to the page you want to get to so the first thing you'll notice is that the toolbar doesn't really have any links in because we found that it just collapses down, gets really big and it takes up about half the page for mobile users so what we have in here is the title of the page you're on and we have a link that says administer when you click on that it takes you to the top of the administration menu so you see content appearance, people and when you click down through these you drill down through the interface so I thought that was a lot simpler and we made the each menu item really big and touchable because currently there was, I think there was maybe this one word here that you could click on to get down to the next layer so we made this whole area clickable and touch friendly and then from there to get back up you have to press the back button to get back up to the top so what we decided to do was instead of making users forcing them to click this one button down here we made the whole screen a target so if you want to get back up to this previous page you just pull and swipe which is a lot better because instead of tapping one button down here you've got the whole screen to touch and you can actually move a lot quicker than just tapping one button like that and the back button is a part of the device UI so it's inconsistent across device as well and placement and there was some discussion at first about having the back button in the top toolbar because they do that a lot on iOS but it kind of seemed like a waste of space because a lot of mobile browsers have these back buttons and you can also swipe forward as well to go back down from where you were so what we also did is instead of having all the oh, do you click on it yeah so it tells you what page you're on at the top of the toolbar, it has the title maybe it's not completely consistent but when you go down it tells you so the question was how do you know when you're on a particular page and you swipe forward how does it know how it's just going through the browser history to go forward when you're swiping like that it's literally the same as pressing the back button is that what you mean so you swipe back and then you swipe forward it's just using the browser history to go forward so you can't swipe forward you can't swipe forward into the future there's no way you want to go the question was can you get all the way back to the top of the administration if you're in a deep menu and somebody said to swipe very hard so no at the moment you would have to swipe six times but there are improvements to be made on this prototype and if you have any suggestions that's great you should come to the sprint on Friday for content creation I'm going to repeat the question so content creation is there going to be a special a special mobile setup versus the desktop so it's an interesting use case to think about maybe having a specific UI for certain roles but for this web interface we kind of have to think about every possible role because we can't assume what the user will want to do but in the future once we have this working really well maybe we can explore making native apps that have very specific use cases I know there's an iOS app at the moment called Drupad and that only gives you a handful of functions or features to use like content creation and you can exclude all the other ones because they don't have to be accessible for this one application so it's something I'm happy to discuss in the initiative but I think that the backend web interface has to do everything the goal is really to have everything be mobile friendly including the permissions page that's the goal it doesn't make sense to assume that the mobile user doesn't want to do everything so we don't want to limit it based on faulty assumptions anybody can look at this prototype what's the URL for that oh I should type it down so it's nav3.d8mux.org I'll see if I can pull up a how big can I make my text what is this can you increase the font on that at all oh it's pretty limited features isn't it there we go font size way bigger bigger bigger bigger plus eight more times so yeah you guys can try out this prototype you can go to it right now on your mobile device you can try it out but be warned that it could be buggy because it's not a faulty featured piece of code and some of my JavaScript does really suck so yeah the comment was that in Drupal it's really hard to administer large numbers of users on the user administration page because there's no easy way to search for a user by their username and I assume you want to know how we're fixing that for a Drupal ain't it yeah so one of the benefits of looking at the interface from a mobile perspective is it makes those problems so much more obvious you've got a large amount of users yeah so he was commenting that on a small site like a hundred users you can sort of manage it okay on a desktop by just going through a couple pages but with a thousand users it's almost impossible yeah it's tricky and I would say in a mobile device even a hundred users is difficult yes you might have noticed this search button on every page so what we also found is it does take a while to swipe around to get back up to the top to find the right menu item to get down to where you want to go so we actually implemented this global search function and you can type any page I said the beginning letters for any page in the admin interface if I type C it will show me every page I can get to in the admin interface so it's just like a global search in Drupal almost like you have spotlight in iOS or in OSX but what it also does is it doubles up as a local search so you can see here it shows you on the current page and it begins to see if we had thousands of users it would show you every user that began with C if you want to get more specific you can type in here you know C and until you find just that one user was it using some really badly hacked JavaScript that I wrote but ideally well it looks like it works really well but I'm sure it will break very easily if you try and do anything else with it sorry this is part of the static HTML and this is why it's great because I don't have to know how to do it properly to show this interface off to everyone but it's going to be part of our work in the issue queue to get this functionality into Drupal core yeah what was that oh user finder in Drupal 7 I don't know what happened there I'm not sure yeah and like I said earlier the goal is to have all the administrative interface converted to be mobile friendly the things that we're going to start with first are going to be content creation and content administration and when I say content what I'm specifically talking about from a sort of code code standpoint is entities so like nodes content types creating content but also users are also entities part of what I consider content administration and content creation because users are also entities so well well I mean yeah that's one of the things that Luis has been working on is the navigation of course is essential it's got to be actually first because you can't get to any of the content creation pages before you have navigation I disagree completely the question was you're not going to create content on your mobile device that's part of the assumptions that you use I would love to create draft posts when I'm on the bus oh drafts yeah that's content creation now I guess it's important to know that oh sorry so for the video listeners the comment and question was basically as we look at all of the administrative interfaces and mobile users what sort of how are we looking at the desktop picture and improving that as well at the same time do you want to yeah so like I said before one of the benefits of taking a view on the interface on mobile is it makes some problems that we have already in the desktop interface so much more obvious so optimistically I like to say we have 100% of rain on changing the desktop interface as well if it makes the mobile interface easier or who knows it might even make the desktop interface a lot better to use as well we had if you remember the D7UX project some of the community members that were working on that Bohan and Roy Shulton they are doing you know they're continuing with their work and improving the administrative interface and they have you know I'm not sure does it D8UX or something like that yeah D8UX but they're working closely with us because they recognize the implications of mobile for improving the desktop so like I said we're trying to make everything better these sort of different initiatives overlap a lot and basically we're all working together so exactly Roy was actually at the sprint that we had Sunday and Monday before the Drupalcon and helped out a lot and it was great so definitely the desktop experience is going to improve because we're taking mobile into consideration back here so the comment was that he likes to think of desktop as being a progressive enhancement of the base functionality yeah I completely agree I love to think of it as a larger screen as an additional capability like you would think of JavaScript as an additional capability so if we design for a small screen first then we'll be in a much better place so the question was a bit about the politics of getting particular changes into core and whether or not we can do it so the nice thing about these sort of official initiatives that are put together in the Drupal community is that basically there's no official initiatives that are created without Dries saying I want this right so the mobile initiative is because Dries says he wants Drupal to be mobile friendly and it's up to us to figure out what that means so we've got some heavyweights who are in favor of making Drupal 8 mobile friendly I think we have a pretty good shot at managing the desktop experience and the people that have traditionally been working on the desktop they're also on board like I said the D7 UX people they're doing D8 UX and they're loving improving the desktop from the mobile so I actually don't think there's going to be that hard from a political standpoint sort of fighting or issue queue back and forth I think the hard part is actually just doing the UX work finding the right people to start implementing the UX work as PHP and HTML and I would love to see everybody who has those skills to get involved again we have another sprint on Friday which is going to be in this room and I think I'm going to take one last question so the question was look that the D8 nav3.d8mux.org prototype look great on an iPhone and does it scale to an iPad I don't know have you tried it on an iPad find somebody who has an iPad and try it on there this is a prototype Al's working on it right now why don't you go look over there and again this is a prototype too we need a process of it going through it's really starting with a smaller screen experience and then once we have that down then let's start thinking about bigger screens bigger touch screens because iPad apps tend to have slightly different metaphors as well so even though it might translate okay it might not be ideal so I'm sure there's loads of work that we can do on the iPad experience or a tablet experience again this is progressive enhancement progressive enhancement we'll start with the smaller screens and look at the bigger screens as progressive enhancements of this base thank you very much I hope to see you guys on one more question and go ahead so the question is have we taken a look at what Joomla and WordPress have done I personally have not I've been looking at the sort of the web development community in general and not at what CMS in particular have been doing but that's a great suggestion personally I'm not going to have time but I would love to see somebody who is very familiar with WordPress who does WordPress and Drupal sites to give input about some of those stuff so I'd love to see that love to see that input so thank you very much there's a survey about what you thought about the talk but I don't really care if you trash us here or whatever but what I really want to see is a lot of you show up on Friday yeah if you guys could turn up to the sprint on Friday that would be great but Joomla has a few patches he has and if you see my PHP it's dangerous and it's important because you guys could all be working with that code when Drupal 8 comes out yeah thank you thank you