Sat, 2007 Nov 17
REST or: How I learned to stop worrying and love frames
Look back about a decade. I was making my first forays into HTML. The web was young, at least compared to now. Geocities was popular and frames were all over the sites I visited. Frames. Dividing up a graphical interface into distinct segments works so well in desktop applications. So what was wrong with frames?
I was quick to develop a dislike of frames. There were the issues with back and forward buttons working in unexpected ways, the difficulty in viewing the source of a particular frame, other such technical difficulties that browsers handled poorly at that time. More significantly, they were consistently used not to divide up the interface but rather to pollute it.
I could at least understand the business rationale behind advertisements in a top frame, although that didn’t stop me from avoiding such sites. However, in looking back, I think what most turned me against frames was the 100 pixel each header and footer frame combo that for some reason was a popular layout, especially in personal sites. In so limiting the area for content, such design limited my choice in the layout of my desktop. That many of these sites had so many other design problems contributed to my determination that frames were simply a mistake.
My last such negative encounter with frames came about four years ago with a website I was reworking. The original designer of the site admitted to having very limited html knowledge. She’d agreed to design the site because she knew more than anyone else, and had done well for her experience. But there were those hideous misguided frames. I was glad to see xhtml strict wouldn’t allow this. Frames, for me, were a failure that I felt should be banished from websites forever.
A series of things have since happened that altered my view on frames. Oh, I still think they should be used sparingly, but I no longer avoid using frames.
About two years ago, I began learning Ruby and Rails. I didn’t notice how much I came to depend on an application that used frames: Rdoc. Here I was, several times a week using frames and it didn’t even occur to me to be bothered by it. In fact, I began to realize that one of the reasons I so like using Rdoc is because of the way it takes advantage of frames. Rdoc also elightened to me some updates in browsers that make frames less annoying; they handle frames much better these days. Firefox’s “This Frame…” context menu is great. And Backs and Forwards now work logically enough for me.
So, when two years ago, I was using all sorts of div craziness to basically mimic the behavior of frames, only mimic it very badly, I was building a problem I didn’t need. After all, the desktop program I was trying to imitate used…frames. Who knew? And all along I refused to use frames, because they had been abused. Really, though, although frames in one context made intuitive sense, I could explain why. If I couldn’t explain why frames should make sense for this web application, I assumed that meant my conceived use must be an abuse.
Then, Rails started having all this REST related goodness coming out, and suddenly frames made sense. I’m not expert on REST, but the main concept I take from it so far is that websites can be considered a set of resources being acted upon according to the verb of the http method. PUT bike[.html], GET bike, DELETE bike. So how does this suddenly clear up the frames issue. Well, it created for me a simple test. Yes, it’s oversimplified, but I like it. Here it is:
Does any request other than GET make sense in the context of this website?
If the answer is “Yes”, you might want to use frames. Now, that doesn’t require that other methods be used (they’re generally not in “help” applications, like rdoc), but that it’s easy to imagine adding that in. For example, I could modify rdoc, so that users could add comments to each method. I could not conceive of adding a comments post to, say, the main part of my church’s website.
This distinction reflects a distinction between web documents and web applications. Documents imply the user retrieving information as directly presented; applications imply the user altering the information or using the information in a clearly non-linear fashion. For web documents, the only use of frames that I can begin to understand is headers and footers. But that’s a very, very bad use, in my opinion. And has largely disappeared in the last few years, at least on the sites I visit.
For applications, things suddenly change. They…imagine this…can act like desktop applications. And desktop applications can make very good use of frames. So, now, instead of saying “No frames, no way”, the last web application I’ve started working on uses them, and uses them in a way that I believe will vastly simplify the design.
