This project is read-only.

Possible changes to CheckInWizard.ascx(.cs)...

Nov 4, 2009 at 12:18 AM

I believe we may have mentioned this briefly on the IRC channel, but I wanted to bring it up here for a more formal discussion.  Our Children's team threw something by us a few days ago that we've been chewing on for the past couple days.

Since our campuses run Check-In a little differently, they're asking for a little bit more control over the system.  Here's the breakdown of how each campus likes to do things:

Gilbert Campus - Uses barcode scanners and USB 9-key keypads in addition to the touch screen kiosk. They like the added speed of the barcodes (it is quite fast if you've only got one kid to check in and there's only one service available... basically turns Check-In into a 2 or 3 click process).

Mesa Campus - Used to use barcode scanners, but with our latest enhancements to theming the Chlidren's areas, they've since dropped them.  They now only use the touch screen. They would like to have the ability to start the check-in process from the "Phone Search" state, bypassing the "Init" state that gives the user the option to "Scan Now - or - Search By Phone".

Campo Verde Campus - Our soft-launch is in 2 weeks for this campus.  Effectively will function the same as Mesa, with the exception of printing at the kiosk, rather than the location.  They would also like to start the check-in process from "Phone Search".

Currently, there's no easy way to implement these changes with our current code.  We're possibly looking at some pretty heavy refactoring/re-engineering ahead of us if our Children's team decides they HAVE to have this.  I wanted to throw this out there to for discussion, because refactoring this part of the system could allow us to add some additional features that I know are in demand.

Right now, we enter the system in the "Init" state.  Within this state, the system decides whether to display feedback regarding the system's ability to check attendees into Occurrences.  This state really does a LOT of things.  It'll display the "no classes available" status.  It displays the countdown.  It also handles the "ready" state of displaying the Search By Phone button and allowing the user to scan barcodes.  That's a lot of work for one state.  Nick and I have been letting the problem marinate a little bit and have arrived a this approach: Refactor the Init state into 3 states.

Bear in mind, we haven't written a single line of code yet.  This is all at the conceptual level so far, but here's our proposed meta-solution:

Init State - The (new) Init state will only display the "No Classes" message.  It will look at module settings and could also (possibly) look for query string variables to act on.  Since changing the state all happens before the Page_Render event, the "No Classes" message will never be seen if there actually are classes available.

CountDown State - The CountDown state's only function will be to display the countdown timer prior to an Occurrence's check-in start time.  Once we count down to zero, we get sent to Init again and routed to the correct state.

Scan State - The Scan state will be the new "ready" state.  It will display the Search by Phone button (if configured to do so) and allow you to scan your barcode (or finger at some point in the future).

So that's where we're at with this new set of challenges.  We're not acting right away on this, because it's not set in stone on our end.  I don't think "the powers that be" on our end have weighed all the pro's and con's of going down this road yet.  Again, we wanted to submit this for discussion, get feedback, and (ideally) consider this as a possible addition to our next release, post 1.2.0.

Nov 4, 2009 at 12:32 AM

All in all, I like the ideas.  We haven't been specifically asked to bypass the "scan" screen, but we have talked a little bit about it.  I would propose the addition of an "Init.Idle" state that is closer to what we have now for the Init screen.  Maybe a different graphic could be displayed so the kiosk could be customized to look more welcoming in this state?  When the kiosks are sitting there with nobody using them they seem to look odd just sitting at the phone number screen (I have seen it a few times when a kid hits the button and then walks away).

Idle State - Custom image is displayed if defined (default to standard image maybe) and the entire screen acts as a Begin button which launches into the Init.Scan (or Init.Phone) state.

The Scan State will check it's idle timer (how long has it been in this state without reload) and after x minutes, switch to the idle state.

I'm not at all married to this idle state, but its out for discussion. :)


Nov 4, 2009 at 4:35 PM
Edited Nov 4, 2009 at 4:37 PM

Just my first impression, the idle state sounds like what the Init state probably should be.  I've been thinking about this set of challenges and our proposed solution since I left the office yesterday.  I'm thinking it'd probably be best to move almost ALL logic out of the Init state (even in our new solution).  We already have a method for branching and setting state on the CheckInWizard page called ShowView().  I'll probably move most of the branching logic currently tied to Init into ShowView() and leave Init as a starting point, with a graphic and a single label whose text we'll set dynamically depending on whether there are any services available... and maybe a button to hide/unhide.  We'll see how it all pans out as we move forward...

Nov 4, 2009 at 6:48 PM

Would the "new" Init state be the default state or only the idle state?  i.e. If we have 5 people lined up, do they all get the Init state or does only the first one get the Init state and the next 4 go strait to the "Enter Phone" state?  I am thinking of something that does the latter...

Nov 5, 2009 at 5:57 PM

I guess that could potentially depend on how it's configured.  That's the thing that scares me more than a little bit about this whole prospect, is that we're introducing a LOT more complexity into a system that's already very complicated.