[FX.php List] [OFF] Those Whacky End Users
Jonathan Schwartz
jschwartz at exit445.com
Wed Nov 28 12:42:19 MST 2007
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
More information about the FX.php_List
mailing list