- From: Nigel McFarlane <nrm@kingtide.com.au>
- Date: Thu, 17 Jun 2004 20:07:10 +1000
>>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
Received on Thursday, 17 June 2004 03:07:10 UTC