Filemaker 14 WebDirect Slow Tabbing

[James Gill]

WebDirect in Filemaker 13 promised many things, but there were a TON of gotcha's that made it pretty hard to recommend as a serious alternative to even a extremely simple PHP web portal.  In Filemaker 14, they've gone a long way in streamlining and adding new features to WebDirect so that it's hopefully a realistic alternative.  One of the things that really annoyed me in FM13 WebDirect was the extremely slow tabbing between fields in WebDirect.  It broke the user experience and made form-based WebDirect solutions a pipe dream, because asking users to wait half a second to go to the next field while WebDirect communicated with the Filemaker server is out of the question.

In Filemaker 14, they've changed the way that WebDirect works so that things like tabbing should be much quicker because they take place solely on the client side.  I underlined the should because according to Filemaker's Product Development Team, there are some gotcha's that you need to be aware of.  Here is the relevent information as filtered from a PM @ Filemaker:

WebDirect in 14 actually has fixes to address this issue. I was aware of this issue customers had with 13. We fixed this by implementing client side tabbing wherever possible. When able to do client side tabbing we don’t communicate with server and this is how we improved the performance. Due to the nature of FileMaker and webdirect, not ALL types of fields can be done via client side tabbing. The WebDirect pdf guide (he will be able to see this at launch) talk about what type of fields do client side tabbing.  The gist is to keep the field as simple, as default, as possible. For example (customer should try this to understand the concept) adding default edit fields will use client side tabbing. As soon as validation, script triggers, data formatting, conditional formatting are added we have to use server side tabbing. That should conceptually make sense since we don’t have a Draco engine running in the browser.

I don't yet have the tech doc that he references, but now that FM14 has been released I'll post it here when I find it.

Edit: Apparently Filemaker is working on creating a KB Article on the issue.  For now here is their response:

If there are no enter script triggers, no data formatting, we will allow the tabbing/focus into the edit box without waiting for server response.  On exiting of that field, if there is no validation, modify script trigger, or data formatting, we will allow the exit to happen without waiting for server.

Edited May 13, 2015 by James Gill

[xochi]

I just tested a simple web form in FMS14 WebDirect, and tabbing is much much better as compared to FMS13.    On a page with 3 fields, typing AAA[tab]BBB[tab]CCC ends up with AAA, BBB, and CCC in the correct fields.    Under FMS13 you'd end up with garbage.    This is a small but really important improvement.

[James Gill]

I just tested a simple web form in FMS14 WebDirect, and tabbing is much much better as compared to FMS13.    On a page with 3 fields, typing AAA[tab]BBB[tab]CCC ends up with AAA, BBB, and CCC in the correct fields.    Under FMS13 you'd end up with garbage.    This is a small but really important improvement.

​The problem that you're describing (typing into one field, tabbing, and then typing into another field with unexpected results) can still happen in FileMaker 14.  The issue is a result of the web client needing to communicate with the FileMaker Server to verify a value that is server-side (auto-enter calc, data formatting, etc).  It's nice that FileMaker is attempting to rectify that issue, but the necessity to verify something on the server means that retaining 'useable' field-based value entry is really limited.  Even on a LAN, changing between fields takes in excess of 50-100ms with the tab button.  I haven't tested it on a WAN yet but I can't imagine it's any faster

IMHO FileMaker needs to offer something akin to an Indexed field for Web Direct validated fields.  It's crazy to think that unless you have a completely 'natural' field, potentially every tab and field interaction is resulting in a call to the server to verify something.  I can see the WHY, but there has to be a better way to validate values that are hardly ever going to need to be validated at the time of entry.