In the first part, I’ve ranted about messy UI architecture of HTML. Today, it is turn of the HTML’s messy information architecture.

We use local applications and web applications for different purposes.

On the one hand, we use Calc app to do simple math, Microsoft Office Suite to format, spellcheck and layout our documents, and Adobe Photoshop to process our images.

On the other hand, we use Google search to find sites, Virtual Earth to obtain a map, YouTube to stream music clips, Skype for instant messenging and Wikipedia to learn and to share knowledge.

As you can see, the value proposition of local applications focuses on algorithms and information processing, while web applications are traditionally about information retrieval. 

Because web apps are so often about information retrieval, information architecture plays an important role.

Information architecture is how information is organized, categorized, and distributed across parts of the system. Simply put, it is how you see the world of your application. Is it a tree of documents? Or interconnected graph of business entities? Consists the world from records of a multidimensional cube?

By designing or choosing a particular information architecture, a spectrum of possible user interaction models is defined.  These models establish the perception of the user. In what chunks can information be consumed? How can I navigate through it? Can I filter or sort it?

HTML has been initially conceivedwith only one information architecture in mind; and this architecture is still hardcoded everywhere in the infrastructure (browsers, server-side frameworks, etc):

• Information has to be partitioned in pages. 
• Information can only be retrieved in pages. 
• There is only one current page. 

Note that I’m only speaking about HTML here. Other web technologies, notably HTTP with its RESTful nature and Javascript in all its kinds, also play an important role in definition of the information architecture. But they are a completely different story.

Page Partitioning

If your site is a dictionary, a stream of marketing news or a wiki, seeing the world as a bunch of pages is perfectly natural way.

Not so in many other cases.

Let’s take e-commerce as an example. On the first glance, everything looks great. Traditional commerce co-existed hundreds of years with book printing. First product catalogs were printed as books (bunch of pages), so that implementing them as a bunch of HTML pages seems to be quiet natural. When the user goes to the check out, he just fills a couple of pages of an order form, just like he would do when using mailorder in the 19th century.

Mailorder in the 19th century… Doesn’t it sound suspicious?

I live in Fuerth, a hometown of well known mailorder firm Quelle. They have also a huge normal store in the nearby Nurenberg. In my town, we have also an IKEA store. Both Quelle and IKEA have web shops. But I still prefer driving to the store and buying things physically, rather then ordering them in web, even though web shops have a bigger assortment, are opened 24h a day and don’t take time and money to travel to the store.

It is so, not only because you have to try clothes (I rarely buy clothes in Quelle) or delivery per DHL isn’t really hassle free. One of the factors is missing shopping experience. Shopping by skimming through a bunch of pages and filling forms doesn’t get you a good, rewarding feeling. Originally, mail orders were developed as a poor man’s choice and targeted rural areas without access to normal stores.

That’s why things are changing slowly: more and more web shops present their product catalogs in coverflows, scrollable bands, DeepZoom, 3D models, virtual shelves, etc… which are all not pages!

If even e-commerce isn’t really happy with paging, what can we say about new web apps trying to re-implement local apps in web… Online tools to create mindmaps, wireframes, calendars, issue tracking. Online games. Online TV. You name it.

Page-based information architecture would be perhaps not so big issue, if pages were only abstract information containers. Unfortunately, they aren’t: on the one hand, valid HTML pages must have a title tag and are conceived to be rendered by the browser and also to be integrated into the browser’s navigation framework (back button, favorites, etc). On the other hand, HTML pages are not flexible enough to contain just any kind of information (you cannot put 2 seconds of video payload in a HTML page), at least not in an efficient way.

Hence, server-side frameworks for generating HTML pages cannot be meaningfully reused for any other purpose other than sending HTML to be rendered on the browser side.

Page Retrieval

In HTML, you can retrieve only pages and anything you retrieve is a page. Sure, with a modern browser, you can retrieve any kind of files, but they are outside of the HTML scope.

It is interesting that the HTML 4.01 spec doesn’t even spend much time on retrieval mechanisms of HTML documents. The only mentions of HTTP are in descriptions of META and FORM tags. Conversely, the HTTP 1.1 spec almost doesn’t mention HTML at all. This shows how much attention the fathers of WWW had spent on dynamic aspects of web apps :)

Meanwhile, retrieving in pages is an issue even for web apps ideally fitting into the page partitioning world. Most of the web pages today, except of the purist and geek ones, have fixed parts repeating from page to page (headers, footers, navigation, etc). Transferring them each time you load a page is a waste of time and money and, as already said, prevents a couple of UX scenarios.

Maps are more interesting example. Real, paper maps consist literally from a bunch of pages. Their early electronic counterparts were also implemented as pages. You clicked on an arrow icon on the map, browser refreshed the page, a new page was loaded, with a new map location. It took more time waiting for the page reload than to lookup a paper map, so if you happened to have a paper map of a location, you didn’t used an electronic map. Nevertheless, they were conceptually pure and beautiful.

So, why do contemporary maps consist from a single HTML page and load their content dynamically? And was shortening the refresh time the only motivation?..

Modern maps consist conceptually from layers of tiles. When users pan or zoom the map, it is only naturally to load missing tiles, instead of refreshing the whole page. This information architecture allows not only for better performance, but also for additional features, like user-definable overlays above the map, dynamic and user-definable POIs, replacement of the rendering engine from HTML DOM to Silverlight (with possible increase in performance and usability) etc.

Only One Page

While modern browsers have a tabbed interface, and you can open several pages at once while surfing on a web site, conceptually each page still believes to be the single one.

Browsers have full control about how to display the pages, and HTML has no control about it.

Why would you bother?

Say, your web site is a web shop. Each your product has a HTML detail page, with an impressive rotating 3D image of the product, detailed info and technical spec. Your product catalog is a HTML page displaying a grid of product thumbnails.

When your customer clicks on a product, you naturally send him the product detail page to help him decide to buy. On the other hand, of course you want to leave your product catalog visible in his browser. In case your customer doesn’t like the first product he looked, it must be easy for him to return to your great catalog and select another product.

So you open the product detail page in another window (let’s ignore popup blockers for a moment). Your customer decides to buy the product, so he clicks on the buy button. What you want now is to show him the shopping cart. So you send him a HTML page for the shopping cart and attach the product page to it…

Wait… No? Not possible? Cannot collapse the product detail page and embed it into the shopping cart page? And, besides that, there are too many pages? But you want this feature to EARN MONEY! 

Product catalog is needed so that the customer can buy accessories to the product. The product detail page enables the customer to refer to the requirements the product has to its accessories. And the shopping cart must show the current total sum and a nice compelling checkout button.

By abandoning the page concept, whether using AJAX or Silverlight, you just get some screen real estate on the customer’s computer and can do there whatever you want. For example, you can implement the scenario above in the usable and visually compelling way.

I don’t see a benefit to allow the HTML standard to dictate, how my information architecture must look like, in what portions the information has to be transferred, and how parts of my information have to be presented on the client side.

HTTP to transfer apps and data, Atom or JSON as transport encoding for the data, Javascript or some other client-side language, and a visual framework allowing to do what you want on the client – these standards would be enough to enable contemporary web applications. And no, I really don’t care about lynx users (I do care about mobile users though).