As mentioned in my previous post, I have been following a discussion on the uptake of BPMN functionality. Basically, the debate revolves around the actual number of BPMN components being used, and the lack of uptake on many of the components devised by the OMG. This is an exceedingly complex issue, that I cannot fully comment on due to my nascent knowledge of BPM, having defected so to speak from the gaming community.
However, I can't help but wonder if the issue here is to do with the visual nature of the diagrams, and their interaction capabilities. Most software I know of that uses this standard presents the diagrams in an inanimate, low-level interactive manner. While this works well for certain stakeholders in a process modelling scenario, it does not bode well for those that think in a different manner, especially if they are new to the field. For instance, you model the business, and then show the user the model and expect them to understand easily. I think a static diagram does not work here for people who are not BPMN experts.
Would more components be used if it was clearer what these icons meant, and what they model? Most of the time we avoid software functionality as it is too hard to find out its usage. And no, RTFM just doesn't cut it as a methodology, because we usually learn by doing, and the doing requires tools that clearly show their functionality.
I think a lot of pedagogical theory could be applied here to look at how animation could be used to show the functionality of the diagram. Not in a simulation manner, but simply in a base functionality level. The user could use a tool to brush over the diagram to generate animations that indicate node or group levels of functionality.
For instance, as an icon is inserted into a diagram (xor-split say), it could animate itself judiciously to indicate that one or the other choice in the branch is made, and not both.
This technique has been applied in other visualisation fields, and I think it could work here.
Ross
No comments:
Post a Comment