Some other things I think would be interesting are:
- A tabbed interface for User Experience. For instance, it would be interesting to have such things as different views for the workload (such as a “process view”, a “task type view”, a “document view” and the like. It would be also interesting to have triggers between tabs (for instance, if you select on one tabbed screen the process you are looking for, then you will have a case information form on another.
- Some kind of “case-state” form, which might be defined at pool level.
- A more “document-awareness” for Bonita. For instance, be able to include some kinds of metadata to Attachment variables, and be able to present such documents to the user in a chronological and case basis.
- Some kind of “screenflow” graphical notation (i.e., a form navigation diagram), different for the one used in BPMN. Screenflows may be defined currently using form-exit variables and Actor continuity, but (I think; I am a bit zealot about modeling languages) it is confusing and prone to cluttering the process with low – level details to represent one thing (a screenflow, similar in concept to the ones used in MVC frameworks such as Struts) using a notation intended for another different one (the inter-personal and inter-organizational task flow of a business process). Some graphical process definition tools (for instance, the one included with BEA Aqualogic BPM, Ex-Fuego BPM and now Oracle BPM Suite) has this concept of separate symbol set for dealing with Screenflows.
I think currently the only way to edit a table is to use this kind of screen flow (you see the table, click “add”, then you are redirected to a “add record form”, then add, then return to the original screen, etc. This definitively clutters the process representation with low-level, unneeded details related not with the process itself, but with pure implementation issues.