Currently "Small" (100mb, $39/month) — will want to adjust based on usage; can probably make big for launch and then bring down to lower tier a few weeks after

As the last step to the process - optional step for those that need it + what it's for, how you use it etc.

Right now the builder prompts the user to set up their CityVoice survey with a number from a free,trial Twilio account. The trial accounts give every survey respondent calling in a confusing "please upgrade your account" prompt. This will deter City staff users from pushing out their survey.

To avoid the prompt message, Twilio has advised us to set up sub-accounts for users that give them access to CfA credits. This requires a few significant changes in the builder:

• Remove direction to set up a Twilio account
• Create subaccount for the city with request to the Twilio API
• Connect the phone number to the Heroku through automation OR serve up a login to the Twilio subaccount for a user to do themselves

Related documentation for creating subaccountsI: https://www.twilio.com/docs/howto/subaccounts

This'll free up Redis storage since the data is now on Heroku anyway.

The UI for voice recording is okay but could be improved I think. I'm really bad at visual design so opening this as a stub in case someone else wants to take a stab. cc @cydharrell @phae

This is the current view:

Test whether adding additional help text at two points in the recording flow reduces attempts and quality of the recording:

1.Additional static text below:
"For a clear recording go to a quiet place; use headphones with a microphone if on hand"

2.After clicking record:
Add a 5 second countdown with direction to speak slowly and clearly.

Update text to:

• Clarify expectation that the user has all of their locations and questions figured out before they start the builder
• Nix the telephone as a necessity to start the builder
• Add direction to read user manual and contact cityvoice@ before getting started.

They tell you to add a phone number, but that’s not right. Tell people go visit the App URL and look for the number, or display the phone number in the builder flow.

Will need to write to app_content_set.csv; right now, the app in web just shows the default phone number

This will probably need to go at the "push" point (pushing to Heroku)

per @migurski — use alerts in style guide when useful: http://style.codeforamerica.org/

Based on feedback from @cydharrell

Ideally, a printable list of IDs next to the addresses they go to (could you organise them in a way that lets people efficiently route to drop off the signs on the way?)

The current copy at the end of your build says you can call in with location code 001 to try out the survey.

001 isn't a test location — it's just the first location. While I think it's still useful for people to call in after their deploy, we should rephrase the text and give instructions on how to reset the database (not hard, but it is command line-y).

App build response: {"id"=>"invalid_params", "message"=>"You've reached the limit of 5 apps for unverified accounts. Add a credit card to verify your account."}

Change all instances of [email protected] to [email protected]

I have to rewrite my script everytime I re-record.

feedback from @alanjosephwilliams — this is good and conservative

Right now, for Agree/Disagree questions we ask the user to provide both the text of the question as well as a "short name":

The CityVoice backend requires a short name, and it is shown as a header inside the CityVoice web interface, i.e.:

@migurski suggested removing the "short name" fields from the Builder — totally reasonable effort-minimization for a "trial" deploy — but opening an issue to discuss this.

If I do this, I will probably simply make the short names "Question 1", "Question 2", etc.

Probably a week to start off

per @migurski

Needs to make some copy additions to avoid common user errors.

More postmortem-y, but BLUF:

• Heroku's Platform API was changed to make the default stack a new one (Cedar-14 instead of Cedar)
• The new stack withdrew support from CityVoice's Ruby version, which broke new builds

I've confirmed my fix for this (by explicitly deploying to the older Cedar stack). I am also attempting to bump CityVoice to Ruby 2.1.3 and see if it causes problems. If not, I will upgrade the master CityVoice repo and update the builder to use Cedar-14.

cc @cydharrell

Particularly needed because if someone doesn't put in the city they may get something way out there — this'll let them do some trial and error.

For example

• Want to tell users they can download their tarball at /USERTOKEN/tarball/download within some timeframe (and that they can then follow the deploy instructions at XYZ in the Readme to further customize+deploy their version)
• Want to tell users how to delete their app

Now required by Heroku (per email)

Per @migurski

(within auto-expiration timeframe)

Off in the future, but a nice-to-have and pretty easy

Reported by @jmadans, for some reason the builder is having trouble reading (or possibly writing) audio files to disk prior to loading them into Redis.

Here's what's going on in the logs:

The relevant code is here:

    wav_path = params["data"][:tempfile].path
    mp3_path = "/tmp/#{user_token}_audio_#{audio_name}.mp3"
    # Convert wav to mp3
    system("lame -V 2 #{wav_path} #{mp3_path}")
    # Read mp3 as binary and put in Redis
    raw_mp3_binary_data = IO.binread(mp3_path)

It's blowing up on the IO read saying there's no file there.

This is odd — my guess is it's something related to a platform upgrade (ie, how shelling out is working) because otherwise nothing has changed in the code.

@migurski — do you have any thoughts?

Right now our beautiful functionality for making CityVoice surveys relevant in the digital world are completely hidden in the builder.

Let's add links at the end of the builder to wayfind people to their next steps.

If a question title has spaces, we need to properly deal with that in filename conventions. Straightforward fix, but need to implement.

Right now it's easy to think that you can type right into the sign (and that would be fun for a later version); it needs to be clear that there's a form below.

Weirdly, in Firefox recording only captures the first half of the audio. This is apparently an artifact of the underlying library we're using that wraps around HTML5's getUserStream.

@cydharrell discovered this bug, and I've got working code to fix it (per mattdiamond/Recorderjs#49 ) en route to master.

We want people to keep these snappy/readable - we should tell them exactly how much space they have in order for the sign to look good with our default layout & fonts.

Saw this in the city-analytics-dashboard repo, just need to implement same thing

So you don’t need to click a marker to see a map.

(When the app.json PR is merged)

per @migurski

Adding a ticket for this — @phae, can you throw me a link to what's the best to use for unified styling (at least for now)?

from @migurski

ideally across Chrome, Firefox, and IE

Because this builder app deploys to Heroku, we'll want "bridge" instructions for a user to be able to:

1. git clone from their Heroku deploy to their local computer
2. Further customize (links to documentation in main repo will suffice)
3. Reset the database to clear any data from when they tested the instance

This way, users can keep the locations/questions they configured using the builder app, but make further customizations.

"You will have thirty seconds to your record your comments?"

I don’t know what thirty seconds feels like, neither do most people. Can we let people finish their answer to the open ended question by hitting the # key?