Hi folks,
1.5.0 is now looking pretty solid and soon to be released as the standard build, so I thought now would be a good time to make some remarks about the next release. After much humming and hawing, I’ve settled on the features discussed below. As you can probably guess, this is going to be a major upgrade - hence the 2.0 label.
So here’s what’s coming in version 2.0:
1. Views
Views are ways to, well, “view” your data. (That clears THAT up!)
To explain: currently, you have one and only one way of viewing your form submissions: ALL submission information. When you or your clients browse the submissions you have no choice but to see all fields and all submissions (with the notable exception of the under-used “submission filters” feature). But what if you’re interested in seeing a subset of that information - both in terms of the submissions that get listed, and the fields that appear for each submission? For example, what if your form was a registration form and you just wanted to see the emergency contact information for submissions entered in the last week? Or maybe you want to limit the fields that client accounts can see? Or perhaps let a client see certain fields but not be able to edit them?
Views let you do all this. You can create your own custom ways to view the data, and assign particular clients to particular Views. This is an exceedingly powerful feature, as it effectively converts Form Tools into a fully-fledged report builder. You can define your own Views to slice and dice your form information in whatever way you wish (including setting up default sort orders, submissions per page and field order) and then use the existing Print Preview and Excel download options to export that particular “View” of the data.
[N.B. I have this feature already working, and BOY is it cool. Incidentally, I cribbed the term “View” from a Drupal module since I think it’s the best term for what it does.]
2. Tabbed Editing
This feature has been put off and off and off in favour of more pressing features. But now I’m adding Views, I figured it was a great time to work on it.
Imagine you have a large form with a lot of fields (say over 100). Viewing and editing that form through the Form Tools UI can be pretty painful: the page itself can take a long time to load and finding the field you want may involved scrolling and scrolling and scrolling…
Tabbed editing provides you with an elegant solution to this. You can defined up to 6 tabs for each View and assign every field that appears in the View to a particular tab. Now, when you or a client goes to edit or view that particular submission, they’ll see the information presented in your neat little tabs, each with whatever title you’ve assigned to it.
3. WYSIWYG editor for field editing
A month or two ago I did a job for a client that involved adding FCKEditor to allow administrators & clients to edit their submissions in rich-text format (with things like bold, italics, colours, links etc). It’s a nice, practical feature so I’m going to incorporate it into this next release. But I still haven’t made up my mind between tinyMCE or FCKEditor. I’ll provide controls so that the administrator can specify which options appear in the editor.
4. Themes
I’ve never mentioned this, but I never really liked how Form Tools looks! I think the UI is generally pretty clear, but the overall styles are very plain, very boring. What can I say? I’m not a designer!
When I first wrote Form Tools I knew that people would want to change how the program looked. So, thinking that the majority of users would be web developers like myself, I added the option to allow administrators to customize the client’s CSS. Well… perhaps that wasn’t sure a great idea. I have yet to see an installation of Form Tools that looks genuinely unique. Most people tinker with the styles but not radically re-write them - probably partly because they don’t have time but also because they’re just not that familiar with CSS.
Solution? Themes.
Themes apply to all user accounts: administrator and clients. Instead of the current, klutzy solution where administrator pages are rendered via one route (the admin_styles.css file), and the clients via another (the CSS in the database), the new themes will apply to all accounts, helping to simplify the code.
There will be 3 themes by default: the “classic” grey theme (as it is right now) a “Deep Blue” theme - a fixed width theme that will fit on all 1024 minimum monitors - and another theme which… well, I haven’t come up with yet.
I’ll also be encouraging real designers to create their own themes and upload them here to the site for others to view and download. Naturally, each theme can include author information and links to their sites.
What may seem odd is that I’ll be removing the existing option to upload your own program image or choose a preset one. Now it’ll be entirely theme based: if you want a client account to look a certain way, you’ll need to create it’s own custom theme. Despite the reduction of the functionality, I think that this is a much better solution all-round.
From a back-end point of view, themes will be the most substantial change from 1.x. I’ll be employing the Smarty PHP templating engine to allow non-programmers to modify every last aspect of the pages without requiring any knowledge of PHP. The existing mix of PHP and HTML is a mess - I’ve known this for some time, but balked at adding some sort of template system, due to the sheer volume of work involved.
5. Modules
With every new version of Form Tools I’m walking an ever finer line between usability and functionality. The more features I add, the more complicated it gets - and for anyone that’s used software like Drupal knows, usability is paramount. Sure, you can do virtually anything with Drupal, but actually figuring out how to get it to DO it can be downright agonizing - often involved at least 3 shots of expresso and a punching bag. Form Tools is nowhere near as huge a script as Drupal, but the usability problems are similar: how to accomodate feature requests without sacrificing usability.
For a long time I’ve known that adding some sort of Module support is the only real solution. If you need Feature A, you can just download it in a separate module.
I have a tentative solution to this problem, which I’m still investigating. But whatever I come up with, the following two modules will be included:
- Duplicate Form Module (lets you make an exact copy of a form)
- Submission-to-User account module. (letting you convert a submission to a user account, allowing that user to log in and update that single submission)
Naturally I’ll also write some documentation to add to the Developers Doc section on how to write your own modules.
My hope is that eventually I can move away from developing features for the main script and focus on separate modules. But time will tell.
6. Other stuff
- All passwords will now be encrypted in the database (loooong overdue! Holy smokes!).
- Options for client accounts to define their own logout URL and system timezone offset.
- A solution for the age-old uploading-images-with-multi-page-forms problem.
- new “date” field type that will let you edit any field that contains date information (consistently) in a specific format with a JS calendar.
- And a few more goodies… 
Oh, and there’s one more thing I need to bring up: this will be the first disruptive upgrade. If you choose to upgrade to this version, the following information will be lost:
- any client filters (the last of the Edit Client tabs) you have defined will be deleted,
- client styles will all be reset.
The reason for this is that filters will now be associated with Views, not directly with clients. Technically I could write some complicated code to allow a smooth upgrade, but frankly it’s just not worth my time: the feature has been rarely used since it’s inception, and it won’t be too much work to your part to create a view, add the filter and assign it to the client(s).
Client styles will be deprecated in favour of themes. I regret that the old styles will be lost, but if I continue to support features that hold back the overall development of the script, the program will be much the worse for it!
That’s all for now! I’ll be sure to post more information as I progress.
Ben
