 Alright, cool. So, full disclosure, I was a theater major in college, so this totally feels like undergrad right now, which is kind of nice, a little throwback as I'm getting a little older. So, nice to meet you. I'm glad to see a lot of people here who want to talk about prototyping. My name is Danny Norton, and it helps when you're presenting in front of a lot of people to turn the clicker on. Just a little bit of advice from me to you. My official title right now is a little influx. I'm actually finishing a master's degree at Bentley University in the Boston area of Massachusetts. So as part of that, I'm working part-time as a research associate at the Bentley User Experience Center. And we work with clients from Fortune 500 companies all around the world doing usability testing, design strategy, user research, all sorts of fun stuff. I also just started a position at a company called Patients Like Me in Cambridge, Massachusetts as the senior UX designer, where I work with people who have chronic diseases to create a social support system and open research platform so that people can get support from other people who are dealing with the same conditions, and also they can share data about themselves that the healthcare community can actually use to help discover what works and what doesn't from people directly who have the disease. I'm also the UX lead of the community tools team. I'm the co-author, the co-organizer of Design for Drupal Boston. The author of Drupal for Designers, which some of you may know because I signed your book today. And this adiva right here is my daughter, Charlotte, who's the reason I get up every morning, despite my love of the Drupal community. And I am Danny Girl on Twitter and on d.o. And I'm here to talk about something relatively controversial to some people I know, which is why you should not prototype in Drupal. And I'll tell you why. There's a story behind this. About two or three years ago, I was hired by Babson College, big business school outside of Boston. And they wanted to completely redesign their digital syllabus. So this was fairly standard UX project. We did user research. We did personas. We did journeys discovered when students were studying. I mean, think about this as sort of an executive MBA program. I'm not sure if that's familiar to Europeans, but it's the idea that you're getting a master's degree, a postgraduate degree while you're working. So you're usually doing this in your spare time over your lunch breaks, taking meetings in your car, doing stuff while the kids are asleep. So we're trying to uncover some of those things. And then we start figuring out features that might work for some of these different audiences. We put that into a set of functional requirements. And then after 12 weeks, my boss says, I need something we can test. And at the time, we're using Drupal Commons on six to do a lot of this stuff. And I have no clue how we can actually get this in front of an entire class of users without trying to prototype this in Drupal Commons. So download a distro. The whole thing is three to five content type node references. I mean, this is complicated stuff. We're dealing with node relationships, OG views, all of this stuff that I have to deal with 30 plus hours of labor just to get a third of what we needed in there. And because this whole thing was so incomplete, we could not get these guys to actually buy into what we were doing. They ended up throwing out all of the research that we did. When I finally got around to learning Aksher and saying, OK, well, let's just, you know, quickly prototype this and put a spec together. Four hours on a plane. Four hours. And I got eight pages of annotated screenshots, including a note add screen so people could see what it should look like to actually enter in the content. Full interactions. Everything was demonstrated. And I could generate a specification with all of my annotations with the click of a button and deliver it to them. Now, mind you, this had already poisoned any ability we were going to have to get buy-in from this. But this got me thinking. There's a lot of power here. There's a lot that I can do before I start investing all of this time to show someone what something can do, what something should be able to do. I'm going to try doing some more of this. So a year later, I'm hired by Berkeley College of Music. Big Music School, great group of people. They are trying to take two different legacy systems. One, and I want to say, like, Web Advisor, one over here, both of them really kluji haven't been updated since about 2007, and they want to move them into Berkeley.edu, which was already existing in Drupal 7. And so we have to migrate content from all of these different departments into Berkeley.edu. And so the first few months, all I did was site maps, site maps and meetings, because we had to reorganize the navigation and content for 98 departments. Most of whom were staffed, by the way, by professional musicians, so you can imagine that there were some egos involved. And some fights over this navigation. We had to set up an internal announcements model that allowed users to subscribe to specific announcement categories. We rearchitected the way that departments and the way that staff and faculty were shown, because now we weren't dealing with nodes anymore, we were dealing with user profiles. So we had to figure out what that looked like. With an announcements model, we had to attach different categories of announcements to users. What does that look like? We also had to completely rearchitect the college magazine, Berkeley Today, which some brilliant person decided they were going to import from another system. And so there were thousands and thousands of nodes with the title, No Title Found. That's fun, isn't it? So I broke out Aksher, and I explained to my team what the workflow might look like. And after doing all of these sitemap models, I started doing a content model. I said, you're moving content from 98 different departments under one hood, and your department right now is just the basic page. Are you wondering why people are hammering the crap out of these pages? Because they want to put this information out there, but they don't have a way to do that. So I put together content models for them for a bunch of different departments. We completely rearchitected the page itself and what the different sections looked like, what the left-hand navigation looked like. We also created this internal model. The entire process took eight months. First time in a couple years of doing UX that something consistently launched. And during this time, I was able to do prototypes for six new features and content models for three entirely new areas of the site. And the best thing about it is the entire thing was in one document, and the developers worked straight from it. They didn't need requirements documents. They didn't need a printout of specifications. They just looked at the prototype, and if they had a question, they said, hey, Danny, what did you mean by this? This isn't working in Drupal. How can we rearchitect this? This doesn't work responsibly, right? How do we make this better? And everyone could see it. And the best part was we could also socialize this around the college, which meant that all of those 98 departments with all of those professional musicians and all of those egos could sit and fight over the 100-some-odd links in the navigation, and we didn't have to make changes in the Drupal menu structure. Imagine the time savings, just in that alone. So one of the questions I always get when I talk about Aksher is, wow, this sounds awesome, but can I get production-ready code? No. No, you can't. Because the point is that you're only mimicking these interactions. You're only showing what search might look like, what data entry might look like. And there are even some interactions, like drop-down menus, that I still prefer doing in CSS when I can, because it's still easy. So there are certain things that can be annoying about it, but what's really nice about it is it takes a lot of the guesswork out of it. When you're prototyping, you actually can create the interactions that you want to mimic without investing a bunch of development time, without having to worry about code, and you can also comment on these prototypes and discuss them anywhere your folks happen to be. So if you're working in a distributed team, you publish this to a service with the click of a button, there's a Discuss tab, and you can sit there and literally talk about this in a go-to meeting or even asynchronously. And if you annotate the prototype as you go, you've got comments right in there that will tell the developers this is where this information should be coming from. You're going to need to add a new field here. I see this is coming from a view. And so your developers can go and look at this prototype and know exactly what you were thinking. And they can call you on stuff and they can say, well, how do you see this working? So all in all, the biggest thing about this is it lets you work much more efficiently. You can even work in teams. It has version control. Guys, it has version control. You can actually work with anyone. If you share this thing in a Dropbox, you can work with a distributed team. And one person's working on this section of prototype, one person's working on this section of the prototype. I just really love Acature. But there are specific times when you need it. When feedback is going to come from a bunch of different sources and it's a highly politically charged situation, for example, the 98 departments fighting to get their navigate, there are a link in the top spot. And the one department that thinks they need to have their entire section in the top navigation, you get to have those fights without having to mess with Drupal. So when things are likely to change really frequently, when you need to set up the entire structure of something before it goes to code. So if you're creating an entirely new feature and you don't necessarily know what it is yet, you don't necessarily know what the experience should be yet, you can put it together in Acature, you can test it with actual users, make any fixes you need, iterate, and then you go into Drupal. And you don't have to worry about touching a database, you don't have to worry about writing a bunch of code, and you don't have to worry about being nervous about throwing it away. Because it's just drag and drop. So some of the stuff that you can create in the program itself, site maps, and site maps can also link to pages within the same document. Content models, which are really, really helpful for working with Drupal sites, to show how content works together and how the relationships work. This is actually really important for what we're doing now with entity references in Drupal. So much of our stuff really is dealing with these related content types that talk to each other and we're pulling a reference in from something else. I mean, that's becoming more and more common in the architecture of our site. You can work all of this out in Acature and do the entire information architecture in this program and then prototype the flows that you're trying to show your team, all in the same document. So in addition to prototypes, you can also create documentation. So this, some of you may have seen and commented on this. This is actually the Drupal.org profile redesign that I worked on that Dries mentioned in the keynote. This was the original Acature prototype that we worked from and that the folks at Drupal.org are actually working from as we implement the new profiles. And this took several iterations. It had the entire community's feedback. It was listed in the issue queue. And when I went to make changes, every time I make changes, it took me less than half an hour. And it's all in the same document with all of the different versions inside. This is pretty cool, isn't it? Do you see how this can save you some time? Now what about Drupal? What do you do in Drupal? There are some distinct drawbacks and I'm certainly, I am absolutely positive that everyone here has dealt with at least a few of these drawbacks. If you're dealing with anything complex, it gets to be a major time suck. Even just configuring Drupal so you have something that someone will look at and not think is horribly broken, unless you've got a process severely down, like seriously down, that can take like 20 hours alone. And because it takes so long, and this is a basic psychological principle, we work really hard to get somewhere, do we really want to give it up once we've done it? If you spend 20 hours just getting something to the point where you can look at it and comment on it, do you really want to give up on that code if you realize that someone can't use it? Not really. But if you can put together a really quick prototype and test it with some folks and say, yeah, okay. And we're not talking about months and months, we're talking within a week. You can get up a prototype once you get up to speed with this program but not that hard. You can actually get a working prototype up in less than a week. Test with users on Tuesday, make changes to the prototype on Wednesday, test again on Thursday, and then iterate on Friday. And then you're ready for development on Monday. This does not add a huge amount of time to the process, but it can save you hours of development time. Now, there are times when you do want a prototype in Drupal. And the times that I have found that are most useful is when you actually have to start getting involved in complex content relationships and field relationships. Sometimes it's nice to see those in the way they interact with Drupal. Same thing with views. When something's going to require a lot of views. Another thing that I'd prototype directly in Drupal is batch uploads. Because there's really nothing you can do, like any kind of database touching, like real database-y stuff. That stuff, yeah, it makes sense to prototype that in Drupal. But most of the sort of front-end, this is what a department would look like, this is what the staff directory might look like, there's no reason to start that in Drupal. So when you know exactly what you're building and you're setting up the initial configuration, all of that stuff can happen in parallel with work that's being done in Azure on other sections of the site. And if you need to think through how Drupal does things, you know, like maybe you need to see, like, how would this view get set up? That's a time you want to prototype in Drupal. Another question I often get is what about Zerb and Foundation and... Blue... What is it, Bootstrap? Okay, yes. So what about whatever CSS framework I want to work in? That's really nice for seeing how something really works. But it's tricky. And I actually dealt with this firsthand on a site that I'm working on. It's really easy to convince yourself that you're creating production-ready code. But you're not. You're creating code that may or may not end up in Drupal someday. And the important thing to remember about all of this is that design is really about communication. And that's why I use Aksher instead of other tools, is because this actually allows me to create design documentation for my team. That I can also test with real users because it looks enough like the actual site that we're not gonna get a bunch of confusion about how something's actually going to look. And we're not just sitting here commenting our opinions on a Photoshop comp and arguing over whether something should really be that color blue or it should be a slightly darker shade of blue. You can actually show someone the interaction, show them how it works, get feedback, iterate, and then document everything for your team. You cannot do that if you're prototyping just front-end code in Bootstrap and telling your developers how a Drupal page should look. I've also found out the hard way that oftentimes when you're prototyping in those frameworks, unless you actually know that the code that Drupal is gonna spit out, it is a pain for your front-end developers to take the CSS you wrote and turn that into Drupal code. Because designers tend to forget that Drupal throws a bunch of extra code, including that whole admin menu on you. And so we had problems with the prototypes that we got from our designer, which were done in Foundation, where we could not, for the life of us, get the header to not be messed up because the admin menu showed up, because he had a fixed navigation, and he didn't account for that in any way in his prototype. You also can't account for things like, what does the content model look like? What is the architecture really? What are the underlying things? These are things that you can use actually to actually work out with your development team. So it's much nicer for collaboration than just trying to go into a CSS framework and code some things. And that's the thing that I really want people to take home from this talk, which is that if your code is just what something looks like, then you might as well just use Photoshop, because you are creating the same level of communication for your team as a Photoshop mock-up that has no annotation whatsoever. The point of a prototype is to communicate design to the user and to the team that actually has to implement this stuff for you. So I want to give you a couple of tips for getting the most from Aksher, because I find that the initial learning curve, if you've ever used Photoshop or Illustrator or any of these other types of tools to create mock-ups, then Aksher will be very familiar to you. It's drag and drop. You have widgets. You drag them into the thing. Omnigraphil is another tool that's very similar. So the biggest thing that I tell people is that they should always start with what they call the core training. And the core training is right on the Aksher website, and it's six videos, takes under an hour. And it'll give you the basics of what you need to know to use Aksher effectively. And it'll teach you most of the things that you need to know. The next thing I recommend is that you actually download some widget libraries. And widgets are essentially shapes that you drag into the frame. And you start putting them into your design. And what that does is it just makes it... It gives you a set of defaults to work with that are nicer than the Aksher defaults, and they help make it very easy for you to start putting together good-looking prototypes. The other thing you can do as you get more skilled is you can build your own widget libraries. So, for example, I'm actually creating a widget library for patients like me that essentially puts our style guide into Aksher so that I can very quickly put together high-fidelity prototypes of different aspects of our site. The other thing you want to do is set up an account with Aksher Share, which is free. It comes with a license, and you can store something like 1,000 prototypes for free, and you can organize them into folders, which is really nice when you're doing them by client. You can also generate, by the way, prototypes for just specific pages of a prototype. So, if you're working on one particular project, you can have the whole thing in one document up to something like 1,000 pages. I want to say Berkeley was something like 120 pages when I was done with it, but each section actually gets exported into different prototypes, so the developers only need to worry about the things that they're actively building. And the other thing is to annotate. And annotating is really, really easy in Aksher. You literally click on a widget, you see a thing that says Notes, and you type. That's it. And so what this does is it actually aids in that communication process between you and developers, which is especially important when you're dealing with distributed teams. Or you're dealing with, you know, a manager who just keeps hitting refresh on the prototype. I'm not saying that I had a manager like that, but I did. And seeing and wanting to see the changes and wanting to see where your thought process came from. And the annotations that you put into the prototype, if you export a specification, it goes directly into the specification. So literally once you're done, you export a specification. It shoots out a Word document with screenshots and all of your notes. And the developers can just take that piece of paper and go with it. The other thing is to work with masters. And if any of you are fireworks users, you'll be familiar with this. It's basically shared layers. So it's reusable bits of code. It's actually very similar to having a style in SAS that you apply to everything. This is my component. This is my header. It's the same on every page. And this actually helps you make iteration easier because you only have to edit one master. This was a lifesaver when we were actually dealing with the fights over the navigation. If you're working on teams, you can easily set up team projects and then you basically check things in and check things out and check them back in in order to make edits. And it also supports Font Awesome. So you can actually get a widget library for Font Awesome and use the icons directly in your prototypes and it will actually load web fonts for you. You can also set up adaptive views, which I've only just started playing with, but it allows you to take sort of a mobile-first approach to creating your layouts. So you can actually start with a base on your phone, set up your breakpoints, and then go up from there. You can also work with grids. There's a 960-ended 1200 grid that's already built in, which is nice. Or you can set up your own. And you also can set up both widget and page styles. So what you can do is, if you really want to just talk about overall layout and you don't want to get into arguments over color, you can include color in your prototype, but then make the entire prototype grayscale. That's really nice. You can also go from low fidelity to high fidelity, really, really easily, just by changing some of the base styles. So this is very similar to anything that you've done in any Adobe product. It's the same type of interaction. In terms of the process, AXURE doesn't replace sketching. It doesn't replace going into Photoshop for certain things. You still want to make sure that you understand which pieces of the product actually need to be prototyped. So what is it that you're trying to create? Are there specific pieces of functionality that are a little more complex than just throwing together, you know, a blog or something like that, or are going to be a little bit more political? Are there, with Berkeley, for example, we actually had a couple of departments that we knew were going to have specific content that was going to need a little extra love? So we prototyped that in AXURE and ran it by them and said, this is what we're thinking. This is how we'd implement it. You know, what do you think works about this? What do you think we need to change? And then you also want to have an idea of what the goals of the prototype are. Is it something that you are trying to just model the content and understand how the relationships work? Or is this something you actually want to test? Are you going to be running usability tests on this? Or are you going to have stakeholder feedback? Are there any areas where you think the stakeholders are going to get stuck if you don't include that interaction? And then once you decide what pages and features need to be included, then you can start sketching. And then you set up your base layers, your adaptive views, your page grids, you set up Font Awesome. You set up your header and footer, so this should be familiar to anyone who's ever done a Photoshop comp. Same basic structure. You start with the masters for common elements. You start laying in the other pages. And the biggest thing is to annotate as you go. So when you think an interaction should go a certain way, you actually annotate and say, this should go like this. This should be coming from here. Because that way you don't have to think about it later. And it becomes part of your thought process. The entire prototyping process becomes part of your design process, which goes really far towards helping you sell your stakeholders on the idea, even if they're not in the room with you. So once you're done, you just publish to Action Share. You do want to make sure that Font Awesome is available if you're using the icons. That's a pretty quick interaction. You can also create custom generators. And then you discuss and iterate. And that's it. That's the whole thing. So it's not going to change your overall design process. But what it allows you to do is get the structure into a prototype in Action that the developers know about. And then you know what you can do is you can focus on using Photoshop for what it's best for. For doing small elements, little features, saying, okay, so a button should look like this. And you can focus your Photoshop work, your fireworks work, or any of that other stuff on creating essentially a style guide for the developers to go from. Rather than spending hours iterating on Photoshop comps that will never, ever look like what these people are building in Drupal. And it becomes a much more lean and iterative process. So there's a couple of resources. I will actually share these slides, so I'm not going to sit here and read from my slides for you. But there's a few different books that you can get that will tell you a little bit more about a little bit more about Aksher and about design deliverables and that kind of thing. There's some good blog posts and tutorials. I want to get to questions, but I also want to do a little bit of a demo. And I'll show you an Aksher prototype in Action. Oh, yes, my daughter lines up her ducks. I have no idea where she gets it from. A little awkward trying to figure out my dock looking over there. Okay, so this is actually the prototype for the Drupal.org profiles. And so you can see here, if I go into this Discuss tab, I can actually create notes right in here. And I've got annotations all over it, so it tells you exactly what you might be building. You can also tell that I've gotten pretty high fidelity here. It's not exact, but it's pretty close to the Blue Cheese theme. So, again, we're not replacing visual design. We're not saying we're not visual designers anymore. What we're doing is we're focusing on interaction design and thinking of visual design as a layer on top of that. And what's nice about this is because this is available at a link, anyone can come in. I think this one actually has more comments on it. So we can actually have someone come in and actually start making comments whenever they happen to look at it. So many of you probably have colleagues in different countries, different time zones. I know I certainly do. Isn't that nice that you can put this up there and have people comment on it while you're sleeping, and when you wake up in the morning, you can go in, you can answer all the comments, and you can resolve them directly in the prototype, and every time you output the prototype, the comments stay. So you don't have to worry about accidentally saving over your comments, and you can show which ones are resolved and which ones aren't resolved. You can also do page-level interaction. So, for example, you can say that one particular item is selected. That's not here, but it's in other ones that I've done. And you can also organize your folders so that you've got prototypes that you've done here, prototypes that you've done here. This is one that we're actually doing for... This is one that I'm actually doing with the User Experience Center for some research that we're doing on navigation. So we're actually comparing four different usability testing methods, remote, unmoderated usability testing methods for essentially testing the effectiveness of information architecture. And so essentially what I was able to do was in a couple of weeks put together a pretty reasonable fidelity prototype of the WellsFargo.com site with the navigation really quickly, and you can actually set about states for this. So I've got a page-level interaction that once you get in there, it tells you what page is active. So there's a lot of the basic interactions that you can expect in a website from doing code, but it's all drag and drop. And you can focus just on the interaction, not on all of the other stuff. So, I mean, that's Aksher, and that's why you should use it. Any questions? Hey, Danny. Hi. I've been using Aksher recently, and I found that the share feature or the functionality is actually kind of hard to use. Surprisingly so for the UX tool. And the clients I share with have trouble figuring out where to find all the pages and how to comment and stuff like that, at least initially. My question is, is there anything out there that you can use to kind of replace the functionality or improve it, like a plugin or something like that? Not that I've found recently. The basic thing that I've found is you can actually save generators, or save prototype generators. So, what I typically do is I create a new generator. I don't know if it's worth. So, what I usually do is I create a new generator in order to capture the stuff that I want to do, and then I change my default generator to make sure that font awesome's in there. So, that helps in terms of making sure that everything's there. But usually what I'll do is I'll have a new generator for each project if I'm outputting just like a section of pages. No problem. Hello, I'm Christian. Yes. I have like five questions. That's okay. Maybe I'll just throw them at you and let you handle them. The first question is about, you know, DRIPPLE-specific work. We have the issue that, you know, I don't use Accure, but the project managers are also kind of busy with handling the customers do. And we're not a pure, pure bland DRIPPLE company, but lots of different CMS. And, you know, we sometimes have the issue that certain project managers, you know, jump from CMS to CMS, maybe even from technology to technology, and sometimes kind of lose scope what actual DRIPPLE is about. Yeah. Does this help or not really? I think it does. I mean, essentially, like, you know, part of that is a communication issue, right? Like, you need to be able to communicate what the capabilities of the software are. So if you're a UX designer or a project manager and you have to put together wireframes, you can show this to a developer and say, what do you think, you know, what do you think about this in terms of, like, what we can do? And so you can very rapidly iterate on this and they can come to you for feedback, and they don't even have to be in the same room with you. They can just send you a link and say, look at this and tell me what you think and kind of feedback. So this is one of the things I like about Aksher as a tool because it's one of the few that also focuses on communication and documentation. So it's not perfect by any means, but it gives you that level of real collaboration between designer and developer and project manager and developer that I think is missing with a lot of the other tools, like InVision and some of these other ones that really just focus on being able to put a prototype together for a usability test. I mean, that's fine, but you guys are the ones that have to build this thing and you need to have your input, too. So that's really what this does. And it's CMS agnostic, by the way, too. So, like, no matter what CMS you're working in, you can put something together in Aksher. Well, some of the questions are repeating, but my second question would be, you know, the usual process in developing is, of course, based on some ticket system we're using Jira, there are others out there. Do you have any magic bullet to actually, you know, make Aksher somehow work together with the ticket system? I call it my design stick. It's just a stick. It has design written in Helbatica, and I just hit the developer. No, I'm kidding. Actually, so one of the things we're playing with at patients like me is this idea of epics and stories. So the prototype is kind of like the epic, and then the individual pieces that need to happen based on that are the stories. So it's similar to what we did in the... similar to what we did in the issue queue with the profile prototype. Essentially, the profile is the epic. It's the meta-issue. But then the stories are, well, we're gonna need to transition this field to this, and it's gonna have this format now. So that's basically what you can do. And the thing that's really nice is that when you have a prototype like this, you can say, this is the thing that needs to get done. See here for the example. And you can share a link directly to the prototype. And so for you, you're not sitting there looking at a Photoshop file saying, wait a minute, there's no hover state. Like, what am I doing right now? You can look directly at that. And you can see it also in the context of what's going on within that. The next question kind of comes after that. Do your developers actually comment on this as well? Do you include them or just the clients? Oh, no, absolutely. No, the developers, the developers, the clients, with the profiles, we wanted the whole community commenting on it. At Berkeley, these prototypes were shared with the developers. We actually realized once we got into development the dashboard that we had originally put together was really not going to work in a responsive way. So we went through an entire, like we basically threw out the whole dashboard that I'd constructed and made a new one in Aksher. And they just took it and looked at it and they're like, okay, this is what I build. All right, cool. And if they had any comments, they just yelled over at me. Well, doesn't this open up the issue that, for example, we have that there's something you're working on. And there's certain reasons why you do certain things and you put it away and then like half a year later another developer has to work on that and you kind of ask themselves why did they do it the way they did. So usually you would look into the ticket and look at the comments. But if comments and all the information about certain objects and design decisions are spread out over tickets, is that a problem? I haven't seen it be a problem yet. I can see that being a problem. The way that I've been trying to, the way that I've been trying to handle the discuss features and I think this goes to your comment too, Lewis, the way that I've been trying to handle the discuss features and the page notes is that anything that's the specific documentation and rationale lives in the prototype. And then the comments that go into the prototype are deleted once they're resolved and in the next version of the prototype. And then what I also do is I include essentially like in most prototypes a list of changes on the home page. So the home page is essentially your change lock. So these are the things I did on this date per this comment. It doesn't replace by any means the comments that are like the comments that might be in the ticket. But if you're careful, if you're mindful about where you put what comments where, like what the comments pertain to, then that I think can mitigate some of that. Or what you can do is put all of the stuff that's related specifically to this is why I did this. You can reference a JIRA ticket in the comment. Okay, last question is how do you handle that? Well, I have that sometimes that clients see your prototype and then later, you know, the actual prototype and then later you come along with your software and the client starts to point at your prototype and says, well, you know, I want it that way. So where clients kind of get fixated on the actual way of certain things and you were still, you know, while we're doing with the actual you still were not there the way you handle it in real life. So the differences between the prototype and the actual Drupal, how do you handle that? So I have to be honest, that's one of the biggest benefits of Aksher because that almost never happens. And the reason why is because you can tell them this is an early prototype, the visual design layer hasn't been applied yet. This is just to talk, we're just talking about the interaction and how things are supposed to work and getting an idea of how the flow works. When you show the visual design, what usually happens is clients get fixated because they see a Photoshop mock-up and they wonder why it doesn't look like that on their laptop. And with this, they are actually looking at essentially code, but there's enough differences that it doesn't seem to connect. They don't seem to obsess about it as much. They can focus more on the interaction and many of them honestly are just so so happy that they can see an interaction instead of looking at this screen and having to imagine what it might work like that the whole visual design layer doesn't even, like they think of it as an entirely different phase of the project that happens later. And I find that it works a lot better because I've seen people do full design comps in code and then you try to apply that code to Drupal and all hell breaks loose and that is just not a fun thing to deal with because even when you're dealing with straight front-end code you think it's going to be easier, it's just not. It's not that much easier. Thank you. You're welcome. Quick question. So after you do your prototype I'm sure you might do design, like visual design. And what my question is or what the challenge is is that you have one source is a prototype for specifications, for annotations, for explanations how this should work and on the other side you have the visual design and how do you keep these two things together? Yeah, no, and that's a really good question. Where I see the opportunity is, where I see the opportunity and certainly in my process, like I've still done action prototypes and then a fireworks layout that says this is like the visual styling that should be applied. Lately I'm starting to lean more towards style guides and I'm not sure if you've heard, what is her name? She's at Twitter now. Samantha Warren's talk about style tiles. The way that I've been thinking about visual design now is more what are the components that we're designing and what do those look like? And then how does that work across the layer? And so what you can do is things like, actually name things with the class that they should be called. And then you have your style guide that says, okay, when I see this component it should look like this. And that's something that's a lot easier for developers to relate to. And what you may end up having to do is still like mock up a fireworks layout with the basic typography and the header and like a couple of stages of the navigation just so the client can sign off on it. But it's much less work than trying to do, like the reason I started going to AXR was because literally I was watching my team go through hundreds of pages of Photoshop files daily. That is not okay. That is not a sustainable workflow. And so AXR allows you to solve most of those challenges and focus the visual design on creating a vision for the overall look and feel and guidance for the developers rather than trying to create these, you know, quote unquote pixel perfect mockups. Is it possible to connect Azure with something like Jira? So you write a comment on an issue and it will show up in Jira or... I think if you made that, the AXR team would love to implement that. I mean, what you can do, for example, is you can reference a prototype link in each ticket. And then you can comment on the ticket and then there will always be that link back to the prototype so that you can see what you're looking for. There's no real... It's not like a database-y type thing, but they're very open to saying, you know, this is a feature we'd like to do and I'm sure that if somebody actually created that feature, then they'd be like all over it. You're welcome. Hello, Megan. Hello. Just a follow-up on Dagmaw's question. One of the reasons I like the concept of masters in AXR is because it's a really nice introduction for designers to reasonable design components similar to what John was talking about earlier. But the kind of thing I find the urge of doing with masters is adding them to a page but with slightly different content without just duplicating them and changing the content because you cannot lose the benefit. Is there any way of doing that? So I think it's a learning curve as you... I mean, with any design... I mean, how many here took a little while to develop your process and how you save things, how you organize a page? So it's the same thing with AXR. The learning curve is not as much the software. If you've ever used an Adobe product, literally you can figure this out in a couple of hours. It's really in developing that workflow. What is it that needs to be a master versus what is it that needs to be? So in your case, what you're probably thinking is that the background should be the same but the content of it should change but it should remain the same typography. So that's an opportunity for you to use a master for the background and then a style for the typography. No problem. Oh, and you can also, by the way, create widget styles, too. So you can actually have backgrounds as a style, too. Which is nice. I haven't worked with AXR yet but I'm getting very interested and I was wondering, is it possible to do real content testing with multiple content items of the same type? Because in my experience, usually if you use one sample product, then everybody is like, okay, this is the right way to do it and then afterwards you start entering multiple products and then you start finding out, oh, these ones don't fit the model. Yeah. Well, this actually goes back to a fundamental design process that I personally advocate, which is if we identify that there's, say, three to five content types that we want, then I need three to five examples of each content type and all of those go into the prototype because we need to see how they look. That part of the process does not change. So I think that the big thing about, and again, this is that opportunity for AXR and Photoshop being used together, AXR will get you a large part of the way towards the basic typography, some of the layout elements, the blocking that you have to do. It's not going to get you all the way there but that's where Photoshop comes in. You can start making those little enhancements and use visual design as a layer over that sort of holds everything together as opposed to, like, this is my perfect baby Photoshop mock-up. Please, developer, go make this. I know that CSS doesn't do any of these things but I want you to do them because you are magical. We need to move away from that. So this is one of the things that helps us do that because AXR will not let you do anything that CSS3 can't do, and this is a nice win. All right. I don't know. Is that my time? Or do we have time for them? Cool. Are there any other questions? All right, well, thank you so much for spending this time with me. It was very nice to meet you all.