Why do you want to show two different clients' training plans side-by-side on an iPad? What is the broad purpose of the iOS app you're trying to build? It sounds like you want to switch away from a spreadsheet to FileMaker for tracking clients' training data, but I don't see anything about how you want to work differently in a database than you do in a spreadsheet.
FileMaker Go interfaces tend to work best when you have a very clear idea what kind of environment you want to use the database in, what you're doing in that environment, and a very specific idea of a very small number of things you want to do in the database when it's on the iPad. A good FileMaker Go app will usually be much less flexible for a spreadsheet, but better optimized for a narrower set of in-the-moment tasks. Usually, those tasks boil down to in-context data entry — like how many repetitions a client was able to do in a certain set — or viewing the very small set of information necessary to answer the question, "What do I do now?"
A side-by-side comparison of different clients' training plans implies to me a detailed analysis task, which may be better suited to the desktop version of FileMaker. On the desktop, you could open two clients' training plans by opening each in a separate window.
I would use a layout based on a "main" table connected to a client table via a one-many relationship.
Then show the info for client 1 in a one record protral secifiied as rows 1 thru 1,
and then client 2 in an identcal portal beside it specified as rows 2 thru 2,
etc etc for as many as you need.
You can filter and sort the relationship between the Main and Client tables in various ways (e.g. who am seeing today, sorted by appointment time)
I have done just this for an Occupational Therapist I-pad app. Worked well
Thanks for the reply.
It's a training facility where two clients are coached simultaneously as they do their individual programme. The purpose of moving to a database solution was to be able to 'stack' client information (like addresses, medical records, food-pictures, body-pictures etc) alongside the training programmes, so that each coach has a full-overview whilst working with the client.
Given that the programmes start with a given set of variables (exercises/sets/reps), it would then be helpful to be able to 'snapshot' the session at the end, so the client could start from that point at their next training session.
For the use case of coaching two clients simultaneously, I think you might be better served if you give users the ability to select two clients for a session, and a way to switch back-and-forth between those two clients very quickly, rather than looking at the client data side-by-side on one screen. The simplest way would be to perform a find for both clients (a separate request, one for each client, as part of the same find), then view them in a form view so the user can use the record forward and back navigation controls to switch between them.
In general, get used to splitting information up into separate screens on iOS and letting the user rapidly switch between them, rather than trying to fit everything into one cramped layout. Each of the types of information you described — addresses, medical records, food and body pictures, and training programmes — could reasonably be displayed on separate layouts, or at least separate panes of a tab control.
The discussion of how to structure your data to enable you to "snapshot" a session deserves it's own discussion thread.