MactoThe Main Screen
I usually like to think about the responsibilities of the system by showing up the UI. It is a great way to communicate with both customers and developers.
Here is the main screen for the application:
This is actually a bad place to start with, in terms of coding start points, because it requires so many other things as well. This particular screen is likely to be viewed pretty much everywhere, this is what the prison commanders and the cell blocks commanders have at their desktop, what the officers are using to do their daily work (usually for Counting, admittedly).
Even before we can start , it reveals quite a lot about the actual way things work. In this screen, we can see that we have Flagged Dossiers, those are Inmates that have some problem with their Dossier. We can accept Inmates with problematic Dossiers, but we want to fix that as soon as possible, so we make this something that is very much front and center.
The “Action required” section detail Inmates that we have to take some action about. Whatever it is a court date that this inmate have to be at or his sentence is ending or a warrant that need extending.
Finally, and most importantly, we have the counts, which are the most important thing in the prison. You can see that the numbers at the bottom line up. If they don’t, we have A Problem.
More posts in "Macto" series:
- (17 Aug 2011) Looking at warrants
- (15 Aug 2011) Talking to nasty people
- (11 Aug 2011) Counting is The Holy Grail
- (10 Aug 2011) Getting Started, you never forget your first Inmate
- (08 Aug 2011) The Main Screen
- (03 Aug 2011) Warrants are for fools
- (01 Aug 2011) Non functional concerns, you are a legal system
- (28 Jul 2011) And it goes on your permanent record, too!
- (27 Jul 2011) Once more from the top, I swear I had a few more over there
- (26 Jul 2011) Day to day life
- (22 Jul 2011) Where is the Inmate anyway?
- (19 Jul 2011) Let’s CREATE an Inmate
- (12 Jul 2011) Creating The Model
- (05 Jul 2011) The boundaries of a prison
- (25 Jul 2009) An end to end sample
Comments
Presumably you mean "Roster" rather than "Rooster". Unless that's the prisoners' rude early morning wake up call!
Thanks, fixed now.
More questions :)
I noticed in the Counts table that some of the numbers don't add up the way I expect them to. For instance Cell Block C2 has 98 Inmates on the Roster and 2 labelled as Out. I would expect the Last Count to be 96 but it is 99. This seems to imply that we have 3 extra Inmates in that cell block. Is that right?
The Actions menu says we can Start Counting. Does that mean that across the whole prison or just for a specific area? Do all areas of the prison have to Count at the same time? Will guards enter data directly into Macto while they perform a Counting or will they collect the data and it gets entered by someone else?
How do Dossiers currently get flagged? How often does this happen? How about checked to see if any Action is Required?
Efo Ima has an Inmate Dossier that is flagged as being Age Inappropriate. If a Judge signs off on Incarcerating Efo in our prison (i.e. the problem is "fixed") should the Dossier still be flagged? (We run the risk of flooding this area with information just because the system cannot cope with human flexibility).
Mike, re: Counts Yes, there are also Inmates that were moved In to the Cell block. They are tracked, but not shown on the Summary view.
re: Counting You always count the entire prison, all at roughly the same time. The officers report that information to the Ops Room.
re: Dossiers When there is any change, we check them for inconsistencies, then flag them. We also check every day based on release criteria (the only thing that is actually time dependent).
As for Action Required, this is checked once a day, for the current and next day.
re: Judges You can suppress a specific Flag by adding a warrant that allows it.
Ayende, if the total counts at the bottom of the screen are so critically important, wouldn't it be better to put them at the top of the screen so there is no possibility that they would be scrolled off the bottom of the screen?
Chris, Yes & no. You aren't going to have it scroll off the screen because the number of location is pretty small, and this is how most of the reports are structured.
Hmmm.... Two reasons, two responses:
Number of location is pretty small - Your example has 13 locations, and likely in a smaller prison there would be a similar number of locations. Wouldn't a larger prison have more locations though? And with widescreen monitors becoming more popular, the risk of running out of vertical space is even higher.
Most of the reports being structure similarly - I would argue that the main screen of the app can (and often should) be structured differently from the rest of the reports; If the total counts don't match then you have "A Problem" (capitalized). I'd argue that it would make sense then to display the total count outside of the main list entirely, perhaps in a box all it's own, centered at the top of the screen. Light green background when the counts match, red when they don't with lots of really big warning signs, spinning lights, and maybe even <gasp> a blink tag :)
Chris, Let me rephrase that, then. As the number of locations goes up, our resolution goes up as well. For example, we might open another two cell blocks, but at that point, we would only track things in cell block levels, not in cell block parts. We would have:
Cell Block A Cell Block B Cell Block C
etc.
Chris, And for the second reason, that might certainly be an option, sure. I am not sure if I would go as far as the Blink Tag, but yes, that is certainly something that we might want to do. The design in the post is an early one, not something that I intend to insist on "Must Be This Way"
Are all areas counted consistently and simultaneously? If a cell block and the kitchen are counted at different times, and an inmate moves from one to the other in between, then the numbers at the bottom will not match.
Is there a kind of eventual consistency going on here?
Michael, Counts go on concurrently, and during Counts movements are monitored VERY carefully. Usually there aren't any movement.
So have you moved from requirements to design?
JarrettV, No, I am just specifying the requirement in a nicer way
Don't know if this is the right thread to mention it, but do you foresee a real time refresh of the numbers in the table (as other users work on the files in real time) or will it require a browser refresh to see up to date information ?
In case of dynamic update, I think the dashboard makes even more sense.
SSII, The number refresh, yes. Real time? No need, every few seconds would be more than good enough
It always makes me laugh out loud whenever you say something like "we have A Problem".
I totally get it, all systems are like that. There are always situations that if "this happens" it is "A Very Bad Thing".
It is our job to assist the humans avoid/resolve these sorts of things :)
Comment preview