Episode #173 Nathan Curtis - Start Full Screen: Organize, Communicate, and Annotate HTML Prototypes
Nathan Curtis and the team at EightShapes are experts at creating modular components and libraries for developing PDF documents. But as they transitioned away from static PDFs to HTML prototypes this approach had to adapt as well.
Nathan and Adam Churchill address some unanswered questions from the live virtual seminar in this podcast:
- Should you start with sketches and then move to HTML?
- Do the modular techniques work for complex web applications?
- What's it like to work with a visual designer with this type of workflow or process?
- How does viewing grids of pages work on smaller devices?
- Are you using media queries for creating responsive designs?
- Why wouldn't you just use something better and more advanced for prototyping like Axure or Fireworks if you’re not producing production-ready code?
- Does using components and libraries lower creativity?
Nathan Curtis: Good to be here, Adam.
Adam: For those listening who weren't with us for your awesome seminar, can you give us a bit of an overview?
Nathan: Sure. We talked in Start Fullscreen about EightShapes' approach to prototyping and how we've built a library to support the various aspects of our user experience design process in the form of HTML. Really, it's divided into four parts and we spent the first 15 minutes or so just talking about the rationale and how many of us had taken up HTML prototyping. We use a lot of the existing kits that are out there like jQuery and 960 Grid and Foundation from Zurb and lots of other things. But really, it wasn't meeting the needs of what we do from a client services perspective in delivering our product and communicating it well to our clients. The subsequent three parts of the seminar covered first modular thinking and how we wrote scripts so that we could divide or chunk out our design into pieces like the header and the footer, navigation, and repurposing all of them in modular ways so that we can reuse them across many different pages and also really control our code base a little bit better and collaborate better with it. The second of the three parts was how we organize our experience and really take advantage of CSS3 to rescale entire pages down so that we can load multiple pages into the browser at once, show flows or galleries of pages, position them side by side to make decisions around design alternatives, which when you're working in a browser typically you're just hitting forward and back in the browser and it doesn't work as well to actually see and compare things side by side. And then the last part of the seminar, we talked a lot about how we annotate designs. Really, when we reduce the size of the page in a browser window so you can see it at a smaller, maybe even at times thumbnail size, how do you label it? How do you describe it with different notes? How do you do a lot of the common things that you do when you're using .pdfs and wireframes, but in the context of doing HTML instead? We've had varying degrees of success with that. Sometimes we never even need to do that. But creating a framework enabled our team to do this consistently for the clients across the 12 designers that we employ in varying ways for them over time. So it's a good exploration with that and then we really concluded with a little preview of some things that we do to responsively design in that context, too.
Adam: Let's get to some of the questions that we had from the audience. One was that folks were wondering if you start naturally from sketches then into HTML, does your team at EightShapes avoid the boxes and arrows stage all together or is there a similar element that you folks are using in the early stages?
Nathan: There are projects, admittedly, where we don't do any site maps and we don't do any sort of wireframes at all. We just go straight into code. Maybe we sketch first with some Sharpies, but it's because we have libraries built for specific clients that have all of their components already established. A client that we have is Cisco, and they have a big modular library of stuff. We know what their header is. We know what their heroes, so to speak...Billboards at the top look like and how they function. We know how they put tiles all over their pages and use RightRails and so on. In those cases, yeah. We go straight to HTML and it becomes more of a strategic content exercise rather than a UI design or page layout exercise because those modular bits are already established. But on most of our projects we ignore boxes and arrows and some of that design planning at our own peril. When we're working on complex web applications, you really still have to think through those bigger implications and think about that forest of the entire design system, how people are going to traverse across pages, how they're going to really go in and out of different interactions on specific pages before you start building everything. If you go straight into HTML you really run the risk of building and then rebuilding and then rebuilding as you iterate without really having a clear sense of where you're going. And so, be it site maps, be it really conscientious sketching, there's lots of things that we do that precede going into HTML in many cases.
Adam: I think this question relates to some of the examples that you showed earlier on in the seminar. The comment is, "This design is a pretty simple content layout." The question is, "Do the modular techniques work for complex web applications?"
Nathan: Yeah, for the purposes of the seminar we focused on a really simple trio of layouts that are standard desktop web pages. They had a header. They had a footer. One of the pages had a big grid of paintings. And another layout was actually a page describing a specific painting that had that painting really large and it had descriptive information next to it. And yeah, I think it's a legitimate sort of instinctive criticism to say, "Oh, these are really simple designs. Your framework works on really simple stuff, but what about sophisticated web apps?" We actually do a lot of that design, but those prototypes take a little bit more time to build, admittedly. And I didn't have any prepared to share because some of the basic concepts are harder to grok with those more complex apps. We do things like...During our design process we were working on a blog site. We asked questions like what if this thing was like Twitter for iPad? You had all these panels sliding in and out. What would that feel like? How can we make each of those panels perhaps repeatable in a modular component so that we extract those and one person's working on those and another person's working on the header and the sidebar. And we also had really detailed patient record applications that we work on, too, where you have a lot of different components, a lot of different UI limits. And actually, it's to our advantage to modularize those so as we collaborate across, say, two or three or four user experience designers you really have to divide and conquer the work. The bottom line is you have to prototype in these situations and you have to actually figure out a way to segment the work so that you can all share common assets but also drive towards your individual responsibilities. And working in a flat environment, I would argue makes that harder that it does when you're working in HTML with some of the opportunities you have there.
Adam: What's it like to work with a visual designer with this type of workflow or process? If you work side by side with developers in a lean approach, would you suggest building prototypes that could produce production ready code or stick with this Blocks framework?
Nathan: That's really two questions in one. Let me tackle the first one around working with a visual designer. We've had a lot of success getting rid of our typical process of two to three weeks you iterate and refine and stabilize your wireframes and then the visual designers starts to get involved and sets a visual direction. And then, once those wireframes have been done, you just do the concept of each of those page types. I've tried to disrupt the process here at EightShapes to varying degrees of success, but it's been really rewarding most of the time. We actually sat down next to each other and from the ground up, for four or five days straight, we built a web site. We did all the visual design and we made all of those decisions together by really forcing each other to ask questions in real time. I would point at the screen and say, "What are you doing with this button here? Is it really going to overlap with this other area of what you're trying to visually design in that way? Does that work right?" And at the same time, there's a visual designer, Jody, I work with and she'll point to the responsive prototype I'm building and say, "What's with that percentage based gutter you have in between those two columns? Is there any way we can make that fixed so that it doesn't become really large when the page width gets really large." We really push each other and I think that face to face direct collaboration really benefits the time that it takes us to do it. It does come with a little cost, however. It does disrupt our typical ways of doing things. I remember she remarked, "I've got this whole comp that I can create to depict an entire page and solve all the problems together, but when I'm designing...When you're prototyping next to me, I end up not having any representation of the page design at all and I'm just working on all these little micro component or elements...Things to get you the CSS kind of definitions you need to prototype it in code because the prototype ends up becoming what we share with the client, not .psd files." And so there's a little tug there. There's a little exiting your comfort zone and trying to share the definition of what the design is. That comes with a little bit of a cost. The second question you asked, I think, regards more the use of production ready code. When you said, "When you're working side by side with developers on a lean approach, would I suggest building prototypes that use production ready code?" Absolutely. If you have a starting point of production ready code and you have designers that are capable to sustain that quality of code and quickly realize the design, then definitely stick with production code. I would characterize though that, at least at EightShapes, we don't find that those conditions apply in two ways. The first way is we don't often find ourselves sitting side by side with developers based on the way that our consulting services work. We're more typically trying to finalize the design and overlap our design process with development. But it's rare, if ever, that we would get a client to actually sit with us, side by side. But the other thing, I think, is that for most of us at EightShapes as user experience designers, myself included, we don't have neither the confidence nor the capability to quickly execute production level code while still meeting the time constraints we have to solve the design problem If that means that as designers we take shortcuts. We don't label our form elements. I'll be honest, I don't even put a form tag but we use an input tag for a text box. Heck, yeah, we'll do it because your responsibility isn't doing that production level code. It's solving the design problem. I'm fairly adamant about that, because I'd rather see designers prototyping to realize a better design solution before I see designers get hamstrung and frustrated and take a lot longer because they're trying to solve production problems during a period of the project that doesn't warrant it.
Adam: A couple of questions involving designing for devices. How does viewing grids of pages work on smaller devices?
Adam: Nathan, you mentioned media queries. Are you using them for the responsive designs that you folks created?
Adam: A couple of our audience members were looking for some reconciliation on some things that you were talking about. On the one hand, you tout reuse and efficiency. But on one point in the seminar you explicitly denounce making your code reusable for production. I know we just talked about that a few minutes ago, but for this particular attendee, can you reconcile those two?
Nathan: Yeah, it really depends on conditions that you're finding yourself engaging into the process because let's take EightShapes. We're a design consultant. We get hired by our clients to do design engagements and deliver the design. We don't do development. We don't implement sites. We've done it maybe two or three times in our six year history and we don't do anything like database or application development. And so, our focus is just getting the design right for the most effective cost and in the fastest time that we can for our clients. And so when you layer some of those assumptions on it, you're darn right. I don't care about production level code. I'm caring about solving the design problem because someone else is going to be building the templates or building the application layer and it's really their responsibility to do that stuff. It's not like I'm trying to pass the buck, because I think in certain times what I would prototype would help educate them and really feed their appreciation for the nuance of how they should build it. But even in house at EightShapes, I fancy myself a moderately good HTML and CSS guy. We have another guy, France, who is a total whiz at HTML and CSS and he does a lot of our production level template creation. He always looks at my stuff and he sees all the shortcuts I make whereas the client's very happy with the solution of the design problem, he'll throw it all away anyway, even though we work together because he knows that there's a better way to adapt that markup to work on Internet Explorer 8, to work on a Blackberry, to work on all these different types of browsers that degrade in various ways. Whereas I'm trying to keep those things in mind, how those things will degrade but I can't, in my design process, express all those things. That's the kind of denouncing making code reusable for production that I'm talking about, whereas the reuse and efficiency we're talking about is just making the design process and the collaborative process across designers in the same project work smoother and work faster. That's admitting all my own biases and where that viewpoint comes from.
Adam: One of our attendees was looking for you clarify the payoff. If not production code, why wouldn't you just use something better and more advanced for prototyping like Axure or Fireworks?
Adam: You talk about annotations, and a comment that some of the examples that you were showing, they seemed fairly sparse. So a concern is do the developers of these designs end up asking a lot of questions?
Nathan: Absolutely. Isn't that wonderful when they ask questions and it's not like this big wall you throw this stuff over? Actually, that's kind of the point with a lot of these more contemporary processes like Agile, is to create the conversation so you don't need to document everything. The documentation is this sort of contract that you have by the nature of the communication you have between the members that should be fluid and constant and deep to develop that shared understanding. We have projects that are like that. There was an example in the seminar that I showed called "Saving the Dream." It was a small website. We did a responsive design and we used HTML prototyping and it was great. But actually we did a lot of this work in such close collaboration with all the different participants in that design and development process that we didn't use any annotations at all. It was kind of ironic because I was building this whole tool that enabled you to exit full screen and put all these annotations next to all of your designs and compare them and so on. And I didn't annotate anything. And you know what? Sometimes you don't have to. That's really, really a great thing but there are other conditions, like this electronic health and medical record project I'm talking about. 35 developers all spread across five different tracks of work. It's just this massive scale. I'm just trying to communicate patterns like, "When you're going to a subpage, you're going to have this navigation on the upper right where you can traverse the subpages without going back to the hub of the main page." That's something that I need to communicate to everybody. That is something that needs a little bit of documentation. That actually would be a pattern that we'd be trying to build into the design system. In that case, it's entirely appropriate to develop that documentation to answer those questions on my behalf because I can't talk to 35 people at once.
Adam: This section on reuse and components in the seminar, it talked about how to include different components. You didn't apply...You have a library of components you use most often in this system like a calendar picker, for example. Are you building a library for those, too?
Nathan: Not really. In fact, like I mentioned at the beginning of the podcast, we do have some client specific libraries that help us render designs fast because all of the components in the visual design system, all of that's already established for us. We don't need to build that every time. But on our projects where it's kind of a blank slate, we've got a big white canvas, that's really your place to create the new design system from the ground up. We might use some tools like Twitter Bootstrap or other types of libraries that help give us a little bit of a head start on those things, but we almost always develop most of the components from the ground up ourselves. That was really the spirit of the framework that I was trying to create with EightShapes Blocks because I actually tried to control almost nothing about what goes in that white box where you actually see the screen design. When you're in full screen view, it's the full browser window. The only thing we put on top of the design were just boxes that identified where the components were. If you look closely, nothing else is controlled inside that white box. Instead, we really tried to focus on how to communicate around the design and communicate things about the design outside that box.
Adam: Nathan, you showed a lot of screenshots with the audience and in the header of each there was a component section that had not been shown. Can you tell us about that?
Nathan: Sure. This is actually referencing when you leave the full screen and you essentially reduce the size of your page design so that you can show it next to other pages or you show it with notes next to it. There is this header navigation for what, in essence, is your deliverable of the prototype. It has, in the upper left, it tell you, "This is the prototype for the 8Shapes Gallery of Painters." And on the upper right there's a navigation to get to a home page that we built, the gallery of pages that are a part of the design. And then next to that is a gallery of components. We've actually built out a way to take the components out of the context of each page but still present them in a meaningful kind of grid automatically. And so that you can traverse things like, "Oh, that's what the header looks like," or, "Oh, that's what the navigation on the right looks like." Here are four different variations of that navigation that I can look at next to one another. It's kind of a bigger challenge, though, because when you take the components out of the context of the page, they really lose a lot of the context of what kind of container, how wide should they really be when we take them out of their context of, say, a column of the design. And also, sometimes they inherit some of their style properties from tags within the page layout that aren't actually part of the component code but might exist a little bit higher in the document object model that they're contained within. So we're still working on it. We didn't share it during the seminar because it's a little bit crude, but still actually effective when you add a few more layers of detail. But I wouldn't say it's smoothed out for the masses, so to speak.
Adam: Nathan, at EightShapes when you are reusing these modules and code across different projects, are you running the risk of lowering creativity?
Nathan: That's actually kind of a softball question around patterns in general and reuse in general because sure, in some projects like the client specific libraries where the visual system's already defined and you have headers and footers and other things you can reuse. Absolutely you want to reuse those over and over again. That's why you built the libraries in the first place, to create consistency, to increase efficiency, to reduce maintenance costs. But there are many in the user experience discipline that disagree with the concept of patterns because they feel that it really reduces the creativity and the license a designer has to solve design problems. I think design happens all the time within a set of constraints that many of which you can't control and many of which you should actually embrace as a way to help you narrow the scope of the design problem you actually need to solve. That means that if you're working within a website design where the header and footer is already defined for you, the object of you working on a specific page within that overall design system is just the body of the page. You should reuse the header and footer. If you're working within the context of a form where someone needs to select a date, should you be developing a date picker that looks like a miles per hour gauge on a car dashboard with a little lever that you're rotating in a polar coordinate like way? No, that's ridiculous. That's not a way to pick a date. Show me a calendar. Let me pick Monday on...The third Monday of that particular month. It's an established way that people already recognize and can really accomplish successfully. There's a reason patterns exist. Hopefully it is to heighten the usability of a lot of the different solutions that we create. It really is not that the designer is less creative, but they're exercising judgments to adopt the conventions that they can use to their benefit, like a header, like a calendar picker. And then apply their design critical thinking to the areas of, "Should I really use two date pickers next to one another? Should I have these on successive pages?" Really, those kinds of choices end up tailoring the use of those patterns to the specific problems at hand.
Adam: One of our audience members wanted to know if he could contribute features to Block, since its sources are available on GitHub.com.
Nathan: Oh, that would be a dream of ours. I think, just like with EightShapes Unify in 2009, we had a lot of folks that contributed patterns of pages that people would use in .pdf deliverables. We tried to incorporate those and it was a lot of fun. But it's really not our expectation. If the community uses the tools, some people download this and find it useful and they're interested in extending it, by all means. The thing that I probably have less experience with is how to coordinate those contributions and the interesting part of the journey, for me, and I think for EightShapes in general is treating it like a product, right? This thing has features. This thing has priorities. This thing has phases that we need to really release it out into even our own EightShapes community of designers to use on projects. Some things are stable. Some things are experimental, but being able to address that over time has been a much different challenge than working on design services contracts that are fairly common within our culture here. But you know, I'd be interested to learn from, and even incorporate, the good ideas that arise so if you have them, don't be shy.
Adam: That's awesome, Nathan. Thanks for joining and circling back on some of these great questions from our audience. For everyone listening in, thank you for your support of the UIE Virtual Seminar. We appreciate you joining us. You can get all the details on upcoming seminars at UIEVS.com.