- From: Neil Deakin <enndeakin@sympatico.ca>
- Date: Fri, 11 Jun 2004 10:26:10 -0400
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
Received on Friday, 11 June 2004 07:26:10 UTC