Re: About the Web Forms 2 proposal

Hi Maciej,

I think you missed the point about the declarative vs. imperative debate, 
and then got it later in the email, so I won't go into that.

Looking only at the forms that showed up as popular in your web survey is 
looking in the wrong place to find out how to solve forms problems because 
you're only looking at the things people know how to do easily as 
evidenced by the fact that they have done it often.  You will not find too 
many examples of the forms we would like for people to be able to build 
because they don't build them as often.  And they don't build them as 
often because it is too hard and they give up.

I can see an argument like yours being made to Henry Ford or Thomas 
Edison.  "Hi, everyone is traveling with horse drawn carriage and I don't 
see anyone driving around in a purely mechanical object so there must not 
be a need for an automobile" or "Hi, everyone seems to be reading using 
sunlight or torchlight; I don't see anyone trying to use glass, tungsten 
and an inert gas to read, so there must not be a need for a light bulb." 
It makes no sense!

Finally, it sounds like you don't have much experience trying to develop a 
larger, more complicated form when you claim that expressions only make 
things easier  in toy forms.  Have you ever tried to put an insurance or 
financial application online?  If you ever do, you will begin to 
understand why we want expressions.

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Maciej Stachowiak <mjs@apple.com> 
04/28/2007 05:04 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
Dave Raggett <dsr@w3.org>, Matthew Raymond <mattraymond@earthlink.net>, 
public-html@w3.org, public-html-request@w3.org, Sebastian Schnitzenbaumer 
<sebastian@dreamlab.net>
Subject
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