The App Store has tons of applications and it can be hard to stand out amongst the big players. However, one of the ways developers can do this is by ensuring they get the little details right. A great app is one that stays great in all conditions. As a user I wouldn’t be pleased with an interface that breaks if there’s a double height status bar on screen, or if the text on the screen is not selectable.
While I was completing the development for LookUp, I started looking for tips that could help me improve the user experience. I came across a lot of interesting resources that helped me build a small list of items I could test each time I submitted to the App Store. More importantly, there were a few things that were so easy to miss during a regular test of the app that I’ve made a Separate checklist for them:
Accessibility Basics
The iPhone takes great care in making all its content accessible to everyone. So users should be able to expect the same from third party applications as well. Here are some tests you should know how to perform in terms of accessibility:
Grey Scale Test
A grey scale test is a simple user interface test that makes sure that the visibility of all elements remains unchanged when using the phone in grey scale mode.
This is particularly helpful to those who are color blind. Elements that use different hues of color to differentiate between the on and off state are the best example of grey scale violators. In general it is good practice to add a stroke or have good color contrast between the on and off states to give clear feedback as to what state the element is in.
VoiceOver
VoiceOver is a great accessibility feature that allows users with visual impairments to navigate through iOS easily, but a lot of apps skip implementing it or sometimes implement it in a manner which isn’t very helpful to the user. It doesn’t take much effort to implement though; so here’s a checklist that might help:
- Label your Element – Labels are generally succinct. For instance, if it’s a search button, Search is a much better label than “A button to find things”.
- Define its trait – Define what kind of element it is. Is it a button or a slider? This might seem trivial but it is a great design practice, and something that’s helpful when using voice over.
- For Value Based Elements – Let’s say the app has a slider to set the percentage of opacity for a box. When I do a voiceover on the element, it’s much more useful if it says “Opacity: 30%” instead of just “Opacity.”
- Provide Hints! – Remember when adding labels: Were we succinct about them? What if some buttons need an explanation? Hints do the job for that! In fact, I believe it’s a good design practice to provide hints for every usable interface element, not just the complex ones. “Look for items” as a hint for search? Sure!
- Test With Screen Curtain On – Closely related to VoiceOver, iOS has a lesser known feature called Screen Curtain. With Screen Curtain turned on, iOS turns off the display on the iOS device. Making the app be used entirely on VoiceOver. And it’s not just about correctly labeling the buttons. It’s also about following the right hierarchy for switching between UI elements. That is, what happens when a user swipes towards right on his screen? Which interface element does VoiceOver go to? Does swiping right take me to the next element on the right side? Or does it take me to something completely different? Believe it or not, for a lot of people this can be the difference between a delightful user experience and one that is annoying. Screen Curtain tests also give you an idea on how the app would function for users who use switch control to navigate iOS. And while there’s no replacement to actually test an app with a switch controller, correct navigational hierarchy is always a positive and an indication that the app would do well with Switch Controller too.
The accessibility menu on iOS has become a really useful tool over the years, from providing dynamic text to enabling the use of devices via switch control. And in general, it’s a great design practice to make the app compatible with all of these accessibility features.
Support for Bluetooth Keyboards
One of the things that can be easily missed is the support for third party keyboards. How does the interface change when the user is not typing on the screen but from a keyboard?
Sometimes, apps have extra UI elements which they add over the keyboard to make it more usable for the app’s purpose (for example the extra pane over the keyboard layout in Editorial provides some essential markdown shortcuts). Personally, I feel that testing the app on a Bluetooth keyboard could be a great opportunity for developers to tweak and customize the interface in a meaningful way.
And there’s always the standard check to make sure that the interface doesn’t fall apart when you’re typing without an onscreen keyboard.
Background Audio
What happens when your app plays an alert and there’s a song playing in the background? Does it stop playing the song or just reduce its volume?
Believe it or not this is a real situation for all the apps that support Speech functionality for text. I faced a similar situation during the development of LookUp where the background audio would stop playing every time I pressed the speak button for reading out the text. At first it felt like a standard iOS thing, but then I looked at the Instapaper app, and they had a much better experience where they’d merely dim the background music and still let you use the speak functionality.
This is just one of the many ways in which the audio from your app can interfere with any kind of audio playing in the background!
No Configured Accounts
What happens when there’s no email account configured for the device and the app has a feature to say, send feedback? How does the app react then?
The desired responses could vary with different interfaces, but at the very least, the app should inform the user that there are no accounts configured with the device and tell them where that can be changed. Since we use Twitter for feedback in LookUp, I didn’t encounter this issue, but it is one scenario I feel is very easy to skip. I had no idea that this was even a possible situation until I read one of Nick Arnot’s slides on quality analysis.
Speech Functionality
iOS has this great feature which allows users to let their iPhone read the text for them. Unfortunately not every app supports it, even though it’s a great accessibility feature.
If there’s selectable text in iOS it’s a good idea to have the speak option as well. More importantly it should be tested properly. I remember when some apps had a weird bug where the speak functionality would scroll the text slightly upwards when activated. This is just the kind of bug that could go unnoticed in a quick test, and would be great to catch before shipping the app.
Multiple Language Support
A lot of apps have localization support. That is, they support the interface to work in multiple languages. To begin with, the very option of localization can be missed out. So, if your app is global and doesn’t necessarily rely on the English language, it’s a great idea to support multiple languages. iOS itself has great APIs to allow that.
More importantly, support for multiple languages can sometimes be tricky to implement. What interface elements need to be in the user’s phone language? And what interface should be English?
As a standard practice, translations aren’t usually encouraged but basic Navigational Elements and App’s Generic Interface text are supposed to be in the User’s Language. A great example of this is the Podcasts app by Apple. Where elements such as “Number of Unplayed Podcasts” and basic Navigational Options are displayed in the local language.
It’s a great idea to display Dates, Numbers and Actions like Cancel, Done, etc. in local languages. It’s also important to test whether the interface works smoothly in all the supported languages. This is especially important for Arabic languages that are read right to left and languages like Hindi and Tamil which follow a completely different typographic layout from languages like English. It’s important that the apps function well for all of these interfaces.
Some final thoughts
Quality Analysis for an app can be a tricky process. It’s hard to catch all the bugs at once. Even harder is to make sure your app works in all conditions. The above list is just some of the small things we usually miss while testing an app. There are a lot of other cases which need to be checked before one can really say an app has passed quality assurance tests.
Thankfully though, there are a lot of resources on the Internet. I found Nick Arnot’s Blog Neglected Potential to be particularly helpful. His talk at the 360iDev Conference back in 2013 had some of the best tips for testing iOS applications. I also found David Addey’s checklist of things that need to be tested before releasing an app to be a useful resource. It’s really concise and covers nearly all the scenarios you should test your app against before releasing it.
If you have any quality assurance tests you think are worth doing, I’d love to hear about them in the comments.
