The photo album feature will be shipped this weekend, so it’s time to stop talking about that (because if we stop talking about it, maybe it won’t crash and burn when pushed to production).
Next up: the recordkeeping feature. It’s fairly useful- we use it for our own internal tracking- but it’s also fairly ugly. And fairly non-user-friendly. It needs a facelift: new interface, easier to navigate, no more tables. It also needs to work out a bit: strengthen up the process by adding drag/drop functionality for adding documents or images to a record. Finally, it needs to learn some new skills: we’ve had multiple requests to allow a custom request form feed directly into a recordkeeping entry, and I think this is where the bulk of the work will end up going.
Creating a form that dumps entered info into a database isn’t too hard (though security concerns should always be taken seriously). But when the form can be customized by the customer, it seems to become a lot more complex. For example: when creating the table to store the form data- how many attributes should it have? One form might have 3 text fields, 2 checkbox groups, and a drop down select list. Another might have 7 text fields. How should we design that table to store the info? Does it make sense to create a new table for each form, and just make the columns ‘on the fly’ as the first form is created? The advantage to that is that each subsequent form (of that same category) would already have the table, and could simply be entered. Or maybe we restrict forms to be used with a database backend to a limited number of fields- let’s say 5 for example. But even then, those five fields could be any one of 8 options for field type, so making sure the schema matches the data coming from the form could be an issue.
We don’t have any answers yet, but sometimes it helps just to write down the questions.