Just because you can put all of the fields on a page doesn't mean it is a good idea to do that. In the best UI inservice that I have ever attend it was stated that design isn't finished when you put everything you can on a layout, it is finished when you remove everything that you can from the layout. Most of my develop is for laptops and iPads. I now try to create one layout that works for both platforms. Years ago when monitors where much lower resolutions I would use 10, 11, and 12 point fonts. In my opinion these are too small now for the things that I develop. I like the look of 16 to 18 point fonts on my laptop. I frequent use popovers, slide panels and tab panels to display data that doesn't need to be viewed all of the time by the user. Another thing that I try to avoid is scrolling up and down or left and right (especially on an iPad).
Yes that would be best. But the guys in our shop with there greasy fingers just want to look at one sheet for everything. There kind of picky about that and I haven't been able to convince them otherwise of the joys of multi pane multi tab windows. So that's where I stand now.
Sent from my iPhone
A slide control could be used to advance you from record to record. This can produce the needed horizontal swipe gesture you "flip through the records like a book". The slide control has just three panels with the first and third blank. Script triggers tripped by the swipe gesture run a script that detects the direction of the swipe, (Did it bring the first or third panel to the front) and updates a match field to show data from the previous or next related record.
From your screen shots, it looks like you just need to move from record to record.
Or do you want what is shown in your screen shot to represent the first of multiple columns of information?
If you just need to move from record to record, very simple navigation buttons can be added that allow you to click from record to record while staying on the same layout.
The greasy fingers is the best - and one of the very few valid excuses - I've ever heard
You can break a n-line portal into m portals showing p lines each, the first showing let's say lines 1 to 10, the second 11 to 20 and so on.
Humans are good t recognising patterns and at assimilating grouped data as a whole, therefore I'd suggest to group data into blocks that have a title and a slightly different background, see picture for an example.
You can protect keyboards with thin plastic or other protectors, you can trigger scripts with the "OnLayoutKeystroke" trigger, which can intercept let's say arrow left and arrow right and scroll through things, while arrow up / down scrolls through the day's repairs - you name it.
Jon, this can be pretty easy. There is a script step called "Go to Portal Row" with choices for first, last, previous, next, or even by calculation. You can do a button bar with buttons for < and > and then use a one-line script that says Go to Portal Row [Select ; next]. Size the buttons for big fingers and there ya go.
My brother is head of Product Development for John Deere's tractor division, btw.
Im trying the go to portal row button setup but I'm just getting it to flip through different vehicles not records from one vehicle. Again background the iPad version of this dbase works but the mechanics don't like iPads, "greasy finger syndrome." they like looking at a big picture then seeing where there at in there service job. Then they will come back and click a few more items of. So I'm stuck with looking at the big picture for now. Also eventually theres going to be for different maintenance layouts. One for passenger vehicles, semi's, tractors, trailers, and so forth, so some layouts will have fewer fields some more. Sorry if I'm being oversimple but I'm kind of new to filemaker and still just learning the ropes and you guys have been a big help so far, helping me to think of different approaches to this issue. I myself am a nuts and bolts guy and often computer logic and bolt logic aren't the same. I could link my whole app if you guys wanted to look at what I'm doing. And then maybe give some pointers. Thanks.
Jon, first make sure you are using the script step Go to Portal Row rather than Go to Record.
The button navigation depends upon which portal is active. Take a look at the script step "Go to Portal Row.” Note that it doesn’t specify focus; there isn’t a space to indicate to go to the next row of WHICH portal. FMP gets that from context. It looks at which portal you are in at the moment. I don’t have your layouts, but if there is more than one portal on the layout, try clicking into a layout and then click the arrow button that you set up with the Go to Portal Row script step. See?
It might be possible to engineer giving FMP the right context. In your script, first start with a line that makes the focus on the portal you want. We'll give your portal the name "Repair Portal" and this will be your script:
Go to Object [ RepairPortal ]
Go to Portal Row [Select ; next]
The Go to Object command works with any Object on the layout. Open the Inspector tool, then click on the Portal you want to use. Go to the Inspector's 'Position' Tab. At the top there will be a space for name. Give it a name like RepairPortal.
Next, when you create the Go to Object script step above, click on the box in the script step and insert the name of the Object like this: Go to Object [ RepairPortal ].
Anyway Tried this fix but didn't get anywhere. I think something else is up. Im going to have to really buckle down and go through what Im doing to try and figure it out.