Re: About the Web Forms 2 proposal

Hi John,

On Apr 28, 2007, at 12:51 PM, John Boyer wrote:

> Hi Maciej,
>
> We really do need to get past this declarative versus imperative  
> debate because in no way does XForms impose on a form author to use  
> strictly declarative expressions, nor even does it impose on a form  
> author to use declarative expressions at all.

I'm not the one who made it a declarative vs imperative debate - both  
Dave Raggett and Sebastian said that declarative expressions are  
essential.

> XForms not only has a well defined imperative mechanism whose  
> "scripts" can be invoked by events, but it also includes hooks that  
> allow *javascript* to manipulate the XForms data.

Great. HTML Forms have this feature too, and have had it for a long  
time. So it sounds like on this point, there is already architectural  
consistency.

> The declarative expressions are intended to make calculation of  
> values and certain key properties easier to maintain, but the form  
> author is welcome not to use them if he feels uncomfortable with  
> the concept.  Yet, the second killer app of computing is the  
> spreadsheet precisely because it transferred computing power from  
> the computing specialist to the domain specialist, so there is  
> plenty of precedent to suggest that declarative expressions are in  
> fact of significant value in real situations.

So it sounds like declarative expressions are the key remaining  
difference in architecture between XForms and HTML Forms. Given this,  
I think it was reasonable for Dave R. and Sebastian to focus on that  
point.

> Even in a toy form, it is easy to see where the benefit lies.  Say  
> I have a form that takes two inputs and shows their sum or  
> product.  The author can write one formula that is always imposed,  
> or he can write two value change event handlers, one on each input  
> control, to recompute the result.  As the complexity of the  
> computing requirements increase, the benefits become more  
> pronounced.  Bottom line, when something is a business rule, then  
> express it as a rule not as a block of script attached to event  
> handlers for all the places that the rule could possibly cause a  
> change for the end-user.

My concern is that it's *only* possible to see the benefit in a toy  
form. For the forms I have seen actually deployed on the web,  
spreadsheet-style calculations are not that common.

> It is easy to see this in action with a simple example, the  
> ubiquitous "shopping cart".  Every item in the cart is represented  
> by row of UI controls to allow the user to express the thing they  
> want to buy, and the cost of each of those things is represented in  
> that row as well.  Cummulative results like the subtotal, taxes and  
> grand total must also be calculated.  Now suppose a user wants to  
> delete an item.  In XForms you could just say one command to delete  
> the data element representing the shopping cart item because the  
> declarative constructs will then automatically remove the UI  
> controls for presenting the data and adjust the cumulative results  
> since a deleted item no longer contributes to the subtotal, tax and  
> total.

Fair enough, although I think writing this with a single update()  
function in JS is not so hard either.

> And again, when you escalate from small examples like a shopping  
> cart to the full breadth and depth of what people are increasingly  
> trying to do on the web, the benefits of the hybrid approach become  
> ever more pronounced.

Here's some of the most common types of forms I see on the web. In  
addition to personal experience, I drew on sites from the Alexa top  
traffic list, the list of Google PageRank 10 sites, and a sampling of  
hot new startups mentioned recently on TechCrunch.

- plain old search box
- login
- registration for an account
- post a comment, blog entry or forum post
- shopping cart
- make a purchase or payment (enter billing / shipping info)
- reserve something for a period of time (hotel room, rental car,  
airline tickets)
- compose a mail message
- record a calendar appointment
- enter a description of yourself for a profile (social network,  
jobs, personals)
- upload some pictures or a video
- provide info to be allowed to download a piece of software
- request a stock quote
- request a map or driving directions
- specialized search with extra fields (jobs, classifieds,  
restaurants, movie times, personals, classified ads)
- add tags or keywords
- submit a link for social bookmarking / news aggregation
- select region (state, country continent) from a list
- send a chat / IM message
- fill in a form to create a specialized piece of online content  
(party invite, auction item, list of favorite things)

I'd love to make it easier to author these kinds of forms, and to  
make them work better for users. But in complete honesty, it seems  
spreadsheet-style calculations would not be at all helpful to most of  
these kinds of forms, other than the shopping cart.  And I don't see  
this changing - these days, computing on the web is about people,  
information, media and commerce; it's not usually about numbers.

I'm interested in looking at simpler forms features that can improve  
more of the popular use cases.

Regards,
Maciej

Received on Sunday, 29 April 2007 00:04:49 UTC