Damien,
About #1 - When I build e-commerce sites I generally store benign
data about a visitor immediately in the database, and then insert
payment data at the end of the process when the user confirms. I
normalize the tables even for temporary storage to reduce
manipulation of the data for permanent storage.
Because I store data immediately, I've been able to generate reports
for my clients that show conversion rates - how many users start the
process but don't finish with a purchase? Is there a consistent place
where users bail out of the purchase? Can that point in the process
be changed to increase completion rates? This can give you a really
good sense of what direction to take as you're designing the purchase
form interface.
HTH,
Darcey
At 07:26 AM 7/7/2006, you wrote:
(originally sent to the MG list but it really should be here)
I'm attempting to redesign a form from a rather messy FB3 app into MG:U.
The current form is a 9 page monster that compiles data in the
session scope and at the end passes the (non-XML) data to a remote
application, then displays the receipt based on the results - I don't
actually manually store any data entered for long-term use, the real
work is done by the remote app. Though the current application is
written in FB3 it all runs from one fuseaction and decides what to do
based on both form variables and the current status.
The new form is going to start off with a static page (page 1) asking
if you want to take route 1, 2 or 3. Regardless of which route is
selected on page 1 the visitor will be then taken to a country
selector (page 2), but I'm also debating on whether this should be
merged into page 1. Anyway, from there the visitor will go to the
main form (page 3) which displays a series of options based on
whether they wanted route 1, 2 or 3 - there'll be a number of common
elements but each route adds additional options to the list. From
there it will go to a page to do some initial data validation (lots
of logic and some cfhttp queries) then either jump back to the form
(page 3) to display any errors or display (page 4) a confirmation
page. On page 4 they could either click Modify to go back and change
their order or click Continue to have their order processed via the
remote API. Lastly, once the API is finished the receipt page (page
5) would be displayed and a receipt email would be dispatched.
In my attempt to redesign it as an MG:U app I'm rediscovering older
issues that led me to the current disastrous design in the first place:
1. Data storage: I wrote the old application to store the client data
in the session scope but I'm starting to think I should temporarily
store the data in the database instead. There is a *lot* of data and
it could be broken down into a number of classes to structure it all
nicely. Given that almost all of the fields will be used by each
visitor (and there will be confidential information in parts inc SSN,
payment details, etc) should I keep it as one large table or
normalize it? What have others done for this?
2. Data normalization: Stemming from #1, any suggestions on how much
I should normalize the CFCs? I'm figuring it will all stem from a
Visitor class which would have an associated Order class, but would
there be enough benefit to e.g. splitting off to do an Address
class. Also, to keep it nice and clean where should I put the
validation code, in the model CFCs or the controller - I'm guessing
they'd be part of the model and the controller would call them, correct?
3. Flow control: I personally hate it when you are going through a
form, type in something it doesn't like and are given an error
message on the *subsequent* page, the old "you had an error, go back
and fix it" routine, rather than on the page the errors were on. The
problem with splitting it up into several fuseactions was that if on
page 1 I set the xfa to page 2 it would be messy to jump back to page
1 to display the error messages, especially when I was storing all
data in the session as you can't write data to the session if you are
doing a cflocate jump. I'm thinking the MVC approach and IoC / II
could help with this, but in practical terms how should I structure it?
UPDATE: the <results> tag should do what I need for this.
Any advice on for an OO n00b would be much appreciated.
Oh, and I'm giving myself until the end of the month to do this
(working around a few days of vacation) so I don't have time to read
& understand five books. I should, though, have plenty time given
that I've got the page designs already done in HTML, have most of the
data validation UDFs from the old app and the business logic just
needs to be transposed rather than written from scratch.
Thanks.
--
Damien McKenna - Web Developer - [EMAIL PROTECTED]
The Limu Company - http://www.thelimucompany.com/ - 407-804-1014
#include <stdjoke.h>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the
subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
Darcey Spears
Q3Studios Collaborative Web Development
www.q3studios.com
520-360-5425
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
