Gathering Meaningful Feedback in iOS Apps

What defines a mobile platform is the apps. There really isn’t any way to get around this. You can have the best looking user interface and a personal assistant who knows your cat’s name, but without high quality apps, the platform will fall flat. Amongst the apps, comes many challenges for mobile developers, but one in particular is the challenge to get meaningful feedback from the customer to the developer. You want 5 stars, right? In this article, we will take a look at why feedback is so important and then look at how several major brands implemented it as well as how Telerik is innovating in this space.

Why is Feedback so important?

Imagine that you just finished publishing an app without any way for the user to submit feedback. A few days later you take a look at your ratings in the app store and notice that you have 20 one and two star ratings because they found a bug before you. This bug is easily crushed with a line of code and approved into the app store again. A few days later you notice your ratings went up but people are leaving feature request in the comments. You would rather them send you this feedback directly. By implementing some sort of feedback mechanism in your app, you will have a two-way conversation with the end user. This can potentially stop negative reviews and turn them into loyal fans. Now that we know this is a good idea to implement, let’s see how other major brands are doing it.

How are some of the best apps approaching this?

I’ve found three main methods that a majority of major brands are using in the App Store :

1. Sending an e-mail.

One of the most common methods that I’ve noticed in the app store is simply sending an email. This can be accomplished with just a few lines of code and is used in everything from hobbyist apps to well-known brands such as USA Today shown in Figure 1.

usa1


Figure 1 : The USA Today App uses e-mail to send feedback back to the team. Figure 1 : The USA Today App uses e-mail to send feedback back to the team.

The main issue with sending an e-mail is concerns over user privacy. With all of the recent NSA articles, not everyone wants to disclose their personal e-mail address. It also leaves the user to “fill in the blanks”. They need to describe what type of feature, bug, or general help that they need. Sure, you can automatically fill in information such as the current app version they are running, iOS version installed, etc. The real question here is, is this is enough information to provide meaningful feedback? It also assumes someone is actually monitoring all the emails coming through. This may be sustainable for a smaller iOS development shop, but what about the apps with 250K users?

2. Send the user to a web page.

It is very common for an app that does not use email to provide feedback to instead redirect the user to a web page. This is very common with User Voice, as the existing infrastructure is already in place. You simply sign up for an account and depending on your needs, you can gather feedback in a variety of ways. Yahoo! News Digest (which won the 2013 Apple Design Awards) uses exactly this method as shown in Figure 2. It simply redirects to Yahoo’s User Voice with the additional option to open in Safari.

yahoo1


Figure 2 : Yahoo! News Digest redirects users to a web page hosted inside their app. Figure 2 : Yahoo! News Digest redirects users to a web page hosted inside their app.

Others decide to roll their own custom web page and ask specifically for the feedback they are looking for as shown in Figure 3.

fandango1


Figure 3 : Fandango uses a custom web page that collects exactly the data they want. Figure 3 : Fandango uses a custom web page that collects exactly the data they want.

If you choose to redirect users to a web page then, once again, you will be depending on an active internet connection the same as when composing an e-mail.

3. Use Native controls and send the data to their own backend service.

This method is probably used the least out of all the apps that I’ve examined in the app store because you are required to provide your own infrastructure. The end user will simply navigate to the feedback page of some sort and the app will collect data and send it to their own backend service as shown in Figure 4.

Figure 4 : The Weather Channel uses native controls to collect data that is sent to their BaaS.

Figure 4 : The Weather Channel uses native controls to collect data that is sent to their BaaS.

The benefits to using this method is that the developer is in full control of what is displayed to the end user and can persist data as it is being entered. When all the data is collected, they can submit the feedback to their backend service.

How is Telerik innovating around this?

Introducing AppFeedback for iOS (and other Telerik products)

Our AppFeedback component is designed to be easily implemented and provide a two-way conversation between developers and end-users. They can simply shake the device or navigate to the feedback option and either send or view feedback. If they send feedback, then it will take a screenshot allowing the user to provide comments that the developer can respond to. If they view feedback, they can see all the feedback that they have submitted, view the status, give additional comments and view the developer’s response.

How do we implement it:

  1. Create a Telerik Platform account and add the project type called, “AppFeedback project” as shown in Figure 5. It doesn’t matter what you call the project, just make note of the API key that will be used later on. This takes care of all the backend plumbing that normally you the developer have to do with a single click!

    Figure 5 : The AppFeedback Project Template does all the backend plumbing for you.

    Figure 5 : The AppFeedback Project Template does all the backend plumbing for you.

  2. Download Telerik UI for iOS and add TelerikUI.framework to the linked frameworks and libraries in your project properties.
  3. Create a new Single-View Application and import the Telerik framework into your ViewController.m file.
  4. Give your Storyboard ID the name “Main” and make sure there is a checkmark on “Use Storyboard ID”.
  5. Add a Button to the Storyboard and implement it as an IBAction (You can leave everything else as the default options).
  6. Switch to the ViewController.m file and add the following code: (This sets up our TKPlatformFeedbackSource to be used anywhere in the application in case you want to add the ability to trigger the feedback component when the user shakes the devices as well as initializes our API Key and UserID).
    @interface ViewController ()
     {
      TKPlatformFeedbackSource *_platformFeedbackSource;
     }
    
     @end
    
     //API key found in the project properties of the App Feedback
     static NSString *apiKey = @"your-api-key";
    
     //User ID used to send feedback to Telerik AppFeedback service
     static NSString *uID = @"name@company.com";
  7. Add the following code inside the button’s method stub found in ViewController.m.
      - (IBAction)sendFeedbackManually:(id)sender {
    
      UIStoryboard *MainStoryboard = [UIStoryboard storyboardWithName:@"Main"
                                                           bundle: nil];
    
    
      UINavigationController *navigationController = [[UINavigationController alloc] initWithRootViewController:[ MainStoryboard instantiateViewControllerWithIdentifier:@"Main"]];
      navigationController.navigationBar.translucent = NO;
    
    
      TKFeedbackController *feedbackController = [[TKFeedbackController alloc] init];
      feedbackController.dataSource = [[TKPlatformFeedbackSource alloc] initWithKey:apiKey uid:uID];
      feedbackController.contentController = navigationController;
    
    
      self.view.window.rootViewController = feedbackController;
      [feedbackController showFeedback];
    
      }

This code finds the Storyboard with the name of “Main” and instantiates it into a variable to be used later. We then create a UINavigationController that will be used to help the user navigate from one screen to another once invoked. Next we instantiate TKFeedbackController and give it a datasource that contains our API key as well as a UserID. We also have to set the contentController to our navigationController created earlier. Finally, we wrap things up with setting the rootViewController to our feedbackController and run the method called, showFeedback.

A sample from the end users’ experience to the developers’ experience is shown Figure 6. Here the end user notices that the slider control isn’t updating the label on the screen. They simply initiate the AppFeedback component and place a red dot where the issue occurs and provide text detailing the problem they found. The developer will open the portal and can view the screenshot on the right hand side and other device information and respond to the user directly letting them know the team will investigate. The end-user is then able to respond back with any additional info. While I didn’t show it, the developer can also select the option “Post and Resolve” to let the user know the bug has been fixed.

Figure 6 : The Feedback component in action.

Figure 6 : The Feedback component in action.

Note: The full source for the demo can be found on Github.

Conclusion

As you can see there are a lot of ways that developers are implementing feedback in their native iOS apps – from email, to existing webpages, to native controls that send their data to their own backend service. While each has its pros and cons, you can’t escape the fact that meaningful feedback is important in any app. By gathering feedback, you can not only solve problems, but develop relationships with your customers that will last a lifetime.

Comments