 I don't actually know any German except for the word Genusa, which means vegetable, I think. So I'm not going to be saying welcome in German. I'm John Albin Wilkins. I'm the Drupal 8 mobile initiative lead, which means that I do a lot less coding than I did during the Drupal 7 development cycle. I sort of look at the big picture, try to come up with plans with the community and get those vetted, trying to get all that stuff sort of planned out and sort of pushed and motivated people. That's my primary job. I'm not the guy who implements mobile stuff in Drupal 8. So I wanted to start back just from the actual sort of goals, listed goals of the mobile initiative and the work that we have to do still and talk about the big picture. Because I really feel like mobile is a really, really sensitive subject when it comes to Drupal. And the reason, of course, for this is disruptive technologies. There have been many disruptive technologies in our history. Printing press was a disruptive technology. The web, of course, was disruptive. It caused a lot of... The newspaper industry is completely foundering because it's not able to adapt to the web. Mobile is sort of the new disruptive technology. And it is already killing markets. There are a lot of phone manufacturers who are like, yeah, we're top of the world. And they didn't see this sort of smartphone emergence of having sort of basically mobile computers in your pocket instead of mobile phones. And it's causing all sorts of disruptions. And it's actually more of a sort of mass extinction. This thing has such potential to change the way that we live our lives that it can easily just squash Drupal like a bug and not even notice it. I mean, there's a real technology that if Drupal doesn't adapt to the ways that people are going to use mobile technologies, Drupal will just not make sense to use it. So that's why I think it's really, really important that we remind ourselves that how important this is and to actually start working and make sure that this work actually happens because it really, really matters. I've talked about this a few times before. I'm going to go over this real briefly. There's basically five ways to build a mobile solution that I've been able to figure out. You can have your sort of native apps, of course, which is code compiled to run natively on iPhones and androids. There are web applications, which are basically a website, and then just sort of you're browsing the website application in your mobile browser. Then there's this mobile desktop domain switching where when you're on a desktop browser, you see the desktop site and when you're on a mobile browser, it sort of redirects you automatically to a separate domain name that has the mobile site. Then, of course, there's this new responsive design which has a single HTML source and then just sort of adapts based using media queries to the different size viewports, different size screens. And then finally, there's REST. This is a term that Luke Rabluski, who is one of the keynote speakers at DrupalCon Denver, and by the way, his video is awesome from that keynote. If you haven't seen it, go see it. It talks about responsive design plus server-side components, and this is sort of basically sort of light client site, light device detection in order to tweak the markup before it gets sent to the end browser. And we don't have to have the ability to do all five of these things in DrupalCore. That doesn't make sense, but we need to make sure that DrupalCore allows us to do any of these five ways of creating a mobile solution because there's no one right way for any particular use case. It's going to be one of these, but we can't say that responsive design is the solution you should always use. It's just not that way. So, given that these are the things that we need to support in DrupalCore, what's actually going to make Drupal awesome for mobile? Drupal8, of course, the future freezes in December. The actual release tentatively is next August. That's actually quite a ways away because after August, there's this whole year of people sort of building up contrib and knowledge base and figuring out how to use Drupal8. So it's going to be almost two years from now before we're using Drupal8 all the time for building sites. That's a long ways off when you're talking about mobile solutions, right? Because people need them right now. So even before Drupal8 is released, how can we make Drupal awesome? And one of the goals that I set out right at the beginning of the initiative was that we should have basically a Drupal7 mobile guide, a documentation that exists on Drupal.org that talks about all of the different Drupal7 contrib things that make mobile solutions possible. And this, of course, gives us a sort of better time to market, if you will, like we can start showing people how awesome Drupal is right now. And it also helps us figure out how are people using Drupal right now and how can we leverage that to make what goes into Drupal8, right? And I'm happy with the whole bunch of help because all I did was like an outline and everybody filled it in. It's 100% done. It's on Drupal.org slash documentation.smobile. This is a resource available today. Of course, all the documentation on Drupal.org is organic. There's certainly lots of things that we haven't got because I'm trying to promote this so that more people can add their stuff, their solutions to this guide. So I encourage you to go look there, find out new things, and if you know some stuff, go and put it in there. This would be great. This would be a great resource for us. So that's one of the goals of the Drupal8 mobile initiative and I want to look at the rest of them. Excuse me. Too much yelling like a morning last night. So these are basically the five points that I think are important to be in Drupal8 core in order for us to have like sort of a moniker of like Drupal being really awesome for mobile, right? Web Services. Of course, Web Services is part of the whiskey initiative. How many people went to Larry's session this morning talking about it? So I was trying to do some slides so I didn't actually go to see it so you probably know more about that than I do. From what I understand though, it's basically, it's 0%. They haven't got to it. They've done a lot of the plumbing for basically all the necessary components are there to allow a contrib module to be really great for Web Services, but he doesn't have the resources. He doesn't have the people to actually go and do the work to actually get this to be 100% in core, which would be quite nice. So if that's something that you think is really important, I really encourage you to go talk to Larry because he really, he needs bodies, he needs people to work on the stuff, a lot of the underlying plumbing is done. You just need to actually just go and implement it. Responsive design. This is basically like 95% done right now. Stark has been converted. Bartek has been converted. There are a couple of fixed-width rules in 7 that I don't even know why they're in there and I think there's a patch there and they're just waiting for maybe a re-roll or a review or it's really close to being done. I think that if you are really into responsive design, go and check out Bartek. You might see some things that you would like to improve. I looked at the NIVL navigation. It works, but now there's some sort of newer navigation techniques and maybe you want to try out. I'm certainly willing to look at those kind of patches so if you want to improve that, go for it, right? These skills, of course, they're kind of all over the map. This is kind of a weird initiative in that it has all these different components that are disparate. They're not really similar to each other so we end up with a big, diverse skill set. So if this is your skill set, you know, there's still some stuff to do in there. Front-end performance, I would say this is about 10% done. There's a lot of different parts in this as well. We have JavaScript. Nod, is he in here? There he is. He gave a JavaScript talk earlier today? Yes? Yesterday. Where he talked about the goals that we've been discussing within the community to try and make JavaScript a better experience for all Drupal developers. And of course, improving how we use JavaScript is going to have a big impact on mobile experience because JavaScript runs kind of slowly on mobile devices. And if we can make that JavaScript a lot leaner, load only when it needs to be loaded, those are the things that we need to have help with and get that kind of stuff implemented. And then we also have CSS stuff. There's been a lot of work inside CSS stuff. Morton's done a bunch of stuff as far as cleaning it up, trying to make it more organized. And one of the things that I discovered just in the past two weeks is I started reading about SMACs. How many people here know about SMACs as scalable and modular architect for CSS? Just a couple of people. Snook, Jonathan Snook, or Snooka on like Twitter and whatever, he describes, hit SMACs.com. He describes a technique for both sort of organizing and categorizing your style sheets that it becomes much easier to figure out, okay, I'm adding this rule. How should it be organized with the other style sheets? I really, really like this method. I would like to build sort of consensus to see if this is something we want to use in core. I think it is, but I'm not the community, right? So I want to make sure that everybody is on the same page and that we start doing this because I really feel that it's good. The other half of SMACs is not just the organization, but the actual class name, how you name your classes. And you need to write that in sort of modular way. SMACs.com, if you don't know it, talks about this sort of naming convention for your class names. Those things two together make, basically give you a set of rules so you can use tools like CSS lint to look through Drupal Core's style sheets and try to correct them using the SMACs rules. I think it's a really good combo. And I would like to see people start jumping on that. One of the things that we want to do is make the JavaScript and CSS aggregation plug-able. The JavaScript people actually understand why this is more important than I do. But one of the things we started looking at is the aesthetic library. This is a symphony component. That is something that... I should have stopped. I should be discussing this with everybody rather than just sort of lecturing. Let me step back here just for a second. Rather than discussing aesthetic, let's talk about JavaScript. So what kind of things do you guys want to talk about as far as JavaScript? How many people went to Nod's session yesterday? Okay, excellent. So do you guys have questions, concerns? What do you want to understand better about JavaScript inside the mobile initiative? Sorry? Whether or not we're using jQuery itself. So right now in Drupal 7, jQuery loads basically no matter what. Even if you don't use it, which is kind of crazy. So has that patch been committed that at least removes the... Almost, right? Yeah, yeah, yeah, yeah, yeah. Okay, so we almost have the point where you can... We are switching all of core's usage of Drupal add.js to use Drupal add library. And that basically allows us to define the dependencies for JavaScript file. So you say, yes, I need jQuery, or yes, I need Drupal settings, whatever. And then those dependencies get loaded depending on... I think we should encourage that pattern in contrib, but Drupal add.js will not go away. If you use Drupal add.js, it will assume jQuery as a dependency. Yeah, that's what we discussed. Other questions about JavaScript? Try not. It's been really, really hard finding people who are passionate about JavaScript, but there's certainly a lot of opportunity to really shine in this area if you want to show off some JavaScript skills. So the question was ignoring JavaScript aggregation and... I forget the other one. But bandwidth. What are the major sort of pain points for JavaScript runtime? I'm not actually sure. Just jQuery in general. It's a large library for when you want to do one simple thing. Sometimes jQuery just is way too much code for the one simple thing. So there's some simplification that we can do in some of our core scripts that contrib can either, you know, leverage or they can continue using jQuery. Yeah. The sort of the... I mean, this is true of any computer language. The sort of closer you are to the actual sort of the bone, you know, the root source, the faster the stuff goes. So when you add abstraction layers, this has to be slower, right? So mobile performance is painful enough that if there are some sort of little tweaks that we can do where we'll have like a one-line jQuery script and change that to maybe three lines of really fast JavaScript, that can be a win for core. And maybe those patterns can be sort of proliferate into a good job that way. jQuery is great. I mean, especially when you're doing a lot of complicated stuff, jQuery can be really, really great. But not for absolutely everything. Yeah, we can talk about SMAC right now. The question was, was there free documentation for the SMACs? And I believe there are parts of the book that are available for free and then the parts of it that are sort of premium content. So I'm pretty sure that the base categories and stuff are free because that's how I initially read it and then I went and bought the book and the whole thing. But I think there's free stuff available on smacs.com to read. Sorry, jQuery... Oh, touching on... I'm repeating it for the video, I guess. Touching on jQuery bandwidth, is there any plans to use jQuery mobile? jQuery mobile is a library for those people who don't know it who allow you to sort of build interfaces using the jQuery mobile library for mobile devices. We don't really have a good use case for that in-core, so we don't have any plans to use it. It's, you know, contrived no problem. There should be no reason why we can't support that as a contrived option. But when we talk about mobile administration, if you're... Actually, I couldn't talk about that now, too. I'll go back to that. Mobile administration. So I would consider this about 10% done. Basically, we want to make sure... People are using their phones in all sorts of different ways, and if they want to tweak the administration of their site using their phone, I want to do that quite often, actually. Or maybe write a draft blog post while I'm standing in line. I want to do that. So having the ability to use most of the administrative functionality of Drupal in a mobile device, I think it would be really, really useful and really essential, really, to... Just, like, the sort of first appearances, right? When you first install Drupal and just sort of look at Drupal and go, does this work on my phone? And then you pull it up and you're like, wow, okay, yeah, okay. Drupal, the administration for work on my iPhone, this is great. So, like, it's a very good first impression, but it's also extremely useful. Too far. And then I lost the thread. What was the question? No, jQuery mobile. So mobile administration, the way that we're going to do this is by making the forms sort of be responsive. 7 is already a fluid layout, so there's, like I said, there's a couple of rules that for some reason have fixed with them, but, you know, we fix that. Make the sort of forms be responsive. It will sort of... You'll be able to administrate it on all sorts of different size screens because we're, like, you know, with 7, we're kind of already halfway there because the theme already supports fluid. It's just that there's some forms like... I love vertical tabs on the desktop. Vertical tabs don't work at all on a mobile device because all you see are the tabs and then you have to scroll over to see the rest of the stuff. So there are some different sort of form widgets that we use and patterns that we use in Drupal 8 administrative screens and we just need to tweak those so that they, you know, they're vertical tabs for large screens and they are some sort of different interface for smaller screens. I really need to not press a button five times. More questions about smacks or JavaScript or aesthetic? So... There's supposed to be a button right there under funding performance. Yes, responsive images. Yeah. I would consider that... I would kind of consider that a front-end performance. It's certainly related to responsive design, but the reason why it's a front-end performance concern, of course, is because the default is to have a giant image and scale it down to a little db screen. This is a horrible performance and it's definitely in this sort of square, you know, it's definitely under this sort of front-end performance. I can't believe I forgot to pull it. Damn it. What was that? Well, yes, so there isn't really... There's no standard. There's no standard for responsive images. There's literally no HTML5 spec for responsive images. You can't... And it turns out that this is a really hard problem. I've been working with the sort of greater web community in talking about this and sort of hashing it out and we basically discovered that there's no JavaScript way to fix this problem. And the reason for this, it's not necessarily intuitive because it's a total browser internal thing. They do this thing called pre-fetching of images where before they build up the DOM, they're like, I'm going to look through this HTML source really fast and find the image tags and then, oh, I'll start downloading those immediately. So it starts downloading the images before it even starts building up the DOM. This is the sort of pre-parcer that fetches stuff. And that means that there literally is no way that JavaScript can run first before that. The only way you could do it is by removing the image tag from the source. But, of course, now you have a problem because there are some noble devices that don't have JavaScript. There are some users who turn off JavaScript and you've lost all of your images. That's not an acceptable solution, right? So we have to have, like, basically a... The only way to, like, halfway do it right now is to use a JavaScript solution paired with a sort of default image, which is the mobile size. So it's a small size that's actually in the HTML source. And then, basically, you use JavaScript to determine what the viewport width is and then load up those larger images for the larger screen size. Yes, that's a double image load for larger image sizes. That's a problem, but that's the only way to do it right now, which totally sucks, which means that we definitely need to have an actual, like, new technology in HTML that allows us to do this because the browsers do know how big the viewport is before it starts prefetching. So we're working with the spec builders to write a spec so that the browsers can look at the viewport size real fast before it does a prefetching. And then when it finds that image tag, or whatever is the new, like, picture element, right, it finds that, and then it knows, based on the viewport, which actual source of the ones that are available to download. So that's the only way that it will actually be fixed is with a new sort of element or new attribute on the image tag and working through that stuff. And just last week, we talked with Matt Wilto, who's been writing the actual sort of draft spec for this, and Jesse Beach started up a Google Hangout where we talked about these issues and how Drupal can actually sort of implement a JavaScript polyfill that's sort of forward-looking. Basically, we would try to create the markup that we think is going to be used inside Drupal Core. And this is a rough idea. We need input. We would implement the markup that we think is going to become the spec. We would implement a JavaScript solution that would do what exactly what I just talked about. That is a sort of polyfill for all the browsers that don't have the native solution, which is every browser right now. But when we get to that spot where browsers know about they have actual native implementations, like IE or Chrome or whatever, implements this, then our JavaScript solution goes, oh, it's already taken care of. I'm not going to do anything. So we wanted to be sort of forward-compatible. And I think Matt Wilto was really interested in Drupal actually sort of testing out and seeing how this actually works in today's web technologies right now. He's very interested in the work that we're doing. So... Yeah. There's no HTML5 actual spec for this. And that's what we're trying to work on. And if you're really interested in that, on Friday, all the initiatives are having code sprints that says on the schedule where that room is going to be. I encourage you to come and discuss stuff. And of course, we're going to have issues. There's an issue already in the issue queue if you're not going to be here on Friday. And I have a regular mobile initiative... Sorry. I have regular mobile initiative meetings online. We've been starting doing Google Hangouts. So that's how you can continue to be involved with stuff. Yeah, go ahead. Right. The... The actual sort of... Right now it's a picture element that's being proposed as a solution along with a source set attribute because there are a lot of sort of... There are a lot of people who want responsive images, but they want them in slightly different ways. Like some people just want to support retina displays, right? And some people just want to have the ability sort of editorially to decide that for small screens we're going to show like somebody's headshot, right? And then on larger screens we'll show them in the context of like the hall where they're speaking, right? So editorial control over the different croppings, right? Because of those different interests, it's a complicated sort of solution and picture is the sort of element with source set attribute. It's just similar to the video tag. That's sort of the current spec. And the filament group which Matt Wilto works for, I believe, they have a polyfill, a JavaScript polyfill called picture fill. Is that right? Picture fill. That's actually the JavaScript library that we're looking at right now in Drupal A core. As far as... Right, so the note was basically that there's some quote-unquote interesting UX work going on in the issue queue right now talking about how you configure breakpoints and actually configure the style sheets. We're definitely at a sort of beginning to hash things out phase right now. We actually had a follow-up conversation to that last initial issue queue posting on Monday, I believe it was. We had Annex, we had Alex Bronstein who had Nod there and Moesh and Jesse Beach and I think a few other people and we just started talking about the UX and that conversation is definitely going to continue on Friday or anytime you want to just come and find me during the conference I'll be happy to continue that conversation because there is a lot of UX work to make it as simple as possible because there are a lot of moving parts because if you have a layout you basically have a series of breakpoints for that layout but you can also have multiple layouts on your site like one for each node type so then there's a different series of breakpoints for those different layouts so it can get a little mind-bending really quickly so we definitely want to have the UX as simple as possible so people can understand it, hopefully. Okay, so what you're talking about is like moving an element to a different part of the page for different breakpoints or... Yeah, yeah. Right, but those are different configurations because you're talking about how you're configuring the one image as a field on the node page and the other you're talking about in the view that's a block, right? It's a different configuration so we don't need to... the interface is basically to naturally take care of that. Any other questions about front-end performance which is these three things plus responsive images which I'm going to dumbass for not putting on there? More questions? Okay, so let's move on to HTML5 form elements this is basically 80% done Jason has had to step down from being the HTML5 initiative lead she... basically just... she wants to work on other stuff and the HTML5 initiative is a lot of work it was a lot of work for her so they got a ton of stuff done but one of the things that's not quite done is the HTML5 form elements I believe that we actually have like in form API we have all the HTML5 elements already the issue is that we don't have those same form elements as widgets for fields, right? and that is kind of a big problem for mobile because if we can't create a... like an email field widget for this text field then the user is not going to get the special email keyboard because it's not using the email input element, right? Is it type email, isn't it? What it is? Yeah, type equals email, right? So those things would be like kind of jarring for the user experience because they're expecting the HTML sort of flashiness and it's just not in Drupal 8 yet so we need some people to help out with that we have some patches for some of this stuff and the stuff that doesn't have patches can basically look at the other issues and sort of replicate that same pattern Dave's worked on a bunch of that stuff and I talked to him on Monday and sort of like, hey, can you do this? So thanks Dave but we need more people to work on stuff it's not just Dave because he's going to do it he's implemented the pattern and now you have to go and replicate the pattern please Are there questions about sort of the HTML5 initiative in general or form elements is specific? Yeah So the question is does anybody get to take over the HTML5 initiative or is it, quote, just finished? And it is the way that Jason set up the scope and the goals of the HTML5 initiative, it's really close to being done, right? So it doesn't make a whole lot of sense for us at this point to, in my opinion and obviously I don't have the hair, I'm not Dries but it's a little bit too late too close to the end goal here to have a new initiative lead and try to look at the whole thing again and maybe figure out some new goals because there's a lot of HTML5 technologies and there's certainly the opportunity to look at all of the HTML5 and go, hey, we need that for Core 2 we've got a lot of other initiatives that need help already so like starting up a basically sort of revived HTML initiative part two we have a resourcing issue already so we don't want to drain some of those resources by starting off that new stuff but we do need people to finish off what's already in the HTML5 initiative I'm actually going to be leading the HTML5 initiative Sprint on Friday as well as the mobile initiative Sprint and I'm just doing that because I know that there's people who are working on the HTML5 initiative that we're just kind of waiting for Jason to hold another meeting and I really think that you can sort of self self organize and finish up this stuff and I'm just going to get the ball rolling and maybe I'll even have an HTML5 initiative meeting here in the next couple of weeks and again looking for sort of self organizers to keep that moving just want to follow up on that so the one thing I would say is there's a lot of things that are sort of part of a larger HTML5 umbrella that aren't in core and the assumption is that they could probably live okay and can trip like we don't have audio and video tags in core or fields we don't have geolocation stuff we don't have stuff having to do web sockets so there's definitely a lot of things that sort of fall under the HTML5 umbrella that we're just assuming can be contrib solutions but if anyone here knows HTML5 really well and looks digs into what actually is in core and sees like oh my god we are actually missing something that really does need to be in core and that can't work well as contrib speak up about that because in the absence of having Jason monitoring that we need that information yeah that's true Dribble H should be able to support anything that's in HTML5 and if we're missing some of the plumbing that allows that full range of capabilities we need to know that now and we need to get it into core so if you are playing around with that stuff and you know how the pain points are in Dribble 7 get into the issue queue find people come talk to me we need to know any other questions about HTML5 mobile administration I talked about this briefly when we were talking about jQuery mobile but one of the besides making all the administrative forms be responsive one of the interesting things that has come out here in the last two weeks is of course the spark responsive layout builder this is a very slick layout builder Chris Vanderwater and I have been talking for months about the blocks and layouts initiative where we were talking conceptually about that initiative is going to have a layout builder and I'm like I would love it to be responsive when you get to that spot in your initiative I'm going to help out coding that stuff because I think it's really important and really interesting and this is one of the sort of the cross poll nation between the initiatives things that happens because a lot of these initiatives are very closely related Whiskey has web services for example so we've been talking about that for months and then the AQUI team did this spark demo in D7 how many people here haven't seen the demo yet there's very few people that's great actually that means a lot of people saw it there was what's the most recent like blog post and video that you can find for the demo is it on Dresa's site or yeah go to the AQUIABOOTH you're here go to the AQUIABOOTH have them demo it for you so oh that's true yeah so there was a demo of it yesterday so that video is actually already online so right before you go and drink tonight go watch the video it's really cool I think it's it looks at sort of the current way that we build responsive designs and the DOM order that you sort of have to have in order to do different layouts techniques and really brings all those sort of concepts together in an interface that is really slick they are not the people who are going to do this for jubilee they are certainly going to do a bunch of it but they're looking for community support community help to actually implement it basically take the pieces that are there and move into jubilee core finish it up I'm going to quote Gabor here if he doesn't mind he basically told me the interface is really slick and the markup and the CSS that it generates because it's a rough demo are complete crap I'm actually paraphrasing but there's I've looked at the way they sort of architected and I understand that there's basically a spot where after you've done sort of the UI stuff they generate the CSS and they generate the HTML and there's a big opportunity for somebody to come in and say I want to make that lean and look awesome and be really slick and you can come in and do that work and so that is a good opportunity and of course there are lots of other places that's the one that sort of jumps out of me the generating HTML and CSS that's kind of stuff I like but maybe you would look more interested in some of the other bits of Spark inside the layout builder or the other parts of Spark that aren't the responsive layout builder um the questions about mobile administration are responsible layout builder right now yeah do I have any thoughts about what? oh the aloha editor in mobile uh not yet I don't have any thoughts about aloha yet I saw the demo yesterday and I thought my wonderful it works in a mobile editor and then like which is I forgot to ask the question because we were talking about all sorts of different really cool things and accessibility and stuff like that so um do people know like does aloha work in mobile devices? so wim lears here is one of the people working on this part and the aloha editor says that and I'm repeating for the video that it works okayish there's a blog post on dresa's website about this as well other questions about the the mobile administration there's a lot of sort of patterns in our forms interfaces that we use that I think need some some sort of UX love as far as making it a mobile pattern and desktop patterns sort of responsive experience um from the back sorry? right so louis neiman did a lot of iterations of the mobile administrative interface specifically the navigation and he did a lot of that the iterative design work and there weren't a whole lot of people jumping in oh I want to implement this and then spark came along and they've taken some of those ideas and come up with a dashboard and they've identified administrative interfaces for navigation which I think build really nicely on what louis was working on and makes it even better so I would like to see people make the spark mobile administration be even better and then use that for dupal core and I know that the spark team would also like that as well so yeah again if you haven't seen that's part of the spark demo and go and take a look in the back so ask this sort of maybe unrelated question about how do I see the future of jQuery UI in core um to be honest I'm not really sure um I don't actually know the answer then I mean there's a lot of moving parts of the mobile initiative and I try to know a lot about all the different parts but that's one of them that I don't know as much about so I try to find people to help me out and answer those questions for me anybody have an answer or their opinion not like the answer but a opinion about it yeah it sounds like we're starting to use UI in core in some of the things oh yeah this spark team was using UI for parts of it weren't they jQuery UI so alohaider uses jQuery UI so I guess oh yeah so the question was are we planning on supporting every single administrator stream in mobile because we're getting views in core um and and I that is a fantastic question and I would love to see 100% coverage really and there are some things that you just can't do on a mobile device like literally the form which don't work on mobile device like I can't upload an image it's just not possible okay so right in a month you'll be able to do it there are limitations inherent to mobile devices that don't allow me to do everything that you can on a desktop device but I would like to see everything that is potentially possible to be able to be done in a mobile device but the reality is that with a sort of small form factor people are sort of naturally not going to do those things very often like configuring panels in a mobile device not such a good idea I would think um yeah so but the the screens that I would like to start working on first are content administration when I might say content administration I mean content creation not only just nodes but like taxonomy or users you know, administrating those nodes and introducing users um I would about to say things that are entities but entities are starting to go all over the place where I'm not sure it makes sense to administer those things um blocks will be entities now content creation like users and nodes in particular I would like to see those things worked on first uh any other questions about anything else or like maybe gaps too big data tables in the administrative area yeah that's actually one of the patches that motion Jesse Beach worked on on Monday and I think they hadn't quite finished it so it didn't get submitted yet uh hopefully that latest patch will come up on Friday and we were working on uh using a one of the ideas from filament group as far as like as you become smaller screen you can easily hide the less important uh columns so that when you're on a smaller screen you see the important ones the essential ones and as you get bigger than the slightly more useful ones and then just like everything when you get to a wider screen and there'll be a sort of link above the table that says just show me anything everything anyway and it'll just it'll go off the edge of your mobile screen but you can scroll over and see it then well yeah I mean these uh are part of the interface for theme table I believe so basically any time you use theme table that would be an option that you could do use so we would just need to the patch I think converts I don't know if it converts all of the uses of theme table but it definitely updates theme table and at least one sort of uses as a like here's an example I haven't like I said I haven't seen the patch because I haven't submitted it on Friday so we'll find out yeah we're working on that other questions so one of the easiest ways to get involved of course is since you're here come talk to me anytime you see me I want to talk about this stuff I want to find out what your experience is I want to corral you into actually doing some work um but if you're and then of course on Friday we're having a mobile initiative sprints everybody is welcome and then after the conference this is basically the best resource we're finding out about the mobile initiative groups.drupal.org slash Drupal slash 8 and if you get out of your picture here if you go to there you're going to see this which is the interesting bit here is the issues to work on I've sort of broken out all of those different components into like because you don't want to see like all of mobile initiatives initiative or issues right this is just going to be like a fire hose so I've broken it down by sort of component and you can sort of click down into the things that you're interested in and see just those issues we have a list of issues novices can tackle these are not like people that don't know anything about web development but like people who worked dabbled in mobile and feel comfortable in different aspects of it and you know they're basically new to Drupal core work right these are some great issues I think actually we've got patches and somebody was reviewing those patches on Monday and then of course we have JavaScript, Stark is complete Bartik and Seven there's a couple little issues old administration this is a great place go there find something you're interested in and start working on it so last chance anybody