The Birth of a Book: Part 2

Read Part 1

So, several days after Interaction 13, I received a “short book” proposal form. The Acquisitions Editor was on the fence as to what format the book should be. I was given the options of a “short, concise book” to be marketed as a hands-on, practical guide, or a “short format project”. They sounded like the same thing to me, but it turned out that the former would be around 200 pages, while the latter would be 120-140. That’s the difference between a typical book from Rosenfeld Media and one from A Book Apart.

Having never written a book before, I really didn’t have any idea how to estimate the number of pages it would be. We decided to shoot for 200. At the same time, I suggested including information from my talk, Working with Developers for Fun and Profit, making the book a blend of practical, professional insight and tangible, technical instruction. So, I started putting together my proposal, which was quite a bit of work in and of itself. It took me just under four months to complete, though I admit I wasn’t dedicating much time to it.

To be continued…

Exciting News!

I’m at Interaction 14 in Amsterdam this week, so I won’t be posting regularly, but I wanted to let you know about some exciting news. It’s exciting for me, and if you enjoy reading DesignAday, I hope it is at least a little exciting for you as well. I’ve written a book.

A year ago, I presented my workshop, Sitting in the Driver’s Seat, at Interaction 13. I was contacted by, and met with, a representative from Morgan Kaufmann. During the next few months, I put together a proposal for a book that would incorporate both the workshop and the Working with Developers for Fun and Profit talk that preceded it. Eventually, a contract was signed and I began writing the book in August. Given that I was a first-time author, the publisher didn’t want me publicizing the fact until they were sure they had something they wanted to take to press.

I’ve finished writing, and the book is going into production. It is titled Bridging UX & Web Development: Better results through team integration. The first half of the book covers collaboration, process, tools, and documentation. The second half is HTML and CSS exercises intended to help designers improve existing coding skills to a point at which they can contribute to the production codebase, giving them more control over the final product.

It’s been difficult to keep this bottled up for so long. I do intend to write posts about the entire process, and of course I’ll be keeping you informed of progress from here on out. Stay tuned.

Unicorn Quest - Part 5

Dave Malouf points out three benefits for designers that can code. The most important one, and I agree whole heartedly, is control. When you can implement your own designs, you aren’t dependent on someone else’s attention to detail. You don’t have to worry about whether or not they care enough to follow the spec. You don’t have to book yourself on somebody else’s schedule to look over their shoulder and tell them how many pixels to the left an element must be moved. You aren’t limited to submitting bugs at the end of implementation in the hopes someone has time to fix all the trivial mistakes that were made simply because the developers aren’t designers. You can implement the UI correctly to begin with, and when you do see something off, you can immediately address it. The final product matches your design because you were able to shepherd it through implementation.

The other two benefits Dave lists are:

  • By knowing the technology we can tinker in it
  • Experience it instead of visualize it

He’s right on the money. The importance of serendipity during the design process shouldn’t be undervalued. When you implement your designs, you are not only tinkering with the technology, but extending the time you are able to spend thinking about, working with, and refining the UI. Design is an iterative process, and the more iterations you have, the better your end result is likely to be. Implementation provides more iterations—iterations that allow you to live with the functioning application. That is invaluable.

Dave also mentions some perceived benefits that he considers less valuable:

  1. Speaking like a developer.
  2. We can work faster.
  3. Designers need to understand technology.

I’m in agreement with Dave that, while these may be of some value, they do not require one to know how to code.

So far, Dave and I seem to be on the same page. We agree on the benefits. We have minor differences of opinion on potential drawbacks. But Dave has a big concern about how designers spend their time. I’ll address that tomorrow.

Leanings: Part 2

Yesterday, I reviewed the premise that Jeff Gothelf based his argument for Lean UX on. With that out of the way, let’s take a look at what exactly Lean UX is.

Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.

A couple things strike me right off the bat. First is the term “deliverables”. He actually means documentation. Not all documentation is delivered (to the customer), and I’ve created plenty of prototypes that were delivered to the customer, so that’s a little misleading. Second is the goal of being “faster”. I’m not going to pick on this too much, because Jeff is clear that Lean UX is intended for startups and quick-to-market product strategies. Speed is important in that context. I just point it out because it’s important to keep this in mind as we continue. Faster is not always the main goal. Faster often requires trade-offs with other goals,.

Now we come to an aspect of Lean UX that I’m completely on board with. Jeff says we can’t have solitary designers perfecting every pixel in private. We must collaborate with the entire team early and often. And while I’m in complete agreement, I don’t think this is something for Lean UX to hang its hat on. This applies to every type of design and has for years. Important? Absolutely. Unique to Lean UX? Definitely not. Moving on…

Next Jeff lays out the Lean UX process: Concept > Prototype > Validate Internally > Test Externally > Learn from User Behavior > Iterate. At first glance, this just appears to be a typical, high-level design process. What you must realize, however, is that this is the detailed process. Concept doesn’t have sub-steps in which you brainstorm on a whiteboard, formalize those sketches into wireframes, and annotate them with notes about behavior. Jeff proposes that “the initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction.” What he’s inferring is that once you have a quick whiteboard sketch, you’re ready to start creating a working prototype. Spending time revising and documenting that sketch is wasteful. That’s not to say that you go with the very first sketch—there is still iteration—but there isn’t much refinement.

In some projects, this is a perfect approach, and I’ve done just that. I’ve rapidly sketched and iterated a UI concept, showed the sketches to a developer to ensure technical feasibility, and then scanned in the sketches and hooked them together to mimic navigating through the application. I presented the prototype to the customer to get their buy-in on the approach. I chose this process because it was a non-standard method of navigating the content that I thought would be particularly suitable. The customer agreed, and I continued to flesh out the details.

In other projects, I consider a prototype to be more time consuming and wasteful than some simple documentation. If I’m designing a multi-page form using tabs, I don’t have to create a working prototype for the customer to understand how it’s going to behave. They are familiar with tabs.

What I’m most uncomfortable with in Jeff’s description is the lack of any kind of formal documentation of decisions. Sure, you can throw up a rough flow on a whiteboard and hash it out with the product owner, but what are you going to do three months down the road when another stakeholder asks a question about the flow and is pressuring the team to change it? You know you had a reason for doing it that way, but it’s gone through several revisions, and you can’t quite remember the rationale. Wouldn’t it be great if you could quickly check a wiki page or PDF to see the history of decisions that led to the current design? I don’t mind admitting that I bounce around from project to project so often that I have a hard time remembering off the top of my head what I did a few days ago, let alone months. But when a developer comes to me with a question, I have a folder within reach that will provide the context necessary to focus my thoughts.

So far, the only thing that sets Lean UX apart from plain old UX is the abandonment of documentation. I don’t see much value in that. Perhaps we’ll find something more tomorrow.

Cobwebs

It doesn’t happen often, but occasionally I get the opportunity to completely replace the HTML and CSS for a particular product screen. I’m able to start from scratch and create a clean structure with modular components. I get to throw out all of the cruft that was hanging around from IE 6 and make sure that the CSS is organized and follows our formatting standards. It’s liberating. Cherish such moments.

Designer’s Toolbelt: Macaw

When I first began learning to design websites, I used the brand-spanking-new Adobe Pagemill. Who needs to learn code? I was a designer, not a programmer, and I wanted the freedom of the WYSIWYG tools I was used to using for print. The computer should do the boring work of figuring out how to actually specify it. When GoLive Cyberstudio released, I jumped on it. I continued using that tool after Adobe purchased it, and I eventually switched to Dreamweaver after Adobe acquired Macromedia.

By that time, I had graduated with my Masters and was working for a software development firm. It didn’t take long for me to realize why the developers turned up their noses when they saw the HTML I was handing them. Fortunately, I had been working with it long enough that I had developed enough understanding of HTML to be able to start coding by hand. Once I got my hands on CSS, you couldn’t pay me to go back to a WYSIWYG editor. These days, I’m a huge proponent of Object Oriented CSS (OOCSS), speaking at conferences and leading workshops about working with developers and contributing directly to the production code base.

So, it was with much interest and a hint of disdain that I took a look at Macaw, “the code-savvy web design tool” under development by Tom Giannattasio and Adam Christ. I must admit, I’m impressed with what they have shown so far.

Stop writing code. Start drawing it.

Macaw provides the same flexibility as your favorite image editor but also writes semantic HTML and remarkably succinct CSS. It’s time to expect more from a web design tool.

This tool is pretty slick, and you can tell that it has been thoroughly designed by a designer who understands typography, grid-based layout, and code. You can tell that it has been built to address all those little annoyances we web designer/developers face daily. From readouts that tell you things like the number of characters per line, to supercharged key combos for quickly aligning objects (pudging is going to make your heart skip a beat), the application looks to be chock full of awesome.

And then there’s the code. I’m awed by how intelligent their aptly named Alchemy engine is.

We wanted Macaw to write code you’d be proud enough to hand to developers. Current applications rely on trendy frameworks, export rigid positioning and generate ridiculous IDs. We think designers and developers deserve better. Macaw’s powerful, patent-pending engine is called Alchemy and it can do some incredible things.

Alchemy analyzes every possible selector to describe your document and determines the most succinct way of using them based on logical criteria: applicability, specificity and semantics.

Macaw offers designers the freedom of absolute positioning within the interface but will convert to a static document flow upon export by calculating the necessary margins, padding, floats and clears. It’s the best of both worlds.

There is an incredibly elegant outline palette, reminiscent of Photoshop’s layers palette, that not only serves as a method of hiding and showing elements within your page, but also creates the semantic linking between elements and the classes that will be generated in the CSS.

I’m just scratching the surface here. You really should check it out for yourself. I’m not saying I’m ready to start generating all the enterprise web applications I work on in this way, but it sure seems like an excellent tool for sketching, prototyping, and then moving your prototype to usable code. It’s leaps and bounds beyond any editor I’ve seen before. They say it’s coming to the Mac App Store soon. I’ll be following their progress with great interest.

Code Reviews

In my Working with Developers for Fun and Profit talk, as well as in my Sitting in the Driver’s Seat workshop, I expound the benefits of tight integration with your development team. A large part of that is participation in implementation. I’m continuing to push this philosophy within my own company.

Did you know that developers carry out iterative design critiques, just like we do? Of course, they are critiquing the design of their code, and they have tools that support that activity. This week, I’ve been working to adopt the code review practices that our developers have been using for years. I can’t stress enough the importance of ensuring that the HTML and CSS that goes into your product is thoughtfully architected and written to be maintainable by the whole team. Code reviews help to enforce use of formatting and naming conventions, as well as code comments, and they allow all participants to share their knowledge and cross-train best practices.

Unforeseen Benefits

It seems obvious now, but when I was working on my conference workshop of Interaction 13, I really wasn’t thinking about it being of particular benefit inside my company. I’ve been the sole interaction designer for so long, I don’t give as much thought to knowledge sharing as I probably should. Since the acquisition, however, we’ve had an influx of work, and due to a number of mostly unrelated circumstances, I’ve recently been charged with training a junior graphic designer to assist in front-end implementation. The exercises I developed for Sitting in the Driver’s Seat are perfect for this purpose, and she is quickly coming up to speed on OOCSS and the standards I employee.

On a related note, IxDA Pittsburgh is currently planning to put on my workshop in May. If you are in the area and interested in learning how you too can participate in implementation and contribute production-ready CSS, stay tuned for an official announcement.

Interaction 13: Workshop

Upon arriving in Toronto Saturday night, I discovered that the conference organizers had provided me with a list of attendees, including their job titles and the companies they worked for. I was very interested to find that they ranged from the standard “Interaction Designer” up to managers and directors. I was a bit intimidated by the fact that there were two software engineers registered. This was going to be interesting. What would they think of my push to get designers involved in implementation, and how would they receive my approach to replacing JavaScript DOM manipulation with simple class swaps? Would they actually find the workshop valuable, or would it all be old hat? I would soon find out.

I presented my workshop, Sitting in the Driver’s Seat: creating production ready CSS, Sunday afternoon at Interaction 13. There were nine attendees, and everyone seemed to have learned something useful from it. Their technical abilities varied, but they were all able to follow along and understood, at least in concept, if they weren’t able to complete the more involved exercises on their own.

I began with an introductory slide deck that I’ve posted on Speaker Deck. I explained why I think it is important for designers working on web-based applications to not just understand HTML and CSS, but to master it, so that they can contribute directly to the production codebase. I talked about the tools they should be using, and then we got into the code. We started with a simple CSS formatting exercise in which they had to fix a CSS file to adhere to the formatting standards proposed by Nicolas Gallagher in his Idiomatic CSS. Then they used a diffing tool of their choice to compare their work against my corrected version.

After that warmup, we dove into OOCSS. I used Amazon’s homepage as an example, challenging them to reformat the “Get yourself a little something” component so that with a single class swap, it could be changed from the horizontal layout to a vertical layout, matching the “Best Sellers” column also found on Amazon.com.

Finally, we went over the benefits of defining state through CSS, rather than JavaScript. The attendees had to write CSS that would change the display of entries in a contact list, showing and hiding various elements,

In the end, while I could have used a little more time, I successfully fit the content into the three-hour event. Reactions were very positive, and I’m looking forward to giving the workshop again. So, what did the developers think? I’ll let Anton tell you about that in his own words

Interaction 13 - Bring it!

Tomorrow, I’ll be driving up to Toronto where I’ll be attending Interaction 13 all next week. I will kick off my conference experience by presenting my workshop: Sitting in the Driver’s Seat: creating production-ready CSS. I have my slides ready (well, mostly), and I’ve created a number of CSS exercises that we will be working through. There are still seats available, by the way. I’ll be encouraging attendees to get involved in the implementation of the web applications/sites they design. To do so, they really ought to know how to create good, clean, maintainable, reusable HTML and CSS components. I’ll be showing them how to do just that.

One of the great things about giving a workshop is that I’ll have it done and out of the way before the conference proper starts, so I’ll be able to fully enjoy myself. There are a lot of people I’m looking forward to seeing, and a lot of food I’m looking forward to eating. Oh, and there are those presentations I’ll be attending, too.

If you are going to be at the conference, please find me. I’d love to meet you.