Following our very successful user feedback session, we’ve mapped out some of the key features in our new status concept.
Many entities in the system would be given user definable status. Some likely entities include:
No mapped transitions
Each status can be accessed from every other status and there will be no controls available for you to map out which transitions are possible. Some statuses might be final though, like a cancelled class and there can’t be further changed.
Multiple status groups per entity
Accredited courses need different statuses than non-accredited. One option is to use the existing data collection as a ‘type’ to which status groups are bound. This is only helpful for courses, classes and enrolments.
Automation on change
Status changes trigger an event which can fire a script. The event could be on arriving to the destination status or leaving the original status.
Automatic status change
Some status changes happen automatically. For example, when a class commences. These will need to be carefully controlled to avoid never ending loops of status changes.
Kanban views with definable columns and draggable cards would be great. We might think of the existing three column view as an example of the kanban view with only one column. We need to think about pagination and scrolling of long lists.
When a user defines a status they will be required to also set the built-in status which it maps to. These built-in statuses control certain behaviour, for example whether the class can be enrolled into or is visible.