[FX.php List] [OFF] Those Whacky End Users

Wed Nov 28 09:43:38 MST 2007

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