- We heard of contractors by word of mouth, and through internet search.
- It was helpful to have initial discussions with each of the contractors to help us identify realistic aims before inviting tenders based on these aims.
- We met with our preferred candidate before awarding the tender so that they could fully appreciate our situation and we could be satisfied that they were able to deliver what was required.
- It was important to define clearly the parameters and structure of the project as it is easy to get carried away with the potential of technology and set unrealistic goals.
- Involving a number of people with heritage expertise was helpful in thinking about what approach would be best for potential users.
- It was difficult to set realistic goals for content development without knowing how much content would be required.
- Our content development was done in-house. Had this not been possible, substantially more time and money would have been required.
- After 3 months the project timescale was entirely revised to take account of a change in app structure. This structure allowed for better understanding of the total scope of the project so timescales could be predicted more confidently.
- It is important to clarify exactly what you will need to develop and maintain the project at the start, in terms of human resources, practical resources, technical resources and finance (for example, expertise/software to develop app content, in-house skills/knowledge/training, additional hardware/ software, web hosting services etc.) This will ensure that you can budget for all eventualities, including ongoing updates.
- It was difficult to estimate the budget required for content development until we knew how many sites of interest would be included and what the content for a single site would consist of.
- We have a pre-existing brand that was used to guide this process. Anyone attempting a project of this kind without a pre-existing brand should allow sufficient time for considering this vital point as the look of the product is important.
- From the start we tried to look at the whole picture. It was important that all the required functionality within the app – ways of searching for sites, ways of linking sites etc. – was there at the start as we did not want to have to restructure the app at a later date.
- The app focusses on interpreting individual geosites rather than trying to make them fit a predetermined trail or area pattern. Sites can be filtered by theme, which allows users to make links between them. This was a major shift from our original intention, which was to employ a trail format. Traditional ways of thinking (tied in part to the aspirations of the Geopark Shetland Action Plan) were set aside as a better understanding of the capabilities and limitations of the app was reached.
- It was difficult to appreciate what could be done without experience of the media. It would have helped to purchase an Android and an iPhone prior to the start of the project. Looking at other aps and digital projects was helpful in generating ideas and seeing what works and what doesn’t.
Plotting site locations
- There was some confusion about the type of GPS data required to build the app. GPS readings were initially taken in the form of Ordnance Survey map references (e.g. HU 21394 77165). These had to be transformed into latitude and longitude coordinates (e.g. 60.477635 / -1.612654). It is possible to convert OS references into lat/long coordinates using http://www.nearby.org.uk/coord.cgi?p=HU+43741+32191&f=full.
- In several cases it was possible to obtain site coordinates directly from Google maps satellite view, as sites could be picked out ‘from the air’. This saved time visiting every site to take readings. It was also helpful to use the street view on Google to ‘drive around’ virtually as this helped locate features and parking places without having to go out and visit.
- At each site content is triggered by GPS signal, accurate to about 5 m. On a coastal route it was important to ensure that points were set far enough from the cliff tops to ensure that people do not have to get too close before the content is triggered.
- In some cases there were two geosites set within very close proximity – or two features set far apart within a single geosite. We had to decide whether to group several geosites into one POI (Point of Interest) on the app or split single geosites into more than one POI. This decision was taken on a site by site basis.
- Initially we worked on pulling together information to get an idea of what we had and identify gaps. Even though the app is site based we were trying to tell a bigger story. We cross referenced sites where possible and ensured that information relevant to more than one site is presented in the same way for each of those sites, to ensure consistency and to allow people to see patterns, make connections, and ultimately become familiar with the wider geological context in which each individual site should be placed.
- We took a layered approach to content, to ensure that the main information about each site is easily comprehensible to our target audience, while those with a better understanding of the subject can access more detail if they wish. It was helpful to talk to potential users to get their views on the kind of things they wanted to see. We tested content with several people to ensure that it was pitched appropriately.
- We took a consistent approach to the interpretation for each site in terms of the way in which information was presented. We avoided video content as being costly to develop and large in terms of file size. We opted for text over audio because users found it easier to grasp some of the geological concepts if they could read them. We used photos in .png format (max dimensions 480x800px) to compliment and illustrate the text information. We kept diagrams to a minimum but in some cases they were necessary. We explored the idea of having clickable hotspots on each diagram with pop-up labels but this proved overly complex so we incorporated text into the images.
- We used a combination of written directions and photographs to help people pinpoint sites and features. We had intended to use Google maps to get directions but this could not work for sites that were away from the road. We tried to bear in mind accessibility issues for individual sites and for the app as a whole and to make these clear to users.
- We tried to ensure that our geological content is consistent with other geological information about Shetland that we and others have produced.
- While the app is intended for use in the field, users may access content from home so it was necessary to ensure that the content would be meaningful when not in the site context.
- All the app content was collated in an Excel spreadsheet, the idea being that the developer would build an interface that could read the spreadsheet and populate the app. This proved not to be possible but a spreadsheet still provided a useful tool in terms of managing the content.
- We had some difficulty getting the Content Management System for the app up and running. The CMS allows us to make updates to the content that will then be passed on to anyone who has downloaded the app. The problem with the CMS is that it uses java, which requires a compatible web server to run it. The server our organization uses for its websites is not compatible so we have to rent space on a ‘virtual private server’ (‘cloud server’) on a pay-as-you-go basis. Examples are Rackspace and Amazon ec2.
are several aspects to consider when assessing the app:
- Content – is the information enjoyable, interesting and pitched at the right level? Is there anything else we should have included?
- Functionality – is the app easy to use? Do all the functions work? Are there any other functions we should have included?
- Design – is the look of the app appealing? Is the design intuitive to use? Are there ways it could be improved?
- General – any other issues and ideas.
- We adopted the ‘cleanest’ least fussy design possible so that everything would be displayed clearly. To overcome the appearance of ‘too much text’ the app displays an initial paragraph with a ‘read more’ option for each site.
- We discovered the optimum image size to ensure that images were sharp without being unduly large in filesize. This was done through a combination of the maximum screen dimensions at 85% quality.
- We incorporated a ‘pinch to zoom’ function for images, although their size does not allow them to be blown up satisfactorily. This was because we felt that people might expect the option to be there and try to use it. By making it available people can use it if they wish, although they will probably opt not to when they realize it does not add anything.
- We discovered the optimum size of text for labeling diagrams and created diagrams ‘actual size’ to ensure they displayed correctly. Diagrams are often larger than the screen and make use of scrolling.
- On Android we programmed the map to remain in its last state, even if the user navigates away and then return to it. This was not possible on iPhone, meaning that the map defaults to the zoomed out version each time which can be frustrating. When loading trails or themes the map was programmed to appear focused on the area of interest.
Technology pros and cons
- A digital product such as an app has the great advantage that you can alter, remove and add content as and when you wish even after it is launched.
- A digital project such as an app generates content, (e.g. images / text / audio / videos) that can easily be used in other digital forums such as websites / social media / static computer displays etc.
- Using an app outdoors in the field can have drawbacks - if it is cold and you are wearing gloves you can’t use the touchscreen function unless you have ‘e-tips’. If it is a sunny day you can’t always see the screen to read the content and sunscreen can cause problems when swiping! If it is a windy day it is difficult to hear audio content.
- Augmented Reality points do not always show up exactly where you want them through the camera view, depending on how high above sea level you are positioned when you view them. It would be helpful for us to have extra time to improve the location of some of our AR tags.
- If you are in an area where wifi / mobile phone reception is patchy then you will need to develop an app that can be downloaded in its entirety up front. That way the user will not have to rely on wifi / mobile connections to use it. However, this makes the filesize of the app relatively large which takes up space on the user’s phone memory and takes time to download. Our app is 42MB and takes a minute or two to download.
- There are variations in the functionality of different devices. Androids have a built in ‘back’ button but iPhones don’t, so in the iPhone version it was necessary to put a ‘back’ button on each page. iPhones allow you to pinch zoom images and move them around so you can hone in on different areas. Androids allow you to pinch to zoom images but you cannot move them to zoom in on different areas. Something that works well on one platform may work less well on another so if you are trying to cater for multiple devices you may have to compromise on specifics.
Handy Digital Tools
There are lots of handy online tools that can be downloaded for free. It can pay to do a Google search on a particular requirement to see what is available. We used:
- Google maps‘what’s here’ function to plot lat/long coordinates and ‘street view’ to work out written directions
- Nearby.org to convert OS grid references into lat/long coordinates
- Faststone resizer to alter multiple images (e.g. filetype, size)
- Gadwin printscreen to capture a computer screenshot
The information given above is illustrative of our experience and should not be seen as and endorsement of any particular company or product. We accept no liability for an problems experienced through use of free online software.