Getting User Input through SMS Text Messaging - PHP dotGo Engine package blog

Your Default Messages

User Input

Conclusion

Introduction

In the previous article, we explored the terminating nodes and how they are used.

In this article, we are going to step up the communication between you and your users by requesting information from them.

I will be providing examples using the administration interface from the PHP dotGo Engine, so if you have already installed it I recommend starting it up to help you follow along.

I will also be referring to previous steps performed in this first and second articles in the series. If you have not already become familiar with the concepts presented in those articles, I recommend that you take a moment to review them.

Your Default Messages

As we learned in the first article, the PHP dotGo engine develops responses based on keywords, however there are 2 responses that are generated directly in the dotgo.class.php file. These are your default messages.

The first default message we will look at, is the message displayed when our engine is unable to find a match for the keywords sent. If you open up the dotgo.class.php file in your favorite text editor, around line 106 you will find the failedResponse property. It will look like this...

$this->failedResponse = array(
 'responseType'=>'msg',
 'content'=>'No information is available<br />Please try a different request'
);

The responseType property indicates that it is a 'msg', message, response and the content will be the message returned to the user. In this case, the notice that they should try again.

There are 5 values for the responseType that correspond to content types we use in the admin interface. They are 'msg' (message), 'qry' (query), 'ctm' (custom), 'rss' (rss feed) and 'eng' (engine).

You will only use these when building responses outside of the admin interface, for example in your own custom engine, however that advanced topic is outside the scope of this particular article.

The second default message we will discuss here is the result of no keywords sent, the null match. It is what your users will see if they just send the designator, yourdomain. Around line 111 you can see the defaultResponse property. It will look like this...

$this->defaultResponse = array(
 'responseType'=>'msg',
 'content'=>'Hello'
);

As you can see, it is a 'msg', message, and the content will be 'Hello'. So when a user sends no keywords they get this friendly greeting. Although polite, it is not very useful since it does not help your user interact in any way.

We are going to change that right now by changing the defaultResponse to...

$this->defaultResponse = array(
 'responseType' => 'ctm',
 'content' => '<message>
  <content>Hello, what should I call you?</content>
  <input name="user_name">
   <message>
    <content>
     Where to <get name="user_name"/>?<br/>
     <a query="yourdomain hello"/> Say Hello<br/>
     <a query="yourdomain news"/> Latest News<br/>
     <a query="yourdomain goodbye"/> Say Goodbye
    </content>
   </message>
  </input>
 </message>'
);

User Input

Okay, looks like we have some things to talk about here. Notice that the responseType has changed to 'ctm' which stands for custom and is used when we want to return the CMRL exactly as entered.

We have to use a custom response in this case because our content is a nested message, which means a message inside a message.

The first message is our polite greeting with a request for information added, we want to know what to call them. That is right, we are going to start getting user input.

We now have a new element, the <input> element. The <input> element is what we use to get user input, which contains the name attribute indicating that we want to save that input as the variable user_name.

The next message is what will be sent to the user after they respond with their name. A new element introduced in the content here is the <get/> element. We use the <get/> element to display the saved value supplied in the name attribute.

So in this case, we ask 'Where to [user_name]?' and supply some options for them to choose. You will need to change the query from yourdomain to your actual domain.

The interaction from the start will look something like this, your user texts...

yourdomain

to the appropriate channel, DOTCOM, DOTNET, etc

They receive back the response...

Hello, what should I call you?

They reply with only their name...

Joe

They receive back the response...

Where to Joe?
(1) Say Hello
(2) Latest News
(3) Say Goodbye

They reply with only their choice...

1

DOTGO responds as if they sent 'yourdomain hello', which if you have been following along with the instructions in the previous articles will be the hello world/universe interaction.

The user also had the choice of sending the number 2, which would be our rss feed, or number 3 which is a the keyword 'goodbye' which we haven't set up yet.

Make sure you have saved and uploaded the changes you made to the dotgo.class.php file and point your browser to the admin interface so that we can add the 'goodbye' keyword.

You should now be in the admin interface, at the root keywords. Go ahead and add the new keyword 'goodbye' and then click on it from the keyword list so that we can add the content.

We are going to add this as message content by ensuring the message radio button is selected and adding the following to the content section...

Goodbye <get name="user_name"/>

and submit your changes to save them.

Notice we are using our new best friend, the <get> element, which in this case will actually display the [user_name] that was provided earlier. Once we have received the <input>, DOTGO will remember it for that user and we can always display it using the <get> element.

We also have started providing options with each interaction. We want our users to engage and interact with us and their experience will be so much better if they didn't have to try and guess what content is available to them.

We are also dealing with SMS messages, so the responses need to be short. Lead your users to what they are looking for with choices that take them down your keyword path.

Conclusion

In this article we expanded our default welcome message to include getting input from our users and how we can use that input to personalize our interactions with them.

In the next article, we are going to learn how to expand this further by recalling who a user is on subsequent visits and customizing our content to them. Are you as excited as I am?

If you liked this article or you have questions on how to get the input from users interacting with your site via SMS, post a comment here.