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...
Layout Groups
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.
WebViewer Enhancements
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.
Layout Layers
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!
Real Indexes
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.
Dependency Tree
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.
Wrapping Up
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!
31 comments:
- Platform-native GUI elements (scrollbars, buttons, etc.)
- On the Mac, Bento-style (but better!) integration with Address Book, iCal and (dare we hope?) Mail
A lite client is very needed, especially in larger organizations. We need a quick and easy way to manage clients and version installs as well.
As much as we would like a lite or thin client, clients are FileMaker's revenue base. If it's lite, they cannot charge as much for it, and then they possibly would not have money for R&D. Install form server is an excellent idea, I hope they implement it. We might as well add plug-in management so they would be installed and managed from the server. I would also add searching and sorting the TOs in the table graph. FileMaker 10 is an excellent product, we got a handful of new features that will keep us busy until the next release, though.
@MiGrant: Amen
My second favorite feature request is offline forms. Imagine a scenario where the FileMaker runtime is a free general purpose runtime akin to Adobe Reader. This way you could build a form in FileMaker, complete with validation[1], value lists, scripting, etc. Now you could simply "tear off" the form and send it to a client to be filled out--just like Adobe form files--except that you need only drag and drop it back on to your database window to add the info back to the system.
To mimic this level of integration now, one must resort to web publishing. Each form which can be created in minutes using FileMaker Pro will either need to suffer the limitations of IWP or be painstakingly recreated in CWP. Offline forms wouldn't require a web server, an SSL certificate, or web programming.
The upside to this would be huge for FileMaker, because the free runtime would help introduce the FileMaker experience to many potential clients who have never heard of it. Brand awareness, coupled with increased productivity make this feature a huge "win win".
_____
[1] I know that validation in FileMaker leaves a lot to be desired, but don't get me started...
@Agnes - I see where you are coming from with your comment about a thin client cutting into FileMaker Pro sales, but I would argue that it could be more than made up in the following ways:
1) If FMI offered hosting and the zero install thin client was only available from them, they'd be making monthly subscriptions fees.
2) If FMI didn't want to get into the hosting business, they could charge a premium for a version of FMS that offered a zero install thin client. I would pay $5k for this without thinking twice.
3) A zero install thin client would drive new people to the FileMaker platform, many of whom would never have bought FileMaker Pro in the first place.
Risky? Yes. But desktop software is on the way out. It's time to take steps away from that model and sell the legendary ease of use as a service. In my mind, FileMaker Pro strikes an unparalleled balance between power and ease of development. Where it completely falls down is deployment.
Think about it - FileMaker has been working off of the same basic DNA for something like 25 years! Furthermore, look at all the time and effort that they've put into preventing piracy in the last couple of releases. It's annoying to customers and ultimately a losing battle. Time to evolve or die.
FileMaker has a very respectable user base and solid reputation which puts them in a unique position to dominate the RIA arena. I keep tabs on the players in this field and there is no clear leader at this point. If FMI came out strong with a zero install thin client, they'd destroy Flex, Servoy, DabbleDB, CogHead, and anything else you can think of.
I have thought about this a lot and could go on and on about ways to make the business model viable, and to make the transition without compromising the wonderful ecosystem that surrounds the product, but I should shut up for now.
Just my $.02
j
I'd like the ability to turn relationship entries on and off without deleting them during testing.
If you've got a relationship that contains a lot of entries (think portal filtering) you're generally doing a lot of testing to make sure everything is working properly. Currently you have to delete an entry to find the problem one. I'd like a checkbox beside each entry so they could be toggled on and off (like in Conditional Formatting).
Tim,
Nice list, well thought out. There are many good ideas here. Wanted to let you know I was paying attention.
--
Rick Kalman, Sr. Product Manager Desktop Products
FileMaker, Inc.
@Rick: It may be a small gesture, but it is very much appreciated. Thanks for the good work; we can't wait to see what you guys have cooking.
Regarding web viewer, one simple thing that already has some traction and understanding within FMI is to enable OnObjectModify for the webviewer, with the result being the updated object source. I have demonstrated this with a few similar techniques, and basically with this you would have a GET form submit "talking to itself" and you would be able to parse the result and act on it.
The ability to do anything by calculation.
For instance, go to field by calc, go to related record by calc, or and this is a big one. Perform script by calc. This would allow designers to make a clear naming convention and I can make the entire database design flow by hows things are named.
A full webviewer. I want to put info in and get it out.
A script trigger from when ever you can enter the calc dialog box. Like Zipp script
Oreste
Almost all of the items on this list are in most other development platforms and FMI is playing catch up! However at the speed FMI is going, when considering the speed that the other platforms are moving forward... FMI has no future!
IMHO, FMI is stuck in a rut with a system based very much on 25 year old code without the financial resources or the guts to really look at it afresh.
They are a company led entirely by their marketing department who make big of features that are only half implemented or are even just a bug fix. Take for example the new Server 10 import/export feature - but only CSV files (not mentioned in the marketing). It will not import or export FMP to FMP tables (e.g. for archiving) or Excel or through ODBC. Pretty useless then! They added SMTP to send emails from FMP but only plain text! Wake up FMI, much of the world uses HTML emails. The changes made to the Print (default) have completely messed it up for anyone in a workgroup or developing products. After all these years why can't we have two script steps - Get(PrintersList) and SetPrinterByName??? Triggers are only on the interface layer and not the data layer. We still can't use variables or other calculations in field validation. Show Custom dialog with input fields still returns no data if you click button 2 or 3. And we can't use variables or calcs on the button names either.
The Layout Layers idea has been in Servoy for 4 years or more (BTW, I'm not a Servoy developer).
The world is moving fast to Web 2 and FMP pretends that's not happening. Have you looked at solutions like http://280north.com/index.php which was written in all of 3 months?
All our clients are asking for web access and SaaS style applications. Why in the world would anyone write a new solution in FMP if it needs this type of access? They wouldn't! Unless FMP is all they know... and there's the catch... and that explains why there are no young FMP developers, not just because they don't have a free or lite edition, but because FMP is now way behind the curve.
We develop a lot of products which are a nightmare to update because of the way FMP still ties its data and interface layers together. We use TSM (The Separation Model), but that only solves a few problems. If we need to make changes to the data schema, we still need to perform a full import of all the data. Could we have a SQL-esque way of scripting changes to the data schema? I'm not holding out any hope on this feature ever being delivered.
I think the list is great and offer my compliments to all who have contributed to it. But the reality is that FMI sales are shrinking and IMHO, FMP will not be around for long unless they have a complete web 2.0 rewrite going on, which I strongly doubt.
What I would like to see in FMP is a development environment (FMPA) that output the *entire* solution in PHP. They should also offer a completely new server solution (PHP clients only) and their licensing model would then be almost entirely on concurrent connections to the server. Of course you should still be able to run it on any SQL compliant server if you so choose.
But it's not going to happen! Wake up and taste the coffee. FMP is way too far behind the curve and has no chance to catch up. FMP 10 is a fantastic improvement over 9, but it is also a HUGE disappointment; clearly identifying that FMI will continue on their unique tangent... which is not where the rest of the database/solutions market is going. Worse still, it is not where your clients will need you and your development environment to be in 2 - 5 years time.
FMP 10 is the warning bell to find new technologies that offer you a future. There is no future for you if all you know if FileMaker and wait and wait and wait for FMI to fulfil your list of dreams.
Good luck dreaming and posting feature requests. Marketing gimmicks will win over your feature requests and you'll still be dreaming in a couple of years time for Layout Layers and data level script triggers and all the rest. But unfortunately, you'll have no business left by then! Or, if you're one of the many older developers, you might be retired by then, in which case none of this matters! :)
Programmatic Manipulation (CRUD) of FileMaker MetaData - ie. buttons, fields, layouts, scripts
(like hypercard could do many years ago...)
example
CreateButton()
CreateScript()
CreateLayout()
CreateTable()
Why?
So I could take the DDR as input and recreate the filemaker database
then I could EDIT the DDR and then recreate the filemaker database
then I could do all my development in a text editor editing the DDR
then I could commit the DDR to SVN or CVS
then I could esily DIFF and compare versions
then I could easily have multiple developers working on the same projects
PLEASE!!!!
shameless plug:
check out free filemaker hosting for FBA / Technet and charities at http://store.neocodesoftware.com/
1. FileMaker needs to update their Active X Automation in windows to allow script parameters and setting of fields and other FM tasks.
2. The Send Event script step could us an additional option that you could check to wait for the event to finish and return the result to FileMaker.
3. The XML import script step needs some additional parameters to allow you to post headers and post information for web services that require posted xml documents and that don't allow REST or GET requests.
@Anonymous: "Almost all of the items on this list are in most other development platforms and FMI is playing catch up!"
FileMaker has always had fewer features than it's competitors and it has never harmed it's business. A product is not equal to the sum of it's features; Apple epitomizes this concept. FileMaker has been profitable every year since inception and has always been marketing-driven, while the road is littered with "superior" products from large and small vendors alike.
You aren't arguing about specific features--or the lack thereof--but long-term strategies for growth. If FileMaker doesn't properly position their product line during the next major milestone (i.e., I'm not talking about v-revs) release then you might have a point. Only the future will tell.
We've had four (4.5 if you count 8.5) v-revs since 7 came out. I wouldn't be surprised to see a significant milestone release some time in the next 2-3 years where you will see a revolutionary leap instead of the current evolutionary updates that we normally see every 18 months or so. I can't wait to see what the FileMaker product will look like, and I'm far less skeptical than you are.
What would I love to see from the next milestone release of FileMaker?
Mimic Apple's success in the OS space. I.e., ditch proprietary FMP technologies and start anew using best of breed solutions and standards. Tie them together and make them easy to use. Specifically, implement something like this:
1. Replace the database engine with a robust open source database engine for FileMaker server or an embedded engine like SQLite for local usage. Mask the complexity of server configuration with a simple admin console like we have now. Allow experienced db admins to tweak server settings to their heart's desire.
2. Replace the current medieval presentation layer. The recent UI refresh only applied to window chrome; our database interface still looks like the now two decades old Mac OS. Adopt a standards-based UI based entirely on Webkit. Webkit provides exactly the same typographical representation on Mac OS X or Windows, so you would no longer be forced to deal with cross-platform font metric variations. HTML/CSS is already capable of creating the next-generation dynamic style of interface design. By default, controls will inherit the platform-native look and feel, but can be overridden using style sheets.
3. Adopt the best of breed SproutCoreJavascript framework for controlling events and element behaviors. This will allow an interface developed in HTML/CSS to look, feel, and behave like a traditional desktop application. SproutCore adds additional form elements and enhances existing form elements.
4. Adopt PDF not just as an export format, but for all reporting. Don't license the expensive libraries from Adobe. Build it yourself based on open specs like Apple did. Doing it yourself will allow you to generate reports server-side or via the publishing engine.
5. Keep Scripts around for beginners, but allow developers to code in Javascript.
Chew on this for a bit. IWP tried but fell short of delivering on the promise of writing a database once and deploying it on a LAN, WAN or Web with relative ease (assuming you were willing to sacrifice some features for web deployments). If your entire presentation layer is based on HTML/CSS and SproutCore, and your entire output engine was based on PDF, there's almost nothing that can't be done in a web-app that can be done locally. In fact, the FileMaker client could be nearly reduced to a glorified Site Specific Browser (SSB), and FileMaker can adopt a flexible per client licensing model that works for either web or network clients.
FileMaker will be tasked with tying the pieces together in a fashion that is simple for the average person to use, but powerful enough for developers to tweak and extend.
If you think this sounds a bit like Servoy you'd be right. One significant difference is that Servoy relies on Java for presentation, which I think is a mistake. Servoy also doesn't attempt to capture end users and beginners in the same way that FileMaker does. It is much more of a developer product which I think limits their market potential.
I do agree that the window is beginning to close on the niche that FileMaker has enjoyed all these years. I think they have sufficiently smart people on board to recognize how the market is changing, and the nature of competition from new SaaS solution providers. Let's hope that they have a good plan to properly position their products for the future.
- Dave
Next thing I would like is per user or per connection licensing like Microsoft server licensing.
Example - FileMaker Server for 5 users is $250
add another 5 users for $250
add 100 users for $750
this would allow everyone to have server...
The one thing I've been waiting for for years is layouts based on templates or master layouts as in page layout programs. Create a base layout that you will want to use in your solution. Like the colors, graphics, common buttons with scripts, etc. And then create layouts based on the master to which you can add unique items for a given purpose. The beauty is that if you want to change the look or the scripts for the common elements, all the layouts based on that master would update as well. Think of the time savings! What if you had 20 similar layouts and you could make changes on one master and those 20 layouts would be updated! This should be possible I would think.
I add my support to...
1. Zero Deploy/Thin client:
Big one for me too. Think would drive a lot of new business for Filemaker for Vertical Market Apps and truely deliver Filemaker as a Platform.
FM Devs are turning to Citrix & MS Terminal Services to deliver similar function. Problem is with hardware, software you can be talking $1000 cost per user before you even start developing, that immediately cannibalizes sales as Dev's look elsewhere for cheaper scalable options. If Filemaker could offer some kind of SAAS as Johnathan suggests they would open a huge market to sell more licenses of the core engine. "Filemaker App Store" anyone?
2. Scriptable HTTP POST & GET: With filemaker ease of use sprinkled on top (native functions/scripts) - could then interact with 3rd party API's via XML & the Webviewer. Maybe some kind of setup wizard for frequent used services (Pre-made XLST's) - Address Book, iCal, GCal with ability to add new Connectors.
...if they could get those Sources onto the graph then Web would become one big EDS Source to plug into.
3 Some others
- Forms within Forms - (eg. Table in Tab panel instead of Portal)
- Full separation option.
- Data level script triggers.
- Nice new UI Widgets + give table view some UI options.
- Few basic OS level File/Folder script functions. eg, open, new, delete, exist etc
- Native Encryption Functions.
- Native SQL functions (would go someway to the CRUD request above eg. Create Table, Field, Insert data from update script)
- Fieldname Aliases would be nice. maybe with the SQL View idea - 'field x' AS 'field y'
Phew..that’s enough for now...back to trying to master FM10.
Dave's suggestions are certainly ambitious, but I think they would be difficult and dangerous to implement. Something that radical would be bound to break a lot of existing Filemaker databases, and the company's existing users wouldn't be happy.
Personally I'd like to see enhanced integration between Filemaker and standard services on the Mac OS such as Address Book, iCal, Mail, etc. I know that Filemaker is a cross-platform product, so adding this sort of integration is problematic for Windows products. I'm hoping that Bento develops into something like a bridging solution. Bento DOES integrate with the Mac OS, and now that Filemaker 10 can import from Bento, there's an easy bridge between Filemaker and all that OSX goodness. I'd like to see this develop further into true syncing. Right now I can import from Bento into Filemaker, but there's no good way to move changes back, so I still can't do things like sync Address Book with a Filemaker contacts database.
I'd also like to see enhanced ability to work with web services via their APIs. For example, I use Basecamp for project task management, and I've found a service that lets me sync Basecamp's to-do lists with my personal to-do lists (for which I use OmniFocus). Currently I'm developing a specialized Filemaker database that includes a "tasks" table related to financial regulatory compliance for a nonprofit organization. If I could sync this "tasks" table with Basecamp, I'd be able to integrate it with the other systems I have for managing to-do lists, which would be a nice win.
My wish list:
- ScriptMaker should be overhauled to allow real text editing/importing/exporting of scripts. I'd like to use my favourite text editor for scripting. It's silly to hold onto the notion of "no programming required" when, frankly, all that clicking and selection of script step options can be more tedious than just typing.
- An "empty matches all" option for relationships. When creating a relationship each key field must contain a value for the relationship to yield any records. Eg, a "colour" field would have to list every colour entered in the related table (or some "all" value) in order to show all records. I'd like an option to match all related records when the key field is empty, rather than having to kludge a way to match all records.
- Fewer dialogs. Some functions (notably, text formatting and tabs) still require opening multiple dialogs, clicking buttons within dialogs, or dialogs on top of dialogs. This just shouldn't be necessary in version 10 software!
- Better ways to import/export/organise custom functions and custom function libraries.
- More support for basic OS functions. Most file management functions (eg, creating/deleting/renaming folders) should be built-in; it's silly that we still need plug-ins for these. Same goes for shell scripting: we have built-in PDF generation, but still no script step to "execute Unix/Windows commands". Crazy.
I'm trying to work more with multiple windows which leads to these two requests:
1) Only being able to reference windows by Name dangerous. Every time I do it I shudder a little over the fact that there may be another window open with the same name - maybe from another FMP solution. We need Window IDs to positively identify windows.
2) Window management is horribly complex in FMP. We can now save finds by account, let's add the ability to save window location by account. Every time a specific window is opened it moves to the location, size and options as the last time it was used. This should work whether or not the window was opened by a script or a user. It would free our users up to control their own window placement.
Bob Gossom
Hi Tim,
Nice list you made! Besides improvements for end users, I would also like to see some small and simple improvements for developers:
- Adding line numbers in the Script Manager would help multi-developer teams referring to scripting bugs
- Line numbers could also be used in error messages
- Some simple code highlighting, like the corresponding End If statement of an initial If statement would be extremely handy
Jeroen Aarts
Great suggestions all! I would like to see a consistent experience in regards to copy / paste and folder organization. What you can do with scripts should also be available for custom functions, custom menus, value lists, layouts, etc...
When defining a value list with "Use values from field:" we can pick two fields, and sort by either field. But when we chose to show values only from the second field, why can we not still sort by the first field?
Integrated Version Control would be nice but even Data Time Modified and Date Time Accessed would invaluable for managing scripts and layouts in large applications
Unified security. We need to be able to use a FileMaker table to define accounts with login information that will work across all files in a solution. I always use the separation model and it's tedious to have to define the same accounts for multiple tables.
I'd love to see scriptable layout objects (size, location, create, name, hide, show, etc.) and HTTP POST capability in web viewers, especially with the data length limitations on the GET string.
For years, I've been wishing (and occasionally asking for) the ability to edit scripts in a text editor.
Except for the HTTP features, these are things that were all available, well implemented, and eminently functional in HyperCard. Try as I might, I cannot come up with any explanation as to why these features are not available in FileMaker beyond, "because the original reason HyperCard was discontinued was because it was free and FileMaker -- HyperCard's natural heir -- is not, and carefully dribbling out features a few at a time provides a virtually guaranteed revenue stream that requires only a minimum of (expensive) actual innovation in the development process."
I would love to be convinced that this perception is in error, but I have seen nothing to effectively contravene it.
Open Type fonts support. Properly, with the postscript bit turned back on that we lost at version 7.
I need it to make databases work with the style guidelines of my corporate clients, and no-one takes me seriously.
MS WordPad can do it, and no-one can explain why the most exciting development in typography in recent years is being completely cold shouldered.
Sorting Millions of records takes many DAYS in FM 8 (if it does not crash while doing it) and many hours in FM 10. By placing FM 10 in RAMDisk 1.0 (2 GiB) a 75MB file will take at least 2 hours when sorted on 2 fields. (I am ever so happy I found RAMDisk for OS 10)
Whatever I have tried - when saving the SORTED file - the sort order is gone when the file is reopened. The sort order reverted to RecordNumber order - which took quite some time, because before being able to Save it appears FM first has to "un-do" the sort.
I imagine the SAVE AS command is routed to the RECORDNUMBER Table to SAVE the Records in the - according to FM - "correct" order.
Is there any way to get FM to SAVE AS SORTED.
-Either with limited any user input - user marking the option SAVE AS SORTED;
-With EXTENDED user input by indicating the FIELD TO BE USED.
I have a field in which I have - after having performed my SORT - imported sequential numbers starting at 1, ending with the last record number in the file.
"However, from a business standpoint, I have a concern: there are no young developers."
Sorry, but why should young developers be interested in FM at all?
Younger people are usually much more IT literate than the typical FM base of users. FM Advanced is just too expensive compared to all the free solutions out there (.NET, Java, PHP...) that have a much larger base of users.
So, tell me, why should a young developer be interested in FM?
Maybe from what I've read over the web one reason would be his boss doesn't understand anything at computing and came across FM:
"This looks so nice and so "Apple" and it moreover seems I may understand something therefore we should use this!" (actually that's what happened to me)...
I feel FileMaker is suffering from a lack of competition. It is just so far behind in terms of scripting/programming and charts, but does very well in terms of simplicity of server deployment...
My 10-features wish-list:
(1) Being able to edit all object attributes with scripts (like for example in VBA or .NET): colour, position, visible/hidden, size, font, etc. That way it would be finally possible to create really interactive layouts (the workarounds are just not practicable, and conditional formatting too limited).
(2) Having a real script/code editor: I would like to be able to really code and not only click with the mouse, I would like to have all scripts in a real text editor with script declarations (subroutines, functions, etc), I would like to have requirement for explicit variables declaration, the notion of type associated to variables, pre-compilation as-you-type in order to check existence and correct type of variables, etc.
FM support for coding/debugging is just stone age. I think Pascal compiler in the 90s was already much more powerful in terms of debugging. Probably Fortran compilation features back then were even more useful due to the requirement of explicit variables declaration... Not even comparing with current standards... If you want a benchmark look at the .Net programming interface: there's pleasure coding there. If you like coding, you won't have any pleasure doing this with FM. IMO that's not coding, but scripting aimed at people with no coding education at all.
(3) Ability to browse table contents with scripts only, i.e. without using any layout.
(4) Folders to organize tables, value lists, accounts, etc (not only scripts and layouts as it is the case in FM11).
(5) FM11 charts are just useless. Here again what FM11 has to offer is just not in line with the competition.
(6) Create shapes. Actually FM11 can do rectangles, rounded rectangles and ovals. I feel this is not that impressive for a product that reached version 11. Again, all these shapes properties should be accessible with scripts in order to create really user-friendly GUIs.
(7) Any serious solution nowadays has a version compatibility check: the ability to check if the features used in a program are compatible with a given version of the solution. Filemaker doesn't provide this. Without version compatibility check either the final client has to upgrade to the latest version of FM (which may cost really a lot), or the developer has to keep several different versions of FM and different versions of the program (for the clients that upgraded and the clients that didn't). This is just not professional.
(8) It is just ridiculous that some very basic features ar available only in the Advanced version, for example: ability to copy tables, script debugger, custom menus...
(9) Upgrade policy is just too expensive. It is outrageous to ask that much per license for the few new features from FM10 to FM11. But all in all we are free to upgrade or not.
(10) I guess one of the aims of FM is to be user-friendly with a very short learning curve? Then FM should meet its objectives and therefore it should provide a macro recorder (the same way Excel does).
I personally miss FMP 4.0's web publishing and CDML. It was limited, possibly insecure but combined with Claris Home Page, made for an unbelievably powerful development environment for a non-developer. XSLT as a replacement? Dog help us.
Michael D.
As a small-time developer, I find it agonizing every time I need to move related tables between databases. You can import the tables in one step, which brings across the field definitions but without bringing across the relationships at the same time it means many of your calculated fields "break" (causing you hours if not days of manually digging out every failed reference that needs to be reestablished once you rebuild all the relationships, which itself requires constant cross-checking against the original tables to make sure you got them right).
I want to see some new Import utility which is capable of bringing across tables, relationships, table data, value lists, scripts, etc in one group, all at once, preserving all the references so none of these items have to be rebuilt if they all come across in one intact group assuming no conflicts with existing elements in the target database.
Post a Comment