Controlled Data Entry Design

[Ocean West]

Before I make several design changes that impact end users data entry methods I am trying to decide the best approach to accommodate the changes that are being made:

Currently:
The user enters a Date in a date field and a time like 8AM-6PM into a text field.  One set of fields for an Event and another set of fields for Setup.

Development:
I have normalized this event data into a separate table and parsed the time field into a its key parts mostly the start time and then also introduced a duration field so the intent is the user just enters the date and start time and a duration (from a pick list) I have a calculation that will resolve to two timestamp fields one for start and the other for the ending - this is essential because we plan to implement a plugin to add this data to outlook calendar. Each event must be its own record. 

User Interaction:
How should the user add / modify this information? Because the data is in a child table from the main record I need to cache the date & time in the parent record so find and sort operations are acceptable over WAN - so this means that a trigger or a modal interface is needed so that when anything is created, modified or deleted, the script runs that will update the cached values in the parent record. And if any records have been synced to outlook the script that does the sync is also executed.

Option 1:
allow user to enter directly into a portal and then have a trigger that executes when the data is saved? - To me it seems like since there are so many fields that they need to access would trigger this script excessively, when putting the trigger on any field in the portal. Or putting the trigger on the portal itself. - And I wouldn't want to add a manual button to "update" the data as that has the potential of the data in the portal and the cached data fall out of sync.

Option 2:
build a modal style popover that allows interaction and a commit / revert button. Clicking on an item in a portal opens the same popover for user interaction. User can't navigate away without the process completing as intended.

Option 3:
Popup window or switch layout possibly more control over the data being entered, could even be a utility table of globals. 

Of these options (or ones that I haven't considered ) which is the preferred method and I hope this discussion reveals that I am not the only one that stands on the forked road at times trying to see which path to take. 

 

[Ocean West]

Well I played around with this and think this is a good compromise.

There is a trigger on opening the popover that sets the data fields in to globals all user interaction can be reverted by the cancel button or closing the popover.

Built a TimePicker for quick data entry.

On saving the needed data from the portal is cached into the parent record which the user has no means to edit via the main record, and yet can search and sort on freely. 

Decided to start with a Popover with the reasoning that if it was just not working or i needed a "portal" (since this popover is in the portal ) i could just copy and paste contents to new layout and everything would just wire right up and use a popup window instead.

I Will probably have an indicator in the portal  that the record was synced to Outlook, then on save update the record if it is a newly created schedule prompt the user if they wish to add it to the calendar.

Waiting feedback from customer but good chance might to reduce the starting minutes to quarter hours intervals. 

Simply using button bars and conditional formatting allows a quick data entry. 

 

[LaRetta]

Hi Stephen,

I am unsure why you are bothering to 'set globals for all data' but I would use popover here as well since you can hold the user captive.  OnObjectExit of the popover, the record's open state can be checked and if modified, User can be asked whether to save or cancel and if save, flag the portal record sync field, sync the change and commit the record.  I like your approach.  :-)

[Ocean West]

in this case it's only 5 fields that I am working with and 5 corresponding global fields - one reason just an old crutch that seemed the safest as the user is not interacting with real data fields until committed, via the script.

I tinkered with the onObjectExit and tried somethings with the openState but found the user could commit a record in the popover simply by clicking in an open area. 

[LaRetta]

50 minutes ago, Ocean West said:

in this case it's only 5 fields that I am working with and 5 corresponding global fields - one reason just an old crutch that seemed the safest as the user is not interacting with real data fields until committed, via the script.

And if two users enter changes into the global at same time, how do you handle it during the commit?  

http://fmforums.com/topic/47273-portal-filter-and-highlight-row/#comment-221213

It is true that using globals is not exactly the same thing but I would much rather trust FileMaker to open a record and protect from other modification until the first User is finished than handle it myself.

53 minutes ago, Ocean West said:

I tinkered with the onObjectExit and tried somethings with the openState but found the user could commit a record in the popover simply by clicking in an open area. 

Oh sure but there are many methods of stopping the commit.  OnObjectExit to the popover with ( roughly ):  

If Get ( RecordOpenState ) or Get ( RecordOpenCount ) 
Exit Script [ False  /* do not allow it to close */

Then layout trigger OnRecordCommit:

If [ $$popoverOpen ]
If [ $$allowCommit ] 
Exit Script [ True ]
Else
Exit Script [ False ]
End If
End If

You can also place a transparent rectangle over the popover ( or web viewer ) to prohibit the commit but it is difficult to completely cover it.  There is usually a pt or 2 along the border which could potentially allow commit so handling it via triggers and global variables works best.  Prohibiting commit until the User is completely finished is far more efficient as well since each commit sends the entire record back to the server over and over.  And of course transactional is far safer particularly if writing back to the parent data dependent upon child records ( such as totals ).

It takes very little to set this up using a few untethered scripts and a few buttons for save/cancel.  Just a thought. :-)

Of course the process would also check if triggers are disabled but the above is rough overview.

[Ocean West]

Thanks @LaRetta for Ray's post that was a good eye-opener.

I think I downloaded your sample modal popover the other day hadn't had a chance to dive in.

 

[Lee Smith]

That was a nice trip down memory lane seeing those names from the past.

[LaRetta]

Hi Stephen,

Actually, I don't use Modal popovers like the file presents anymore either.  

The above abbreviated, rough-shod example ( in my prior post ) is based upon work I've seen in files by Daniel Smith and the more I use the concept, the more hooked I become. ModalPopovers.fmp12 is similar but uses transparent rectangle over the popover with script attached and does not modularize into reusable code.  I had avoided global variables because they would need to be cleared but I now know that it doesn't matter since it is locked down by script triggers anyway - no chance of global variable remaining improperly populated because we have total control!

Hi Lee,

I agree.  It was nice to have Ray on the forums.  

Edited December 5, 2015 by LaRetta

[bruceR]

I prefer the modal popover method which I first saw demonstrated by Excelysis, I find it much simpler.

It goes through the popover control script twice. See my attached example, similar to files in this thread.

No cover-button required. Note my example includes a couple of other variations in the form views.

http://www.excelisys.com/fm-tips/filemaker-pro-13-tip-n-trick-filemaker-pro-13-popover-close-in-one-script/

ModalPopover_BFR.fmp12.zip

[bcooney]

What I wrestle with, is that a modal popover does not obey the Apple UI guidelines.

https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewControllerCatalog/Chapters/Popovers.html

"The use of a popover for the preceding actions is less intrusive and cumbersome than a modal view. In iPad apps, modal views should be reserved for situations where you require the user to explicitly accept or cancel some action or information. For example, you would use a modal view to ask the user for a password that granted access to the rest of your app. For most other cases, you would use a popover instead. The advantage of popovers is that they do not cover the entire screen and can be dismissed by simply tapping outside the popover view. Thus, they are an excellent choice in situations where user interactions with your content are not required but provide information or additional features for the user."

So, a model popover is an oxymoron according to strict UI guidelines.

[Ocean West]

Very good points @bcooney 

So I built it and have made two portals to separate the type of event. And am quickly realizing that any minor tweak i make to one i have to repeat in the other popover - 

Now after it's built I am contemplating a possible alternate approach - heeding the other suggestions by NOT loading and unloading globals while the user is editing the record. 

If i wanted a unified interface for both types of events that I could either use a popover that isn't in the portal however i am not a fan of having a disembodied popover - it would be one thing if we could natively dim or blur the non active layer and or choose to show or not to show the connection triangle that connect to the popover, and control alignment of the popover, (essentially the same control we have with a modal pop up window ) however unless i know the end client is only using Mac at this point I refrain from using other windows because how it behaves on Windows. 

The other option is to use a slide panel and put everything on one pane and then target another pane when editing content, but it makes it much harder to control exit points with out putting a lot more controls in every button's script. 

I am open to suggestions.

[LaRetta]

Hi Barbara!  Nice to see you! 

4 hours ago, bcooney said:

What I wrestle with, is that a modal popover does not obey the Apple UI guidelines.

The 'g' in guidelines is capitalized and it is is an important distinction ... they are guidelines and not rules.  If you review, many applications, even those from Apple Store, do not hit them 100%.  And, as you know, FileMaker requires lateral thinking.

4 hours ago, bcooney said:

So, a model popover is an oxymoron according to strict UI guidelines.

'strict guidelines' is the oxymoron here.  ;-)

[bcooney]

lol, LR, yep, "strict guidelines."

OW, this is a very good thread and we've all been here. I'd probably do globals for create and another panel for edit using a selected relationship. All in a slide panel.

[Ocean West]

with ample amount of coffee here is a video i made this morning...

 

[bruceR]

I am a little confused by your two time portals.

You say that in the parent record, you want to capture the setup time; and the show time.

And you show two portals, for the event, one seems to be about setup time; the other about show time.

There can be multiple setup times? Multiple show times?

But you only capture ONE show time and ONE setup time in the parent record?

[Ocean West]

the two portals are based on the same relationship they are just filtered to show only setup / shows respectively.

i have inquired with the client several times if they ONLY have one setup date & time but when I seen notes to the contrary and it indicates to me that its best to build this that will accommodate multiple for each type. 

Only the primary or initial setup / event is needed in the parent record, and the reason for having a normalized table for each is so that eventually these will be published to Outlook Calendar which requires a record for each. 

-

I removed creation bit on the portal so the blank row doesn't show up ( requiring scrolling if there are > 4 items ) reduced it back to one portal removed the filter and added the New buttons for each type below. 
it sorts by type ( setup / show )

playing with conditional formatting on button icon to indicate possible record is synced with Outlook.

-

There may be a chance that the user may create a show time and based on some some logic the setup times may follow a pattern to be done the same day just hours before, or the day prior, if I can get this pinned down then the creation of a setup record could be automated to some extent.

 

[bruceR]

OK, please look at the attached. It's a bit cobbled looking and not an exact match for what you are doing but I think it illustrates several things.

1. It uses a modal, transactional popover. You cannot switch records, quit, etc. But you can add and delete records in multiple portals and edit any data; and then choose to cancel or save.

2. The popover button is in the header and set to always hide. This allows you to have a popover detached from the portal(s) or buttons that may call it. You do not need maintain multiple instances of the popover.

3. By using conditional formatting it is possible to give the user visual feedback on which item (portal row) you selected to edit. As opposed to having the popover-pointer point back directly to the triggering button.

4. It installs a minimal menu set. 

5. By using a popover not attached to a portal, you are free to include portals within the popover.

6. A layout-level OnRecordCommit trigger prevents click-outside-the-field from committing changes.

7. I did not actually create the write-back-to-parent function but I think you can figure that part out.

8. It does not require an overlay button.

9. It uses empty fill, no shadow, empty line for the popover but uses fill and line for the popover content.

ModalPopover_BFR.fmp12 2.zip