Wireless Web

Posted to UWebED 17 July 2000

Kari Chisholm wrote:

Kevin--
I'll respectfully disagree.
Wireless Web browsing is such a miniscule fraction of Web use that to spend a substantial quantity of resources on it is a waste of time. Frankly, the standards haven't even gotten worked out.... [much clipping]

While I am (very) sympathetic with Kari's comment, the fact is that we are looking at an increasing number of page display devices. Consider the existing range of possible displays:

  • HTML (and XHTML)
  • IE and Netscape flavours
  • RSS, RDF, CDF and other syndication formats
  • WML and other wireless standards
  • .js for embedding in other documents

and that's just a start. Even within one domain, we can imagine how we would want to be able to provide several views of the same information: For example:

  • list of programs in a faculty
  • list of programs, with course titles, in a faculty
  • list of programs with course titles and descriptions, in a faculty

etc.

I have been telling online course designers for some time now that they should stop thinking about designing HTML pages and start thinking about content management. The same applies for university web sites in general (the same applies to all web sites in general, but I digress).

Conceptually, you need to distinguish between:

  • the content, that is, the information to be displayed, and
  • the format, or, how the information is displayed

In terms of content, you should proceed as follows:

  • define the information to be displayed. Structure it hierarchically (ie, faculty - programs - courses etc) and maybe represent this structure using a DTD or schema
  • create a database for this information
  • create a mechanism for extracting this information in a structured way (ie., be able to extract some or all information fields for the faculty)

In terms of display you should be thinking of this:

  • detect the application accessing the information
  • use this information to select a template (or CSS or XSL)
  • retrieve the relevant information
  • merge with the appropriate template
  • send the information in the proper mime type

This way, when a new standard emerges (or when a standard is updated), you are not rewriting thousands of web pages - you are simply creating a new template (or CSS or XSL) for that type of application.

I've very briefly summarized a complex process - but believe me, as the number of viewing applications multiplies, you will find this this structured approach is the only way you can cope.


Share |
Views Today: 3 Total: 153.