Your app will likely contain text, images, audio and/or video. Optimising this content will not only make it easier for you to upload content but it will also mean quicker downloads for your users.
At the start of each project we always get asked what format content should be prepared in for the app. It’s a good question and one we will explore below for each of the four main formats:
It is worth compiling all (or most) of your content together before adding it to the Content Management System (CMS).
Your Places and Trails app is location-aware. That means each place of interest is linked to a geographical location in the world. Compiling your content in a spreadsheet is probably the easiest way to capture all the information needed for each place of interest:
- Place name
- Trigger radius
Why not use this content matrix template for your content. If your app has multiple trails then use a separate tab (or spreadsheet) for each trail, remembering to provide the stop number in the first column to ensure your Places are in the correct order. At the top of the spreadsheet you will also have space to fill out general information about the trail e.g. Trail summary, distance and time to allow.
This will be a unique name (for the purposes of the app) that describes the Place e.g. St Michael’s churchyard. Try to keep it relatively short.
The latitude and longitude pinpoint the location of the place. Google Maps can easily be used to find the latitude and longitude of a Place, without even having to leave home! Open Google Maps and zoom into the correct area; in the example below I have chosen Chatsworth. I tend to work using Satellite view as it provides more information for me to find the exact location I am after – or enough of one to test on the ground once I have uploaded the content to the app. The default Google Maps view is Streetview so switch to Satellite view via the button in the bottom left corner (highlighted in blue in the screenshot below).
Two things appear on screen when I tap on the location of my Place:
- a small grey and white round icon with a pin (highlighted in yellow) representing the Place I have selected
- a pop up ‘modal’ at the bottom of the screen (highlighted in orange)
In the modal you will see e.g. ‘53.221487,-1.611440’. The first number (before the comma) is the latitude and the second is the longitude. However, these numbers can’t be copied. Instead tap on the numbers and the screen will change. See below.
Look to the left of the screenshot. Ignore the larger font (highlighted in the red box) that looks like: 53°13’16.9″N 1°36’41.6″W. This is the ‘degrees, minutes and seconds’ (DMS) version which is no use to us. We want the decimal version (highlighted in the green box) and you should be able copy and paste firstly the latitude (highlighted in blue) into one column of your content spreadsheet and then the longitude into another column. We keep them separate as they are added as separate entities in the CMS.
Imagine you are back at school and you have placed a dot on a map. Now take an imaginary compass and draw a circle around the dot. The distance between the dot and the circle is the radius. When someone using the app ‘breaks through’ that imaginary radius the app will notify the user that they are close to a Place.
The trigger radius is set in metres, and each Place can have a different trigger radius. The minimum radius is 5 metres. This is to take into account any inaccuracies in the user’s device. There is no upper limit but be conscious that you don’t want the trigger radius of two Places overlapping. If a user happened to enter this crossover zone (think of a Venn diagram) then the app would be confused as it would want to trigger both places at the same time!
Please note: Google Maps nor the Places & Trails CMS provide a way of showing trigger radius displayed on a map. The example above is purely illustrative. There are some online tools that may assist with this.
In the content matrix spreadsheet there are two further columns. One to provide the filename of your gallery image(s) – see ‘Optimising images’ below – and the other is to add your ‘body’ content. An example is provided in the spreadsheet and in this section you add text, plus the filename of images, audio etc in the order you want them displayed. Use bold to signify headings etc. Add captions and alt tags (accessibility text that describes the image that screen readers read for visually impaired users) below filenames, if required.
It’s worth noting at this point the importance of a good filename. The temptation is to upload the file with whatever name it was saved as (an image from your phone might be called 20220317_160857.jpg). Take a bit of time to rename the file so it relates to the Place e.g. st-michaels-churchyard-soldiers-grave.jpg. Note that a hyphen (an underscore is also fine) is used instead of a space. Spaces in filenames can introduce issues. You’ll also notice the comma in Michael’s has been removed. The rules to follow for filenames should be:
- use all lowercase – avoid capitals
- only use alphanumeric characters – avoid special characters e.g. @%#
- the exception for using special characters is to use – or _ instead of spaces
- never include spaces
Need help with your content?
We appreciate that creating content or compiling it to the correct formats can be a bit overwhelming. If so, why not ask us to help you?
There are two main image types: JPG and PNG. PNG files are generally larger but useful if you need to add a transparent background e.g. for a photo filter. For standard images in your app use JPG. Cameras and phones tend to take high resolution images that are thousands of pixels wide. However, for your app 1200 pixels is the sweet spot. The iPhone 13 Pro Max has a screen width of 1284 pixels wide (believe it or not but iPads has smaller screen dimensions), and many phone have smaller screens, so anything larger is a waste. On the flip side, avoid images smaller than 800 pixels wide because these may look pixelated on screen.
Changing the pixel size can be done on both a Mac and Windows computer using pre-installed software. On a Mac, open the image in Preview, select ‘Tools’ from the tab at the top of the screen and than ‘Adjust size’. In Windows you can use Paint. Ensuring you are in the ‘Home’ tab, find the option called ‘Resize’. Select the ‘Pixels’ option to change the size.
Once your images are the correct size drag and drop them into tinyjpg.com . This online tool will remove any unnecessary metadata and optimise the image without any loss in visual quality. It can reduce image file size by up to 80%, ensuring the quickest possible download speeds for your app users.
Finally, place all you images in one folder (per trail) so you have everything to hand when you need it.
Optimising your audio quality
If you have oral history recordings, music or other audio it must be uploaded to the CMS in MP3 – a universal audio file type that will play on pretty much any device. Unless there is good reason, the audio should be mono (rather than stereo) and between 96 and 128 kilobits per second (Kbps).
The MP3 format can range from around 48 to 320Kbps, and streaming services like Spotify range from around 96 to 160Kbps. In general, a high bitrate means better sound quality so it is about getting that balance between quality and download speed. 128Kbps, in our opinion, is the sweet spot for app content. The human ear will notice a significant drop in quality for anything below about 90Kbps. A 256Kbps audio file will be twice as large as one saved at 128Kbps.
As a listener, the most noticeable difference between mono and stereo is that the latter is capable of producing the perception of width, because there is a left and right channel. Stereo is not necessary for one person telling a story, but for a piece of music where you’d like to localise where the sounds e.g. different instruments are coming from. But in most cases mono will more than suffice and ensure the content is downloaded twice as fast as a stereo file.
A one minute mono MP3 file saved at 128kbps is approximately one megabyte.
In some instances we can embed very short video files within your app, but video files tend to be pretty large and often quite tricky to watch outdoors. For this reason we recommend video is streamed from the relevant page(s) in your app via YouTube. Users won’t need to leave the app page because the YouTube video player will appear on the page, inline with your other content.
YouTube is also very good at optimising video. You upload your video to YouTube and all you need to do is enter the URL in the CMS.
If this all seems a bit overwhelming then simply get in touch so we can help you out.