Go Flow

Stephen White made a comment on my Human “Facilitator” Processes post that deserves highlighting.  You probably know the Stephen was the chairman of the working group that developed BPMN.

The discussion of the different diagrams shown in the post really have nothing to do with BPMN per se, but with the methodologies that would be used to model with BPMN. BPMN is generally methodology agnostic. The way that a process is modeled, to what level of detail, and what information should be captured, is really up to the methodology and the purpose for creating the process model.

He is completely right, and this is really really important.  I have discussed this with Stephen before, but this is something that very few of the experts seem to understand.  What he is saying is that the way you draw something with BPMN depends upon your methodology you use.  Given one method for one purpose (e.g. Automators) it would be right and correct to draw one way, but with a different method and different purpose (e.g. Facilitators) it would be right and correct to draw a different way.

This makes those who want ONE TRUE WAY to draw process diagrams extremely uncomfortable.  This was never the goal of BPMN.  BPMN instead had the goal to define a set of common elements that could be used for multiple different specific diagramming needs.  I might even venture that this is why BPMN did not have a meta-model to begin with.  I might also venture that BPMN success is precisely because it was flexible to be adopted in slightly different ways. Had it been overly rigid, it might have been rejected.

I would have said it slightly differently: that differences in the diagrams come from differences in the capabilities of the underlying system that will enact the processes.  This amounts to the same thing since tools are created with a particular methodology in mind, and that use of a particular methodology draws you to particuar tools.  What you are allowed to draw, and how you draw it, depends on things outside the BPMN standard.

What does this really mean?  It means that using one methodology one might draw a given process one way, while using another methodology one might draw it a different way.  Those who want a single diagramming approach, want a single methodology, as well as single set of underlying capabilities.  That would make life easier, in the sense that having a single flavor of wine would make life easier.  The world is not so simple, and some of those differences have great value and utility.

I have been arguing for years that disabled (greyed-out) menu items and buttons are in general a bad idea because it is impossible for users to know why the associated function is not enabled at the. It is quite frustrating: the user sees a menu command that looks like it might be what is needed, but it is disabled, and there is not at all obvious why it is disabled. I wrote a blog entry about this last year: “Please Don’t Disable My Menu Options!” and includes some references to noted UI experts on the issue.

Today a colleague pointed out to me a small advance in the area: the new UI guidelines for Vista include this recommendation:

Reconsider disabled controls. Disabled controls can be hard to use because users literally have to deduce why they are disabled. Disable a control when users expect it to apply and they can easily deduce why the control is disabled. Remove the control when there is no way for users to enable it or they don’t expect it to apply, or leave it enabled, but give an error message when it is used incorrectly.

• Tip: If you aren’t sure whether you should disable a control or give an error message, start by composing the error message that you might give. If the error message contains helpful information that target users aren’t likely to quickly deduce, leave the control enabled and give the error. Otherwise, disable the control.

Thank you, Microsoft. You have reaffirmed my faith that some day, user interfaces will be advanced beyond the “simple rules and superstition” that we have today. It is a SMALL step, to be sure, and still leaves plenty of room for misapplication. My experience is that programmers usually make the mistake of thinking that a user will find something obvious, because the programmer’s knowledge of the system makes it hard to understand the viewpoint of someone who does not understand the system. Consequently, we will see whether programmers will correctly estimate whether users “can easily deduce” why something is disabled. Even if the reason is obvious, why not go ahead and display a message spelling it out. Leaving it disabled is a lot like a taunt; e.g. “if you can’t figure out why this control is disabled, then you shouldn’t be using this product“. I have been taught that when a person asks a question, no matter how obvious the answer, it is most polite to simply answer the question. A small step in the right direction is better than none.