 to some sufficient degree. And the number three item is now sort of moving up to the number one slot. So that's something that we need to address in Drupal 8. So taking over the list of things that actually were addressed, I think we made pretty significant progress on most of these. Maybe some of them were not necessarily progress, but there was at least some sideways movement of some kind, some effort to expend in all of these. Except for a basic views-like module, which wasn't even in the top 10 of the most recent survey, and a WCWIG editor, which we had some really early, early patches into Drupal 7 to sort of get a better API underlaying for WCWIG. But as for an end user experience, there's absolutely no evidence that we did anything whatsoever to improve a WCWIG experience in Drupal 7. So in Drupal 8, we're now calling these sort of initiatives instead of killer features. But ordered by percentage, once again, here's our new list. And WCWIG sort of, interestingly, has moved down the list quite a bit. Media and asset handling is still really high. HTML5 and CSS3, something that we weren't really thinking about four years ago, wasn't even in the list. So usability is of use. Mobile support, again, something that's indicative of the changes over the past four years. Better APIs always in there. And then some new items down here, configuration management, content, import, export, content staging. So nonetheless, WCWIG is still a really important thing that we need to be handling and figuring out a solution to. So I think it's good when I talk about WCWIG to kind of outline what I expect from more WCWIG. And this is what I think most people expect as the bare minimum of what a WCWIG should accomplish. The first thing that it should probably do, a WCWIG should provide a visual representation of output, actual output while entering content, which is not something we have right now. Even with CK Editor and TinyMCE and the WCWIG projects out there, using those, you don't get a visual representation of the output. You get a pretty close approximation of what bold and italics look like. But not of what your images or your videos or whatever are going to actually look like. The second thing is that this WCWIG or Rich Tech's editor should have a toolbar to do the basic operations, bold, italicize, add lists. That's not exactly a brainbuster either. During the usability study, which unfortunately is happening right now over in the main building, they're talking about the usability study. So I recommend watching the video of that tomorrow, hopefully. They had users try to put formatting, like a bold tag, into an editor. And when a user goes to create a new article, they're like, where's the toolbar? How do I add a bold tag? Not while there was one person, one person that knew HTML in the usability study that tried to bold the text by using a B tag. She was like, B tag, bold, and then hit Save and didn't work. And she was like, huh, well, that's odd. I thought that would work. So she goes back and she edits it again. And then she sees the input formats down below. And you think that maybe she would be like, oh, strong tag, right? Nope, full HTML, save. There we go, that worked, right? So not everybody, like a less experienced or powerful user, probably wouldn't have even had the option to switch to full HTML. But anyway, users expect a toolbar to assist them. And when they don't have one, they're just absolutely stumped. It doesn't occur to a lot of people to enter code of any kind these days. It's just there should be a toolbar for doing those things. And thirdly, and this is, I'm saying the basics, you should be able to insert an image with a caption and then float the image and the caption to the left or to the right of the content. And maybe that sounds like it's a specialized use case, but everybody wants that. And it's one of those things that Drupal up until, well, Drupal even now just absolutely falls on its face when it comes to aligning an image with a caption underneath it altogether all at once. You always have to have a div that the div itself is what's getting floated left and right. And the caption is inside of that. So accomplishing that is something that is still, to this day, almost impossible to accomplish in Drupal that just isn't done. Oh, fantastic. Inline image caption module, okay. But functionality that I think we can agree upon, that that should be, yeah, so it probably took you three plus probably around the edge of like four, five, six modules to get that happening, right? And I don't think that should be the case. So we're gonna do a short demo here of what I think that we should essentially do. And during my talk or my description, I think I noted that we're not going to be doing much of a Drupal demo here. What we're going to be doing is looking at WordPress. Which seems like, oh, blasphemy. But honestly, they've solved this problem and we haven't. And I think that we could imitate a lot from them. And basically the task set before us is so ridiculously simple that all we have to do is get to where they are. Which seems like that, seems like it should be a reasonable goal to imitate. So in WordPress here, I'm gonna go to the admin section. Maybe, okay, there we go. And then I'm going to go and create a new post. And I'm sorry for all the people that are familiar with WordPress in the room that you're gonna have to bear with just this simple functionality here. So I'm gonna add a couple lines of text. Insert an image. That is awesome. Okay, so I'm having trouble. So fortunately they have this nice thing where it's like if flash is just being a bummer then you can switch to a non-flash uploader. So pictures. Okay, and upload that. Okay, great. So I've got an image here and right off the bat you can see after uploading an image I get the convenient options of saying adding a caption. So I can insert, I can create a caption and then I can write off the bat, even say which alignment I would like it to be, the size of it and say insert into post. And there we go. You can see my picture inserted into the post. And if I at some point changed my mind about what the caption is here currently says my profile picture, I can change that to be something else that has been edited. And you can once again do a wissy wig-like operation here where it's intuitive to basically make changes from one thing to the other. I can click on the image and I can left align it, line it instead of right. And you can see the caption goes with it. All of this stuff is really pretty simple. And then actually publish this post and on output we'll get something really, really close to what we were seeing in the wissy wig. So there we go. So float it to the left, the caption goes with it. And that's it. And I don't think that that's asking for a whole lot. So let's talk about what it is that WordPress has done here and what it is that we can imitate from them. Yes? Yeah, so it's not quite wissy wig you're saying because the text color changed and it doesn't have the black background or? Yeah, yeah. So you're right. So the question is, or the statement was basically it's still not quite wissy wig. Maybe it's just closer than we have and maybe that's what I'm after. And that the wissy wig itself still isn't, it's not like inline editing and it's not like giving you the actual theme style text and coloring and things like that. It's still quite separated. Yeah, another question? Have you, yeah, so how is this better than Drupal? In Drupal, have you ever managed a caption that was underneath the image that you could float left and right at the same time? Like this caption, the fact that there was a caption right here and I floated it left with the image is actually a bit of an accomplishment. If you try to put a caption under an image with a wissy wig, you have to manually, as far as if you're doing this, okay. Yeah, yeah, that lets you insert an image, but not a caption. Yeah, this is all without anything. You've just installed WordPress and this is what you have. So there's also, how is this different from Drupal? Well, I didn't have to do anything to get this functionality. This is what I get by default and that's what we're trying to accomplish is actually including some kind of wissy wig actually in core. So that's a big difference in that right now, for Drupal you need to manually download TinyMCE or CK Editor, install a wissy wig module and then configure it with your input formats. There's an awful lot of setup there that we can skip also. There's another question over here too, no? Okay, so yeah, so let's look a little bit about what is going on here. If I edit this post and then actually look at the source code of what's happening here, this caption business with it floating left and right is really a challenging thing to do because if you look at what's happening here, I click on the image. So the image currently is selected and then when I hit align to the right, it's not the image that was aligned right. It was the wrapper around the image that was actually aligned right. So the div around it and the caption below it that was aligned right. So what I clicked on and what it was actually aligned were actually different, but that's the expectation that if you write a line something like the image, it would write a line, the caption that goes along with it also. So if we look at how this is actually accomplished in WordPress, it's actually a little bit surprising, I think, where that caption itself is not a div at all. It's square brackets or what Drupal, we would call tokens, right? So it says, let me zoom in a little bit here for everybody. Ah, shoot, so what we're working with here is it has an open square bracket caption, ID equals the attachment like ID, the width, the alignment, align equals align right, and then the caption actually in it. And then inside of here we actually have HTML that represents the link to the image and the image itself. And when you left and right align things, what it's actually doing is it's just updating this meta code here, this caption or token, if you will, to actually do the alignment left and right. So what WordPress essentially has here that we do not is they have filtering done on input versus just on output. So in WordPress, when you insert a video or an image or really anything other than text, it uses these meta tags or tokens to sort of handle anything that's complex. And if it's something like a YouTube video, you don't actually get the YouTube video in line, you get like a little placeholder thing that has like a YouTube icon there. So once again, not quite wissy-wig, but still better than Drupal, which is if you have a token of some kind that's doing like the inline module, does the same sort of thing where it has square brackets. When you're using the wissy-wig with inline module, what you get in the wissy-wig is actually just the square brackets, literally, like no replacement whatsoever. And so what we have here is we have essentially some input filtering in addition to the output filtering. So everything essentially has been written twice if you think about it, like all filters have something that is done both on input and output. Do we have any other questions so far? Yeah. I think that's the whole page. This is the whole going to another screen and seeing everything sort of in the admin interface is something that we just have to almost throw out and have this idea of doing everything in the pages. That's not even going about completely the wrong way. We should be giving them exactly what they want on the screen. YouTube videos shouldn't be a, hey, picture saying this is a YouTube video. It should be the actual video. Web fonts, if there was a great talk on web fonts yesterday, they should be rendered directly in the page. We should see the exact thing that we're getting, not just in the admin interface. So the general diatribe was basically that Drupal and even having a separate editing interface, so even imitating WordPress at all is totally the wrong approach that it should all be inline editing, just literally looking at the front end of your site, clicking edit, and then it becomes editable. Imitating Firebug, okay. So I can't disagree that that would be amazing, but the technical challenges around it are insurmountable, literally, to do it in a generic fashion. Everyone's like, whoa, whoa, whoa. What about editables, and what about HTML5, and what about all this new technology stuff that we have? And it's like, well, can you put that into a system like Drupal and have it actually be distributable? I mean, is that a generic enough solution that it's going to work for everybody that uses Drupal? I mean, yeah, just doing something that uses anything like that advanced like an editable is not something that's feasible in the internet right now as a solution that we've actually got to be distributable. So let's, okay, let's go through them. Over here, which product? MySource Matrix. MySource Matrix, is that a product, or is it like, is it a service as a software or an open source counter management system? And it's called MySource Matrix. Okay, just as a suggestion, I haven't looked at it so I can't comment on it really. And let's go to the back, not Larry. We'll get to you next. So I'll reiterate for the recording. There was basically a comment about saying, yes, it's great that we're comparing to WordPress. And actually the follow up of that, I think is that as far as I know, WordPress doesn't have a fantastic way for linking between pages, but I could be totally wrong about that because I haven't actually looked too much into it. So you hit link and you get URL. Or link to existing content, here we go. And so we have a search here that lets us link to an existing piece of content. That's pretty awesome. So, I'm just saying, well, I mean, Drupal is so far behind because for WordPress, this is where editors live. They live in this editor in the wussy wig. And for Drupal, we just haven't really, what we do is we make more and more fields, right? We make a different field for everything and that solves our problems. So, let's go Larry first and then up here. Okay, go ahead, continuation on this. Okay, TinyMCE node picker, something to do the same thing in Drupal with TinyMCE module, or with wussy wig module probably. Yeah, wussy wig module plus TinyMCE. Image caption. And does the image caption project work with wussy wigs of any kind? So yes, it does work with, does it work specifically with TinyMCE or CK Editor, or, okay, it doesn't matter. Okay, it takes the title attribute and uses it as the caption. So basically, it's, yeah, yeah, clever. So Larry in the back, the raw source again. Yeah, yeah, because there's, yeah, so Larry's basically saying that using inline editing or using a wussy wig like this and inserting an image directly into a post often is not the desirable situation, which I could not agree more with. Say like if you're writing an article for some major newspaper, which there are plenty of newspapers, major newspapers using Drupal, you might not ever be allowed to use an inline image. You need to put that into a separate field or something like that. And the image itself and the caption and all that stuff is then aggregated into some kind of slideshow or something like that and then laid out by the editors actually on the output. And I totally agree. WordPress's general approach here, I'm basically saying these are great features that we can implement, but I'm definitely not saying that we need to lock people into the WordPress model of thinking. Definitely not at all. Like if you wanna disable the image button entirely and set up your filter in Drupal lingo to not allow the image tag, all of that. Definitely we're not throwing away flexibility or we're adding functionality that just gets people the basic functionality that they want. Over here? Yeah, so is there a question to be answered there? Was that a general statement? Okay, gotcha. So basically there's a common situation where you need to attach additional metadata to an individual image or video or whatever it is and the solution for that now in Drupal is you make that image a node or you make that video a node and then you attach all the assets and like the copyright and maybe the date it was taken and the license on it and all that stuff. You might include all that stuff on the asset itself and then use node reference. Sorry, the names of these modules are just giant strings of abstract nouns. Node reference URL picker, what was it called? Node picker, okay, well that's quite more simple than I was making it. So node picker module to actually insert that into a wissy wig and it's like a node reference in the wissy wig that actually displays the image. And how would we solve that in Drupal? Well in Drupal 7 we have entities. So essentially you can add fields to anything now out of the box, that's users, terms, comments and nodes. So you can add fields to all of those as if there were nodes in Drupal 6. So essentially all the flexibility CCK on any arbitrary object. And so in Drupal 7 there's a lot of work on the media module that is finally broken out the media entity, they've called it now the file entity which is a really positive development in that project. Because what essentially it makes is that every single asset itself doesn't need to be a node anymore, it can just be a file and you can attach as many fields as you want to it. And then all of the information is not associated with the node, it's actually associated with the file directly. So the file has an ID and all of that metadata is associated directly with the file. And WordPress actually does do that same sort of thing where all of this metadata that I've entered down here, well actually this isn't true, this is now the instance. But when I was looking at it in the media picker, so if I say from the gallery, oh boy, okay here we go. So when I'm actually looking at thing here this is actually metadata that is actually on this file directly and every time I use this it will actually, it'll save the same information. So the caption, the description and things like that. So this is actually metadata actually potentially on the file itself. So I think that in moving forward using a file entity like media module is sort of pioneering right now, a file entity in Drupal 8 I think is a necessity. And if we make that happen then we'll be able to do all kinds of great sort of attachments and metadata onto images themselves. Deciphered is in the room and I'm gonna raise your hand. Basically Deciphered's big thing is trying to figure out what this dialogue looks like when you click image, how to handle a file that needs to be done there. And I know the media project also has been working a lot on that but this is another, that approach is something else that we're basically going to try to figure out this system after we get sort of the initial, just get a wissy wig in core. So for right now the target is the first two, a visual representation, get an input filtering system in addition to the output filtering system, get the tool bar set up and then we're going to figure out sort of what the image browser looks like. And my plan doesn't yet extend that far but fortunately the media project and Stuart with the wissy wig fields is working on that project sort of in parallel. So I'm sure that both of those projects work will eventually find their way into whatever solution we end up doing for Drupal 8. And they're compatible so you can actually use wissy wig fields with the media module in tandem which is awesome. There was another question up here I thought. Yeah. Okay yeah, do you think that the input should be in the same structure as the output? So basically something like markdown should we be using markdown instead? And my general feeling is that I think HTML should be the primary storage mechanism just because it's the closest to the output system and it's what works best and most natively with wissy wig editors today. And so using HTML saves you a whole heck of a lot of trouble because browsers render it directly and wissy wigs have been built essentially to produce HTML. And every time you deviate from that and do something else like markdown or BB code you're making work for yourself to actually implement that translation in JavaScript from BB code or markdown to the HTML content that is rendered by the browser. So I feel like HTML is the safest format but with wissy wigs there's a limitation to how far you can take that. And I think that basically augmented HTML stuff like this inline token handling. I think that if we're going to get this functionality we need to be able to embrace that we can't just use straight HTML anymore. It needs to be something a little bit more powerful. Yeah. Do other devices or what about through applications or via services? Gotcha. So when it comes to a wissy wig editors and bloggers specifically, which is why WordPress has got such a heavy wissy wig like interface because it's made for blogging. How do you handle situations where you're feeding this information out to multiple devices if you're using a wissy wig? And there are probably two approaches to that. One is that you implement heavier filtering on the output that you basically do parsing in regular expressions on the output to find things like images and then present them in different manners to different devices. Or as John Albin would recommend, like scaling down and delivering different versions of the same image based on the browser size, not actually device targeting at all, but just by window size. Or the other alternative is that the amount of wissy wig capability that you have is restricted essentially to bulleted lists. Like strong tags and italics, maybe alignment. And that's all of the functionality you get in the wissy wig and then everything else is separate field so you can pull that information out and deliver it in different manners. So there definitely is not, this wissy wig approach is really difficult when you're dealing with multiple devices because now it's definitely not wissy wig exactly on output because you're gonna have to see it in six different formats which are all different. Of course you can't have the editing interface be exactly what that system is unless you have six different wissy wigs, one for each different format, but I don't think anybody's gonna want that approach. A theme switcher, yeah, oh, yeah, let's not get into that. Another question. Hey, Joyce. I'm glad you asked because basically the question is, do we have any concrete plans? Do we have, it's okay because I haven't actually gotten a concrete plan so far. Basically all that we've been talking about is what is it that we're going for? We're looking for a visual representation of the output during input. We're looking for a toolbar to insert an aligned text as well as inserting an image of some kind and then aligning that image left or right with a caption. That's what we're talking about. But we've found some other things that we can imitate just in this short time. So let's look at Drupal. Now that we've looked at sort of an approach that would be worth imitating, let's look at Drupal's approach right now in Drupal 7 and then talk about ways we can improve that in Drupal 8. So this is Drupal 7. I've already downloaded and then installed the wissy wig module as well as CK editor. I could have used TinyMCE, obviously. And as you guys probably know, right now there are text formats and there are wissy wig profiles. And so wissy wig profiles is where you set up the editor and text format is where you set up the filtering. So let's say I wanted to add an image button to my editor. I would go over here to wissy wig and let's say I wanted to add this to the filtered HTML type I would save and then I would hit edit on this type and then of course, wissy wig module does define a default set of buttons but unfortunately they're not checked for you. If this is just kind of like a little UI fail that it should probably check the ones that are active by default, right? That would be nice. But instead if you check even one button then it undoes all the other buttons. So if I enable a couple and I'm just gonna go ahead and say, let's see where even is image, here we go, image. And then I hit save. What I've done is I made a new editor that when I create a piece of filtered HTML content, right? I can insert an image. But I'm gonna save you guys the work of this. If I insert an image here, what's going to happen on output? Yeah, exactly. So the statement was with filtered HTML by default the image tag is not included in the list of allowed HTML tags. So I'm gonna see the image in the wissy wig but when I hit save there's not gonna be an image there. Now that's pretty baffling to a lot of new Drupal administrators. And so what you have to do after setting up your wissy wig you need to go back over to your list of input form or your text formats. And then you need to edit filtered HTML and then you need to go down here and add image to the list of allowed tags for that image to actually come out. And this is why I'm saying that Drupal currently is doing things, well actually it's not wissy wig modules fault. Wissy wig module is doing a bang up job of what it's attempting to do. It's just that in order for this to make sense we need tighter integration between the wissy wig and the input and the filtering system on output. So much that they need to essentially be the same thing. So right now I think on this filters page or text formats page, which is provided by the filters module. The whole situation is just messy, right? The filters module provides text formats and then text formats are associated with wissy wig editors. The whole thing is just crazy. It would be nice if on this page I would just immediately choose whether or not I wanted a wissy wig editor or not. Like for the filtered HTML editor I'm going to turn on tiny MCE. Maybe as a dropdown, none tiny MCE, CK editor, whatever. Roles, that's great. And then I would be able to choose my toolbar hopefully through a much better interface than we have currently. Like you'd be able to drag in the buttons and if you drag in the bold button it enables the strong tag automatically for you. And then maybe down below you have a list of additional tags that are allowed even if they're not buttons, right? There should be a lot of configuration here that is done automatically. If you enable the image button you should enable the image tag on the output. There's just a lot of no-brainer things that we could potentially do here if they were the same thing. However, calling a text format as the place where you configure your wissy wig editor I think is also super confusing. And so my proposal essentially of what it is that we should do I think we should rename text formats to and call them editors. So you can go and you can configure your editors. And let me show you just sort of where this is gone a little bit. So this is a modified Drupal of Drupal 7 in which I have renamed text formats to editors. So you would go under editors and unfortunately you're gonna see there's not a whole lot of action here but an editor essentially is the exact same thing as a text format now with no changes whatsoever. But the lingo here suddenly kind of makes a lot more sense so it's like add a new editor, right? And it's just like, oh, I want to configure the editor the filtered HTML editor or the full HTML editor or if you had the BB code editor or the, I mean, things it's like, wow, this makes sense. The name editor makes sense from an end user perspective. And the fact that we've been basically forcing terminology like filters and text formats upon our end users neither of which they're actually very concerned with they're concerned with like a toolbar and the editor. Like they're concerned about how do I get the content in not exactly like what kind of filtering occurs on the output, right? And so my recommendation here and this one is almost going bogus. I do think that we should update the lingo to be end user facing lingo as opposed to developer logo. I think that would be a logo lingo. So make the lingo front end friendly and make it back ends sort of, you know, adjust to our users. So calling them editors, which to me, the filter module providing editors is silly naming conflicts. And so my recommendation is that I think that we should rename the filter module to the editor module. And so whenever you want to have a wissy wig somewhere in form API talk, that would mean you would say pound type equals editor. That sounds pretty cool, right? And it's a pound editor equals filtered HTML. I mean, these sort of things, like when you put it all together, you find out that the pieces fit really nicely that maybe that's something we should do. Of course, renaming a module in Dribble Core is a significant effort. So, and the really frustrating thing is that the first thing that needs to be done if we do this is we need to rename the module from filter to editor and then make iterative improvements on top of that because you can't just remove a module and add a new module into Dribble Core and have that be passed through the patch process or passed through the gates now. That would just be a tremendous like, you know, 1200 comment thread with a two megabyte patch. It just isn't a process that anybody can review adequately. So it has to be this iterative improvement and getting through the first problem of like renaming filter to editor, which I think that's where we need to start is gonna prove to be a huge battle. But that's why I'm here to you guys to explain all my thinking. So hopefully you guys can agree with me. Larry, oh, do I have any usability studies to say the editors is better than text formats or filters or other terms? No, definitely not. So do the usability study first before we start implementing this? And that brings up an interesting point. Obviously doing the usability study first means that needs to be finished or at least usable. I mean, right now it wouldn't make any sense if we had somebody go through a usability study with this and we said, okay, I want you to add a bold tag. You know, well, first of all, they'd be like, well, what's a bold tag? He'd be like, well, it's HTML. And they're like, well, what's HTML? And now your usability study is pretty well shot, isn't it? Because it's like, how are you gonna have them? You have to teach them what HTML is. But the end purpose of this is so that they don't have to learn HTML at all. So you could do a usability study with paper as an alternative. I'm, yeah. Yeah, that's a good point. Yeah, so as an abbreviated test, I can agree with that too. If you were telling users that they had a choice of wissy wig systems or had the ability to turn on and off the wissy wig, which term basically this label right here next to this dropdown made the most sense. And if it was plain text versus like full HTML or plain text versus visual or something like that, which term did they find to be most intuitive and which one did they find first? That would, like an abbreviated test, that would be great. Yeah, so basically the end statement is that we need to figure out, we need more evidence to back up that changing the name is a worthwhile endeavor. Right, and the word editor doesn't exactly convey the amount of filtering and the amount of security that may be implied there. But really, I mean, right now we have a really, really hard time with text formats. And yeah, yeah, yeah. So making it clear that the security and the full repercussions of what these things do, we need to make that clear no matter what we go with. Back here. Right, which actually that process you've described has never been done in Drupal ever. And it's kind of like, I mean, you can say maybe, you know, we've had usability studies we're always testing what we have right now. They've tried some things like usability testing on vertical tabs and things that were obvious improvements and we found that, yay, those things are better. But we kind of already knew what the results of those things were gonna be because everybody liked it. And everybody liked it is pretty much the model that we've been going on forever. So basically, the description or the full comment was that we need to have like UX people come in and come up with potential designs and we need to have that reviewed and then we need to have some way to actually test that and see if it's worth building and then we actually build it all out and see and then we test it again probably to make sure the end result is good and then we maybe reiterate and change it on top of that. There's kind of an issue with the Drupal community that we actually have so much more development power than anything else that oftentimes what we'll do is we'll develop it first and then usability testing it and test it because honestly it was easier for us just to write the whole thing and then have it tested against the final product and then iterate on top of that than it is to have the usability tests. But then of course some people's work sometimes gets said that is entirely wrong and the entire thing gets thrown out which has happened in the past before too. But, or it'll go into core and then the next version of Drupal core will fix it. I don't know what you've described sounds desirable but there's a lot of resources there that you've described that aren't immediately available. There was another comment up, oh yes. Yeah, so that's a great comment. So regarding usability and functionality that we can potentially implement in a Drupal can't we just look at what other people have done and learn from that which is a really good statement because WordPress's entire UI, the 3.0 version I think it was could be totally wrong about that maybe it's 2.5. They had HappyCog do their entire administrative UI like everything and they redid the entire design kind of similar to what Drupal did with Mark Bolton only since WordPress is essentially a single company developing it for the most part. They implemented it entirely versus what we got in Drupal was kind of like a half baked version because the Drupal community actually wasn't interested in implementing all of the designs that were in the D7 UX movement. So we ended up with this funny kind of half done system things like the dashboard was just complete catastrophes and things like the toolbar that a lot of people liked admin menu better which the irony being that WordPress essentially actually has an admin menu and we have a toolbar kind of just the way things work out sometimes are just funny. So yeah, any other comments about WissyWig and this approach like generally speaking like how's it feel in the back? Okay, so basically how do we move forward and especially non-developers how do we participate with this? Well, right now with Drupal 8 development things are a little bit of a standstill but that doesn't mean that it's gonna be that situation forever. At DrupalCon Chicago I was rustling up a small team of developers trying to get sort of behind this idea of making input filtering and output filtering the same thing and building the WissyWig in into all one big interface and generally got a lot of positive reception there but as for now like I guess we could have things like I mean the UX designers and the UI designers of people that have the ability to actually come up with things without actually having something to start with already could have a big impact here in terms of like visualizing what the final interface would look like as for where that collaboration can actually happen. I'm hoping to take a lead on this particular project and actually move it forward into into Drupal 8 core and for now what I've done is let's see if I can figure out where this is. Oh, I know where I can do. So what I've done is I've created a sandbox project for WissyWig in core and that's where this code that I showed you of basically the renamed editor module lives and I think actually this is what you know I still haven't quite figured out how to navigate Drupal.org without the URL but no idea, no idea at all. So there should be a usability like core initiatives like things that the community community initiatives and in that one there is a WissyWig section and included in that is my post that says I'm trying to take a lead on this and it links here to my sandbox and the sandbox project is currently only has two issues in it which basically is a call for volunteers which if you're interested you should post there because that's where I get a list of people that are interested in the project. So if you can add a subscribe to the call for volunteers and this is like just a general meta discussion currently which honestly the number of meta discussions that we can have about WissyWig without actually doing something is pretty infinite. So what I'm wanting to do is actually have a discussion around code that exists as opposed to discussions around just WissyWig and core because we've been having discussions for years but we haven't actually written any code. So there was another, yeah up here. This is more of a, we also like to tell what some curl was saying about use cases and that we're talking about what you see is what you get automatically creates accessibility issues which is again sort of another use case. So I'm totally interested in this but I can't call it so the power to help, the power to ask someone who's critical to help with this is what solves some serious problems. Okay, so basically, yeah it would be great if we can get more people especially like the comment specifically was around accessibility in WissyWigs and WissyWigs naturally, your accessibility of your site oftentimes is dependent upon your editors to know about accessibility and a WissyWig sort of immediately reduces the overall accessibility of your site unless you enforce some kind of tools to make them work in an accessible manner. So how can you participate? How can you help be involved in that? And there's so many people that really want to improve upon this system but it's like what it is, when it comes to the amount of discussions that are necessary and the amount of things like reading text is a tedious process and that's why I think that we need things that are more tangible like we need images or mockups, we need wireframes, things that people can actually look at and sort of respond to and my natural instinct almost always is to have working wireframes so basically just code it and see if it works and that's the way a lot of Drupal development has always been because that's what we have a lot of. We have the ability to work really quickly in the development side but then where things actually get held up in Drupal, people think that some people may think I should say, some people may think that Drupal development is slow because it takes a long time to write the code, it's totally not the case. Drupal development is slow because it takes a lot of work to get through the politicking and the bureaucracy and basically reaching some kind of agreement. Core development like views got entirely like new UI that was designed and basically executed upon in a matter of months and views was basically the entire interface was overhauled over the course of six months which is of an amazing feat and that's because we have incredible development muscle to actually execute on things if you remove the processes. Of course with Drupal Core something that's this mature it needs processes to make sure that stuff doesn't go wheelie-nilly all the time so actually developing this and getting something working and with the Git migration we have this amazing ability to do sandboxes, we can actually do stuff and have something to work against and if they enable tar balls on sandbox projects we'll have an even greater ability to make this stuff accessible to people and say look this is it, set up a demo site and look, look, go try it out and it's just a website and that's your mock up if you will and I think, I don't know, my feeling is that's the way I feel that this project is going to proceed where essentially I had to make this so single person focused but honestly I like to code and I like to do things that move things forward so what I think is probably going to happen is we'll have some code that is actually executable and you can actually go look at and then we start the discussion of was this actually right and we roll back and start from the beginning again which is the way that pretty much everything has happened in the past well except for D7's UX which was sort of the anomaly and honestly not everybody was actually happy with the way that turned out. So yeah, another one. Yes, yep, yep. I'm so glad you asked. So basically the question was if we're going to put a wissy wig editor in core and have things like you're going to drag in buttons into your toolbar and choose how your toolbar works ultimately we need to make a decision about which one to include and I'm going to tell you guys right I'm not going to keep you waiting I'm not here to tell you what that editor is. I can tell you that we essentially have a choice to make we need to choose one and that I think that right now there are two real contenders CK Editor and TinyMCE and choosing between one of those is a decision that we need to make. The simple solution right now WordPress uses TinyMCE if we take that approach we have a tremendous advantage that we can just copy a bunch of their code like literally just rip it right out. It's GPL, it's great, that's what we are. So we can just totally move it right on over. So that would save us some potential work. CK Editor, I think this is purely by my gut feeling I think CK Editor is more popular right now. WordPress has been using TinyMCE for the last six years and so they'll probably continue to use TinyMCE because it's what they started with and that's why they're using it. So I think we could save ourselves a lot of work with TinyMCE and we know it does what we want it to do. CK Editor, I'm quite confident that it can do the same thing too but if we run into, like I think we should try it out first so we can research the alternatives and see if it works then maybe we'll proceed that way and if it doesn't work then at least we can say well we tried but we have to go the other way. So I wanna talk a little bit more about why, about the single choice because the WYSIWYG module currently as it is today the WYSIWYG module has attempted to write a generic wrapper API around all other WYSIWYGs making it possible for you to swap out any WYSIWYG you want into Drupal but just by dragging in the library. This is the one point where Son Daniel Kudwin who unfortunately is not here, he and I disagree about that particular point and that I see that we've been working on this WYSIWYG API for years and the simplest thing that we've implemented in this generic plugin fashion is the teaser break, right? The teaser break little icon to split the body and the teaser and the actual body has been written as a generic plugin but unbelievably that simplest piece of functionality does not work across more WYSIWYGs than TinyMCE and CK Editor, it hardly even works in CK Editor as far as I know and so essentially we've written this generic API which is a huge burden that people that have written CK Editor plugins or TinyMCE plugins can't actually use their knowledge, they need to write a whole new plugin that is a Drupal plugin that doesn't actually that is a completely different set of knowledge that can't be used anywhere else and so my general feeling is that the generic API I think is extremely difficult and it's a lot of work and we haven't even succeeded in it despite the years that we've been working on it that the generic API is not worth pursuing that we should pick one and honestly whichever one we pick people will develop against that one platform and if you install an alternative one like other modules that integrate it with the WYSIWYG maybe Media Module continues to exist in Drupal 8 will need to implement the functionality themselves basically say once for TinyMCE and once for CK Editor because I think that one editor it just has so many, it's simpler existing knowledge can be reused the functionality is already built at least in the case of WordPress there are so many advantages to reducing the code weight there and just building against one so back here you've been waiting a long time yeah so how do I feel about content editable and using basically new browser, newer browser technology I know Firefox has had it for years now Internet Explorer 5.5 had it but I really doubt that was against any standard or anything yeah so the ability to do that sort of stuff has been around for a while but how do I feel about it? I still feel that it's not mature enough it's not a mature enough technology to actually become reliant upon it which I know it's kind of a bummer that we're stuck against this technology that is really like new and not mature enough and this technology that is very mature but old and crufty because like TinyMCE and CK Editor they're not exactly like hot new projects that most people have worked with them at one time or another and a lot of them people aren't happy with it but I still feel like right now we just the ability to use like in browser editing and content editable we're just not there yet so in the future potentially but those tools also are also like they're very much HTML tied doing this kind of like filtering stuff on input and on output and making it so that the browser itself is executing some kind of code replacement just seems like we're, yeah and it's too new for me to even have pursued it much. Yeah, yeah, so from the end user perspective the statement is like we can be attracted by like new approaches and new technologies and potentially they'd be really cool and they'd work really well but for the end user we really need something that works and we need something that works widely with the system like Drupal. Camilla. Okay, okay, so is that, yeah so two points so the first one was the big gripe against WYSIWYG is the type of data that gets saved in the database can look really ugly, right? Like maybe it has MPP tags all over the place and stuff like that. And the second point was does WordPress do any kind of like link checking to make sure the images exist or that the links are valid and things like that and to answer the second point right off I don't think so, I think it's just if you've linked to a broken image then you've linked to a broken image and if that image has been removed then it's removed and now you have a broken image so I don't think it has any special checking against that kind of thing. WordPress does however do some work to kind of ensure that you've got nice content that gets saved into your database and interesting thing that WordPress does is you'll see here like I've got these two paragraphs here and I entered these in the WYSIWYG but they're not actually wrapped in P tags. So even though this is the HTML so like the WYSIWYG here that we've got if I enter in new lines and then I look at the HTML you'll see that they don't have P tags around them and that's because WordPress essentially implements this is what we're lacking. WordPress implements the automatic return to P tag filter like Drupal does but it implements that on the input as well as on the output which is what we're lacking. With Drupal you should do the same thing that when you do a return in the WYSIWYG it doesn't put a P tag in the HTML because the P tag is added by the filtering and it's the same sort of thing that this is what I'm talking about where the filter is applied on the input as well as on the output and if we had that then the code that was inserted into the WYSIWYG would be a lot more similar to the code or the code that people type out by hand right now because when people type out by hand right now they know that the P tags get added for them so they don't add it and if we had that integration between the input and the WYSIWYG then the WYSIWYG would know that the P tag was gonna be added automatically and it wouldn't do it either. Yep, actually that's exactly what I was in the midst of pulling up was that there is a function here that essentially does that and WordPress does not have that ability to to configure your input formats, right? It's all just the same for everybody. Yep, yep, and here it is underscore WordPress underscore no P for paragraph tag and this is its regex that it runs essentially when you turn on and off the editor or when you save it into the database when the editor, the editor automatically turns itself off when you hit the save button and that's what gets saved into the database. Yep, and then there's a PHP function that does the exact same thing. Exactly, so what I've been saying, we need to essentially write filters twice. You need to write them once in JavaScript and once in PHP and they don't need to be identical but they need to be pretty close in order to make that work. So a recap on, okay, yeah, I have about two minutes. Thanks for the heads up. So a recap of what it is that we need to do, we need to enhance the filtering system to provide a combined input which basically means JavaScript and output which means PHP filtering. So make filtering do input and output filtering instead of just output filtering. Unified configuration of rich text editors or wissywigs with the configuration of filters. So filters and wissywigs, they're all one thing now instead of having them be in two separate administrative areas that don't talk to each other. And shift the terminology around content creation from developer-centric terminology like filtering to user-centric terminology like editors. And yeah, as we discussed, editors isn't set in stone, I just think that it's a good proposal. But this is the extent so far of where I think wissywig is going to head. There are a couple things that are totally unanswered and I think that we need to have more information on them before we can actually, well, I'm not saying we can't act upon it, we can act upon them very little information actually, just not sure that you're gonna go the right way. But which editor we're going to use is a big decision and the ultimate bike shed, I'm sure it's going to be a fantastic battle for the Drupal analysis of history of which one we're going to use there. But I'd like to base that not upon the things that we have today, because what people are judging today is they're judging the out-of-box experience because Drupal's integration with those things is really bad. It's literally like everybody is judging them off of what they get out of the box, not the kind of integration that they could potentially have. I think that if we write a wissywig in decor and we give it just kick-ass integration with Drupal, it doesn't matter which one we choose because it's going to surpass everything we've ever done before as long as you write really good integration. Right now, with the wissywig module, the idea was to ride you with as many out-of-box experiences as possible, and none of which are good, right? It would be great if we had like a, whichever one we choose, if we make a really compelling, tightly integrated experience, then I think that it'll make it so people don't really even care what the editor is. Back here. Does WordPress have the ability to offer anything else? I think they do. I've seen, yes, plugins that allow you to swap out the editor, but of course, what those editors need to do is they need to reimplement almost everything that is done by WordPress Core for their particular editor. So there's a lot more work upon each individual plugin's opportunity, and I think that will remain. I'm not suggesting that the filter module or editor module would include TinyMCE or CK Editor directly. I think that that still needs to be a separate module that is just the default implementation that is turned on in the standard profile. So TinyMCE module or CK Editor module, one of those will rise from the ashes and be included in Core, essentially along with the editor module, and they'll just collaborate together and they'll just be the default. And being the default pretty much means that they're what everybody will use. Any other last comments? So can we show a video like right now? Do we have time for that? Okay. Okay. Well, what I'm going to do is I'm going to say, thank you very much for coming. Okay, so in the meantime, while we're waiting for lunch, let's watch the video on WissyWig fields.