Re: About the Web Forms 2 proposal

On Apr 28, 2007, at 2:49 AM, Dave Raggett wrote:

> Please can you summarize the evidence for that extensive research  
> and effort, as I can't find it. I am hoping that this isn't just a  
> lack of will to thoroughly explore new ideas.

The fact that Ian tried and failed to come up with such a design  
doesn't mean you can't also try. Instead of demanding proof of Ian's  
efforts, I think it would be more productive to propose a specific  
design. Then respond to feedback until we either find a workable  
solution or give up on finding one that satisfies our design goals.

>>> A well defined expression language with a fixed set of predefined
>>> functions can certainly be made to work. Will you accept the
>>> challenge of working out how to make that fit with the rest of WF2?
>>
>>   If someone wants a feature, shouldn't they be arguing how the  
>> feature
>> can work rather than challenging others to make it work for them?
>
> I already have and failed to get a meaningful response to the  
> proposal for using a well defined expression language with a fixed  
> set of predefined functions.

You didn't provide the details of how it should work - you challenged  
Ian to figure out the details based on a one-sentence description.  
I'm sure he and the rest of the group would be happy to review and  
help you refine a fleshed-out proposal.

> I think this is perhaps more a matter that other people have yet to  
> realize the potential for lowering the development costs for  
> website owners and for enabling high level authoring tools for use  
> by people who aren't able to code JavaScript.

I think some are not convinced that these benefits would transpire by  
allowing some things to be coded in a restricted subset of  
JavaScript, using a topological sort and a "pull" model of linked  
control updates, as opposed to using event listeners, full  
JavaScript, and a "push" model.

It certainly doesn't seem obvious to me. Current web-based  
spreadsheets don't make any use of user-typed JavaScript expressions.  
I'm also at the receiving end of bugs and other feedback from Apple's  
developer channels, and while we've had all sorts of feature requests  
for web technology, declarative constraints in HTML form controls  
have not come up.

I'm not saying the benefits you cite definitely won't happen - maybe  
they will. But I'm personally more interested in pursuing proven high- 
demand features.

> There isn't any fundamental computer science problems to solve.  
> Spreadsheets after all are clearly practical and have been around  
> for nearly thirty years. I agree that we still need to specify the  
> detail of when expressions are evaluated relative to WF2 event  
> handlers, but that is clearly a matter of detail and not a  
> fundamental barrier.

Spreadsheets generally use a language purpose-designed for the  
spreadsheet, and where there isn't other code floating around  
changing the content. So it is a fair bit more complex.

>
>>> It is obviously tempting to identify relevancy with disabled, but
>>> that would be to miss an opportunity to support wizards such as you
>>> find on online ordering sites (including Apple's) where you are
>>> taken through a sequence of choices with material irrelevant to the
>>> current state hidden from view. For this we need to be able to
>>> hide fields but to do so in such a way that their values are still
>>> submitted as part of the form.
>>
>>   First of all, why would someone conclude that material not  
>> relevant would be submitted to the server? That's  
>> counterintuitive. Why would you waste bandwidth by submitting data  
>> that is irrelevant? It may not be stated explicitly in the XForms  
>> Transitional document that |relevant="false"| values are not  
>> submitted, but neither does it explicitly state the opposite.
>
> I trust you are open to new ideas. A use case is where say Jon  
> wants to buy a computer from examples.com. He goes to the website  
> and uses example.com's wizard. This presents him with a series of  
> choices, and as it does so, shows a summary of the system so far,  
> but hides the questions/input fields for all but the current  
> question as they are irrelevant for the purposes of posing the  
> current question. Relevancy is thus sensitive to the state of the  
> dialogue.
>
> Here is a concrete instance of this use case, go to the following  
> web page and click on iMac:
>
> http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore
>
> This offers the choice of 4 bundles. Pick the 2nd. This takes you  
> to a page to customize your Mac. You can now click on radio buttons  
> to change various options. The summary shown on the top right  
> changes dynamically as you do so.
>
> Now if you look at the page markup you see that it is rather  
> complex. It could be made a lot less so quite easily. Let's imagine  
> going through an exercise of redesigning the page. We keep the  
> summary but present the choices for processor, memory, hard drive,  
> modem, applications bundle, keyboard/mouse and warranty, as a  
> wizard. In otherwards, first show the choices available for  
> processor and hide the rest. The user clicks on a next button to go  
> to the next set of choices. This hides the choices for processor  
> and reveals the choices for memory, and so on.

The reason this page doesn't use a wizard-style interface isn't  
because it is hard to do. It's because Apple considers wizards to be  
bad human interface design. Especially in a case like this where you  
are making only 7 choices, which all affect your total price, it's  
better to see all the choices at once and manipulate them in any  
order than to be limited to a linear flow. So the whole premise of  
your example is flawed.

Note that the Apple ordering process does have cases where you follow  
multiple steps. You enter the shipping address and payment info on  
separate pages from these product choices. There's no problem  
implementing that in current web tech.

> This could of course be implemented directly in JavaScript, but  
> that is still complicated. We can reduce the need for most of the  
> script through declarative techniques. Essentially, add an  
> attribute to each section that indicates when the section is  
> relevant to the dialogue. A simple numerical or named state will  
> suffice.

Or you could use this: http://www.whatwg.org/specs/web-apps/current- 
work/#the-irrelevant

All sections but the current one can be marked irrelevant. Then  
previous and next buttons can use a trivial amount of script to  
change the current relevant section.

> The previous/next buttons for the wizard would be represented as  
> buttons with the corresponding types (e.g. type="next"). On  
> existing or older browsers this would have the effect of submitting  
> the form, whereupon the server could do the work of sending an  
> updated page, even if scripting is disabled.

With the approach I suggested, the fallback behavior in older  
browsers would be the same as the fully supported behavior if the  
author adds <style>[irrelevant] { display: none; }</style> to the  
<head> section. That seems like easier authoring and a better user  
experience than hitting the server.

If you care about UAs with no scripting support, then an additional  
server-based fallback can be added.

But like I said, wizards are usually a poor user experience, in the  
opinion of Apple's interface design experts.

> (note that the Apple page hasn't been designed to allow the user to  
> update the summary when scripting is disabled).

Did you try visiting the page with scripting disabled? I tried, and  
when I do so, I see an "Update Details" button labeled with the  
instructions 'Click "Update Details" to reflect changes to system  
price and shipping'. This button is hidden when script is enabled.

> On new browsers that support the wizard markup, the buttons update  
> the wizard dialogue state using the name and value attributes on  
> the buttons, i.e. the form's object model is updated to set value  
> on the corresponding name. This can then be tested for by the  
> expressions given as the value of the relevant attributes on markup  
> for each section and also on the summary. The subtotal is express  
> declaratively as an expression that sums over the prices for each  
> of the choices. This is where we can use a declarative mapping from  
> teh choice of say processor to a price. For radio buttons and check  
> boxes etc. this could be represented as an attribute on the field,  
> and "price" comes to mind as a possible name. However a more  
> general solution would be desirable, e.g. for use with text fields.  
> JavaScript associative arrays offer one possible solution, or we  
> could introduce some new markup for the purpose.

I don't think we should encourage users to add nonstandard attributes  
like "price", nor do I think "price" is general-purpose enough to  
become a standard attribute. Maybe I'm missing what you mean.

> This examples that simple declarative markup can replace a lot of  
> costly and hard to maintain script. This might not be of concern to  
> browser vendors as they don't bear the cost, but should be of  
> concern to website owners who do bear the cost.
>
> Does the HTML WG have any responsibility to website owners? I  
> presume (and it is a rhetorical question) that the answer is  
> clearly yes!  HTML standards need to satisfy multiple stakeholders  
> and not just browsers vendors, althrough they are clearly very  
> important.

I work for the company that operates the web site you mentioned, and  
a couple of other popular sites (apple.com is a PageRank 10 site and  
#30 in the Alexa US rankings). As part of my job, I talk to the  
developers of these sites regularly. It is my intent to advocate for  
things they need that are not covered by current web standards.

I haven't heard any requests for declarative scripting. Indeed, my  
impression that declarative scripting would not solve any of the  
problems they have brought up to my team. In fact, in many cases they  
use imperative scripting even in cases where a declarative  
alternative exists today, perhaps because an imperative model is  
easier for them to understand. Specifically, on the page you cited,  
the hover effects on the radio buttons are done with script rather  
than with :hover styles.

In conclusion, based on my experience working with web developers at  
Apple and elsewhere, I see no evidence of your claim that delcarative  
features are important to website owners. I will admit I could just  
be talking to the wrong website owners, but I have talked to the ones  
you cited specifically.

Regards,
Maciej

Received on Saturday, 28 April 2007 11:05:57 UTC