[whatwg] What improves Web applications?

[Nigel McFarlane]

>>Web apps are "tightly navigated" and subject to "data entry". They are
>>visited "repetitively" or routinely.
 >
> ...and I "tightly navigate" several W3C specs repetitively and routinely,
> although I would call them documents not applications.

We differ on what tight navigation is. I mean really tight.

I would ask you to compare Web/doc navigation with the data-entry
behaviour of bank tellers or travel agents. If you stick to ones
that use non-dumbed-down non-Web applications, you'll see
their navigation techniques are far more efficient than those
used generally on the Web. A non-dumbed-down app is one that
hasn't been mouse-ified or dialog-ified in search of dubious
improvements.

> In general I think the separation of "data" from "code" -- the separation
> of "document" from "application" -- is a concept that has been outgrown

In implementation terms that may be so, but in terms of
modalities it's not. Support for common modalities is what users
need, whether those modalities are drawn from non-computer idioms or
constructed from perceptions of how computers work. Both
"document" and "app" are well established idiomatic uses of
particular software. A page that happens to blend those two
is either failing to be either or attempting to develop a new
modality. Any new modality assumedly is better in some way,
which is ... ?

>>Of course, it's possible to build a DHTML page that's tightly navigable
>>without the user having to absorb a lot of information about images

> Not 100% sure what you mean by these. Could you elaborate? Maybe there are
> some things we can do to HTML to solve these problems.

The brain-effort required to absorb a page/window whose structure
is hinted at by graphical layout is greater than the brain
effort required to navigate a page/window that has fixed and reliable
structural aspects that a user can recite from memory or habit
(like OS look'n'feel + useability guidelines). That is just
a consequence of the cost of visual processing by the brain.

If you're a frequent Amazon user, you can learn some of the
layout specific to that site. That will speed you up a bit. It won't
speed up your general Web use - every app is layed out differently -
and it won't speed up your use to optimal keyboard speed. That is
the case behind the success of the Mozilla Amazon Browser app,
and the argument for modality support in the absence of a single
canonical Web page look and feel.

Seperate to the Web, using a mouse and/or visually absorbing
layout content are both slow navigation techniques for frequently
visited applications.

For HTML, the hope would be that when an app developer want
to support the "highest gear" navigation speed, then such pages could
be easily constructed without those other problems.

>>The web bolt-on technique of "breadcrumbing" is an example of how HTML
>>is encumbered by lack of fast navigation techniques. There are no
>>breadcrumbs in WinZip or in MYOB/GnuCash/QuickBooks (for example), and
>>no need for them.

> I don't really see that there is a need for HTML-based applications of
> that type either. GMail for example has no breadcrumbs.

Well, that's an ambitious statement at least. Those apps are
in none of the classes dropped from consideration so far. Most
Internet banking sites are proto-examples of such apps.

- N.

-- 
---------------------------------------------------------------------
Nigel McFarlane                                   nrm at kingtide.com.au
Services:                   Analysis, Programming, Writing, Education	
Expertise:            Software, Telecommunications, Internet, Physics
"Rapid Application Development with Mozilla" / www.nigelmcfarlane.com