I think it is time we stopped getting too worked up about product version numbers. FileMaker is not a Product. It is a Platform. Platforms are different. They don’t really have a product release every 2 to 4 years. They have regular releases of whatever is ready to go. That’s why I don’t care much about the number 17. It has great new features and capabilities that once again improve how we approach how we build apps, just like last years big game changer. Let’s take a closer look, shall we?
Missing the Point
I see a lot of bitching about how FileMaker 17 should be FileMaker 16.5 because it doesn’t have enough new features for end users to get a new version number. Frankly, those forum posts are missing the point. First, this release does have several game-changing features and capabilities. Second, as I just said FileMaker is a platform, not a product. If you know the difference between the two, all this kvetching over a given release and its number seem pointless. We get a new version every year. It always includes new great stuff. The next batch of new stuff is about a year away.
FileMaker 17 Features I won’t be Talking About
Most of them :-). We’ll have other blog posts that will go into more detail on each of the new features and how they work. In this post I want to focus on just a couple that I think have major implications for the platform and not necessarily because of what they do specifically in your apps, but because of how they might affect how we approach building high-value FileMaker apps for our organizations and customers.
The End Of a Two-Class System
FileMaker 17 Pro Advanced is now the only Desktop client. There is no more FileMaker Pro. That means that everyone has access to the advanced tools: custom functions, the DDR, custom menus etc. Everyone can copy and paste the code. Everyone can take advantage of RealTime Developer Intelligence Tools like FMPerception and Analysis Tools like Base Elements and Inspector Pro.
There are no more “haves” and “have-nots”. Just “haves”
This means that product developers can no drop the ridiculous work-a-rounds to handle the fact that most of their customers wouldn’t be able to copy custom functions into their files.
Modular FileMaker 2.0 Guidelines when they are released at FileMaker DevCon 2018 will drop the guideline about not using Custom Functions completely. I was famous for advising against Custom Functions in the past because it decreased the likely hood that code could be re-used by other people, who didn’t have advanced. Since it was focused on sharing code, Modular FileMaker 1.0 Guidelines suggested not using them. While I have moderated that position over the years somewhat, but now we can embrace them fully.
Since everyone is on an equal playing field now it will be easier to teach people to share code and build products that everyone can use.
Less UI Hacks, More Business Logic.
I spent years developing workarounds to UI limitations in FileMaker. Back when we got one release every 30 months and they NEVER included new UI widgets and patterns, this might have made sense, but FileMaker 17’s Master-Detail feature has convinced me that is no longer a good use of time.
Over the last couple of years, FileMaker has added major new UI features that change the way you might develop your interface. We have Popovers, button bars, Top Nav, Card Windows, just to name a few. With this release, we get Master-Detail. It no longer makes sense to waste cycles building up massive leaky abstractions like my old version of MasterDetail.
Instead, I think we should focus on the parts of our system that aren’t going to change as much, the data layer and the logic layer. Maybe design systems so you could rebuild the UI at any time, without having to rebuild the data layer and the business logic.
The fmDatamigration tool is a game changer. Using our soon to be released Otto product, we have fully automated multi-file GB data migrations going from Development servers to Production servers in just minutes. That is not a typo. GB data migrations from server to server in just minutes! The implications of this are massive and wide reaching.
You may still choose to separate your solution into multiple files, there are many reasons to do so. But avoiding data imports no longer needs to be the reason to do it. Becuase you are free from worrying about data imports, you can find different ways of separating that make more sense for your scenario. You might want to make some features more of a self-contained module that can be maintained separately. Or you may shover everything back into one file. It’s up to you.
Live development on production servers has always been frowned upon. But it was almost a necessity because some systems could take hours or even days to go through the data migration. That excuse is now gone. If you run a busy complex FileMaker solution, you should be doing development on a development server, and doing regular automatic migrations.
The Data API is Out of Beta
The Data API is now out of beta and includes a tiered pricing model that fits nicely into the new simpler overall licensing model. Finally, we have a pricing model that makes sense.
Developers can feel confident about building on top of the new Data API, because it is official, and generates revenue for FileMaker. I know some folks wanted it to be free so they could get around FileMaker License costs, but really that is a very shorted sighted view. If you rely on the FileMaker platform you should want the vendor (FMI) to thrive.
This year’s release ( notice how I didn’t say “17” ) includes a number of compelling improvements both to the end user experience and the developer experience. It is another step in a continuous process of improvement. Each year it gets better and better, and we would do well to work that fact into our plans.
Also published on Medium.