Parenthesis of Forgetfulness

I am reading the excellent book Sleights of Mind: What the Neuroscience of Magic Reveals about our Everyday Deceptions.

In discussing how magicians manipulate attention (looking at the way Apollo Robbins the Gentleman Thief picks pockets) they described a technique called time misdirection. This is when your attention is misdirected in the time dimension. Magicians may introduce delays between the method behind a trick and the effect itself, which makes it difficult to link the two (see pg. 69).

Here's an example from the book:

Imagine that a magician fakes a coin transfer from his left to his right hand, and then opens his right hand to reveal that it is empty. Because there is no separation between the sleight (the fake transfer) and the magical effect (the vanished coin), you may easily conclude that the coin was never actually transferred but remained concealed in the magician's left hand. A more accomplished magician will introduce a separation -- a parenthesis of forgetfulness -- between the method and the effect. For example, after the fake coin transfer, and before revealing his empty right hand, he may reach into his pocket for the overt purpose of retrieving a magic wand, but in fact he is also dropping the palmed coin inside his pocket. Then, touching the magic wand in his left hand to his right hand, he shows that the coin has disappeared.

You can also see the master of sleight, Slydini, using time misdirection over & over in this routine on the Dick Cavett show:

Parenthesis of Forgetfulness

A primary skill of magic is to learn how to hide information. In this case, magicians use the delay of time to take advantage of the way our brains work and misdirect you from the method to the effect. However, when we are designing interfaces this parenthesis of forgetfulness can work against us (often the things that magicians employ, designers have to avoid).

When designing an experience we need to keep the result as close to the action as possible. In other words we have to shorten the parenthesis of forgetfulness.

Performance delays can create this parenthesis. Let's say you want to withdraw or send funds on your bank's web site. If you withdraw funds but it takes a while to show your balance updated in context on the page then your brain will have to work harder to causally tie the action and the result together. One solution is to keep refreshing the user's memory of the relationship by such methods as progress indicators while the user is waiting for the result.

Taking the user out of context through a page refresh to show the result of an action will also create this parenthesis. The time it takes to get to the result (the new page) as well as the change blindness that results from the refresh zaps the brain and takes it to the zone of forgetfulness. A solution to this is to draw the user's attention to what just happened. For example, highlighting the change will work as it refreshes the user's memory and ties the action and result together. But the best solution is to not have action & result span a page refresh. This will remove the parenthesis altogether. Elsewhere I have written about this disconnect before, especially as it relates to change blindness.

What examples of the parenthesis of forgetfulness have you seen in web & mobile experiences? What solutions have you found for these situations?

My Lean UI Tech Presentation from Open Web Camp 2012

Thanks to John Foliot for putting on an excellent Open Web Camp. It was especially great as we got to host here at PayPal at our Town Hall facility.

Lots of great talks. Check out the presentations at http://openwebcamp.org/slides (more to come).

Here is my talk from this morning.

The Lean Tech Stack

View more presentations from Bill Scott

Anti-Patterns for Lean UX

We are going full bore on LeanUX at PayPal. This presentation just captures a lot of cautions for our teams. These anti-patterns call out bad behaviors or situations that can become bad which will stifle collaboration.

Lean UX Anti-Patterns

View more presentations from Bill Scott

What anti-patterns have you seen?

Welcome Crock!

Welcome aboard Doug! Stoked to be working with you again :-)

Interested in where PayPal is headed in the world of Javascript/User Interface Engineering? Ping me. bill.scott at paypal.com.

The Experimentation Layer

Designing for Reusability

Code reuse has been a major concern of mine throughout my career. I graduated with a computer science degree and was taught the value and beauty of loosely coupled, modular code with a clear separation of concerns. In fact some of my most rewarding experiences have been writing user interface frameworks (a few dozen over the last 30 years).

The same goes for designing experiences. Early on I realized that interaction designs could also be reused. Sometime after reading the gang of four book (Design Patterns) I started thinking that patterns could be used to define experiences as well. It was after that I stumbled upon Jennifer Tidwell's excellent work which would later become the book Designing Interfaces. A few years later, I went on to help launch the Yahoo! Design Pattern library and write a book on the subject.

I mention all this to set the context that I am a huge fan of reuse.

Designing for Throwaway-ability

In my prior role at Netflix, I quickly discovered a wrinkle to the reuse mantra. If you know a little about Netflix you will know that experimentation is the bread and butter of refining the experiences there. The big "aha!" moment came (2008) when I counted the number of experiments we fielded vs the number of experiments that became a lasting part of the site. I discovered that

Only about 10% of the UI code written to craft the experience lasted more than a year. 90% of the UI code needed to be thrown away.

Could that really be right? In some cases we were testing 10+ test cells over a couple of months time. Only 1 cell (or sometimes a combination of cells) was selected as a winner. The winning cells often led to a new hypothesis that led to another set of test cells being fielded (perhaps another 10+ cells). And of those a new cell (or control) would end up as the winner. It doesn't take too many 9 out of 10 losers to start seeing that a lot of code needed to be thrown away over the course of a year. (I am over-simplifying this a bit. There is often reuse between test cells as well as the number of cells fielded will vary.)

Now to a typical user the experience doesn't seem to change much in the short term. User A might be in a control cell (the standard experience). And in the next set of tests User A might still get allocated to the standard experience again. So to User A the site seems pretty stable. However if you plot the arc of the experience year over year you will see some substantial changes occur (think: Amazon, Netflix, Twitter, Facebook) as newly minted experiences are released to the full user population.

The epiphany for me was that for the most volatile part of the experience...

We needed to design for throwaway-ability and not as much for reusability.

What does that even mean? Design for throwaway-ability? It means not over-investing in the scaffolding for reuse. It means designing a way to select code for experiments in a simple grokkable manner (like using the file system or packaging mechanisms for bundling experiments together). It means externalizing the logic for selecting experiments as much as possible. It might even mean copy and paste reuse to make it easy to modularize the experiments. It means don't start with writing components, instead start with creating the experience.

Heresy!

When I had this epiphany it certainly felt heretical. Over time I have come to see the wisdom of knowing when to reuse and when not to reuse. However, lest I be next for a good stake burning for giving others a license to writing crappy code (since one could argue that it will be thrown away anyway ;-) let me provide some nuance.

Reuse is Still a Good Thing

Not all of the UI layer changes with experimentation. The nuance is the UI layer contains different levels of volatility. The code to make a button or render a template doesn't change with an experiment. However, the placement of the button or the contents of the template will often vary from test to test.

For the more stable areas of the experience, the great news is we have a rich set of open source libraries and frameworks that can provide a lot of this reuse right out of the box. Examples include component libraries like YUI or jQuery; templating solutions like mustache or dust; MVC patterns like those expressed in backbone.js; common javascript extensions like those found in underscore.js and so on. In addition each organization will find certain aspects of their user experience that benefit heavily from thoughtful reuse.

The truth is volatility increases as you get closer to the user experience and reuse opportunities increase as you move down the software stack.

This funnel illustrates the relationship of volatility and reuse 

as you move up and down the software stack.

UI Layer = Experimentation Layer

What I want to impress upon you is a simple thought.

The UI layer should be thought of as the experimentation layer

Think of the topmost layer of the user interface code (especially the HTML, CSS and Javascript for experiments) as the experimentation layer. As a corollary

You should always create an experience before thinking about creating a component 

In other words seek to use before reuse. I have found in my conversations at PayPal, talking about the UI layer as an experimentation layer is a great way to shift the conversation to the experience rather than to spending months building components and interface scaffolding. The goal is to get code in front of the user as fast as possible. Instead of starting with reuse, we start with the experience.

What about Consistency?

Now let's be clear, experimentation is not the silver bullet that will create the perfect experience. A lot of understanding about the user, scenarios, and just good solid design principles are needed to make a good start on the experience. Experimentation can often lead to local optima instead of finding the overall experience. But given a good experience, experimentation can allow you to refine the experience in the right direction.

One of the valid complaints that designers will often raise about experimentation is that it can lead to different experiences across the product families as the experimentation often is chasing specific business metrics in a specific area of the business. This can lead to some inconsistency when we allow the experience to be experimented on (at Netflix we call this the Frankenstein phase). There is a natural tension between innovation and standardization and the truth is healthy products will swing back and forth between loosening the constraints and innovating and then pulling back in the reigns and standardizing.

Design standardization (read: patterns, guidelines) can be used to bring consistency. But I have often seen design standards teams position themselves at odds to innovation. And on the converse I have seen design innovation teams totally ignore basic patterns that could be employed. Both are wrong. Consistency without informed learnings during phases of innovation is the dead letter. And innovation without the learnings of the past & best practices is just wild speculation.

Engineering teams will struggle with when to invest in the reuse scaffolding and when to simply create an experience that is quick to build and quick to tear down.

The Bottom Line

The key thing to remember is everything must be in service to the user's experience. It's way to easy to forget this and get in an endless cycles of finessing the UI - which I must remind you might not even be the right experience.

My PayPal Update: PayPal Rocks.

The last three months have been a blur. The last blog I posted was right before joining PayPal. So I thought it would be good to give an update on my honest impressions about PayPal.

Here are my take-aways.

#1 PayPal is positioned like no other company to change the way people use money. 
I am really excited to be part of changing something that is so fundamental to the way the world works. I sensed that PayPal was at an inflection point. And now seeing the products we are working on has convinced me we can do this and we welcome the competition. At Netflix we changed the way people view movies. At PayPal we change the way people use money :-) I am totally stoked about our business future.

#2 The wisdom is in the crowds! 
I interviewed over 100 different people in the organization in my first 6-8 weeks. My theory was the "smarts" was already in the organization. My interviews confirmed this. In many ways my job is collecting the intelligence, distilling it, and connecting the right people and information together and ensuring that we remove friction, indecision and instead multiply the ability of our makers to make.

#3. Innovation is blooming all around the organization
I think this surprises colleagues of mine when I tell them that innovation is alive & well at PayPal. At PayPal's quarterly Leader's day they have a great tradition of every new leader (director & above) standing up and telling about where they came from, what's unique about them and what they will be doing. At the November meeting it took us over an hour to get through all the new people. I would estimate that 15-25% of the leaders were new. Either through acquisition or new hire. All this new blood brings in change with it. Couple the sparks from the new blood with the kindling of the wisdom in the crowds (to mix a few metaphors) and you have a roaring fire. I can assure you the PayPal you see on the site today and on merchant sites around the world will not be the same paypal you see in the future.

And the competition from our friends at Google, Square and many others is awesome. Thank God for good competitors. This is energizing and refines a company and makes it lean.

In fact I am in the middle of hiring for my head of UIE Innovation. This is a kick-butt role that partners directly with UED & Product in a lean & mean & collaborative manner to burn through as many ideas as possible and marry technology & innovation.

#4 The Technology Platform is being Re-Invented
Prior technology choices on the front-end have hindered productivity. Using XML/XSLT is a HORRIBLE choice. It is a curse that thankfully is being rooted out. We are migrating all of the products to a simpler architecture that supports true client side development. I am happy to report that my team and the infrastructure team are building strong alliances and we have a shared vision that is about making UI development as nimble as possible. We are building towards a rapid experimentation platform.

#5 My Leadership Team Rocks
Ok, so you might say "well you would say this because some of your leaders will read your blog." Regardless, it is true. I have never been as challenged by my leaders to be bold, make quick decisions, lead, allow no excuses to paralyze us as I have been here at PayPal.

I can't speak for the past at PayPal. And we certainly are not where we need to be yet. But I can assure you that we are unified on empowering an army of change agents. And we have the right vision, the right story that defines where we will be.

We are Hiring
How about it? Want to join me in this grand adventure? I am on the lookout for talented user interface engineers. I need strong developers. Strong computer science skills. JavaScript rock stars. HTML5/CSS3 aficionados. If you have the chops contact me at billwscott over on gmail.

Shared Understanding Resource: Head First HTML5

I am constantly talking about creating a "shared understanding" between design and engineering. And I love it when I find a book or resource that creates more bridges across these two worlds.

Eric Freeman & Elisabeth Robson have done the community a great favor with the addition of Head First HTML5 Programming. If you are a designer or product manager or backend engineer (though as the latter you will have to get past the less serious tone you may be accustomed to) then this book is for you.

As with all of the books in the Head First series they aren't meant for mid to advanced level developers. Where they shine is as a first introduction to a set of technologies. In this case they do an delightful job of introducing the HTML5 family of technologies.

The first thing to understand is what they mean by "HTML5". They aren't restricting the discussion to just HTML5 markup and the technologies that are strictly part of the current HTML5 spec. Instead they take a looser, more popular perspective on what HTML5 is. I actually like this approach. I like it because it is just too confusing to constantly explain to the public what is in and what is out of the spec at any given time. And I really need an easy way to talk about this collection of technologies. So using the term "HTML5" in this sense becomes more expressive. I don't even mind when CSS3 gets lumped into the bucket. I know call me a heretic.

Ok, back to the review...

The book ends up covering a lot more than I expected: markup (of course), JavaScript, DOM manipulation, geo-location (complete with a google maps/geo-location integration), AJAX, Canvas, Video,  web storage and web workers. There is also some discussion of CSS3 and styling and selection.

Overall, I really liked the examples and was pleasantly surprised at how real world they were. Another great touch was the Bullet Points section which summarized each chapter in a single page.

Its really hard to write a book for the complete newbie yet remain technically accurate. The authors have done this and more. Let the shared understanding grow. Highly recommended.

Full Disclosure: I received a free copy for review. However, if I didn't like it I wouldn't have bothered to write anything. The review above would have been the same even if I had bought it.

Excited About My New Role - Sr. Director, Web Development @ PayPal

Elsewhere I have updated my bio to reflect my new job as head of web development for PayPal (which starts on 10/24). The 'elsewheres' being on my twitter profile, facebook profile, blogger profile, linkedin profile, etc. I also tweeted it and updated my status that I had taken this new role. However, those formats are shorter so I thought I would discuss what I am up to and why I am making this change.

As many of you know, I returned to Netflix after a short stint away and have just wrapped up being back a year. Altogether I spent about 4 years at Netflix and had some wonderful experiences and especially wonderful folks that I got to work with (in particular I am partial to those who worked for me).

The first stint at Netflix was a strategic role in which I had the opportunity to define & build the UI engineering organization there as well as guide the architecture and build the talent. I also helped build out the UX design team and especially worked closely with that team. The second stint had some of the same elements as I focused on the ECommerce side and we built out a UI architecture using Mustache (the java version -- thanks Sam Pullara!). And as a team we rewrote the whole code base back to front, internationalized and localized it in just 7-8 months and launched in 43 more countries. In addition, we were able to simplify the device UI code base to handle multiple devices, resolutions and input handling. Even with those good things it was one of the more exhausting experiences I have had in my career. And once the dust settle I quickly realized the role was becoming way too tactical and too focused on one aspect of a single product.

So I popped my head up and decided I would start looking for an opportunity (thinking I would make the move in 6 months or so). But within just a few days this awesome opportunity at PayPal showed up.

Why PayPal?
PayPal continues to be the world leader in online payment. And with the formation of x.commerce the position of PayPal as the payment provider and more importantly the payment identity for online transactions around the globe, I could see the huge upside to the business. Couple this with what is to come in offline payments (POS, mobile, tablet, etc.) and the huge resources of eBay as the parent company and I was sold on PayPal as the company.

Why this role?
While PayPal has all this goodness, they felt strongly that one thing they needed was a strong Web UI leader who could help define a nimble, open source based UI architecture, who could help bring design & engineering together, who could help simplify the process of getting design to life and who could attract top UI talent to the organization. That is a tall order. But as we talked about this role and my background we felt it was the right match. And just 2 weeks after the initial conversations I accepted the role as Sr. Director of Web Development.

Looking back at my career the most successful & enjoyable times for me have been when I am in the role of influencer or change agent. Back at Sabre I was able to found the common web & desktop UI engineering teams as well as the UX design team and influence many of the core products. At Yahoo! as evangelist I was able to influence dozens of their sites and evangelize great engineering & design internally & externally. And as I mentioned, the same for my time at Netflix. So this seems the most logical next step for me.

I will have a lot to learn as I join PayPal. There are many people there I look forward to learning from. I certainly don't have all the answers, but I do have the confidence that I will be able to join forces with other smart people there and at the right time know what is the next best step to take. It's a little like improv. I can tell you a lot of stuff I might try, but until I get there and get a deeper understanding of the needs & the assets I won't know what will make the most sense to try.

It takes a Team
If you work at PayPal, be sure to reach out to me and let me know who you are. I need others like you in order to make the right impact. Or if you don't work there but would like to join me somehow in this opportunity please reach out also. And while I don't know yet what my open positions will be, don't hesitate to reach out in an exploratory manner.

Contact Me
You can always find me at billwscott on all social networks and on gmail. Look forward to talking with as each of you that reach out to me.

Join Me in Boston for User Interface 16!

I am excited to be part of UI Engineering's upcoming User Interface 16 Conference in Boston. The full event is November 7-9th and will be held at the beautiful Renaissance Boston Waterfront Hotel.

I will be giving a full day workshop Monday, November 7, on "Designing Rich Interactive Experiences." You can check out & signup for my workshop here.

Additionally on Tuesday, November 8, I will be presenting a talk on "Designing for Mice & Men" which focuses on experiences across mobile, tablet, TV & Web.

There are a host of other great speakers as well: Kevin Hoffman, Luke Wroblewski, Jared Spool, Hagan, Brandon Schauer, Kim Goodwin, Steve Portigal, Stephanie (Sullivan) Rewis and Greg Rewis.

Join us in Boston for an awesome lineup of topics & speakers.

Looking for a User Interface Engineer for our Account UI team

How about it? Want to work at Netflix? If you have strong user interface engineering skills coupled with solid computer science skills then my latest opening may be just the fit for you.

The ECommerce Team at Netflix is responsible for all member account & profile experiences (including help). It's time to grow the team so I am looking for a talented, passionate engineer who will take on the following responsibilities:

• In concert with design and product management, deliver multiple simultaneous experiences in an A/B test environment
• Develop the full stack from data marshaling in Java, to JSP, Mustache, HTML5, CSS and JavaScript to create these experiences
• Work in close concert with backend web development team, be able to understand the impact on the whole product, and suggest and plan the best solution with backend to UI in mind
• Take full ownership of a feature set from first discussion to bringing it live on the site
• Turn requirements into simple, elegant, optimal solutions that balance the needs of the health of the technology stack but always guided by our business needs

If you are interested or know someone interested, please email at bscott -- over at netflix dot com.

Full description here (or apply here):

Senior User Interface Engineer - ECommerce

Check out the new Netflix Tech Blog

Lots of interesting technical stuff happening to get movies to your living room, mobile devices & browser. You can read about the technical side at techblog.netflix.com.

New - Social Systems Engineering Team at Netflix

Michael Hart is now leading a new Social Systems Engineering Team here at Netflix. He has a couple of immediate openings. Here is a partial from the job description:

Netflix is the leading online movie and TV service, reaching almost 17 million households in the US and Canada and growing over 50% in the last year. Many of the other fastest growing companies today have achieved that growth in part by leveraging Facebook's social graph. As a founding member of the new Social Systems engineering team at Netflix, you'll be challenged with helping us leverage the social graph to propel Netflix's growth even higher.

I am really excited to see what Michael and his team will accomplish with this new dimension of the Netflix experience. Wouldn't it be a blast to be a part of this team? If you are interested apply for the job here.

Back at Netflix and Hiring

I am back at Netflix!

I am hiring (naturally). I am specifically looking for some talented user interface engineers to join my team. My team builds the experience for acquiring new members. We are at a critical phase as we expand internationally while supporting a wide range of devices. You can check out the job posting here.

I can't think of a better recommendation for Netflix than the fact that I have returned :-D

Why would I return? First a little about why I left.

In my previous position at Netflix the team had gotten large (15+) and was on a growth path to be 25 or 30. I no longer could be involved in the details as my group spanned every part of the Netflix business. It was a fantastic position -- really a dream job. But at the end of the day I needed to be more a part of the solution.

So I left Netflix and became the VP of Engineering & UX at Meebo. Meebo is really a stellar place. But after just a couple of months I realized I had moved in the wrong direction. And it became clear to me that all of the positions opening to me where at a level that mostly dealt with the organizational challenges with some limited high level strategy. So while Meebo was really a great place to work I knew that I had to figure out what level I wanted to work at.

After that I started consulting. During that phase I learned a lot about myself and how I want to spend my time. Consulting was especially rewarding as I had some amazing clients (PayPal, Adobe, Rypple and BagCheck to name a few). I got to do product strategy consulting, UX design (lots of wireframing) and JavaScript development. The most rewarding part was being hands on solving problems. And of course working with Theresa Neil (my co-author) was a blast.

During that time I was presented with a lot of really great opportunities by companies I respect deeply. After I started considering full time employment again I realized that I was happiest at Netflix. And coincidentally I had been giving recommendations to Netflix on people that I could recommend for a new role there. Then it dawned on me, why not offer myself for that role? And that is what I did.

My new role is much more focused than my previous role. I am the Director of ECommerce UI Engineering. Instead of leading all of the user interface engineers at Netflix, I am leading a smaller (but growing team) that is focused on solving specific problems on the marketing/customer acquisition/account side of the house. The cool thing is the solutions our team fields directly impact the growth of Netflix & the dollars that come in the door. Plus I am able to get much more involved in the day to day work of the product.

The bottom line: My recommendation couldn't be stronger for coming to Netflix. I believed in it so much that I decided to return. It's an amazing brand and we are poised for more amazing growth.

So want to join me? Check out the job description. Is that you or anyone you know? If so don't hesitate to apply or ping me at bscott _at_ netflix _dot_ com.

Snap, Annotate & Share Workflow Tools

Commonly I just want to grab a screenshot or wireframe and annotate it and share it with others for commenting on.

If you are snapping, annotating & sharing something that has a public URL then BounceApp by the Zurb guys is pretty cool. Notable App takes it further, but there are no free plans at the moment and it is limited to snapshots of public URLs. But for that space it is the quickest snap, annotate & share tool I have seen.

But what I have been using of late is two tools to accomplish flow. Little Snapper and Tiny Grab. I like Little Snapper because I don't mess with filenames. And it has a simple interface like iPhoto. And I like TinyGrab because you can drag any image to it and it uploads it to the cloud and creates a tiny url link on your clipboard.

Here is my workflow.

1. Snap an area with little snapper. No filenames needed. Image displays in Little Snapper (which looks a lot like iPhoto).
2. In Little Snapper I edit the snapshot.
3. I use the annotation tools to mark up the snapshot.
4. Then I drag the annotated image to either the TinyGrab app in the dock or the TinyGrab tool in the upper right area of the system menu.
   

TinyGrab then uploads it to their servers and creates a tiny URL. It copies that URL to my clipboard.

Then all I have to do is just paste that URL into email, etc.

Then to take it one more step. In gmail, go to Settings: Lab and turn on Insert Images. This provides an image button in the email editor. You can then pick from URL and paste in the URL that was on the clipboard.

This allows me to quickly grab a snapshot, annotate it and share it without messing with file names, etc. Here is a quick video of the annotate & share part of the workflow:



You can also use HipChat or CampFire in this process if you need to also do a lot of collaboration back and forth on an annotated snapshot.

I am curious. What do you use to snap, annotate & share (and collaborate)?

Update. @balsamiq reminded me of Skitch. I hadn't tried Skitch in a couple of years. Looks very promising. All in one tool. I didn't like the way it stored your snaps (as history). Also I wish it just copied a short URL to my clipboard like Tiny Grab. Don't want to go to the website and pick one of 6 different ways to share just for the most common case.

Togetherville Hiring Interaction Designer

I love the folks at Togetherville. They are the "facebook for kids". Mandeep Dhillon and the team are passionate about a safe, fun environment for kids to engage with one another.

Here's a great opportunity! How about joining their team as an interaction designer? If you want to be part of changing the social landscape for the web, here is a place you can do it (and have fun in the process).

Don't believe me? Earlier in the year when Togetherville needed to rethink a lot of the social interaction I suggested Tangible-UX as a great partner. They got involved and it has been one of their favorite projects.

Check out the posting over on the Togetherville blog.

Zurb's 110 Interesting Moments for BounceApp.com

In our book and often in our talks we discuss a technique for thinking through and documenting detailed interactions in a user experience. Just arrange the interesting moments in a grid. List the "actors" (user interface elements) vertically and the events horizontally. The cells in the grid become the interesting moments.

With the classic example from the of drag and drop there are at least 96 interesting moments (6 actors X 16 events = 96 interesting moments).



About a month back I gave a talk at Zurb, a northern California design firm, in which I discussed this technique. On Friday I was pleasantly surprised to see they had already taken the idea and used it in a new product they announced last week -- BounceApp -- which was featured on TechCrunch.

Check out their article on 110 Interactions for Editing Annotations on Bounceapp.com.

Nice application of the grid.

Workshop in HD Video: Designing Web Interfaces

A couple of months back Theresa Neil & I filmed a combined workshop on the material from Designing Web Interfaces plus Theresa's material on application patterns, screen patterns and ui controls.

This is a beautifully recorded workshop by O'Reilly Media filmed at the Images in Motion Studio in Sonoma. The workshop is over 4 hours long and broken down into 11 smaller, digestible segments. A full camera crew, HD video and lots of great post production conspire to create a video series I am proud of.

Here is a sample of the material posted on youtube.



To appreciate in all of its HD glory visit our video site on O'Reilly Media. The full 4 hours is only $79. You can get it and show it to your whole team.

Inline Form Validation

At the last Web App Masters Tour Luke Wroblewski gave a great talk on Forms in Action (quick plug -- you can hear him again in Minneapolis, Philadelphia or Seattle as the tour continues in those cities as well as myself and others!)
Luke brought out that on the good side more forms have added interactivity to form field validation. Error prevention is an important design principle. An ounce of error prevention is worth a pound of error handling design and code.

But on the bad side some forms are actually hurting the experience by either being too aggressive or trying to be too clever in input assistance.

I stumbled across two examples to add to Luke's collection. Both come from a very useful tool Its Deductible. I highly recommend the tool for what it does as it encourages me to donate more items and allows me to accurately take them off my taxes each year. Big fan. But two not so good experiences in their forms.

Not Clearing Error Message

Its Deductible Error Message on Login Screen

I entered the wrong account name and got a message bubble warning me about it. Good things about it:

• The bubble is clearly worded.
• Red color got my attention.
• Is nicely placed

However, the screenshot above is after I started typing a new login name. Even after I tabbed into the password field the error message stayed up. What's bad about this? I got immediate feedback that something went wrong. But got no credit for trying to fix it. Once I started typing the new login name the bubble should have disappeared.

Draconian Date Input Handling

How many times have I entered a date in a web form? So I just need to know are you expecting month/day/year format and whether I should type the slashes or not. However watch the video and see how poorly I entered the date!

Its Deductible Date Input Handling
Don't even think about entering slashes or not giving 2 digits for the month, 2 digits for the day and 4 for the year. Anything except typing 02092009 will fail.

Here is what went wrong.

• You have to enter 2 digits for the month, 2 digits for the day and four digits for the year. Why? Next bullet point...
• You can't enter 'slashes'. If you do you get two slashes! And when you submit it won't like that.

It is obvious there was some effort put into assisting me in entering a date correctly. But unfortunately it took me about 45 seconds to figure out their algorithm and enter the date in exactly the way they wanted me too.

BTW, You can use SCOTT for a 10% discount on the talks in Minneapolis.

Designing with Lenses - Slides - CHIFOO 4/7/2010

Had a great time last night presenting at CHIFOO in Portland. Lovely facility at the White Stag Block, University of Oregon. Thanks Leo Frishberg for the wonderful hospitality. This was the first time I have given a talk on design lenses so was curious how it would be received. I was really happy with the positive feedback.

Here are the slides from last night.

Designing With Lenses - CHIFOO

View more presentations from Bill Scott.

The biggest takeaways for me were:

• The idea of lenses is a great way to mentally frame design principles
• There is a strong interest in us curating these principles
• There is still some tinkering on how broad the lenses should be (lumping vs. splitting). The analogy of a camera lens was used by Ann Marcus. Narrow the lens and get the details but lose more of the context. Widen and you get less detail but a broader application.
• That lenses can serve (as patterns do) to inform not just designers but all involved in product design as a common vocabulary and repository for examples.

Let me know what you think.

You can follow the lens project on the @uxlenses twitter feed. Or visit the designingwithlenses.com site directly.

Speaking at CHIFOO on Design Lenses

Looking forward to a quick jaunt up to Portland tomorrow and back home again Thursday morning. This is my week between Netflix and Meebo and it has actually shaped up to be quite busy. But I am excited to be giving a new talk on Lenses.

Since the CHIFOO site seems to be down at the moment, here are the details of the talk:

Designing with Lenses: Lessons from Other Design Crafts.

In any field of design, designers can enhance their craft by studying the work of others. Through the careful exercise of breaking down real-world solutions into their underlying principles and patterns, previous lessons can be applied to new sets of problems we encounter. Designing for web interfaces is no different. By necessity we are constantly searching for inspiration and practical guidance in solving the problems we face as designers each day. A powerful approach is to capture these lessons into "design lenses". A design lens allows you to view the user experience through the eyes of a single design principle. Lenses were originally created for game design but are just as powerful for user experience design.

In this talk, I will introduce the idea of design lenses and discuss several lens inspired from fields of study as diverse as theater, magic, game design, storytelling, Shaker furniture, motion graphics, and comics for inspiration in designing rich, interactive interfaces. By teasing out some of the key takeaways from each of these disciplines, a fresh light can be shed on our own corner of the design universe.

Join us at 7pm at the University of Oregon's White Stag Block.