Use Case Event Workflow

Use Case: Event Workflow

One of the outputs of the Carolingian Autocrats' Roundtable has been the realization that it would be useful on a lot of fronts if we had an easy-to-use system for autocrats to use. As of this writing this is still in design, but desireable features potentially include:

• Having an easy-to-use form that lets you enter all of the information about the event early on. (Possibly in wizard format -- if you say "Yes, there is fighting", it might offer a few more fields.)

• A little bit of true workflow -- in particular, the Seneschal would have full insight into the system, and there would be a signoff step where the Seneschal approves the event to run. (And possibly more workflow after the event, to get the right people involved with the event reports.) This would likely involve a mix of email notifications and approvals. Likely not horribly difficult, and potentially generally powerful.

• The ability to generate all necessary forms automatically, especially the final Event Report.

• Possibly some links to the Site Book; it would be nice if an autocrat could just select a site and poof include its information. (And if they enter a new site, it should go directly into the Site Book.)

• The ability to search and query previous events in both structured and ad hoc ways.

• Being able to compose the Event Announcement directly in Querki, and have it submit that automatically to the EK Site, the Minuscule, maybe the Gazette, and so on.

Analysis

This is a pretty great application for Querki -- it would stretch the system in a few ways (especially the workflow feature), but most of it would just work out of the box. We are officially not waiting for Querki -- the current theory is that it will be hand-built as part of the Baronial Homepage -- but I want to monitor this as a good potential Use Case anyway.

The relationship to the Site Book is very complex and interesting, and the resulting App structure exceptionally complex. I believe that there would be a super-App of "Event Info", defining the main Site data structures. There would be a Site Book app, and an Event Workflow App. Then there would be a Carolingian Site Book Space (with controlled but moderately broad access for the Barony), a Carolingian Event Workflow Space (tightly controlled), and a separate Space for each Event (with access focused on the people working on that event).

Data sharing and searching would be an interesting challenge here, possibly the most interesting bit. We want to be able to search all of the previously-held Events in the Barony, mining information about dates, sites, people and so on. This probably needs to be both structured queries in Querki Explorer and freetext search. All of which violates some of my assumptions about how Spaces get loaded, but I suspect this sort of problem will be common, so I'm going to have to figure out a way to tackle it.

Features

• Feature - Workflow: Fairly straightforward for this particular Use Case, but it's a good first example of a very general Feature. Certain things can't proceed (such as submitting the Event Announcement) until the Seneschal has officially signed off that the event is go.

• Feature - External APIs: This has a nicely concrete use of external APIs. If the EK site has a Web Service interface for submitting events, it would be delightful to use that.

• Feature - Automatic Email: Tied into the workflow system, some specific event would trigger an email announcement to go out to the Minuscule, and maybe the Gazette and EK site (if the latter doesn't have Web Services).