Modal Web Development
I was chatting with Chris Double the other day about the growing number of hits in our referrer logs having to do with "continuation based web frameworks", and how awkward a phrase this is. Not only is it long to write and say, but it rather misses the point: it describes a particular implementation technique without saying anything about what the technique achieves. You can build Seaside-like frameworks without having full first-class continuations (this is what UnCommon Web does, and arguably what ViaWeb did years ago); you could also build a web framework that happened to use continuations but didn't have Seaside- like session flow. So I proposed that we stop talking about continuation based web development and start talking about "modal web development" instead.
Why "modal"? Well, first of all, it's short, and it's an adjective instead of a noun, both of which are bonuses. Second, it brings to mind one of the best examples of Seaside-style interaction, which is the modal dialog box. In pretty much any desktop GUI environment, there are a number of simple functions or methods that bring up standard dialog boxes (file selection, color picker, notification, confirmation), block the current thread until they are dealt with, and then return the user's input. These are supremely reusable - the file selection dialog doesn't know what you're going to do with the file, just that you need one, and so it can be written once by the toolkit developers and used unchanged by hundreds of applications. They are also extremely easy to use - if at some point during a computation you realize that you need a file before you can continue, you just write something like
end = chooseFile("Pick the end point of the morph", "*.jpg")
and keep going from there. One major advantage of Seaside and similar frameworks is that they let you write webpages that act much like modal dialogs, and reap those same benefits of simplicity and reusability.
Now, I know that people instinctively flinch when they hear "modal UI", because in a desktop context we've all had "modeless good, modal bad" drilled into us. I actually don't believe that this applies in the web context, but I won't go into that now. Instead, I'll just say that at least in the specific case of Seaside, the point isn't that you are forced into using a modal style, but rather than you have it available when you need it. Seaside has an excellent event model and uses it extensively, far more in most applications than it uses modal semantics. However, you can have real modal interactions when you need to, whereas with pretty much any other web development technique you can't, ever.
So this is a blogging experiment: how long before we start seeing "ANN: new modal web framework" and "Modal web dev sux0rs!" posts? Is "continuation-based" already so entrenched a term that it won't catch on? Or will the opposite happen: no longer tied to a specific implementation, will "modal" get so widely and over-generally applied that it's rendered as meaningless as "MVC" or "object oriented"?
Note: I originally wrote this about a week ago, and then decided not to post it because some people I respect really didn't like the term. However, Chris Double just let the terminological cat out of the bag, so what the heck: let's see how it plays with a wider audience.
Comments
I think I can live with it
[Chad Fowler] April 3, 2004 10:03:33.309
It's definitely better than "Continuations-based web framework" ;)
I just keep saying "modal" to myself
[Brent Vukmer] April 3, 2004 11:32:07.436
And I still like "continuation based" better. It sounds mysterious, different and cool :)
"Modal" is a misleading name
[Sophie] April 3, 2004 14:15:19.618
If anything, by enabling the BACK button Seaside comes closer to Modeless interaction in that you can be partially along multiple paths at any time. So I do not like the word "Modal". It may be worth discussing what _really_ are the (architectural abstractions of the) end-user visible benefits of Seaside. There may be more than one answer, and picking a single word to capture them all might not be good. e.g. I think "composable multi-tier components", while a mouthful, captures one key benefit. You compose the UI panels and the middle-tier logic behind them. Re: continuations, it is worth spelling out the contexts where the Seaside usage is wonderful, and the contexts when it is not, and picking the marketing blurb that says "and hey, look how you can combine these at will". In fact, I think "composable multi-tier components" might capture these as well, if you stretch the dimensions of compositilon to include the temporal (interaction) dimension. Each (sub)component brings its own set of possible interaction traces, and the component has some nice composition of all these. With that kind of jargon I clearly need to give it a rest ... just my 4 cents p.s. Any chance of a "preview" button on blog/wiki/thingie?
Er, yuck
[David Farber] April 3, 2004 14:39:39.321
"Modal" isn't any better at capturing what I think is the main advantage of continutation based web frameworks: which is that when I code something using Seaside it is "Just Smalltalk". No coding in some frankenstein half-HTML/half-Java language soup. No slavish constriction to page-by-page generation of my application. I just code--bringing to bear all the power and flexibility of Smalltalk--and I let the framework take care of making it all HTTP friendly. State, I believe, is (almost) completely beside the point--it just happens to be the thing that continuation based web frameworks handle really well when everything else doesn't.
Continuations and Modality
[David Naseby] April 4, 2004 21:17:47.162
Continuation-based local applications claim to rid the user of the burden of modality (see Haystack). Continuation-based web-server applications bring the joy of modality to the consumer. Using modal is probably a bad idea, as a result of this disconnect.
Haystack
[Avi Bryant] April 5, 2004 0:06:19.690
Haystack is an interesting example; in a way, it's an attempt to bring web-style interactions to the desktop. Web users have always been able to ignore a "modal" dialog just by opening a new browser window or using the back button. Haystack does something similar for desktop users, but (I'm guessing) forces the developer to use a somewhat web-like event-driven programming style to achieve it. Seaside completes the circle by bringing a desktop modal programming style to the web. So it still seems to me that the notion of a modal interface is at the heart of things, we just might need to find a new way of talking about the kind of modality enabled by the browser.
Another name...
[James] April 8, 2004 18:31:45.233
Let me throw in another vote for "please not modal." I think a Borges reference is appropriate, so how about using "forking-path" somehow? Forking-path web development. Forking-path webapps. Not nearly as technical as continuation-based, but still evocative of the ability to clone a browser window and have both sessions keep working. Or to have a working back-button.