Taking the CUD out of CRUD
a.k.a. New Editing Interface Inbound
While there has been talk about releasing 9.0 stable a while ago, something just didn't feel right yet, namely the state our administration interface. With most of the internals cleaned up now, and component functionality improved in a lot of places, most of the system is in pretty good shape, which made the shortcomings of the current editing metaphor all the more obvious.
There are a few different basic approaches that CMSs take with their editing tools, the most common one being a backend of some sort that is completely isolated from the user visible parts. This has the advantage that there can be no interference from frontend code, and the interface can be optimized properly for the task at hand.
For a while now this approach has been criticized for not being user friendly in the sense that what a user does is too far removed from the results of their actions, so in-page editing systems became the hot new thing. MidCOM was in fact an early pioneer in that approach, Datamanager2 includes inline editing functionality since time immemorial. However, it never really took of, because this approach created a number of problems on its own, for example interference of site CSS/JS with editor functionality, the problem of editing invisible fields, and so on and so forth.
For a while, we've tried to overcome these issues by switching to Create.js, which managed to address these concerns to some extent, and was generally a much more capable tool. But it, too, simply was not able to fulfill OpenPSA's needs. It's development seems to have stalled lately, so there doesn't seem to be much chance to see it improving in the forseeable future.
So in the end, we stuck with the status quo that has been around since the release of MidCOM 2.0. It can probably best be described as „inline editing without inline editing“, that is to say, there is no admin backend, all editing is done in the website itself, only there are no actual inline editing tools, instead a new page with a (backend) form opens in the frontend layout. So you had the problem of site/application layout bleeding into the admin functionality, while still being unable to see the effect of your edits immediately. For site/application developers it also meant having to allot time to the task of adapting/testing the admin interface with each new project they built, which is not exactly an incentive to use MidCOM if you don't have to.
So for the last year, we have been experimenting with different options on how to solve this dilemma, and it turns out that the solution is pretty simple: We're splitting the established CRUD (create/read/update/delete) cluster into one interface for Reading (i.e. the regular frontend of the site/app), and move the other three into overlays (iframes, if you want to get technical). This solves the problem of the admin interface interfering the site/application functionality, and at the same time provides a much more direct connection to the frontend than a dedicated admin backend could. The limitations of actual inline don't apply, since the admin UI is isolated, and the users can see the result of their actions as soon as they click save, with no further interaction required.
We've used this in a couple of production sites already and had quite encouraging feedback so far. Currently, the migration of mainline components is ongoing, and should be completed in a matter of weeks. Afterwards, the long-elusive 9.0 release should just be one stabilization period away.
You can play around with the current state on our demo server, or you check out the latest version directly from Github. In any case, if you find any bugs or have requests for improvements, just let us know.
There have been no comments so far.