Coding and Design Advice

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hello:

I'm seeking some objective advice on designing and coding a registration form. I'm not asking anyone to write any code. If I have coding issues, at that time, I will submit another question.

Here is some background info. I've been hired to redesign a website. There are two registration forms that allows a person to register and pay online.

There are three methods of payment:
a. bill to member account
b. pay at time of event
c. pay by credit card via PayPal.

The current form has the person entering their member info and selecing their event. First, the person has to decide whether they are choosing payment method a or b. Then, they click the submit button. After clicking submit, for those who want to pay by credit card, they have to hit the back button and select the credit card option and click the buy now button. Personally, I think it's a poor design.

I've come up with two options of redesigning this form but I'm not sure if it is efficient or whether it too is bad design. That's why I'm here. I would like to run my options by you and get any advice. Maybe someone, with their more experience with Perl, can suggest other alternatives.

Option 1:

The person would complete all the form information. If they select payment option a or b, the script will send a confirmation email to the person and then send the registration to the club. If the person selects payment option c, the script will open a new page where they can select the event they want and click an Add to Cart button, then can click the Checkout button and it will send them to PayPal to complete the transaction.

Option 2:

The person would first select the method of payment. If option a or b, a new page opens, they complete the form, and confirmation is sent to everyone involved. If person selects option c, a new page opens, they complete the form, select the event to register, click a button and it will take them to PayPal for processing.

You can visit the following URL to see the current design: http://www.bridgemilltennis.com/PAGES/campreg.html.

If either of my options are poor, does anyone have other ideas?

Thank you in advance.

Comment on Coding and Design Advice

Replies are listed 'Best First'.
Re: Coding and Design Advice by Zaxo (Archbishop) on Mar 31, 2005 at 13:08 UTC
Don't they need to select an event with payment plans a and b, too? After Compline, Zaxo	[reply]
Re^2: Coding and Design Advice by b310 (Scribe) on Mar 31, 2005 at 13:20 UTC
Hello: Yes, everyone needs to select an event regardless of their payment method. That's the problem. I need to design the form and write the script in a way so that those who select plans a and b are not sent to PayPal. Only those who select plan c would go to PayPal. I'm having a tough time figuring out a design which will allow me to accomplish this. Any thoughts?	[reply]
Re^3: Coding and Design Advice by tlm (Prior) on Mar 31, 2005 at 13:33 UTC
With the CGI module, you'd just check the value of the payment_mode param (or whatever you want to call it) and generate the appropriate response accordingly. the lowliest monk	[reply]
Re: Coding and Design Advice by g0n (Priest) on Mar 31, 2005 at 13:24 UTC
Its a bit subjective, but I prefer option 1 - asking for payment before giving the option to choose your 'product' seems a bit off putting to me. Alternatively, how about a first form with all the event information, on which they select their event, then clicking submit takes them to a second page for all three payment options. If they choose paypal it takes them to paypal from page 2, otherwise it sends the emails and says thanks? And yes, I had a look at the URL you posted, and it does look like a rather unfriendly way to select payment at the moment. g0n, backpropagated monk	[reply]
Re^2: Coding and Design Advice by Anonymous Monk on Mar 31, 2005 at 17:25 UTC
Hello: Thank you for the reply. I like your alternative approach. I actually thought about this option as well. As I was thinking about it, I thought I might run into a bit of a problem with PayPal. On the first form, the user would fill out all the event information. They will click submit and takes them to a second form where they select the payment option. I set all the parameters for event charge to this button. When the user clicks the PayPal button, it will link them directly to PayPal and PayPal will take care of the rest. My question: In my script, if a person chooses the PayPal route, is it possible to include the PayPal button that I create (as mentioned above)? This button will have a direct link to PayPal. Will the script actually direct me to PayPal? I thought that I had to do the PayPal transaction outside the Perl script. Thank you for your time.	[reply]
Re^3: Coding and Design Advice by g0n (Priest) on Apr 01, 2005 at 10:55 UTC
I had in mind the following logic: 1) user selects the event, enters their personal details etc, then clicks on submit 2) 2nd form appears, with a radio button group for payment type. User selects their payment method and enters a membership number if appropriate, then clicks submit. 3) Your script checks the value of the radio button group. If its paypal, it issues a http redirect to paypal, or displays a 'now being redirected to paypal' page then redirects to paypal, and sends the confirmation of booking emails. Otherwise, it sends the confirmation emails and displays a 'thank you' type page. You could also look at opening a new window to redirect to paypal, and displaying the 'thank you' in the main window, although these days a lot of browsers will refuse a popup. By 'do the paypal transaction outside the perl script' I take it you mean that you can't gather the users paypal account information in your own form and handle the paypal transaction yourself? I think you're right, the user has to interact with paypal themselves, although I don't know this for certain. Using this process, you only need a single submit button, rather than a submit for two of the payment types, and a separate paypal button (as long as there's nothing else forcing you to create a separate button). g0n, backpropagated monk	[reply]
Re^4: Coding and Design Advice by b310 (Scribe) on Apr 01, 2005 at 11:34 UTC
Re^5: Coding and Design Advice by g0n (Priest) on Apr 01, 2005 at 11:43 UTC
Some notes below your chosen depth have not been shown here
Re^4: Coding and Design Advice by Anonymous Monk on Apr 01, 2005 at 11:38 UTC
Re^4: Coding and Design Advice by Anonymous Monk on Apr 01, 2005 at 11:40 UTC
Re: Coding and Design Advice by tlm (Prior) on Mar 31, 2005 at 13:22 UTC
Do you need the same info from the user regardless of their chosen mode of payment? If so, I'd go with Option 1 (although I don't understand why in this option the choice of the desired event does not happen on the first page, and is uniform for all users). If, on the other hand, the information you need from the user varies depending on how they want to pay (e.g. do you need their postal address if they pay with PayPal?), Option 2 makes more sense to me. the lowliest monk	[reply]
Re: Coding and Design Advice by johndageek (Hermit) on Mar 31, 2005 at 13:53 UTC
Could the user fill out their member info, go to a shopping cart to select the event, click check-out, then select a payment method? This allows the user to make their selection prior to selecting a payment method and it still allows you to route information appropriately. Enjoy! Dageek	[reply]
Re: Coding and Design Advice by thekestrel (Friar) on Mar 31, 2005 at 17:16 UTC
Hi, How about having the form have fields for all of the information and depending on what they select as the payment method, the fields that are not required are grayed out. Then upon submission which is the same for every type is routes to paypal as needed etc. Regards Paul.	[reply]
Re^2: Coding and Design Advice by Anonymous Monk on Mar 31, 2005 at 17:27 UTC
Hi, Thank you for your reply. I started to follow your idea. I got lost when you mentioned graying out fields not required. I'm not sure what you mean by that?	[reply]
Re^3: Coding and Design Advice by thekestrel (Friar) on Apr 01, 2005 at 00:52 UTC
Hi, I meant that depending on the selection, you grey out the some of the sections/options where you could put information. Here is an example of Greying out I found here <html> <head> <title>Disable Drop Down</title> <script type = "text/javascript"> function disableDrop(){ if(frmMain.sltMain.options[0].selected){ frmMain.sltSecondary.disabled = true; } else{ frmMain.sltSecondary.disabled = false; } } </script> </head> <body> <form ID = "frmMain"> <select ID = "sltMain" onchange = "disableDrop();"> <option value = "onetime">One-Time</option> <option value = "recurring" selected>Recurring</option> </select> <select ID = "sltSecondary"> <option value = "1">One</option> <option value = "2">Two</option> <option value = "3">Three</option> <option value = "4">Four</option> </select> </form> </body> </html> [download] Yes I know it uses Javascript, but just to show you. So applying this sort of thing to your method you might have. Name:__________________________________ Address:_______________________________ Method of Payment: (*) Tape Cheque to a pigeon ( ) Pay by C/C ( ) Use Paypal --------------------------------- Pigeon Payment Section Name of pigeon provider:________________ Number of pigeon's:_____________________ --------------------------------- Pay by C/C Section C/C Number: ____________________________ exp date: ______________________________ funky 4 digit number: __________________ --------------------------------- Pay pal section Paypal number____________________________ paypal pass:_____________________________ --------------------------------- So when you select pigeon payment option from the radio box, you can't even fill in the details of the other sections and the same for the other sections and you can obviously keep common information for each like name or username or something at the top as they are common to all. Hope this is useful... Regards Paul	[reply] [d/l]