 So, when the typewriter first was invented, it was the sort of concurrent to that, the QWERTY arrangement of keys was invented. And originally, actually before that, they had keyboards that were like piano keyboards, which is why we call a typewriter keyboard a keyboard or a computer keyboard a keyboard because they evolved out of the piano keyboard. They thought that this would be the optimal way for people to enter text or to type text. It's a little bit silly when we look at it now, but it shows you how things radically change. But there's a little bit of a mythology that kind of grew up around the keyboard. And there's two different stories of how the whole QWERTY arrangement evolved. If you've ever spoken to anybody who uses a different kind of a keyboard layout than QWERTY, you might have heard the story about the sort of speed of typing where the original typewriters with their, with the keys that sort of used the ribbon and actually wrote onto the paper would get tangled up if people typed too quickly. So they intentionally made the QWERTY keyboard more difficult to use so that type couldn't type so quickly that the machine itself would get tangled up in itself. So that's sort of one thread of the mythology. And the other one is that they made an unusual arrangement so that they could have a monopoly on the teaching and the sort of, you know, the business around teaching people how to use this complicated typing method. So now we're not sure whether either of those is really true. But suffice it to say that once a standard like this establishes itself, it's very, very difficult to rip it back out again. And even if it's not the most optimal method for doing this, it sort of, it has this kind of crazy longevity. So if we look at, you know, you see QWERTY in the earliest keyboards and then it so quickly became the standard that it was, you know, it was adopted and carried through and, you know, you got it in, you know, all of the manual typewriters. And then here's an Atari, you know, one of the early word processing machines. And again, we still have the QWERTY keyboard. We still have the exact same arrangement because it's so embedded in the practice and the use of it in the everyday lives of all of the people who require this for whatever they're doing, their businesses. And then, you know, we can bring that forward into, you know, when we get into the age of mobile, the early, you know, machines that we're looking at, again, we still have QWERTY. We still have the same basic kind of layout. And you know, up to Mac, we still have, we're still there. This inefficient sort of system is still sort of carrying through right into iOS 7. And interestingly, the guy who invented the QWERTY layout, he wasn't satisfied with it. He didn't think it was necessarily the be-all and end-all and he kept writing new patents for different arrangements. But because QWERTY had gotten so sort of, you know, well adopted and universally used and everybody, you know, sort of was comfortable with it, none of that ever took off. So you can see this is an actual patent application that he put together where he has a totally different, you know, main, you know, root, I can't remember exactly what they call it. It's the sort of, trying to remember from my typing classes from high school, home. There you go. That's the one. So there's an entirely different set of letters for this particular patent that he was looking for. So you know, if we think about, you know, how the user enters information or how the user works with a system, you know, if you looked at Dries' keynote, you know, we talked about simplifying the user journey and that's also true here. You know, we want to try to simplify the authoring experience and simplify the user journey as much as we can. So we go back and take a look at this, you know, again, it's all about the experience and if we go back before the web, we can see that the experience was very complicated and it took quite a lot of time. You had, you know, handwritten notes which you would then make into an outline. Maybe you might mail that to somebody to share that with them and get their input on it. Approval could be over the telephone, you know, you had to then send this work to a designer, say you were in a publication like a newspaper or a magazine or a book before the days of the web and then if you wanted photography, there was, you know, real film and photography that had to be developed and composited and typeset and film needed to be shot of an entire piece and then made into plates that got printed and delivered and then sold on a newsstand or in a bookstore. So it was a very long process for the author to get their message, you know, to the end user and we simplified that quite a lot, you know, so in the age of, you know, the static web when, you know, people wrote HTML by hand but you still had to, you still had the same kind of, you know, processes. You started with your notes, you create an outline, maybe you email that around to a few collaborators to sort of get feedback on, share it. Maybe your editor approves that again by email but again still design, a designer has to take that from there and then a coder makes it into HTML and publishes it to the web. And now, you know, currently we have, you know, a situation where people are starting to use mobile devices to sort of take notes or sort of, you know, there's a lot of sort of Evernote and a lot of other apps where you're getting your thoughts down immediately wherever you are in the context of what you're doing so that you don't have to go back and sit down at your computer at a later point. You don't have to, and you also don't have to use a piece of paper that, you know, you would then have to transfer onto the computer. So you have this, you know, this note taking capability but oftentimes that's not really connected to the mode in which you share the information. So you might be taking your notes and then transferring your notes into an email and sending that to somebody or you might be putting it into a Google Doc and then you're collaboratively working on, you know, oftentimes at Acquia, we do this, we'll put a Google Doc together before somebody publishes a blog post and several people will comment on it, you know, in the Google Doc and it becomes a, you know, that's the forum that becomes the way that you revise and extend and expand your thoughts until it's in a state where you want it to be. But the problem is that at that point you want to move this into the CMS. And when we get to the CMS, when we get to Drupal, right, you have to copy and paste. Maybe you're copying from Word. Maybe you're copying from some desktop, you know, application. But I think more often these days you are, you're copying from Google Docs or from some other collaborative editing platform. Maybe you're using Evernote or something else like that. And your formatting is completely lost. You know, in Drupal 8 we introduced the capability of having your format come with you from a Word document, but that's not true of Google Docs. Google, all the formatting in Google is in there with JavaScript and spans and everything is completely gone by the time you paste it into Drupal. So then you're going back and you're adding back all of the formatting that you had when you put together your collaborative, you know, editing process and then there might be an additional sort of, you know, workflow process after that, at the end of that, right? So you had a sort of, you had a collaborative process in working in Google Docs and then it went into and got reformatted and then, but now I also have a workflow. I have workbench installed and, you know, and then I have an editor who has to approve it and then they're going to say, okay, that's good to go. We publish it. We push it live. So it's still a fairly, you know, complicated and convoluted process, but what we really want is something much more simpler than that. You know, we want a situation where all of the note-taking and the editing and the collaborating and the sort of formatting occurs in one place, right? All in a single sort of environment where nothing ever gets lost because this kind of loss and sort of rewriting and reformatting is, it's painful. It's not an optimal experience really for anybody. And however much we have improved content authoring in Drupal 8 by adding, you know, by adding edit in place and adding CK editor, which is awesome, these problems still persist and they will persist into the future. So we have to think about where we're going to go next with this. So going back to the keyboard for a minute, I want to just dive into some of the current sort of trends and places where things are going, you know, with the keyboard itself and with text input. So because the landscape of this is changing really, really rapidly and we're going to need to adapt to that. We're going to need to figure out how we, you know, how we cope with these totally new paradigms that we're going to be seeing. So you can see that, you know, right off the bat, a lot of people use a Dvorak keyboard, which is, you know, which solves this QWERTY problem. You know, we saw, you know, how we've inherited this ridiculous QWERTY arrangement, which is not optimal for typing. So the Dvorak keyboard completely rearranges all of the keys and lets you type more, supposedly lets you type more efficiently. And a lot of people at AQUIA use that. I personally never could type either way particularly fast. So I'm always just sort of hunting and packing with two fingers. But, you know, this is at least a start of an effort in the direction of sort of optimizing this, but let's look at, you know, a couple of other things. So obviously we have all of our vowels in the home area rather than, you know, the QWERTY, which doesn't really make a lot of sense. You want to have the things that are there most often. But then, you know, but now we have swipe. You know, I mean, we have swipe keyboards and Android devices. And you have swipe keyboards and apps on iOS and, you know, and on desktops and on Windows devices. So, you know, how do those two things mesh together? If people are using swipe, but they're swiping on a QWERTY keyboard, that doesn't really even make any sense anymore. You know, I mean, the home keys are there, you know, because you typed with two hands. But, you know, swiping is a totally different experience. Why do we have that? It doesn't make any sense. You know, you have swipe also on your phone. If you have an Android device or you can have it, you can set it to your keyboard. But it's not, again, it's not universal. It's something that's available for some users and not for others. For instance, iOS, you can't set your global keyboard to a swipe keyboard. You can have an app. Here's a couple of apps that I have used, which are really interesting for this. One is Path Input, where you can have a swipe keyboard for iOS. And the other one is Flusky, which is not a swipe keyboard, but it's a keyboard that sort of is adapting to you and sort of figuring out how to auto-complete your words based on a database that it compiles of your most commonly used words and the patterns that you use to type them. But both of those are really excellent. And then you also have, like, voice and dictation stuff happening. And then you have things like Markdown. And if we go back and we think about these, all of these aren't really coming together yet in a kind of a way that makes sense and that sort of ties it all together. So if we go back to our Dvorak keyboard, you can see that it moves all of the most commonly used letters into the middle, where they will be easily used. But this doesn't really necessarily work with swipe. And it doesn't really even work well just with touch. First of all, they're squares. That doesn't really make any sense. You want to have something that maps more closely to the human factors, to your actual fingertips. Your fingertips are not square. And then the next thing is that if you are using swipe, say you wanted to swipe student, the word student. Well, you can see that because all of my letters are in a row, it's a much more difficult job for the pattern recognition to figure out that I'm typing student because I'm going back and forth across all of these letters several different times. So if we were to, and also it's set up horizontally for people for sort of two-hand typing. But if we were to think about this in a slightly different way, and rearrange things so that you stagger the letters and then you brought them all together, something like this makes much, much more sense for swipe. This is student again in that format. So I have a way to more easily move around and I can see where I'm going. And additionally, one of the other problems with the swipe keyboard is how many people have actually used a swipe keyboard just out of curiosity? So quite a lot. So how many people have had a problem with a swipe keyboard where your finger is in the way of the letters? Have you seen that? Yeah, it's problematic. I find that it works quite well if you're using a stylus. But on a phone, your finger gets in the way of the letters. So I don't see this as necessarily a really kind of efficient way, even if you make improvements like this of users, of authors, authoring content in Drupal with the swipe keyboard. But there's a lot of other things happening. And then the other question is, isn't this the responsibility of the device? Well, when we're thinking about our CMS, we're thinking about what does the CMS do and what does the device do? And we push off all of these other use and responsibility questions onto the device and leave it in their hands and say, oh, well, you know, I mean, we don't have to worry about that. We'll just give them a whizzy wig, and then they can format their text. But how they actually get the text in there, that's not our problem. That's not our business. I think we should think about it. We should think about it as our business because we should be thinking about the whole user journey. And it's not just that it's our responsibility or our problem. It's our opportunity, right? As a community to seek out what the entire experience is and see how much of it we can really encompass with what we do. So I'm gonna talk a little bit more about that later on. So one of the things that we've come across in the authoring improvements in Drupal 8, that may be a problem that we are gonna have to think about more creatively and differently, is that despite the fact that we've got CK Editor and that we've got Edit in Place and that we've got a lot of really much more effortless tools for entering text and for authoring things in Drupal, we are still fighting with the devices. So how many of you have used CK Editor in Drupal 8 on an iPhone or on an Android device? Or tried it out? So, you're right. Or boy, I'm sorry. It's not easy because the device is fighting with you. It's great. It's tremendous on a desktop or laptop device, but as soon as you get into the context of mobile, the devices are getting in your way. They're throwing up their tools right in front of the WYSIWYG tools. And this is really problematic, because there's nothing we can really do to get around that. We can't turn off the device tools. The device tools are gonna be there, no matter what we do. And what happens in this instance is, in order to use this, you have to scroll out of the way. You have to scroll the device controls away from where your cursor is. And in some instances, if you have specific types of controls under there, by the time you've scrolled it away, you've deselected the word that you had selected and you can't even do the thing you wanted to do. So it's really, really difficult. And we spent a lot of time trying to figure out a way to get around this. And what we found out was that, you know, we were just gonna have to live with it the way it is. But, and then in addition to that, the device is providing redundant functionality, which is confusing to the user. You can see here that you have bold and underline underneath, or on top of in the iOS device tools, you're bold and underline that you have in your CK editor. So somebody might easily get the impression that they could bold something using the device tools in iOS, and that it's gonna be bolded. But that's not gonna be saved into your database. It will bold on the screen. If you bold something, it's gonna bold it. But it's not bolding it. It's CK editor is not bolding it. It's not getting written into your database. So this is another one of the problems that we are encountering and that we're gonna need to think about. So, you know, a lot of these issues around, an application or a device control can be overcome in the context of an app. It's just when we're in the context of HTML in the browser that we come across these problems. So it begs the question, you know, should we think about solutions in Drupal that use an app to, or use something that's more on the client side to deal with these issues. So, but when we talk about issues with input and issues with text and keyboards and WYSIWYGS and all of those things, there's a whole other range of things that we're not even thinking about, which are coming on the line. So the content author's journey starts with input, right? And we need to understand where all of these new methods of input are going, because this is really, really a very exciting area. So, we have glass. Glass, obviously, you're not writing things with glass, but you have input with glass. You know, you have a Boolean, you know, blink, which is yes or no, or submit, or, you know, or cancel. So, you have that ability. And it's not too difficult to imagine, you know, coupling glass with voice recognition and being able to look at a document and speak your text and then sort of, you know, use your WYSIWYG tools, you know, with your glass controls. So, you also have style, you know, things that use a stylus, I mentioned before, but this is, you know, can be very slow. Has anybody seen this film, Her? It's really interesting because, I think it's wrong in a lot of respects because it shows this world in which this guy is talking. He's using voice control in the office to sort of write, he's a kind of a writer, he writes people's letters for them, which is kind of a strange quirk of the movie. A rewriter, right, he rewrites people's letters. But it brings up this issue, which is something that comes up with voice, which is that nobody wants to speak a personal email or correspondence in the middle of a crowded office where there are people standing all around them. But there are things that are arising now which sort of overcome that. So, dragon speech recognition has been around for some time and it works quite well, but you're not gonna speak private correspondence, you're not gonna wanna do that. And the other thing is that it strains your vocal cords. If you're an author or a journalist and you're speaking all day long, this is even worse than carpal tunnel syndrome. You really get vocal strain. People have severe problems with this already. Character and pattern recognition is what's being used for the stylist stuff. And all of these things are using these kind of forms of recognition, but this has problems with speed. You can't write in longhand as fast as you can type. You may be able to use your stylist to swipe faster than you can type. But there's other interesting things on the horizon coming up very soon, which is things such as sub-vocal speech recognition, where you're actually not really even speaking. You're just thinking, I'm gonna say this, and a voice recognition very similar to dragon is actually reading that. But it's not quite ready for primetime yet. It still has problems with accuracy. But this technology and other technologies around sort of sub-audible, highly sensitive microphones are going to come together to form a new form of input where you don't really need a keyboard at all. You don't need a stylist or a keyboard or anything like that. And how are we gonna deal with that when that comes along? How are we going to, how does that mesh with a WYSIWYG editor? How does that mesh with text input in Drupal? These are questions that are gonna need to be asked. So, and then additionally, we have a lot of stuff happening about the intelligence of the device or the intelligence of the application. So we have things like auto-complete, auto-correct, which gets a lot of humor on the internet. And other things like, essentially these auto-comprehend tools where it's like it's figuring out what you were going to say or what it thinks you might say and then sort of auto-filling those in. All of these things, one of the interesting things about these things is that they all compile a database on you and on your specific habits. And they use that to build on this sort of recognition and improve it over time. Nuances tools use that and a lot of the other tools that they're building up a database that's gonna be something that is specific to you. It's not sort of general. And then there's something that I'd call contextual input. And we already see this with things like photos on your devices. So if you go out and you take a photo on an iOS device, that's geotagged and it's given a lot of meta information based on where you were the time of day and a lot of other factors, what device you were using, et cetera. But it's not hard to see very soon in the future a situation in which all of the input that you create of text is also meta tagged in this exact same way. So your system can know and read back to you, oh, you said this at night or you said this in bad weather or this is something that you wrote at this particular time in this particular place and then be able to use these recognition techniques to make some sense of that and to give it back to you in a more contextual way. So that could lead to something which I would call auto compose. So imagine I started an email or a document and I said one of the problems with using web fonts is and then it prompted me, on December 12th, 2013 you wrote this, right? You've already said this, you've already written this stuff. Do you wanna just use that and or edit it and add to it and extend it? So it's kind of in a sense replacing your memory. It's like it's sort of extending and adapting to and enhancing your ability to author and sort of compose ideas and bring things together. And that's really just the beginning of that kind of thing. But one of the things that this really sort of leads to or one of the questions that this leads to is should, you know, with all of these capabilities, right? With all of these possible modes of input and with all of these problems that we have with fighting with the device and not having a sort of a mesh between the device and what we're trying to do with Drupal, which is give people an authoring experience that makes sense and that's effortless and easy, does it really make sense for us to continue to push on authoring being on the server side and should authoring really be on the client side? Should we be working on a solution that brings authoring over to the client side or something that bridges that gap in a better way? I mean, we have authoring right now, again, we have this situation where I take notes, I share, I use Google Docs or some other method and then I still have to do this reformatting. I have to bring it over the gap. How can we remove those steps from this process? And I think that there's a couple of ways that I think that we could do this that we could look towards. The first one is authoring on a content server. This doesn't necessarily solve the problems of, it doesn't necessarily solve the problems of, I want some specific form of input that I don't have available to me in a browser like Swipe or something else like that or Voice or some of these really forward-looking things and it also doesn't solve the problem of, I want to edit when I'm offline or when I'm not connected to the internet but it does solve the problem of, I want to compose things in Google Docs and have a collaborative editing process and then move that into my CMS, right? Because if you have a content server, you could conceivably have your collaborative editing there and then just push that content into whatever site it's going to. The other value of having a content server and a lot of people are making distros that do this is that you can push to several different sites. You can have, if you have an architecture or enterprise infrastructure with many sites, you can push your content to the site that you want to push it to but all of your authoring lives in one place. Especially if you, this is nice if you have, if you have content authors who are publishing things to multiple different sites. It improves workflow and a lot of other things like that. But then the other path is client-side authoring. Is there a way that we could move authoring to the client side? Could we do it through an app? Could we do it through a richer use of local storage or some other technological means where we can move things into the client and give people the ability to both edit offline and then also to be able to avail themselves of a lot of these kind of connections to the device that you don't necessarily get when you're just in a traditional browser situation. So I've mapped out some of the pros and cons that I think these kind of solutions might have but I'd love to hear, when I open up for questions, other people's ideas as well. So I'm thinking that when you have things on a content server, you have all of your content in one place, you have a canonical record of content. You have, as I said, better workflow. It's better for multi-channel deployment. But we're still fighting with the device controls. You can't work offline. You still have to migrate local content if you wrote something on your local device. But if you're authoring locally, you can have all your content in one place also but you have a single authoring environment. If you have something that works in a similar way to say, for instance, Evernote or Dropbox, you can actually have collaborative editing through an application. But you can also have that local experience where it has all of those databases, remember, that are sort of remembering your information and how you swipe and how you speak and something that you said last week and keeping that locally in a database. It's also more customizable and you can work offline and you can publish to any system. Publishing to any system, I think, is one of the really most exciting parts of this because if we have a system whereby you can edit and enter and author your content locally, who's to say that that couldn't publish to Drupal but then also to Joomla or to WordPress or to typo3 or to some other CMS? And just by hooking into their REST scheme of whatever their fields are and pulling that down into your local environment. And then, again, the personalization, the algorithms that are put together about you that describe how you edit, how you do things, right? The cons of this is, well, it's not Drupal. That's another application. And how does that mesh with Drupal? How do we do something like that as a community? And then also, there are cons around collaborative editing. It's probably gonna be quite difficult to do that. And does it dilute the power of Drupal as a CMS? If we move, if we think about the place where people are doing their content authoring and editing as outside of the CMS, are we sort of taking away something fundamental from Drupal? So those are some of the questions that arise around this. And but one of the notes about the app experiences, we already created an app for authoring content in at least an iOS app for authoring content in Drupal. Acquia built this app called the Drupal Gardens app. And this is available for pushing content into DrupalGardens.com. But it can also be used to push Drupal content into any site. So this is something that could be built on top of or sort of extended to do a lot of these things. And as I said before, on the content server side, there are a lot of distros that are already doing that. But then there's also the question, does it need to be an app? Or can we just make a more open, restful kind of sort of endpoint for accepting content and allow people to just create their own kinds of apps that will sort of be able to feed content or pull the schema of a content type with all of its fields locally, edit that in whatever system you have and then push that back up into Drupal. I could easily see with Drupal 8 now that we have rest in Drupal 8 that happening much more easily. So obviously there's implications also for staging, collaboration and workflow, but there are apps out there like Firepad for instance, which is a client side editing app that allows you to collaboratively edit locally on your device and do it in real time, just like you can in Google Docs, but then, and this is an open source app as well. So I don't know if it's GPL V3 or V2, but it's definitely open source and available on GitHub. So there's a lot of interesting questions there and I'd love to hear what people have to say. I can see some people filtered out, I think they really wanted to hear more about the semantic stuff or the content strategy and WYSIWYG stuff, but like I said, there's gonna be a lot of that in Jeff's session, which I encourage everybody to go to because he's gonna talk about how we chunk up our data once we've got it into the system. But I'd love to hear people's opinions and questions about what I've talked about so far. So with that, open up. Anybody have any sort of thoughts on the modes of input or the different ideas? Hi, Peter with the Four Kitchens. So I don't know if there's, this is a very open-ended question and I don't know if there's a very good answer, but I'm curious to know your thoughts. Given the need to chunk up our data and provide more structured content, what kind of impact does that have on what you have discussed here, providing a better experience for authoring and where you do that, whether you do that locally or on a server, what? Right, so I think, as I was alluding to at the end, I think that the fact that the structured data model is there in Drupal, at least outside of the body field, I think Jeff is gonna talk more about when you get into the body field and how do we chunk up that content. But outside of the body field, we have all of the structured fields there and any system that's inputting content that's on the client side is gonna be feeding it into those fields. So it's really just the job of that system to sort of make sense of that for the user, to make sure that they have a clear understanding of the structure of the data. And in a sense, I think that that's gonna be easier for a lot of these systems because it's abstracted away from the actual site, right? When you're in Drupal and you're actually editing your content, you're very much connected to sort of previewing it in the side and seeing what it's gonna look like and then it's getting mixed up with the presentation to a certain extent. When you abstract it away and you're editing it locally, you're literally looking just at the content. You're not looking at any of the presentation. You may go and preview it or push it up to a staging site and then preview what it's gonna look like, but you're just seeing the chunks, so to speak, right there in front of you. So I think in a sense, it's better for semantic content creation than a lot of the experience that we have right now. Does that answer your question or? Yeah, I mean it was very... Cool, sure. I'd be curious if anybody had any ideas around or thoughts around what I talked about in terms of the content server ideas and editing on the client side or in fact any experience working with systems that do editing on the client side. But anyway, go ahead. I guess my concern, I own a small agency in Boston who develops only Drupal sites and our struggle is getting our clients to put their content in, but they, I guess my concern with the methods that you've described is that for non-technical users, when they, we're trying to get them to link things and create calls to action, I would see them having a lot of difficulty with the methods you described. Are they gonna type out A, H, F, blah, blah, blah, or whereas if they're in Drupal, they can just use link it or some other tool to easily link things up. So I guess my feeling is the content shouldn't be completely abstracted from the presentation because for example in one of the sessions yesterday, they talked a lot about proper use of headings, bullets, links, and so on to make your content really usable and really legible. So I guess these are the questions I'm struggling with recent about your thoughts. Right, so I'm not totally certain I understand your comment about links or about sort of exposing the markup to the user. Are you saying that you want them to see the markup or you want them to? No, but if they were, I guess if they were working collaboratively on their content in one of these apps you described, how would they put in their H2s? How would they put in links? How would they put in bullets in the content as they're working on it? Ultimately they have to, our clients who are very non-technical would have to be in Drupal to do those things. Right, right, right. So that's a really important question and I think that when you get into the body field, and you are creating content that is already essentially marked up in HTML, all of the sort of filters and all of the kind of, access to all of that stuff is gonna need to be there regardless of whether you're on the client side or on your Drupal site. But you can't not have that. You can't just have it sort of plain text and then once it gets up to Drupal, then that's where it gets formatted. That's essentially the same problem that I talked about before. The formatting tools, the WYSIWYG tools have to be there on the client side just as they are now in Drupal 8. But we just have to have an ability to transfer that information, to sync that information back to Drupal. We would need to if you used a client side system. I see, so you're suggesting make sure that let's say they're using Evernote that every piece of formatting that they do in Evernote would translate directly to HTML? Ideally, yeah. Okay, yeah. How? I mean that's maybe I- So what I'm talking about is that we need to work on figuring out ways that we can extend things like the Drupal content creation app that I showed you, and also build modules, build things that extend Drupal to kind of cope with these issues. Work on ways that we can stage and preview content and ways that we can remove steps from this process as contrib in Drupal right now. I mean, the solutions for your content authors right now we've gone a long way to solving those. So if you get, for instance, are you mainly working with Drupal 7 sites? Yes. So are you using the new versions of CK Editor and are you using Edit Module? Are you using those kind of tools? Yeah, yeah. So it's not so much the Drupal setup that I'm concerned about. That part's fine. It's that when dealing with these very non-technical clients and getting them, like I'm always trying to figure out what's the best way to shepherd them through the content creation and import process. And so, for example, I would see the kinds of clients we're working with, I would see them much, much less likely to be entering content on an app, on a mobile device. I'd see them more likely to plug in a bunch of stuff into a big Excel spreadsheet and then import that into Drupal. That would actually be a lot handier for them. You know what I mean? Because especially if, let's say it's, let's say we're not even talking about the body field. It's just filling out all the different fields for each kind of content type. They'd be happier just filling in an Excel spreadsheet and then going from there. It's interesting that you bring up this thing about an Excel spreadsheet though because one of the things that I think that we have not dealt with efficiently yet in AID, which I would love to see somebody actually start working on a module for this, is tables in the body field, right? So, Google has dealt with this really quite neatly so far. From what I've seen, you know, when you have a table of data in your body field, you should be able to bring the data in and display it as a table in the body field. But in fact, what often happens is exactly what you just said. A spreadsheet gets sort of copied and pasted, all of the rows and columns, and it's not linked to the data anymore. It's removed from the data. So, that's something that we really need to think about, if it's data, it should still be data. It should retain its integrity. Yeah, you know, that's really interesting because I just had a conversation with a prospective client who has a Drupal site already, and they did this, and I'm really hoping we get a chance to work with them to see, I think they wrote a custom module that did it. So, it has a huge table of technical information on their products within the body field, but it's still linked up to the database. So, I'll give you my card and if I find out anything more about it. That would be awesome. Yeah, thank you. Cool, thank you. Hi, this is not a Drupal question, but I'm an avid user of Swipe Keyboard, and I was very intrigued by your circular or hexagonal prototype or mockup that you presented for the Swipe Keyboard. Is that something that you designed or? It is, actually. Is that something you've taken further than just a picture? Not yet. Okay, too bad. There's a lot of solutions out there, though, actually that are going in that direction. So there's, for instance, there's one that has a kind of a square set up, and it's not exactly Swipe. It uses a sort of a flick where you start from the middle and then flick out towards the letter that you want. But it does this, yeah. Sort of a radial approach. Right, exactly. But it does the same thing of grouping the most commonly used letters in the center. So there's a few solutions out there, but this is all very much in flux, and we're sort of in a very innovative, evolutionary phase of input, I think. If it were possible for me to use Swipe for all of my input on any device, I would do that all the time. I love it, so I'm excited about the future of that sort of touch text input. Yeah, cool. Thanks. Thank you. Well, this isn't really a question. It's more kind of a what if since we're being all futuristic or in everything, right? I tend to be pretty futuristic. That's kind of what I do. To me, the most simplest, the closest you could get to the input to the user would be to sit and watch them as they type. So something sitting in the client side, recording every single thing you're typing, and then computer learning being able to say, hey, do you want to put this on your website? Do you want to email this? And then being able to do that. And being able to let the computer try and figure out and suggest from what it's learned from, like you were talking about your past behaviors, where does this go? Because really the ideal experience is to type once. Right. And then just tell it where to go or have it even suggest where to go from there. Yeah, and I think we are, one of the great things about Drupal is that it is very dry in terms of content. If you write something, right, you can reuse that thing in a view any number of times or put, you can take that exact same field and repurpose it in any number of different ways and push it out via multi-channel to JSON or whatever, XML to any other kind of device. So you're not really, you're not repeating yourself. You're not writing the same thing over and over again in many, many different places. And I think that we have that really over any other system. But I think what you say is really absolutely true. That we need to sort of get closer to the end user, to the person who's actually creating content. Yeah, because how many times do my users, they type things in Word documents first. And then like you're saying, they're copying and pasting or they're copying it, they're putting it in email and then they're copying and pasting it. If you could have something that just sat and watched and said, oh, she just scheduled an event at such and such date. Hey, do you want to put this on the website? And then figure that out. Well, that goes to the semantic stuff as well because if you're talking about an event which is a kind of an entity, it's like there's a schema.org entity event. And if you're structuring your content types in that way, then something that is an event should automatically be, if you have the content strategy structured correctly, be getting pushed into the right place so that anybody who wants to discover that event can find it. So knowing that somebody's about to create an event, something that's an event is another sort of predictive analytics kind of problem, but it's definitely interesting. Thank you. All right. Did I, do you have one more question? Can you go back to the slide about the client side authoring? The pros and cons, sorry. Oh, this one? Hold on, one sec. One for the client side one, I guess. Right. So, yeah, I think that a lot of this is like, because it's very speculative and sort of, and forward looking, knowing what the proper technical solution is, is tricky, but I'd love to hear any thoughts you had on that. Yeah, so you kind of talk about all the content being in one place in a single authoring environment. And I guess kind of where my mind went was, you're likely gonna be on multiple devices. So I'm in an airport, I'm authoring on my phone, I get to my hotel, I pull up my laptop, things like that. And so, there's still an element of local, but it's almost kind of a distributed approach in that you need to sync those devices so that, you know, all your content. So it's like, what you want is you want a multi, you want a multi-device approach, like an Evernote kind of a thing. Where you have the same application, right? Available to you in multiple devices that then syncs back to your content hub, right? So that, you know, everything is getting added back, maybe lazily in the background, right? But you have access to it wherever you are. So like you said, if you're on your phone, it's going, you know, you're making notes, then later on, when you get home, you open it up on your tablet or your laptop or whatever. And then you go into it in more depth and detail, but it's the same app that's following you around. I mean, I think that's really what needs to happen. Right, and I think that also maybe helps to address a little bit of those collaborative problems as well. If you can start syncing to other people's devices, similar content, you potentially address some of those. I think the other interesting thing is syncing about the format of the content that's coming into that central location. So if I can support multiple formats, whether it be HTML, whether it be Markdown, et cetera, translate that into some pure canonical type form, it's almost multi-channel input as well that you can then translate into multi-channel output. So that was just some things that were running. Well, so that fire pad that you were looking at a minute ago, that supports Markdown. So, and it also is, you know, it's restful. So, you know, it's a question of getting the APIs to make sure that you can communicate with those, or integrations so that those things can communicate with Drupal. Right, you know. So, right, right. Well, and it may not be, it may be translating other things into HTML, so just kind of decide, what is that central format that you wanna be able to translate things to that you can then translate from as well? I mean, I think the use case of Markdown, the reason why people use Markdown is because, as far as I understand, is because it's a rapid, it's like a shorthand HTML, really. It's like I can do it quickly, you know, with some quick keyboard commands and get something that's a lot more sort of lightweight and simple than having to go in and laboriously write all of my tags. So, you know, it essentially can be translated right into HTML, so it's, I think, you know, I think it's not any less semantic. I could be wrong on that, but I believe that Markdown is not less semantic than HTML, so. So anyway, thank you all for coming along, and again, go to Jeff's WYSIWYG session as well, because that's gonna cover very many of the sort of content strategy and semantic issues that I didn't talk about. I'm gonna be there as well, so thanks a lot.