Join Cris Ippolite for an in-depth discussion in this video Design considerations in FileMaker Go, part of Learn FileMaker Go 15: The Basics.
- [Voiceover] Deciding to design layouts for use with FileMaker Go on iOS devices should come after you've already planned out which of your users or user groups will need access on those devices. This should be part of your discovery process prior to even starting the development of your custom app. So by the time you get down to the process of designing, you should know who the users are that are going to be using their devices to access your custom app. And more specifically, what type of tasks they're actually going to be performing on the device. As you consider bringing your custom app from the desktop to the iOS platform, you should stay focused on ways in which people actually use iOS devices.
People often use iOS devices when they're on the go, or in environments that are commonly filled with distractions. So part of your job is going to be to create a responsive, compelling experience that pulls people in, gets them quickly to the content that they care about, and then maintains focus on that content. Now many times you may discover that groups only need a subset of features from your entire desktop version. As a matter of fact I'm going to go so far as saying exactly zero cases in my professional carreer over 20 years have I ever have to build in all of the functionality from a desktop layout into an iOS layout.
So make sure that you're only designing layouts with the data and the features that are required by the go users, rather than trying to replicate your entire desktop database in FileMaker Go optimized layouts. So, following what's know as the 80/20 rule, where the larger percentage of users typically at least 80% use a limited number of features in the app. While only a small percentage, around 20% of them use all the features. So most iOS apps don't even provide all the features that only power users are going to need.
So it's very, very important to keep this in mind when you're planning your go layouts. First determine who's going to use them on the go, and in the FileMaker Go app. And then simply figure out which layouts they need access to. What tasks are they going to perform. Are they going to be entering in invoices? No, probably not. Are they going to be searching for customers for contact information for directions? Sure. Maybe they're doing that. Are they going to be taking inventory by scanning devices up on shelves? Sure. But are they going to be ordering new inventory? Probably not. Those are the types of things that you need to figure out so that you're not rebuilding everything in FileMaker Go.
And once you figure out what those layouts are, you need to take some considerations into mind when you're designing them. Many developers will choose to create solutions or layouts that are tailored to take advantage of the native iOS environment. These mobile layouts, as you can call them, could be aimed at smaller screen sizes, or simply provide larger targets for touch. So when you're designing and developing layouts for any platform, there are always considerations to take into account. But if you make yourself familiar with the limitations of the IOS devices as it pertains to interacting with the data, before you design these layouts you're going to save yourself a lot of time.
So here's a couple of tips for you specific to designing FileMaker layouts. You should be aware of the things FileMaker Go can not do. So when you design a Filemaker layout for deployment on FileMaker Go, keep in mind that you can't remove views or layouts. You can not add or remove fields. And you can not actually switch to layouts that aren't displayed in your Layouts menu. Now that's unless you provide a navigation button. So right there, those first few items they're telling you your user doesn't have any design control over the layouts. And if they're going to navigate from layout to layout, give them buttons to be able to do that.
Also keep in mind that users can not define or assign value lists to existing fields on a layout. Again, they don't have any access to layout mode. Now they could edit the values inside of a list if you've added the Edit option on the bottom of your Control style option. You can't display tooltips in FileMaker Go. And just as on the side, there's kind of a technique to put "..." as leading characters and tap control names not supported on FileMaker Go. So really, if you take these things that you can't do you have to remember really, what's that experience going to be like for users.
First of all, they're not going to do any designing, they're simply going to work and interact with the data that's already there, and you want to minimize the actions that they're actually performing to just stuff that's really possible to do on a device anyways. And when you do that, then you actually get down to some actual design decisions. So some of these design decisions should be pretty pragmatic but for example, you want to leave enough inactive space on the form so that users can tap outside of a field to commit their data. So remember, committing the data users don't have many other options to do it, so give them some space so they can actually tap somewhere to do that.
And you want to reduce the file size of images like logos or background images that you're using as much as possible because if you're connecting using FileMaker Go to a hosted solution, you have to push all that extra data though what could be just a 4G connection. Use PNG file format for images, that's the one that's the easiest to use and gives you more control over the file sizes. And there's a technique that I'm going to show you in a moment where you're creating iOS-style grouped fields, where you're going to take a stack of fields and then you can use the Appearance tab in the inspector and create a corner radius for each of them.
This something that your users are already seeing in a lot of different apps. So this'll help them look at all the information together as a whole rather than as individual fields that are stacked up. And you want to make sure that you have complete control over the interface. So what's very common is users will hide the Menu bar and Tool bar when they open up a file. I'll show you tat later on in this chapter. So that users aren't compelled to have to use some of the built in functions like the Menu bar. You should never have them navigate to their own layouts. You shouldn't have the be creating records through the Tool bar. It's things like that that you want to keep in mind and build those activities right into your layout.
Again, if you've already done discovery, you know what actions the users are going to perform. You can build all of the buttons that perform those actions right into your iOS optimized layouts. Another thing that's particularly important is the size of the data. Actually for viewing purposes or editing. So while it's possible to open any FileMaker database in FileMaker Go, it can be challenging to navigate to layouts that are not designed for a small screen. In addition to screen size, it can also be difficult to enter fields, tab buttons and perform a variety of other necessary functions when the layout was not designed with FileMaker Go in mind.
Now there's an entire science behind designing applications for use on smaller screen devices. And Apple has even released a document called the iOS Human Interface Guidelines. I've supplied the web link to this in the exercise files as well as a PDF version of the document itself. I strongly recommend that you read through this document to understand the science behind building for devices. Some of the challenges that come up and a lot of that has to do with just the size of things on devices. So for example, you'll notice on the section on page 13 where it talks about displays paramount regardless of its size.
One of the big tips is, you have to have a comfortable minimum size of tappable UI elements, and that's generally 44 x 44 points. So the way that you're going to use that information in FileMaker Go layouts is to make sure that fields that you might want a user to enter into may be 44 points (mumbles), or tappable buttons or areas on screen should be 44 points (mumbles). So following the iOS Human Interface Guidelines you can apply those same rules when it comes to font sizes and object sizes inside your FileMaker Go optimized layouts.
Now this trickles down to the fonts that you're choosing as well, there's a couple of good rules to keep in mind when you're choosing fonts. First of all, not all fonts are supported on the desktop or on devices, so make sure to test your solutions on all platforms that you plan to use before you deploy them. Tahoma, for example, is not supported on iOS and would be then converted to Helvetica when opened in FileMaker Go. So if you've taken all the time to go in and tweak all your layouts or build in a custom style that uses a font that's not supported on Go, by the time it gets to go, they could be converted to something that is supported on Go and it might not look the way that you want to.
Now conversely, there are some fonts that work on FileMaker Go that don't work on the desktop. So for example, a very common font that's used which is called Helvetica Neue, which frankly just looks beautiful on iOS devices, is not supported on Windows on the desktop, for example. So, really shouldn't matter too much if you're using a font like that specifically just for devices that will only ever be accessed on Go, but keep those things in mind as you're creating device-specific layouts.
- Getting files on the device
- Navigating in FileMaker Go
- Working with data
- Performing finds
- Using container fields
- AV controls
- Signature capture
- Barcode scanning
- Creating layouts optimized for FileMaker Go
- Detecting user gestures
- Communicating with other apps via URL schemes
- Securing your custom apps with Touch ID
- Connecting with iBeacon