In the next UIE Virtual Seminar, Rich Rutter gets you started with JQuery—assuming no prior knowledge—and shows you lots of examples, hints, and tricks. Just 5 minutes into this seminar, you’ll see JQuery in action and have something you can use in your own wireframes.

Employ Simple Show and Hide Techniques

The essence of JQuery is to find something and do something to it. This technique easily shows different page states so your team and test participants can “do things” to your design.

• See, step-by-step, how to put this simple, yet useful example of JQuery in action
• Use modules and plug-ins to make your design to do simple things, without worrying about the performance of production code

Toggle Wireframe Annotations

Add notes to your interactive design.

• Turn your comments on or off depending on who’s viewing your design
• Add lists, comments, or direction for developers and others who need to work with your design

Fake Simple Ajax Interactions

Without creating production level code, get your design to quickly and easily do its thing—click something and change occurs—for your developer or client.

• Replicate what happens when you click something like a “favorite button”
• Fill in all the steps of an Ajax interaction such as a slight delay or adding different page states on a single page

Get Started with JQuery UI Widgets

Rich will introduce a library with options and widgets that you can easily put in place. In many cases you’ll see how to simulate what the full interaction could be.

• Explore modal dialogues, an intrusive piece of interaction and a good example of something you want to test: Do I really need a modal, or is a link better?
• Get more examples: Prototyping calendars, lightboxes, and more.

Rich will show you the power of combining discreet interactions together with a complex interaction.

Regardless of your JavaScript experience, this seminar will be a great way to start using JQuery and take your interactive skills to the next level. JQuery gives us a clean, interactive feel, and can be the difference between a slick design and something annoying or disruptive. It brings rich interactivity to your HTML and CSS3.

Rich will incorporate complex interaction examples along with providing excellent sources of documentation and tutorials for your toolbox. The seminar will keep theory to the bare minimum and focus on getting you started with practical takeaways you can use straight away.

The real power in what you’ll learn is getting very close to a final look and feel of your intended design with just a bit of effort and without having to build the whole application. Get over the initial hurdle of the JQuery learning curve and gain momentum in your design process. Join us for JQuery for UX Designers.

I know you’ve been involved with the web for a long time, so I wanted to ask you a simple question: in your opinion, how useful is a computer science degree for a career in web development? I’m a second year CS major, and considering dropping out because I don’t see the value in it anymore. It’s just taking away my time from learning and doing what I love most–developing web apps. Will dropping out hurt me later on?

After thinking about it, I crafted this response:

It’s an interesting question.

I think the answer depends on what you want your long-term career prospects to be.

If you’re looking for immediate payoffs, then quitting school and heading straight into web-app development could work well. Very little of what you learn in school will contribute to that effort more than just getting experience being out there, solving interesting problems with innovative designs.

However, the computer field changes quickly. New languages, new tools, and new technologies emerge every day. These introduce real challenges for the practicing developer. It can be really hard to keep up, especially if you don’t have the foundations to build on.

Remember, “web development” didn’t even exist 8 years ago and, even from the landscape of 4 years ago, everything is completely different. There was no cloud. There was no Ruby on Rails frameworks. Virtualized systems didn’t play a role. CSS3 and the miracles of the HTML Canvas tag weren’t anywhere to be seen. There was no mobile web, per se. What will be different 8 years from now? Everything.

If you’re at a good CS program, it won’t help you be a better web app developer today. It’ll help you be a better web app developer later.

Take something simple as graph theory — something usually not taught in CS programs until the third or fourth year. This is a completely abstract mathematical idea, which, when presented in class, seems to have no real-world applications. Except in high speed networks, where the base math and algorithms help you identify the best way to route messages through the net. Or in social computing, where you can calculate the relationships between people and objects (such as users & pictures on flickr), to create new features (like the “Hey, this person in our net is connected to all your friends, but not you. Do you know them? Want to connect?” feature of Facebook, Flickr, Gowalla, and every other new social app).

Sounds like you need to decide if you’re chomping at the bit for getting serious development experience under your belt or if you want to make sure you’re prepared for the new stuff coming in the next 20-30 years, ready to tackle what those new innovations are going to bring us.

Hope that helps. Let me know what you decide.

Which generated this response:

Wow! I am so thankful for your reply! You definitely helped me see the value in my CS degree again. You see, the thing that made me consider dropping out of college was the discrete math class I’m taking right now. I saw no value, no real-world application of the abstract concepts we’re learning, and thought I was just wasting my time and money filling my head with useless knowledge I would never again use in my life. I then realized I would be taking many more similar theoretical classes in the next three years. As a result, it made more sense to drop out and learn stuff that I’m truly interested in, like PHP, Javascript, user experience design, etc.

But now I realize that a CS degree will help me build a strong foundation for a career that will prepare me for the many challenges and changes in the near future. I’m definitely staying in school to get my CS degree. And let me tell you, I am more motivated than ever to master my discrete math class and all the other theoretical classes that will follow.

Thanks again, Jared, for your words of wisdom. I respect you deeply and feel extremely honored to receive words of guidance from you.

Nice.

Apparently, I wasn’t the only one to get the query. Here’s Eric Meyer’s response.

Former UIEer Joshua Porter wrote a blog post recently, Why A/B Testing Isn’t Just About Small Changes, that captured the attention of the twitterati. His point, which is a good one, is that if you just tweak small things, you hit the problem of running into a local maxima, where you think you’ve got the best result, when in fact there’s better ones you can’t see. Josh’s point is that radical design changes can be helpful to avoid hitting a local maxima unintentionally.

To support his point, he draws on the A/B Test results of Luke Steven’s home page. Luke is writing a book and decided to change his home page, which previously contained his portfolio, to let folks sign up for an email when the new book is published. Luke tested two designs and was shocked to see a 131% improvement with his alternative design.

Luke Steven’s first design alternative with lots of details about the book.

The experiment is simple. He started with a page that had lots of details about the book. Over the test period 655 folks visited the page and, from that, there were 33 “conversions” (people signing up for the book)—a 5.0% conversion rate.

Luke’s second design alternative, with virtually no details about the book.

At the same time, other visitors saw a different page. This one just asked the question “Are you a designer?” and mentioned there would be a new book, but didn’t explain what it was about. You’d think that having fewer details would get fewer conversions, but out of the 661 conversions, 77 converted—an 11.6% conversion rate. The less-detailed design got Luke twice as many conversions.

Luke wrote that his big takeaway was “Engaging visitors through appropriate copy improved sign ups by 100%+”. For Luke, getting more email addresses was an improvement and the second, less detailed design did that quite handsomely.

That got me wondering.

Luke has seemingly made an assumption: Any email address is a good email address. This is a basic approach to marketing—we need a mailing list, let’s collect email addresses. If we get enough email addresses, we’ll get some people who buy from us, and we’ll make money. (This is the entire premise behind the spam industry. Just keep mailing and someone is bound to buy.)

Yet, for small marketers, list quality plays a huge role. So, what if Luke had made a different assumption to measure against? What if he only went after email addresses of people who bought the book?

Now, the book isn’t out yet, so we don’t know the quality of Luke’s list. But let’s make up some numbers and see what happens.

The first design alternative said a little about what the book will contain: how to kick ass with web analytics, A/V testing, usability testing, and advanced CSS & CSS3. Sounds pretty good.

What if fewer people signed up for the email because it didn’t sound that interesting to most of the visitors? From that, we could assume that the people who did sign up were interested in the book. Let’s say 50% of those folks would likely buy the book when it’s published. From the trial, 50% of the 33 who signed up for the list is 17 people who we predict might buy the book. If Luke used sales as his conversion (instead of sign ups), that would make it a 2.6% conversion rate.

The second design alternative didn’t say anything about the book, other than the vague statements of “it’s what comes after web standards” and “you’re going to love it.” People are less likely to know what they are signing up for. While more people signed up, I think we can safely assume that more won’t be interested in the book once they hear about it. Let’s say that only 10% of those folks would likely buy the book. From that page’s trial, 10% of the 77 who signed up is 8 people who we predict might buy the book, a 1.2% conversion rate.

So, if our wild-ass predictions are right, the new assumptions suggest that design alternative A is the clear winner, twice as good as alternative B—the exact opposite of what Luke’s initial testing showed.

Of course, there’s a lot of fabrication here. We don’t know the quality of either list. We’re only guessing that the quality of one list is better than the other.

(Luke could measure the quality of the list today. He could, for example, send an email to each of the 110 emails he’s collected. A simple email with a choice: “I’m not interested. Please stop emailing me.” or “Send me the coupon.” would do the trick. That would tell us more about the list quality.)

The assumption “any email address is win” is different from “anyone who buys the book is a win.” Luke chose the former to measure his design success. Had he chosen the latter, it could’ve taken his design in a different direction.

We need to make sure we’re measuring the right assumptions.

Your site’s search engine produces all sorts of useful information. Spending time with your site’s query data—data that is semantically rich—will help you answer questions about your users’ behavior and intent. You’re likely to learn some unanticipated lessons about your site.

Why spend time with your search log’s data? It will give you more usable content, improved search engine performance, as well as better navigation and metadata. Your users will achieve more on your site. You’ll sell more, engage more, and reduce frustration.

Lou Rosenfeld, who helped establish the field of information architecture, will show you how to take advantage of your site’s query data, data that’s sitting on your server right now. He’ll show you how to set up and run simple reports and queries to get you started towards better dialogue with your customers.

Do you spend time on your site’s search analytics? Maybe you use Google analytics or some other tool? What sort of time does it require? Other resources? Share your experiences below.

Subscribe to our podcast via

There are more than 16 different events and 96 interesting moments in a common drag and drop interaction. Your designs must leverage these moments to enhance the user interaction to deliver the right feedback and avoid distraction and confusion.

Bill Scott’s Designing for Interesting Moments was one of the highlights of the first stop on UIE’s Web App Masters tour, in San Diego. We wanted everyone to benefit from his research into web interactions, so we’re bringing you this audio and visual sample.

View Bill Scott’s Designing for Interesting Moments Sample

Since we couldn’t embed all the visuals here, we’ve built a special showcase. You can listen to Bill describe the components of his first principle of Designing for Interesting Moments, “Input where there’s output”, and view his example videos and screen shots. Bill’s presentation is visually rich. You can listen to the audio alone, but we recommend you view the visuals with the audio.

In this excerpt from the talk, Bill touches on patterns that work and anti-patterns to avoid.

Patterns

• In-line editing
• Multi-in-line editing
• Symmetry

Anti-patterns

• Non-symmetry
• Tiny-targets
• Artificial Visual Constructs

Until May 7th, you can register for any of the Tour cities for $795 when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

This is just one principle from Bill Scott’s Designing for Interesting Moments You should join us to see all six principles at the UIE Web App Masters Tour. You won’t regret it.

Join us January 12 for our next webinar: Leveraging Search & Discovery Patterns For Great Online Experiences, with Peter Morville and Mark Burrell.

The abundance and variety of search implementations present a challenge to designers: How do we leverage the behaviors our users are developing to ensure they find the content they’re seeking? By understanding how people interact with search implementations, we can create effective designs that deliver great experiences for both searching and discovering.

We couldn’t have timed this seminar better. In just a few weeks, Peter Morville will put his new book, Search Patterns, to press. And Mark Burrell and his team at Endeca have been working hard to release their new UI Design Pattern Library for Search & Discovery. So, this is the perfect time to talk about how to leverage patterns for better search designs.

This seminar is perfect for you, if you’re working on providing the best experience with your site’s search implementation. Bring your entire team and schedule extra time to talk about what you’ve learned—you’ll want to implement Peter and Mark’s ideas right away.

This winter, Peter’s new book, Search Patterns, published by O’Reilly, will hit the stores. But you won’t have to buy it, because as soon as it comes off the press, we’ll send you a copy—just because you attended this seminar.

Thanks to Peter, Mark, and the great folks at Endeca, we can include this must-have book. We’ve seen an early draft and we’re amazed by Peter’s talent to explain these topics so clearly. The beautiful full-color illustrations and screen shots don’t hurt either.

Register your team today, and reserve your copy of Search Patterns.

Do you use design patterns? What questions do you have about them? Where do you go, or where would you go to find them? Share your thoughts and experiences below.

Subscribe to our podcast via

A few weeks back we held a UIE Virtual Seminar with Pete Bell and Daniel Tunkelang of Endeca. These guys are the experts we go to when talking about designing for facets.  As always, we had a number of excellent questions from the live audience that we couldn’t attend to during the seminar, so I got together with Pete and Daniel to record this podcast and cover a number of those remaining questions.

If you didn’t attend the live seminar, and are interested in how to make the jump from a standard on-site search to faceted search, then you’ll still enjoy this podcast. If you find yourself wanting more afterward, don’t forget you can still purchase a recording of the session for another 90 minutes of Faceted Search.

During the podcast, Adam asked Pete and Daniel to dig into these questions:

• Should we show counts for each facet? What about when using multiple selection?
• Can you elaborate on the mixing and matching of precision and recall results to construct facets?
• Is there a best practice for deselecting facets?
• Most search interfaces assume a flat list of results. What happens when you mix up different types of results, and how would you distribute them across a page?

Tune in to hear more about designing for facets. Still have questions? Start the discussion in our comments, below.

This week, our long time friend, Molly Holzschlag, joins us to discuss the cutting edge of web standards as they apply to web application development. Molly is the unsinkable author of a metric ton of web development books, is a noted teacher, and an in-demand consultant in the field. There’s likely no one better to ask about web standards than Molly.

There are a number of new standards that have come out recently, HTML 5 being perhaps the most notable for web applications, because it was brought forth with applications in mind. New features, like canvas, are designed to improve dynamic interactions between the presentation layer and the behavior layer, for example, with things like ECMAScript, more commonly known as JavaScript. JavaScript’s usage has really matured and become nearly indispensable as developers have really begun to exploit its full capabilities. JavaScript’s importance to front-end developers continues to grow.

In this podcast, Molly and I discussed the impact these and other advancements are having on web application design and development, along with the tremendous benefits building with standards (or even a subset of them) brings to the lifecycle of a product.

(During the episode, Molly and I touched upon the critical security exploit that effects all versions of Microsoft’s Internet Explorer for Windows. Please be careful out there, folks.)

If you found this podcast interesting, you’ll be happy to know that Molly will conduct a full-day workshop for web application developers on harnessing the power of web standards in their work at our Web App Summit in April 2009. Please join us and take your work to the next level!

We’re curious to see if any of our audience is venturing into the HTML 5 waters, or using other newish standards in their work. Won’t you let us hear your story in the comments?

Robert Nyman does just that with the Nokia and SonyEricsson UK sites and finds some surprising results. It’s quite a good write up.

Very much worth a read followed by the obvious next step: checking your own site out the same way.

[Hat tip to NortyPig]

Because titles often don’t communicate what’s in the article, the implementation gives users a chance to see more by providing a summary as a tooltip-style pop-up.

However, it seems someone has been slacking off, because in today’s list, articles come up with the text “(no summary)”.

Three things about this jump out at me:

1. I don’t typically think of the Wall Street Journal as an organization that slacks off, so the missing summaries feel wrong to me. (Maybe this is all part of Murdock’s plan—first, eliminate the summaries, then eliminate the meaningful content? Worked for the Post. Bring on the Page 6 girl!)
2. On the development side, someone wrote a piece of code that says, in essence, “if there is no summary in the content management system, substitute the phrase ‘(no summary)’ in the tooltip.” That took more effort than just leaving it blank.
3. Similarly, on the development side, it looks like nobody put in an error message when the article is published that said, “You haven’t included a summary and that’s going to make us look silly. Want to rethink that?”

Of course, it’s unlikely that the person pressing the publish button ever goes and sees what pops up in that tooltip. (Ironically, if they’d actually published it as a synopsis that appears with the title, instead of putting it in a mouseover action, they’d see the problem right away and fix it.)

This is one of those little things that reduces the overall quality of the experience. And it’s also a great example of what happens when you spread the design contribution across different roles: developer, visual designer, and editor in this case. All three have to execute perfectly to succeed, with no checks & balances to ensure that’s actually happening.

Seems like we need to learn something from this…

Where would you send a client looking for an article on designing for different browsers and conducting browser-compatibility testing?

One of the downsides of being a researcher and never actually doing the hard work is that you don’t know the answers to the important questions. However, I know people who do. Here are the responses I got back:

Andrew Smith (@somenice):

@jmspool I would recommend http://www.quirksmode.org/dom/compatibility.html and http://browsershots.org/

@rustyspiedel

@jmspool http://www.netmechanic.com/products/Browser-Tutorial.shtml and http://www.justskins.com/design/browser-compatibility/137

Peter-Paul Koch (@ppk):

@jmspool: My quirksmode.org is one of the best resources, even though it doesn’t contain an article about the basics, just lots of facts.
This article looks promising, too: http://anthonyshort.com.au/blog/comments/how-to-get-cross-browser-compatibility-everytime/. Is only about CSS, though.

Amy Stewart (@astewart):

@jmspool check out Browsershots: http://browsershots.org/ and Position is Everything http://www.positioniseverything.net/

Thanks everyone!

As we’ve researched further, it’s become clear to us that, out of the eight types, the most important navigation page is the gallery page. Any site with more than one page has a gallery, which is a list of the links to the potential pages that contain the user’s final destination on the site (known in our work as the target content).

In today’s UIEtips, we reach back into the archives to reprint an article where I discussed what we know about building successful gallery pages. I talk about the problems introduced by poor scent and, in particular, the act of forcing users to pogostick (jump up and down in the site’s hierarchy). Click here to access the article.

If your interested in learning more on Galleries, attend our UIE Virtual seminar on August 14, 2008

Have you done something special with your gallery pages? How have users responded? We’d love to hear what you’ve been doing. Leave a comment below.

In the “old” waterfall method of development, there are explicit milestones: first you develop requirements, then you create a design that meets those requirements, then you lay out the functionality that will implement that design, and so on. You can see when things are moving forward and you know where you are in the development process. (Of course, it never actually works this way, which is why so many are moving to an Agile process, away from the waterfall.)

From a user experience perspective, it’s clear what you need to do in a waterfall process. You need to gather any research that will affect the requirements, before the requirements are done. You need to test your designs before the designs are signed off. You need to evaluate the functionality as it’s being built. And so on. Every step has clear contributions and expectations.

In Agile, these contributions and expectations aren’t nearly as clear. Waterfall gave us nice “hooks” to hang our UX work on, but Agile doesn’t do that. The team breaks up work into small chunks and just starts chipping away at it. There’s no clear point when requirements are done (they are gathered in parallel with trying out the designs). There’s no clear point when design is done (it evolves over the duration versus being declared up front). It doesn’t seem that there are any clear hooks in an Agile process.

Interestingly, if you dig deeper, the hooks are there. In this issue of UIEtips, Jeff Patton concludes his two part article on his best practices for integrating user experience work into an Agile development environment. He talks about how teams he’s worked with have found the hooks and made it work.

Read Jeff’s article, 12 Best Practices for UX in an Agile Environment – Part 2.

Jeff will be sharing his wisdom on integrating UX into an Agile process at the upcoming User Interface 13 Conference in Cambridge MA this October. His is just one of the great full-day seminars we have at the conference. If you’re looking to create great designs, I suggest you check out the program.

How have you integrated your user experience methods into an Agile process. What struggles have you encountered? We’d love to hear your experiences.

The Agile development process is about breaking things into small pieces and acting on each piece really quickly. Yet, traditional user experience practices aren’t used to working fast. How do we adjust our practices to survive in a fast-paced agile process?

That’s the question we posted to Jeff Patton, the noted independent UX/Agile consultant and speaker, who joined me on this week’s show.

During our conversation, Jeff and I discussed some of the issues surrounding development speed that UX practitioners encounter when working in an Agile development team. While we talked, Jeff shared these observations from successful teams:

• Rapid Iterations: We’ve known for a while that fast iterations can help design, but now the rest of the team is iterating quickly too. Jeff proposed regularly using development partners — people you revisit — can help you with low-hassle usability testing and feedback sessions.
• Continuity: One of the key challenges in the agile environment is that working with small pieces of the project can lead to a lack of continuity between the pieces. Jeff suggested that a key role of the user experience professional on the team is to maintain the big picture: seeing what’s been built and what’s about to be built, and ensuring those pieces come together to form a coherent experience.
• Are your designers your users? It’s been said that Apple’s designers created the iPhone for themselves, without user testing. When the designers are avid users of a product, this can be successful, but such instances are rare. For most projects, it’s nearly impossible for designers to consistently put themselves in their users’ shoes. In agile environments, there may be more temptation to skip the user testing and go with designer intuition. Successful designers acknowledge that this intuition, talented though it may be, is usually no substitute for real user research.
• The RITE Method: Rapid Iterative Testing and Evaluation, is a successful method developed at Microsoft. It combines fast iterations with testing, looking to make improvements after each participant. Jeff suggests this is something agile teams should investigate.

Of course, I’m not doing Jeff’s ideas justice with this summary. You really want to listen to the entire interview to hear all of his wisdom.

[Jeff is teaching a full-day workshop, “Bringing User-Centered Design Practices Into Agile Development Projects”, at our User Interface Conference this October in Cambridge, MA. If you work in a fast-paced agile environment, Jeff's seminar is for you.]

Questions, comments? What have you done to adapt to the speed of the Agile process? Let us know about your experiences in the comments.

It occurred to me, while talking with Jeff Patton last week, that the same can be true in an Agile development process. Often times, the team will start with a piece of the project that isn’t the first thing the user experiences, but instead might be at the end. For example, they may start by building the functionality to save a file in Photoshop format – technically an important, high-risk part of the project, but not much of a user interface beyond a simple “Save as PSD file” option.

Jeff mentioned that user experience designers on the Agile team end up adopting a similar role to the person who gets the credit of “Continuity” in a film. It becomes their job to make sure the final experience makes sense, even though the order of construction was not linear. This is a huge challenge and one that has come to forefront as more teams move to an Agile development method.

Jeff has been researching the new challenges that arise when teams try to merge their UX efforts in an Agile process. In his travels, he’s assembled a slew of best practices that result in the development of great experiences. In this week’s UIEtips, we’re proud to publish the first installment of a two-part article where Jeff describes 12 of his best practices.

Read Jeff’s article, 12 Best Practices for UX in an Agile Environment – Part 1.

If you’re a user experience professional working inside an Agile development team, you’ll want to check out Jeff’s full-day seminar on this topic. He’s updated it with his newest findings and it’s promising to be one of the most popular sessions at our upcoming User Interface 13 Conference in Cambridge, MA this October.

Are you working to improve the user experience in Agile development projects? What practices have you found to work (or to avoid)? Share your thoughts with us.

This week, Ajax design expert Jeremy Keith joins us from Brighton, England. Jeremy is the technical lead at Clearleft, a leading design consultancy in the UK. He’s the author of the popular books, “DOM scripting” and “Bulletproof Ajax.”

Ajax has really evolved since the term was coined. The technologies that we use to make responsive web pages and applications continue to evolve as well. Jeremy has his fingers on the pulse of these changes, and has a lot to tell us about the when, the where, and the why of using Ajax.

Talking with Jeremy was fascinating and, during the interview, he offered several juicy nuggets about using Ajax effectively. For example, he suggested that we think twice about if our business logic should be in the client-side environment. He proposed the server should be doing the heavy lifting, since this is a controlled environment. The interactivity should appear within the browser, so the interactions appear quick and seamless.

His rationale is interesting: Since browsers are diverse and quickly changing environments, Jeremy recommends we use them primarily for display and interaction, and we should resist the urge to process too much data with JavaScript. Instead, we should move the data to the server for processing. It may increase your bandwidth or server load, but both of these, he argues, are good problems to have—it means your app is popular!

Of course, you’ll want to listen to the rest of the podcast to hear the other wisdom that Jeremy has about using Ajax in production environments.

[For even more wisdom, you'll want to attend Jeremy's full-day seminar, Bulletproof Ajax: Designing Interactive and Usable Ajax Solutions, at our User Interface 13 conference that will take place this October 13-16, 2008 in historic Cambridge, Massachusetts.]

We look forward to your questions and thoughts on this podcast. How are you deploying Ajax to improve your experience? Let us know what you think in the comments!

This week, I had the pleasure of speaking with Donna (Maurer) Spencer, a world-renowned information architect and owner of the freelance agency MaadMob, based in Canberra, Australia. For nearly 10 years, Donna has been a prominent player in the information architecture world, sharing her experiences for designing some of the most challenging clients around: large government sites.

For this interview, I asked Donna, “What separates good information architects from great information architects?”

Donna said that she believes that great IAs can think structurally, can synthesize many inputs at once, can work strategically, and can work in the smallest details. A good IA can get by doing these things very occasionally, or not at all. But, great IAs do all of these constantly, bringing more value to the project.

Over the years, Donna has come into contact with some diverse and multi-talented IAs. She noted that one thing they all have in common is they all do more than just information architecture. Donna told us how she keeps herself balanced by also practicing other user experience disciplines, such as interaction design.

Donna also suggested that perhaps the strongest skill the great information architect needs is people skills. It’s one thing to build a quality taxonomy or navigation system, but if you cannot interface with your own team or the client, you may find your usefulness diminishes greatly.

This was a great interview. We had a lot of fun making it and I’ll bet you’ll enjoy listening to it.

This October, Donna present a full-day workshop, “Information Architecture Essentials: Best Practices for Organizing Your Site’s Content”, at the User Interface 13 Conference in Cambridge, Massachusetts. It’s a great place to learn what it takes to become a great information architect.

We look forward to your questions and thoughts on this podcast. Do you agree with Donna about what it takes to become a great information architect? Is there anything she left out? Let us know what you think in the comments!

How do you communicate complex and interactive design ideas to the development team? To answer this question, I had a chance to speak with with D. Keith Robinson, the Creative Director of Blue Flavor, a premier design and development shop based in Seattle, Washington. In addition to being one of the design experts we turn to for guidance, Keith was formerly the Editor-in-Chief of Digital Web Magazine.

We had a great discussion regarding the “backstage” portion of web app design. I think Keith has some innovate ideas which will inspire your own projects. In our chat, we discussed:

• “Projects from hell”
• Where can communications break down when designing web apps?
• How do effective deliverables affect the success of a project?
• What’s involved in creating enhanced deliverables to improve communication and the interaction design process?

We’re excited to have Keith speaking at our UIE Web App Summit this coming March. Keith will be discussing his successful communications methods for highly interactive designs, especially those where the design elements can’t be captured with static images.

You can catch his talk, Making the Translation: Critical Web App Design Deliverables on day 3 of the UIE Web App Summit!

Today, in our UIEtips email newsletter, we published my latest article talking about engaging experiences found in an unlikely place: a newspaper web site. Yet, this isn’t just any newspaper web site, it’s the New York Times. The engaging experiences are interactive calculators, maps, and data visualization tools.

I’ll admit it right up front: This article is probably the most difficult one I’ve had to write in a long time. Not because the subject matter was hard to come up with. Nor was it because I was at a loss for words.

No, the reason it was so difficult to write was because of the examples. They were just so much fun to play with. I’d bring one up to quickly note a detail and then I’d realize I’ve spent 30 minutes just playing with it.

In this week’s article, I explore some key principles that are the common thread in the NYTimes interactive graphics. Of course, I provide links to the examples, which you’ll really want to play with. You were warned!

You can read my article here.

I am extremely excited that we have two key members from the New York Times, Andrew DeVigal and Steve Duenes, joining us for the UIE Web App Summit in San Diego, CA on March 26-28. They are going to share their process and inspiration for their engaging interactive designs. You don’t want to miss this session.

Have you come up with some interesting methods of making your data engaging?

The question has turned into a bit of a conundrum, with the answer being yes and the answer being no. While good design practice is good design practice and it applies no matter what you’re designing, you need to know who your users are, what they are trying to do, and how they expect to do it. You need to watch the users work with the designs you create, so you can learn where the designs are working for them and where they are failing.

However, designing for web apps is different than just designing a web site. It lives in a browser, it has complicated activities and edge conditions, and little things can have big implications, especially when they go awry. You need to know different things when designing for web apps than when designing for any other type of interaction.

In today’s UIEtips, we’re reprinting an article I wrote last year detailing five of the greatest usability challenges that web-app designers face. The problems and constraints designers are still dealing with today make this article just as pertinent as ever.

Read today’s article.

What challenges have you faced when developing web-based applications? How have you overcome these? We’d love to hear from you. Leave your thoughts below.

[Overcoming the challenges of web-based applications is just part of what we'll be talking about at the upcoming Web App Summit, March 26-28, 2008 in San Diego, CA. You can be part of that event and receive your limited edition Web App Summit iPod nano by registering before 12/11. More details here.]

During the debate, Richard Todd made this observation:

What about the challenges in trying to avoid a major relaunch?

When faced with many new site ideas and a desire to introduce them in a better structured environment, the pressure is on to – while you’re at it – rebuild everything. This pressure is compounded when, regardless of any surface changes, the internal architecutre must be reenginnered due to changes in servers, browsers… the forces without and within. Call it “valid software engineering principles”.

what then? Recreate the old site on a new platform? It would be like putting an old , but not-so-classic, car body on top of a high-end power plant. It works in the funny car races, but that’s why they’re called funny cars.

There are times when a rebuild forces so much change that a relaunch is inevitable.

The other truth is that the transitional approach can be much more expensive. A wholesale change is a one-step event. Transitioning takes planning – each baby-step to pull the audience along with you, can be as expensive. And it often must take place over a long, gradual period of time – this also gives competitors a chance to usurp your ideas before they have finally hatched.

In other words there are forces outside the confines of the user interface and user hand-holding. Not every company can afford the time and extra effort of small steps.

It is a challenge we face right now. I’ll let you know how it turns out – if we go to major re-launch or if we sneak in incremental changes until we get there.

At the time, my opinion was that he should slowly integrate the new platform into the design, supporting both platforms simultaneously for a while.

“Heresy!” the masses clamored. They said I just wasn’t being realistic and understanding the complexities of that. Plus, if you’re going to take the effort to change the platform, they suggested why not do a complete overhaul at the same time? It’ll be much cheaper.

I disagreed. It might be cheaper, but the odds of getting the design right out of the gate are very slim. Better to do it in small pieces, learning as you go.

Well, here it is a year later and Richard has an update for us:

Well, you were right. It is now a year and a bit past the point of no return when we relaunched our website. The site is much better (far from UIE endorsed perhaps but better) in term of navigation, design, content, and all those other reasons why companies decide to re-launch.

But, the truth of it is, while comments from users are favorable, page views have not substantially increased per user nor has time on site. Overall user numbers are a function of other factors such as marketing effort, so we are only looking at the actual user experience.

There was certainly a high curiosity factor in the first month (perhaps the best reason for a “re-launch” – the marketing opportunity it provides). And the functionality under the hood in the new content management system is very robust and flexible and extensible – it had to be done for our authors, and our members, and our sales streams.

But the part of the process where we redesigned the look and feel was the area of fault. It might have been more difficult to reengineer everything while trying to match the old appearance, but in hindsight we would have been better off to do that – to say with the familiar.

Words of advice from an anecdotal experience with the pitfalls of relaunch. We were warned, you have been warned.

Thanks, Richard, for letting us know how it turned out!

We’re holding the Summit in beautiful Coronado, CA on March 26 – 28, 2008. We’ve got a great line-up of presenters, including Andrew DeVigal, Steve Duenes, Derek Featherstone, Kim Goodwin, Sean Kane, Jeremy Keith, Steve Mulder, Leisa Reichelt, D. Keith Robinson, Bill Scott, Luke Wroblewski, and Indi Young. Jared Spool will also be presenting UIE’s latest research on web app design.

Last year, we were amazed at how well this event was received, and this year is already shaping up to be even better.

It could be because of the full-day workshops covering the most critical topics surrounding web apps for your success, or the 90-minute short talks covering the essentials for designing successful web apps and the best practices for implementing successful web apps. It could be because the caliber of attendees we attract are the best and the brightest. Or it could be because we’re giving everyone who signs up before December 11th a brand new, limited edition Web App Summit 2008 iPod nano.

Of course, I know you want to come to the Summit (and get your own iPod nano). Everything you need to register is at the Summit site. Don’t delay — there might not be seats available.

On my recent trip to the d.Construct 2007 conference in Brighton, England, I had the good fortune to sit down with acclaimed designer Cameron Moll.

Cameron is the Interaction Design Manager for the LDS Church in Salt Lake City, Utah, where the work he oversees reaches a world-wide audience. His very popular design blog Authentic Boredom, regularly features engaging articles and unleashed the “wicked worn” look across the web, which earned him a mention on NPR.

Cameron’s excellent talk at d.Construct was about the differences between good design and great design. (Fortunately, he’s covering this topic — and much more — in his almost sold out full-day UI12 tutorial session.) I found Cameron’s perspectives on graphic design theory, HCI principals, and his communication-centric approach both fascinating and stunningly effective.

In our conversation, Cameron let me in on his background and his unusual journey to both design and the web. We discussed the importance of getting to know your customer before you make design decisions. We also discussed what to do after each project so you take its lessons forward.

Like many of us, Cameron works in a large, complex organization. This means managing design decisions and wrestling (often inflexible) enterprise technology. He talked to me about how he has integrated his real-world experiences into his UI12 tutorial and how he is working on bringing elegance and great function to his complex work projects.

Even though Cameron is recognized for his world-class design talent, I am surprised how friendly and humble he is. We had a fascinating conversation that I think you’ll enjoy.

New: Survey and listener drawing!
We would like to give you and your co-workers free admission to our next Virtual Seminar program, with full, lifetime access to the archived program as well! All you need to do to be eligible is give us your feedback on your podcast listening experience. Fill out the following survey and each week we’ll randomly send one survey participant a free admission to the next UIE Virtual Seminar and Archive, a $169.00 value! We appreciate your input!

Participate in our survey to win!

Cameron works for the LDS Church and has assembled a lot of real-world examples of web design in a large organization. Cameron oversees the creation of highly flexible interfaces that can be repurposed as needed for a very diverse, multi-lingual audience around the world.

Looks like a fascinating talk.

You can find the screencast here, at Cameron’s blog.

You can check out Cameron’s tutorial description on the User Interface 12 Conference Site.

Stay tuned for a podcast interview with Cameron Moll and Jared Spool from d.Construct 2007, due out shortly.

In today’s SpoolCast, I had the good fortune to speak with Kevin Cheng. Kevin is a senior interaction designer with Yahoo! Brickhouse, an advanced development team within Yahoo!. Prior to joining the Brickhouse, he worked on the Yahoo! Maps and Local team. Kevin is the co-creator of the usability and design comic, OK/Cancel. At Yahoo!, Kevin merged his interests and introduced the use of comics for conveying new design ideas and concepts.

In the interview, we discuss the use of comics to express user experience ideas early in the brainstorming stage of a project. Comics show the team how a user will experience the design. This lightweight approach helps you iterate quickly without making major time and resource investments. You don’t need to be an artist to effectively employ comics in your UX processes. Kevin also discussed his presentation for the upcoming UI12 conference in November and gave a sneak-peak at what attendees can expect.

While we were talking, Kevin mentioned the following collection of comic-related resources on his site: Creating Concepts with Comics.

Kevin shared a lot of great information here. I think you’ll enjoy it. As always, we welcome your feedback in the comments.

New: Survey and listener drawing!
We would like to give you and your co-workers free admission to our next Virtual Seminar including full, lifetime access to the archived program! To enter, give us your feedback on your podcast listening experience by filling out the survey!. Each week we’ll choose one winner from the survey participants and send them a free admission to the next UIE Virtual Seminar and Archive, a $169.00 value! We appreciate your input!

Last week’s winner was Carolyn K. You could be next week’s winner (even if you’ve entered before). Just participate in our survey to win!

The day of the announcement, users using the popular Mac browser, Camino, received the following message when visiting O2′s iPhone promotion page:

Error message in Camino Browser when visiting O2′s iPhone Page

Your browser version is out of date. Would you like to upgrade it now for a better user experience? (Highly Recommended)

This message showed up in every version of Camino, including the latest version. When users clicked OK, the site automatically brought them to the download page for a different browser, Netscape 9.

For those users visiting the site using Safari, the browser supplied by Apple on OS X (and on the iPhone), the page failed to render correctly, leaving critical navigation unreadable.

O2′s iPhone Page, seen from a Safari Browser

There are a couple of interesting points that arise from this.

First, this certainly argues the importance of using standards-based implementations on your pages. Gone are the days where we can count on 100% of the users using the same browser.

A product like the iPhone will naturally attract folks who are active Apple product users. On Apple’s OS X, Firefox, Safari, Camino, Flock, and Opera are all popular browsers. In Windows, the various versions of Internet Explorer and Firefox dominate, but others like Flock and Opera have found their niche audience.

If your pages don’t render in all these different browsers, you’re going to substantially reduce the quality of the user’s experience, potentially turning them off of your site, your products, and your brand.

Second, this brings up an interesting question about how much control Apple can have over the experience of their product when they have major partners like O2 and ATT. Apple’s success has always come from carefully crafting the experience customers have, from the marketing materials, to the packaging, to the customer support of the product.

Yet, in the mobile phone world, Apple can’t work alone. They have to work with established businesses — major players in the space with established business practices.

Apple initially approached Verizon for their US carrier, but Verizon declined the opportunity because they didn’t feel they could meet Apple’s demands on service. Apple settled with with ATT, but the seams in the relationship are very apparent. (One doesn’t have to look much farther than the 100-page bills ATT delivers, showing every data file transferred with a $0.00 charge.)

It’s hard enough to create a successful user experience when you can control every aspect of the customer interaction . Can Apple (or anyone else for that matter) create truly amazing experiences when they need to work through partners? That is yet to be seen.

A few weeks back, I had the chance to talk with Gerry McGovern, author of Killer Web Content and UI12 Speaker Extraordinaire. We talked about a variety of aspects of designing web sites, but one theme we kept coming back to was about how prepared the team was for the long haul.

During the talk, I realized people who have experience building brochures and marketing materials might come to the web design process with a misleading perspective. With a brochure, you carefully construct the design and messaging, put it into production, and then never see it again. Rarely do you get to see anyone interact with the brochure. That information never informs the design of future brochures.

Gerry made the great point that web design is very different. It’s an iterative process where you’re receiving constant information after the design. This information allows you to tweak and enhance the design, often in small ways, to make continual improvements. Most of the work happens after the initial production, not before, as in a brochure.

In this week’s UIEtips, I’ve described the findings from recent research on web site redesigns. In this article, I talk about seven strategies we see employed by the organizations best at redesigns.

Read today’s UIEtips article.

Have you employed these strategies? Are you finding hurdles from thinking too much in the short term? We’d love to hear your thoughts on the challenges when redesigning web sites. Join the discussion below about this week’s topic.

Want to learn more? At this year’s User Interface 12 Conference, Gerry McGovern will present How to Design a Task-Based Information Architecture, to give you a solid grounding in IA that will enable you to create designs that help your users find what they want.

Over the past few years, the world of web application development has seen the emergence of a new set of approaches such as APIs, RSS, and Folksonomies that have come to be known collectively as Web 2.0. These new approaches allow developers to easily create innovative applications at a rapid pace from common elements found lying around the Web.

The speed and ease at which these new applications were built is what is keeping us very excited about the continued success of the Web 2.0 world. With a little skill and motivation, people can create new applications in almost no time at all. As the skill requirements for building these applications decreases, it opens a whole new world of possibilities for development teams.

With new sites and services popping up, such as Flickr, Del.icio.us, Digg, and Twitter, it’s easy to see how we’ve entered a new era of social networking, and we’ll continue to see the Web evolve as we realize its full potential to create optimal user experiences.

In this week’s UIEtips, we’re reprinting an article I wrote in 2005 where I examine how design teams and individual developers alike can harness the power of APIs, RSS technologies, Folksonomies, and Social Networking to approach hard problems in new and effective ways. I think you’ll really enjoy it.

Read today’s UIEtips article.

Do your applications take advantage of APIs, RSS, Folksonomies, and Social Networking? Does it intrigue you? Scare you? Bore you? I’d really be interested in your thoughts. Join the discussion below about this week’s topic below.

[Want to learn more about Web 2.0? Check out the UIE Virtual Seminar, Web 2.0: The Power Behind the Hype. In this 90-minute presentation, Jared M. Spool will outline how Web 2.0 works, and discuss how APIs, RSS, Folksonomies, and Social Networking can help designers expand and improve the user experience.]

This week, UIE turns 19 years old. Over the years, we’ve seen technology come and go, features grow and shrink, and interaction styles dramatically change.

What used to be just a person interacting with a screen has become something more — people interacting with other people, using the computer as a moderator. This has enhanced e-commerce (as seen by Amazon’s reviews), brought families and communities together (with tools like Flickr’s photo sharing and commenting), and enabled new ways to keep in touch with people important to us (as with Facebook and MySpace.)

As with the development of any system, it’s easy to focus on the mechanics of making the technology work. Just allowing people to add reviews or establish connections is the first step.

Yet, perfecting the mechanics won’t get you a service that delights the users. That has to come from something more. Something that takes into account how people interact with each other and how businesses can thrive on that interaction.

In today’s UIEtips, Josh Porter gives us the continuation of his analysis of the common pitfalls of building social web applications. Josh has done a fabulous job looking at what it takes to survive in this new world.

Read today’s UIEtips article.

Are you implementing social web applications into your designs? Have you encountered any of these pitfalls? If so, what you have you done to avoid them? Join the discussion below about this week’s topic below.

This is Josh’s last article as a member of User Interface Engineering, as he has recently left the team to start his own business, Bokardo Design. Over the last 5 years, Josh has contributed tons to our thinking on Search, e-commerce, web apps, and developing social applications. He’s been responsible for our site design, the e-commerce application that funds our research and events, and our blog. Most importantly, he’s been part of the life-blood of what makes UIE what it is. We won’t be the same without him.

Just because Josh is leaving our offices doesn’t mean he’s leaving our life. UIE will be one of his first clients, as he continues to help us with the design of our site. However, he now has the opportunity to help other organizations with their sites. (You can contact him at porter@bokardo.com if you’d like to see if he could help your organization.) He’ll also be presenting at the upcoming UI12 conference and as part of our upcoming podcasts. It’s likely you’ll hear more of his thoughts in UIE Virtual Seminars and articles. Of course, you can follow his thinking on his blog, Bokardo.

In each part (part 3 is in the works,) Leisa states a way you might make qualitative research “look more scientific,” and then discusses some reasons why trying to make qualitative research more quantitative is a waste of time, money, and energy.

1) Use a relatively large sample size

The richness of the information and insight you receive even from this small sample size makes the return on investment enormous – and the small sample size makes it an activity that almost any project can incorporate into their timeline and budget. At the end of the day – those things are far more important than scientific validity.

2) Ensure that your test environment doesn’t change

If you want to quickly weed out problems with your site/application/prototype – then I recommend that you fix the problem and move on to spend your valuable research time learning about things you don’t already know about. It will certainly keep you awake as you’re researching, you’ll get rapid return on investment and excellent bang for buck as far as research techniques go.

3) Ensure that your test approach doesn’t change (don’t change the script, and stick to it)

Perhaps you can use her arguments when someone asks you about the validity of your qualitative research.

You can read part 1 here: Embracing the Un-Science of Qualitative Research Part One – Small Sample Sizes are Super

You can read part 2 here: Embracing the Un-Science of Qualitative Research Part Two – Ever-Evolving Prototypes are Ace

Part 3 is on the way.

The daily grind of the designer and information architect can become very focused and repetitive. Project after project, client after client, iteration after iteration, we work through the motions of wireframes, card sorts, hierarchies and task flows ad nauseum. How do we break away from this cycle and step away far enough that we can truly explore, innovate and define strategy?

The pair also talk about the challenges and difficulties they faced, the lessons they learned, and the successes they experienced by creating a project that defined product strategy, instead of just diving head-first into product design with no direction or vision in mind for the product’s intended user experience.

You can find the slides and audio from the presentation up on the IA Summit site here.

Jared has also been talking a lot about creating an experience vision and building an envisionment to keep the design team on the right track throughout the entire design process, and the needs of the users at the forefront of design.

How are you guiding your design direction towards your users’ ideal experiences?

When teams make critical feature changes in their designs, there’s always a risk of backlash from loyal users. That’s what happened to Facebook, the social networking site, a few months ago. Facebook’s designers created the mini feed, an exciting new feature that promised to offer users a vastly improved experience. Instead, the feature resulted in loyal users getting angry and frustrated with the change.

How could Facebook’s designers have prevented this backlash from users? How can you ensure that you don’t experience a similar fallout when launching a new feature? In this week’s UIEtips article, I discuss what led to the Facebook disaster and how design teams can avoid similar results with their own sites.

Read today’s UIEtips article.

How does your organization handle the launch of new features or products? Has your team experienced any backlash when launching new design features? Join the discussion below about this week’s topic below.

[If you find this article interesting, you'll definitely want to attend this year's UI12 Conference, where I'll present my full-day seminar: New Perspectives in User Experience Design. In this seminar, I'll be sharing my outlook on the state of our field and discuss UIE's latest research.]

Web-based applications are quickly becoming critical components of the strategy of many organizations. In our research at UIE, we’ve seen that creating usable forms is essential to the success of these applications.

Forms are crucial for users to complete many online transactions, ranging from sign-up forms introducing new customers to your site to checkout forms finalizing your users’ purchases. However, until recently, the knowledge and skills to design a great form was still only available as scattered lore.

In this week’s UIEtips, we’re publishing an article written by Luke Wroblewski, a Principal Designer at Yahoo!, where he discusses how form layout and visual elements can have a real impact on users’ success with your web applications.

Read today’s UIEtips article.

Do you have any best practices for designing forms? What usability problems have you encounted with your web forms? As always, I’d love to hear what you’re doing. Join the discussion below.

[If you find this article interesting, you'll definitely want to attend the User Interface 12 Conference this November 5-8, where Luke Wroblewski will present Site Seeing: Communicating Successfully with Visual Design. This in-depth seminar will provide you with practical insights and strategies for boosting your site's visual appeal and delighting your users.]

Frameworks are a hot topic on the web today, names like Ruby on Rails, Django, Cake, and Prototype.js are all over the place. For the uninitiated, Jeff gives us a nice definition of a framework in the article,

[…] a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around.

Jeff points out there’s no reason you can’t do this with CSS, as well. There are certainly things that you write project after project, and the use of a framework would reduce repetition and increase maintainability. It’s always nice that if someone is out sick, that another person can quickly go through their code and know where to find the part that needs a tweak. Of course, someone doesn’t need to be missing to take advantage the efficiency of a framework. Having a “self descriptive” code library provides a level of documentation to make any long term maintenance of the system far more efficient.

Are you using frameworks to speed up your work?

In the last couple of years, web sites and apps focusing on social interactions have become increasingly popular. We’ve been seeing more and more designs that allow users to collaborate and share what they’re doing with others, including such popular sites as MySpace, YouTube, Facebook, and Craigslist.

But only recently have design teams started to understand the complexities of dealing with thousands or millions of users who want to connect with their peers and coworkers in new and exciting ways. Several prominent incidents, such as the Facebook newsfeed blowup, have shown just how complex the social issues are.

In this week’s UIEtips, UIE’s Joshua Porter, an expert on the issues related to Social Design, has written a fantastic article outlining many of the common pitfalls that lead to failure when building social applications. Today’s UIEtips article was originally published on Josh’s blog, Bokardo. If you haven’t yet checked out the Bokardo blog, I highly suggest you take a look if you’re interested in Social Design. Josh is *the expert* we turn to at UIE when researching these types of issues.

Read today’s UIEtips article.

Is your organization starting to focus on Social Design? How are you handling the complexities or connecting your users in new and exciting ways? As always, I’d love to hear what you’re doing. Join the discussion below.

[If you'd like to hear more insights from Joshua Porter on Social Design, you'll definitely want to check out his UIE Virtual Seminar, Social Design: Designing for the Social Lives of Users.]

Rebekah explains why she uses comics:

Comics are effective not only because they are essentially narrative, but also because they are unpretentious, easy to follow, and accessible. Whereas a functional specification document uses words and often “tech speak” to communicate functionality, comics use pictures and interactions to get ideas across. Comic artist and Yahoo! staffer Kevin Cheng put it best, calling comics “the universal language.”

And how she uses comics to explain the user experience in a series of steps:

Step 1: Focus on the point (forget the details) I was already well aware of our key scenarios and use cases, so I crafted brief stories in paragraph form for each one. Taking the time to write these stories before incorporating them into a comic allowed me to focus on the main points and the completeness of the message without the clutter of images and thought bubbles…

If you’re still skeptical of the value of comics, I think Rebekah’s story will give you a new perspective. You can read Rebekah’s full article, and see the sample comics here: Comics: Not just for laughs!

The answer was interesting: “Yes, your SDK will be Web 2.0 + AJAX”

The only way for third-party apps to run on the iPhone will be through the Safari engine, which is part of the OS X install that powers the iPhone.

Interestingly, the apps can have the iPhone look and feel. Apple showed a custom iPhone application that worked as an LDAP corporate address book, written by one person in less than a month using around 600 lines of code. Such apps can access iPhone resources, give apps the ability to make phone calls, access Google Maps, and so forth.

The second, and somewhat unexpected announcement, is that Apple has expanded their standards-friendly and open-source derived browser to the Windows platform. Version three is available now, in beta, on Apple’s Safari site for both XP and Vista. This has a number of implications:

• Easier testing of web sites for compatibility with Safari, making a Mac an option for the Windows-based developer
• The very standards-friendly WebKit engine can now expand its user base beyond Macs and the iPhone (Safari), Linux (KHTML) and Nokia phones
• Yet another standards-friendly browser for Windows is now available – competition is good.

Mac users also can download the v.3 beta for Mac OS X 10.4.9 (Tiger) but be warned that the install will overwrite your v.2 install. Clearly, Apple believes this beta is stable.

Lastly, you may notice that Apple also completely revamped the look and feel of its well-regarded and highly-trafficked website quietly while Steve had us distracted during the keynote. They’ve simplified the navigation panel at the top, widened the page and redefined the visuals to fall inline with the upcoming Mac and iPhone software.

In the Apple sphere of influence, it was a big day for web developers. And that sphere seems to grow daily.

[ Postscript: If you've found this post interesting, I've written a more speculative commentary on my personal blog, discussing what impact I think Safari will have on the mobile web, check out my post on WWDC '07 ]

Back in January we had planned to have Stewart Butterfield, co-founder of Flickr, speak at our Web App Summit. Sadly, events conspired to force Stewart to Europe at the last moment. In his stead Peter Merholz and I got together to lead an analytical interactive discussion on what makes Flickr such a success in the Web 2.0 space, and as a popular destination in general. What makes it such a draw? It can’t just be AJAX.

» What tools does Flickr use to foster its community?
» Does the service have a personality?
» How is it different from competing sites?
» How does Flickr invite you to discover new tools?
» How does the app leverage its API to increase its values?

Flickr is often mentioned in our individual talks for just a few minutes. It was really interesting to collaborate and dig deeper into the app and explore its many layers of innovation. I hope you enjoy this recording as much as I enjoyed the session.

Q: Although there are established design and usability best practices and standards, there are also varying standards within companies’ definitions of good design and usability and the role design should play in the product development process. Some companies value form as well as function whereas others appear to value function only. Is form still a valuable element in usability?

A: There are two strongly interconnected ways to utilize form: personality & visual organization.

Personality–or visceral design if you prefer-is defined by the subjective reaction people have when viewing a product. It’s the combination of fonts, colors, images, shapes, and patterns that tells you which laundry detergent is tough on stains and which one provides a delicate touch. Though this aspect of form predominantly enforces a brand message for products it can also have an influence on usability. To substantiate that point, Don Norman has recently exposed research that indicates “attractive things work better”. To quote “When you wash and wax a car, it drives better, doesn’t it? Or at least feels like it does.” So there’s a corollary between aesthetics and ease of use.

For many people, the role of visual design ends there as they only consider form for “making things pretty”. As a result, they overlook the crucial role of visual organization.

Visual organization is the deliberate prioritization of meaning within a visual design. It’s the process of applying the principles behind perception–how we make sense of what we see- to illuminate relationships between content and actions. Through applications of visual contrast, designers can communicate the steps required to complete a task, the relationships between information, or the hierarchy between interface elements. Since the majority of people are only able to interact with a Web application through its presentation layer, visual organization is a key component for successful interface designs. It essentially tells people how to use things. Personality, on the other hand, tends to focus on why.

You can read the entire interview here: Interview with Luke Wroblewski, Senior Principal Designer,Yahoo! Inc.

Sean Kane, showed off some of his behind the scenes work on Netflix.

Jon Wiley showed off some of his and his team’s work behind the scenes on Google Apps. He asks, can you market usability?

Luke Wroblewski of Yahoo! talked about the structures of web content. What do M-16s and AK-47s have to do with Web 2.0? (hint: révolution!) How does usability address the complexity of data on the web?

The three then participated in a round table discussion.

The entire two and a half hour presentation is available to view on Google Video. There’s lots of great stuff here.

Additionally, Luke also did a followup blog interview with moderator Reshma Kumar, VP of WebGuild, in which he expands upon the topics he discussed at the event. This interview will also stand on its own if you don’t have time to watch the video first.

In the interview, Luke touched upon the roles of form and visual organization in usability, addressed design for the mobile web, noted the value of usabilty testing, and more. Check it out.

You can view the first set of 30 here: 30 Great Website Designs (Part1).

You can view the second set of 30 here: 30 Great Website Designs (Part2).

I’d like to hear your thoughts on whether or not you think these web sites are usable as well as visually appealing.

For those of you not familiar with SharePoint, it is a web application from Microsoft that’s deployed within an organization for collaboration purposes. I’ll pigeon-hole it as an intranet-in-a-box™ app.

There are a lot of people out there, web developers and designers especially, who have this app in their organization and they don’t much about it. And now they’ve been charged with wrangling it. The complaint I hear repeatedly is that it is difficult to make properly coded web pages (CSS, semantics, et al) on the SharePoint framework. The phrase “surrender” is thrown about commonly.

Several people have referenced Jared’s comments on the topic of SharePoint at the Web Directions North conference.

Implementing Sharepoint is a lot like building a house. It’s like a friend of yours says, “I know exactly what to do.” And, he drives you to a Home Depot, drops you off at the front door and says, “Everything you need is here.” Then, drives off.

Luckily for SharePoint users, Cameron knows a ton about semantics and CSS, has been thrown into the same position as many of you, and is sharing his discoveries. A big thanks to Cameron.

Unlike most of its hardware and software rivals, Apple has eagerly used open standards and open-source software to develop–ironically enough–a system that combines proprietary hardware with proprietary software. Apple’s iCal was one of the first widely available desktop calendar programs to adopt the iCalendar standard; Apple embraced iCalendar so early that many people mistakenly thought Apple had invented it.

Being so intimately familiar with Apple myself, sometimes I forget than many people may not know how involved in open-source software Apple is. It has a reputation for being proprietary, but since the return of Steve Jobs, UNIX and other open-source projects have become a staple upon which Apple innovates.

All this borrowing is completely legal, and the result is that Apple is able to direct more of its R&D dollars to developing distinguishing technology, since it doesn’t have to spend as much on the “plumbing” of today’s information infrastructure. That directly benefits customers by lowering Apple’s cost of innovation. It also benefits Apple’s third-party developers by making Macintosh development not all that different from Linux development, which is generally regarded as a lot easier than developing software for Microsoft Windows.

If you’re curious how much they are leveraging this, Apple’s produced a 20-page PDF on the topic of open-source and UNIX in Mac OS X 10.4 (Tiger). Expect more in 10.5 (Leopard) this October.

Could you free up some resources by using more pre-fab plumbing in your product?

David Churchville, over at the Agile Project Planning Blog, wrote about what he thinks are the core elements to successful Agile development projects: Small wins.

Small wins create momentum. Continuous small wins create tremendous momentum. OK, but what kinds of small wins are important in software projects?

• How about early positive feedback from customers?
• Or early clarification of an important feature (that leads positive feedback later)
• Early detection and resolution of defects before they lead to not-so-positive feedback
• Early proof that you can build and deploy the software somewhere other than your own machine

Small wins allow for a feeling of progress and achievement, and help developers, customers, and stakeholders to see the true value of your new product.

You can read David’s full-post here: Small Wins: Agile Psychology

David also has a follow-up post, Agile Project Management and Competitive Advantage, outlining the reasons he thinks Agile development is crucial to software releases.

In just the past couple of years, we’ve seen more and more designs that allow users to collaborate and share what they’re doing with others. Web sites and applications such as MySpace, Flickr, and Craigslist, are becoming increasingly popular.

One of the underlying reasons for their popularity is because they all focus on Social Design, an area of design that deals with the activities, behaviors, and motivations of people who work and play together through software interfaces. Each of these social applications connect users in new and exciting ways.

In this week’s UIEtips, we’ve republished Joshua Porter’s recent Brain Sparks blog post discussing how organizations can benefit from incorporating social features into their designs. I’ve decided to share the post with all of our UIEtips readers because I think Josh’s commentary on the importance of Social Design is just too important to miss.

As always, please share your thoughts with us. Have you ever wondered why sites such as MySpace and Flickr are so popular? Have you considered incorporating social features into your design? Leave your thoughts and join the discussion below.

Read today’s UIEtips article.

[If you find this article interesting, you'll definitely want to attend the User Interface 12 Conference this November 5-8, where Joshua Porter will present at UIE's Showcase Seminar, Usability 2007: The Latest Perspectives. In this seminar, Josh will share his latest research on Social Design practices.]

Kathy Sierra has a really funny, yet pertinent post on what has come to be known as “girl code.”

What prompted this post–and it’s whimsical title–is a post by Jamis Buck titled Beautiful code, test first, which includes the following: “He was telling me how he feels like he has to sit and tweak his code over and over until it not only acts right, but looks right. It cannot be merely functional, it must be beautiful, as well.”

But the best part was a comment by “Morten” that included the line:

“As for spending too much time on making the code look right down to the last indentation – my code has been called “girl code” for the same reason…”

Kathy also outlines the benefits of creating code that’s well formatted, well documented, and easy to maintain. This post particularly struck a chord with me, as a large portion of my background is based in programming. It’s tempting to throw a bit of Java, C++, Ruby, or what-have-you around and say, “Oh, it works. Who cares what it looks like?” But, when it comes to usability, everything on the inside is just as important as everything on the outside.

You can read Kathy’s entire post here: Code like a Girl

Also, for non-programmers, you can see a quick example of some less-than-stellar code with a nice write-up explaining its pitfalls here: What’s Wrong with this Code?, by Chris Becker.

How do you handle the aesthetics and usability of your product’s insides?

Jeff Patton has a really cool article outlining what he thinks are the two aspects of human behavior that surface when encountering new products, which he calls the buyer head and the user head.

The buyer head looks at the product objectively, considering how its features will help to achieve specific goals, address certain needs, and rectify various problems.

The user head looks at how effective the product actually is in achieving those specific goals, addressing those certain needs, and rectifying those various problems. The user head also evaluates ease of use and the emotional response the product generates.

Sometimes the buyer head and the user head agree on a purchase decision. The customer is satisfied with the value, features, and experience that the product provides. But other times, the buyer head and the user head end up in conflict, especially when the product does not provide a pleasant experience, even though it provided the best value.

By learning how to appeal to these two sides of potential buyers, design teams can create products that have great value in terms of money, time and goal achievement, are easy to use, and provide a delightful experience. While these aren’t the only two “heads” to consider, designing for the buyer and the user in all of us may prove to be an effective way to drive sales and create satisfied customers. I think you’ll find Jeff’s article extremely valuable.

You can read Jeff’s full article here: Designing Software for Two-Headed People

Gerry McGovern just wrote a piece examining Don’s argument, where he gives various reasons for using complexity to appeal to customers when designing physical products.

…we love to show off. Complexity is like the peacock’s feathers. It is brash and impossible to miss. Complexity lets other people know how clever we are and how rich, because we can afford such complexity…

This is definitely something everyone can relate to. I’ll admit I bought a Motorola Razr the second it came out because it was flashy, laden with features, and made people “oo” and “ah”. Now two years on, I’ve found I don’t use anything on the phone besides talk and the camera. Whether I planned to use the Razr to its full extent or not is irrelevant. I wanted a reaction from my peers.

Everyone is different though. Some people are very minimalist, some people are very high tech, but most people are just caught up in the latest fads. This leads me to wonder if people really care about whether a product is simple or complex, or if people just care that a product is new, trendy, and in high-demand. Apple’s iPod is a simple device, yet it’s the most popular media player in the entire world. Microsoft’s Zune, which has more features than the iPod, isn’t doing so hot. What gives? Is it our ego that drives what we look for in a product? To steal a line from Jared, when someone asks me if I want to see their iPod, I automatically say, “Yes!”, but when someone asks me if I want to see their Sandisk Sansa e280, I give them a weird look.

Moving away from the design of physical products, Gerry asserts that simplicity is king when designing for web sites.

…we can’t wear a Web site, drive around in it or show it off at a party. Browsing a site is essentially private behavior. When we go to Google we are usually alone. We search for cheap flights, but we certainly don’t go around advertising that we’re cheap.

We may still end up buying complex products on the Web, but our Web behavior will remain relentlessly simple and hugely impatient…

Do we just want an effortless way to acquire products that make us feel superior? What do you think?

You can read Gerry’s full article here: Why Simplicity is Essential
to Web Design.

[Joshua Porter also wrote an in-depth article addressing this topic. You can read Josh's article here: Simplicity: The Ultimate Sophistication.]

…the prototyping stage is the right time to catch design flaws and change directions, and the flexibility and disposability of paper encourages experimentation and speedy iteration. Instead of “deleting” hours worth of layout code you’ve used to position a column in the right place, you can draw a prototype, throw away the ideas that don’t work, and move on.

Another benefit of the use of paper is it’s highly inclusive to the non technical people who may be involved in the design process. Someone might not dive right into Flash/Dreamweaver/Photoshop, but they can pick up the scissors and sharpie pen and draw some boxes and arrows to get their point across.

[We've been talking about Paper Prototyping for some time, and if you're interested in learning more on how you can quickly unite your stakeholders with wheat paste, you're in luck! On February 6, 2007 we'll be holding our next Virtual Seminar, Paper Prototyping: Streamlining the User-Centered Design Process. Our friend and colleague Carolyn Snyder will be presenting, and she literally wrote the book on Paper Prototyping: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces]

Originally recorded at the User Interface 11 Conference, recorded in Cambridge Massachusetts on October 10 2006.

There’s been a lot of talk about Rich Internet Applications (RIA) over the last few years. When the topic was first raised through the release of Flash MX’s change in focus from an interactive animation development studio, to an application development environment, there was an early conversation about trying to define what a rich internet application is. Then as other players tried to enter the field a bit more ferociously, the conversation has turned towards how to make rich internet applications. Not in terms of design, but rather in terms of technology. Little care has been given to the more sensitive topic of what and why.

In this presentation, David Malouf moves beyond the usual story of patterns, code, and tips and tricks, and talk more about aesthetics, experience design, brand, and total environmental context of use. He layers those elements over a discussion around trying to define “richness” in the context of general application design and then try to apply it to a continuum of various types of computer and network based solutions.

David Malouf is a passionate spokesperson for the discipline of Interaction Design. He founded the Interaction Design Association and became its first Vice President, with a keen eye towards evangelizing interaction design in the areas of practice, research, and education.

David is now a Senior User Experience Designer at Symbol Technologies, where he designs a wide array of complex system applications as well as software to run on various types of handheld devices. (At the time of this recording, he was still working at Interlinks, doing similar work.) Over the last 7 years David has designed RIAs ranging from e-commerce sites to enterprise software platforms utilizing a range of technologies including, Java, .NET, Flash, and AJAX.

If you found this presentation interesting, I encourage you to join David live in Monterey, California this January at our UIE Web App Summit. David will co-present, along with Bill Scott from Yahoo, their full-day workshop, Designing Powerful Web Applications using AJAX and RIAs. This workshop was a hit at the UI 11 conference and we expect it to sell out quickly.

(If you’d like to get all of the Brain Sparks Audio Library in iTunes, just paste this link into the Subscribe to Podcast feature.)

Recently, I’ve been playing with a new feature of Google.com: Google Docs and Spreadsheets. Trying these out is a must-do activity for any interface designer.

At first glance, they look just like any other word processor or spreadsheet. However, that’s what makes them impressive. They are implemented completely in a browser, using only standard HTML and Javascript.

The line between what we do on the web and what we do at our desk has significantly blurred. This presents opportunities for application developers that were previously unthinkable.

Yet, it also presents challenges and puzzles to solve. We need to learn an entirely new interaction style, with new constraints and new boundary conditions. (For example, how do you make accessible AJAX work?)

Two people who are at the head of this curve are Bill Scott and David Malouf. Bill is Yahoo!’s local AJAX evangelist and David has been a major player in the founding of the Interaction Design Association. Both have been at the forefront of this new wave of interaction design.

Josh Porter and I recently had a chance to talk with Bill and David about some of the challenges and changes that are happening in the interaction design space. We were supposed to talk for only a few moments, but the discussion was so fascinating, we kept talking for almost an hour.

In this issue of UIEtips, we’ve put together some of the best parts of that discussion. You’ll read what David and Bill think about choosing AJAX versus Flash, what’s a good starting point for learning these technologies, and how design patterns can help with the development process. I’m sure you’ll find it as fascinating as I did.

Read today’s UIEtips article.

Have you been experimenting with RIAs and AJAX? Is this an area you’re thinking of moving to? We’d love to hear your thoughts on this. Leave a comment and join the discussion below.

[If you find this article interesting, I encourage you to join us in Monterey, California this January for our UIE Web App Summit. David and Bill will present their acclaimed full-day seminar, Designing Powerful Web Applications using AJAX and RIAs, as well as give their own short talks. You don't want to miss out. See the summit website for more details.]

Usually, we’re not like this. We don’t get too excited about the new technologies that are introduced. After all, we never really got excited about mobile computing. Or, ubiquitous technology. Or, speech technology. Or, rich media. Or, tablet computers. None of these things excited us enough to really pay attention. When clients would come to us and say, “What are you thinking about designing for handhelds?”, we’d just say, “That’s not our area of expertise. We haven’t looked at it yet.”

NASA’s a client and they have a saying about the technology they use: “It has to be old enough for the Space Program.” NASA likes proven technology for their spaceships and I guess we’re very similar. We don’t like to look at something until it’s been around and proven to be something more than hype or a fad.

So, why did we get excited about Web 2.0? The thing that excites us the most is what people are doing with it. We’re seeing interesting new applications appearing out of nowhere, all because of this new platform and its capabilities.

I think it makes sense for designers to really understand what Web 2.0 is and what it could mean for them. That’s why in this week’s UIEtips we’re re-printing an article I wrote last year, where I discuss the power of API’s, RSS, Folksonomies, and Social Networking. I hope you enjoy it.

Read today’s UIEtips article.

Have you looked at the Web 2.0 platform yet? Do your applications take advantage of APIs, RSS, Folksonomies, and Social Networking? Does it intrigue you? Scare you? Bore you? I’d really be interested in your thoughts. Leave a comment and join the discussion below.

[If you find this article interesting, I encourage you to join us in Monterey, California this January for our UIE Web App Summit. On Day 3 of the event, we'll explore the important innovations from the Web 2.0 phenomena. We've invited the experts behind these approaches to give you insights into how to integrate them into your design. You don't want to miss out. See the summit website for more details.]

Designing with Patterns

We’re lucky to have Bill speaking at our upcoming Web App Summit this January in Monterey, CA. He knows a tremendous amount about both creating and disseminating patterns, and his full-day tutorial with David Malouf contains an in-depth discussion about them.

Here’s a snippet from the article about how patterns play a dual role for teams:

“Patterns really act both as a design vocabulary and as a way to capture emergent best practices within the context of a specific design problem. With the recent advent of AJAX and the resurgence of Flash within the page, there are a number of new (and old) idioms that are now appearing on the web. As these idioms emerge, it’s handy to have a common terminology across Yahoo! for referring to them.”

Joost points out that single-screen interfaces have a big advantage over page-based approaches because they allow users to work in their own, non-linear way. He says:

“In a multi-page environment, there are likely to be separate pages for almost every task in the purchasing process, including a search page, a page listing search results, pages displaying detailed information about individual search results, some options pages, pages showing pricing and availability, and booking pages. It’s difficult to make sense out of such dispersed information. When customers are looking at a page showing details about a particular search result, they can’t see the list of search results, making it difficult to compare and rank different results. When they are looking at a list of results they can’t see the search criteria that produced them, making it difficult to adapt their search criteria and come to grips with all the different offerings.

Customers who need to assess a great many search results must visit and revisit a lot of pages. In doing so, they often lose track of the big picture and waste a lot of time clicking back and forth and waiting for the server to deliver pages. They may become disenchanted with an online travel site that seems to punish them for not knowing exactly what they want.”

Although Joost doesn’t mention them specifically, an excellent example of a single-screen travel interface that realizes much of what he’s talking about is Kayak.com, who have continually iterated their interface over time with incredible results. They combine a single-screen with various filter mechanisms to make finding the right flight really easy. Here’s a screenshot:

To get the real experience of using Kayak’s single-screen interface, simply perform a search from their homepage. The results are a great use of what Joost calls “spatial adjacency”, meaning that multiple items (that used to be on separate pages) are now in adjacent positions on the screen.

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”

Other People Have the Itch, Too

What happens next is the same: after you scratch your own itch someone realizes that others have the itch, too. It might be the developer who notices, or another user. Mike McDerment, who co-founded Freshbooks, a web-based accounting application, describes this:

“(We) founded the company in January 2003. We were doing web design and development projects for various clients. We built FreshBooks for ourselves and very quickly realized that other businesses needed a painless billing solution. We put our heads down and got to work.”

Eating Your Own Dogfood

After you realize that others have the same problem, the next step isn’t to start building for all of those other people and assume you know everything. No, it’s to continue to design for yourself, and then use the product for an extended period of time. Play with it, push it, pull it, make sure that the features there are the right ones, not the nice-to-haves.

Christina Wodtke (who spoke at our User Interface 9 Conference), is working on a new web app: Public Square. She’s testing it out in a small way before releasing it as a service, using it to run one of our favorite sites, the online magazine Boxes and Arrows. She’s effectively killing two birds with one stone…using it herself as well as testing it with others to get real feedback.

Increased Passion for the Work

This users-as-developers cycle may be more virtuous than others. Dan Cederholm, who co-built a wine-sharing site called Corkd, describes how much more passionate he is when working on his own project.

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people. Cork’d has been the complete opposite situation, where we’ve been able to launch a product that would be considered “done” under most circumstances and then react to member feedback using the same attention to detail that went into the initial construction.”

A New Model

At first, it can be quaint to say that building for yourself is a nice perk of your situation. Increasingly, however, starting with eBay and now with firms like these four (and countless others as well), this new model is becoming the de facto way to develop, a critical part of success. If you compare a piece of software created by its users vs. one that’s not, it’s pretty easy to tell the difference. The designers understand the problem better, they’ve worked through most of the issues, and they’re more passionate about it after all is said and done.

You may have seen one of my recent presentations where I talk about the failure of Blockbuster to win at the home-delivered DVD game. In this presentation, I’ll often take a show of hands, first asking people if they participate in Blockbuster’s program, then asking them if they participate in Netflix’s program. Usually, I get only one or two people, if any, who say they participate in Blockbuster’s program. (In contrast, almost everyone raises hands for Netflix.)

Recently, I was stunned at one presentation when several dozen people said they subscribed to Blockbuster. I was even more surprised because
of where I was at the time: in the main auditorium of Netflix’s corporate headquarters addressing a hundred of their designers and developers.

Josh Porter and I were on a swing through Silicon Valley when we had a chance to visit Netflix in their new headquarters. As soon as you pull in the driveway, you can tell these people really like their movies.

The building has an old So-Cal movie studio motif and the front lobby feels like you’re walking on celluloid. They’ve named every conference room after a film, complete with etched imagery in the glass. (The larger-than-life image of Tim Curry’s Dr. Frank-N-Furter in the window of the Rocky Horror Picture Show room is astonishing.) Even the bathrooms are named for film personalities (the first floor as Fred and Ginger; the second floor has Boris and Natasha).

I think this speaks to Netflix’s success. These folks live and breathe movies. They start many of their staff meetings with a discussion of movies.

However, they don’t just subscribe to their own service, which they get free. Many also subscribe to their competitor’s service.

The folks at Netflix really understand what it takes to make a culture that supports successful experience design. We were quick to notice the quality of the people they’ve assembled on their team and the culture they’ve built to create a great design.

All of that has paid off. Netflix is a darling of the high-tech world, showing how, in less than a decade, you can create a new type of business and beat the established, entrenched players. (Netflix is now twice the market cap of Blockbuster, having regularly shown a profit while Blockbuster regularly shows losses.)

For today’s UIEtips, Josh Porter describes one aspect of Netflix’s culture responsible for their success: Fast iterations. Because they are constantly trying new ideas, they can quickly outmaneuver their competition and stay ahead of the game.

Read today’s UIEtips article.

Is your culture accepting of iterating quickly? Do you face obstacles getting designs in front of users rapidly? We’d love to hear your thoughts. Leave a comment and join the discussion below.

[Overcoming the challenges of web-based applications is exactly why we've put together the UIE Web App Summit, in Monterey, CA on January 21-23, 2007. We've assembled an amazing team of speakers, all of whom have overcome some significant challenges in some very creative ways. You don't want to miss out. See the summit website for more details.]

Have you ever noticed that many successful web apps seem to change a lot? The designs are always being retooled, changed, improved, upgraded, tweaked?

This is a trend we’re seeing more and more of. Many teams are changing their development process to speed up iterations. Instead of taking months to roll out a new release, they’re breaking it down into smaller parts and releasing them more often. This helps to reduces risk, the smaller the change the smaller the risk and the easier it is to figure out what is working and what isn’t working. Taken to the extreme it would be science: test one isolated variable at a time and iterate accordingly.

One of our clients recently told us, “the faster we iterate, the faster we learn”. In his view, the quicker they release iterations, the quicker they can improve on them. They call this on-the-job-training, referring to the app as being tested by the actual users while they’re using it, as opposed to traditional pre-release testing.

So how fast can app iterations get? Well, teams are all over the map. Another team we know takes about 4 months to make any change to their web app, even the smallest text tweak. If they want to change a navigation button to read different, it takes 4 months. The levels of corporate hierarchy and business rules simply take that long. Interestingly, the product inventory on their site is updated daily, by a completely different development team! They have fully separated their application framework from the products they’re showing in it.

Most teams are faster, though. Mike Davidson, who founded Newsvine, a social news app, recently wondered if two week iterations were fast or slow. Apparently, for some teams it is dreadfully slow, as they update as fast as they can.

I spoke with a developer of QVC.com at the UI Conference who said they often update their site several times a day. Their promotions practically demand it. One promotion might run out in twelve hours and they have to get it on the site and taking orders as fast as possible. He said they also do extensive A/B testing to see what sorts of promotions work and what ones don’t. But they bypass that slower testing method when they need to get a promotion up quickly.

Iteration for iteration’s sake is probably a bad strategy. But many teams are moving to fast iterations to both learn things faster and sometimes simply because their business rules demand it.

So, how fast are your iterations?

Note: This post grew into an article: The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site

Download a Free Chapter of The Designer’s Guide to Web Applications here.

We’re really excited about this report. One of our most popular conference speakers, Hagan Rivers (who is giving a full-day tutorial at the Web App Summit in Monterey this January) has distilled some of her vast knowledge of web applications into this easy-to-read report. Some of the topics she covers are:

• How to build your application’s structure diagram. Hagan will explain how to use structure diagrams as shorthand for visualizing your designs. Structure diagrams help you communicate your application’s structure with your team members and to help everyone focus on the key parts of the design.
• How to identify the two basic forms of application structure: Hubs and Interviews. The two most common structures found in web apps, Hubs and Interviews are essential components in your toolkit. You’ll get a comprehensive introduction to these two components, with several examples showing you when to use each type of structure.
• Which design elements to use. Hagan will show you where and when to use tabs, menus, breadcrumbs, links, and titles in your application. She’ll go over the strengths and drawbacks of each element.
• How to build your application’s Command Architecture. When you design the organization of an application, you’re building a command architecture, a hierarchy of hubs and interviews reflecting each command in your application. Hagan will show you how to build your architecture, step-by-step.

If you’re just getting into web apps or are working on improving the design of an existing one, Hagan’s report will prove invaluable. And don’t forget to check out the free chapter

Would you like to join us? The UIE Web App Summit is being held from January 21 – January 23, 2007 in Monterey, California at the Monterey Marriott Hotel. We are currently looking for volunteers who are available to assist us throughout the full three days of the summit. Volunteers will be asked to arrive by 3pm on Saturday, January 20th and stay until the end of the summit.

Throughout the main three days of the summit, volunteers will be assigned to full-day seminars and short talks to assist summit speakers with their needs. We’ll make every effort to accommodate your preference for which sessions you’d like to attend. Volunteers are responsible for paying for all travel and hotel accommodations but we will provide breakfast and lunch Sunday through Tuesday of the summit. The registration fee is waived for volunteers.

If you’re interested in volunteering, or if you have any questions, please send your replies directly to Ashley McKee at amckee@uie.com. Priority will be given to full-time students and those of you available to help out for the full event from Sunday, January 21st through Tuesday, January 23rd.

‘You don’t always want to write copy that exactly matches the user’s task. It’s a very special skill to write copy that speaks to the user’s task but doesn’t call it out explicitly when you don’t want to. Just imagine those folks who are looking for a hotel room at dirt-cheap prices. You probably wouldn’t write copy that says “Dirt-cheap hotel rooms”, but that might be the idea you want to communicate’.

Gerry’s heavy Irish brogue and great presentation skills makes this much more funny than I can write. But matching the person’s task (and their conception of their task) to the copy on the page is a unique and important skill. Interestingly, as Gerry points out, people do approach tasks in many domains similarly. Many people shop for cars in a similar way, for example. They perform many of the same tasks in the process of purchasing a car, no matter what kind of car they’re looking for or even what country they’re in. Some of these include:

• Choosing a model
• Research financing options
• Research safety/consumer reports ratings
• Exploring pricing options/packages

Though there are many other steps involved, these are big ones that many people buying cars go through. When creating an information architecture, you can be sure that these tasks are going to be important. When matching these tasks to the type of business you have, the actual words in your information architecture needs to reflect the values and ideas of the users you’re writing for, without resorting to saying something like “You’ll be cool with the in-dash iPod player”. Gerry calls this “framing” the web site from a small, core set of tasks, or what he calls the “Long Neck“.

I’m sitting in the Designing Powerful Web Applications with AJAX and Other RIAs session given by David Malouf and Bill Scott. Right now they’re discussing AJAX-friendly application frameworks like DOJO, Ruby on Rails, and Yahoo’s User Interface Library. These guys really know their stuff…I’m finding out how little I know about the latest application technologies.

David is now talking about the importance of talking to developers, really pushing the needs of users and the importance of advocating for users during the design process. He suggests that interface designers, even if they aren’t writing code, could use a high-level overview of the important details of the frameworks their developers are using. This isn’t so that interface designers can give pointers to the developers, this is so that the team can better understand each other’s needs, which leads to better team chemistry and communication. David’s point echoes very closely something that we’ve found at UIE: the design teams that focus on users best are those that communicate most…they’re always talking with each other and learning about each other’s needs.

In general, there’s a tremendous amount of conversation here…I just hope I can remember and share 5% of it!

Deep AJAX

A two-day deep dive into developing real world applications using AJAX

Details at www.gbcacm.org

About the Seminar:

AJAX — more an approach than a technology — is one of the hottest topics for Internet developers. AJAX builds rich interactive applications using standard browser technology, enabling delivery of sophisticated user experiences without the problems of distributing and updating client software.

This seminar is designed for Web developers on a deadline and in trouble — or anticipating being in trouble! — who are developing interactive Web applications that stretch the bounds of the possible.

We are taking some of the leading developers of AJAX Websites and tools — people who have “been there and done that” (and lived to tell about it…) — and giving them the time to delve into the details of what it takes to make the AJAX buzzword into real applications

If you are looking for high level overviews, marketing presentations and academic theory, this isn’t the course for you. On the other hand, if you are “up to your eyeballs in alligators” and want to learn from people who have already drained this swamp, then we’ll see you in October!

Speakers:

• Alex Russell – Project Lead for Dojo Toolkit, President Dojo Foundation
• Adrian Holvaty – Lead Developer, Django Web Framework
• Simon Willison - Yahoo! User Interface technology development team

Presented by Greater Boston Chapter of the ACM
Professional Development Seminars
www.gbcacm.org

Following the Defining the Problem series on Functioning Form, several designers asked how they should go about reframing problems with clients. How could they shift the conversation from an analysis of specific solutions to a broader discussion that better defined the problem they were trying to solve? Perhaps the best way to illustrate such a process is with an example.

Several years ago, I was called in to help redesign the registration process for a large European e-commerce site. The company had put together two options for a new registration flow. Both were compiled by engineering and product management teams and incorporated “best practices” from competing sites. I was tasked with determining which option would work best and to address any usability issues either of the options might have.

Read Luke’s article.

Changing Architectures

Some of the comments were about separating out a change in the look and feel of a site from the underlying architecture. People argued that changing the internals, such as implementing a new content management system, search capability, or advertisement management system, can be difficult to do in a piecemeal fashion, making it very tempting to do an entire overhaul of the site.

This could be true. I’ll be the first to admit that I have very little exposure to that side of the business. However, when we watch our large clients, such as Yahoo!, NetFlix, and Amazon do their work, we know that they’ve had architectural changes that didn’t require a major redesign of their entire sites, at least that any user noticed. So, it’s possible to make those changes under-the-covers, without affecting what the user experiences.

I do realize that possible does not equal inexpensive. Costs may make doing this prohibitive. However, design is all about trade-offs. What’s the trade-off of the costs to support multiple architectures in a staged-roll-out versus the costs of the user experience disruption that comes from a sudden major redesign? That’s the question that needs asking.

Reducing Risk

The main impetus behind my article is about reducing risk. Many have heard me talk about the big-box retailer who, in 2003, spent $100,000,000 on a redesign of their site to find, upon their major re-launch, a 20% reduction in sales they never quite recovered from. (Think what they could’ve accomplished if they’d only spent $50,000,000 on the redesign! And, no: I can’t tell you who they are — everyone wants to know {sigh}. I’ve been sworn to secrecy. If I tell you, I have to kill you.)

A major re-launch is risky because:

• You have a lot of stakeholders – Redesigning the entire site means you have every stakeholder involved. Not just the folks for the major content/application areas, but the folks in charge of the little details, like the investor relations and career folks. That’s a lot of coordination to make everyone happy.
• You have a lot of personas – A major redesign implies that every persona, including the odd cases (a WSJ reporter coming to get information for a story on the quarterly earnings) need to be considered.
• You have more code – A major redesign means touching every part of the code. Longer to implement. More bugs to squeak out. More instances of unspoken requirements that get dropped.
• You are less likely to have a fallback – Often, the changes involved in a major redesign are so extensive they cut off fallback options. If things go very wrong, you’re less likely to have a way go back to the old system.

With a incremental change approach, you:

• Reduce the number of stakeholders to only those players involved in the particular iteration. Less masters to serve means you’re more likely to meet all their needs.
• Reduce the number of personas to only those who are important to the iteration. Again, it’s more likely you’ll create a design that meets those personas needs and increases the chance you’ll come up with something they find delightful.
• Reduce the amount of code, which shortens development time, reduces the bugs needing fixing, and allows teams to quickly identify surprise requirements.
• Keep an easy fallback option, because, rarely, does an incremental change eliminate the option of going back to the previous version if things go horribly wrong. (Plus, when it does go wrong, fewer users feel the impact and smaller code means fixes are easier to come by.)

While a major relaunch is tempting, when you factor in the time spent dealing with all the things that will likely go wrong, the incremental approach is probably less time. And it’s less embarrassing when Murphy raises his ugly face.

Battling the Cultural Forces

Several people commented on the appeal of dumping everything and starting from scratch. Certainly, I can see where they are coming from. Sometimes, if no real thought was put into where you are today, using that as a base might be undesirable. There might be merit to Monty Python’s “Quickly, Quickly, Run Away!” approach.

But I see a flaw in that logic. Our research consistently shows usability problems are caused by developers making design decisions without all the information they need. If you have a site far from meeting its potential, chances are that’s because a lot of bad decisions were made, which implies a lot of information is missing. Where is all that missing information going to come from? How do you know you have all of it?

Designs evolve in a certain direction because of cultural forces. And cultural forces are hard to shift suddenly. As with anything, incremental approaches to cultural shifts will encounter much less resistance.

Picking an important part of the site and redesigning just that portion will more likely succeed because it will meeting less resistance. And when it does succeed, you’ll have learned a boatload about your users, the needs of your organization, and you’ll get the street cred needed to work on making other improvements.

Every week we get calls from people who are looking for help with a redesign of their site. They are rethinking the entire design and hoping their new concept will get them what they want.

The sad thing is they are very likely to fail. We’ve been studying web site design for more than ten years and, if we’ve learned anything, it’s that redesigns rarely improve a site. At best, it just rearranges the elements. At worst, it frustrates the existing, loyal users without bringing anything valuable to all those new users the site is trying to attract.

For several years, we’ve recommended our clients take a strategy of incremental change. Pick one small piece of the site to change and focus on that. You’ll have less stakeholders to cater to, fewer personas to integrate, and you’ll keep the risk down to something manageable, all the while you’ll be learning about your users and what they need.

Back in 2003, I wrote an article entitled the Quiet Death of the Major Re-Launch. This article is just a relevant today as it was back then. That’s why we decided to republish it in this week’s UIEtips.

Is your organization thinking about a major re-launch? Have you come up with a strategy that reduces the risk? We’d like to hear from you. Join the discussion in the comments below.

Read today’s UIEtips article.

[This is one of the many design strategies we'll be covering in our sessions at the User Interface 11 Conference, October 9-12, in Cambridge, MA. You'll want to check out the impressive array of speakers and topics at the conference site.]

The two timelines move in appropriately when you slide one (without a scrollbar). You can select keywords to filter by. It’s all very cool.

As part of MIT’s SIMILE Project, the Timeline demo is intended to be a Google Maps, but for time-based information.

Tip o’ the hat to Nina for pointing us in this direction.

Last week, we sent out the first part of our interview with Luke Wroblewski, author of Site-Seeing: A Visual Approach to Web Usability and UI11 speaker, on the topic of where usability meets visual design. (You can read the first part of the interview here. ) This week, we continued the conversation with Luke.

Are you seeing benefits when you combine visual design with usability in your designs? What challenges are you facing trying to make that happen? Join the discussion below.

Luke Wroblewski will be presenting his full-day seminar, Site Seeing: Communicating Successfully with Visual Design, at the upcoming User Interface 11 Conference in Cambridge, MA on October 11. You can read about Luke’s session, along with the other great full-day seminars, here.

Read the article here.

Enjoy your holiday weekend!

Last night, in a phone conversation between David Malouf (the interaction designer formerly known as Heller), Bill Scott and myself, David shared he took a page out of Yahoo’s book and has been using something similar to Yahoo’s new home page tour.

Yahoo! just launched their new home page and with it created a tour.

Click to see the Yahoo! Home Page Tour.

The tour shows the new home page with various new elements annotated with callout bubbles. Mousing over one of the bubbles provides a larger callout with more information.

The Page Options callout from the Yahoo! Home Page Tour

David’s idea was to use a similar mechanism to annotate new designs his team was conceiving. Creating a static page, with mouse-over callouts gives a quick and easy way for people to understand the new design.

That David guy is pretty smart, I thought.

Somewhere along the line, usability professionals became branded as people who don’t “get” visual design. Their reputation has become one of only thinking about the functional, usage-oriented aspects of design, without considering how something looks.

Maybe it’s because many usability people don’t have training in visual arts and design. Heck, the only thing I can draw is blood. A quick survey of usability web sites shows many of them are not at the high-end of the artistic scale. (Of course, too many of them aren’t very usable, either.)

Similarly, within the usability community there’s a similar perception that many visual designers don’t understand how things are used. There are those who believe the visual designers know how to make things pretty, but at the expense of usability.

From these perceptions comes the belief that the two communities are in contention with each other. That you have to “find a balance” between usability and visual design to produce a great design.

But is this belief correct? Is it about finding a balance between two opposites? Or is it about finding the synergies between two disparate skillsets? Could it be a combination of usability and visual design would produce an effect better than either can do on their own?

UIE’s Josh Porter interviewed Luke Wroblewski, author of Site-Seeing: A Visual Approach to Web Usability and UI11 speaker, on the topic of where usability meets visual design. Luke’s answers were so thorough, we had to break the interview into two sections. In this issue of UIEtips, we present Part I of the interview.

Are you seeing benefits when you combine visual design with usability in your designs? What challenges are you facing trying to make that happen? Join the discussion below.

Luke Wroblewski will be presenting his full-day seminar, Site Seeing: Communicating Successfully with Visual Design, at the upcoming User Interface 11 Conference in Cambridge, MA on October 11. You can read about Luke’s session, along with the other great full-day seminars, here.

Read the article here.