Brainstorm scheduling flow

[jrubenoff]

Copying @ajb's last comment in dobtco/dobt#1608:

Some meta-feedback: I try to make screenshots of user flows (or anything, really) < 1500px wide, so that they're easy to read on most screens.

Thanks for the suggestion. I kinda struggled making that chart... I think I need to learn Sketch or something too.

I disagree with your assessment that this is a "manual scheduling UI with a computer assist." Maybe I gave you the wrong ideas with my WIP modeling, but depending on the constants that I throw at the model, over 90% of the appointments can be booked automatically. I would obviously like this number even higher, but I would feel comfortable saying that we should aim for 90% or higher as a measure of success.

(Let's go over the modeling on Monday, it's a little more than I want to write up in here.)

Also, the modeling will allow us to determine what factors are necessary for more appointments to be booked without admin intervention. For example, we can tell users "please increase the number of timeslots", "please ask reviewers to pick at least 6 timeslots", "please increase your number of reviewers", etc. Also, my modeling doesn't account for users who have nearly full availability, like those two did last year. If we add them, 100% of the slots will have enough reviewers.

The wizard currently sets a definitive start date. Your flow assumes that the admin will move everyone through all three phases before that start date happens. If the admin forgets to do that work, what happens to the start date? What do we do when the admin goes on vacation / gets sick, becomes busy with something else, our reminder emails go into their spam folder, etc?

If the admin is going on vacation, we can let them "set it and forget it" and automatically set a date for Phase 2 to happen.

If very few have responded by the Phase 2 date, I'm not sure that's a problem that we can be expected to solve.

Also, I think we can safely assume that for this GBAS deployment, Nicole will be very on top of things.

Let's say the admin enters "Phase 2" when very few applicants have selected... maybe they pressed "Generate schedule" by mistake, or most of the participants are laggards like I mentioned above. Is there a way to automate the schedule again when more available times come in?

Yup, I just updated the simluation to include this. You can run an "auto-book" at any time, and it won't change any appointments that have already been scheduled. (This makes it safe to run at any time.)

We're asking the staff to do a lot of work: either we make them manually adding a bunch of "hold" invites to their calendar, or we attach one invite file for each event to their confirmation email, and make them open and accept each one. Is it a reasonable assumption that they'll do all of this? If enough staff members don't, GBAS will run into the same headaches.

This is a good question, I'm glad you bring it up. Instead of sending calendar events (.ics files?) and expecting users to manually download and add them to their calendar, we could publish a per-user calendar feed that would automatically update. (Here's a project where I've done this before: https://github.com/ajb/milestone-cal)

We can also encourage users to pick less-selected timeslots by subtly highlighting them and prompting them with some friendly copy.

I see this as kind of the core of my original flow, but I thought you said it wasn't technically feasible to implement. Could you explain again what makes my concept difficult to build? If I have a better understanding of this, I can be more effective in making valuable contributions towards what we eventually decide upon.

To be clear, this is what I'm advocating for in my flow:

It's kinda clunky, but it could help the algorithm be more effective.

The part of your concept that I'm resistant to is that all of the flows in this screenshot would add a ton of complexity to our application, and in my concept, they are consolidated into a single flow.

[jrubenoff]

That all sounds good!

As for sketching out flows, I used to draw it out on a whiteboard or notebook and upload a picture, so you could always do that too.

I guess most of the thinking around my flow centers around sorting the timeslots on that page by the number of selections, so that the UI incentivizes admins to fully book slots. Does that make sense to you?

Most of the complexity you're referring to was based around my assumption that staff should be required to choose a minimum number of slots, which it seems like you may have abandoned, so that works.

Also, here are some questions on the modelling. Feel free to move them into gbas-schedule-modeling:

• What happens to the model if staff are biased against specific times (for example, if 80% of them are in the same meeting one afternoon?)
• If staff can select as few slots as they want, what happens to the model if a large number of staff under-select?

[jrubenoff]

From check-in:

• Initial tests of staff timeslot bias are promising, but we'll test against actual schedule data (the GBAS Doodle, maybe others if we can think of them?)
• If staff under-selected, we need to give the admin a path to success (up to us how we define that)

[jrubenoff]

It seems like this is resolved, but just to close the loop...

• @ajb, did you test your model against actual schedule data (GBAS last year, and/or other schedules?)
• I'll create an issue for when helping admins when staff under-select. (The feasible answer might be "contact them manually and manually schedule", in which case we don't need to do anything.)

[ajb]

This issue was moved to dobtco/scheduler#25