Jason's Recent Weblog Entries
With One Arm Tied Behind Their Backs
The web and the Internet have been so successful (and so hyped) that
they eclipsed all other kinds of software development. In that
eclipse, we've lost sight of some of the things we learned about
human-computer and programmer-computer interaction in the dawn of the
PC era. History tends to repeat itself in the computer industry.
Given that as a starting point, how can we expect the web to change
over the coming decade?
First, what's wrong with the web at all? Operationally, the web uses
a rigid request-response-display cycle with response times running to
the seconds or tens of seconds. Design-wise, user interface elements
are limited by the restrictions of HTML. The user experience of a web
site shares more with minicomputer/mainframe "green screen" terminals
than it does with the any modern graphical user interface: A panel
(web page) is presented to the user, the user fills in or selects
fields, a request is sent off to a server in the sky, and at some
point a response is returned and painted onto the screen.
I'll elaborate on some of the consequences of this model:
- Usability has taken a big hit:
HTML doesn't offer the rich set of tools and opportunities for
feedback, reactivity, and careful formatting which a good
user-interface design depends upon. Add-ons like Flash and
client-side Java and modern versions of HTML (DHTML, CSS, etc.) offer
relatively minor improvements but suffer from many incompatibilities
limiting widespread use and in any case do not change the
request-response-display cycle.
- Interactive response times have soared:
Waiting taxes the attention span and forces us to multitask to retain
efficiency when we might be better off focusing on the task at hand
until it is completed. One widely-cited IBM study
from 1982 found that reducing one particular system's response
time from 3 seconds to 0.3 seconds resulted in a 100% increase in
human productivity using the system. Another, more
recent study found the same thing. And while both studies used
programming tasks, I think we can apply those results generally.
Notice that even the longer, 3 second, response time would be
considered "quick" on the web!
(other
good references here)
- Persistance of interaction (and the lack of it) has hurt programmer
productivity:
The "stateless" request architecture of the web is great for fault
recovery and simplifies the protocol considerably. However it makes a
web programmer's job harder because it requires otherwise continuous
processes to be broken up into many tiny chunks. This cuts programmer
productivity and continues to be the source of many security and
reliability problems today.
... to be continued ...
- why the web is a *good* applications platform after all
- when client software might nonetheless be a better choice
- explain the impact of XML on enabling better client-software connectivity
and helping bridge the gap between fully-connected web applications and fully
disconnected browser-based apps
- what does this suggest for future applications development?
- what am I doing now along these lines?
Category: /it
permanent link