Re: About the Web Forms 2 proposal

On Apr 29, 2007, at 10:46 AM, Doug Schepers wrote:

>
> Maciej Stachowiak wrote:
>> On Apr 28, 2007, at 9:03 PM, Doug Schepers wrote:
>>> John Boyer wrote:
>>>> And the use cases you listed here (
>>>> http://esw.w3.org/topic/HTML/FormsUseCases) are pretty trivial.
>>>
>>> On the one hand, I agree that this list isn't really  
>>> comprehensive. When you consider some many Web applications use  
>>> hoop-jumping libraries to supply multiple dialogs and numerous  
>>> inputs, there is clearly a desire to have more complex forms than  
>>> are addressed by this list of use cases.
>> I'd love to hear examples, especially if you can cite multiple  
>> sites doing the same sort of thing.
>
> Well, I didn't keep notes on where I've seen such things, but I  
> suspect that a survey of sites using dojo and Prototype would turn  
> up quite a few.

I've looked at a lot of sites using dojo and prototype. In my  
experience, their complexity rarely lies in form logic. Mostly it is  
in fancy dynamic layouts and general application logic.

>> That's a good point. Tax forms are pretty complex. But even here,  
>> I'm not sure declarative client-side features would help much.
>
> I think that in the problem case I mentioned, with the "worksheet",  
> had they had a simple way to set up a calculation and dependency  
> matrix (which is where a declarative solution shines), it would  
> have worked out better.  We could ensure that by taking such use  
> cases into account when designing the language.

That doesn't seem obvious to me, but I don't know the details of the  
scenario.

>> For security and data integrity reasons, you really need to  
>> checkpoint the data to the server often, time out the login  
>> session after some period of inactivity, and verify all the  
>> important calculations server-side.
>
> They could have done that with existing technologies, and no doubt  
> they tried, but it still came up short.

They do use existing technologies -- in what way do you think they  
came up short? I used turbotax online to do my taxes this year and it  
seemed like a pretty good experience, at least as much as doing your  
taxes can be. I think they do all the things I mentioned above. Your  
worksheet problem sounds like just a case they didn't think of.

>   It would be interesting to talk to them (and other large site  
> that use complex forms) to see what challenges they faced and how  
> we could have improved their development experience (whether  
> declaratively or not).

I'd like to talk to the sites with the everyday sorts of forms first,  
since those appear to be far more common.

>> Maybe we can think of features to improve tax forms. But let's  
>> keep in mind that this is a form most people fill in once a year,  
>> as opposed to the kind they fill in multiple times a day. I do  
>> realize there are exceptions for specific business domains, but I  
>> think specialized
> > problems can be solved by specialized solutions.
>
> The tax form was just one example.  There are lots of similar  
> things that could be brought online, especially for government  
> services or regulated industries (construction, contract bidding,  
> legal disclosures, etc.).  Like I said, PDF has quite a niche  
> there, and I'm personally uncomfortable with government documents  
> being in a proprietary format.

My understanding is that PDF forms use JavaScript, not declarative  
constructs, for all their logic. Furthermore, I'm told PDF forms are  
used instead of HTML because they give better formatting control, and  
for government use especially there are often specific requirements  
on how the form should look. To aim for this niche we would need  
better control over printed output.

> I'm not sure if you consider intranets as a target audience, but  
> you should, and these large forms that see frequent repetitive use  
> are more common there.

I think intranet use is an interesting secondary use case, but any  
feature that is only interesting for internal business use is  
dubious. Because these are controlled envioronments, interoperability  
is less important, and use of specialized technologies is acceptable.

> I don't think PDF is a specialized solution (I think it's very  
> general, in fact), nor do I think these are specialized problems.   
> I'm not proposing that HTML become a PDF-killer, but there is a  
> demonstrated need that goes beyond the simplest use cases.  Maybe  
> it should be solved by some other language than HTML.  I don't  
> know.  But unless it's implemented natively in browsers, I don't  
> think it has much chance to be adopted.

I don't think we can address the precise printed output of PDF by  
adding declarative expression features that PDF lacks.

> Flash and PDF only win out as plugins because of huge marketing  
> dollars and concerted effort by a single vendor who *needs* that  
> buy-in. Open-standards browsers don't really have the same type of  
> pressures, nor are they selling the same products.  I can't think  
> of a single open-standard technology implemented only as a plugin  
> (SVG included) that could be said to be an unqualified success.

There aren't that many technologies implemented only as a plugin that  
are an unqualified success, open standard or not. But I'm also not  
sure what you count as an open standard. PDF (implemented via the  
Acrobat plugin) and MPEG-4 (implemented via the QuickTime plugin) are  
both pretty successful and are open standards, although not W3C  
standards. Furthermore, many script libraries see huge success (such  
as the dojo and prototype you mentioned).

>   Thus, I don't think your demand-reflects-desire stance is  
> entirely accurate.  Large companies are typically conservative in  
> the technologies they will use (even if they are interested); if  
> it's not native in the major browsers, they are very reluctant to  
> use it (unless they have a stake in it). This applies to SVG, and  
> I'm sure it applies to these more advanced forms features.

In my experience, intranet sites are much more willing than public  
web sites to use specialized plugins, advanced features only in the  
newest versions of browsers or only in a single browser, and even  
quite complex JavaScript application frameworks. For middleware  
applications catering to such uses, the burden is much more on Apple  
as a browser vendor to support the features they demand in order to  
be supported than for public web sites.

Regards,
Maciej

Received on Sunday, 29 April 2007 23:18:26 UTC