FileMaker Pro 9 added support for ESS, Script Groups, Conditional Formatting, and more. FileMaker Pro 10 added Script Triggers, dynamic reports, saved finds, the ability to send mail via SMTP, etc. FileMaker Pro has come a long way in a short amount of time.
So, what's still missing? What functionality do we still want or need that we don't yet have?
Below is a list of what I and a few other FileMaker developers that I spoke with (including Hal Gumbert of CampSoftware and Jonathan Stark) think is still missing. Think of it as a "wish list" for what we hope to see in FileMaker Pro 10.5 or beyond. Here's the list, in no particular order...
We've had the ability to group related scripts into folders since the release of FileMaker Pro 9. I'd love to see a similar concept applied to layouts. Extending this idea a bit, it would be nice to be able to specify permissions at the layout folder level instead of having to specify them for each layout.
Filtered Table Occurrences
As someone with a strong background in SQL, I was excited when the concept of table occurrences was first introduced way back in FileMaker Pro 7. At last, I thought, we have support for views! In the SQL world, a view acts very much like a table, and can be used to provide access to a subset of the data in an actual table. For example, you can restrict the columns available, as well as the rows available -- and views can also include data that is joined from multiple related tables. Views are a great way to add a layer of abstraction to the underlying tables, and can also be used as a way to control access to data.
But FileMaker's table occurrences do not provide the power that SQL views do. They are simply a way to have a single table be represented multiple times on a database's relationship graph. They are mirrors of the tables that they represent. You can't specify which fields are available through a table occurrence, nor can you specify which records are available through one.
I would be thrilled to see this filtering functionality added to table occurrences. I'd also like to be able to specify table occurrence-based permissions as well.
Table and Field-Based Script Triggers
In an email conversation with Hal Gumbert, he mentioned that he'd like to see support for more event types. Hal wrote, "I think that events should also be on tables and fields. On Record Create, Modify, Delete and such. For Fields, on Create, Modify. Right now you can only run triggers via the FileMaker interface, but not via custom web publishing or importing. If these were on the table, you might not need to set the triggers on every layout in the database."
I agree! What we'd have at that point is something more like triggers in the SQL world. Think about how powerful those types of triggers would be! You'd never have to worry about whether a script was executed when data changed. For example, scripts could fire when records are imported. They could also be executed when records are added, modified, or deleted via Web interfaces or ODBC connections.
Hal also mentioned that he would like to see events related to the WebViewer as well. Specifically Hal would like to see "On Error, On Load Complete, On Form Change" events. I can see the value of those new event handlers as well.
My clients always seem thrilled when I find clever ways of using the WebViewer in the solutions that I build for them, so anything that would make the WebViewer more powerful and flexible would be welcomed. In my conversation with Hal Gumbert, he said, "I'd also like to see more functionality with the webviewer to run scripts from the webviewer. We're using the MBS plugin, but there are issues with it. It would be nice to access page elements from FileMaker." Another great suggestion!
"Execute SQL" Script Step Enhancements
The Execute SQL script step, which gives us the ability to execute any SQL statement, has been frozen for so long now that I've almost given up on it ever being enhanced. But it is time to dust off that function and do something to it. Sure, it does give us a way to execute stored procedures from within FileMaker Pro. But my big gripe with it is that when you use it, it's like shooting into the dark. You have no easy way of getting back the results of the SQL statement. So if you call a stored procedure with it, and the stored procedure returns results (as either output parameters or a recordset), you can't see them. While I've found a way to work around this (and you can get this type of functionality using plug-ins), it sure would be nice if the work around wasn't necessary. And this enhancement would complement the ESS functionality very nicely.
It would also be nice if the Execute SQL script step acted like ESS does, where in a server environment, clients could execute SQL using the server's ODBC connection (instead of needing their own).
More Comprehensive Conditional Formatting
Conditional formatting is one of those functions that I wonder how I've ever lived without. And some of the tricks that you can do with it make it even more powerful. However, it would be nice to see conditional formatting extended to additional layout objects and layout parts as well. For example, to change the background color of a layout part based on a condition.
It would also be nice if you could hide an object entirely under certain conditions. Sure, you can simulate this by doing things like making text color the same color as the background. But it would be very nice if you could really hide an object.
With tab controls we can simulate the concept of "layers" in FileMaker Pro. With script triggers in FileMaker Pro 10, simulating layers is now even easier. But this still feels like a kludge. I find it difficult to manage the tab controls with the border turned off, empty tab names, etc. It would be nice to have support for real layers.
Jonathan Stark suggested a similar concept, something that he referred to as "Layout Portals." He wrote:
I wish it was possible to embed a layout inside of another layout. If we could do that, the first thing I would do is stop using portals in favor of embedded table views. The workflow would go like this: You build an "Invoice Item List" layout based on the InvoiceItem table occurrence. Then, you build an Invoice layout based on the Invoice TO, and define a Layout Portal that points to the "Invoice Item List" layout, but you base the Layout Portal on the "Invoice to InvoiceItem" TO in order to limit the Invoice Items to only the related records.
Furthermore, I'd have settings available in the Layout Portal Setup dialog that would allow you to override the defaults set on the actual layout (like changing views, modes, auto commit, etc...)
Now that sounds very cool!
To a large extent, indexes remain a mystery in the FileMaker Pro world. We have very limited control over them. It would be very nice if we had the ability to create indexes manually, based on the fields that we want included. It would also be nice if FileMaker Server had a way to suggest indexes based on an analysis of long-running and/or frequent finds being performed.
Ultra-Light FileMaker Pro Clients
This one isn't as important to me as it seems to be to other developers. A number of developers that I have interviewed over the past few years have mentioned the need for a lightweight, less expensive, "light" version of FileMaker Pro, allowing access to FileMaker Pro databases in a network environment. This "ultra-light" client would be stripped of the functionality needed to create or modify FileMaker databases. The reason that developers seem to want this is to make FileMaker even more affordable.
Client Installation from FileMaker Server
Wouldn't it be convenient if, in a network environment, we could install FileMaker Pro on our client machines by simply making a request to FileMaker Server? Server could keep track of the number of licenses purchased, the number in use, etc.
In an email conversation with Jonathan Stark, he combined the "ultra-light client" and "install from server" ideas into a single concept that he referred to as a "Zero-Install Thin Client." He wrote:
There should be a free "lite" version of FileMaker Pro that allowed anyone to connect to a FileMaker file hosted on server. It should work basically like the server admin console - browse to a link, download a little runtime, and boom - my mom has read/write access to my FileMaker database, without any install on her machine."
What a great concept!
Hosting Services Available through FileMaker Inc.
Another interesting concept that Jonatahan Stark mentioned involves hosting services provided directly by FileMaker Inc. He wrote:
FileMaker, Inc should offer hosting services. Newbies could host their files on FMI servers and pay based on bandwidth, number of connections, or size of database. In conjunction with my first suggestion, this would give the average joe an adoption path for the platform. Imagine: I am an entrepreneur with an idea, but scant programming skills. I download 30 day trial of FMP and build a simple file. I host it with FMI for free using their "basic" package service level. I can email links to the file to my mailing list. People can interact with the file with the zero install thin client. I start to get a lot of data in the file and I need more bandwidth, so I graduate to the "silver" hosting package and start paying $24/mo for 30 connection, or whatever. My 30 day FileMaker Pro trial period ends, so I buy a license for FMP. Etc, etc, etc... before you know it, they'll be buying FMPA and a membership to tech net.
Integrated Version Control
Ok, I'm really dreaming big now! But imagine FileMaker with some sort of integrated version control system in place. FileMaker itself could keep track of changes to layouts, table definitions, relationship graph changes, script changes, etc. Yea, I'm dreaming.
Here's another interesting idea that Jonathan Stark presented. Ever look at a FileMaker Pro solution, and at something in particular (maybe a field or layout) and wonder if it safe to remove it or not? In other words, are there other objects in the database that are dependent on it, and if you were to delete this object, those dependent objects would break? Jonathan writes:
I know that there are 3rd party applications that will show you which objects are dependent on others, but it would be great if that was built into the application, and extended with logging features. Is this script called by any buttons, menu items, events, or other scripts? When was the last time this layout was viewed by a user? Has this button ever been clicked?
These are all questions that can't now be answered, which lead to cruft build up, and eventually unmaintainable solutions.
Unit Testing Macro
Another interesting suggestion from Jonathan Stark:
From a purely developers standpoint, a big drawback of FileMaker is that it is basically impossible to automate testing. Developers should be able to build a solution against a set of tests, and run those tests in an automated fashion at the click of a button. Delete a field and run your unit tests - did all tests pass? Yes? Sweet. No? Revert to back up. Lack of automated testing is a deal breaker for the big boys in enterprise IT.
FileMaker API for PHP Enhancements
If you've ever looked at the large amount of information returned by FileMaker when using the FileMaker API for PHP, then you know where I'm going with this one. There is a LOT of meta data returned that, for me anyway, typically isn't needed. It would be nice if we had a way to make requests and choose to have the non-critical data suppressed. I think we'd see a very significant jump in performance as a result.
It is important to stress again just how far FileMaker has come over the past several years. Longtime FileMaker developers will tell you that FileMaker Pro 7 marked a turning point in FileMaker Pro's evolution, and that it has been a fun, wild ride ever since. There are features built into FileMaker today -- features that we're probably starting to take for granted -- that just a few short years ago were either impossible to replicate or required expensive plug-ins. In other words, this is by no means a list of gripes or grievances. FileMaker Pro 10 is a fantastic product, and FileMaker is a great platform that just seems to get better and better.
When I asked Jonathan Stark what he felt was "still missing" he wrote: "I feel strongly that FileMaker is feature complete. If FMI never added another thing to it, I'd be cool with that. However, from a business standpoint, I have a concern: there are no young developers. I believe that this is due to the fact that there is no painless (i.e. free) way to get new people addicted to the awesomeness of the FileMaker platform."
Do you think that there is something missing from FileMaker Pro 10? Got something you'd like to add to the wish list? Let us know!