Adding Feedback to Your Application | Mining Google Web Services: Building Applications with the Google API

Most people have an opinion. The opinion doesn't have a right or wrong value ”it's simply how they feel about a particular topic. Getting an honest opinion from people can be difficult, but you can do it. When the topic concerns your application or Web site, the need to get an honest opinion is essential. Otherwise , changes you make to an application or Web site as the result of user feedback is going to be off target ”you want to target the users of your site to ensure they have a great experience.

When you mix interaction with another application, Google Web Services in this case, the problems of getting honest feedback intensify . You need to consider whether the feedback relates to your application, a connectivity issue caused by an ISP, the user's environment, or Google Web Services (among other things). It's not always easy to sort even a good opinion into the right area.

Tip

Don't assume that every positive feedback message you receive means that you're doing everything right with your application. Some people will tell you positive things to obtain benefits they might not normally receive or simply because they don't want to hurt your feelings. Likewise, not every negative message is an indictment against your programming practices. Sometimes a user will have a bad day and decide to take it out on you because you're the nearest target that can't attack back. Deciphering feedback often means reading the message several times and deciding just how it affects your application (or whether it affects your application at all).

The following sections discuss user feedback. This information reflects issues you need to consider when working with Google Web Services. For example, it discusses some of the problems of sorting information into the right area for consideration.

Designing User Feedback

One of the problems in getting good user feedback is designing the form so that it elicits a response, especially from users who don't normally express themselves well. A nebulous question, such as "How do you feel about this search?" won't net you a very good response. You need to direct the user to the kind of input you want, without contaminating the user's response. For example, "Does the search help you find the information you need on my Web site, or do you find yourself using alternative search techniques?" offers the user a choice and makes them think about alternatives. The question is still specific enough that even a shy user can provide an answer. Offering yes, no, and other (with a comment field) lets the shy user off the hook, but also lets vocal users state their answers in precise terms.

The simplest method for obtaining user feedback on a Web page is to create a form and send it to your email (or other location). Although this method does require a little interpretation, it has the advantage of allowing you to get feedback almost free. If you use a programmable email reader such as Microsoft Outlook, you can write a macro to interpret and save the results for you. Otherwise, the careful use of form values will let you read the report with a little effort. Listing 11.2 contains an example of a simple form that works with almost all browsers even if the user has turned off scripting support and cookies. You'll find the complete source code for this example in the \Chapter 11\SimpleRespForm folder of the source code located on the Sybex Web site.

Listing 11.2: A Simple, Low-cost Feedback Form

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Simple Response Form</title> <meta name="vs_targetSchema"     content="http://schemas.microsoft.com/intellisense/ie5"> </head> <body> <!-- Display a heading. --> <h1 align=center>Simple Response Form</h1> <!-- Define the form and anticipated action. --> <form action="mailto:JMueller@mwt.net?subject=Test Message"       method=post       name=SimpleRespForm       enctype="text/plain"> <!-- Ask about search engine performance. --> <label>Did the search engine work as you expected?</label> <input type=hidden        name="Q1"        value="Search Engine"/><br/> <label>Yes</label> <input type=radio name="1A" value="Y"/><br/> <label>No</label> <input type=radio name="1A" value="N"/><br/> <label>Other</label> <input type=radio name="1A" value="O"/><br/> <label>Additional comment (40 characters max):</label><br/> <input type=text name="1E" maxlength=40/><p/> <!-- Ask about link descriptions. --> <label>Were the link descriptions easy to understand?</label> <input type=hidden        name="Q2"        value="Link Description"/><br/> <label>Yes</label> <input type=radio name="2A" value="Y"/><br/> <label>No</label> <input type=radio name="2A" value="N"/><br/> <label>Other</label> <input type=radio name="2A" value="0"/><br/> <label>Additional comment (40 characters max):</label><br/> <input type=text name="2E" maxlength=40/><p/> <!-- Submit the form to email. --> <input type=submit value="Send" accesskey="S"/> </form> </body> </html>

For anyone who has spent considerable time working with Web pages, this might look like old technology crying for a makeover. However, this technique works quite well. I didn't include the accessibility information in this example for the sake of clarity. You could also dress it up a bit using Cascading Style Sheets (CSS). The underlying example, however, is easy to understand.

The focus of this example is the <form> tag. Notice that the action= mailto:JMueller@mwt. net?subject=Test Message attribute defines my email address as the destination for the data in the form. In addition, the email subject is Test Message. By giving each survey a different name, you know precisely where the user took the survey and what to expect as input. Most developers would stop here and complain about the results received in their email (a rather unattractive attachment). By adding the enctype= text/plain attribute, you can change the output to something that is easy to parse using any script and not all that hard to read using the email application's preview pane, as shown in Figure 11.3.

Figure 11.3: Encoding your survey form correctly lets you read it directly in email.

Tip

Many developers don't understand the mailto: URL very well. The problem is that the protocol doesn't appear very often on Web pages and most Web pages don't use the full potential of the mailto: URL. You can use most of the same fields with a mailto: that you use with an email program including such features as cc and bcc. You can find several good resources about the mailto: URL on the Internet. One of the better places to look is the Web Design Guides site at http://www.ssi-developer.net/design/mailto.shtml. Another good place to look for tips of this sort is the Ezine-Tips.com site at http://ezine-tips.com/articles/format/20001020.shtml.

Each of the entries in the email has a corresponding tag in the form that has the name attribute shown. Notice how the example separates the questions using a hidden <input> tag like this:

 <input type=hidden        name="Q1"        value="Search Engine"/><br/>

The value you provide should include a reminder about the question content. In this case, I provided a reminder that the question asks whether the user found every product needed.

The main problem with using this technique is content size. Forms can have a 255-character limit on the amount of data they can send, although this limit is apparently uncommon. (Make sure you also check for potential limits with the Web server that you use.) This means you have to provide limits on the size of comment fields using the maxlength attribute, as shown in Listing 11.2. You also need to design your form carefully and make answers terse whenever possible.

Developing Automated Feedback

This chapter doesn't delve into automated feedback systems because there are a number of resources you can use for this type of programming. Here are a couple of resources you should consider.

User Feedback HTML Form http://www.bytesworth.com/learn/html00009.asp
Creating Feedback Forms for WAP Sites http://www.aspfree.com/articles/1137,1/articles.aspx

However, given that many Google Web Services developers want to provide a research resource, making the feedback page friendly is critical. In general, the more you automate the feedback to make things easier for your company, the fewer users will be able to use the feedback system. This issue is especially true of form-based Web feedback because many users now turn off scripting, cookies, applets, and plug-ins for fear their systems will download viruses or experience other problems. Automation usually requires some level of client and server scripting, along with cookies and even plug-ins.

The problem even occurs with desktop applications. Some vendors make feedback available as part of a Help menu option. In most cases, the feedback form works and sends the information to the vendor (usually over the Internet). However, problems arise when the vendor assumes the user has a permanent connection to the Internet ”many users use dial-up connections. Fortunately, Google Web Services developers can assume that the user has some kind of Internet connection (even if it's through a proxy server) because otherwise their application won't work at all.

Tip

Some ISPs consider user feedback forms so important that they make them part of the documentation for their service. For example, check out the AT&T site at http://www.att.com/style/wc_feedback.html. This site tells how to create a user feedback for using the special features of the AT&T servers. Your ISP might provide similar services that you can use to make development of automated pages easier.