Sorry John, what new FileMaker checkbox function you are referring to? I just checked and I can only see that they added a bit more styling to checkboxes, but this dos not apply to what you are trying to do. Am I missing something?
Your question is a bit too generic though.
Let's disregard any new checkbox functionality there may be …
What's the best way to complete this using the new FM checkbox function?
That's the wrong question, because it presumes that “checkboxes” (which would reflect fields native to this table) are a viable approach for this task.
They most likely are not, especially considering that each item has several pieces of meta-info associated with it, which you will probably want to check against (e.g. the completion status of the main record is a function of “all vs. completed” items, and similar things), which would necessitate long and complicated formulae …
Instead, consider a line item approach, where you create the items and their attributes as related records, based on an existing “blueprint”.
If it's only about creating graphic-objects, you only need to go into layout-mode, select the rectangular-tool, drag your square and with Inspector, set attributes like border-line, round-corners, colors, etc. or even precise size.
create 1, select and duplicate with cmd / D, drag at the right position, repeat, …
We have similar requirements with a couple of our clients and we didn't use checkbox lists as there are other things we needed to capture which I suspect you may as well. In our case, we needed to capture who checked the box as well as the timestamp of when. Plus, we needed the ability to allow an uncheck in case the user clicked the box by accident.
In one instance, we created a value list with only one value, yes, and applied that to each field on the form and sized the field to only so the checkbox. This was when the user clicked the box, it would toggle checked or not, and that's all they saw on screen. We also applied a script trigger that then updated two other fields tracking the user account and timestamp, and if the user clicked a second time, we removed the account and timestamp. The script trigger used a parameter for which field set needed updating, so as long as you're consistent with your naming convention, that single script will work for all fields.
In another solution, we put a graphic of a checkmark on the layout for each item, and when clicked we changed the color and updated the related account and timestamp fields. This was we only needed two fields instead of three. We also made that information available on hover as a tool tip so the manager could see who and when without running a report. If you needed to run your solution on an iPad, I'd recommend a pop-over instead.
This is just what I'm looking to do.
How did you setup the naming convention for the script triggers & the triggers?
Using On Modify for the field or checkmark, the script trigger runs passing the parameter. Based on the parameter being passed, we have a series of If statements that looks for a match from Get (ScriptParameter) and when matched, we know which field to update. Depending on your naming convention, you might be able to shrink that down to just one and use the set field by name step.