This post is about my software product Hyperion. You can read more about it here.
The Original Design
A Hyperion administrator is able to edit the PIT count survey: adding, deleting, and editing questions.
My expectation was that the workflow would look like this:
Edit the survey as needed.
Create a new PIT count in the software, and use it for that year.
Many months later, tweak the survey to reflect changes for the new year.
Create another PIT count for that year.
I architected the software with that use case in mind.
The survey structure is attached to the organization.
When an admin edits the survey (and saves it) the updated survey is saved to the organization.
When an admin creates a new PIT count, the structure attached to the organization is copied into the PIT count. Then, when a volunteer accesses the PIT count, they receive that version. When an admin makes a change to the survey, it doesn’t affect an ongoing PIT count.
The Emergent Behavior and Misunderstanding
In reality, the survey-editing process was iterative. Administrators would make a couple changes to the survey, create a PIT count, go through the volunteer portal to see what that was like, and then realize that they needed to make more changes to the survey. They could always create a new PIT count that would reflect the new changes but:
Administrators rarely realized this on their own. They would edit the survey in the admin portal and then expect that change to be immediately propagated to the existing PIT count. Then, they would reach out to me about a “bug.”
I want/need to have a revision system for the survey editing anyway. I’m planning on leveraging that to reduce confusion around the behavior and support the emergent behavior of iterative survey editing.
When administrators edit the survey and save, they’ll be prompted to give that survey revision a name:
When they create a new PIT count, they’ll choose which survey revision they want to use for that PIT count:
This alone should clear up the confusion around the survey editing behavior.
While I’m at it, I’ll add the ability to change the survey version currently available for a particular PIT count. This will allow their iterative editing and serve as yet another reminder that if they edit the survey it won’t automatically be applied to all existing PIT counts (behavior I don’t want for many reasons).