Re: Layout is content, not a property of content.

> Look at the window this content is in. It has a title bar, menus, a
> toolbar, possibly a status bar and so on. These layouts are part of
> the system specified in content somewhere and they are reused over and
> over again even when all the other aspects change.

These layouts are not part of the application code, they are part of
the platform (in HTML terms, this means that they should firstly be
defined by the consumer's operating system and secondarily by the
user's web browser).  You can tell this with well written applications
because you can move them from Windows 3.0 to Windows XP and still 
have them obey the conventions of the operating system on which they
are currently running.  X Windows applications can often radically
change their window decoration on the same version, without
changing anything in the application.

> 
> Content on the web works the same way. Pages often rely on only a
> handful of layouts. Styles vary greatly, but layouts are fairly
> restricted. This is a good thing since finding information is painful
> when these conventions are ignored.

By analogy, such things are part of the document structure, or I would
argue, the sub-web structure, and the resulting physical layout ought
to be determined by the consumer's tools, not by the document.

> It seems that when we moved to the web we had to relearn everything we
> learned on the desktop.

What really happened is that people started using web sites as thin
client applications, using a language designed for documents.  The other
problem was everyone wanted to brand their own chrome, rather than
accepting the GUI platform's branding.  As the computer software
industry continues to move from a data-processing to a fashion based
arts industry, this ignoring of standard platform behaviour is
moving into native applications as well.

> So what does this mean. It means that it should be possible for the
> UA/user/OS to specify the layout used and not the page. The page
> should be more concerned with how it looks and not how it's layed out.

What is needed is for the document to identify the structure, so that
the user agent can apply it to the standard layout that the user 
understands, much like a traditional Windows or X application, specifies
the menu contents but not how or where to display the menus.

Moreover, I think that the right way of doing this would have been
the use of link elements.  E.g. the contents links indicates what to
use as the navigation menu contents and one could have a site branding
link for logo and top margin type content (the link version of 
favicon is already a branding link).  Because, as I said above, 
designers think establishing their branding is more important than
applying platform conventions, it is probably too late for that now.

Part of the reason that link wasn't properly implemented in the early
days, is that the early GUI browsers were targetted at advertising, not
at documents, and were really PDF competitors, concentrating on visual
appearence and giving authors control of that (one telling event was
the removal of user control over heading appearence when Mosaic 
became commercial as Netscape).
 
> The usability improvements would be immense. The user wouldn't have to
> guess what the designer was thinking when he or she designed it and
> users will gain the benefits they've had on the desktop for years.

The reason they have to guess is because designers think that establishing
their branding paradigm is more important than obeying user interface
guidelines!
 
> It allows for spatial orientation to match the environment the user
> uses and not the environment in the designer's head.

Unfortunately designers, or rather the marketing people that commission
them, generally don't want the user to play with their layouts!

[ There are a lot of points that I'd like to respond to today, but I
only have limited time - it's my own time - so I'll probably miss a
lot in other replies. ]

Received on Thursday, 30 June 2005 21:22:52 UTC