(this is a continuation of the Fruits of Calligra Suite Sprint #2 series)
2012 started and I am still summarizing ideas from the Sprint. Today an integration idea: Office Forms for Calligra apps.
Forms are useful for improving data entry. Alternatives like entering data into spreadsheet cells can be too error-prone or tedious for the end-users. Forms reuse the GUI paradigm that is most probably already known and accepted by the user.
First, it is good to know forms were historically handled in popular office software. Extra functionality in MS Office or OpenOffice/LibreOffice still tend to be added using form elements (widgets) like buttons directly embedded into the document.
Quick look from the bird's-eye view shows multiple issues.
There is clear escape from the document paradigm to the application paradigm, thus mixing the document and the app functionality can be observed. Not only there is no model-view approach. On the plus side is that the user can just open the document which is a self-contained file, easy to manage and transmit. But this comes at cost. To start fresh with a clean document, the whole original document with the GUI and business logic code is just copied. This is not a surprise as the documents with forms are distributed as document templates. Because of that copying there is no organized way to upgrade the GUI and the code when the authors provide a new version.
And let's not forget: users are gernerally unable to notice which part of the GUI comes with document and which is provided by the application itself. So there is a break in the familiar GUI paradigm. User may accidentally move or delete a button. The form elements affect the presence of printouts. Various document formats deal with this by employing whole set of workarounds like locking position and modification of a form widget and excluding them in printouts. This further contributes to complexity of the solution.
So at the Calligra Sprint instead of drafting a set of workarounds I outlined idea for the solution (see the mockup below):
There is extra rationale. It was never too realistic for the Calligra project to support VBA/StarBasic and forms. Even StarBasic perceived as a drop-in replacement for VBA never achieved compatibility and continued its life as a distinct scripting environment. Only simpler VBA solutions are similar under StarBasic. Even assuming extremely good will, achieving reasonable compatibility is very hard. So VBA is Windows+MS Office-only. Microsoft itself has admitted this at least twice: by giving up with delivering VBA for its Mac Office, then it skipped scripting topics in its MSOOXML specifications by declaring scripting as implementation-defined area. That was rather honest move.
Then there is question about the ODF. Currently reusing any partial support for scripting/forms defined by ODF is not worth the effort in my opinion. While working on applications we start with requirements and usability. Reusing incomplete standards here is nice-to-have but at this stage definitely it cannot have higher priority than practicality and usability of the solution.
This does not mean I am ignoring importance of standards. As the case of OpenFormula shows, ODF is vital in its iterative approach especially when the problem and the scope is well defined and rather narrow. So users would eventually see some complete standard in the area of forms going behind the level of XForms. Cooperation is getting more possible after the collapse of the controlled corporate structures of OpenOffice.org (but let's appreciate the huge contributions of Sun) and emerging of LibreOffice as a free software project.