Victor Lombardi of Smart Experience and I begin DAKISSA, a podcast that looks at innovations in interface design. You can view the podcast on Konigi or at dakissa.blip.tv where you can subscribe via your RSS reader or iTunes.

MTV Israel using Tvinci video player.

Missing Christina's Widgetopia, I've decided to dump my screenshots of examples of user interface and interaction into a flickr group rather than keeping in the vacuum of my own experience. So now you can view screenshots I'm grabbing at the Design Pattern flickr group and feel free to add your own. The example below is from Daylife.

Design patterns are generally repeatable solutions to a commonly occurring problems.

This group was created to post examples of web design solutions seen in the wild to help people compare different solutions, and to find existing and emerging patterns to design problems.

Tagging consistency will certainly help make this useful, but it is likely that people will use different tags to describe problems, e.g. will you use "sign in", "log in", or "login" to tag a sign in interface? Consistency will allow you do things like search for stuff like Design Patterns: clustering.

I spent a little time today watching Bill Buxton's Nov. 2006 Boston CHI presentation on sketching. Buxton talks about the distinctions between sketching and prototyping, in orderto discuss why sketches are valuable and need to be emphasized during the design process.

I was intrigued by what he calls the right process for ideation. When speaking about the sketching process for industrial designers, he says that designers need to come to the review table with 5 sketches, of which she cannot have decided in favor of any one. This practice contrasts with the method of doing 1 design and iterating over it with usability improvements, what he calls a spiral process in a single direction. The purpose of sketching is to find the right design, and the purpose of prototyping is to get the design right.

This doesn't say that usability testing and prototyping is wrong, but the approach to getting the right design is a process of sketching and critiquing, and it's an essential part of the process of generating ideas and is a bridge between ethnography and prototyping. By bringing out 5 sketches, you work on multiple directions in parallel until you find the direction that is best suited to the problem -- the one that is "right."

I've always used sketching to find the right design, but rarely showed the sketches, tending to simply discard the ideas that don't work and using finished wireframes and storyboards created in Visio or OmniGraffle for the team critique. But that goes against the purposes of exploring ideas as a team, I suppose, if the team never gets to see them. After hearing this presentation, I wonder what is being missed by not sharing more of the sketches. Often times, the ideas are generated in discussion while I sketch at a meeting or conference call and then I flesh the sketches out on my own, exploring different alternatives. But my team usually only sees what I deliver in the document created in the drawing tool.

This is one of the downsides of working in different locales and relying heaviliy on technology. I've become accustomed to deciding on and refining designs and quickly putting them in a drawing program, so the decision making process of sketching never gets seen. I've talked to a colleague about how to get my sketches to the group, and am considering the process of scanning and distributing sketches as PDFs, but this adds so much time and effort to the process.

When we talked about doing this, I though the value of scanning drawings would be for me to save time by skipping the wireframing part of the process when I could so we could work with agile methods. But I'm beginning to see that the problem is not the effort to do the wireframes. I think I'll always do them as part of the process. The problem is that the sketches aren't being seen enough and that people need to see the low fidelity creative part of the process in order to push the design direction in as many ways as possible and drive innovation a bit more. This, as I'm sure other designers know, is hard to do with finished looking documents.

I stumbled across the Pen-It device, which takes sketches and transfers them via Bluetooth to your Mac as vector drawings. I'm going see how I can make pencil sketches a more visible part of the design process with the larger team again. In any case, I expect to try to tweak my process a little to make more of the idea creation visible, so that sketches and annotations are seen more in their rough state, rather than editing out those details in the documents I deliver.

A few months ago a few colleagues asked me if I could turn a design document into a low-fi clickable prototype to demonstrate interaction design on an application we were developing. I also talked to an IA recently who had the same need to demonstrate interaction, but lamented over the tools at our disposal.

I've used Visio and Axure Pro in the past to do quick and dirty demos of interaction. With Visio, it's been easy to link sheets together. But I've been spending my time primarily in OmniGraffle Pro lately, so I wanted to demonstrate to the other Mac-using IA's and IxD's out there how you can do the same thing.

With this simple process you can create working prototypes with exported PDFs or HTML with clickable images/image maps. The next step to get this to be a richer tool would be to have working form fields in the prototype, but not sure yet how you would do that natively. The hack would be to absolutely position divs for form elements over the OG image.

Luke Wrobleski has written a great article discussing the difference between perceived and actual simplicity and what it means to designers. Simplicity is more than the perception of spareness or bareness of design. In actuality, simplicity probably has more to do with ease of use than with appearance, and achieving simplicity can be a complex task.

Wrobleski illustrates the Pareto principle applied to expert user features on sites like eBay and You Tube. On those sites 80% of activity comes from perhaps 20% of the users. These are often the expert users, who want to do more than simply find products or watch an occassional movie. Those users are the one's that add the most value to the system, so features that enable those users to be empowered need to be addressed. So how does that user type's need impact simplicity of the experience for others?

Tufte speaks of information density, how much screen real estate is devoted to useful information, as a measure of an information object's effectiveness at communicating messages. "Usefulness" is the operative word there. Data dense interfaces don't necessarily lead to ease of use. The point is that if the ratio of useful data to chart junk is good, the object has better information density. It is the usefulness of the interface for helping users get things done is what leads to actual simplicity.

Achieving a simple experience when the spectrum of needs of users are varied is complicated, but possible. He points out that some interfaces have tried to balance those needs, e.g. Microsoft Office's partially hidden menus. I don't know many people that would argue that the MS menu design has lead to a simplified experience.

The implication is that you probably want to find a way to make expert-enabling features available because they probably serve that 80% of value to your product or service. Making those features available is what makes the experience simple for those users. But how to do it? One suggestion in the comments is practical and probably generizable for most web sites. Michael Zuschlag writes:

I think the answer is that, while experts do use expert features, even they rarely use them. Most of the time expert features are a distraction even for experts. That doesn’t necessarily mean designers must eliminate or hide expert features, but it does suggest that designs should be proportional, with commonly used features easy to see and select, and rarely used expert features being less obtrusive, even if less convenient.

Sound simple enough? The proof, I suppose, is when the executed design is deemed useful to the types of users it serves.

As you probably know, Google began it's Book Search project a while ago, scanning the collections of prominent academic libraries in the US and England. We're now beginning to see the most practical uses of Google Book Search. Google began offering free PDF downloads of books in the public domain -- books that were published before 1923 or whose copyright has expired. See for example this copy of John Stuart Mill's On Liberty scanned from the Library at Stanford.

I had to read this book in grad school. Students will be able to save quite a few dollars I suppose because of this, but think of the money they'll spend printing these things out. Someone's got to come up with a usable ebook reader. I'm certainly not scrolling through a book like this on my PPC PDA, even in landscape mode. When's the affordable, easy to use E Ink based product going to hit so I can read a novel like Jean Luc Picard in his "Ready Room"?

In any case, this is a great development. If we do see a usable method for toting these ebooks around, I can't see why Google couldn't begin selling ebooks like Amazon does. But maybe that's years away from being a reality. The good thing is the dead tree data is getting digitized in some standardized and accessible fashion.

Amazon's Online Reader is really nice, by the way. Here's a demo using a Beatles book.

The folks at Humanized had a nice idea that seems a perfect use of AJAX. They proposed that a user interface could get rid of the page chunking links you see at the bottom of search results lists and instead, dynamically add more entries to the bottom of the page as the window is scrolled. To prove the concept, they've implemented this idea in a news feed aggregator. They call this automatic expansion of the list of entries "Humanized History".

Scrolling in GoogleReader is essentially the same. There are two panels, one on the left to scroll the entries titles and one on the right for viewing the individual entry selected on the right. Humanized Reader does it all in a more typical blog-format, with a simple reverse chron list. Google Reader is more like a conventional application UI, but has the same page-less model.

The concept is very powerful. Using technology appropriately, let the interface get out of the way when possible so that people get right to using the content. Humanized does this with a design that is simpler and more elegant than the Google Reader. They say the point is to let you spend more time reading and less time thinking about navigation. Put another way, they say, "Don't force the user to ask for more content: just give it to them." Sounds like something Steve Krug would agree with. I like it.

A few new interesting labs projects were announced at a Google Press Day. What caught my eye:

Google Notebook (to be released at http://google.com/notebook) uses the familiar Gmail UI to give you an easy to use text editor application. Seems to take cues from the wiki-hybrid text app http://www.writeboard.com/. It seems to integrate with Search somehow so you can take notes while sifting through results. Screenshots of the app are available via EricaJoy's photos at flickr.

Google Trends provides simple graphing of search and news reference volume around search terms. The UI is similar to the Finance timeline, without the slider controls. See for example this search for ajax or even more interesting is this search on several different content management systems.

Google Gadgets are little apps that can be floated on your desktop similar to Konfabulator's widgets or the Mac's Dashboard. Gadgets will be most interesting when used for showing stuff like changing data in stock quotes or weather, but I presume will be created for nearly any type of information Google retrieves.