I’ve been working pretty continuously towards the 3.0 release these last few months, but I’m afraid it’s still a ways off yet. But my plans have now solidified about the foreseeable future of Form Tools, so a post was in order. Much of this has been posted before – now more than anything it has a concrete roadmap.
Form Tools 3
As I’ve written about before, Form Tools 3 is an under-the-hood rewrite of Form Tools to support PHP 7. There will be a few small changes here and there but the interface will look the same, the way you install modules the same, the API etc. etc. All pretty much the same.
Upgrading to 3.0 will be possible from 2.2.6 or 2.2.7 to 3.0, but no earlier. The upgrade code supports upgrading from waaaaay back in time and it’s time to clean house. So yes, there will be an upgrade path, but you have to upgrade to the latest versions of Form Tools 2 first (I’ll be updating the System Check module to add the one additional FT version check on the “FT3 compatibility” section).
Once 3.0 is released, along with all the modules, themes and API, I’ll be releasing bug fixes for 3.0 only – that major version is effectively finished. At that point I’ll be working on…
Form Tools 4
As I’ve been slowly refactoring the code for 3.0, I’ve had to hold myself back again and again from doing more aggressive changes. I now have a long list of things that I think the script needs, but avoided working now to prevent 3.0 being held up any further.
So 4.0 will be a much more aggressive change to Form Tools. These are the main goals:
User interface redesign & rewrite
Personally I don’t find Form Tools’s UI or UX too bad (okay, I’m biased) but it’s 2017 and it can be better. Better use of space, better look and feel & better IA (information architecture – the structure of how the pages tie together) I want to do a complete re-write of the front-end portion of the script from the JS code to the user interface. Language-wise I’ll be using React – but it’ll probably remain a traditional page-by-page app and not a one-page web app. We’ll see.
This is an item that’s long overdue, but one that I’m the least sure about how to implement yet.
I want to completely revise the installation and upgrade code to remove the dependencies on the website. Adding modules should be as simple as selecting them via the interface and clicking a few buttons. No more manual FTP’ing of files to your server to install things! (well, other than the original installation). Right now I create a bundle of files via the website which generates a zipfile containing the Core, API and list of modules & themes. Bah! Instead, Form Tools should be a single identical zip for everyone who downloads it, containing ONLY the Core code. Then, during the installation phase they would select what pieces they want. Users shouldn’t have to concern themselves with manually downloading separate pieces of code and installing them separately.
This would result in a lot of complex code being dropped from the website making the project far more maintainable for me, and much simpler for people.
Form Tools is too slow in places! Time to benchmark and improve.
User Roles / Permissions
Form Tools has a very basic user account system at the moment. It has a sort of basic way to change configuration settings for multiple users at once, but no real concept of a “role” which you see in most large applications. The idea of roles is that you create a role that describes what a user can do, then set each user to a particular role. Pretty straightforward. This means re-writing the backbone of the current permissions code and remove the current admin/client separation.
Schema ALL the things!
This one’s is a bit technical, but the idea here is to make all configuration data stored within Form Tools adhere to schemas, i.e. make them “well-defined”. Form Tools changes and configs have always been very ad-hoc: each version comes out with new settings for your forms, client accounts, form builder forms and so on. A schema will provide an explicit description of a particular version of each piece of data, outlining the semantics for each and every part of the configuration. So why do this? Well it’ll allow for my ultimate goal of Form Tools, which is…
Form Tools market
I’m really proud of what Form Tools does. It’s crazily feature rich and lets you set up complex forms and let’s you fine-tune who sees what, what can be downloaded, edited, viewed etc. etc. But the pain of Form Tools lies in configuring it. It takes TIME setting up a form with all the right settings, form fields, users and so on. The goal of the Form Tools market is to allow users to share configurations so rather than manually setting up a form field by painstaking field, you just browse the market and click “Import!”. That imports the form configuration, views, email templates, form builder templates, etc. etc. Then you can go to town tweaking it.
This is eminently do-able, it just requires a lot of work and planning. But there’s one catch to this last one: I may have to put a small fee on this feature, like $20 a year or something… it’ll mean increasing the server load for the website a great deal, and Form Tools costs me a fair bit of money as it is to host.
Alrighty, there’s the update. I’m sorry development on 3.0 is taking so long. I’m still not at the point when I could estimate a release date for the alpha.