[whatwg] What improves Web applications?

[Neil Deakin]

Most of this is a more general response to the discussion going on in this
mailing list, but it is related to this message.

Nigel McFarlane wrote:

>
> The point I keep coming back to with Web apps is that they
> are a fundamentally different use-case to Web docs.
>
> Web docs are "browsed" and "read", which can be re-phrased as
> "lightly navigated". They are visited "ad-hoc" or casually.
>
> Web apps are "tightly navigated" and subject to "data entry".
> They are visited "repetitively" or routinely.
>
> 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 and white areas. It's just not
> done much. And it's not possible to navigate a Web app by
> keyboard without the focus moving to the toolbar (irritating)
> or else providing a pop-up window.
>
There are two types of UI model used today. The first is the data entry UI
where the user would enter information and then click Next or Submit to save
results or continue with the next step. This model is the one traditonally
used by database tools like Access where the user doesn't generally do much
with the data except enter it and perhaps later, generate and print results
of the data. This UI model has been adopted by HTML via forms.

The other UI model involves a menu bar and toolbar across the top of a 
window
(top of the screen for the Mac menu bar), and a work area below. Apart from
navigating the contents of the work area, one doesn't usually go to 
different
pages or fill out information. Instead, operations are carried out by 
selecting
from dialog boxes. For example, Options -> Cookies -> Delete Cookies, by
selecting menu commands and choices from dialogs. This model tends to 
use lots
of different 'popup windows', and is used for most native applications, 
such as
a file manager, mail client, spreadsheet, and the browser UI itself.

The problem from a usability perspective comes when these two UI
models are combined, which has often happened with current web applications.
I think web developers, which are almost never user interface designers, 
have
a tendency to borrow the concepts from the menu/toolbar UI model into web
pages but don't succeed since an HTML-page-in-a-browser doesn't fit this
technique. In fact, the idea of using tabs in Nigel's example (see link 
below) instead of
a page by page is less usable. Much better would be a page by page that 
simply
fit on the page better.


> 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 nedd for them.
>
> I touched on this recently here:
>   http://www.webreference.com/programming/xul/index.html
>
> I'm not saying that's a full analysis, but it does
> contrast and compare some HTML tricks with XUL ones.

I think evolving HTML into the menu/toolbar UI model is not the right
direction in which to go. These types of UI are better served by different
languages such as XUL/XAML/etc... My understanding from reading the 
documents
on whatwg.org suggests that this is what is intended by the WHAT group.

Instead, the focus of this group should be on improving HTML within the
data entry UI model, which is exactly what WebForms 2.0 is doing. From 
there,
the web applications spec should attempt to improve the underlying 
technologies
such as server side events, drag and drop, rich editing, etc, but not on
defining a whole pile of menu and toolbar tags. The Web Controls spec is
described as 'a specification describing mechanisms for creating new 
widgets'
but is not a specification for defining what those widgets are. This way,
many of the specs that come out of the WHAT group (such as one for drag and
drop) can be used equally in HTML, XUL and even usable for those that prefer
the XForms/SVG approach, which, to me, has the advantage of being backwards
compatible with everyone.

Another reason is that drag and drop can't, as far as I know, be implemented
with today's W3C specifications, at least not easily, yet to your ordinary
web developer, a toolbar can be -- most will just create a <div> and stick
some images in it. In fact, I'm betting that even with a <toolbar> tag most
will still just use a <div> and stick some images in it.

/ Neil