1 of 1 people found this helpful
1) For more discussion about orientation-dependent FM Go iPad implementations, have a look at this "Slide-a-Block" technique:
2) Martha Zink gave a FileMaker Academy presentation on FM Go design last year which included that approach. You can find her webinar and sample file here:
Beatrice Beaubien, PhD
i2eye, Toronto, Canada
FileMaker Business Alliance
FileMaker 11 Certified Developer
Knowledge Translation Certified Professional
On Jun 26, 2012, at 11:04, tcfitzgerald wrote
created by tcfitzgerald in FileMaker Go - View the full discussion
I am researching developing layouts in FileMkaer for the iPad and was wondering if anyone had best practices or advice on a few topics.
I have looked through the starter solutions that come with FileMaker Pro 12 and it seems that the iPad solutions all use one basic technique for dealing with rotation in their main list views. There is one item anchored to the left and right and all of the other items are anchored to the right. This allows the first item to stay in place while the others adjust themselves according to the orientation of the iPad.
I've also seen some solutions that involve "sliding" out of panels or hidden content. This method is used here in the training file located here: http://www.rcconsulting.com/FMGO-Web/index.html.
I was wondering if anyone had any other tips or tricks that they use for iPad layout design.
Is it possible to have more than one item in a horizontal list that is anchored to both sides allowing for growth without introducing overlap?
Several ideas to consider, depending on what you are building:
First, it is always risky to have multiple items anchored to both sides in the same horizontal area, but a bit less so with FM Go than with Pro. In Go you know the maximum dimensions of the screen, so you can make some accurate predictions of how much objects can grow before they might overlap. With Pro, the variable of possible screen sizes makes that a worse risk.
I like to evaluate which fields in a horizontal area will benefit the user most from expanding, and generally only set one in a horizontal group to expand, but choose the one likely to have the most content or most variable content.
Of course, this means that things aligned vertically may no longer line up at some edges in the middle of the screen. It's a trade off.
Now that 12 offers screen stencils for iDevices, I would plan for specific devices, and use stretching/anchoring only to deal with device rotations rather than trying to create layouts which work on both desktops and iPads.
Another option which works great in some cases is to design some screens with No objects anchored at all so that everything remains centered and its original size as the screen size or orientation changes. It means you have to design for the narrowest dimension for both horizontal and vertical, but, for some screens that's OK and makes a nice centered effect regardless of device orientation.
Great, thanks! I have seen the sliding-block technique page but forgot to mention that. I am watching the Martha Zink video and there are some good tips in there. Seems to confirm the ideas I originally had about designing layouts for iPad/iPhone.
I am able to get this technique to work in FM Go 11 but not in FM Go 12. Anyone else having that experience?
Sorry - just discoverd the answer. In FMP 12, the canvas size matters. It must be 768 pt wide. Then, when turning to landscape, the sliding occurs as expected.
I've the same problem but i can't solve it.
On fmpro all work as expected
But in fmgo12 it's fine only in landscape but when in portraite the part that should be hidden it's in front of the other...
Sounds like a layering issue. Make sure the "hidden" element is sent to back.
If I recall correctly, in FM Go 12 you can't slide anything OVER TOP of a portal. Worked fine in Go 11 but not in 12.
I've solved (reading the comment on the original article) using an autosizion TAB tabel which contains the "slinding portal". The TAB Panel should be dimensioned at 1 px and positioned at the right of the screen.
In this wa in portrait mode the tab is invisible, instead in landscape mode the tab expands and makes the portal visible...
Very tricky; and it's a little simpler to post-modify/mantain/test because there is no overlap of element and the tab expands as expected also in FM Pro