DesignAday

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 Nicola 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.

15 Reasons

You should attend my workshop if:

1. You want more control over the realization of your design.
2. The developers you work with are getting tired of you pestering them to “move it a few pixels to the left”.
3. When you look at your CSS in Firebug, half of it is lined out.
4. Your files aren’t under version control.
5. You would like to know who edited your style sheet and messed up your layout.
6. You are up for learning how to make UI behavior easier to maintain by reducing the amount of JavaScript necessary.
7. You feel guilty asking a developer to change the color… again… when they have performance requirements to hit.
8. You think there may be a better use of the time you spend specifying type sizes and pixel dimensions in an InDesign document.
9. You have wondered why you bother putting so much detail into a spec when they don’t follow it anyway.
10. You are interested in optimizing your CSS for reuse, turning styles into plug-and-play components.
11. You would like to create a functional design pattern library for your product.
12. You currently hand off an HTML mockup to your developers and hope they don’t screw it up.
13. You’ve ever fantasized about checking in your own code.
14. There’s stuff in this list that you feel like you should know, but don’t yet understand.
15. You want to take control of your destiny as a user interface designer.

My workshop, Sitting in the Driver’s Seat: creating production-ready CSS, will be on Sunday, January 27th, from 2:00 to 5:00.

…and then we got acquired.

IxDA Pittsburgh had an outstanding event tonight hosted by Confluence on the North Shore. The topic was UX Within an Organization, and our panel had a lot of wisdom to pass around:

• Gary Minnaert, User Experience Architect at Confluence
• Maria Emerson, User Experience Director at Intermedix
• Ian DeJesus, Interaction Designer at Viz | General Dynamics C4 Systems
• Anna Abovyan, User Experience Designer at M*Modal
• Minette Vaccariello, Experience Design Manager at UPMC Health Plan

Ryan Cummings, Manager of User Experience at Dick’s Sporting Goods moderated, leading us through discussions of work environment, organizational structure, designer/developer collaboration, in-house challenges, and growth, among others.

Something that struck me right at the beginning, as each of the panelists gave us a little background about their careers and their companies, was that many of us share the same basic story. We were one of a couple, or the only designer, at a relatively small firm, and then we got acquired by a much larger company and had to establish a UX presence within it. It doesn’t make my job any easier, but I rest assured that I’m not alone on this journey.

Of course, the topic of a designer’s ability to code also came up. I really liked Francisco Souki’s comment. He’s a Game Designer working at Schell Games, and he observed that Interaction Designers in industry have a battle to fight that he doesn’t have. In the gaming industry, it’s a foregone conclusion that a designer is needed on a project. Francisco went on to say that a Game Designer is not expected to code, and in fact, the developers would never let a designer touch their code, but they create tools with which the designers can tweak things. A tool may be nothing more than a text file with a bunch of dimensions in it. That sounds an awful lot like a stylesheet. Hmmmm. Don’t forget, I’m running a workshop at Interaction 13. You too can learn how to replace your specification documents with production ready CSS.

Sitting in the Driver’s Seat

I have some exciting news that I’m finally able to share. The Interaction 13 program has been announced, and I’m part of it! I’ll be running an afternoon workshop on Sunday, January 27th. Registration for the workshop costs $200 through November 30th, after which the price rises to $300. There are only 30 seats, so book it now.

Sitting in the Driver’s Seat: creating production-ready CSS
workshop with Jack Moffett

CSS 3 has handed the keys back to designers. With a syntax and structure that speaks our language and a fine-grained level of control, it empowers designers to not only prototype in the actual medium, but to contribute production-ready code. The days of pointing at the screen over the developer’s shoulder and trying to explain how something needs to shift three pixels are over. In fact, much of the JavaScript currently employed for simple UI behaviors can be replaced with well-architected styles. Take the driver’s seat, and make the CSS your UI specification document. This workshop is intended for intermediate designers interested in gaining more control over their team’s final product. As a participant, you will:

• Familiarize yourself with the tools you’ll need to integrate with your development team.
• Learn how Object Oriented CSS (OOCSS) can lead to cleaner, more maintainable code.
• Discover how to replace heavy-handed, inefficient JavaScript with CSS-driven behavior.
• Get started on your own library of CSS components.

Working with Developers: 12 and counting

One of the great benefits of having worked at the same company for 12 years is that I have developed an outstanding working relationship with the developers. Literally every developer I work with has an appreciation of my role in a project. They understand how my design tasks relate to their development tasks and how the whole process weaves together. They know what questions should be asked of me and which decisions I should be approving, and they actively seek me out of their own volition. More importantly, they recognize that my work makes the output of the team better, thus making us more competitive in the marketplace. Upon attending my talk, Working with Developers for Fun and Profit, a couple of my coworkers expressed dismay that our methods were not commonly practiced throughout the industry.

In a recent discussion, my manager pointed out that once upon a time, if the developers had been instructed to take our customer’s requirements document, develop a solution, and build it, they would have done so. The result would have been similar to any other programmer-designed UI, but they would have done it. If given that charge today, the same developers would likely throw up their hands and say, “Hold on! We can’t do that without Jack (or someone of my talents).” They know that the result would not be on par with our typical work.

I say this not to brag, though I do take pride in it, but to illustrate the value of putting in the time (years, in fact) and effort to learn to communicate, build the relationships, teach the process, and adapt to your development team.

My talk on working with developers was not accepted to Interaction 13, but there will be other opportunities to learn from my experience. Stay tuned. 

A Deep Bench

My band has a deep bench. We are all multi-faceted. I’m the drummer, but we have another guy that can play drums, and a third that will cover in a pinch. The two of them are both guitarists, electric and bass, respectively, but they can both play acoustic. Our lead guitarist can also play keys. We’re all better than average singers, each one able to sing lead or provide harmony. You can understand how important that is to a praise band that has to lead worship every Sunday. We each have to miss occasionally for business trips and family vacations, and the ability to cover for each other is invaluable. But more than that, it makes it more enjoyable. I’m happy for the opportunity to step out from behind my set and give my vocal chords some exercise.

Interaction designers often make the argument that they don’t need to know how to implement the UI, or they don’t have to be good at visual design, because they work in teams that include members with those skill sets. I would argue that your design team is going to be more efficient, more effective—more successful—if you have a deep bench. If every designer in your group can contribute to the visual design, help produce graphics, create wireframes, structure content, write HTML and CSS, lead customer meetings, and gather user research, you are going to have a much more flexible team capable of doing more than if each person focused on one of those activities.

At An Event Apart in 2010, Jared Spool stated:

“Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.”

If you currently have a team of segmented roles, the good news is that that’s the perfect place to start. All you need to do now is cross-train. Build yourself a deep bench.

It’s Away!

There are only a couple days left until the deadline for Interaction 13 submissions. I just got mine in. In addition to my talk, “Working with Developers for Fun and Profit”, I achieved my goal of submitting a workshop. In fact, I submitted two. Hopefully, one or the other will be selected. With my teaching experience, I do believe that conference workshops would be an excellent fit for me.

Introduction to Typography

Typography is one of the foundations of design. It should be part of the fundamental training of a designer, whether pursuing Graphic Design, Interaction Design, Industrial Design, Information Design, or Service Design. Unfortunately, due to the limitations of technology, especially on the web, typography was given short shrift. Designer’s control of type was hamstrung, so the importance of learning the finer points of working with type diminished. A large percentage of Interaction Designers don’t have a visual design background and have not been exposed to typographic training.

Now, with the advent of web fonts and services that provide them, typography on the web is seeing a resurgence. CSS 3 provides fine control of type, making it, once again, a powerful tool in the hands of those that know how to wield it. We are the caretakers of an art that has been under development since 3200 BC (cuneiform)—the very architecture of visual communication. As such, it is our responsibility to become proficient in the use of type as a method of communication, a means of expression, and an element of usability.

Intended primarily for typographic beginners, the goal of this workshop is to:

• Provide a basic vocabulary with which to discuss typography
• Give a historical overview of typographic evolution
• Instill a foundational understanding of how type works in print and on screen
• Demonstrate the implementation of type with contemporary web technology
• Elicit an appreciation of, and passion for, well-executed typography

Sitting in the Driver’s Seat: creating production-ready CSS

CSS 3 has handed the keys back to designers. With a syntax and structure that speaks our language and a fine-grained level of control, it empowers designers to not only prototype in the actual medium, but to contribute production-ready code. The days of pointing at the screen over the developer’s shoulder and trying to explain how something needs to shift three pixels are over. In fact, much of the JavaScript currently employed for simple UI behaviors can be replaced with well-architected styles. Take the driver’s seat, and make the CSS your UI specification document.

This workshop is intended for intermediate designers interested in gaining more control over their team’s final product. As a participant, you will:

• Familiarize yourself with the tools you’ll need to integrate with your development team.
• Learn how Object Oriented CSS (OOCSS) can lead to cleaner, more maintainable code.
• Discover how to replace heavy-handed, inefficient JavaScript with CSS-driven behavior.
• Get started on your own library of CSS components.