Database Reference
In-Depth Information
bad user experience. You could have users running the wrong scripts at the wrong time,
which is an opportunity for all kinds of failure. Where failure starts, trust starts to erode.
When users are on the go, they often have very specialized database needs. For instance,
since salespeople are making contacts with customers, they may just need a list of customers
and a way to review contact notes before a meeting. Warehouse people don't need customer
histories when they're filling orders; they just need to see a list of items to grab. Or stock
personnel may need a very simple interface that lets them scan a product's bar code to find
an item on a purchase order and mark the item as received.
Give users what they need to do their jobs, but nothing extra. When possible, break a task in-
to several steps, each with its own layout, so you can send the smallest amount of data pos-
sible. For example, if users need to document their daily work on a desktop computer, you
could create a single layout with one portal for entering their hours and a second where they
can create a list of materials they've used. But on a mobile device or the Web, you should
break those two tasks into separate layouts so that each one will load faster. Plus, the choices
users have to make on each layout become more prominent, so the process is easier, even
though it has two steps instead of one.
In addition to reducing layout clutter, use object styles (
Touch Themes
) religiously. Remem-
ber that objects on the layout are rendered using CSS. When you format an object with a
style instead of ad hoc formatting, you reduce the under-the-hood code that has to travel with
your data. And as much as possible, limit the number of styles you use. That is, make all
your field labels the same style, and use one style for all your fields as well. Of course, there
are exceptions—fields that use pop-ups must use a different style than regular text fields, for
example. But if you remember this rule, you'll be less tempted to make formatting changes
without a very good reason.
Choosing Layouts for WebDirect and FileMaker Go
You control which set of layouts users see by writing a script that runs when the database
opens. That way, no matter who opens the file, which platform they've viewing it on, or
which device they're using to open your database, the script runs some tests and then sends
each user to the proper opening layout for that device. Then you create navigation scripts that
stay within the proper set of layouts.
For example, the Contacts template that comes with FileMaker Pro has four different Contact
detail layouts: one each for desktop computers, iPhone/iPod Touch, iPad, and web browsers.
Within each set of layouts, the navigation always stays within the set. So you check the
user's platform at login, and there's no need to test again. Here are the two main functions
you need to test:
