[Javascript] Dirty Button

[tedd]

>At 1/25/2009 12:37 PM, Claude Schneegans wrote:
>>Solution looks fine, but where is the problem?
>>Why do you need to show the user what he selected?
>>If you really need it, just update the "You Selected" innerHTML on 
>>a onchange event.
>
>
>I assume that Tedd's fundamental goal was to ensure (without using 
>XMLHttpRequest) a match between the client-side display and the 
>server-side data, as set by the previous submit, not simply to 
>duplicate the form control settings in the client-side display.
>
>At the risk of being overly obvious, though, I'll point out that the 
>principal problem Tedd is trying to solve exists only when the input 
>form and the calculated result of form submission coexist on the 
>same page.  Another model for the user interface, in which the form 
>and its result each resides on its own page, bypasses this problem 
>completely.  For instance, the results page might have a 'run again' 
>link or button to return to the form which is always populated by 
>the current server-side data.  What such a two-page model may lack 
>in sexiness it certainly makes up for in unambiguous clarity and a 
>guaranteed match between form state and stored data.
>
>>At 1:23 PM -0500 1/25/09, Gene Berger wrote:
>>>I like the concept!  The only thing is that if the EU clicks one of the
>>>dropdowns but does NOT change the selection, the color of the buttons still
>>>changes.  Perhaps if the selection doesn't change the color of the button
>>>shouldn't change.
>
>At 1/25/2009 11:03 AM, tedd wrote:
>>I thought about that as well, but I wanted to keep the solution 
>>simple. I'll give that some thought though.
>
>At 1/25/2009 01:32 PM, Matt Warden wrote:
>>It doesn't seem to work if you use the keyboard to alter the select
>>values rather than the mouse.
>
>Tedd, these criticisms are radical.  To create a signal that the 
>value has changed and allow it to indicate a situation in which the 
>value hasn't changed, or fail to signal an actual change, means that 
>you haven't finished writing it.  Misleading assistance is worse 
>than no assistance at all.
>
>It would be simple enough to download the form with the current 
>value duplicated -- say as an element in the control's own class -- 
>so that your algorithm can know when it's truly dirty and when it's 
>not.
>
>Regards,
>
>Paul


Paul:

I believe you truly understand the problem and I appreciate your input.

The cursory solution is to update the display as the user changes the 
controls on-the-fly. However, in some cases (as the one I'm currently 
working on) doing so will probably confuse the user more than help.

In some case, the user needs to set all the controls to what they 
want and then calculate the results. Intermediate steps can produce 
confusing and/or nonsensical data.

For example, I'm working with a display that will allow a student to 
pick the course they want, what times they want to take the course, 
what location they want to attend the course, and what tutor they 
want to teach the course. Going from one scenario to another (i.e., 
setting all the controls to different values) may not produce 
meaningful data within the intermediate steps.

I'm not sure what is the optimum solution here and thus the reason 
for my post. I'm still undecided, but I'm favoring the dirty button 
solution.

Thanks,

tedd


-- 
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com