Creative Projects - Experience Prototype

tl;dr; Develop a first cut implementation of your prototype prototype that explores the interaction and experience with users. It should be interactive but not functional i.e. you can have a basic conversation with it.

Creative Projects: Experience Prototype

As part of this exercise, you’re going to prepare an interactive mock up of your bot. Think of it as an ‘invision’ demonstration. As part of this weeks exercise you’ll translate your application into a form where you can test the workflow and experience live.

What is an experience prototype?

Simply put, it’s a prototype that isn’t hooked up with complex functionality, real outcomes or third party services.

We’re basically building a ‘wireframe’ diagram with code.

As part of this:

You won’t:

  • connect to third party services e.g. make a call to giphy in response to a user request for images
  • integrate complex gems e.g. work out how to add new features
  • write details functionality or code

You will:

  • use a template application to create the bare-bones of your webservice
  • implement end-points even though they mightn’t do anything real
  • create ‘dummy’ content and responses in lieu of live data so you can prototype fast and test quick.
  • write pseudocode (or human readable comments) to highlight where you’ll add functionality and why
  • use stubs or placeholder methods as markers for functionality you’ll need to revisit down the road

Steps Involved.

You’ll need two diagrams.

  1. Your workflow diagram
  2. Your data diagram.

Starting with the workflow diagram:

  1. Copy a template application and do the basic setup to get a deployable application to Heroku.
  2. Look at your workflow and identify where you might need endpoints
  3. Translate your workflow into comments and place them in the relevant endpoints
  4. Iterate progressively to flesh out details
    • add expected parameters
    • add placeholders for methods
    • add conditional statements like ifs
  5. Iterate
  6. Keep going until you have a basic interactive version
    • If you’re working in SMS interfaces, you should be able to type commands and get a response (but it doesn’t have to do anything real)
    • If you’re working in Slack, link your incoming and outgoing webhooks and slack commands so they return basic responses.
    • etc.
  7. Deploy to heroku.

If you were going to do a giphy search application through SMS you might end up with something like this


get 'sms_gateway' do 
	# get the parameters from twilio
    sender = params[:From] || ""
    body = params[:Body] || ""
	# format the body correctly
    body = body.downcase.strip
  	# decide what to respond with 
    message = decide_response( body )
	# respond back to the message
    twiml = Twilio::TwiML::Response.new do |resp|
      resp.Message message
    end
end 

def decide_response body

  # response to the search 
  if body == "hi"
    "I'm a basic giphy search you can send me a command by saying search [something]"
  elsif body == "help"  
    " you can send me a command by saying search [something]"
  elsif body.starts_with? "search"  
    search_giphy body 
  elsif body.starts_with? "advanced_search"  
    advanced_search_giphy body 
  else
    "I didn't understand"
  end 

end

# this will search the giphy api
# and return an image matching a query from the user

def search_giphy query
    # return a dummy response for now... 
	# this will display a test image...
	"http://i.giphy.com/gw3IWyGkC0rsazTi.gif"
end

# this contains a method for advance search of giphy
def advanced_search_giphy query
   #...
	"http://i.giphy.com/gw3IWyGkC0rsazTi.gif"
   
end

Note Avoid the temptation to actually implement functionality like calling a webservice. Just implement the workflow. Note See the above example doesn’t actually connect to a live web application. It just returns a hardcoded image to test with. Note Ideally incorporate the personality and script developed as part of class.

Implement Data Models

Then, use your data diagram to begin

  • Create a migration for each table. Remember to pay attention to the names involved. Plural for tables. Singular for models.
  • In each migration, add the required columns.
  • Create a model for each and add any validations and associations.
  • Make sure the model is included in the app.rb using a require_relative ./models/<model_name>
  • Check and double check your migrations and namings.
  • Then apply your migrations using rake db:migrate

Deploy and Test

There’s a few ways you can test.

  • I highly recommend using cURL to test your app locally before you deploy. It’s a really useful strategy. If you’re going to do this, you can a) set up a dummy endpoint that allows you to pass information you’d like to test and get sample responses or b) simulate the kinds of calls you expect to get from whatever bot communication platform you plan to work with e.g Twilio. If you go with b; add a puts params to your endpoint, deploy to heroku and test the

  • Once your confident the code works, deploy to heroku and test through the proper platform (Twilio’s SMS, Slack or Alexa).

  • Make sure you’re happy with the workflow, the interactions, conversation and outcomes. Adjust as necessary.