> Another situation I''m facing involves how to submit form data back to a > remote method without having to use the submit button. Or.. to submit to > a different method. Perhaps one way would be to implement a submit > button that rewrites the target of the form submission when clicked.You can submit a form using lots of methods, for example the onblur event on a form field, or directly from elsewhere in the page using document.formname.submit. The example of rewriting a form''s target seems a little obscure. I''m not quite understanding the context in which you''d want to do that. Wouldn''t it be easier to submit a form to a single controller that can handle all the permutations? In some ways, it sounds like you''re pushing Ajax farther than it''s really suited to go. I''d be wary of trying to ajax-update lots of parts of a page via an ajax operation. As a UI designer, that strikes me as something it would be acceptable to do in a normal page refresh, particularly since users might expect the Back button to step back to the previous state of the page.
> same controller, sure, but different actions. Button one adds the > address to a private list, button 2 adds it to a public list. So on > needs to submit to "/list/add_public/1" where the second button needs to > submit to: "/list/add_private/1" > > Ok, that''s a contrived example. A real world example is where I have an > admin form (actually a partial within a larger page) for credit card > info. I want one button to submit the form to save/update the info for > future use, and another button to simply submit the data for a one time > payment. I know one could have a select box or radio box collection to > accomplish that, but it really doesn''t flow the same within the ui.Just submit to the same action, and in that action determine how/what to do with the data, based on a choice made by the user, such as a selected radiubutton, or similarly. This is a more fail-safe approach (since a form can be submitted simply by hitting the enter-key as well (to god knows what action?)), and definately more user-friendly, given its predictability. Regards, Tomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Otwell wrote: |> Another situation I''m facing involves how to submit form data back to a |> remote method without having to use the submit button. Or.. to submit to |> a different method. Perhaps one way would be to implement a submit |> button that rewrites the target of the form submission when clicked. | | You can submit a form using lots of methods, for example the onblur | event on a form field, or directly from elsewhere in the page using | document.formname.submit. | | The example of rewriting a form''s target seems a little obscure. I''m not | quite understanding the context in which you''d want to do that. Wouldn''t | it be easier to submit a form to a single controller that can handle all | the permutations? same controller, sure, but different actions. Button one adds the address to a private list, button 2 adds it to a public list. So on needs to submit to "/list/add_public/1" where the second button needs to submit to: "/list/add_private/1" Ok, that''s a contrived example. A real world example is where I have an admin form (actually a partial within a larger page) for credit card info. I want one button to submit the form to save/update the info for future use, and another button to simply submit the data for a one time payment. I know one could have a select box or radio box collection to accomplish that, but it really doesn''t flow the same within the ui. | In some ways, it sounds like you''re pushing Ajax farther than it''s | really suited to go. I''d be wary of trying to ajax-update lots of parts | of a page via an ajax operation. As a UI designer, that strikes me as | something it would be acceptable to do in a normal page refresh, | particularly since users might expect the Back button to step back to | the previous state of the page. Yes, I''m pushing ajax farther. Farther than it''s suited to go? I don''t know, try asking google about that. I''m using ajax for a billing application - I don''t *want* the back button, as it would otherwise point to out of date information. The responses from the various ajax requests update the screen to show the current status, and the old status is no longer available. That''s a correct design for this app. - -- David Morton Maia Mailguard server side anti-spam/anti-virus solution: http://www.maiamailguard.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCUmm9SIxC85HZHLMRAoObAJ9JxAMyW28nGPBd5VjKnAkyk+V4ugCfSfRe D99RN+dgpYD0tS0sX0w/zzA=ECNY -----END PGP SIGNATURE-----
> I''m trying to make this into a real "application", not just a web page. > If we were discussing how to do this in VB using native win32 widgets > (eep!), then this would be accomplished with a button. No one would > think of having a select box to choose the action to take and then click > the one and only action button. That''s an extra click! > > This part is an admin interface, designed to be used by the billing > people. It needs to have a fast and intuitive workflow. I can control > what browsers will be used, and so I can depend on JS in the form. > > I''m not going to allow the web platform to dictate bad design to me. > I think the default action will be the submit button, and the other > buttons are just buttons. That makes the enter key do the right thing.What is so great design-wise about a form which can/will submit to different actions unbeknownst to the user? What is so bad design-wise about making user alternatives clearly obvious in the shape of *gasp* form options? Seems to me you might want to consider re-thinking the interface from scratch, but if you could show us a screenshot of your form we might be able to come with more applicable suggestions. Right now we can''t see anything at all, and thus it''s quite difficult, if not entirely impossible, to talk in anything other than very broad and generic terms. And, generally speaking, having a single form ambigously submit to different loctions is _bad_ design, both technically and from a user perspective. Tomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tomas Jogin wrote: |>Ok, that''s a contrived example. A real world example is where I have an |>admin form (actually a partial within a larger page) for credit card |>info. I want one button to submit the form to save/update the info for |>future use, and another button to simply submit the data for a one time |>payment. I know one could have a select box or radio box collection to |>accomplish that, but it really doesn''t flow the same within the ui. | | Just submit to the same action, and in that action determine how/what | to do with the data, based on a choice made by the user, such as a | selected radiubutton, or similarly. This is a more fail-safe approach | (since a form can be submitted simply by hitting the enter-key as well | (to god knows what action?)), and definately more user-friendly, given | its predictability. I''m trying to make this into a real "application", not just a web page. If we were discussing how to do this in VB using native win32 widgets (eep!), then this would be accomplished with a button. No one would think of having a select box to choose the action to take and then click the one and only action button. That''s an extra click! This part is an admin interface, designed to be used by the billing people. It needs to have a fast and intuitive workflow. I can control what browsers will be used, and so I can depend on JS in the form. I''m not going to allow the web platform to dictate bad design to me. I think the default action will be the submit button, and the other buttons are just buttons. That makes the enter key do the right thing. - -- David Morton Maia Mailguard server side anti-spam/anti-virus solution: http://www.maiamailguard.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCUsSgSIxC85HZHLMRAksyAJ9Iv1gs1k0HObO8svJjFZL4QjzCzgCgmwuB BCXxQRP6FntGuQgyNqa8xnw=hdd5 -----END PGP SIGNATURE-----
Tomas Jogin wrote:>>I''m trying to make this into a real "application", not just a web page. >>If we were discussing how to do this in VB using native win32 widgets >>(eep!), then this would be accomplished with a button. No one would >>think of having a select box to choose the action to take and then click >>the one and only action button. That''s an extra click! >> >>This part is an admin interface, designed to be used by the billing >>people. It needs to have a fast and intuitive workflow. I can control >>what browsers will be used, and so I can depend on JS in the form. >> >>I''m not going to allow the web platform to dictate bad design to me. >>I think the default action will be the submit button, and the other >>buttons are just buttons. That makes the enter key do the right thing. > > > What is so great design-wise about a form which can/will submit to > different actions unbeknownst to the user? What is so bad design-wise > about making user alternatives clearly obvious in the shape of *gasp* > form options?It would seem that the buttons would make the different actions clear. This makes complete sense to me, why are the different actions unknown to the user? I''m curious what type of experience you have in billing / financial batch processing type applications that you would require your users to use a select box or radio button to determine the action to take? Especially that you consider this bad design. As a point of reference I''m involved in processing loan payments, which has some similar factors to this inquiry. I know you like to *gasp*, but for folks grinding through things, they want to hit enter for default "submit" type options, and hit a button for the other various options (2-3 often). If you had a different experience in this type of enviroment I''m curious why the feeling is so strongly against it? - August
> It would seem that the buttons would make the different actions clear. This makes complete sense to me, why are the different actions unknown to the user?If the user submits the form by hitting the enter key (as opposed to clicking a button), he/she will have no idea what is going to happen. The user did not make a choice, and yet, unbeknownst to him/her, did.> I''m curious what type of experience you have in billing / financial batch processing type applications that you would require your users to use a select box or radio button to determine the action to take? Especially that you consider this bad design.The bad design is that a user is able to unknowingly make a choice, or that the app assumes the user made one, when he/she did not. If an unintentional choice was made, how obvious is it to the user afterwards that the wrong choice was made? And how can the user undo that choice? When the user is going to undo that choice, will he/she know what he/she unintentionally did wrong last time around?> As a point of reference I''m involved in processing loan payments, which has some similar factors to this inquiry. I know you like to *gasp*, but for folks grinding through things, they want to hit enter for default "submit" type options, and hit a button for the other various options (2-3 often). If you had a different experience in this type of enviroment I''m curious why the feeling is so strongly against it?Like I mentioned earlier, I cannot speak in other than the broadest terms, as I haven''t seen the interface in question. And, in broad terms, ambiguity is a bad thing. And again, in broad terms, if your interface sports ambiguity and unintentional choices, you might want to re-think it. Tomas
On Apr 6, 2005 12:50 AM, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > It would seem that the buttons would make the different actions clear. This makes complete sense to me, why are the different actions unknown to the user? > > If the user submits the form by hitting the enter key (as opposed to > clicking a button), he/she will have no idea what is going to happen. > The user did not make a choice, and yet, unbeknownst to him/her, did.Then pop up another dialog box to confirm the action.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Corey Lawson wrote: | On Apr 6, 2005 12:50 AM, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: |>>It would seem that the buttons would make the different actions clear. This makes complete sense to me, why are the different actions unknown to the user? |>If the user submits the form by hitting the enter key (as opposed to |>clicking a button), he/she will have no idea what is going to happen. |>The user did not make a choice, and yet, unbeknownst to him/her, did. | | Then pop up another dialog box to confirm the action. And good visual design will make the default choice clear anyway... - -- David Morton Maia Mailguard server side anti-spam/anti-virus solution: http://www.maiamailguard.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVElzSIxC85HZHLMRAnZ6AJ418vL/8Ly0SpZ/dwMW9XBmcDHoAQCePNnb 5M1eDv0jhYp6xPbSOYmP0I0=tX6T -----END PGP SIGNATURE-----