NOTE: This blog has been moved to http://www.looksgoodworkswell.com

Friday, October 13, 2006

Question: How has your background influenced you as a web designer?

As you probably know (if you read much of my blog) I tend to focus narrowly on the world of user experience and user interface engineering. My passion is building great user experiences with a special emphasis on the web.

I was having a hallway conversation at UI11 with Joshua Porter. Lots of fascinating discussion (during which my voice finally played itself down to a rasp). But one of the things that I took away was a renewed interest in reading outside my field for inspiration for my field. You know learning from other crafts to inspire my craft. (In a separate article I will publish my reading list.)

I had started thinking along this line earlier in the year. In fact, Brian Kromrey (Yahoo!) and I were tentatively planning to convene a panel of Yahoo! interaction designers carefully chosen to represent very different design backgrounds. Backgrounds in design from gaming, industrial, motion graphics, theatre, software, comics, and so on. We had tentatively called it, "A Different Box of Tools." Since most of us did not start out as interaction designers/information architects/web designers our craft is certainly enriched by this varied tapestry.

How has your former design training influenced:
  • The way you solve problems?
  • The way you document solutions?
  • The way you communicate design?
I'll go first.

Solving Design Problems
My strong background in software architecture led to a passion for clear vocabulary and a deep appreciation in the powerful nature of patterns. The famous Design Patterns book for software was formative in the way I thought about solving problems. No surprise that patterns make up a lot of the way I approach design today.

My exposure to the agile community (eXtreme Programming in particular) reinforced the principles of simplicity, iterative problem solving, and pairwise-thinking. Not surprising that I value doing the simple thing first, communicating via the design in the simplest manner to start with and adding the effects as needed to tune the interface. Iterative problem solving is key to good interaction design. Having the user and other stakeholders early in the loop and rapidly iterating to a solution is critical. Pairwise programming (although I confess the religious adherants of this practice almost made me loathe this approach) can be seen as a reason that I latched onto Alan Coopers "designing in pairs" approach so easily.

Documenting Solutions & Communicating Design
Agile software approaches taught me the lesson to only document what others will read :-) Another way of stating this is who are the users of your documentation? That will determine what and how you document. This has influenced me in trying to keep documentation simple or create tools that make it feel more lightweight. My engineering background also taught me what developers need in documentation, so my background has helped me create solutions that can bridge the gap between design and development.

That's enough for me. Now it's your turn!

Share Your Lessons
So why not share? How about stepping up and telling me how your passion for art or your training as a clown or your training as an architect has crafted your craft. We could all learn an amazing amount from each other.

The Best Way to Communicate Patterns

Pleased ignore if you already syndicate the yuiblog.com.

But for those who don't, check out the five-part series by Jenifer Tidwell, Luke Wroblewski, Martijn van Welie, James Reffell and myself as we answer the question, "What is the best way to communicate design patterns?"

Tuesday, October 10, 2006

Wanted: Pattern Curator for Yahoo! Library

As many of you know one of my jobs at Yahoo! has been as Yahoo! Design Pattern Curator. My main contribution in this role has been (along with the incredible help of Erin Malone, Annette Leong, Leslie Wang, David Gan, Greg Rosenberg, Jay Bergesen, Ben Clemens, Kiersten Lammerding and Lance Nishihira -- to name a few) to launch the public Yahoo! Design Pattern Library. (Of course I must also mention the incredible work of Matt Leacock, Erin Malone and Chanel Wheeler in launching the internal pattern library before I joined Yahoo!)

The library has meant a lot to various folks in the community. I have heard over and over at various talks I have given the gratitude to Yahoo! for opening up the pattern library to the public. As an example, recently in Portugal I had several design/engineering teams personally thank me for this library.

The library has also attracted some great talent to Yahoo! We have heard consistently from recruits coming into Yahoo! that the library was a big attraction to their checking Yahoo! out.

The job involves working with properties/sites across Yahoo! evangelizing the internal and external adoption of patterns. If this excites you, then we have the perfect job for you! Or perhaps you can recommend that perfect person...

Here is the email from Erin Malone (who could ask for a better person to work with?) posting this position.

I have a really important and interesting position on my team here at Yahoo! This position is a result of an internal transfer to another role which opens up great opportunities for you!

Rather than post the full long bulletted list of the job description I have presented here a brief overview of the role in the hopes that the excitement that I feel about the role comes through. Please feel free to ping me for the full description or if you have questions or if you want to send me resume.

ABOUT THE TEAM - PLATFORM DESIGN
Platform Design at Yahoo! supports the Platform Products Group and is responsible for the development of NETWORK standards, the PATTERN Libraries, solutions and components for the UI WIDGET Library, for the PERSONALIZATION platform, for intertwining COMMUNITY across the network and for MEMBERSHIP touchpoints across the network. Our team consists of Interaction Designers, Visual Designers, User Researchers and Developers. Team members work closely with other cross functional people from Product Management, Marketing, Engineering, QA, and others across the company.

THE JOB:
CURATE THE YAHOO! PATTERN LIBRARY
Yahoo!'s Platform User Experience Design team is looking for a new curator for the Pattern Library. The curator works with designers from across Yahoo! to develop new patterns and to eventually migrate a pattern to the public library. You will be responsible for spotting trends in the designs of our properties, for designing and crafting new additions to the library and for evangelizing the authorship of new patterns among your Interaction Designer colleagues.

You will partner with our Platform Presentation Engineering team to create interactions and best practices that accompany the UI Widget Library. Additionally, you will own the external Public Pattern Library and develop the pattern lifecycle from internal to external libraries. And last but not least, you will be the spearhead and driver for a new addition to our Library suite - a new Terms Library and will work closely with our internal editorial team.

Please respond to me directly with resume and links to work.
Reference Job # RX1000017268

thanks

Erin Malone


If you are interested, feel free to ping me via email. You can reach me at b dot scott at yahoo dot com and I will get you in contact with Erin & the right parties.

BTW, I will still be 'yapping' about patterns. I will still be evangelizing the patterns. It's part of my blood. Whoever takes this role should know that I look forward to supporting them and helping them in this role as much as possible.

Friday, October 06, 2006

Lisbon, Paris, AjaxWorld, Code Camp, UI11, WebGuild & Ajax Experience

The last few months have been pretty crazy. In one 8 day stretch I put in 17,000 miles in the air!

I had a wonderful time in Paris presenting a couple of sessions on design & developing for Ajax to the People in Action folks. It is interesting to see the excitement about "what is possible" being a world-wide phenomonon.

The same week Luke Wroblewski, Kevin Cheng, Peter Merholz and myself (we have dubbed ourselves the "Bay4") had a great time in Portugal in the wonderful city of Lisboa (Lisbon as we say) giving 4 back to back talks to the first annual SHIFT conference. Our wonderful hosts Bruno Figueiredo and Pedro Custódio gave us tours of the city. Most interesting (besides being in Portugal) was having discussions with people from all over Europe about what all these changes in the web world means to them.

In Portugal there are wonderfully bright folks who are starting to really get the whole concept of innovation. For so long (at least this is what I heard from multiple Portugese sources) there is a strong cultural influence that shuns failure. Of course the freedom to fail is a key ingredient to innovation and something that we generally cherish in the U.S. (probably to a fault).

I had a wonderful chat with an engineering manager, Bruno Pedro at Sapo (sapo.pt, largest site in Portugal) who echoed these sentiments. He shared his enthusiasm about the Yahoo! Design Pattern Library as well as the Yahoo! UI library. Very encouraging to hear of the nice impact these tools are having around the world. He promises to share some of the exciting developments they will be making on this site.

You can check out photos from the various folks that attended as well as blog posts at Luke's blog, Luke's photos, Kevin's photos, Peter's photos and mine.

Closer to home I will be at the Silicon Valley Code Camp tomorrow (10/7/2006). There are 700 attendees and a bunch of us speaking. Its going to be at Foot Hills College this weekend in Los Altos, CA. Doug Crockford, Kent Brewster and myself will be giving talks from Yahoo!

This past week I spoke at the Ajax World Conference here in Santa Clara. Enjoyed giving my talk and had some great conversations afterward. But the highlight was getting to hear my fellow cube-mate, Doug Crockford, give his abbreviated Advanced JavaScript talk. Its definitely great material.

Next week I will be presenting an all day workshop with David (Heller) Malouf on Designing Rich Internet Applications at the UI11 Conference. Looking forward to the session (well over 100 signed up!) as well as the rest of Jared's exciting conference.

Then the next week I will be on a panel at the First Annual Web Guild Conference on "The New Web". I am an advisor for the Web Guild which usually meets over at the Googleplex. This looks to be a really great conference. Its very affordable and has an incredible lineup of great speakers like: Jared Spool (ui engineering), Ram Shiram (Founding Member Google), Marissa Mayer (Google VP), Kelly Goto (gotomedia) just to name a few. Still time to sign up!!

The next week Nate Koechley, Doug Crockford and I will be at the Ajax Experience. This was the best Ajax event I have attended (last event was in May) and I really look forward to hearing what the top quality speakers there have to say as well as connect with others in the field. That will be in Boston, hope you can join us there.

Thursday, October 05, 2006

Designing a Component



I’ve designed a number of software widgets, components and gadgets throughout my career. In the early days of Mac programming I created small desktop accessories and my own set of components to enhance my application development (e.g., geographical map component, 3D graphics library).

Later in the days of Motif I wrote numerous components (spreadsheets, charts, directed graphs, server-side grids). I also made a trek through the TCL community creating components for the incr Widgets set.

I spent several years working in the world of Java Swing building components (in fact I built at least three completely different component sets for three different companies—thank God that we now see more things getting open sourced!)

I finally ended up in the land of web development taking trysts through HTC components, JSP/Struts components (tag libraries) and finally pure JavaScript components. There are a lot of lessons I have learned over the years in how to create useful components. There are three that stand out in my thinking:

  • Make the component specific in purpose, yet flexible in use.

  • Avoid the do-everything component. Instead make it do the main thing well. But make it pragmatic by keeping it flexible.

  • Separate the concerns of interface, interaction, and content.

  • Avoid hard-coding visual style, give flexibility in the interaction model and provide flexible ways to manage data content. Keep these three areas independent to allow them to be customized separately.

  • Document the interface and use the component before releasing it.

  • You know the experience. You think you have a great idea. Then when you go to explain it to another person you immediately see the holes in your logic. Documentation provides a way to explain your interface; writing demos allow you to exercise the component to test its ease of use and flexibility.

Make it Specific yet Flexible
Make the component specific in purpose, yet flexible in use.


The agile community expresses the idea of simplicity over over-generalizing. One of the traps that people fall into is trying to build a component that does everything. Not unlike feature creep in application development, a component can collapse under the weight of too many features. One of the sure signs of this is when certain parts of the API start competing with other parts of the API.

As an example, let's look at the carousel. It is just a simple list view manager. You can actually make the carousel look like a tabset or a slideshow. However, I chose not to provide additional tabset or slideshow functionality. Why? I knew from experience that the interface would become unwieldy. Lots of new configuration parameters and methods would get added that only made sense if you were using the carousel strictly in slideshow mode. You can imagine that with enough features, some of the API would only apply to these tangential behaviors. The result would be a carousel component that ends up with portions of API that don’t even apply when the carousel is behaving “just” as a carousel.

A nice way to keep a component flexible is by providing a simple configuration mechanism. The Yahoo! UI library provides a Configuration object for just this purpose. (The first time I saw this mechanism in popular use was with the Prototype library.) Instead of having to pass lots of parameters to the carousel’s constructor (new Carousel()), you pass in a configuration object. The configuration object is really just an object that contains parameters and values encoded in JavaScript object notation. Here is an example from the wrap example:

var carousel = new YAHOO.extension.Carousel("dhtml-carousel",
{
numVisible: 4,
animationSpeed: .8,
animationMethod: YAHOO.util.Easing.easeBoth,
scrollInc: 3,
navMargin: 40,
size: 17,
loadInitHandler: loadInitialItems,
prevElementID: "prev-arrow",
nextElementID: "next-arrow",
loadNextHandler: loadNextItems,
loadPrevHandler: loadPrevItems,
prevButtonStateHandler: handlePrevButtonState,
nextButtonStateHandler: handleNextButtonState,
wrap: true
}
);

Each configuration parameter has a default value. If the user provides a configuration parameter it is treated as an override and is applied to the internal set of configuration values. The carousel then uses these values in its operation.

Keep Concerns Separate
Separate the concerns of interface, interaction, and content.



If you have read other articles on my blog or heard me speak you will notice that I often fall back on this idea of separation of concerns along the lines of interface, interaction and content (or data). Sometimes I express it as feedback, interaction and information. And often I just state in the way I first learned it from the boys at Xerox as simply Model-View-Controller.

When I wrote the carousel I started with the basic understanding that I was creating a list view manager. The underlying HTML structure I chose to control was an “unordered list” (UL & LI HTML tags). Keeping my thinking general in this matter allowed me to separate several areas of concern. Here is how this concept of separation played out in the carousel.

1. Flexibility of Visual Style
First I wanted to provide flexibility in the component’s presentation. One of the ways I did this was by putting all style choices into a stylesheet (CSS). It’s really easy to hard-code style choices into the component logic. By placing style considerations externally you can help fulfill the first point above – keep it flexible. The other way the presentation was made flexible was by providing configuration parameters that select the way items are displayed. Control over the number of visible items, the animation speed and method, the size of a page of information, and the orientation are all ways that the carousel is flexible enough to adapt to most environments.

2. Flexibility of Interaction
Second, I decided that the interaction should be completely flexible. I did not want to constrain it to my choice of navigation controls or method of user interaction. In most of the current examples, previous and next arrow buttons control the carousel. While this is the normal case, it is easy enough to allow mouse over events drive the interface. The carousel exposes the same interfaces it uses internally. You can simply wire your events to the same internal mechanisms used by the carousel internally.

Microsoft Altas (now called Microsoft Ajax Framework) does a nice job of separating behavior from its components. For example, they isolated the behavior of auto complete from the components. This means that if you add this behavior to say a text field you would have an auto complete text field. It also means that you can write your own components and by obeying an interface contract, have your component support this behavior. In essense the interaction is packaged as a separate entity and just attached to the component needing the behavior.

3. Flexibility in Content
And third, I felt that there had to be flexibility in the way content gets displayed in the carousel. The simplest mechanism for this was to allow developers a way to shove their own HTML into any item in the list. The innerHTML technique is very useful in this regard. It is very friendly to PHP, JSP, ASP and other page generation techniques. It’s also the native way to express an interface on the web. What this means is that each “item” in the list could be a complete page of content, a single photo from a photo stream, a set of form elements—in short anything you want a “list item” to be it can be.

Another dimension of content is in how the data actually gets loaded. By externalizing the loading mechanism through a set of function callbacks (functions that you write that let you decide how to load the initial set of data and fetch the next and previous set of data) the component is able to support static data, client side generated data or server-side fetched data (e.g. via Ajax). Recently someone wanted to wire the carousel up to RSS feeds. Even though I had not considered RSS feeds, since the data loading was externalized, it turned out to be a fairly trivial exercise.

Test by Documentation and Usage
Document the interface and use the component before releasing it.



Alan Cooper advocates that designers design in pairs. One takes the role of Interaction Designer (ID), the other the role of Document Communicator (DC). In design sessions the ID takes the lead role in pitching ideas. The DC tries to capture the ideas and wherever there is difficulty in capturing or explaining the idea it is forced to go through some iterations to make it easier to communicate. The idea is that by having to explain your ideas. This doesn’t just work in designing user interfaces, but it also works in designing programmer interfaces.

As I am writing this blog post I am sitting next to Luke Wroblewski on a flight back from Lisbon. He saw this point in my article and reminded me of a post he wrote a while back on Nine Lessons from Nine Years of Interface Design. One of the lessons he notes is that “writing it down forces you to think it through.” On this point he summarize three good reasons for writing it down:

  • Solidifies the approach. Guards against localized decisions.

  • Articulates the rationale. Puts the solution in context of its use.

  • Ensures clarity. If you can’t explain it, then nobody else will be able to either.


I find the exercise of both documenting and writing demos for components to be refreshing. It gives you a chance to come above the code cloud and both talk to the user and be the user of the component you are writing.

I finished the first version of the carousel in just 2 days. I spent the better part of the next 2 days writing documentation and creating demos for it. All during that phase I was constantly going back and rewriting parts of the code. Documentation can seen as a kind of test-first strategy for writing APIs. Writing demos is a good way to create tutorials as well as experience what it is like to really use your component.

Of course the biggest caution I would have about trusting too much in the demo applications you write is to realize that they are only demo applications. It really takes being exercised in several real world examples to fine tune an interface.

This lesson follows something that we try to employ at Yahoo! We call it “eat your own dog food.”

The phenomona of Yahoo! Hack Day has had a profound impact on the web services and APIs throughout Yahoo! (I would go so far as arguing that this has been the biggest impact of Hack Day—causing our services and APIs to become more robust.) When the Hack Team attempted to put together a combination of our APIs (events, maps, search, etc.) they discovered just how many things were missing. The creation of just that one demo pushed the discussion of what needed to be added or corrected—-and the result is a much richer API available to everyone (public included.)