
July 2000
Ten Commandments of FileMaker Pro
by Brian Dunning
digg this
article | del.icio.us
this article
Any
of us who have created something in FileMaker have had our praises
sung by our users at one time or another: it's hard to go wrong
with something so elegant and easy to use. But be warned: as easy
as it is to be exalted, it's just as easy to stumble and follow
Lucifer down the pit to eternal torment.
In the public interest, I therefore present these Ten Commandments,
which, if obeyed, will insure your eventual translation to a higher
state:
1. Sendeth thee not emails to the wrong recipient by mistake.
I worked once with a developer, who, upon receipt of a particularly
nasty and scathing email from an unhappy client, attempted to
forward it to his supervisor with the following comment: "Listen
to this (unprintable). Should we fire her fat (unprintable)?"
Please, please, whatever you do, learn the difference between
the Reply and Forward buttons in Outlook. Learn to use them effectively.
Learn not to click the wrong one, and don't reply an email such
as this back to its author, which is exactly what happened. Score
one for Lucifer.
2. Useth not the Set Crash Mode[On] command.
No, Virginia, there is no Set Crash Mode[On] command
in FileMaker. But there always seem to be plenty of people around
who think there is, usually FileMaker users who know nothing about
Define Fields or ScriptMaker, and who firmly believe that their
developer has, like Machiavelli, deliberately placed land mines
throughout a solution to "maintain control over the users."
Sorry to disappoint, but there is no way a FileMaker developer
can do anything to deliberately make a solution crash. If there
was, I'd have found it years ago to maintain control over the
users.
Sometimes elements in any file can become corrupted for no logical
reason: be it a field, the appearance of a field on a layout,
a box or a line on a layout, a script, or anything. And when FileMaker
attempts to access or display such an element, a crash can often
result. A frequent miscreant is a Windows video driver, which
can be particularly annoyed by corruption. Fortunately, much the
same way a bay leaf is often found growing alongside poison oak,
nature provides a cure along with the disease. Upgrading Windows
with the latest version of DirectX and then reselecting a generic
video driver will frequently do the trick.
3. Includeth not fonts in thy solution not present on the
client's machine.
Remember the shareware developer who distributed a bar coding
solution which relied on a commercial barcode font which his computer's
prior owner had bought and installed. The shareware developer
thought the font was built into the OS and sold his solution to
dozens of unsuspecting customers. Think different.
4. Watcheth thy field length when developing on Mac for deployment
on Windows.
Imagine a room full of students taking their final exam: for
some, a test which will determine their future; for all, a stressful
trial demanding the highest attention and effort. At least it's
multiple choice.
It's even in FileMaker. A room full of Windows computers, with
four available radio buttons for each question. Strange, about
twenty percent of the questions don't seem to have the right choice
onscreen. Oh well, better select the next best alternative.
The result? Nobody scores better than eighty percent, and the
guy giving the test springs to his feet in the middle of the session,
shouts an oath, and hurls himself through the glass window to
his death several stories below.
And on his Macintosh Powerbook's screen, the same test: only,
with Mac's smaller font metrics, all five choices are visible
for each question. Cross platform developers are encouraged to
test on both platforms.
5. Includeth not thy private comments on thy invoices.
Or, differently stated, give better, more descriptive field names
to your Public Notes and Private Notes fields in your invoices
file. So when your partner creates your invoice layout for you,
it's certain that he'll put the right one on the layout. Imagine
the private notes you might scribble to yourself to describe a
customer who does not pay, pays late, complains, and inspires
adjectives. Imagine his reaction when he sees these private notes
mailed to him on an invoice wanting more money. Imagine you'll
ever see the money? Keep imagining.
6. Testeth thy solution with the same printer used by thy
client.
Those who fail to follow this simple commandment will find that
their client's printouts don't quite fit on the page, or that
their envelopes print upside down, sideways, or both. I know of
three separate cases when an onsite troubleshooting visit was
necessary, in all cases costing the client more than it would
have cost to buy another copy of the same printer for the developer
to test on.
7. Relyeth not on plug-ins which thy client hath not.
With a little elbow grease and some clever FileMaker work, you
can get FileMaker to do most things that plug-ins provide, such
as charting, filling foreign key date fields with date ranges,
encryption, credit card validation, and so forth. However, someone
already went to the trouble of creating these functions in plug-ins,
and with some exceptions, the plug-ins are often easier to use
than the 100% Pure FileMaker workarounds. By all means, use plug-ins
whenever they make sense.
Just keep one thing in mind: solutions which rely on plug-ins
only work on computers that have installed, paid for, and licensed
the plug-in. Just because one guy in the office has plug-ins installed
doesn't mean the solution will work for anyone else in the office.
In any solution which requires a plug-in, it's always wise to
have your scripts test for the presence of the plug-in, and if
it's not there, bring up a friendly dialog that explains exactly
what needs to be installed, and how to go about installing it.
And always be sure your users are aware of the site licensing
requirements and the cost...BEFORE you charge them to put the
plug-in into their solution.
8. Placeth not data entry fields on the header part.
Wouldn't it be cool if you could have a list view, with detail
fields for the selected record in the header? A developer I know
once went a step further: placing global fields for search criteria
with a Find button in the header, and using the list view to display
the results all on the same screen. It was a last minute brainstorm
from a client who needed something quickly, and thought that one
layout would be the fastest way to finish the solution.
Sounds great on paper. Not so great on screen.
In case you haven't figured out this Commandment yet, FileMaker
does not let you enter fields which are in a header or footer
(buttons inside portals in the header or footer don't work either).
It seems stunning that this particular developer went ahead and
delivered the solution as requested; perhaps his testing procedures
were unusually lax that day, or perhaps he found that it was impossible
to enter data into the search fields, but, since the client requested
it, the client must have known a workaround. Wrong. Into the furnace
with you.
9. Thou shalt not give thy developer a due date, then add
specifications.
I am always reminded of the homeowner who hired a landscape architect,
said "Here's my yard, can you have something nice done by this
weekend?" And then, when the landscaper filled that bill, the
homeowner came back, shook his head dubiously, and said, "No,
I don't like that very much. Try something with more trees, and
a different species of grass. By the way, since today's Saturday
and I don't see that you'll have it done today, you don't get
paid."
Or the motorist who dropped his car off at the "Fifteen minutes
or it's free" speedy oil change shop, and asked "While you're
in there, please drop in a new engine block, change out the wiring
harness, and replace the chassis." Oh, it's not done in fifteen
minutes? It's free.
10. Always givest thyself enough time to finish a project.
Oops.
|