[FX.php List] [OFF] Those Whacky End Users
Bob Patin
bob at patin.com
Wed Nov 28 12:52:30 MST 2007
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
More information about the FX.php_List
mailing list