Developing an app for a client, especially an enterprise system that runs a small company, can be a huge undertaking. It’s not surprising that most of us don’t really think very far past the development stage. The thing we forget is that for many users, this may be the first look they will have at this new software which is about to become a permanent part of their job success. This means, of course, that your fantastically helpful new app is about to make its first impression. Perhaps a lasting impression that will affect all future impressions. Yep – it’s the mother of all impressions.
I’m kidding a little, but perhaps most critically, successful deployment might be a real milestone that you have to meet to get paid. The last thing you want are speed bumps between you and that bank deposit. Small things can be big bumps to users who don’t really know any better. A simple thing like a tab order that doesn’t flow, or inappropriate data in a global field, can come off as a big crisis to a confused manager.
If there’s one thing I’ve learned about common developer mistakes, it’s that I’m going to keep making them. The same ones. Over and over. It’s just the way we flawed humans operate. Not only that, but I have my own set of blind spots, and each and every developer on my team has their own favorite mistakes as well. So, over the years, I have compiled a “pre-deployment checklist,” or PDC. It’s just a simple list of common errors to look for prior to rolling out a new solution. I’m sure it has saved me and my team a lot of uncomfortable moments, and gained us much more solid cred with our clients. There’s nothing new under the sun, and there’s probably nothing here you have not encountered, but it’s nice to have a single point of reference.
Item #1: Tab Order
There’s a reason why I mentioned this in the intro above — it’s so darn easy to screw up. That one last field the client asked you to place in the middle of your layout in the midst of 20 or so others? Did you go back and check the tab order immediately after? Maybe. Why not double-check?
Item #2: Copied Objects
Why would you draw a whole new field on the layout when you can copy one with all the attributes you need right there on the screen? Yes, FileMaker gives us some nice tools for styling things, and also sizing them, but an option (alt)-drag is faster and easier. Just one big problem — if that field or object has:
-
A drop-down menu
-
Calendar pop-up
-
Script trigger
-
Conditional formatting
-
A tooltip
-
An object name
-
A hide condition
-
Special anchoring…
It’s going to look like amateur hour when someone clicks into it and gets a very weird result.
Item #3: Uncleared Local Globals
We do about 99% of our development on hosted solutions. This makes collaboration possible, allows us to test in an environment closer to that of the actual solution we are working on, and best of all, heads off problems like this one: the old “value stored in a global field when the file was on my local machine” problem. As you probably know, FileMaker hangs on to a value in a global field if the file is in single-user mode. It then helpfully presents it to your users every time they access that field, unless it’s been cleared that session. This one is a pain to fix, because you have to pull your file from wherever it’s being hosted, clear the global field, and return it to its hosted state immediately. Like, right away unless you want to inadvertently re-populate that same global again. Pro tip: if you are in the habit of working in single-user mode, store all of your global fields in a single-record table, then delete the single record and create a fresh one just before deployment.
Item #4: Set the Startup Screen
Most likely, you have a startup screen specified in a script somewhere – a layout the user first lands on when they log in. This is good practice. But this is another single-user-mode gotcha. Whatever layout you were on when you closed the file in single-user mode, that’s the one that will be there when the solution opens. On a fast computer, you might not ever notice this, but on a slow WAN connection, users may see things they are not supposed to. It’s disorienting. I like to set the layout to the actual one I have scripted as mentioned above. Sure, it redundant, but it creates a less jarring experience for the user.
Item #5: Default Layout Views
FileMaker allows users to change the view of a layout by selecting View as [Form/List/Table] from the View menu. This can have weird results, and users can do this accidentally and have no idea how they did it – or how to get back. Fortunately, you can change this in the Layout Setup panel, Views tab. Each layout should, theoretically, only have one view checked. FileMaker cheerfully checks them all for you, by default.
Item #6: Privilege Set Testing
That script is a thing of beauty, a real sight to behold. Logged in as [Full Access] anyway. But is it working when the user is blocked out of half a dozen related layouts by the priv set you’ve pigeonholed them into? Maybe you should check. We’ll wait.
Item #7: Hidden Tabs and Navigation Dots
We used to develop lots of solutions with “hidden tabs,” meaning tab panels that have been made essentially invisible. As a shortcut, we would expose those tabs temporarily while working on them, then hide them again later. Except we didn’t. And it looked junky when we forgot. Later, we started using slide controls for this purpose, but we we still sometimes forget to hide those pesky navigation dots.
Item #8: Enterable Fields in Portals
This may be the most debatable item in this list, but I’ll go out on a limb: data should not be edited without context – meaning if you have a main area where some data gets entered or edited, you don’t want users editing it somewhere else like a portal where they have far less information to help them understand the ramifications. Most often, when I find a portal row with editable fields, it’s an oversight.
Item #9: Custom Menu Set
Custom menus are a great way to control what users can and cannot do. You need to make sure that a default custom menu set has been chosen for the solution, and that the appropriate set gets loaded depending on the user’s privilege set and what layout they are on. Easy to forget when you are always logged in with [Full Access] privileges (see #6 above).
Item #10: Security
Security is a complicated subject — there’s not only the setup on the client, but also the server. Here are a few things you may want to check:
-
Have all privilege sets been accounted for? We like to send a spreadsheet to our clients to fill out with create, edit, delete, and view privileges specified for the various layouts in the system.
-
Have extended privileges been set up as needed?
-
If you are using external authentication, have you set up Active Directory, Open Directory, or some flavor of Oauth?
Item #11: Full Access Control
We like to set up a developer privilege set that uses external authentication while we are working on a hosted file as a team. This can be a security risk when the files are deployed to a different server, so this set needs to be disabled and, preferably, deleted prior to rollout.
Item #12: Client Disconnection Settings
Making sure users can not only get in, but stay in is an important part of helping users feel less anxious about the advent of a new app. Security requirements vary (HIPAA, for example, requires frequent screen locking); but here are some things to check: first of all, check your fmreauthenticate extended privilege. Secondly, you need to pay attention to the idle time disconnection settings on your server. Lastly, the user has some control over the password dialog when they log in, such as keychain and touch bar settings — it’s worth educating them during training.
Item #13: Final Code Review
This item should possibly be first on this list, since it may be too late to do anything meaningful about it once you are about to deploy. Your code should be well commented, and broken code should be fixed, before your system goes out the door. All too often I have opened one of my own solutions a few months later, and wondered what heathen has hacked my code and rearranged it beyond recognition — only to realize it was me. Comment your code. Big, BING, bing — the more you know. Third part analysis tools like FMPerception, Analyzer, and Base Elements can show you what’s broken. Even if old, abandoned code that no user will encounter is what it finds, you should deal with it somehow. Didn’t your mother teach you to wear clean underwear in case you get run over? You never know who will end up seeing your files under the hood some time down the road.
A Gift for You:
Wow, this got a little preachy toward the end, there. No apologies, I’m just passionate about some things. I hope this little checklist will help you make a stellar impression on your clients. To that end, I have included a FileMaker file to help you manage your deployment pre-flights. Just fill out the form below to receive a free download link.
Recent Comments