Open daguar opened 10 years ago
@daguar To answer your immediate question: Yes/No is fine. Users just want an IVR survey that is straightforward and quick to complete. You can fit a lot of basic surveys into the yes/no format although multiple choice (I would recommend not more than 4 options) is something the city definitely wanted.
They wanted many other things as well which we can talk about more if you like. I'm happy to add what we learned with the South Bend redeploys in whatever place is appropriate to catalogue that.
@daguar @migurski I would also like to put together a longer term road map around CityVoice or has CfA started to put this together already?
I've done the basic implementation of Agree/Disagree on a branch here: https://github.com/daguar/cityvoice/tree/change-repairremove-to-agreedisagree
I'm wondering if we should make Agree/Disagree vs Yes/No an easy configuration option — it seems to be it's a useful case to ask Yes/No questions where Agree/Disagree is awkward.
An example to me:
@rduecyg — Would definitely love to get a roadmap and process around the project going. Right now, the work I'm doing is purely to make the redeployment experience as easy as possible, expected to be done in early August.
Closing for now — we can revisit Yes/No in the future.
Reopening — after speaking with @rduecyg, I'm more inclined towards "Yes"/"No".
I think this is borne out when you try to think about writing questions — "agree"/"disagree" questions come off as pretty awkward.
@jmadans I'd love your thoughts on this.
Still an open issue. For our pilots, I've decided to constrain the cities to Agree/Disagree statements.
In line with @dave's assumption, Cities don't have a clear preference for how to structure the binary question. It's dependent on the question. The fix here is to offer them a drop down menu to customize their question type.
I think we should offer three question types:
Right now, the app handles "structured questions" (the ones where you press 1 or 2) by having only two, hard-coded options — "repair" and "remove". This is vestigial from the South Bend case.
Because it'll be a fair bit of development work to allow for customizable numbers of, and text for, structured questions, we want to select a reasonable default for where the codebase is now.
Some options:
@migurski has a strong leaning towards 2, and I'm fairly agnostic. @cyd — do you have thoughts on this? @waltz and @rduecyg — in your South Bend reuses, did you learn a bit more about what users might like?