- Jeff Brandenburg <Jeff.Brandenburg@persimmon.com>
-
I've got a set of issues that have come up as we've been working
on Web-based collaborative applications. These issues are somewhat
orthogonal to "traditional" site design, but as Web-based
collaboration continues to become more important,
more and more people are going to run into these same problems.
- Our group has been working on an application framework to support
distributed, collaborative applications using standard Web browsers
as clients. The framework uses a tiny (4K) Java applet to dynamically
reload HTML information. This approach provides good performance even
with relatively slow machines over standard modems, and avoids the
portability problems that still plague heavyweight Java-based interfaces.
- With this framework, we can build applications out of objects whose
user interfaces are built from standard HTML, using forms and links
for user input. Users are represented as objects as well, so you can
"see" and interact with other users, or mutually interact with other
application objects. As objects and users arrive, leave, change their
appearance, or do things, your view of the application updates
asynchronously to reflect these changes.
- Anyone familiar with basic HTML can describe and create new objects;
anyone who knows how to write simple JavaScript or Tcl scripts can
give these objects behavior, including autonomous behavior. This
makes for a powerful development environment, but it also raises
some issues that weren't really pertinent when "the HTML standard"
was first being developed.
- Navigation within a "spatial" metaphor
- Our framework supports a containment hierarchy, and most of the
applications we've prototyped follow a "rooms" metaphor. Users
can move from room to room (or among steps of a task), with "exits"
indicating where they can go next. Objects within these rooms
can have "action" controls that provide access to application behavior.
- The logic of these applications, and the techniques we use to
implement our framework, don't play well with browser navigation
tools -- it's the same problem Jakob Nielsen pointed out so long
ago ("Why Frames
Suck"). What does a "back" button really mean? Go back to the
previous location? Undo the last action?
- We believe we can build interfaces that will let users do what
they want without recourse to browser navigation buttons. What are
the things we absolutely must do for this to work? In this
era of "shopping carts" and other stateful Web-based interactions,
are users learning to get around without using the "back" button?
Or are we kidding ourselves?
- Using asynchronously-updated HTML forms
- The applications we're working on allow a number of people to
interact concurrently with application objects. We represent
these objects with HTML descriptions; a user's view of an object
gets updated whenever that object changes. The user never has
to "hit reload to see recent changes."
- One problem: it's fairly simple to put a form in an object, and let the user
manipulate the object that way. (Think of a threaded discussion
forum, with a form at the bottom for following-up a message.)
But if the object changes while a user is filling out the form,
the user has to start over!
- What's the best way to approach this problem? Should dynamic
views have a "pause button"? If so, how to you keep people from
forgetting to "un-pause," and how do you let them know that changes
are backing up while the window is frozen? Or must forms always
be in a separate, non-updating frame?
- Another problem: given asynchronously-updating views, we'd like to find ways
to represent how recently the view has been updated, or "how active"
it is. Simple timestamps probably aren't the best representation
in views that can change several times a minute (or more).
- Subject-verb-object interactions
- Users can move application objects around. It's fairly easy to provide
a "get" (or "buy") button, so you can pick up an object; in the same
way, you can discard an object, either dropping it into your "current
location" or returning it to its "normal location."
- How do we let a user "move this to there" with standard HTML
interaction facilities? On the desktop, we use drag-and-drop, but
to do that in the browser, you still need heavyweight Java, non-
portable scripting facilities, or proprietary (and again non-portable)
plugins.
- We've developed a "picker window" that displays a list of possible
destinations. If you select an object's "move" button, the picker
window displays a list including yourself, your current room, and
"containers" (objects that can hold other objects) in the room. If
you select an item from that list, the object you chose initially
moves to that destination.
- This has a number of problems. It's modal, and it's hard to make
that mode clear to the user. It turns a conceptually atomic operation
into a two-step dialogue. It forces the user's attention to the
picker window, when the user's task should only involve the object
and the destination. It forces us (the implementors of the
framework) to decide what should get displayed in the picker list; that list might not
include the destination the user has in mind, and might include a
lot of destinations that aren't relevant in a particular application.
- Before drag-and-drop, people moved things by copying (or cutting)
them to a clipboard, then pasting them to a new location. We could
do something like that, but then there's an interim period when the
object is "in limbo," not really "located" anywhere. This is a problem
in some applications.
|