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

Joel Shapiro jsfmp at earthlink.net
Wed Nov 28 12:25:15 MST 2007 

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

More information about the FX.php_List mailing list