[whatwg] What improves Web applications?

[Nigel McFarlane]

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

For the keyboard: word processing speed - maximum typing rate.
For the mouse:  graphic design speed - leaping from palette
                 to palette instinctively, clicking "where it works"
		without checking the thing clicked on.

>>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 summary, a subset of such applications rely heavily on
tab-navigation and the use of micro-prompting cues like
keyword completion in fields. Some even have a command line
for keyword-based screen navigation. The user tends to bounce
between screens or subsections of screens using shortcut techniques
specific to the app. Scrolling is almost never used, unless
the app has strong document-display functions. Mouse-pointer
navigation and dialogs when added, rarely increase the speed of use.

A Unix example with some vague equivalence would be elm (a character
mode email reader). The ancient input styles of VisiCalc or EDIT
are others. Bash is another. Used repetitively, these are very
fast tools.

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

I'm not saying "abstract HTML", there are various research dialects that
attempt that. HTML is a nice concrete language and should stay so.
(although I do say that dialogues are time-ineffective for users).

On platform compliance, I guess various -moz extensions and CSS3
properties lead down that path. I'm in favour of that. If that's the
extent of HTML's support for native-style form interfaces, then
that's at least something.

My point (a broad one) is that HTML is the main vehicle for
service delivery across the Internet  - to about 50% of all consumers.
Web apps are common, increasingly so, and increasingly complex.
Most people would rather go out and play than sit in front of
a computer, and if web apps can be built so that there is some
commonality in fast navigation techniques, (tab order
is an existing example), then everyone can go home sooner.
Monolithic organisations would also rather see their
info-workers using efficient UI's.

I also lack extensive concrete ideas on this front; this thread
started with an observation by me that developers are not the
only consumers of such technology; users (consumers) count too.

Blue-skying for a minute, though, I can see how some
meta-data hints in HTML about the availability of keys or
data input workflow steps might allow browsers to display
additional navigation info for the user (perhaps in a toolbar),
It might further assist with accessibility too - if not for the
blind, then at least for the unrecoverably dim. I'm not, however,
putting myself up as a standards expert on that point.

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

I'm suggesting that today's internet banking sites are very
simple examples of the kind of service delivery we're likely
to see from banks in the next few years. So new features of
HTML are appropriate if they ease consumer's use of such services,
especially if consumers find that managing their life binds
them increasingly to such apps.

In summary, all I've said is that navigating websites is not
as fast as some other navigation environments in computing.
There's opportunity to factor in end-user needs here, and
simultaneously make HTML navigation options a bit broader.

There are other ways, though. For example, there are now
various industry standards like PDF/X that sit atop PDF.
They're used to define a subset of PDF for particular modalities.
Embedded PDF adverts submitted to magazines is an example.
Perhaps several such "views" of HTML might emerge one day
in the absence of global look'n'feel Web standards: one for
TOC-style e-books; one for form data-entry, one for link pages,
and so on.

- Nigel.

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