Wandering Thoughts archives

Frames were never necessary for menus and tables of contents

One of the big excuses for HTML frames, back in the days when anyone tried to use them at all, was that you needed them to do websites with tables of contents and similar things (I was reminded of this when a commentator sort of mentioned it in passing on here). This excuse was always bunk.

We can see how much bunk it is by looking at pretty much any blog, where you will find things that look an awful lot like a table of contents (and menus and so on, all of those things that frames used to be used for), none of which uses HTML frames. But, you might say, blogs are all built with various sorts of blogging engines and content management systems.

Exactly.

What was really going on with this excuse for frames is that people were using a bad HTML feature to cover up (or deal with) the lack of decent backend technology. The attraction of frames was that you had one file with just the table of contents and one file with just each bit of the content and so on, and HTML put them together for you (at the cost of a bad user experience). Any templating system would have done that for you just as well as frames did, probably with more flexibility, and the result would have had a much better user experience.

(With some more work, templating still copes with more sophisticated systems that had multiple, different tables of contents that still use the same actual content. And even back in the day when it theoretically wasn't feasible to run a program on every web request, you could perfectly well use a templating system that pre-built the actual HTML files.)

You don't even need much of a templating system, since frames aren't really very sophisticated themselves; for a table of content, all you need is file inclusion. File inclusion is really easy to do, sufficiently easy that Apache has had an option to do it for you for some time (I believe it dates from the heyday of frames, for that added annoyance).

Finally understanding the attraction of AJAX

I'll admit it; I'm slow sometimes. For a very long time now I haven't really gotten why people keep sprinkling AJAX over their web pages (partly because I assiduously use NoScript and so mostly don't see it). Oh, I understood that you needed it to create actual applications on the web and that it could be convenient for making vaguely friendly things, but I didn't really understand it in the context of relatively ordinary web apps like DWiki.

But my recent thinking about my comment form design mistake has finally fixed that. Here is my recent insight in a nutshell:

AJAX lets you do things without page changes and refreshes, so you can preserve the user's context on the page and make them less confused.

In a conventional non-AJAX web interface, any significant action forces a (full) page reload. This creates a visible page refresh except in extremely ideal circumstances and in general means that the user has to find their place again and reorient themselves. This is sort of tolerable if what the user is working on fits entirely inside their browser window; it's fairly horrible if it doesn't and they have to actively scroll around to find where they were before. This is the core problem I have with a revision to my comment form design; I'm pretty sure that people would get lost among everything else going on.

(The ideal circumstances are that you're using fragment identifiers in the URL, the browser accurately repositions things back at the fragment identifier, and the entire system loads the new page so fast that there is no visible flicker.)

In an AJAX web interface the user can perform actions without this lurching jump. For example, when they click on 'add comments', they don't get yanked to a new page; instead, a comment form unfolds right then and there in front of them. This is less confusing in two ways. First, it is happening right in front of you, clearly visible. Second, it is the only thing that is happening; you don't have to pick out the significant change from all of the other flickering and movement and so on that's going on as the page reloads.

This creates a more fluid, less disorienting interface, one that is easier and faster to work with because you spend more time doing what you're interested in and less time finding your place again every so often. In a sense, the result is much closer to a direct manipulation interface than a standard, non-AJAX web page can manage.

I don't think that there's any way to pull this off without AJAX; you really need some way to do a partial page content update without anything else flickering or moving. That's just not something that browsers offer (you don't even get it on plain user-initiated page refresh).

(I suspect that this is old hat for people in the field, but all of it only clicked for me when I started really thinking over the problem of people getting lost in my comment form under various circumstances, cf TemplateLimitations.)

PS: looking backwards, this makes me slightly more sympathetic to old HTML frames. Although they were almost never used this way, you can argue that they were a crude first attempt at the sort of limited page update you'd need to pull this off.