W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] What improves Web applications?

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 5 Aug 2004 08:40:10 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0408050830240.2738@dhalsim.dreamhost.com>
On Thu, 17 Jun 2004, Nigel McFarlane wrote:
> > >
> > > 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 guess I don't know what you mean then. Could you give detailed examples?


> I would ask you to compare Web/doc navigation with the data-entry 
> behaviour of bank tellers or travel agents.

I am not familiar enough with these systems to understand how the 
navigation in such systems differs from the navigation in HTML. Could you 
describe some cases for us?


>> 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 ... ?

You're assuming users understand the application/document duality. In my 
experience, this isn't the case. The way in which the "new" modality is 
better than the "old" one is that it is, IMHO, closer to the mental model 
that most non-experts have.


> 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.

Sure.


> 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.

Ok...


> 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.

Absolutely. However, beyond providing Web application authors with richer 
widget sets, what can one really do? The "highest gear" is quite different 
from platform to platform (for example Ok/Cancel buttons are in a 
different order on Mac than on Windows), are you saying we should extend 
HTML to the point of being so abstract as a UI language that HTML apps can 
easily be styled into a platform-compliant application?

I have no idea how to even approach that, if so.


> > > 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.

Internet banking sites don't need breadcrumbs either. I'm not really sure 
what, at the concrete level, you are suggesting.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 August 2004 01:40:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC