Future Practice Interview: Bill Scott

As part of our Future Practice webinar series, we’re interviewing presenters to give you a preview of what they’ll cover. Next up is O’Reilly author and Netflix Director of UI Engineering Bill Scott on the topic of interface engineering.

Lou Rosenfeld: Bill, what are some of the biggest disconnects between design and engineering?

Bill Scott: This depends on the role that design and interface engineering play within an organization. Sometimes the designer’s final product is an interface specification that might include wireframes, mockups, interface diagrams, and so on, with the engineers producing the HTML, CSS and other interface code. In other organizations designers actually produce HTML and CSS, and the engineers take this code and carve it up to work with various user interface technologies (like JSP/ASP/PHP/Rails). Regardless of the actual split, there is a natural disconnect in the actual “product” that each team is responsible for.

Design teams feel finished when they have produced a comp and the necessary graphical assets (or HTML/CSS). But the interface engineering team is just starting their work. The trick is to get interface engineers involved much earlier in the process (through design reviews and prototyping) and to get designers to stay engaged throughout the full production cycle (by understanding what issues arise from their designs and by setting their goal to be the full delivery of the experience.) Engineers are production focused. Designers are often ideation focused.

Lou Rosenfeld: Don’t many of the problems come down to the lack of a shared vocabulary?

Bill Scott: Absolutely; a recent round table discussion at Netflix brought that to light. The terms “component,” “simplified visual framework,” and “lockups” were discussed and very quickly we realized that engineering had a different definition for components and visual framework, and had no clue what the design team meant by lockups. The term lockup comes from advertising and was used to describe the movie box shot, movie title, add buttons and the star rating. Component had a much more rigid meaning for engineers as an interface control that could be packaged as a reusable software module (like a carousel control). Designers thought of this as being modules on the page (titles, header, footer) as well as the carousel control. The “Simplified Visual Framework” is a term we use to describe the system of grids, tempates and common site elements on the design side and on the engineering side to include proper semantic markup, unobtrusive JavaScript as well as the Struts2/Tiles2 page generation frameworks. In fact, despite 6 months of having this common terminology and numerous presentations there are still occassional disconnects that arise between the teams over just what the other means by this terminology.

Lou Rosenfeld: How do you get team members to start speaking the same language?

Bill Scott: Constant communication between the teams. What also works is adopting a common language to describe interactions. The use of design patterns is a powerful way to disseminate common thinking and approaches to common problems. I have been pleasantly surprised when language that design and engineering use to describe certain bad approaches (anti-patterns) gets in-grained even in our product managers vocabulary as well.

Lou Rosenfeld: What do engineers wish designers understood?

Bill Scott: I spent a good deal of time thinking about this question when preparing this talk. In fact I pinged a number of people I highly respect in both design and engineering. After listening to hundreds of comments and reflecting on my own experience I boiled it down to five simple ideas that developers wish designers understood.

1. The site is dynamic. Photoshop is static—the site is not. The site is dynamic in content, layout and interaction. It’s too easy to forget all of the details that come about when users get involved. But engineers end up having to fill in the gap where the designer has not accounted for all of these dynamic concerns.
2. Technology is critical. Web design without technology is just art. You must understand the magic that gets it on the site. Designers that “get” the unique challenges of getting their designs live can make smart choices up front and anticipate problems or even better arrive at more elegant solutions.
3. Components are key. Developers think in terms of reuse. Designers often think in terms of new ideas. To be effective you must plan for the common elements and interactions as this will map into a better experience as well as a more efficient use of engineering time.
4. Partnership is imperative. It’s tempting to design and toss over the wall. But the real magic happens during collaboration. Communication and constant iterative engagement are key to fielding a great user experience.
5. “Yes We Can!” Interface engineers have the power to say “yes” more than ever. And there are a lot of technology advances coming that if you are aware of as a designer you will enlarge your toolkit of tricks. Good interface engineers see problems as challenges and instead of trying to whittle your designs out of existence they will try to make it happen. Good engineers want to say “Yes”.

Lou Rosenfeld: Give an example of something that is surprisingly difficult for user interface engineers to produce that designers would think should be easy.

Bill Scott: Almost anything on Internet Explorer 6 🙂 I joke, but any engineer worth his salt will have a list of things they hate about IE6. But more generally the DOM (document object model) was designed for documents—not application development. So engineers are always “working against the flow”. The browser rendering engine is geared first and foremost to layout text and images, all the while marching down the page in a vertical flow. User interface layout is about modules with equalized height or items aligned vertically or items placed in a grid or side by side. Understanding this one fact that we are trying to do interface layout in a document rendering engine goes a long way to understanding why some things that should be easy turn out not to be trivial. Especially in light of making it work on IE6, IE7, Safari, Firefox, Opera and Chrome.

One example is vertically aligning interface elements. Now it is trivial to vertically align “inline” elements like spans of characters, etc. But attributes like “vertical-align” don’t work with “block” elements (e.g., divs). And if you aren’t resorting to the brittle technique of trying to force height on everything, you will find it to be particularly challenging. One solution is using display:inline-block. It allows block elements to be treated like inline elements. But alas this doesn’t exist for Firefox 2 (although a Mozilla proprietery property that sort of works like it does). And for IE it only works on elements that are naturally inline! So one has to trick IE into thinking the block element is inline and then set it to inline-block. And one has to trigger an internal IE flag for “hasLayout” to get the magic working completely. So yes it is possible. With the correct magic CSS formula (and for FF2 a little extra markup) you can get block elements to vertically align along an axis! Now if that sounds painful, imagine dozens of other seemingly simple tasks that require numerous hoops to make it work across browsers and you will begin to appreciate how frustrating this is for talented developers to spend their time figuring out.

Lou Rosenfeld: Bill, it does sound frustrating, but it’s good to know that problems like these might be alleviated when engineers and designers can talk and, ultimately, understand and value each other’s contributions. I know that both your webinar and your forthcoming book will get us one step closer to that happy outcome; thanks for sharing your wisdom!