Tag: Mobile Apps

Recording Quick Screencasts on Android

Rachel

When I’m testing mobile apps, I often create quick screencasts to accompany my bug reports. Screencasts are especially useful for capturing issues that aren’t visible in a static screenshot and for demonstrating the exact steps to reproduce the issue. I try to keep them as short as possible for easy viewing.

Lately, I’ve been using Android Debug Bridge (adb) for these screencasts on my Android test devices. With adb, you can create a screencast on the command line — no need to install any apps on the device or deal with convoluted steps to transfer the files. It also means I don’t have to open up Android Studio just to record my device. Quick and easy!

To get started:

  1. Make sure you have the Android SDK Platform-Tools package installed on your computer. You can install this package from the Android Studio SDK Manager or download the standalone SDK Platform-Tools package.
  2. On your Android device, go to Settings > System > About phone and tap Build Number seven times. This enables Developer options which you’ll now see under Settings > System. From there, you can enable USB debugging.

Once you have that setup done, connect your device to your computer via USB. You should get a prompt to allow USB debugging; you can set your device to always allow it from your computer, or choose to get that prompt each time you connect your device.

Now, recording a screencast is just four easy steps:

  1. On the command line, run adb devices. This isn’t strictly required, but I do it to make sure my test device is connected and authorized for USB debugging.
  2. Then, start the recording with adb shell screenrecord /sdcard/screencast.mp4 (specifying your desired directory/filename). The maximum recording time is 3 minutes.
  3. Stop the recording with Control + C (Command + C on Mac).
  4. Move the recording from your device to your computer with adb pull /sdcard/screencast.mp4. You can also specify a local destination for the recording, e.g. adb pull /sdcard/screencast.mp4 ~/Downloads/screencast.mp4.

That’s it! Your screencast is now available on your computer for you to handle however you need. You can also check out the adb documentation for more screen recording options and other useful actions you can take with adb.

Do you have any favorite tools for creating, editing, or sharing screencasts, especially on mobile devices? I’m always open to trying out something new!

Advertisement

Right-to-Left Testing in Mobile Apps

Rachel

Did you know that both iOS and Android have easy ways to build your apps for localization testing?

As someone who loves languages, I’m used to just switching a test device into another language for testing and dogfooding over a longer period of time. But even I get a little scared that one day I’m going to switch my iPhone’s device language to Arabic and never find my way back to the language settings. And for teammates who don’t speak another language, it can be even more intimidating. Here’s where iOS and Android come to the rescue with build options for localization testing.

Screenshot of WordPress for iOS app with RTL pseudolanguage displaying backwards English text.
RTL Pseudolanguage on iOS

In Xcode you can select a pseudolanguage in your build scheme. For regular localization testing you can choose Double-Length Pseudolanguage to see how your app works in languages with longer strings. (My teammate Eduardo also suggests using the iOS text size settings as another way to test this on the fly.) But for RTL testing it’s especially handy — choose either Right-to-Left Pseudolanguage to get an RTL layout with regular English strings or Right-to-Left Pseudolanguage with Right-to-Left Strings to see the English strings backwards in the RTL layout. Build your app and you can test out the RTL experience, no language classes required!

For Android, you can enable pseudolocales in your build.gradle file. Then, on your device or emulator, go to the device language settings and select English (XA) or Arabic (XB). (If you don’t see those languages, make sure developer options are enabled.) The first language gives you lengthened strings and all kinds of exciting accented characters, but the second is where RTL testing kicks in — you get English strings backward with an RTL layout.

Now, off to file some GitHub issues for the localization bugs I just noticed … 😉

Sharing User Feedback from App Reviews

Rachel1 Comment

Over the past year, I’ve been working fairly closely with the mobile app team at Automattic. As I got more involved, I tried to help close the feedback loop with the team by taking advantage of the feedback our users were already giving us — so of course I took a look at our app reviews.

It’s hard to look through app reviews. I mean, on one hand, it’s just emotionally draining to be hit with that barrage of unmediated criticism (although the unmediated praise is wonderful!). But it’s also hard to grok all that feedback when it’s just a stream of comments. So I decided to collect that feedback and present it to the team in an easier-to-digest format. I’ve now gone through that process several times and want to share it in case it helps you process reviews or other feedback from your customers.

Collect and Organize the Feedback

The first step is to gather up all the feedback. I used App Annie, since our mobile app team was already using it. I decided to identify all the reviews from the latest version of our app (in my case, it was the WordPress app on two platforms, iOS and Android) and export them. This conveniently dumped all of the ratings, reviews, and user details into CSV files (one per platform).

Then, I set up a spreadsheet for each platform and focused on a few key details:

  • The user’s rating (from 1 to 5)
  • The review’s title and content (adding a translation where the review was in another language)
  • The main issue in the review
  • Any secondary issues or notes about the review

How did I identify the main and secondary issues? A little analysis.

Analyze the Feedback

To find the main and secondary issues, I read every single review from that version of the app. I picked keywords to describe the main issues users described and assigned one of these keywords (categories) to each review.

If you’ve ever coded survey responses, this is a similar process. If this is the first time you’ve done this, here are some tips:

  • Read through all or a representative sample of the reviews. (For your first time, and especially for an unfamiliar product, you might need to read all of them.)
  • As you read, make notes about the topics or keywords that come up (more is better at this stage).
  • Pare down your list to a subset of more general keywords. For example, for the WordPress app I used keywords like “Editor,” “Login,” and “Media upload.”
  • Go through the reviews one by one and assign a keyword for the main issue the user described.
  • If the user mentioned more than one issue, or there is additional detail that you think will be helpful later on, add it in the field for secondary issues or notes. For example, I found a number of reviews with the “Editor” keyword that specifically mentioned “limited features” in the editor, so that went into the second field so I could keep track of that sub-issue.

Pro tip: To keep my sanity, I worked from 1-star reviews to 5-star reviews, so the toughest criticism came when I had the most energy and the work got easier and more cheerful as I went.

Once I was done assigning keywords to each review, I organized the spreadsheet by those keywords so I could see which issues were most commonly reported. I made adjustments to the keywords, looked for subsets of related issues, and checked everything for consistency. Finally, I got ready to share my findings.

Share the Feedback

I had a few self-imposed guidelines for what I wanted the team to get from this user feedback:

  • Praise for the things we are doing well
  • A clear picture of the top pain points our users experience
  • Suggestions for what action could have the biggest impact

Here’s a template showing how I organized my report:

Overview:
- Number of reviews
- Average rating
- How ratings are weighted (evenly spread? split between 1 and 5 stars?)

Highlights:
- Features or experiences that our users enjoy and appreciate
- 2-3 quotes from positive reviews

What did users mention in their reviews?
- The top three issues mentioned in reviews
- For each issue, an explanation of its impact (how many or what percentage of reviews mentioned it? what were the star ratings for those issues?) and a little context about what exactly users discussed and your interpretation of the source of the problem
- Links to any open bug or enhancement issues the team is already tracking, or any ongoing work related to the issue

Suggestions for followup:
- One or two projects, or open issues in the bug tracker, that the team could make a top priority to help address this feedback
- Any other user feedback (for example, from customer support interactions) that could shed additional light on the feedback in the reviews

I shared this with our entire mobile app team (along with the spreadsheets with the raw data), inviting questions and discussion. Although we haven’t taken action on every single issue, it has led to some quick wins, reprioritizing, and planning ahead with our users in mind.

I hope this is useful to you and your team! If you try it out, let me know how it goes. And if you have ideas for how to improve this process, I’d love to learn from you.