Back in 1987, Apple (under the direction of John Sculley, not Steve Jobs), released a video of what Apple products could be like in the future. Called the Knowledge Navigator, it showed a sci-fi mythical tablet computer from 23 years in the future (yup, 2010) that the user talks with to get things done.

Fast forward 24 years and Apple releases Siri with the new iPhone 4S. Siri is an assistant that takes voice commands and acts on them. If you haven’t seen Siri, here’s a demo.

Now, as far as I know, Siri is only available on the iPhone 4S. However, that’s likely temporary, as I don’t believe there’s anything that prevents it from showing up on other platforms, like the iPad.

And once it shows up on the iPad, Apple will have fulfilled it’s 1987 quest. All the components of the original Knowledge Navigator are now available and for less than $500.

In ’87 — when we all used big, boxy CRTs on bulky, loud, slow desktop processors without any notion of communications beyond 9,600 baud (14.4 came in 1991) — there was no way you could have a small, tablet computer to do all the things in that video. Knowledge Navigator was complete science fiction to everyone at that point. Computers couldn’t speak. You couldn’t imagine face-to-face video conferencing across the planet, let alone collaborative workspaces. None of that had been invented yet, except as sci fi.

Yet, if we look close, it’s the path Apple has been on for 24 years. We’ve seen the baby steps. With the introduction of the Mac Book, then the iPhone, followed by the iPad, we got our table. The interwebs provided the connectivity, where Apple focused on its Airport wireless products to get the components tiny. Innovations like built-in cameras and Facetime made the video conferencing a reality.

And now Siri completes the journey. Siri isn’t quite the bow-tied dude who can order a cake for your mother’s birthday party, but it’s damn close. (And I’m not convinced we need avatars to believe the computer is speaking. I think Second-Life ruined avatars for everyone, except those who enjoy online virtual sex.)

In 1987, when Apple first released the video, they received a fax (!) with a purchase order for the Knowledge Navigator. Now they can finally fill the order.

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.

Yes, you read that right. A blind person driving a car. Not an autonomous car that drives a blind person around, but a car where the blind driver is getting feedback and making real driving decisions in real time.

They’ve created an amazing set of devices to make this work. One that impressed me the most was the AirPix, a tablet-like device that uses small holes blowing air to substitute for visual picture. By waiving your hand over the air bursts, the user can get a strong sense of the terrain. It’s Google Maps through air. Brilliant.

Virginia Tech's AirPix Kinestetic Display

Watch the video. You’ll be blown away.

Nathan Curtis of EightShapes uses HTML prototypes in his team’s design process. Using HTML, they test functionality and interactions in ways that are impossible while using static PDFs. During his virtual seminar, From PDFs to HTML Prototypes, Nathan discusses how his team uses dynamic documentation and design thinking. This has improved communication among the team and enhanced their process. Nathan wasn’t able to answer all the questions during the seminar. He joins Adam Churchill to address those remaining for this podcast.

Here’s an excerpt from the podcast.

“…There’s clearly start-up costs for creating an HTML prototype that are heavier than creating a wireframe PDF document. Honestly, we’ve been working with InDesign for years. As a company, we’ve got out system down for how we churn out good ideas quickly, via wireframe PDFs. And so for us to open up InDesign, open up a template, open a couple libraries, through all those things onto a screen, produce a PDF, you know, you could have a wireframe in five minutes. From just the start of a project.

But with an HTML prototype, you’ve got to set up all your folders. You’ve got to copy all of your libraries. And then you have to start marking up the semantics of your HTML to describe what the structure of your idea is. And then start layering on that CSS. And then start getting into some of the JavaScript to make those interactions happen. Suddenly, that’s not a five minute process. There’s certainly a start-up cost such that it’s almost like you’re a diesel engine.

You’re going to get out of that starting gate a little bit slower. But I’ve also sensed that, once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, “Well, you want to make the header twice as large.” In HTML we just change the height from 50 pixels to 100 pixels.

But in wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too. In wireframe PDFs. So my instinct is that, yes, there is definitely a start-up cost that’s greater for HTML wireframing. But the overall cost once you start getting your engine running, and you start gaining the momentum of where the design’s going, it actually nets out…”

Listen to the podcast to hear Nathan answer these additional questions:

• Are your prototypes HTML, Flash or image maps?
• How can prototypes be successful with distributed teams?
• Do you start your designs with sketches?
• Have you ever tried to merge HTML and wireframes?
• If a designer can produce production-level code, are they more of a developer at that point?
• Do you produce production-level code in your prototypes?

Do you have experience integrating HTML into prototyping? Share your thoughts or experiences with us in our comments section.

Recorded: May, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ]

Pam Rodriguez and Luke Wroblewski did a nice job of posting their notes. Thanks guys!

• Steve Portigal on Design Fieldwork: Uncovering Innovation from the Outside In – Pam’s notes, Luke’s notes.
• Kate Brigham on PatientsLikeMe: Adventures with Data Visualizations – Pam’s Notes, Luke’s Notes.
• Luke Wroblewski on Designing Mobile Web Experiences – Pam’s Notes.
• Mike Lee on AARP: Designing a Strategy for Organizational Transformations – Pam’s Notes, Luke’s Notes.
• My presentation on The Essential Principles behind Great Design Principles – Pam’s Notes.

As you can see from the #UIEWAMT Twitter stream, everybody had a great time and we all learned a ton.

There’s one more stop on the 2011 tour – Minneapolis on June 27-28. Use the promo code BLOG and get $100 off the registration price.

See you there!

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Minneapolis

Subscribe to our podcast via

Prototyping is an iterative process. You generate design concepts. You test them. You discover what works, what needs improving, and opportunities for new ideas. Then repeat. Prototyping your design will get your team and your stakeholders to talk about it. They’ll use it, touch it, walk through it at a point in time when you can make changes inexpensively.

Last year, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, joined us for a UIE Virtual Seminar: A Practitioner’s Guide to Prototyping. In it, Todd explores his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, regardless of the method and tool your team uses. Also, Todd’s principles are sure to test and improve your design whether you’re a seasoned prototyper or just getting your feet wet.

Todd is a Pied Piper in the user experience design world. We’ve seen it! At conferences, everyone wants to catch up with him to see what he’s doing and what he’s thinking about. He’s loaded with charisma! Oh, and he’s a pretty good designer, too. He thinks about this technique a lot, so we’re thrilled to have Todd’s UIE Virtual Seminar as part of our UIE User Experience Training Library.

Here’s an excerpt from the podcast.

“…For us, we actually use the prototypes as our specification, for the most part. Now, there are some things that you’re not going to see or that maybe won’t be self-evident in the prototypes. Some of the business rules or back-end functionality may not really be clear in the prototype.

What we found, and this is actually one of the reasons why we turned to prototyping and away from an older, traditional method of wire frames with written specification documents. What we found is that, since the prototype, basically, is show and tell and allows you to see the story as well as tell the story and actually play around with the systems, it’s much more tangible. When we do prototyping, we find that actually, any specifications that have to be written are dramatically reduced.

So, for example, in my book there is a case study from a gentleman over in the UK and their old, traditional system was: do some wire frames, write a 200-page specification document and deliver it out to the development team. And they shifted over to using more of a prototyping model. And for similar systems that they used to have to write a 200-page spec document, they found themselves delivering the designs, with specifications, about three times as fast and that the specifications went down to 20 pages instead of 200.

And so they’re essentially using the prototype as the bulk of the specification and then writing some supplemental documentation to describe things that aren’t self-evident, like back-end business rules and maybe some technology-type stuff. And we’ve done a very similar approach.

So, a lot of times, what we’ll do is prototype out maybe a core flow, plus maybe some error sessions and maybe some success screens and that type of a thing. But, we won’t typically prototype out every single scenario. We’ll kind of do the 80-20 rule. So, here’s 80 percent of it prototyped out. You can pretty much see how it works. And then any additional, supplemental information that may not be self-evident in the prototype, we’ll either write some documentation, or in a lot of cases actually, our clients just take the prototype and then their internal team basically writes that spec…”

If you thought that was interesting, you’ll also hear Todd address these questions:

• If you’re prototyping only some of the functionality, how do you talk about the rest of the functionality that isn’t in the prototype such that the team knows how to fill in the gaps?
• How are you able to do usability testing when the prototypes are not refined, or they’re missing pieces?
• We often talk about how prototyping lets you reduce risks, but does it give you an opportunity to actually take risks?
• Do the prototypes have to be made with the same technology that you’re going to use in your production system, or are there actually advantages to doing them in something completely different?

If you have any questions or thoughts on prototyping, please feel free to share them in the comments section below.

A little over 3 years ago, we started producing 90 minute online seminars. We call them the UIE Virtual Seminars (or webinars). These seminars give you the chance to hear the latest perspectives in the world of design from the field’s premiere experts.

During the live virtual seminars, we receive many questions. It’s rare that we have enough time to tackle these questions. So to address the unanswered questions from the seminar, we record Q&A podcasts with the presenters.

These podcasts are a wealth of information. It’s like a little secret only a few know about. But we want the world to hear the podcasts. And the beauty of these podcasts is that you don’t need to attend the virtual seminar to follow them. So we thought we’d occasionally feature them in our newsletter.

In today’s UIEtips, we focus on two podcasts. One is with Beth Loring on Effective Moderating for Usability Testing. The other is with Fred Beecher on The Whys, Whats, and Hows of Prototyping. Like all our podcasts, they’re available on our web site and on iTunes (and they are free).

Enjoy these podcasts and let us know what you think below.

But when it comes to prototyping tools and methods to use, many of us are unsure what to do.

There’s lots of tools to choose from. It’s often a mystery as to which one will work best for you and what’s best to use based on your situation. That’s where Todd Zaki Warfel comes in (cue the Superman music).

Todd is a thought leader in the user experience design world, as well as the author of the acclaimed book, Prototyping: A Practitioner’s Guide. Thanks to Todd and his publisher Rosenfeld Media, today’s UIETips article is a reprint of chapter 5, Picking the Right Tool, from his book.

In this article, Todd explores what tools people are using and  what kinds of prototypes they make. I’m sure you’ll find this book excerpt of great interest.

Read the article, Prototyping: Picking the Right Tool.

On March 31, 2010, Todd is presenting the next UIE Virtual Seminar on his Eight Guiding Principles for prototyping. Whether you’re just starting with prototyping, or you’re a seasoned veteran, I’m sure you’ll get a lot out of this webinar. And when you register, thanks to Todd and Lou you’ll be sent a pdf copy of Todd’s entire book. Learn more about it Todd’s seminar, A Practitioner’s Guide to Prototyping.

What tools do you use for prototyping? We’d love to hear your experiences below.

Prototyping is an iterative process. You discover what works, what needs improving, and opportunities for new ideas. The earlier you learn about a design change, the easier it is to implement, and the less costly that change will be. Prototyping allows your team to explore ideas before you invest in them.

In this seminar, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, will explore his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, and will improve your design process whether you’re a seasoned prototyper or just getting your feet wet.

Register before March 24 to get your free personal PDF copy of Todd’s book, Prototyping, A Practitioners Guide, and lifetime access to Fred Beecher’s seminar, The Whys, Whats, and Hows of Prototyping.

Tell us how prototyping fits into your design process. Do you have an example where something in the design was caught early and saved a bunch of money? Or one where something was identified late and cost money? What is your experience with prototyping, and how do you sell it to the rest of the team? Or your stakeholders? Share your thoughts and experiences below. We’d love to hear them!

Subscribe to our podcast via

We turn to Hagan Rivers for insight on designing challenging web applications year-after-year because she just keeps coming up with better and better ideas. When we were talking with her late last year, she mentioned she had another innovation in her web app design workflow, which sounded a bit strange at first blush: she designs the navigation as a separate application.

“How is that even possible?” we asked. Navigation is so central to the experience of the web that it frankly sounded like crazy talk. But we knew to hear Hagan out. Now we wonder how people do it any other way.

Recently, Jared sat down to talk with Hagan to discuss her somewhat radical notion, which she plans to discuss in detail at our upcoming Web App Masters Tour. Jared began by asking about the genesis of her application development strategy.

“I would be working on relatively complicated applications, and I found a lot of our design discussions would get really mired in the navigation. And the problem was, because we hadn’t fully worked out what was on each screen, we were kind of co-designing two things in parallel: how to get to the screens and what would be on the screens. And the two kind of affect one another, and so it was really hard to design these two similar objects at the same time.

And so what I started doing was just leaving this big, gray block at the top of the screen that says, “Navigation goes here. Let’s focus on the screen.” And once I did that, I found it got a lot easier to concentrate on what goes on each and every screen”

Of course, the primary application and the navigation are never truly separate apps. They’re always joined at the hip.

“They are obviously interweaved. […]you have to always design the navigation system with the rest of the screens deeply in mind, and you’re going to be inserting little bits and pieces here and there. But it’s still something you can design as its own freestanding thing.”

Hagan brought up the idea of momentum in design, where inspiration doesn’t just appear on demand, but when the ideas do start flowing you don’t want to hamper them. Navigation is often a decelerator of momentum. Leaving navigation until later in the process doesn’t just ease addressing the primary tasks of the application. There are other advantages to having many of the app’s screens complete, prior to having a navigation system. For example, during your usability testing of prototypes,

“Because you don’t have the navigation system in front of [your users], [they're] not being led by it. You’ve just got the raw screens. You know, sooner or later, to make a purchase order you have to collect certain information. No matter how the user got there, you know you have to collect. It’s a bunch of forms to fill in.

In what way does the user think about that? How do they get to those screens? What are they prepared with when they arrive there? What do they know? What don’t they know? Do they need to quit halfway through sometimes because they have to go look things up? All of those things will tell you what the navigation system needs to be.”

We feel that’s an powerful way to address the needs of your users with the navigation, gaining even more value from your research and testing efforts.

These are just a few tidbits from the interview. Be sure to listen to the interview to gain even more web app wisdom.

Obviously, we’re really excited that Hagan will be discussing this topic in depth at our Web App Masters Tour. Her “Escaping Navigation Hell” will be featured at all four stops on the tour, San Diego, Minneapolis, Philadelphia, and Seattle. You won’t want to miss it.

When do you address navigation when building complex web applications? Would Hagan’s idea help you in your situation? Let’s discuss in the comments!

Subscribe to our podcast via

Our audience clearly embraced Fred Beecher’s recent Virtual Seminar on prototyping, The Whys, Whats and Hows of Prototyping, because we were nearly buried under all the thoughtful questions we received. It’s clear people are looking for more effective and efficient ways of working through their design ideas. Our Adam Churchill got together with Fred after the seminar to go through the pile and deliver more answers for you.

During the podcast, Adam asked Fred to explore these questions, and more:

• Can you tell us how design differs from prototyping, and where
  elements like visual design and wireframing fit in?
• Does prototyping require organizational change? Anything you
  recommend when working with others in the organization that aren’t
  members of the design team?
• What are the best methods and tools for online testing?
• What recommendations do you have for collaboration when working with
  people in different locations, and possibly at different skill levels?
• Which prototyping tools do you recommend, and how do they differ, from low fidelity to high fidelity?

I know you’re going to enjoy this episode because I couldn’t get through editing the audio without pausing to look up some of the resources Fred suggests.

Do you still have prototyping questions? Ask them in the comments below.

One of Brian’s comments jumped out at me:

We took our knowledge and created, in a warehouse in San Francisco, an entire lobby made out of white foam core. We built it to scale. Then we brought in consumers to get feedback on the overall experience of the space. We didn’t want feedback on color choices, like blue versus red. Instead we wanted feedback on using welcome pedestals, rather than a clunky front desk. Our associates circle around the space rather than standing in one place, and we wanted customer feedback on that. And the foam core allowed for rapid prototyping. After we got user feedback, we could rip it apart and build it again to get the concept right.

It’s one thing to talk about the abstract notion of protoyping a web page or a dialog box. But to prototype an entire lobby experience? That’s pretty cool.

Not too different than what Apple did with the Apple Store. Who said an old-tyme business like Marriott can’t play the same game as the cool kids. See? There’s hope for us all!

Read the entire interview.

(Hat tip: Dana Chisnell)