An Old Dog learns some new tricks...
This is a long "blog type" entry--not a request for help.
I've recently been experiencing the joys and tribulations of FM GO database development courtesy of a new iPhone 4s. I've developed multiple FileMaker Pro databases for multiple clients starting with FileMaker Pro 2.5--which was a flat file database. Thus, most of this has been a process of trying out and testing various techniques/issues that I either already used with FileMaker Pro on a conventional computer or that I had recalled reading about here in the forums.
The following is a summary of some of my discoveries, observations and opinions thereof:
Item 1: That screen is really, really small. Yes you can pinch zoom and work your way around a DB with layouts that are not specifically optimized for iOS use, but you won't get much done very quickly. Layouts designed for iPhone use really are necessary and the major challenge is to how to creatively and efficiently shoehorn everything into that small screen. Given that sometimes it's a challenge to do that with a conventional 15"+ display it can really take some thought and experimentation to work out the best compromises to make that work.
Item 2: Your finger is really "fat". That mouse cursor allows you to effortlessly click on very small objects on the screen. Tapping with your finger is using a much "blunter" pointing device and you need to make sure that all such objects (buttons, check boxes, etc..) are large enough to tap consistently and with enough spacing that you aren't tapping other objects by mistake. Sometimes, just a small change of a few pixels in size or position make a big difference in ease of use.
Item 3: You still need open areas on your layout. Tapping an open area on your layout not only commits data, it dismisses those pop up keyboards and pickers that cover over the bottom part of your screen each time you edit a value in a field. If your layouts are densely covered with buttons and fields, you have to tap a much smaller button in the picker/keyboard itself to dismiss it and this slows you down.
Item 4: You still can't overwhelm your layouts with too many objects in one layout. This is true of conventional layouts in FileMaker Pro; it's still true for your iPhone. If you pack too many things into the space available, the eye has trouble taking it all in and it leaves the user with a sense that your design is not easy to use and understand. Open space between objects actually is a key design element in helping the user mentally when they interact with your layout
Item 5: when you combine items 1-4, you realize that "less is more" really comes home to roost with iphone friendly layout designs. Some data entry tasks just aren't going to be something that can be done quickly and efficiently on an iPhone. If the db requires large amounts of typing to enter the data, it's not really going to work well on an iPhone. Setups with limited text entry, with most input via choosing values in pickers and from value lists are simply going to lend themselves far more successfully to use on an iPhone.
Item 6: Tab controls are your friend. Since you have such a small screen, splitting up different parts of your layout onto different panels of a tab control, yet in a logical left to right order is really crucial. Not only that, but there are a few cool tricks that you can achieve with a tab controls to improve your user interface design.One such trick is to extend the width of a portal inside a tab panel just far enough that its scroll bar is to the right of the tab panel's right hand border. The portal looks correct and can be scrolled by flicking the portal rows, but you don't give up millimeters to display the scroll bar.
Item 7: Exploit phone orientation changes at every opportunity. You really need that extra width that becomes available when you rotate the phone into landscape orientation, but you can't afford to lose the info from view when you rotate it back to portrait. Thus, setting up your layouts to display the info most effectively in both orientations becomes key to giving your users the most user friendly experience possible. Thanks to this forum, I've learned two ways to make my interface responsive to orientation changes:
Item 7a: Auto-resize anchors are useful, but have limitations on their utility. Learning how to make this work was way cool and a lot of fun when it worked, but was very frustrating when it didn't. Here's how it works.
Select the correct rectangles for both portrait and landscape orientation. Put all layout objects inside the small rectangle formed by the intersection of these two rectangles--this is the part of your layout that won't change when the phone changes orientation. Leave all such layout objects with the default top and left anchors selected. Now add layout objects that you want to appear automatically when the phone rotates into landscape orientation to your layout. Put them also inside this small rectangle, but hide them behind an opaque object such as a tab control or a rectangle that has the same color as the layout background. Select the top and right anchors instead of the top, left anchors. (make sure that the object behind which they are hiding has top left selected.) You'll find that when you rotate the phone into landscape orientation, the increase in window width will cause the hidden objects to slide out into view.
For objects that you want to appear when the phone rotates into portrait orientation, do the same but select the bottom anchor instead of the top. In one of my layouts, I actually placed two copies of the same object hidden behind an opaque rectangle. One slides right to appear in landscape, one slides down to appear in portrait. It took both copies to get the object positioned correctly in both orientations. Finicky, but the result--which can be seen in the Known Bugs List search layout, is pretty cool.
Be prepared to do repeated tests with this method. It can be difficult to predict whether objects will move far enough to look correct until you test it on the iPhone. You can test this on your computer by manually dragging a window border to resize the window in and out past the points marking the limits of each orientation. (And now that I think about it, maybe I can gin up a script that exactly toggles the window dimensions in Pro to mimic orientation changes in GO...)
You can also put all your objects inside a tab control. Stretch your tab control out to the width of the landscape stencil. Place your objects on the tab panels as you want them, then resize the tab control to fit just in the portion that is visible for both orientations. Now select both left and right anchors. When you rotate the phone to landscape, the tab control will stretch sideways and objects located past the limit of the portrait stencil automatically appear. Unfortunately, I have yet to find a way to make this work to expand the tab control vertically.
And keep in mind that if you select both top and bottom anchors for a portal, the portal will expand vertically in portrait orientation to display more portal rows.
You do encounter some key limitations with this approach. Portals with a scroll bar cannot be hidden behind an opaque object and set to slide out from behind them. When you open the layout on your iPhone, you'll find that your portal "shows through" and is not hidden. If you remove the scroll bar, you can hide the portal back behind, but now you can't scroll the portal. But note that at least for rotating into landscape orientation, you can keep the portal fixed, but inside a tab panel and just expand a tab control to reveal it and this will work with scroll bar enabled portals.
Item 7b: A tad less responsive and tricky to debug at times, but Install onTimer Script used with Get ( WindowContentWidth ) can also detect a change in orientation and then your script can actually switch layouts when the phone changes orientation. This gives you an option that works for list view layouts where you have multiple records in view and need to change layouts to switch between a layout where the fields from one record are arranged in a single row for landscape and in a double row for portrait orientation. The basic script I came up with for this was originally written like this:
If [ Get ( WindowContentWidth ) < 400 // Phone is in portrait orientation ]
Go to Layout [ Get ( ScriptParameter ) & " p" ]
Go to Layout [ Get ( ScriptParameter ) & "L" ]
I called this script "Adjust to Orientation". I create two layouts with the same name except for the last letter that designates the optimum orientation for it such as "Calendar p" and "Calendar L". Any navigation button that takes the user to the calendar then performed a script with at least these steps:
Perform Script [ "Adjust to Orientation" ; Parameter: "Calendar" ]
Install OnTimerScript [ "Adjust to Orientation" ; Parameter: "Calendar" ; Interval: 1 ]
That worked well even though it has a timer counting down and performing a script once every second. Eventually, I modifed the original script as follows to make it safer and easier to control:
Set Variable [ $$TriggersOff ; value: True ]
If [ PatternCount ( Get ( LayoutName ) ; Get ( ScriptParameter )
If [ Get ( WindowContentWIdth ) < 400 // Phone is in portrait orientation ]
Go to Layout [ Get ( ScriptParameter ) & " p" ]
Go to Layout [ Get ( ScriptParameter ) & "L" ]
Install OnTimerScript [ ]
Set Variable [$$TriggersOff ; value: False ]
The $$TriggersOff global variable enabled me to disable script triggers that would otherwise be tripped by the layout change and the outer If block protected me from mistakes where I might accidentally perform this script from the wrong layout. (Install OnTimerScript with no parameters cancels the timer set on the current window.)
The main challenge to this approach is when you go to debug scripts and such from FileMaker Pro Advanced and find that you can't get this script to stay out of the script debugger long enough to perform the script you want to step through in the debugger. Eventually, I figured out that I could insert a pause into the script I wanted to examine. Then I click the button or whatever to start that script executing, open the debugger, and then click the continue button to start stepping through the script.
I've also found that when going from one such timer controlled layout to another, you need to use Install OntImer Script with no parameters to cancel the current timer before changing layouts and/or opening a new window to the next timer controlled pair of layouts.
Item 8: Windows are dead easy in FM Go to set up and can make for very user friendly non-linear navigation between different layouts. I can use new window to open a new window with no other details specified except the name I want to use for the window. Since it totally covers the existing window, this looks just like a layout change, but now I can add a "back" button that just closes the current window. I assume that there's some limit based on available RAM on how many windows I have open, but with a little fore thought, you can do a lot and still have no more than 2 or 3 windows open at the same time.
This may not be such a revelation for Mac users, but as someone who has primarly been developing on Windows systems I've tended to avoid multiple windows due to the way maximized windows spotaneously resize and the work arounds to manage that result in annoying "window twitches". FM GO's simplistic handling of windows actually makes for very simple coding and yet the user is able to use very few buttons to pop between different layouts.
Item 9: Touch Themes save me time.
There's only a couple of these, but if I choose one for my layouts, a lot of size and appearance settings are nicely set for easy on the eyes layouts when viewed on the phone.
Item 10: Form view layouts often work well in list view. Your layout may be sized so that one record fully fits the screen, but if you use form view, you also have to provide something that the user can tap to change records within the current found set. If I choose list view, I can keep the tool bar hidden, not have any such next, previous buttons, but can easily "flick" through the records in my found set. (But I wish on both Pro and GO that I had a setting to select that caused the top edge of the body to "snap" to the edge of the window top or header bottom boundary to prevent a portion of the preceding record from showing.)
Item 10: Gripes and feature request wish list:
The stencils aren't sufficient. Not only do we have more screen sizes out there with the iPad Mini and the iPhone 5, the actual amount of usuable space is larger than that shown in the stencil if we hide the status toolbar. Since every square millimeter is precious on an iPhone layout, hiding the toolbar has become my default setting for iPhone layouts, but now It's difficult to tell exactly how much more space I have to use without trial and error testing on the iPhone.
I've found that layout text that displays correctly on my Windows platform is severely clipped when I first view the layout on the iPhone. I'm not sure, but this seems to be primarily the case when the text is right justified--which is the default setting for field label text when it is added with the field to your layout. This wastes more time as I have to check every layout carefully on the iPhone and then return to my computer to correct layouts where I find clipped text.
There needs to be more ways to make the interface respond to orientation changes. A layout script trigger that either detects a window size change (which would work in Pro as well as GO) or that detects the orientation change would make for simpler and more flexible designs. We could also use better ways to handle how the auto-resize anchors behave with different window size changes. My layouts that look just fine on an iPhone 4 look a bit off on an iPhone/iPod 5 because things have slid and stretched farther than I intended. A way to set a limit past which the layout object won't move or stretch would help give us better control.
Buttons within portal rows appear more responsive on the left hand side of the portal. That's been my personal experience so far. I can put the same size button on the right hand edge of the portal and end up having to tap it repeatedly to get it to respond. Move it to the left hand edge of the portal row and the problem goes away. The presence or absence of a scroll bar does not seem to affect this.
You can't easily set up read only text fields that can be scrolled without a keyboard popping up to cover a big chunk of the screen. It would be really nice for an upcoming project I am working towards if I could drop a big chunk of text into a field and have the user just scroll to read through it. I ended up setting up one field on the Known Bugs List so that tapping it cycles the text displayed through a series of "pages" to get around this. That works pretty well for the user, but makes setting up the blocks of text in each page very labor instensive for me and if I have to edit the text somewhere in the middle, I have to completely refigure the "Page breaks".
Tapping a text field drops the cursor at the end of text in a text field. If I could put the cursor exactly where I tapped, I could edit text more quickly. I've also worked out a method in FMP Pro where I can trip the OnObjectEnter script by clicking a word in a text field. The script then uses the current cursor position to identify the word clicked and runs a script that uses that word (or phrase with the same distinct text style) to produce the needed result--such as looking up definition or displaying a picture relevant to what was clicked. Was very, very disappointed to be unable to set up a similar interface in FMP GO.
And we really need another option to keep a field from expanding and covering some of that precious space each time a field gets the focus. Yes, we can add a scroll bar, but it's hard to hide that feature with rounded fields and the field just looks wrong to me to have a visible scroll bar when none is needed.