State Machine Enhancements
Hi Tolis, I've been using the State Machine module quite extensively and getting some feedback from users.
One common feedback I keep getting that at the moment it takes quite a lot of time to make the transition making it very inefficient. I had a look and indeed I can see what users mean. Currently, the field is disabled in the form and in order to make a transition you need to click on the Change State action in the ribbon, then select the State Machine and then the status to transition to. This requires quite a few mouse actions which is both time consuming and awkward. The alternative option (which also for some reason doesn't seem to be working for me) is to expand actions. This is also not a good option as with many statuses and allowed transitions you end up putting a lot of irrelevant data into the user interface. What I mean by that is that the user may not be interested in changing a status, but sees all the possible states they can transition to. This goes against good usability design principles. I know it's possible to add the transition into the quick access toolbar, but that's not that great either.
I believe the best option would be to have the dropdown of the field enabled (rather than disabled) when there is a state machine defined over the field and only show the states to which the user can transition if Hide If Criteria Do Not Fit is ticked. This would give the best possible user experience and enhance the user experience.
The second feedback is that often the administrator needs to be able make any state transition (to roll back a mistake for example). At present you need to define all possible transitions and only allow certain transitions to admins. It would be much simpler if there was a checkbox on the State Machine that would effectively allow administrators to make transitions from any state to any other state irrespective of whether transitions are defined for the states. This could also be defined in the Model Options so that it works the same for all state machines and doesn't need to be defined on a per state machine basis. This would be inline with how view visibility is implemented based on the Is Administrator flag.
this updated in next version 188.8.131.52
what will happen when more than one statemachines?
>The alternative option (which also for some reason doesn't seem to be working for me) is to expand actions
why this does not work? it solves the issue of the enabled property editor and the multiple statemachines
Hi Tolis, the expanding actions works fine (I just had freeze layout on the form so needed to the newly generated layout group manually), but as I described, there are 2 major problems with it from a usability perspective. This is particularly a problem if you have say 5 or 8 potential states as you end up with 5-8 buttons on the user interface. The are a couple of major problems with this.
1. This goes against good UI design and usability principles and in fact against how all of XAF UI is designed where all actions (i.e. buttons) are in the toolbar or ribbon, which is where they belong so that your form isn't full of irrelevant actions that you may not be interested in using at that time. With 8 buttons the user would see all 8 buttons in the UI even though they aren't necessarily interested in changing the state (i.e. showing irrelevant data on the form). Now imagine if you have 2 or 3 state machines because you have 2 or 3 fields that use state machines. You basically end up with a huge number of buttons on the form which the user sees all the time when looking at the form.
2. With the changing number of states (based on the available transitions) the form layout changes and things really get pushed out. This is particularly an issue if you have say 5-8 available states you can transition to.
In essence I think showing state transitions as buttons on the form is very bad usability design and I would only do it in very rare circumstances where I'm prepared to trade off usability for productivity (i.e. specialist forms for specialist tasks).
In relation to your other question.
I don't ever forsee a situation where you would need multiple state machines defined over the same property. If there is such a situation I think it's more due to poor design as opposed to real need. What I'm basically saying is that in State Machine the combination of Target Object Type and State Property Name should be unique. I checked and this rule isn't there at the moment, but perhaps it should be.
That said, for 99% of use cases, I think having an active dropdown that only shows the states that the user can transition to is the best possible option from the usability perspective. To handle the 1% of cases where are multiple state machines defined over the same property perhaps a new "Default State Machine" property on the state machine object could be added, unless of course you think its better to have a constraint on State Machine to enforce Target Object Type and State Property Name combination being unique.
I agree with your points the functionality you requested is implemented in next version 184.108.40.206