You should always check that all links you have created work as intended.

Depending on your import type, some types of links may not work on mobile and tablet devices. 

For instance, a direct link to a PDF in an InDesign document will not work when exported with How to: Import in5 Content.

For more information, see How to: Link to a PDF with in5

Any interactive content should be thoroughly tested.

Make sure the interactivity would be intuitive for a user who does not have previous knowledge of the app.

More information on this topic can be found in Tips and Tricks for Creating App Content.

Any audio or video which is embedded on (or attached to) your app's pages should be tested.

Aside from checking that the audio/video works as intended, try to think about how a user might perceive this content.

For instance, a video which automatically plays when a page is loaded could be considered as invasive in some contexts.

Conversely, a media element which is not obvious on the page may be overlooked by a first-time user.

If you have included any other type of advanced app content, you should always make sure it works as intended.

Whilst the Liquid State system is very flexible, and makes use of HTML5 technology, some web elements may not yet be supported within Liquid State apps.

If you do come across a bug, or want to request a new feature, please raise a relevant ticket in the Liquid State Service Desk.

Some import types require much more rigorous testing than others.

Basic imports, such as PDF, Word, and PowerPoint documents, have very little interactivity. This means that, beyond checking the design of your pages, there is very little that you can actually test.

At the other end of the scale, advanced imports (in5 and custom HTML) offer a vast range of interactivity. With increased functionality comes increased complexity, and with increased complexity comes an increase in the likelihood of content bugs.

More advanced app content will require more rigorous testing.

Always check that your app is configured correctly.

You should check design elements such as your app's icons, thumbnails, loading screens, and theme.

You should also check app container (user interface) elements, such as your app's Table of Contents (ToC), launch notice, and included/downloadable content.

You should always use an app build to perform testing on all of the platforms you intend to publish your app on.

For instance, you shouldn't submit an Android app to the Google Play store unless you have tested it on an Android device first.

Different platform operating systems will interpret some types of app content in different ways. Never assume that app functionality will work the same across different platforms.

It is also a good idea to test on as many devices as possible. Even within one platforms operating system, some devices may interpret app content differently.

This is particularly important for Android, which runs on many different types of devices. An HTC smartphone may display content differently to a Samsung smartphone.

Mobile and tablet devices also use a range of different aspect ratios, meaning the physical proportions of a screen may differ between devices.

This is often seen when comparing Apple iPads to Android tablets. iPads use a 3:2 aspect ratio, whereas most Android tablets use 16:9 or 16:10.

Testing on devices with different aspect ratios will allow you ascertain if your content has been designed with too much of an emphasis on one device's aspect ratio.

Mobile and tablet apps were originally created as a way to offer content without requiring a constant web connection.

Although most users will be connected to the web, you should think about how your app will work if users don't have a web connection.

All standard page content is stored to users' devices once they download your app (and downloadable content).

However, advanced app content is often web-based. It is a good idea to try and keep your app well-balanced in this respect.

Too much web-based content might make for a bad user experience for individuals who try to access your app whilst offline.

Although Liquid State apps follow best practice for app navigation, it is always a good idea to think about how a user might perceive the app.

Is your content intuitive? Are there any elements on the page that might be confusing or misleading for a first-time user trying to navigate around your content?

Many users add navigation instructions to their app, either as a small dedicated content, or as a page at the start of each document.