Archives

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here’s an extract:

So, usability. That’s really at the heart of good design, and I’m going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That’s it! That’s the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It’s a truism that "making things easy is hard." Spolsky’s Principle (First Draft) strikes me as being simultaneously concise,  self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme–documentable–precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky’s Second Draft. Hopefully, he’ll have both feet on the ground next time.

Share/Bookmark

Daniel Zeiss has put together the and excellent review of Ajax frameworks for ASP.NET. He narrowed down his selection of frameworks as follows

First, let me explain why only these 11 Frameworks are included although there is a lot more AJAX stuff for ASP.NET out there. All the frameworks listed here have one unique AJAX feature: They allow updating page content without programming AJAX directly – i call it indirect AJAX programming – a comparable concept is called Hijax. To make it concrete: Direct AJAX programming would mean dealing with client scripts, DHTML, method proxies, client side rendering and so on… Another important property the framework must have is the ability to support non-AJAX controls and enhance them with AJAX features. Therefore, frameworks that supply only controls with built in AJAX-features (Buttons, Trees, Grids, Lists and so on…) are not included in the comparison.

He has done extensive work in road testing and comparing. Well worth a look.

Share/Bookmark

As I leafed through my ever growing stack of tech magazines
yesterday, a column in eWeek by Peter Coffee, entitled Thoughtful gestures
– don’t make complexity elegant; make it disappear caught my eye. 

Mr. Coffee was writing about a patent
application from Apple for processing multipoint gestures on a touch input
device. The language of patent applications is notoriously dense and jargon laden, so in laymans terms, this is about making it easier to interpret what a user wants when they touch a screen or touch pad at multiple points at the same time.  Some simple examples of multipoint gestures include squeezing, stretching or twisting motions while touching a screen with your finger tips.

Mr. Coffee’s contention is that this invention is a way of making
more complex tasks easier to perform, that it has no real-world, practical application, and that this is the wrong problem for
inventors to tackle. He states
that “I’d rather see interface efforts based on watching what
users do, understanding common needs and designing systems in which those
actions are simple. Making complexity elegant is an achievement, but I’d rather
just make that complexity invisible.”

This is a fine sentiment, and a good one-sentence
description of user experience design, but he really misses the point of how
new input device inventions relate to user-experience design.

He illustrates the uselessness of gestural interfaces by describing
two ways of saving a users work – one using a whole series of convoluted
gestures that makes the user look like she’s doing the Macarena, and a simple,
elegant way of using keyboard strokes. Boy, based on that example, gestural interface sure sounds like a bad
idea, and inventors should stick to improving how to use existing input
devices.

The trouble with this example is that the same argument was
made about the mouse when it joined the keyboard as an interface device. There were (and are) many things that are
easier to do with a keyboard than with a mouse – saving a file using shortcuts,
typing a letter, entering data in a spreadsheet, just to name a few. Does that make the mouse useless? Why use something as complicated as a
mouse?

Let’s take the case of a user putting together a process
diagram in Visio. Using a keyboard
interface, a user can perform a lot of complicated keyboard strokes to
generate, place, link and annotate the diagram elements. Meanwhile, back in the real world (as Mr.
Coffee would say) the user simply drags and drops the elements in place using
his mouse, touch pad or pointer.

Clearly, different interfaces are good for different types
of actions, and it’s up to the user experience designer to apply the
appropriate combination of available interfaces in a way that lets the user
simplify and streamline their interactions.

So where might using a multipoint gesture interface simplify
a current, real world interaction? How
about Google Maps: Multipoint gestures such as squeezing,
stretching or turning, combined with single point gestures like dragging, could
make navigation significantly simpler and faster than the current mouse-based approach.

The point of inventions like this is not to make more
complex acts achievable, but what things can be simplified using these
inventions. Almost all ways in which we
interface with computers are pretty complex. For example, learning to use a keyboard is a lot more complex and time
consuming than learning to use a mouse, and learning to navigate using keyboard
shortcuts requires much more familiarity with an application than using a
mouse. Gestural interfaces need be no
more complex than keyboard or mouse interfaces.

So inventors, keep inventing!  Between user experience designers, developers and usere, we’ll take the best inventions to  make things genuinely simple.

Share/Bookmark

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it’s very [linear] nature makes it… well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here – at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations – look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn’t need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that’s another blog.

Share/Bookmark

Here’s just a little sampling of articles from the November 1983 issue of COMPUTE!’s Gazette.

• Computer Graphics – The Age Of Electronic Art
• VIC Super Expander Graphics64
• Introduction To Custom Characters For VIC And 64
• VICreations: Animating With Custom Characters

It seems every issue would have at least two articles on how to twiddle the graphical bits on the C64 or VIC-20, articles on how to make sprites dance across the screen or writing your own video game or drawing program in 6502 assembler. You had similar articles in similar magazines with the introduction of the IBM PC.

With the advent of the Mac (yes, yes, Xerox did it first), all that bit twiddling disappeared. People started wondering more about how to get windows and menus and buttons to do what they wanted them to do, or even to start developing their own controls.

Fast forward almost 23 years and read just about any blog or magazine that features Ajax articles. The articles are almost universally about nuts and bolts, nitty-gritty details, i.e.:

• Writing a server-side Ajax handler
• Creating souped up popup windows with Javascript
• Implementing fancy form controls in Javascript
• Understanding the DOM

It’s bit twiddling all over again. Perhaps it’s time to write an article on how to do Sprite animation with Javascript.

Share/Bookmark

Legend has it the famous advertising slogan “Two scoops of raisins in Kellogg’s Raisin Bran” was created by an energetic copywriter who literally dumped out the box of cereal on a table and scrutinized the content for inspiration. Moral of the story:  As designers we have to know our product. But what do you do when your product involves biological science, electrical engineering or any other complex domain? Here’s a few suggestions for getting up to speed in a complex subject areas.

Speak the Language
First, you have to speak the language. Ask your subject expert to outline the top ten or fifteen words or expressions used on a daily basis by your users. Then have him or her define those words in terms that you can understand.  Keep the number of words to ten or fifteen, and only the most important terms.

Key Scenarios
Next, identify the top five or so key scenarios your users do in a typical day. Each scenario should have a simple title and a set of steps. Remember, the goal initially isn’t to do user research, but just to get a feel for what people are doing. Try to cover the five scenarios in an hour or less. This will help your expert from getting too bogged down in details you won’t be able to digest yet.

Map the Scenarios
Once you have the key scenarios, arrange them in a hierarchy. Of course, it’s possible the scenarios are isolated tasks and don’t fit a hierarchy, which is fine. But usually a hierarchy of some kind applies. This hierarchy will become a context for understanding when your user does various things.

Construct a Day in the Life Narrative
To test your understanding of the domain, take the information you have gathered and construct a day in the life narrative of your user. In doing so, you will create a vehicle for refining your domain knowledge and a start to your more serious user research.   

Two Hours or Less
No matter how complex the domain, make it your objective to get through the above tasks in 2 hours or less. By time limiting the exercise, you can keep your subject matter expert from straying into the details before you have the basics solidified.

Share/Bookmark

A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company’s Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.

I’m sure most people involved in systems development have experienced this sort of infuriating situation — I’ve seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I’m not alone. No matter how much testing and training is done, some people can’t get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.

In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn’t play nice with the application design. You ended up doing lots of kludgy things that you wouldn’t do in a GUI or command line application. You had to think differently in order to build successful web apps.

As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we’re missing an opportunity to rethink how we build webapps. Isn’t it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don’t depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let’s rethink and DO NOT PRINT THIS FORM.

Share/Bookmark

Among the issues that the increasing ubiquity of Ajax on the web brings up is, where does that leave the "Back" button.  Or, is the page metaphor still relevant, and if not, how soon before everyone knows it?   
Essentially all worthwhile new technologies ask us to change our understanding of the domain they effect, and the compilation of techniques together known as Ajax have the potential to do just that.  But it will take time, no doubt.  There’s still a lot of work to be done–both for developers and designers–before adoption becomes universal, and years more before the inevitable breakdown of the page metaphor.  On the way, questions will need to be asked about where we as web app developers see our role in the transformation to "Web 2.0".

Share/Bookmark

woolfel gets bent out of shape about an abstract by Forrester that states that InRule uses RETE for it’s .NET based BRE when, in fact, they talk about a decision table based approach:

There’s a slight chance that InRule is using Microsoft’s BRE engine, but I would
think MS would require someone licensing the engine to state that fact clearly.
Since the InRule website doesn’t, I suspect InRule doesn’t use MS BRE and isn’t
RETE.

From my conversations with the InRule guys, it seems that InRule is a hybrid that started out as decision table based but has started to incorporate RETE. That may seem to be a franken-engine, but isn’t actually so far fetched when you think about the algorithms. I’m pretty certain that Microsoft’s BRE has nothing to do with it, since I believe InRule predates the MS BRE.

Anyhow, I can’t get quite as worked up about RETE vs anything else as woolfel can. Most real world applications of rule engines end up being so small in terms of numbers of rules and facts that the advantage of the RETE algorithm doesn’t really show up. This is sort of like quicksort vs insertion sort. Yes, quicksort is O(n log n), and insertion sort is O(n^2), but insertion sort is just faster on average for small n.

BTW, does anyone know the the worst case time and space complexity for RETE? I’ve been able to locate a paper on the average case complexity for RETE, but nothing for the worst case.

Share/Bookmark

I’ve been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it’s useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM’s Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.

A framework exhibits "inversion of control" at runtime
via callbacks. These callbacks invoke the hook methods of
application-defined components after the occurrence of an event, such as a mouse
click or data arriving on a network connection. When an event occurs, the framework
calls back to a virtual hook method in a preregistered application component,
which then performs application-defined processing in response to the event.
The hook methods in the components decouple the application software from the
reusable framework software, which allows each to change independently as long
as the interface signature and interaction protocols are not modified. Since
frameworks exhibit inversion of control, they can simplify application design
because the framework—rather than the application—runs the event
loop to detect events, demultiplex events to event handlers, and dispatch hook
methods on the handlers that process the events.

Inversion of Control, it’s not just for Spring anymore. Seriously, though, how many of the current Ajax toolkits — I’m not sure that with the exception of appfuse it’s correct to call them application frameworks — give you IoC? I’ll be watching to see if they make the transition to frameworks and will give credit where credit is due.

Share/Bookmark