- Kevin Mullet <mullet@icarian.com>
- Icarian LLC is creating a set of web-based applications to support
workforce management (recruitment, evaluation, hiring,
deployment, utilization, retention) for information age companies. We
provide an HTML front end that uses a set of Java business objects to
access existing enterprise databases in concert with our own people
asset database. The user interface we provide must be powerful
enough to support hard core, dedicated users (e.g., recruiters, hiring
managers) as well as occasional, possibly "lightly motivated" users
(e.g., individual contributors).
- Many of the issues we face arise from the growing divergence between
applications and publications on the web. HTML has strong
historical ties and a continuing orientation toward the publication
model. This model assumes that the final product is a constantly
changing collection of interlinked documents that are themselves
relatively static. There is a fairly strong assumption that every page
is relatively context free... viewers "see" the same page regardless of
where they are coming from. While there are ways to work around this
limitation, they are fragile, cumbersome, and generally not very
portable. Although navigation is certainly an issue for us, as
it is for everyone else (and we could easily spend the entire workshop
on this one topic), our leading sources of pain fall into four broad
categories:
- State management
- Web pages "want" to be stateless, but context-driven interaction is
fundamental to user-centered design (long-winded polemics against
invisible modes notwithstanding). Each page is a self-contained module,
and with the exception of the browser history any client-side state that
may have been built up is discarded when a new page is loaded. The page
has no knowledge of where you've come from and, as a result, it can't
provide context sensitive guidance on where you might want to go next.
There are numerous workarounds... adding a frame with a static page
whose primary function is to run the JavaScript and maintain the state,
using the URL to pass parameters from page to page, or going all the way
to a full blown server-side application... but all of these methods are
cumbersome or limited in scope.
- Selections and feedaback
- Selections are one of the fundamental concepts found in virtually all
GUI applications. The fact that they are completely unsupported in both
HTML and JavaScript is perhaps the most telling example of the web's
current orientation toward publications rather than applications.
Selection becomes essential as soon as the level of functionality rises
beyond a few simple operations or the number of elements being
manipulated expands beyond one. Generic commands that can be applied to
any or all of the available elements still provide the best user
interface to non-trivial applications. The lack of drag and drop support
is just a special case of this general limitation.
- Display momentum (i.e., frames)
- Everybody likes to bash frames, but they are still ( until we can assume
one of the 4.0 browsers ) the only way to preserve any display momentum
( which depends on some portion of the display not "flashing" ) when
moving from one page to another. This imposes a serious distraction
effect and probably contributes to the oft-noted navigation woes. Even
the most basic demands of dynamic applications - such as altering
choices the lower portion of a form based on user choices in the upper
portion - make this flashing problem even worse. Eventually all
browsers will catch up to the fully addressable document object model
defined by Internet Explorer 4, but until then we will continue to force
complete page reloads for most content updates. Unless we use frames,
that is.
- Authoring techniques for server-based apps
- Database-driven applications running JavaScript on both the client and
the server show some promise for addressing these problems but they are
excruciatingly difficult to develop. The limited graphical tools that
are available quickly decline in usefulness due to their inability to
handle the large amounts of custom code embedded in even the simplest
HTML templates. None of the graphical authoring tools, for example, can
display a form element once you've replaced the <INPUT> or
<SELECT> tags with JavaScript wrappers that query the database and
dynamically generate the available <OPTION>. And of course none of
the high-level site design / management tools are able to work beyond
the bounds of their own narrow assumptions about how the implementation
will be structured. Integrating the work of a graphic designer is even
more difficult than in the world of shrinkwrapped software. Imagine a
world without UI builders or resource editors... aside from handing over
the icons, designers are limited to whatever they can specify and
convince the developer to include.
- We are working on a number of ideas that partially address these issues
today, in an environment where we still need to support browsers from
multiple platforms and releases. Although some of these concerns will no
doubt be mitigated under the forthcoming unified document object model,
we will still need to establish conventions for using these mechanisms
to meet the needs of dynamic applications in relatively standard ways.
I hope to learn how others are addressing these issues. And argue about
navigation, of course.
|