Collecting and analysing in-app feedback can be very straightforward – provided that you have the right tools and methodology in place to do so. In a previous article, we outlined several reasons why collecting in-app feedback is important for the mobile user experience. The next step is to demonstrate how this feedback can be collected. There are three options to choose from when it comes to collecting feedback in-app – all of which offer their own advantages and drawbacks. These methods include: Webviews, SDKs and APIs.
This article will define and analyse each individual method, giving you – as a mobile marketer -more clarity on what these methods can and cannot do and what is expected of you in order to implement these methods.
Let’s get started with the first method: webviews.
What is a Webview?
A webview is – by definition – a browser that has been packed into a mobile application (which produces what is called a ‘hybrid app’). Webviews allow mobile apps to be built using web technologies, such as HTML, CSS, or JavaScript and still be packaged as a native app that users can find in the app store.
When collecting feedback through a webview, all the user needs to do is load a feedback form into the webview using their feedback software provider. The process of doing so is basically the same as loading a feedback form (as a web page) into the shell of the mobile app. A good example of this is an ecommerce or sports app.
Note: A webview is not the same as a mobile responsive website. When a website is responsive, the layout and/or content responds or adapts based on the size of screen they are presented on. A responsive website automatically changes to fit the device you’re using. Typically there are about four screen sizes that responsive design is geared towards: the widescreen desktop monitor, the smaller desktop (or laptop), the tablet and the mobile phone. As the screen gets smaller, the content shifts and changes to the best display for each screen.
Free White Paper: The importance of A good Feedback Strategy
Learn about asking the right questions in an online feedback form to get the most out of it.
In-App Feedback via Webview
Here is a closer look at what collecting in-app feedback via a webview can offer and where it falls short:
Advantages:
- Quick and easy to implement. All you need to do is link the URL from where your feedback form runs, into the app through a webview. More advanced feedback tools have a unique URL where the feedback form runs as standalone. What this means is that it’s not inside a slide-in or modal on a page, but rather the form can be addressed using a unique URL.
- Easily release / make changes to the feedback form. This can be done without releasing a new version of the mobile app.
Disadvantages:
- May interfere with the in-app experience of a user. Webviews can sometimes make a user feel as though they are outside of the app (depending on the design), even though in theory the user remains within the app. Therefore, it is very important that the webview is well integrated within your app. To do this, however, it might cost you some extra effort, time and customisation.
- It’s not possible to make use of some native / mobile functionalities. Because you are loading a web page through a webview, some functionalities won’t be available including taking screenshots (e.g. visual feedback), GPS (via location services) or adding a picture (using the camera).
- An internet connection is always required. Mobile apps that run completely native can function without an active internet connection. However, webview requires a constant connection. If there is no connection, there is no feedback form in your app.
What is an API?
API, or Application Programming Interface, is a set of definitions, protocols and tools that are used for building application software. Most large companies have, at some point, either built APIs for their customers or for internal use.
Development teams often break up their application into several servers that can communicate with one another using APIs. The servers that support the main application server are called ‘microservices’. A company that offers an API to its customers is another way of saying they’ve built a series of dedicated URLs that supply pure data responses – or, ‘raw’ responses – that you won’t see in the user interface of a website.
Two Types of Feedback APIs
With respect to customer feedback systems, there are two types of APIs. One API is used to direct feedback into a platform. Some examples of this are a post from the website or transferring feedback from a mobile app into the feedback collection system.
The second API is one that will retrieve and export feedback from the feedback system. For example, it can extract feedback from the system and add it to a project management tool such as JIRA or Trello.
In-App Feedback via API
Here are the advantages and disadvantages of using an API to collect in-app feedback:
Advantages:
- Freedom and flexibility on how to build and implement. With an API, there are no rules you must follow. In other words, you have complete control of how you implement your feedback forms. You build it yourself, decide how your feedback form(s) look and choose when / where they will appear in your app.
- All mobile device functionalities are available. Although you will need to develop it yourself, you will be able to use mobile functionalities such as GPS, camera photos or screenshots – whereas with a webview you cannot.
- Feedback form(s) can function without an internet connection. The feedback response can be cached, meaning it is submitted whenever the user has connection. This is important because some mobile apps are built to fully function without an internet connection. For example, a travel insurance application that is used to make an insurance claim on location. Say you have an incident abroad but you do not have access to the internet. The app caches your insurance claim so that when you are back in a WIFI zone, it can submit all of your data to the insurance company.
Disadvantages:
- Cannot easily make changes to the feedback form without releasing a new version of the mobile app. For example, when you want to add or change a question in the feedback form you will need to change the interface and the API post and release a new version of your app that users will then need to download / update.
- You have to design your in-app feedback form yourself. However, many mobile development frameworks have pre-built modules that enable you to build an interface quickly.
- There is a longer learning curve. It’s important to get to know the API of your feedback software supplier. This will include relying on all documentation and guides to sort out any errors or confusion. This is why it is ideal if there’s a community available where you can ask questions. It could also cost more time to develop because you are building everything yourself.
What is an SDK?
For those who are unfamiliar, the acronym SDK stands for Software Development Kit. An SDK is a downloadable software package that includes the tools needed to build on a platform.
According to Twilio, ‘An individual SDK is often heavily customised for its platform, but a typical SDK may contain the following’:
- Libraries or APIs: these are pre-defined pieces of code that help you perform common programming tasks on the platform.
- Integrated Development Environment (IDE): an editor that enables users to design graphic elements such as buttons or text boxes. IDEs are very common on mobile SDKs.
- Additional Tools: these are often used to carry out tasks such as debugging, building, running and testing your application.
Try any of Mopinion's Mobile SDKs today!
Start gathering powerful feedback from your native apps with these flexible and easy-to-install SDKs for in-app feedback.
SDK vs API
An SDK is a complete set of APIs that enable users to perform any action needed to create applications. An API on the other hand is just a series of related methods that may be good for a specific purpose.
To put it into perspective, let’s use an example.
The Java Development Kit (JDK) not only contains the API but also compilers, runtime systems, and other miscellaneous tools. The Java API is simply all the libraries that make up the core language that you can work with out of the box.
In terms of in-app feedback software, there are various solutions for collecting feedback inside a mobile app whilst using platform-specific SDKs. Examples include a Swift SDK for iOS or a JAVA SDK for Android.
Various SDKs are available to you depending on your programming language, the platform you’re developing for, and the kind of communication solution you need (e.g. posting feedback to your feedback software provider).
In-App Feedback via SDK
Here’s what SDKs can and cannot offer in terms of in-app feedback collection:
Advantages:
- SDKs allow you to quickly get things up and running. It is easy to integrate new features to your app (e.g. collecting feedback). A lot of things like authentication, posting feedback to your feedback supplier and validation of input fields are already taken care of.
- Easily make changes to the feedback form without releasing a new version of the mobile app. What this means is that you can add / change questions or designs from your feedback tool, rather than having to program it into the app.
Disadvantages:
- Longer learning curve than with a webview. Similar to an API, you will need to familiarise yourself with an SDK. There are some SDKs that are very well-documented and have an active user base. Github is a good example of this. However, if that is not the case, it may be wise to choose an in-app feedback supplier that offers great customer service.
- You are reliant on the quality of the software of your app as well as the SDK. With an SDK, you are essentially running a piece of software inside a piece of software. So even if your mobile app and the SDK you are using are both developed according all software development conventions, issues still may occur. It is also important to be aware that SDKs easily slow down the performance of your app and may introduce flaws to the user experience. For example, you could be loading in modules that you do not use or that interfere with other functionalities of your app.
Assessing which method is best for your business…
As you can see each method has its own pros and cons, including requirements for implementation, technical know-how and performance once implemented.
Our advice to you? Define your goals beforehand as well as assess which resources you have and which resources you need – especially from a technical standpoint. Obviously not all of these methods are right for every company so by laying out your goals and capabilities, it will be much easier to decide which method is right for you.
Want to learn more about in-app feedback?
Get a free copy of our White Paper now!
