"No Holding Back FileMaker Blogging"


Navigation:


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



Document Management Videos



Become a patron of this FREE web site!


Recent Blogs:

Why then How
Why then How

Twenty-Twenty in Review
Twenty-Twenty in Review

SVG Ready
SVG Ready

Removing Text Formatting
Removing Text Formatting

Nineteen Point One
Nineteen Point One


Meta-Consulting
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:

Discontiguous Items
You can select multiple script steps to duplicate, including discontiguous ones. On the Macintosh, hold down the Shift while clicking on script steps to select continuous steps. To select discontiguous script steps, hold down the Command while clicking on steps. Under Windows, hold down the Shift or Ctrl key while clicking. You can move the selected steps, duplicate or delete them. You can even control where duplicated steps are placed. Select an additional step further down in the script and the duplicated steps will be inserted immediately after that step. Just delete the last duplicated step and you have placed your duplicated steps exactly where you desire. This process will also work with just about any dialog presenting a list of items such as fields, layouts and value lists.



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.



Create a FileMaker Calendar







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.

Excel
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.

Author:
John Mark Osborne
jmo@filemakerpros.com
www.databasepros.com

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!

Comments:

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!