iOS devices present special constraints for layout sizes. This video shows you how to design layouts in your custom app that can be easy to use on iPads and iPhones.
- [Narrator] Deciding to design layouts for use with FileMaker Go should come after you've already planned out which of your users or user groups will need access to these devices. Take an inventory of who your users are and how they're going to access your custom apps should be a standard part of your discovery process prior to starting development. As you consider bringing your software from the Desktop to the iOS platform, you're going to need to stay focused on ways in which people use iOS devices. People often use iOS devices while they're on the go, or an environment that may be filled with distractions, which is not necessarily the case when you're working with your custom apps on desktops.
Part of your job, will be to create a responsive, compelling experience that pulls people in, gets them quickly to the content they care about, and then maintains focus on that content. Many times, you'll find that your users that are accessing your custom app on devices, only need a subset of features from your entire Desktop version, so make sure that you only design layouts with data and features that are required by the go-users, rather than trying to replicate your entire Desktop database on FileMaker Go layouts. Following what's known as the 80-20 rule, the largest percentage of users, typically 80%, use a limited number of features in the app, while only a small percentage, 20%, use all features.
I can tell you from over 25 years of programming in FileMaker, that we've had exactly 0% of the cases where we'd have to rebuild all of the functionality from the desktop on to the device. In every case where we've built something for the devices for our clients, they've only needed a subset of functionality, and that has mostly to do with the fact that they're only accessing the app on the device and not at their desktop where they have all sorts of other functions that they might be performing. Most iOS apps, don't need to provide all the features that only power users need either. It's very important to keep this in mind when you're planning your FileMaker Go layouts.
Many developers will choose to create solutions or layouts tailored to take advantage of the native iOS environment. These mobile layouts, could be aimed at smaller screen sizes or simply provide larger targets for touch. When designing and developing layouts for any platform, there are always considerations to take into account. If you make yourself familiar with these before you design, you'll save yourself a lot of time and your users a lot of frustration. For example, when you design a layout, keep in mind that on an iOS device, your users cannot remove views or layouts, add or remove fields.
They cannot switch to layouts that aren't displayed in the Layouts menu unless you provide a navigation button. They cannot define or assign value lists. They cannot display tooltips or display leader characters such as dot, dot, dot and tab control names. These might be tactics that you're utilizing on the desktop. Here are some tips for when you're designing layouts for iOS use: Leave enough inactive space on the form so that users can tap outside of a field to commit their data. 'Cause remember, this is something that we do with a cursor on the desktop in order to save data changes, but the end of a cursor is so small compared to the tip of a finger, so make sure to leave your folks a little bit extra white space.
That's something that we have to concern ourselves with with FileMaker custom app on iOS, whereas, other apps don't need to worry about that. Try to reduce the file size of images as much as possible. So if you're capturing images on the device, you can maybe restrict the overall size of what you can capture, or the length of video or audio that's captured. And FileMaker uses PNG, for example, for when they capture signatures. I like to use PNG for background images or logos. It does have a little bit of resizability that makes it easy for iOS. A lot of apps on iOS use iOS-style grouped fields.
In the appearance tab of the inspector, you can create a corner radius. If you grab ahold of a chunk of different fields, you can then take the top field in the stack and the bottom field and create corner radiuses to give it that rounded effect that you see on other iOS apps. And in order to have complete control over the menu bar and toolbar, you can choose to hide or show menu bar, or hide or show toolbars when users are accessing your device from iOS. While it's possible to open any FileMaker database on FileMaker Go, it can challenging to navigate layouts that are not designed for such small screens.
In addition to the screen size, which will require a lot of pitching and zooming, it can also be difficult to enter fields, tap buttons, or perform a variety of other necessary functions when the layout was not designed for FileMaker Go in mind. You can see that FileMaker has some good examples in their, if you look at the layouts in our exercise files that are designed for access on the desktop, you can see that the fields are 21 points high. But if you go over to fields designed for tablet, you can see that they're 44 points high.
That's not just an arbitrary amount. There's entire science behind designing applications for smaller screen sizes. As a matter of fact, Apple has an excellent resource, I've provided a copy of this document for you in your exercise files, and it's called the iOS human interface guidelines document. It has all sorts of really interesting rules and guidelines from everything from animation to views and controls and everything. I find this very useful when I'm designing layouts for FileMaker Go apps.
As a matter of fact, if you look at that guideline and you look on page 13, it talks about a comfortable minimal size of tappable UI elements, like buttons and fields, to be 44x44 points. That's what a button would be. So the heighth of that, they've indicated, is enough for the average finger to be able to enter the field. That's why 44 is the field size that we would use on iOS devices. You'll also notice that the screen size, of course, is much smaller on a iPhone, so therefore we'll utilize long scrolling on the iPhone because we don't have a lot of page width.
This is common in other apps, although page scrolling or long scrolling, is kind of a no-no on the desktop because we have so much wifth to work with there. Also, you'll notice that on the iOS layouts here, we've got certain fonts that are chosen. Notice that we've chosen Helvetica New. If we were to open this layout on a Windows computer, for example, we would not see Helvetica New. That's because Helvetica New is an iOS font. I happen to be a big fan of the look of Helvetica New because it looks very iOS-like, and the thing is, you don't have to worry about installing this custom font on iOS because it ships with iOS on all these devices.
So you can make the decision to use iOS supported fonts in the layouts that are going to only be accessed on iOS, whereas you can choose fonts on the desktop, for example, that might not be Helvetica New. Instead you can choose things like, let's say, Aerial or fonts that are supported on multiple different platforms. I would strongly recommend at least scrolling through the iOS human interface guidelines before you start working with FileMaker Go. And also take a look at some of the starter solutions that ship with FileMaker, because they do a really good job of designing for the iPhone, iPad, and Desktop, and you can see slight differences between those, and you can use those same practices when you're developing your own FileMaker custom app layouts.
- Understanding FileMaker Go
- Getting files on the device
- Touring the interface
- Design considerations for FileMaker Go
- Creating and editing records
- Working with container fields in FileMaker Go
- Matching keyboards to data types
- Detecting gestures in FileMaker Go