[FX.php List] [OFF] Those Whacky End Users
Jonathan Schwartz
jschwartz at exit445.com
Wed Nov 28 13:10:49 MST 2007
Hmmm...
I'm not sure about making the switch. I probably need to get a
couple more years of experience under my belt to offer definitive
opinions, but I would say that the nature of the client and data
collection helps determine which method to use.
For your survey's, your client is probably hungry for data...even if
it is not 100% complete data. Survey takers tend to drop off before
the end...I know that I do. By writing the record at the outset,
you are assured of having SOME data, even if users prematurely depart.
On the other hand, when orders are to be taken, users are motivated
to finish the process and get the reassuring "Order Confirmed" page.
I doubt that many online order systems (Amazon, ebay, any airline,
etc) writes the record before the sale is complete. Perhaps I am
wrong about that.
For my initial inquiry, I will just need to me more mindful of how to
properly handle navigation to pages in my solution.
J
At 1:52 PM -0600 11/28/07, Bob Patin wrote:
>Jonathan,
>
>Maybe you should just write after each page... it would certainly
>get rid of the problem you're having.
>
>I'm working right now on a 90-100-question survey web app, and I'm
>going to write after each page. I know it involves more hits to the
>DB, but I think it'll keep things simpler overall...
>
>But that's just me, I get stuck in my method "ruts." :)
>
>Bob Patin
>Longterm Solutions
>bob at longtermsolutions.com
>615-333-6858
>http://www.longtermsolutions.com
>Member of FileMaker Business Alliance and FileMaker TechNet
>
> CONTACT US VIA INSTANT MESSAGING:
> AIM or iChat: longterm1954
> Yahoo: longterm_solutions
> MSN: tech at longtermsolutions.com
> ICQ: 159333060
>
>--------------------------
>Contact us for FileMaker hosting for all versions of FileMaker
>PHP * CDML * Full email services * Free DNS hosting * Colocation * Consulting
>
>On Nov 28, 2007, at 1:42 PM, Jonathan Schwartz wrote:
>
>>I forgot to mention something.
>>
>>In a 10 page process, I'm only hitting the database twice. Once to
>>load the original record (if applicable) and once to create a new
>>record based on the new info collected from the "interview". all
>>the rest of the pages are handled in a session. I did this to save
>>bandwidth/traffic to the DB.
>>
>>Perhaps that's why I can't just ask the database for the status.
>>it doesn't know until the end of the interview process. In between
>>the first and last screens, only the session knows the status.
>>
>>That's why I am struggling to manage the various conditions that
>>might exist at any point.
>>
>>I just need to bone up on the whole subject of managing sessions, I suppose.
>>
>>J
>>
>>At 11:25 AM -0800 11/28/07, Joel Shapiro wrote:
>>>Hi Jonathan
>>>
>>>Is there some kind of check that you can do on each submit before
>>>processing, e.g. if this family already has a record, don't allow
>>>a new record except through your intended process (and then take
>>>the misguided user automatically to the appropriate page)
>>>
>>>HTH,
>>>-Joel
>>>
>>>
>>>On Nov 28, 2007, at 8:43 AM, Jonathan Schwartz wrote:
>>>
>>>>Bob, Dan,
>>>>
>>>>As I add features to my processes, the number of allowable
>>>>navigation options goes up. Along with it goes the need to
>>>>allow/restrict the desired navigation. I'm willing to rethink
>>>>the entire approach of "session_handling".
>>>>
>>>>Perhaps we need to clarify the term session and session handling.
>>>>Is it OK to uses these terms to describe the "page-to=page
>>>>process" we've designed? Or, are these terms reserved for
>>>>referring to Apache and PHP "Sessions"?
>>>>
>>>>Anyway, the number ways that a user can "properly" access a page "
>>>> - Normal progression through interview process
>>>> - Back button
>>>> - Custom Navigation bar
>>>>
>>>>Improper access:
>>>> - Back button after the interview process has been completed
>>>> - Back button after the interview process has been completed
>>>> - Navigation bar after the interview process has been completed.
>>>> - Bookmarked access
>>>> - Referral link from former "session"
>>>> - User experimenting with URLs
>>>> - Bots
>>>> Add to that: users who have not officially completed their
>>>>process, but are starting another.
>>>>
>>>>So, in my eyes, there's nothing simple about accounting for all
>>>>these possibilities(realities).
>>>>
>>>>FYI, I employ an FMP log.fp7 file that writes out a record for
>>>>every screen access in the interview process. It writes out field
>>>>validation errors and everythng. I end up with a single
>>>>registration record, but 25-50 log records documenting the path
>>>>the user took to finish the process. By monitorng the log file
>>>>in real time, I am constantly amazed that while one user can
>>>>breeze through the interview process in under 4 minutes, some
>>>>users take 3 -4 times that time, hitting every validation error
>>>>in the book.
>>>>Others walk back thru the process several times before
>>>>committing. I swear that there is enough data in these logs to
>>>>write a graduate thesis on human behavior. ;-)
>>>>
>>>>Jonathan
>>>>
>>>>
>>>>At 9:37 AM -0600 11/28/07, Bob Patin wrote:
>>>>>Jonathan,
>>>>>
>>>>>Couldn't you just write to a field when the interview process is
>>>>>complete, thereby making the record uneditable? I'd probably
>>>>>create a field and use a boolean to tell the system whether this
>>>>>is an "open" record or a completed one.
>>>>>
>>>>>Then you don't really need to rely on session variables for this
>>>>>particular problem... or am I missing something here?
>>>>>
>>>>>Best,
>>>>>
>>>>>Bob Patin
>>>>>Longterm Solutions
>>>>>bob at longtermsolutions.com
>>>>>615-333-6858
>>>>>http://www.longtermsolutions.com
>>>>>Member of FileMaker Business Alliance and FileMaker TechNet
>>>>>
>>>>> CONTACT US VIA INSTANT MESSAGING:
>>>>> AIM or iChat: longterm1954
>>>>> Yahoo: longterm_solutions
>>>>> MSN: tech at longtermsolutions.com
>>>>> ICQ: 159333060
>>>>>
>>>>>--------------------------
>>>>>Contact us for FileMaker hosting for all versions of FileMaker
>>>>>PHP * CDML * Full email services * Free DNS hosting * Colocation
>>>>>* Consulting
>>>>>
>>>>>On Nov 28, 2007, at 9:15 AM, Jonathan Schwartz wrote:
>>>>>
>>>>>>There seems to be no end to the variations on how end users can
>>>>>>get "creative" to circumvent the "perfect" systems we design.
>>>>>>I'm looking for some perspective on how to handle them.
>>>>>>
>>>>>>In a current project, I have an "interview" process where end
>>>>>>users will complete the process once, but sometimes they need
>>>>>>to do it twice (or more) for additional household members. End
>>>>>>users LOVE the feature, saving them time in retyping common
>>>>>>information. At the end of the process, they are given an
>>>>>>option to end or loop back and repeat the process. Based on
>>>>>>this choice, I accommodate both choices by either ending the
>>>>>>session or continuing the session with reset variables. Fine.
>>>>>>
>>>>>>It turns out that some folks don't proceed to the end. They
>>>>>>stop at the "Record Created" screen and then
>>>>>>get creative on how to repeat the process for the next person.
>>>>>>In some cases, they go back to their email (Personalized emails
>>>>>>were sent to start the process) and use the link to initiate a
>>>>>>whole new interview process. In other cases, they simply return
>>>>>>to the first screen.
>>>>>>
>>>>>>The problem is...when they start the new process, they are
>>>>>>actually continuing the previous session because it was never
>>>>>>ended or reset gracefully. Argh. I was going to ask advice on
>>>>>>how to handle, but the answer is clear..just add another layer
>>>>>>of session handling to test for incomplete processes.
>>>>>>
>>>>>>This is just one example.
>>>>>>
>>>>>>So....my question is: Is this the way that the web development
>>>>>>game is played? Design a seemingly good system for 98% of the
>>>>>>users and then double your efforts to plug holes for the
>>>>>>non-conformists...and let's not forget the BOTS?
>>>>>>
>>>>>>If so, I am having serious doubts about continuing on my
>>>>>>present path of "whipping something up" for clients for short
>>>>>>term use.
>>>>>>By the time all the holes are plugged, the
>>>>>>interview/signup/registration process has ended.
>>>>>>
>>>>>>Would enjoy hearing comments from the experienced members.
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>Jonathan
>>>>>>
>>>>>>--
>>>>>>Jonathan Schwartz
>>>>>>Exit 445 Group
>>>>>>jonathan at exit445.com
>>>>>>http://www.exit445.com
>>>>>>415-381-1852
>>>>>>_______________________________________________
>>>>>>FX.php_List mailing list
>>>>>>FX.php_List at mail.iviking.org
>>>>>>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>>
>>>>>_______________________________________________
>>>>>FX.php_List mailing list
>>>>>FX.php_List at mail.iviking.org
>>>>>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>>
>>>>--
>>>>Jonathan Schwartz
>>>>Exit 445 Group
>>>>jonathan at exit445.com
>>>>http://www.exit445.com
>>>>415-381-1852
>>>>_______________________________________________
>>>>FX.php_List mailing list
>>>>FX.php_List at mail.iviking.org
>>>>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>>_______________________________________________
>>>FX.php_List mailing list
>>>FX.php_List at mail.iviking.org
>>>http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>>
>>--
>>Jonathan Schwartz
>>Exit 445 Group
>>jonathan at exit445.com
>>http://www.exit445.com
>>415-381-1852
>>_______________________________________________
>>FX.php_List mailing list
>>FX.php_List at mail.iviking.org
>>http://www.iviking.org/mailman/listinfo/fx.php_list
>
>_______________________________________________
>FX.php_List mailing list
>FX.php_List at mail.iviking.org
>http://www.iviking.org/mailman/listinfo/fx.php_list
--
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-381-1852
More information about the FX.php_List
mailing list