 Alrighty, so thank you so much for coming to our session. This is Lessons in Spark UX, prototype user test and iterates. If you're looking for the LAN party, it might be in here, if you're not paying attention, but it's not good. This is Lessons in Spark UX. So just to get started here, just a brief outline of what we're going to talk about. We'd like to start off with a little bit of a description of who Spark is as a team. I know that many of you may have seen Spark sort of in the Drupal Sphere without really seeing the faces behind it. We're going to talk a little bit about the vision of Spark and what Spark is meant to encompass. We're going to talk about our design and UX processes as well as speech-to-focus design and testing. We'll talk about some key takeaways from our approach in Spark and we'll talk a little bit about how you can get involved. Just as a disclaimer to practice the session, this is going to be a conversation about our processes and about the testing and prototyping, not about the features themselves. So we will not be talking about sort of what the vision of Spark is missing or things of that nature. We'll be talking totally about our product process and things of that nature. My name is Preston Sok. I am a prototype developer at Acquia. I'm also the prototype lead for Spark. I co-founded the startup Colorado user group in Colorado and I'm actually a part-time employee at Acquia. I'm a full-time college student right now. So I just wanted to say that that photo looks like he's 12 right now. I kept telling him that he should change his photo. He didn't want to do that. Anyway, my name is Hermes Mistry. I'm a UX researcher at Acquia. I'm also heavily involved in the very interested and excited for Drupal 8. My other appreciate of that can speak English. The other things that I'm involved in is user experience professional association in Boston and a board of directors there. For instance, like Boston Design Jam, designed for Drupal last year, and also the UX UI Summit at Bad Can. Really passionate about open source and user experience design and that's what I do. I went to Bentley University to get my master's in user experience research and my other hobbies include eating desserts. So how many people here have already tried out Spark? How many people have used Spark? I looked at it a little bit, downloaded it. So we've got a lot of people who are new to Spark. What you might not know about Spark is that we have a very large team of people who are working behind the scenes to make Spark possible. And as you can see up here, we have a pretty large team. I think a few of them are here in the audience. We have a really great team starting with... So how many of you are here in the audience who is our design lead? Put your hand up in the other faces in the Drupal sphere here as well. So what is Spark's vision? Last year at Drupal Con, Denver during his state of Drupal presentation, Dries actually mentioned the potential for Spark to become sort of the press flow of content authoring in Drupal. It's meant to improve the experience all across the board in Drupal for content authors and inside others as well. So what are some of the goals that we're hoping to achieve with Spark? Well, the first thing is that, you know, as always, not all goals can be met. So we put together a North Star vision which is sort of our guiding light but not necessarily sort of the ultimate end result. Because obviously there are a lot of things that are in flux and that change throughout. So what is the part of this North Star vision? We have in-line editing which I'm sure many of you have heard about. We have a drag and drop content layout tool. And we have enhanced content creation all across the board. Every one of our edit pages and so on so forth. But those things have all been approved very, very drastically. We also hope to include some useful dashboards for content creators. And the most important, I think, you know, based on the theme of the Drupal last year is mobile content offering and responsive support for working within the administrative interface. So Spark actually began as a collection of contributed modules that were intended to be part of Drupal 7. And then eventually we shifted our focus to over to enhancing existing features in core and adding these contributed modules into core for Drupal 8. And so again, you know, that list, you know, does take into account what we hope to accomplish but not necessarily what we will accomplish in the end. So what are some of the user experience goals of Spark? These are sort of the goals that we hope to accomplish during our time with Spark. The first thing is to improve these experience of all content creation. And that means that all interaction patterns, all workflows, need to make sense to any lady user. We also wanted to simplify saving and versioning tasks because that's often something that I did very first introduction to Drupal while still distinguishing the operations. And then we also wanted to include toolbar and dashboard that force limited clicks. One of the biggest complaints about the way that, you know, the SCM access out of the box is that it's very difficult to access certain areas of the administration. And of course, full mobile UX support including touch support and so on and so forth. In addition, you know, just as important as you experience is the accessibility front, which is, you know, including basically a sort of fallback for all people who, you know, need extra resources. So that includes edit in place, you know, need to be fully accessible with full timing interaction, accessible UIs all across the board and an oral interface actually, which was spoken about I think a few days ago that sort of guides users through the changes that have occurred on the page when they are 100% obvious with about the traditional process and how we modify that process to fit our constraints and what we wanted to achieve. A traditional process goes like a waterfall way where we identify a problem and we design it, we prototype it, we test it and we develop it. In a lot of these cases what's kind of also happened is that we are going to probably skip the prototype and test and just go from design to develop. But I think in a lot of these organizations now we are seeing, especially in mature organizations where the value user experience design is that we go through the process of usability testing as well as a key point to validate your design before you put it out in front of your art. What is important, what happens in an ideal waterfall traditional model is that you're going to do an internal review at every step during this process but also considering that we work with the Drupal community we want to review that process through issue queues and understand that we're getting the community sure that we are not missing anything and also trying to prove. So the way we modify the process is kind of a difficult diagram to grasp but the idea is it's the more of a cyclical process and the process never ends. We always identify a problem. So for example, when we start talking about content creation over the period of my time at art, we have talked to a lot of enterprise customers, a lot of S&P customers and understanding the pain that they have with content creation because site builders, they are different audience. The one who are actually writing the content is a different audience. We need to make sure that if we want to move in the right market trend direction we have to accommodate the need of those content creators. So we identify that that is the problem. Then we are going to sketch the problem. We're going to prototype the problem. We are going to test the problem and then develop it and then it kind of goes through all the process. What's interesting is that at any point during this cycle it might be a sketch step or it might be a prototype or test we'll come across as like, hey this is not really working well. I think this is missing that or it's not going back to the goals that we started with. So we again go back to the identifying the problem, try to sketch it again, try to go through this process again and again and again till we come to a point that we all agree that it's right. The same happens at testing. So when we are testing, sometimes we are testing for interaction patterns, sometimes we are testing for, we do a lot of contextual inquiries to understand is that how is the mental model working with the prototype? Is it working in sync or it's going against the model? So we'll show you some examples of some things that we did well, some things that didn't go well. And of course throughout this process we are going to go through the internal review process and also the process of engaging with the community. The other dimension that is interesting in this part is the point of where we start with the design and where we want to go with the design. So as Professor mentioned earlier, the north star is like the guiding light, that's where we want to be at. It's not necessarily the end goal of the process and what is happening is that we kind of have to, I don't want to say the word compromise but we have to settle for an actionable design and that actionable design comes from a lot of constraints that we are bound with that could be the other point of view or the time limitations or the code 3's deadline, what we want to do if we want to include that in Drupal Core. And this actionable design step is actually, it's not necessarily going towards north star always. Sometimes what happens is that we are moving with the initial design, we come to an actionable design, we close it to the north star design, we come across it although we have to go back, go back a few steps and then we see that we have to make this balance and come to an actionable design. The two important things on this slide are the way we did our prototyping and usability testing is through InVision and high fidelity prototypes. By that what I mean is that InVision is an app which sort of allows you to stitch together a few images and then there are hotspots so you can click through them and then it provides sort of a pseudo-experience of what that prototype would be. The pros and cons of each of these processes is that prototypes are possible to talk in a bit but I'm also going to show you what is an InVision app prototype and how does that look like. The other prototype that we do is a hyperactive prototype it's really doing all the jazzy technical things that I don't really understand but it provides a rich interaction and interaction that is true when it's going to be just pieces that two dimensions that I spoke about earlier they all work in Agile as the way we do it at Acquia. Agile, I feel familiar with it, it comes with its pros and cons. The pros is that it is a month-long iterated process. We are continuously iterating as we move on. One of the interesting things about Spark is that the design is changed so rapidly it's like if you miss a day it's like, whoa, whoa, whoa, what happened? Did this design change? Because we are going through that process of identifying problems every step. So anyone in the design team or anyone involved in the Spark team can say, hey, there is a problem, let's stop it, let's go back to the process of identifying it, sketching it again. So that's one of the advantages of Agile and of course the bottleneck that it introduces is another problem with it. The good point of Agile is also that it enhances for usability researchers like me is that it enhances the flow of doing usability testing. The way we do usability testing for Spark has been it evolves from running sessions which would probably take two or three days to running sessions in four hours and getting the results out so that we can iterate it faster. Community feedback, we always provide, I always provide reports to the other issue queues and tell them these were the issues that were found. We can always just do Spark and then you know, associate it with that. I just want to talk a little bit more about the disadvantages in terms of the constrained team that we have, so he's a part-time employee at Agile. I'm a centralized usability resource so I don't get to spend all my time on Spark and in that case what happens is that since this process is moving so fast it becomes really difficult to keep up with it and when you have to make sure that the communication is optimum it's always totally documented in one way or the other to make sure that everyone is on the same page. A person could talk a little bit more about what it means to prototype in the Envision app and in the Heighted LTE version of it. So the two approaches that we take to prototyping are really quite contrastive. In Envision app, you know, we have a set of pros and cons that really are good for quick turnaround. If we want to produce a prototype that's going to be testable within a day, within a few hours Envision is really the most optimal choice because obviously because I'm a part-timer it's difficult for me to really code something out very quickly that can be tested. And the good thing about Envision is that you can actually directly put in and insert the mock-ups that haven't produced. So any of the things that were produced in the design are replicated pretty much exactly. Additional feature of Envision, which is one that we've used to quite a big extent, is in prototype commenting where you can actually go in and click on an area which produces a focus in an app singular point. Unfortunately, the biggest problem with Envision and the biggest weakness that we have to face is that there is no possibility of complex interactions. We really can't do anything such as focusing, hovering, anything of that nature, any sort of dragging and dropping. All of those things really cannot take place in Envision because it is sort of an image-based. Additionally, the prototypes are not based on code, which means that this adds an additional layer of sort of setback of a latency to the process in which we have a prototype, but none of that prototype is reflected in code, which means that we still have to go through the coding process in order to produce anything. And one final weakness of Envision that we have found is that there is a great deal of confusion that we've encountered with testing. Because of the simplicity of the interface and because of how sort of straightforward the workflow is in any Envision process, it doesn't really sort of work out so she should display a vast array of complexity. That really is sort of the key element of... On the other hand, high-fidelity prototyping, which is sort of my primary area of expertise, relies on these complex interactions. It relies on cover, it relies on active, of autofocus of that nature, of entities of that nature to really display how these interactions are playing out, to display how the UI is going to eventually take shape. And once again, because of the fact that Envision is solely image-based, there is no code. And with high-fidelity prototyping, what we can do is we can put together a code that even at its current state might even be ready for development. It might even be ready just to put straight into form. And we actually had one episode of that where a little bit of the code that I had written was just pretty much work-for-work place in the court. Pull in browser testing environment, which means that there's none of this sort of extra fluff around the page. There's no commenting. Basically, any time that you test something in Chrome, you want to have a very clean testing environment, a very pure testing environment that people are going to use as a sort of default tool as opposed to something that displays hotspots as Envision does or guides you through the process. Unfortunately, the method of prototyping that we've adopted does produce a slower turnaround. It's a lot easier to sort of drag and drop pictures into a grid as opposed to typing out a hundred-fold code in one day. Another big problem is that because of the fact that we need to produce things very quickly and achieve high-fidelity, sometimes the interactions really have to be sort of magic. We can't really have the full breadth of possibilities because of the fact that we are so time-consuming. And what that does mean is that something doesn't work, but honestly, in the code, it doesn't really work that same way. It's just sort of magic. It's just sort of prototypes are not necessarily based on design mock-ups of 100%. Sometimes there are limitations. Sometimes there are problems that need to be addressed immediately that sort of preclude the prototypes being 100% accurate to the mock-ups. And we address those pretty much every step of the process. Another thing I want to talk about the other slide is in terms of what it means to... It's like, how do you, if you're a usability researcher, it's like, when do you want to test something with InVision app or something? When do you want to do a high-fidelity code write? It always comes back to the question of what is that we are trying to accomplish with this code write testing? And a lot of times, or rather, should I say, most of the times I always go to the lead designer and tell it what is the goal, and then we talk about it, is that it is the goal of it to just go through the workflow and verify and validate the workflow, or is it also to understand the subtleties of every interaction that is necessary to complete the workflow and understanding of the user? So that's just one of the interesting things about using. So one of the most important findings that we found sort of through vetting our process and then the evolution of the process was that sort of phenomenon known as designing the browser was really sort of revolutionary for our process. One of the things that we discovered was that overly rigid sort of linear process really didn't work out the way that we had hoped. And traditional processes are sort of overly rigid because you take a product, you have an input, and you do something to it, and you pass it on as output, and there's no sort of collaborative process in that. There's very little opportunity to sort of come together and say, well, this is the approach that we should take. One of the best things, obviously, about traditional rigid approach is that you can pay very close attention to the details, and oftentimes design attributes are very easy to substitute when you iterate on the design. But the issue with that is that there's somewhat of a slow turnaround. Prototyping is sort of not even later in the process and plays even later in the process. And interactions, obviously, as we've mentioned, those things are very difficult to commit to the design and display in the design. So one of the things that we came up with was, you know, in my prototyping processes, as I was coding, there were oftentimes instances where we discovered an issue in the design or an issue that was typical that really needed a new design solution. And what that meant is that, you know, the designer and the prototyper really forged a partnership at this stage to fix any of these technical issues, if possible, in an in-browser context. So anything that is sort of faulty can be immediately rectified within the browser just with a few changes in the code. And these sorts of things are meant to be collaborative. It's meant to be part of this typical process that isn't necessarily devoted solely to iteration, but also to this sort of collaborative approach. And so what's really great about this is there's a very fast turnaround. Anything, any changes that are made are immediately implemented. And any interactions that do change can be sort of as a collaborative process placed into the design as neatly. Of course, the weaknesses are that, you know, there's a little bit less attention to detail. Sometimes the design that was initially finalized might not be followed 100%. Oftentimes, simple changes to attributes such as color or simple type of graphical changes might need to be a little bit more extensively done. So as a result, our sort of new, modified process entails at the prototyping stage, including a design of browsers part of it, which is sort of hand-in-hand with the prototyping stage. So that was about the overall processes that we followed in order to make sure that we are at inching towards the right goal that we want to be aiming at. What we're going to do in the next part is that we're going to focus on a few features, focus design, and test by that. What I mean, we're going to talk about the problem space, the solution, the technical design constraints, and the UX issues that came along with it. As you would go through these slides, you will realize that some of these things have been implemented in Spark, some of these have not been implemented in Spark, and some of them have just been installed for the moment for various reasons and constraints that we'll talk about. So what are the problems space that the biggest concerns who are trying to address is that users do not know the context of what they are editing. So previewing content or editing content has been a big pain point in Trukel for a very long time. You don't see the content. What also happens is that the new user is going to, it takes too much effort to that specific content, may changes to that content, especially if it's like a small typo, also the content listing pages, and let's say it's less than optimal right now in terms of experience. So those kind of things kind of exaggerate the problem area right now, what we have. Also, when you go on the content creation page for content editing, there is a lot of, may want, may not want. So thinking about this problem space, what we thought is that what we want to do is, in order to improve the content offering experience, is introduce something like in-line editing. Not showing it properly, but what is, this is an envision app. That's where I was talking about. So it's a bunch of emulators that are stitched together with hotspots. And the way it works is that you cannot be done holler basically for main services. An envision prototype, so this is what we tested. And this is what we have right now. So that was the in-line editing that we were talking about. And this process, what I think is also important to talk about what happens to save and publish, because over the period of time, when doing research for Google Gardens, we found that save and publish is really, and it's a very interesting problem that you trace with save and publish is because the experienced people and users understand what is save and publish. But what the new users are coming from different CMSs, they do not understand what is save. Does save publish? Does save not publish? So we also wanted to make sure that as we are going through this process of in-line editing, we make sure that you are absolutely sure what you're doing. If you are editing that content, and if you're getting that save or that publish, what is that going to do? So that has been one big problem that we are trying to solve. Of course, it's still working on the solution, but basically, that's the agenda. So one of the other things that we decided to approach was sort of how do we let users know which areas of the site, which areas of the page are actually able to be edited. And one of the initial approaches that we took was sort of a three-second stage setting transition where every single editable field was sort of highlighted with a blue water and then faded out. Now, one of the biggest problems that we discovered with this, though, is that it's a very fleeting affordance. It doesn't really make much sense to sort of display it only one time and allow you to sort of figure out what's going on later on. So in this case, the edit-on-set prototype that I put together didn't really yield the best results because, first of all, the affordances need to be persistent in the sense that users need to know exactly what fields can be edited. And also, the sort of accessible component, which is that those sorts of transitions are very accessible and can't be iterative testing on in-line editing. And I'm just going to go through the latest results that came from that study in April. One of the in-line editing had received overwhelmingly positive response from the users, and you can read some of the codes which tells that how it is a delightful experience to do something like that. And that's something that they did not expect people to do. However, there are some issues that we still need to work on. We need to still really identify and flush out the same versus publish. What happens is that, as I was talking about the three-step process from initial design to actionable design to a non-start design, is that when we started adding revisions to it, it became complicated as to what does that mean? Is that, is it the revision going to save in terms of where field is it going to be collapsed together, where are my final revisions, how does that interact with save and publish? So it's a classic example of how you add another feature and then everything kind of, you have to make changes to it in order to accommodate that the experience is still very solid. So revision is still something that we want to flush out in the near future, but the bigger problem was save versus publish and also the transitions that we had were too subtle. I would say the transitions being too subtle is more of a minor usability problem because that is something that you're going to learn over the period of time more about what's happening with this. It's also, it's not really a roadblocker from completing the task but it is just an enhancer to understand. The other thing that we had was the unsafe changes. So in the prototype, what would happen is that if you make some changes to your content, it will give you a sign and say two, three and say, people understood that these things, these are the number of changes that I've made but what happened with the prototype that it could not tell you that what those changes were. So people are like, okay, that's great that you're telling me that I've made three changes but it kind of does not really help me if you're not telling me what those changes are because I have these seven fields in my content type and it's just not effective for my use case. So that was just about the inline editing. The other thing that we wanted to solve with Spark is the notion of the tool bar. The tool bar is the glue that connects everything together. It is besides the terminology problems that we have with people understanding the mental models with blocks and views, this is what it is actually going to bring everything together. And since 2011, I've done a lot of usability studies understanding the problems with the Drupal 7 tool bar and the biggest problem with the tool bar is that it's too busy, it's too convoluted. Even a lot of experienced users, you will see that it's like, oh, is that insightful? Is that inconvenient? Where is what you don't remember? There are a lot of these options. You'll see that a lot of these people, what they do is that they just even don't bother going to the U to the tool bar. They just want to put the URLs and move forward. So what we want to do with this approach and with this problem is that we want to make sure that we are at least helping just a little bit, just a little bit more to the new user to make the learning curve because it's also unresponsive. So what we try doing it, the thing about this tool bar is that it goes horizontal and vertical. It is what it's trying to do is that it's supposed to help the new user get into where they need to, but it's at the same time also telling the established user that we are not going to compromise on your efficiency if you have to use this tool bar. One of the things that I want to mention about the tool bar is I still think that we still need to work on the information architecture. What we have right now is very much similar to Google 7 and we know that there are a lot of issues with the IA so that's something that we want to figure out. So when we did the usability testing on the tool bar and what we did is a comparative usability study. By that, what I mean is that we show, let's say there are eight participants and we show four participants a new tool bar and then we show the current tool bar and then we kind of flip the order so that there is no bias to the viewing order in which how people think. And we found that people had positive response to the tool bar. They thought it was clean. It had nice icons. It was usually appealing, but they had some trouble discovering a few things. So the drop down arrow which kind of eliminates page refresh was not very clear. It was too small. They did not know that that would, in its problems, discovering how to do. Oh, I did not know. I could move the tool bar from horizontal to vertical, vertical to horizontal. So that was an icon problem that we needed to fix. The edit shortcut, people were not sure how to do that. It was a good feature in these seven. So how many people here have experience with WYSIWYG in Drupal and all of the props associated with it? Yeah, right. Lots and lots of issues with WYSIWYG Drupal. Well, you know, one of the approaches that we took, you know, a little while ago, we actually decided to adopt CK Editor as the core WYSIWYG platform for Drupal. And part of the reason for that is not only to simplify the ridiculous complexity of WYSIWYG in Drupal, but also to cater to mobile users a little bit as well. They're doing a lot of good work over there on the team with approaches to mobile and approaches to non-bestop devices. The current problem with WYSIWYG in, for example, in 7 is that WYSIWYG really does not cater to mobile users as the needed context. And, you know, if you're a mobile user and you're going into a page to make one change, let's say you want to boldface a word or you want to add a small link or something like that, that's very, very difficult to do on a mobile device, even though it should be something that, you know, really shouldn't be easy, especially with our new focus on mobile-oriented administration. There are too many small buttons. The affordances aren't there. There's, you know, you really just can't, you know. For me, I have, you know, I have kind of big hands and I really just can't, you know, touch those buttons sometimes. So the solution that we came up with was a mobile WYSIWYG solution that adopted CK Editor and had some envelopes on it to really improve the platform itself. Right now, this is quite a state of flux. There's a lot of discussion going on about this right now. But if I just switch over, I can show you very quickly one of our prototypes here. You'll notice here is that it's, we have, we simplified the number of buttons. We simplified the number of buttons in the prototype and we also made it so that whenever you scroll on a mobile device, the toolbar actually sticks with the content. So you don't have to, you know, because one of the biggest problems with editing any sort of page on a mobile device is that you have to scroll all of it down to try to find buttons again and so on and so forth. So this actually makes the process a lot easier. So this prototype is currently not implemented. It did sort of yield a lot of important considerations that have actually made their way into port. And this is sort of part of that overarching theme of, well, you know, even though we haven't reached the North Star design for this process, we haven't reached a vision that can be sort of applicable to a variety of different environments. And so one of the biggest to make sure was that, you know, mobile affordances need to be there. But they also need to make sure that loading time is not extended as a result. Don't mention the talk a little bit about some of the useful results that we've got. I think for the last few use cases I was telling you about how everything tested positively. So now I'm going to say something that didn't test positively. One of the research that we did with usability testing with the mobile receiving is kind of a very complex problem that we are trying to solve here, is understanding the three big problems with it. One is the user behavior, the iOS behavior, and the prototype behavior. So the user behavior was very, they were very rigid about making changes. They wanted to not make any changes to their content. More research and more contextual inquiries with a bigger sample size to see how that affects what we are trying to achieve. The other problem was the iOS behavior. So what happens is that iOS has its own behavior functionalities like select and copy. And when we're trying to use it with the visibility, it just kind of blocks and overlay kind of thing and then it becomes way that we're going to make those changes. So that was another problem that kind of resulted in this negative experience. And of course there were some prototype changes that we had to make because it's high fidelity but it's still not there. So people sometimes get confused as to what is above and what is actually a problem with the prototype. So we, also because there was some design, I wouldn't say I would say time constraints and understanding that what we want to achieve and where we want to go, we did not take this design to the next level at least for now. So ultimately the results from that weren't 100% positive but they did actually yield a very good aspect sort of icons in general that we had incorporated to a great extent in core and that's icon fonts which is a way to produce icons in a semantic, accessible way that doesn't require you to have a new image in certain, basically what it encompasses is a custom font is created with a bunch of SVGs of all these icons and they're put together into a sprite and that's the use of the font. So this code on the right side that you see here is part, this code actually taken directly from the high fidelity and it's not the sort of end-all, be-all code but it does sort of show you a little bit of how easily we can manipulate the icons and basically any sort of character entity here can be replaced and this is actually part of extending the code. We can actually take an icon and insert as part of the font and this actually is an approach that's been used by several other applications but we've adopted it for a toolbar in addition to Articles to Bob. So as you can see just a little bit more code here. We take a custom app font face rule and we insert what we call Spark icons which is sort of the overarching font that encompasses all of the icons that we use in the CSS is that we use CSS content to actually insert the attribute back into the page flow and make it readable as content. Grab image with no text and it doesn't require what's already sort of the main aspect of the administrative interface that we want to address as a dashboard and one of the biggest problems that New User is coming to Drupal really don't understand how the dashboard works. The dashboard in its current state is sort of this aim-worthiness box area where you can insert different sort of columns which have loads of content and what have you but a new user is really going to want a more useful dashboard that is really geared toward their personal needs. And so our solution was a responsive dashboard because as part of this global approach we do want to be, you know, so what you see up on the screen behind me is on the left side you see sort of a desktop version of the dashboard that we initially created and then the mobile version on the right side. As you can see you've got four very simple icons that are very simple and very direct for content creators who can instantly access any sort of task that they might need to create without really knowing any of the jargon. As you can see there are icons up there which were implemented using icon fonts once again. And so, you know, one of the really great things about icon fonts is that you can actually use CSS to change some of these applied text shadow, applied backgrounds, but CSS to change how the icons actually look and that's because they're being displayed as text and not as images. And so this was a very sort of important part of our prototype process that yielded a very big result that was approachable to a variety of different aspects of approval. And we actually, you know, put this sort of form on. The thing that I do want to talk about is the problem space for me for response to Bayard really. We thought that we, what we don't allow our users right now is what is happening with the current market trends. The ability to create these layouts and breakpoints for tablets, for mobiles, for desktops, whatever you want to do. You want to give that flexibility to the user which we don't currently provide in a very simple, cheap, gooey fashion. So the way we wanted to do this is to the breakpoint editor and I'm going to very quickly show you just an image of what it does. And what it does is that you can create, add a breakpoint to it. You can also minimize and maximize the pixel sizes of it. Just in the interest of time I'm going to rush through this. But one of the interesting things that we found from this process is that it is trying to do too many, from the user experience testing that we found is that it's trying to do too many things at the same time. And it kind of confuses or it goes against the mental model of the user. So what happens is that when you actually create an added breakpoint, you would expect that, let's say if I hit that add breakpoint here, I would expect that the new breakpoint would be between phone and tablet. But what it was doing is was it was creating a breakpoint between tablet and standard which was against the mental model of the user. So we wanted to make sure that in the next portion of the design fix that mental model design changes. The other also problem is that you had to move the add breakpoint to the standard or to phone in order to make changes to the mid-mass. So we want to make sure that we provide... How do I say it? It's trying to do too many things at the same time and especially because this is a new concept, the users took a while to really understand what was going on. So very quickly, we just wanted to go through some key highlights as to what all this means to us and how the community at large. One of the key things that we've learned so far is that we have to work with what we've got. We are all trying to be perfectionists in our fields and it's not always ideal to be perfectionists. In resources, you have to balance your time constraints. So this is probably... It took me a while to really like, no, we don't want to do this. We need to get it better. We need to get it better. But it's like, no, we don't have time to do it. One other key highlight that we sort of found was that prototyping and iterating upon design was very important from a early stage and even actually our process as well because oftentimes we had to sort of follow our process to really yield the best results. And so trying to repeat a repetition is still very, very useful. But sometimes you do need to move ahead and as Dharma said, iterating constantly and trying to achieve a sort of paradigm of perfection is not going to really work in a very timely string context. And so one of the approaches that really sort of functions well for this is the design of the browser. A collaborative process between the designer and prototyper yields really good results because it doesn't require the iteration that really delays the project and it actually moves it ahead and brings the project to the coding stage which is really key. Another very important takeaway is that sometimes you have to leave the typical context to make it better. And this is something that we came across time and time and time again is that first of all, trying to prototype in Drupal is one of the hardest things in the world. Trying to implement some sort of a new feature you might as well be developing on Drupal and with this sort of extensively modified functionality, for example, with the breakpoint standard that was entirely high fidelity. That was entirely outside of Drupal because it simply had to be. There was no way to really easily do that. And raw HTML and CSS is really advantageous for Kina Markup. It's much more easily. So one of the other problems is that a big component of the aspect of design in Drupal is that it's very based on precedent. We have a lot of precedents that have been established since 4.7, since 5, that really have stuck in Drupal and haven't really left. And so what we really strove to do in this process is to excise ourselves, is to extrapolate ourselves out of this paradigm, out of this paradigmatic approach that Drupal has already expressed. Because oftentimes in our current context, the responsive context, the mobile context, these paradigms really just break down entirely. And so by taking away our preconceived notions of what this ought to be because of the fact that there was this way in 5, there was this way in 6, we decided, well, we need to completely remove ourselves from the Drupal context and say, what is it that actually needs to remain? What is it that housed the structure? A few other key highlights, I think, is something that we need to learn. I think there is some room for us to think about is that this is a really good model for, of course, it needs some changes of all the period of time, but it's for open-source projects. I think we've done a fairly good job of engaging communities or that we are doing the right thing. To the point is also that engaging the community is hugely beneficial. Can we come up? We have so many times that we haven't discovered issues that the community members have told us like, oh, what about this use case? What about that use case? And that really helps us to make this thing better for everyone. I would want to say that there is still a lot of room for what we have right now, that Habitat does not give you enough use because it's more of a developer-focused workflow and not so much of the design issue focused to workflow. So that's something that we want to talk about is how to get involved in the project. So for those of you, I know that many of you have not tried out Spark, but I invite you to try out Spark. We invite you to look at some of these new features that we've tried to implement. And the best way to get involved in Spark is really to go through the issue cues and look at some of these really, really defacious discussions going on about the future of Spark and the future of the way cost-mediting will work in approval. So we invite you to go to the project page and look at some of the issues that are there. It's a very, very well-curated cue that has sort of mountains of issues that are really useful. And we're hoping that in the context of the problems that we face, we're hoping to find a little bit more improvement in the issues cues for design-related issues as opposed to development-related issues because one of the biggest problems that we face is that design-focused problems are not being addressed in a very intuitive way in the issue cue because the issue cue is so focused. So we'd like to thank all of you for coming to our session. We'd also like to thank all of the key contributors to Spark, Lewis Hyman, Roy Shulton, oh yeah, Summers, excuse me, and all the other people that contributed countless hours to the issue cue, countless hours to making this project work the way that it has so far. And we thank you so much for coming to our session. We invite you to go to our session, tell us how we did, and feel free to get in touch with us with any questions, and we'll also take questions right now as well. So thank you so much. I was interested in what mobile use cases you had for Spark, like did you do personas and like specific people that were going to be editing on mobile and is on the iPad or tablet are you going to have the mobile experience because it's touch-based? Yeah, so we actually tested both. We didn't have the time to fit into our presentation, but we did test on the iPads and the iPhones. So when we, the person that we were trying to aim was the content editor, the marketing person. And one of the things that we tried doing is to really fasten the turnaround times. We had, we do a lot of in-house usability testing as well. So we would have someone from the marketing team who is like a project manager who needs to quickly edit content on aqueer.com. It's like, how would you do it? Why would you do it? When would you do it? So we focus on that use case. I want to say that the experience on the iPad was more, it was significantly better than the iPhone one, but it's also, that's something that we really need to understand. And I'm not sure at this point in time is that my personal problem is I'm not really 100% convinced that people do want to edit so much content on the mobile phone. On iPads, yes, but... And I work on a lot of international sites and a lot of research I've done. There are a large amount of people doing work on their mobile phones in different countries. So it just happens to be like what they have to access the websites, but there is one use case there. And then I had another question about, did you modify CK Editor like the JavaScripts, no? No, we just skimmed it. You just skimmed it, yeah. Okay, cool. Oh, can you disable the WYSIWYG? Can you just do plain text editing? Okay, cool. Thank you so much. I'm not sure if you've seen the yesterday's keynotes where Karen criticized the use of the WYSIWYG and inline editing. And I would just like to know what's your opinion about it if you accept the criticism and what can you do about it? Sure. So I think everyone who's on this party can contribute to this conversation. I think my personal viewpoint is that we, as a usability researcher, I love feedback and I appreciate the feedback. And as I mentioned earlier in the session, that this session is more about the focus of the process, not about why we did what we didn't necessarily. And I think there is a lot of room for discussion as to what we can do to make this a better experience for the content editors. That being said, I'm not either convinced entirely as to the criticism that we've got, but I think I'm having a lot of hallway conversations with people which kind of is helping me understand what we need to do to get this better and nailed down. Maybe we need to do something else. You don't know yet. These guys have just done some awesome work on the Spark project. But I do want to comment and yesterday, and I spoke about this in my own session in the community track a little while ago. And, you know, Wim and I went up and we spoke to Karen after her keynote. And we were really interested in hearing more because, you know, I think both of us and Russ and Darmech as well have really followed her work and been really excited about it. And we, I think we're really all on the same page in terms of giving the user an understanding of the different contexts that their content is going to appear in. And I think one of the things is that Karen wasn't really kind of clear on what we're really doing with in-place editing in Drupal, which is actually quite unique. Even going beyond what's in head right now where you're editing individual fields, the contextual experience that we give the user in the latest version of in-place editing that we're working on actually first shows the user that they're editing in Node. And then once they click inside the Node, atomizes out all of the fields into individual containers. So you're actually illustrating to the user that they're creating content in a structured way. So we're showing the user the structured content of Drupal in a very clear and unambiguous way in in-place editing that no other content management system is really doing. The one thing that we do still have to work on which you made a fair point about is that we need to give the users a much better understanding of how the content that they're editing in the desktop experience is not exactly going to be the same in the mobile experience. And they don't want it to be the same in the mobile experience by providing better affordances for divisions between teaser full content and things like that. So the push and pull between innovation, user experience, design and features, right? So we have to try to balance it out with everything in a very cohesive fashion. And it's always not easy. All right, I think we're out of time, but thank you so much for attending and we'll stick around just for a few minutes if you have any personal questions. Thank you so much.