 Is that better? Yeah. Okay. Whatever. So the first part of the session is going to be discussion and lecture. I'm going to tell you a little bit about why I do prototyping in AXURE as opposed to going straight to Drupal. Give you some sort of general tricks on how to make your life easier working with AXURE and how to work with developers and answer questions and all that kind of good stuff. And then the second half, which is actually going to be after the coffee break. The second half is actually going to be a live demo. So I'm actually going to show you how I walk through a typical prototyping process. And if you want, and you have your laptops, you can feel free to download a trial of AXURE and sort of play around with me so you can see a little bit of the ropes if you haven't played with it before. So the first thing I should probably do is introduce myself. My name is Danny, Danny Norden. I am from the Boston area. And currently, I've actually operated my own design consultancy called the Zen Kitchen for almost a decade now, but for the last year and a half, actually no. For the last almost year, I've been working at Bentley University in the User Experience Center while I get my master's degree in human factors. I'm the UX lead of the Drupal Community Tools team. So I'm going to be focusing on the ways that we collaborate and give support to community members through Drupal.org and G.O. and all of our different tools. I also co-organize the Design for Drupal Camp in the Boston area, which is happening, which is actually happening the first weekend in August, and we are accepting session proposals. So if all of you all are designers, come and get one of my fancy postcards after the session and propose your session because we're looking for great people to talk about design, front-end development, and also workflow and process issues, and to provide case studies for the audience. It's a great event. We get 300-plus people every year. Cambridge is gorgeous in the summer. You guys should come down. So I also am a teacher. I teach at General Assembly in the Boston area, UX Design. I wrote the book Drupal for Designers for O'Reilly, and on Wednesday I'll actually be signing copies of that book, so if you want to come down and say, hi, you can. And if I wasn't doing enough already, I'm also the mother of this little adorable person right here who you'll see sometime tomorrow afternoon. So you can find me on Twitter and D.O. as Danny Girl, and I'd like to start with a tale of two projects. A couple of years ago, I worked with Babson College, a big business school in the Boston area, on a critical piece of functionality for their learning management system. This was their web syllabus, and it was this big, clunky behemoth that was built in 2005 and had been sort of cobbled together from bits of HTML and was basically being brought into Blackboard. And they needed to redesign it and revamp it and make it easier to use for the people who are in their online learning programs. So the job started in a typical way. I did user research, did some journeys, some personas. I brainstormed features with the stakeholders and with other people. I refined that into functionality requirements. But then after a few weeks, the person that I was working with said, well, we need something we can test. We need something that we can see. So I was trying to figure out how to prototype this. I played with actual a little bit, but it didn't seem like something that I could get the developers to actually plug into Blackboard so we could actually put it into the LMS. So I started working with Drupal Commons, which was in version six at the time and started prototyping. Because in order to make this syllabus work in Drupal Commons, which was what they were using as their enhancements to Blackboard, I needed three to five content types. I needed to work with node references, organic groups, and views, because that's how everything was organized. And I had to touch not only the content layer but the theme layer and the menu layer and the display layer. And after 30 plus hours, I had managed to get a third of the ideas that we had come up with as requirements of the system into this prototype. And when the stakeholders saw it, they just didn't understand. They're like, this doesn't look finished. This doesn't look like, why did you do all the user research? You waste it all this time, yeah, yeah, yeah. So unfortunately, now I was in a position where we're like, OK, we just need to generate a specification and then we'll call it a day. So I decided to open up Aksher and say, OK, let's try this out. So I took the tutorials while I was on a plane, oddly enough, to Austin. And in four hours, I had managed to demonstrate everything that we were trying to do with annotated screenshots, including the note add screen so that they could see the field and the way that people should enter this into the system and generate a specification that was in a Word document and had layouts, wireframes, and annotations listed with a click. It was a three-step process. You click a button, name the file, hit Enter, and you have a specification. So a year later, I'm hired by Berkeley College of Music to bring two legacy websites, one in, I want to say SharePoint, one in some kluge version of WebAdvisor. And the content from both of these websites into a Drupal site that was already running and already had a year and a half of content in it. And most of this was coming in behind a login. We had to reorganize the content and the navigation for 98 departments throughout the university. We had to set up an entire internal system where students, faculty, and staff could log in and get messages from the college, including an internal dashboard and a subscription model where people could actually subscribe to the types and locations of announcements that they wanted to receive. We had to re-architect the way that departments and the way that faculty and staff members were even displayed in the system. When I walked in, a department was just a basic page with department information on it. It wasn't its own thing. And in order to fit all of the department's information, we actually had to create an entirely new content type and start associating different content with it and understand all of the different content that went with a department. And we also had to re-architect the college magazine, which was also brought in as basic pages and many of which were automatically imported with no title. That was fun. So that piece alone accounted for something like 1,100 links in one of the menus. So by this time, I had had a bit more practice with Aksher. And I started using Aksher heavily in my workflow because I could actually take on pieces of the experience and pieces of the research and start doing rapid prototyping while the developers were working on other things. And before we even had the content in there. So I started with sitemaps and understanding where we were in terms of the content. And doing the sitemap process in Aksher, I was able to realize that we had content that lived in that was shown in this system and 90% of it was actually coming from this system. And we had no idea where it lived in this system. So we ended up having to create an entirely new workflow to handle all of this, an entirely new information architecture. And so we started doing some content modeling. So actually putting together what are the content types we need, what are the different fields that go in that content type, how do they relate to each other. I also prototyped complete departments. So there were several departments that we knew were going to have complex architecture, departments like human resources, departments like the academic departments where we have syllabi and staff, and we have downloads. And I started seeing the different commonalities between those departments and prototyping what they would look like when you're logged in versus when you're not logged in. And we also prototyped a dashboard experience and what the subscription model would look like. This entire process, and mind you, this is a college with 98 departments and two different locations, took eight months. And in that time, we did at least 30 pages of site maps, prototypes for six new features and functional content areas, and a complete content overhaul of at least three different content areas. And we were able to do that in one document that was shared online that could be sent via a URL to anyone within the college for feedback. And the best part about it was I was annotating as I go, so the developers actually worked from it directly. So we didn't even have to create a specification or any kind of documentation. People that the project manager just put the tasks into the system and pointed at the URL. So this is the page in the prototype that you need to go to. So obviously I'm a proponent of Aksher, but one of the questions I always get is, can it give me production ready code? Can I take Aksher and plug it into Drupal? Unfortunately, no. It will not give you production ready code. Additionally, it can only mimic sort of database type interaction. So if you're trying to show people how search is going to work, if you're trying to show people how content entry might work, you can really only mimic those kind of things. It also has some issues when you're talking about certain interactions like drop down menus are so much easier to create, just coding them than they are to create an Aksher. But with this program, you can actually go beyond wireframes and into actual prototypes. And not only can you do that, you can put user flows in the document, you can put content model in the document, all of the typical documentation. I've even put personas in Aksher, and you can keep everything in one document that you can send to anyone in your organization and they can give feedback on it and they can discuss it right in the prototype, which is available publicly online. And you can password protect it if your clients are wishy about that. The other thing that's really nice about Aksher, and this is where I actually put it far ahead of many of the other prototyping tools that you see out in the world. There are a lot of prototyping tools that are much better for creating a screen or a thing that you can interact with, but they don't necessarily give you documentation. They don't necessarily give you the ability to show someone you're thinking, show someone you're rationale and put comments inside the document. And that's the thing that Aksher really, really excels at. And not only can you annotate as you go, which saves a ton of time and helps the developers see exactly where you're coming from. When you output a specification, all of those comments are right there with your document. They're right there with your wireframes. Another thing that it allows you to do, and if anyone here has been at Design for Drupal and heard me talk about fireworks versus Photoshop, I lean heavily on the fireworks side because it gives you multiple pages and you can share layers among those pages so you don't have to repeat your work. And anyone who's ever had to prototype a complex navigation understands how important it is to not have to repeat it in multiple files. Aksher gives you that same ability. You can create a master and share that master on all of the pages of your document or select pages of your document so that if we're working on a complex navigation and I have to make iterations to it, I make that iteration once. And the minute I save it, it goes to all of the pages that you use that master. The other thing that's really nice, and this is actually a feature that just came out in Aksher 7, I believe, is you can actually create team projects. And what that means is you can actually create a project that another person can go into and work on with you. So you can be prototyping this slice of the experience and your collaborator can be prototyping this slice of the experience in the same document. And you check things in and out, much like you would with Git or SVN. So it really is wonderful for working in distributed teams. It's one of the best tools that I've found for working in distributed teams I've found, and I work on a lot of distributed teams. So in terms of when you need to work in Aksher, one of the things that is really important to frame this conversation is I'm not suggesting that we don't work in Drupal. I'm not suggesting that we sit on our hands and do everything in Aksher before we ever touch Drupal. There's still a lot of stuff that needs to be done in Drupal while prototyping is happening in Aksher. So for example, it's not going to change the way that you configure the database. It's not going to change the way that you have to update the text formats, figure out the basic modules, start working on some of the views. You can still do all of that work, but the times you need to work in Aksher are when the feedback that you're getting and the changes you're going to make are going to be coming from a lot of different areas. And when things are likely to change frequently. So for example, I showed you the navigation on Berkeley, that one tab that had something like 20 different items in it, there were 10 to 12 of them, all like that on this one site by the time we were done. Every time we got out of a meeting with the department, the department wanted one or two more links in there, and we had to move stuff around and rename things. We've got, I'm math impaired today, so I don't know exactly how many links that is, but I can tell you trying to do that in Drupal in the menu system when half of the content isn't even in Drupal yet, that's a lot of development time just on messing around with menus. Meanwhile in Aksher, because I had this set up, 15 minutes after the meeting and the iteration was done and it was pushed out, and people could look at it again. Huge, huge time savings. Another thing that's really nice is when you're working with a smaller foundational slice of the experience that's not ready to be built yet, and you need to get that experience right before you start committing things to code. So this is really important, for example, when we were figuring out that departments needed to have their own content type and they needed different content to be associated with them, and we needed to work out what was the content that needed to be associated with them, how did it need to go into the system? And during the process of that we learned that, for example, a syllabi could change every semester and they were 20-30 files. If you're trying to put that manually in there, there's five different ways that you can do that in Drupal, and you need to figure out which one is going to work the best. You don't necessarily need to work in Drupal for that. You can actually go and you can start prototyping bits of the experience in Aksher and you can start running that by the different departments and saying, this is what your department could look like. This is the architecture we're thinking about for your specific department. Poke holes in this. What does this look like? How is this going to work for you? And get all of that stuff settled before you spend development hours in Drupal. That is when Aksher really, really shines. It's when the thing that you're building is so complex or could change so frequently or is really just such a pain to change quickly that it makes sense to do it here and then put it into Aksher when you've got the approval. So let's talk about some of the things that you can actually make in Aksher. One of the most obvious and one of the things that I think sometimes people don't realize when they work in Aksher is sitemaps. And you can make them by default. You can actually create them as flow diagrams. You can also have connectors really, really easily. You can post them online. You can even drag pages from your sitemap into a document so that when you click on it, it goes directly to that page. Content models. And these are something I use specifically to describe when we're doing sort of a more complex content type than just, you know, a body and a few different fields. And we've got different things that relate to each other and we want to show all of the different relationships. That's something that I really use content models for and you can document everything as you go. Then obviously you can do prototypes. But you can also do documentation and discussion. So it's not just the fact that you've got a prototype that you can now put in front of a user and test. It's that you've actually documented all of the thinking behind this, all of the stuff that has to go in, all of the things that you might use to implement it in the same document. It's not floating around 80 different Word documents in the client folder. It's actually in one document. And anyone on the team can go and look at that document and figure out where they need to go to get the information they need. So this is the number one reason why I use AXR as opposed to other tools. So given that, I want to give you some tips and then I want to show you a little bit of the prototypes that I've worked on and give you some stories of how I use them and then I'm going to answer some questions. So the biggest tip I can give you is to really start with the actual core training that AXR provides on its website. I've known many people, if you're a designer already, it's pretty easy to learn the basics of AXR. But there's some of the more complex bits that do require a little bit of training. And the tutorials are literally an hour of your life. And you learn everything you need to know to get the basics done. The other thing, and this is a really important one for my workflow, is to actually start with some widget libraries. And AXR has a whole bunch of widget libraries available for free on its site. There's a couple of more advanced ones that are available for pay. And one of the things that the libraries do is it gives you a nice base of defaults so that you can make really good-looking wireframes much more rapidly than you would with the defaults that AXR gives you. My favorites include the Font Awesome library. There's a call-out library called EE Callouts. And then there's another one called WebWidgets by Proto5 that I use for almost everything at this point. I was hoping that I could get sort of a Drupal AXR widget library ready by Khan, but I'm a bit busy, so I couldn't do that. I apologize. The other thing is to set up an account on AXR Share. Now AXR Share is actually a free service to anyone who owns AXR, and basically what it allows you to do is with the click of a button, you can actually push your prototype onto the web and share it with members of your team. And not only can you share it with members of the team, you can actually discuss it directly in the document. And I'm going to show you that in a couple of minutes. We're going to see how that works. And it's free for up to 1,000 prototypes. So if you're working in a distributed team and you need to collaborate with multiple people, this is how you do it. You generate a prototype and say, I need feedback on this, use the Discuss tab, and then you start having discussions. This is actually one of the things, as I'm doing designs for the community tools team on D.O., that's one of the things that we're going to be doing. We're going to be working with AXR prototypes and asking the community to give us feedback directly in the prototype so that everything stays in one location. And the other thing that you really want to do is annotate. And I cannot emphasize this enough. The reason I was able to create such an efficient workflow with the team that I worked with at Berkeley was because as I went, I annotated everything I was doing. And I said, this is where this would come from. This is what this links to. Try this module. This comes from this. And you can even use page notes to discuss specific aspects of the experience or specific types of feedback that you're actually looking for. Another thing is to work with masters. And masters are similar to layers in Photoshop or fireworks. And essentially, they let you reuse specific components throughout the pages of your site, which makes it much more efficient to iterate on things. This is especially true with navigation, but it's also true with just basic elements. Team projects are a relatively new feature of AXR. And this is, again, really good for working with a distributed team. Imagine that you've got your prototype shared on a Dropbox. And you've got that Dropbox shared with your teammate. And your teammate's in another state. And you guys have a big presentation and you need to work on this section of the functionality. They need to work on this other section of the functionality. You can both be working on the same document together, sharing components and reusing them from place to place and creating a completely consistent layout. Regardless of where you're located and regardless of when you're working on it. That's what this team project allows you to do. Another thing that you want to do is use font awesome for icons. I actually, before font awesome came out, I downloaded a bunch of different icon libraries and the problem that I had with them was they were always images and they were always a single color. I couldn't change any of the colors on them. I thought that if I was actually trying to create contrast, for example, by having a black background with white icons, I couldn't do that because I couldn't find a white icon library. So when I started using font awesome, which requires a little bit of setup, but it's really not hard, now I could easily make the icon whatever color I wanted. Which means you can actually go from, you know, low to relatively high fidelity very easily with your wireframes. Another thing you want to look at is adaptive views and grids. Now adaptive views actually allow you to set up breakpoints to mimic responsive design. It's not perfect, but it's very, very close and it works really well. And it has some of the standard presets already for you, so you basically just set up your adaptive grids and then go. And you can do all of your work in the base view and then you just click on one of the other views and move stuff around. And it's really easy and that's going to be part of the demo I'm going to do after the break. Same thing with grids. Grids also have four different presets, including a 12 and 15 column 1200 grid and a 12 and 16 column 960 grid. And all of this is built into the tool, so you don't really need to download anything or figure stuff out, you just need to know where to find it. And then the last thing is to work with widget and page styles. And what those allow you to do is really customize, really easily customize the way that your prototype looks and it helps you go from really low fidelity to really high fidelity much easier. You can actually add sketch effects to your prototype with page styles and you can make it grayscale even if it's color. So it's really nice if you have certain stakeholders who are really going to get distracted by the shade of blue you're using and you just want to make it grayscale for them so they can shut up and talk about what really matters. Very useful for that. It's also, by the way, really useful for people who are really, really stuck on balsamic. I've had multiple conversations with this and actually my best friend works at BioRaft and she was having a conversation with me. She was doing a session on the hat later about the reason that they standardized on balsamic. And my friend Heather is trying to tell her, oh, well, you know, Akshar just lets you do a lot more and she's like, oh, well, you know, that's okay. Well, what does Danny think about it? And Heather said, well, Danny thinks that that balsamic is kind of what happens when you give a developer crayons and let them go, which is not totally true. Balsamic has its uses, but the reason that I standardized and committed myself to working in Akshar, and I still work in Drupal occasionally, but the reason I standardized on Akshar is because, to me, a prototype is not just about looking at something. It's about looking at something and being able to document your thinking and get developers and stakeholders on board and create something that you can test with real users without having to reinvent the wheel every time. That's why I standardized on Akshar. It's because I can do all of this at a much faster pace than I could if I'm creating wireframes in balsamic and then going into this thing and doing all of these annotations and then going over here and doing all of these annotations. I can do everything in one document and the developers can just look at it and say, okay, this is what I have to do. So you might be thinking now, what about Drupal? Don't you want to prototype in the browser? First, I would argue that prototyping in Drupal is not prototyping in the browser. It's prototyping in Drupal. And prototyping in Drupal requires that you have the content first and any of us right at show of hands has the content first. So this is why you don't start off in Drupal. It's really time and labor intensive for anything that's more complex than a simple content type. On top of that, one of the biggest problems is you can't necessarily give up on code. Once you've spent the time, do you really want to just give up on that I've heard people tell me that they'll throw away code, but I've rarely seen it done. And so when you go through a usability test and you're using a site that you spent hours and hours and hours developing in Drupal and you find that the thing that you built that you spent so much time and effort on has critical usability flaws that are going to break the site. What are you going to do? Are you going to go back and fix those flaws? Or are you going to put them in a backlog somewhere and say, yeah, we'll get to that eventually? The important thing about working in Drupal is you work in Drupal alongside prototyping some of the more complex stuff that requires more feedback and requires more iteration in Aksher. This is where during your project management cycle you want to think about the process of breaking things into functional segments, into chunks of functionality, slices of the experience that you can work on independently so that everyone on the team is doing something, as opposed to, you know, I'm going to build all of the content types this week. Has anyone ever gotten a project plan like that? I have. Did you laugh at them too? You know what it's like working in Drupal. You know, you realize somewhere down the line when you actually have content that actually, no, this content has, like, five more fields than we thought it was going to have. So now we have to go back to the content type and make edits to that. Oh, and now, wait a minute, we only hit Manage Fields. We didn't hit Manage Display. So now we've got to go back to the content type and now move all the fields around. And, oh, this looks really crappy in line, so we're just going to make it above. And, like, it just goes over and over and over again. With Aksher, you can play around with all that stuff without the headaches, and you can get it right before you have to sit there and muck around with Drupal. But it doesn't replace the fact that you're doing some stuff in Drupal. One of the things that I like doing in Drupal that I like using Drupal for is anything that requires me to play around with content models and entity references and see the relationships a bit more easily. Also, anything that actively will require interacting with the database. So for example, if I need to find a way to bulk upload files into the system, am I going to do that in Aksher? Probably not, because that's a technical solution. So technical solutions are absolutely something that you want to explore and play around with in Drupal. And you also do want to understand how Drupal's infrastructure will impact the UX of what you're building. So this is one of the benefits that I see as a UX designer who not only works in Aksher but also can speak the language of Drupal and can work in Drupal. I know when I have to do something in Drupal as opposed to doing everything in Aksher. And I can switch between the two. And that's the point. It's knowing when to switch between the two and knowing what needs strict documentation and what's really just an item on a to-do list. So I want to talk a little bit about the prototyping process. Just a very high level overview. And then I'm going to show you guys a little bit of prototypes. And then we're going to have about 15 minutes for Q&A. So the first step of prototyping in Aksher is to identify which pieces of the puzzle actually need prototyping. I will say if you're working on any kind of complex navigation with a lot of different items, that is something that you should probably put in a prototype instead of trying to do it in the menu system in Drupal. And there's a few different reasons why. One, it's just a time suck to try to do that in Drupal, especially if you have a bunch of different items. And second, as we all know, Drupal's menu structure basically requires that the content is in the database before it can go in a menu. Who has the content before they start building? Yeah. So at the Berkeley project, for example, we launched in August, I started in December. June 7th was the last time the navigation changed. June 7th was the last time someone said, oh, and then like two weeks before launch, one of the communications director went in and moved two items in the main menu because now they were in Drupal. So anything like that, very important to prototype before you go. Anytime you're building an entirely new section of content that's going to require new content types, new fields, any of that kind of stuff, that's really nice to prototype in Drupal because you can actually work out, for example. I've got this content that's in a Word document. How does this break out into actual pages on a website? What types of content am I actually dealing with here and how do they go together? We also want to determine the actual goals. What we're going to do with the prototype. So is the prototype primarily for showing a concept? Is it for testing with users? If it's for user testing, and prototypes are very good for user testing, by the way, but if it's for user testing, you need to have an idea of what task flows someone's going to have to go through so that you know what screens you're going to have to prototype. You also want to know, are we dealing with information architecture here as well? Are we supposed to be modeling content in here? Is this so the developers can understand what they need to build? Is this so we can talk to stakeholders and get their feedback on it? All of this stuff helps you figure out what is it that I'm going to do within this document? And the beauty of AXR is you can actually export the stuff that you do in so many different ways. So you can actually have two different links. One is the prototype you use for testing, which has no annotations on it at all. And one is the one that you use for documentation, and then it has all of your annotations. And you don't need to change your workflow. You just need to change some buttons on the thing that you output. So once you've done that, you want to figure out what pages and what features you need to put in there. And then you're going to set up your base layers. So your base layers is just the base of your functionality that's going to help you set up that sort of design environment within AXR. So this is where we talk about adaptive use, page grids, making sure you've got the right widget libraries, making sure you've got font awesome installed. And then you set up your header and footer. So now we're getting into a pretty common design process for anyone who's done this before, right? Does anyone else, a designer, usually starts with the header and footer and then starts doing the middle and the sidebars? Yeah, so it's exactly the same process. And so if you're a designer, you're going to find this very familiar. And then the biggest thing is to use masters for the elements that you're going to use over and over again, you're likely to change over time. And you also can use styles. So for example, if you have common elements that you're going to use all the time and you want them to look the same, you can actually create a style for those elements. And then reuse them throughout your document. And it saves you a lot of time because let's say that you need to start at low fidelity, but then now I need to start getting into actual layout. Well, most of us are going to open up Photoshop, right? We don't need to do that. We can do it in Aksher. And all we have to do is change our styles, change our fonts, all of that stuff you can actually do in Aksher. And it becomes a much more efficient workflow because you can actually see it online. And it actually looks like the thing it's supposed to look like, sort of. It's not complete, but it actually looks mostly like what it's going to look like. So it actually helps you create a much more realistic workflow and realistic experience for stakeholders. So you don't get those stupid phone calls and emails about, well, why is this one pixel off to the left? Although you still might, who knows. So then, you know, once you've got that basic layout together, that's when you start putting in the other pages. So it's really a flow like any other. Once you get your base set up, like anything else, you just keep going. And then the biggest thing that you're doing here is you're actually annotating as you go. So if you're working in Photoshop or fireworks, you might be like, you know, jazz, you know, going along. You're like, yeah, I'm going to put this here. I'm going to put this here. And you've got a rationale in your mind. But then someone asks you to explain your decision. And you're like, oh, I totally remember why I did that, totally. And you sort of make something up. But what if you're not even in the room when you present, how often is that the case? If you annotate as you go, you actually can put your rationale right in the document. And it displays right there. And you can show it to a stakeholder and say, see, this is what I was thinking. And the whole workflow is much more efficient because you basically create an element, annotate it, and then go on and create the next element. And then you get to publish to Actorshare. And this, as soon as you set up an account, it's super easy. You set up an account, it publishes, you set up the settings for your prototype, and it goes right there. The only thing you do want to make sure of is that if you're using Font Awesome, that the actual Font Awesome CSS is included in your document. And the tutorial on, if you Google Actorshare Font Awesome widget library, you find it. And it's super easy. And you can just create a custom generator to actually include Font Awesome in there. And then you discuss and iterate. So, again, totally normal design process. So I want to show you just a couple of the prototypes that I have made with Actorshare. So this is part of the prototype that I did for Berkeley. And what you can see here, this is the sidebar. And the sidebar has your site map. And the site map shows all of the pages that are within the site. This might be a little tiny, so don't pay too much attention to that. Here, we've got page notes. And I didn't put page notes in here in this document. But this will actually tell you, for example, this is the specific... You could put in here, this is the goal of this page. That's one of the things I do now. This is the goals of this page. And this is the specific feedback we're looking for. And here's the deadline for that feedback. And so if you start with the page notes, you can actually see, okay, as a stakeholder, I need to be looking at these things. What do I look at? And then here, I can actually discuss. So I can actually create a comment that goes right into the document. And so what I've done since leaving Berkeley and going to the User Experience Center, when I do these prototypes and I'm in meetings and we're showing the prototype, I'm actually in the document in this discussion tab, creating new topics as we're going. So that I can actually take notes of the things that I'm hearing from stakeholders, the things that I'm going to have to iterate on, and they're right in the document with me. And so now when I go back and I have to iterate on this document, I can look and say, okay, I have to deal with that. All right, now this has been taken care of. So I can add a comment saying that this was resolved. All right, so, you know, when I'm actually, when we're at the point in the community tools team, when we're prototyping different areas of functionality, I can actually post a prototype out to the community and say, we need feedback by this date. Please add your name to any feedback because anonymous comments will be ignored. Which by the way, that's true. Early warning. But you can see how interesting this is, right? Because you can see what I've created here. You can actually see a comment here that actually explains the rationale. So you can actually see the work in progress and understand it in the context of the actual design, as opposed to a bunch of words that you're reading through and then you see the design. And then you can discuss it right here and you don't even have to be in the room. And then in terms of interactions, you can actually do drop downs reasonably well. So this was the menu if you weren't logged in. And it grew quite a bit by the time we were done. And if you were logged in, there were like four other tabs. And so every time we left a meeting, I had to go in and change this menu again. And because it was a master, I went in, it was 15 minutes, and it went on all of the different pages. Remember if I did this. Okay. Another one that I recently did, and this is one that I will show you, this is the one that I'm going to be sort of showing in the demo. So this is Drupal.org. And this is a mock-up of a user profile. So you can see where the Berkeley, where Berkeley is relatively low fidelity, right? But you can actually type in here, hit log in, and that should send you to the dashboard, so it looks like it didn't go awa. But you can go from being mostly black and white to actually being pretty high fidelity. And here, again, I'm annotating as I go, so that everyone sees what we're thinking about here and what we're suggesting. And you can actually discuss it all along the side. And then the other thing that's nice about this, so I can hide this so you can see more of it. And then I actually was able to make this somewhat responsive. Not entirely, but close. So it's not quite as easy as, you know, putting something together in HTML, I'll admit. But it gives you enough of the functionality, and most importantly, it provides documentation. So after the break, I'm going to actually do a live demo so that you can see how you can put together an actual file. But in the meantime, I'd love to take any questions that you have. Yeah. Please. Oh, yes. And please use the microphone because we're being recorded. Yeah. So this is good. I've had this debate internally for a long time about whether I'm doing prototyping in Drupal or not. If there was a way to have those sort of inline notes that you kept referencing in Aksher in a Drupal site, would that bridge some of the gap for you? For me, no. And the reason why is if you remember the story that I told you about Babson, it took 30-plus hours to prototype the same thing in Drupal that I could prototype in four hours in Aksher. I know that with content, you don't usually have the content from the client, but a lot of times you have a sense like, okay, I know they're going to have this news item, or they're going to have events. Can I just start populating that even then to tell the client, hey, this isn't going to look good, but let's just see how it functions. Well, in news and things like news and events, you don't necessarily have to prototype in Aksher. Sure. But anything that's remotely complex, especially anything that's going to change frequently, that's going to take you a long time in Drupal. It just is. And prototyping in Aksher is not taking away any of the work that you're doing in Drupal. It's just saying, you know what, we're going to use this other tool for actually ideating and iterating on this because we're going to save dozens of hours of development time by getting this right before we start doing Drupal. And the time savings you get from working here is worlds better. I mean, just unbelievable. Yeah, so how does the licensing work? The licensing is fairly, I mean, it is a product that you have to pay for. I recommend the ProLicense, which is $600. People have told me that that seems expensive, but I also tell them that it paid for itself roughly 200 times over the first product I used it for. So it's been the most worthwhile purchase, the second most worthwhile purchase I've made since I started doing UX. So who has to have a license? I mean, whatever computer it's on, but I've actually used my license on multiple computers. Okay, so the web form you're displaying, so if you're sharing that with other people, like how... Oh, this isn't really owned by anyone. Okay. Yeah, this is just a way of displaying the work and discussing it. Okay. And what you create is just an Aksher prototype. So it's not code you can use for anything. Well, yeah. It's literally just clickable. Well, I was just trying to figure out if whoever is using that, do they have to have a license for that? Or is it just the desktop where you're producing the demo? It's just the desktop that you're producing it. So what is the format of the document that you produce? So it is an Aksher file, which the file name is RP. Specifications are generated in Word, and the prototypes themselves are generated in HTML. Okay, but if I want to put out a prototype for comment to a specific set of people, it's the only way to do that, to put it out on Aksher Share, or can I publish it internally? You can absolutely publish it internally because it outputs as HTML files. So it just goes into... Yeah, so you can load it into an FTP server, too. You can also, by the way, password protect these. So let's say that you can't share it outside of whatever your environment is. You can actually password protect it when you put out the prototype. Okay, and is the only way to get comments, though, is to put it on Aksher Share? I don't believe so. Or I can publish it internally and collect the same comments. Yeah, I believe so. I have more questions about catching up. Sure. So I've used Aksher successfully and a couple client engagements, but wanted you to talk about a couple things. So it definitely makes your life as a PM or IA your expert a lot easier. Maybe talk about managing expectations, though, with the client now who sees one of these prototypes and is like, holy crap, that's really easy. And assumes that they can have then the full website just that fast as well. And managing expectations with the developer because you're giving them a different type of documentation now. It's not a requirement spreadsheet. It's not a use case document. It's something altogether different. Yeah. The way that I usually set expectations is, you know, I use a prototyping tool called Aksher. What it allows me to do is very quickly generate these drag and drop prototypes, but nothing you're going to see here interacts with the database. Nothing, like there's nothing, the complexity that we're actually building in the back end of the system is not being represented here. So all of that stuff is going to take more time. But what this is going to do is allow us to use our development time in the wisest way possible by knowing what we're going to build and settling on this is what it's going to be before we start building. The other thing that I do with developers specifically is I actually show them my process while I'm in the middle of doing it. So I will actually publish early and often and start getting feedback from developers as soon as I start doing stuff and say, I need you to look at this and tell me if there are any technical realities I'm missing here. And that way they're very familiar with the prototype by the end of the process, and I can hand it to them and say, okay, we're ready to go on this piece of it, go for it. Thanks. I have two questions for you. The first is why would you recommend Pro so much over the basic, I guess? The reason I recommend Pro over basic is because outputting specifications is only available on Pro and so is annotating. And basic, you can use all the functions, but really the value you get is the annotation and the ability to discuss right in the prototype. That's the value you get. If what you're really just looking is for something to create really quick mock-ups, there are so many other tools that can do that even easier than this. But this really the value is in the documentation that you create out of that prototype. The other question I had was, you said this was your second best purchase as far as you asked. Oh, yes. What's the first? Oh, so the first best is, so this is like incredibly nerdy, but it's a software called N-Vivo, and literally it is for analyzing qualitative data. And it's like this drag and drop interface that you highlight text and drag it into a thing, and it's like doing a card sort on your laptop with Word documents, and it just makes my life filled with nerdish glee. So none of you need that, but I do. I was just wondering on the published online versions that you share with people when you create comments or when people add comments, do you get to pull that back into the version on your machine so that when, like, is it like the next time you push a new version out, are you losing everything that was already published? No, so actually, so you don't, it's not necessarily like a pulling it back on the machine type of thing. Everything stays with the, everything stays with what was published online, which is really nice. So I basically, what I do is I go back to my desk and I start looking at the comments. So I start looking at the comments and sort of processing them as I'm iterating. And then what I might do is, when something's been addressed, I just get rid of the comment and I close it because it's been resolved and it's in the prototype now. But when I push up a new prototype, those comments all stay there, which is really nice. And just one thing to mention about Pro, I'm a information studies student right now and if you can prove to AXR that you're in a UX or design related field and currently a student, you can get it for free. I know. I learned that after I was a student and had purchased AXR already. Hi. My shop currently just took the dive into using Envision app, which is fairly new for us but is also a really robust prototyping app. Yeah. I wanted to see if you were familiar with it and if AXR provides a certain benefit over Envision for prototyping with Drupal. Sure. So I would say that AXR, like I don't know that much about Envision. I just heard about it from Kevin O'Leary at Acquia because he uses it a lot. And I think both are good. Okay. What I like about AXR is again sort of the documentation, but I think Envision has some of that. And one of the things that I like about AXR is just again the documentation but also just how editable things are. Okay. It's really easy to iterate and add on things. Awesome. Thank you. No problem. Hi. Hi, Danny. I was wondering if you have any good stories about using AXR to test with real users? Yes. Actually, I do as a matter of fact. So as a matter of fact, this is research that's being done at the User Experience Center right now. One of the things that we just finished was a study for a big healthcare company who is redesigning their website. And what they were trying to do was understand whether people, first of all, they were concept testing the website and they were also testing the information architecture and navigation and trying to see if people could find their products on the website. So the website obviously was not at all close to done yet. But what we were able to do was create a really high fidelity prototype in AXR that we used as the basis for our user test. And we discovered a whole host of problems that were specific, not to the design of the navigation, but literally to the labels that people were using and the way that content was organized through the user test. And actually, I would also say that in terms of the user studies that we do at the User Experience Center, I would say like a good 50% of them are AXR prototypes. And we've tested a lot of really high fidelity prototypes, but now we're doing... One of our consultants is doing a research study where he is using two different levels of fidelity with AXR, a high fidelity and a low fidelity, and the actual website to sort of test how predictive users omit with the three different levels of fidelity. So, yeah, it's very, very robust for testing. And you literally... You just change the way that you generate the specification, or the way that you generate the prototype online, and you can send it up without annotations and use that for testing and then have another one that you have with the annotations that serves as the documentation. Do you run all your usability tests face-to-face? No, we actually do a fair amount of remote testing, but it's usually one-on-one. User Zoom we have used, but it's usually for literally something that someone can do without you sitting there. It's really much better for performance testing. Can the person find this thing in this much time as opposed to, you know, what does this person think this label means? Yeah. Is it easy to track success using X-Roll, or do you have to add something else on top of it? Yeah, so, I mean, this really creates the prototype. It doesn't create the testing environment. But you could, for example, use user... Like, you could combine User Zoom, for example, with AXR, an AXR prototype, and track success through User Zoom. Thanks. No problem. All right, so it is two, which means that we get to take a break. But then anyone who is interested in has their laptops, the next part of the session is going to be me sort of demonstrating how I created the profile page and the Drupal.org in AXR. So, stay tuned. Oh, yes, and if anyone... If anyone wants a fun Design for Drupal postcard and submit your session to Design for Drupal, please come and get one.