"No Holding Back FileMaker Blogging"


Support this site by clicking on a sponsor below or becoming a patron!

$10.00 Beginner Video Training

Become a patron of this FREE web site!

Recent Blogs:


Multilingual Solutions
Multilingual Solutions

Why then How
Why then How

Twenty-Twenty in Review
Twenty-Twenty in Review

SVG Ready
SVG Ready

Meta-consulting is a service Database Pros offers to help other developers over programming hurdles via GoToMeeting. Email John Mark Osborne or call John Mark at (909) 393-4664 to find out more about this service.

The Philosophy of FileMaker recommends PCI!

Quick Tip:

Global Naming
Most FileMaker developers begin the name their global fields with a "g" (i.e. gMyField). This differentiates global fields, at a glance, from regular fields. In addition, it groups global fields together, so they can then be more easily located in Manage Database and in other field listing dialogs. Unfortunately, this grouping places the global fields in the middle of an alphabetical listing. A better naming convention is to begin global field names with an "x", "z" or "zz" (my preference is "x"). This will group your global fields at the end of an alphabetical listing and differentiate them better from regular fields in a long list of fields (i.e. xMyField).

Create a FileMaker Calendar

Fun Stuff:

Dull Boy
FileMaker files were stored in clear text prior to FileMaker 7 so, if you opened a FileMaker file in a text editor, you could see the phrase "All work and no play makes Jack a dull boy" in the header repeated over and over. No, it's not a virus! My understanding is the developers just needed to take up some space in the header and that's what they came up with. Today, modern FileMaker files are stored in Unicode so I'm not sure if the phrase is still there.

$10.00 Beginner Video Training

RSS Feed
Why then How
Level: Intermediate
Version: FileMaker 19
Category: General
Tuesday, February 16, 2021
I once asked someone on the forums why they wanted a particular solution. I did this because they were asking for a technique that seemed like a lot of unnecessary work. I was attempting to provide a better answer that met their true needs within the abilities of FileMaker. In other words, why give a man a fish when he really wants a fishing pole. The response I received was, "Why is not relevant to how." Wow! This guy couldn't be any more wrong. Such a shortsighted approach to programming is not uncommon which is why I'm writing this article. It's your job as a developer to ask your clients "why"! So... let me tell you why.

Why then How

The Client Isn't Always Right
When your client asks you to be on time to a meeting, he's absolutely right. When a client asks you to program a feature that's going to be slow or unnecessarily expensive, they probably aren't right. It's your job as a consultant to ask your client why they want something. This leads to more client satisfaction rather than less. Your client is the subject matter expert and not the programmer. It's your job to translate their business into electronic form, not their job to tell you how to program FileMaker.

Why then How

This may sound harsh but it's really the opposite. If you program a database system based solely on input from an armchair quarterback, it's bound to fail in terms of speed, flexibility and/or expansion. This is a disservice to your client. Of course, you need to be able to eloquently describe why a solution is not viable. But, to avoid that conversation with your client cause you don't want to upset them is a dereliction of your duty as a developer. Therefore, you need to be diligent in asking why they want something if it seems different than what you normally do.

Interviewing a Client
Most of the time, I ask a client to create an outline of their needs. There's no right or wrong way to format it. It's just a good starting point so I can interview them and fill out the requirements document more quickly. It's your job to dictate the structure and the client's job to provide the information about the problem they are trying to overcome. It's that simple but I see databases on a monthly basis that were essentially designed by the client.

BTW: I also see tons of FileMaker solutions designed by the developer alone. What you are aiming for is a joint effort between the developer and the client.

Why then How

Reporting Disasters
Probably the number one client request that I try to discourage are dashboards. It's one of those buzzwords that a client gets in their mind from some demonstration they've seen. In reality, only a small percentage of the clients I've worked with over the last two decades actually need a dashboard. That's because I ask them why they want a dashboard. Most of the time, they really just want a subsummary report.

Dashboards tend to be slow because they summarize data. This is true no matter how they are designed. If they are summarizing data live then the unstored calculations are slow. If they require a refresh button to update the values then why not just run a standard subsummary report so you are using FileMaker the way it was designed to work. Subsummary reports are easy to design so they often take less time to program. Less time means less money. And, if it gets you the same summarized information, what's the difference?

A lot of people are now using third party products like Tableau. While this technology can do some super cool stuff, you still need to export your summarized data and import it into the third party interface. This also requires licensing another product and likely paying quarterly or yearly rental fees. If you just work within the development environment in FileMaker, it can also do some amazing things with reports and charting that can save your client time and money.

While we're on the topic of reporting, let's talk about the world where most clients come from... Excel. Excel is a spreadsheet but it has been frankensteined to do a lot of the things a database can do. It kinda looks like a database but it's only a flat database. People move from Excel to a database because Excel has been stretched to it's limit. Now they expect FileMaker to work exactly the same. It's your job as a developer to educate them.

One of the most common requests is cross-tab reporting. Sure, you can do this with some workarounds in FileMaker but it requires hard coding the report. In other words, once the report is complete, it's not flexible like a standard FileMaker subsummary report. And what's the difference? Cross-tab reports look like a matrix. FileMaker reports are linear or vertical. I understand the format is different and the client is not used to seeing it the FileMaker way. But, consider the flexibility that a true FileMaker report offers. I think it's worth explaining the change to your clients.

Stories from the Depths of FileMaker Development
I have so many stories about clients who I talked out of features over the last two decades. None are really that interesting to recount. I bring it up cause of the frequency. Almost every client asks for a feature that's not advisable. Whether it's mimicking a iTunes interface or building a feature that should be handled by a human, the story is the same. Sometimes you have to convince your client not to program a feature. Do it nicely and factually so they feel good about following along in your direction.

Why then How

I was just talking to a client last week and they wanted a feature to quickly and easily move players from one team to another in order to balance out teams. His idea was to allow dragging and dropping from window to window. I was able to convince him over a screen sharing session that a subsummary report in browse mode, organized by teams would allow him to move players around just as easily. Now all he does is run the report and popup a menu of teams next to each player to switch. The subsummary report automatically reorganizes the player and he gets a great overview of the entire league so he can get a bird's eye view of the structure.

This report only took me fifteen minutes to create while the client was online with me. I duplicated an existing report layout and a script and modified them to meet the needs of the feature. When I was done showing what could be done, there really was no polishing to be done since I had reused previous work. My point is, you need to understand why your client wants a particular feature. Don't just give them what they request. Fully understand their motivation and you can provide better and less expensive solutions to meet their needs.

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!


Elzo Guarnieri 02/17/2021
  Well put! There‚Äôs a lot of truth to what you said.
Taylor Sharpe 02/17/2021
  Some people are not open to advice or help and they have blinders on to solve a particular problem without looking at the big picture. One response I have to such people is to ask them if they are open to ideas and suggestions before progressing with them because by asking them that way, it tends to open them up to ideas.
Peter Cross 02/17/2021
  The most powerful moment in my FileMaker career was during a presentation you made at ... think it was... Devcon 2003.

You said you relied on a behavior in FileMaker and leveraged how it worked. It was then that I knew that truly great programming comes from understanding the tools.

Never did thank you properly for that. So Thank you so much! I invented some really amazing stuff out of that inspiration. You are the master John.

Add Comment:

First Name: *
Last Name:
Email: *
Web Site:
Comment: *
 Email Addresses will not be shared on the web site!