Version: FileMaker 15
Sunday, January 1, 2017
It’s easy to develop a solution on your own computer and hope it will deploy exactly the same on all devices. While this would be a dream come true, the reality of a solution working the same across different screen resolutions, platforms, FileMaker versions and operating systems is unlikely in this modern age of device proliferation. I remember when I first started developing in FileMaker, the only choice was the Macintosh, a couple of operating systems and a couple of screen resolutions. When cross-platform development on Windows was introduced in FileMaker Pro 2.1, it only added a little bit of additional complexity. These days, you need to consider so many different operating systems including iOS, web deployment, endless resolution options and many more operating system versions. It’s a tangled mess you have to unravel before starting to develop a solution.
Private or Public
Your first decision is private or public consumption. If you are developing a solution for your company, you know your audience. You can control what platforms and operating systems they are using, making your considerations easier. When you release a solution to the public domain, you need to examine the requirements necessary to use your solution. You don’t know who will download your solution so the requirements must be well thought out. While most considerations between private and public overlap, some are unique and need to be carefully geared towards your audience type.
Screen Real Estate
Every good software product has a minimum screen resolution and operating system. Currently, the FileMaker application itself is limited to a minimum 1024 x 768 screen resolution so the status toolbar can display all functionality. You, as a developer, should also specify a minimum screen resolution before beginning the development phase of your FileMaker project. Each new layout will be based on or duplicated from the original form and list view layouts you create so getting them right the first time is critical. Check, double-check and caution your client or boss about the problems that can occur with an interface that doesn’t fit all required resolutions. This is not a mistake you will have fun correcting over hundreds of layouts.
Screen resolution is one of those considerations people often forget to consider but I’m not sure why. Developers create a great ERD, beautiful scripts and complex calculations but forget to fit the interface to the minimum screen size. If you are designing a solution for your company, all you have to do is go around to each person who will be using the solution and find out what screen resolution they have set on their computer. You might be surprised what you find. Older people tend to have lower screen resolutions so they can read text better. Younger people have higher screen resolutions so they can fit more on the screen. Of course, older computers have hardware restrictions and may not be able to display as much screen real estate as a new computer.
People don't always choose the default resolution, mostly because they have trouble seeing the screen. This makes even a 30 inch monitor seem like a 15 inch!
Finding out the minimum screen resolution is fundamental to the window size of your solution. You don’t ever want to require users to scroll in form view either horizontally or vertically. List view is fine for vertical scrolling, of course, but should also not scroll horizontally. I remember at the very beginning of my FileMaker career when I worked at Claris, I represented technical support at one of the early developer conferences. At this particular conference, FileMaker had a proficiency test that was naturally conducted on a hosted FileMaker solution. To make a long story short, one developer realized at the end of the test that there was one more answer choice on the multiple-choice test if he scrolled down. He had finished the test without considering the last answer choice because it wasn’t clear he needed to scroll down. I just happened to be the first Claris employee he found after finishing the test and will never forget the rage he let loose on me. While your disaster might not be as great as this story, if you design for the wrong screen resolution, you will increase user frustration by requiring them to scroll to fill out the entire form. Or, they may not even see the entire form until you point it out. A user experience should be straightforward and uncomplicated by as few barriers as possible.
If you are creating a vertical market or shareware solution for the public domain, determining the lowest resolution that satisfies everyone will likely put you at 640 x 480. It’s better to set a resolution minimum that you feel is representative of 80 percent of the population. I love the 80/20 rule and employ it all the time. In this case, you can’t design your solution for everyone or you will alienate the 80 percent of the population with realistic screen resolutions. 1024 x 768 is usually a good minimum choice for a vertical market solution but bump that up if you feel your audience has newer computers on average or you really need the extra real estate to properly design your solution.
Unavailable Real Estate
The Screen Stencil feature, in FileMaker layout mode, is a tool designed to combat this myriad range of resolutions, but it’s not perfect. Don’t get me wrong, it will perfectly outline the dimensions you specify as your minimum design resolution, enabling you to easily design an interface to meet those dimensions. Unfortunately, the Screen Stencil feature doesn’t consider FileMaker and operating system interface elements. These interface elements will shrink your available screen real estate significantly.
FileMaker interface elements can be hidden using scripts steps so they do not impact your valuable screen real estate. Features such as the Status Toolbar, Formatting Bar and Text Rulers can be hidden or rendered unusable via script steps upon opening of a solution. These script steps are Show/Hide Toolbars, Allow Formatting Bar and Show/Hide Text Rulers, respectively. Since they only need to be disabled or hidden once per session, a script triggered on open of the first window via File Options is sufficient to lock them down to your specifications.
There is a small real estate issue between FileMaker 12, 13 and 14. The issues really exists in any version prior to FileMaker 12, but since FileMaker 12, 13 and 14 share the same file format, it becomes an issue if there is no control over the FileMaker application version, as in a public distribution of your solution. In FileMaker 12, the list view current record indicator steals 3 pixels from the left side of the FileMaker window while later versions do not. You can toggle on this archaic feature in post FileMaker 12 versions, but why would you want to? I can’t tell you how much wasted time went into accommodating the screen shift between form and list view because of that annoying little indicator. Now the currently selected record is indicated by changing the appearance of the record itself with themes. What a relief!
It is possible to prevent FileMaker 12 users from messing up your beautiful interface by setting the minimum version of FileMaker that can open your solution via File Options. The default is for new or converted .fmp12 formatted solutions to be opened by the the lowest FileMaker version in the format family, so consider yourself warned! Starter Solutions, on the other hand, are set to only be opened by the current version of FileMaker to avoid feature incompatibility.
Operating system elements are a little trickier since you can’t control them with a script step. Even if you could, you would likely alienate users if you hid their dock or taskbar when launching your FileMaker solution. Both docks on the Macintosh and taskbars on Windows can vary greatly from user to user. They can be displayed on just about every side of the screen, increased in size or even hidden during non-use. The best solution is to leave more room than necessary for these operating system elements. How much is up to you but I recommend overcompensating.
On Windows, there is also an application window to consider. The application window is the FileMaker working area where all windows are enclosed. If it’s maximized, FileMaker windows can use the entirety of the screen real estate offered by the monitor being used. If it isn’t maximized, not only do you lose screen real estate but the interface for the application windows is increased with the addition of a scroll bar.
On the Macintosh, you also have to contend with the removal of the scroll bar, or at least shrinking, in current versions of the operating system. The problem is the Windows operating system still has a large scroll bar that takes up a significant amount of space. Most solutions are cross-platform these days, so it is best to accommodate for this difference between platforms.
This is a lot to consider but not very difficult to overcome. Start by deciding on your minimum screen resolution. Reduce the size of your layouts to accommodate for the variety of operating system interface elements and you are good to go. I usually overcompensate and reduce my layout size to easily handle every interface element. You don’t have to fill the entire screen with your FileMaker solution. In fact, it is better not to fill the entire screen so users can take advantage of multiple cascading windows in FileMaker and also easily click to other applications with the mouse.
And by all means, test your window size on a variety of different computers. You never know what you might have forgotten or misjudged. There’s nothing worse than reducing the size of fifty layouts after they are done because they don’t fit on the screen properly. Make sure to test several Macintosh and Windows machines with several different resolutions. Also play around with the size of the task bar and other elements to see if you can make a scroll bar appear. Better safe than sorry. This is also a good time to test cross-platform colors, fonts and other elements.
It seems like you have to cater to the lowest resolution but FileMaker has a solution. There is a layout feature called Autosizing in the Inspector palette that allows you to decide which objects grow when the window is enlarged. You’ve probably seen this feature in action when surfing the internet. Instead of white space showing when the browser window is expanded, web site developers can have the contents flow or expand to fill the window. In FileMaker, for example, this object growing could allow a notes field to grow larger for high resolution screen users so they can see more notes. While not as good as an interface designed specifically for high resolution screens, autosizing does help bridge the gap between high and low resolution users.
Desktop layouts should not be shared with iOS devices. Differences between how and where these devices are used requires special programming and interface design. For example, mice can click on very small buttons while a finger would fumble around awkwardly with the same design. Design special layouts for the iPhone and iPad and use an open script to choose the correct layout for the current device. Macintosh and Windows are enough alike that the same layouts can be used.
Where iOS devices will be used is also an important consideration in interface design. FileMaker Go is appropriately named because most solutions are designed for remote access. With a slower processor than desktop devices and connections in the 3G range a possibility, layouts should be designed with efficiency in mind. Figure out what designs are slow over a remote connection. For example, don’t present the user with a list view of all records on startup or boot time will suffer. Start with a layout of buttons, attached to a table with no records, that let’s users choose their action like finding a record or creating a record so FileMaker only has to deal with a handful of records at the most.
When deploying a solution on FileMaker Server, the initial layout is the last one used when closing FileMaker in single-user mode. This could very well be a list view and slow down the opening of your remote solution. No problem, just set the correct layout with no records in the open script, right? Unfortunately, the initial layout loads even if you don't see it. The only way to switch layouts on open before FileMaker actually opens is to use the "switch to layout" option in File Options.
These are just a few considerations for the iOS platform. An entire book could be written about how to program for this unique platform. The point here is to figure out what users want to do on the go and design a unique interface that quickly accomplishes those tasks. Never design a FileMaker Go solution to do everything the desktop version can do. With this basic goal in mind, iOS solutions can be designed successfully.
Macintosh versus Windows
Even though these two platforms are more alike than different, there are important variances to ponder. Fonts, graphics and even script steps can vary between these two desktop platforms. Once you get the hang of these differences, they are much easier to handle than any other device differences. In fact, I barely even think about the differences since I’m so used to programming cross-platform solutions over two decades.
While you may have the same font from the same manufacturer on a Macintosh and Windows machine, that doesn’t mean they display the same. Macintosh fonts are slightly smaller than Windows fonts, on average. If you are developing on Windows, there is not much of a concern. But if you are developing on the Macintosh, you generally make your fields taller by a few pixels so descenders are not cut. It’s also a good idea to vertically center your text in a single-line fields or use the padding features so text doesn’t get squished at the top. In fact, developers usually pad all sides of a field so text does not appear to bleed into the field borders.
Graphics can also vary from platform to platform. Some colors look exactly the same but others may be a few shades darker when moving from Macintosh to Windows, or lighter in the opposite direction. This can throw off an entire interface so it’s a good idea to test your color scheme before making a bunch of layouts. The same is true for fonts. Better to take the time to check an interface cross-platform before replicating it across multiple layouts.
If you use the built-in themes that come with FileMaker, all the work with fonts and graphics has been done for you already. The FileMaker development team has already tested themes for cross-platform compatibility in all the areas mentioned. This is the beauty of using a theme even though your solution may look similar to other developer solutions. The same is true for the starter solutions as well. Starter solutions use themes and have been programmed to choose the correct scripts steps and layouts for device types. I’m not really recommending that you use a starter solution, but it can’t hurt to check them out and see how they handle some of the platform specific programming and interface design.
There are a few script steps that either don’t exist cross-platform, act differently or have to different interactions with third party programs:
The dial phone script step is not supported on the Macintosh because it doesn’t have the built-in external API to connect to a phone. Dialing will work on an iPhone or Windows device but not a Macintosh. OSX Yosemite does now support phone dialing directly in the operating system but FileMaker hasn’t caught with support in it’s Dial Phone script step. Third party phone dialers are available but hard to control from FileMaker unless you know AppleScript.
Since AppleScript doesn’t exist on Windows and DDE (Dynamic Data Exchange) doesn’t exist on the Macintosh, these two scripts steps are platform dependent. Think of them as counterparts attempting to accomplish the same tasks but requiring separate programming. A simple If script step using the Get(SystemPlatform) or Get(Device) is usually sufficient to determine whether to Perform AppleScript or Send DDE Execute.
The Speak script step is only available on the Macintosh because Windows does not have the technology built-into the operating system to support this type of feature. Not to worry though, you shouldn’t use this script step anyhow. How annoying would it be to speak a dialog every time it shows on the screen. Just show the dialog until the Speak script incorporates Siri technology to support a conversation. Otherwise, people want to work in peace.
I list the Send Mail script step as acting differently cross-platform even though it is available on both platforms. The reason is the different natures of the email programs supported on the two platforms. For example, under Windows, Outlook will warn the user if a third party product tries to send a mail without interaction from the user. This makes it nearly impossible to send bulk emails generated by FileMaker to Outlook under the Windows operating system. It basically comes down to viruses. Windows has them and the Macintosh doesn’t so Microsoft has to take precautions.
Many versions of FileMaker share the same file format, allowing the files created by a newer version of FileMaker to be opened in an older version. For example, FileMaker 7 through 11 all share the same .fp7 file format. Creating solutions for public consumption in FileMaker 11 required feature avoidance or at least conditional programming to determine which feature to use for what version of FileMaker. This is one of the reasons for the existence of the File Options feature to specify what version of FileMaker can open a solution. If you want to make your solution available to all versions of FileMaker in the same format family, just be careful the features you leverage are available across the spectrum of versions included in a format.
Just about every database solution has at least one report or form to print. When designing layouts for output, it is very important to understand the unique characteristics of the printable area for different printers. Some laser printers can print all the way to the edge of the paper but most only get within a quarter inch. Inkjet printers usually have a smaller printable area. Some inexpensive and older inkjet models can only get as close as a half inch to the edge of the paper.
Add on top of these restrictions that most of the world uses the A4 paper size (8.26 by 11.69 inches) and not US Letter paper size (8.5 by 11 inches). The difference is subtle so adjustments can be made to a single print layout so it will work anywhere in the world. The biggest concern is the width. Since there is a quarter inch difference in the width, create a print layout with the settings you desire using US Letter print setup. When you design it, just make sure everything is a quarter inch from the right margin and it will not be cut with A4 print setup.
The height of the print layout is of no concern since what doesn’t fit on one page will just go to the next page. FileMaker can slide objects to prevent blank pages due to paper size differences. Just make sure your objects fill the body part entirely and the option to resize the enclosing part in the Inspector is checked.
Why go through the effort of using a single layout for US Letter and A4 sizes? If you have to maintain two layouts for the same job, that means you have to modify two layouts every time you make a change. I always try to combine layouts for multiple uses whenever possible. The less work you have to do, the more you can accomplish.
Sometimes it is necessary to use multiple layouts. I’m not saying the best choices is to always combine layouts. You simply have to weigh the pros and the cons. If a single layout starts becoming too complex with calculations and scripts to drive the functionality, opt for two layouts. It all depends on what hoops you need to jump through to make a multi-use layout.
A lot of planning will save you a lot of time fixing mistakes!
John Mark Osborne
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window or becoming a patron. Thanks so much!