Drag and Drop Forms — Really?
I recently saw a blog post by a competitor criticizing our platform due to the lack of the ability to add fields to forms using drag and drop. I’m not going to reciprocate and criticize their platform, as I’m sure it’s a fine solution for some organizations (plus, I do believe that it’s unprofessional to criticize anyone’s work). However, let me explain exactly why our platform does not use drag and drop.
Oh, and by the way, it’s not that we don’t know how to program drag and drop to work; we’ve known how to program drag and drop for at least 20 years.
Since the invention of the relational database, the general approach has been to: add columns to a table (fields) and create a form that shows these fields, so the user can enter the data that will be stored back into that table.
This approach is fine as long if all users should see the same fields on the form. But what if you want different people to see different fields — that where it gets tricky.
We’ll stick with a grant application scenario. The Grant Seeker needs to see
the fields required for the application, generally Grant Staff need to see additional internal fields not displayed to the Grant Seeker, and perhaps external reviewers need to see a mix of the Grant Seeker fields and internal fields.
So how many forms do you need to create? Drag and drop or otherwise. Yep, the traditional answer would be three, one for each type of user. Now multiply that with different application forms for different programs and the number of forms multiplies very quickly.
You can drag and drop to your heart's content, but it’s going to still require a lot of maintenance. Consider the exponential additional work if you add a single field to the table and want to display that field on every form.
Simple modifications are where the wheels really fall off the wagon. You are now going to have to drag and drop that field onto every form!
In the early 2000s, a development architecture called Model-View-Controller (MVC) was developed. The Model-View-Controller philosophy is that the fields you should see on any “form” should be based on defined logic. The form itself is irrelevant, it’s the defined logic that serves up the content.
In our case, we implemented this model through Role-Based Access Control (RBAC), another architectural standard that says that the user’s role should define what they should see.
Combined, these architectural constructs mean that (hold your breath!) there are actually no forms at all, as the form the user sees is created on the fly based on the user’s role. This approach works because you set the permissions for each field, rather than relying on the form to manage access to the content. So, using the previous scenario there is no need for a Grant Seeker form, a Grant Staff Form, or an External Reviewer form. The system knows what fields to put on the form based on the user’s role. And if you add a field to the table it will automatically appear on all forms.
We go further with this approach by also using the status of the grant application underlying the form. That means you don’t need two or more versions of a form for a Letter of Intent or a Full Proposal stage, you simply specify which fields should be available at each stage (and, of course, combining that with the user’s role).
In our experience of implementing grant solutions for hundreds of clients, a typical grant organization either small and large will require a suite of forms, applications, and business rules to accommodate their critical functions. A few examples are described above. Once decisions on which fields are to be placed on a form, a form can be assembled in minutes whether you use drag and drop or other methods. It is far more important to have a product with depth to accommodate the critical functions of a grant organization.
Of course, dragging fields onto a form shows well in a product demo but if you fast forward to the actual work that clients need to do, they will pay dearly if drag and drop is the best you can do over time-tested architectural standards.
