Archaeology Britain Mobile App Development

The icon for the Archaeology Britain app

About a year ago the ADS was approached by the British Library (BL) about joining up to develop an mobile app together.  A good relationship had evolved out of the ADS involvement with DataCite at the BL, so this seemed like a good opportunity to work together on something other than DOIs.  Another reason the BL approached the ADS was because we hold a large amount of open data which would have a widespread appeal.

A year and many lessons later, the app has been available to download for 6 weeks and has notched up a respectable 650+ downloads.  This blog post is an attempt to document and explain many of the decisions that were made during the development of the app.  Some things in this blog may make more sense if you’ve already seen the app, which can be downloaded from the App Store.  If you don’t have an iPad (or don’t want to download it), you can see screenshots on the ADS website to get an idea of what the app looks like.


ADS staff have bounced around the idea of developing a mobile app in the past, but until ADS was approached by the BL we didn’t have the time or resources to undertake the building of one.  If the BL hadn’t approached the ADS to collaborate (and lead on the development), it is unlikely the ADS would have undertaken the developing of an app at this time.  Given the widespread appeal of archaeology and the rich archaeological content held by the BL, an archaeologically themed app in collaboration with the ADS made sense. What kind of archaeological app to develop proved to be a more difficult question to answer than expected.  Aware that a low curatorial overhead was desirable, initial thoughts focused on existing ADS collections or projects such as a mobile version of Archsearch, The Defence of Britain (DoB) archive or England’s Rock Art (ERA) project. An Archsearch mobile app was dismissed due to the scale (1.2 million records) and the broad nature of the Archsearch data.  The more compact data sets of ERA or DoB were more appealing because they were focused on a distinct theme and had already been effectively curated by the depositors.  DoB is also one of our most popular resources, but like ERA, its audience is rather specialist.  While it may have been easier to create an ERA or DoB app, we wanted to develop an app with the widest appeal possible.  We also wanted an app whose code and structure could easily be reused by us and others, so instead we decided to develop an app that focused on the archaeology of a select group of key British heritage sites.  It was also obvious that general archaeology would be better suited to the BL and their collections, which has some of the rarest and most unique content in the world. After some initial indecisions, a general British archaeology app straightforwardly called “Archaeology Britain” was settled upon.


The technical development of the project was done by Ed Zukowski, a software engineer from the BL, while myself and other ADS colleagues provided domain expertise and direction on the user interface.  The iOS platform was settled upon in an effort to keep development simple, and it was decided that the iPad form was more appropriate for the type of content we were going to include in the app.  Both the ADS and the BL are aware that their choice of iOS exclusively for the Archaeology Britain app has excluded a number of potential users, and it was a decision not taken lightly since accessibility is a key tenant of both organisations.

Another important development decision was to ensure that all of the content and data resided on the device, so that no network connection was required to use the app.  This decision was slightly enforced by the fact that the iPad doesn’t necessarily have a cellular network to fall back on when no wireless network is available like the iPhone.  For practical reasons we also didn’t want to have to host the images or content on a web server which would have required management and maintenance.  This decision meant our app was very large (over 100 Mb) because all of the images had to be downloaded with the app from the App Store, but in our opinion this results in a  much better user experience.

The iOS development tools available made the process straightforward and a helpful  development community accelerated the process.  Balancing this project with other core responsibilities, it is estimated that the total development time on the project was around 4 weeks.  Open source software was used were possible, and overall a very refined and professional first app was produced by Ed.


The general layout and structure of the app was agreed to be based on ADS’s What, When and Where facets that can be seen in the ADS Archsearch browser.  Within those facets we decided to have a ‘site’ be the primary unit within the model, with a one-to-many relationship to the site’s associated Digital Objects (images).  In terms of user experience we wanted to keep things as simple as possible, and in particular ignore the complexities present in the categorisation of many of the archaeological sites we were including in the app.  For example, Stonehenge is often associated with the Neolithic and Bronze Age, but for the sake of simplicity we categorised it within the ‘Stone Age’ When facet.  Likewise, the period categorisation of Old Sarum is even more complicated, since human inhabitation at the archaeological site extends back to the Neolithic but continues through to the Medieval period.  Rather than try and perfectly represent these complexities, we decided to simplify the When facet, which will surely upset the pedants amongst us.

The BL also had a small amount of funds to employ a professional company to do the graphic design of the app.  The final product was well worth the investment, which created an app that looks both clean and professional.

A screen-shot from the app


Once we had the development and design decisions pinned down, it was time to start thinking about content since without good content, we had nothing more than a nice looking scaffolding.  Fortunately, the BL is sitting on some of the most interesting and unique content in the world.  From the very beginning we decided to let the BL content guide us in some of our design decisions.  For example, we picked significant archaeological sites across Britain and then checked if the BL already had content for that site digitised.  For some sites, such as Stonehenge, this was no problem as there was ample content already digitised by the BL within their Images Online service.  However for some sites the content held by the BL was limited (such as Hadrian’s Wall) which relied on us finding suitable content within ADS archives or elsewhere.  Some of those external content sources (outside the ADS and BL) were places like English Heritage, York Digital Library and The Urban Explorer, which gave us explicit permission to use their content in our free app.  We were able to also find usable open data under CC licences from other sources such as geograph.

To begin with we identified categories of archaeological sites we wanted to have in the app, which included Castles, Churches, Megaliths, Settlements, Defence of Britain, Industrial, Bridges, Burial Sites and Stately Homes.  The final app only had the first 5 categories, but we identified sites which could fit into the latter.  It was easy to identify good archaeological sites that fit into all of those categories, however finding good content associated with them proved more difficult.  The content we were focusing on was exclusively images since those are the easiest and most pleasing, however we could at some point include dynamic GIS/mapping data or 3D models.  With the images we were hoping to portray a unique or rarely seen perspective of the site, or present associated content that might not be a direct representation of the archaeological site.  We focused on old maps and antiquarian drawings/photographs from the BL collections, but occasionally tried to tell a story about the site from artefacts associated with it.  For example, a tombstone found outside a fort at Hadrian’s Wall offered the opportunity to present the diversity within Roman Britain.  There was also some interesting content related to more general aspects of an archaeological site, such as Anglo-Saxon drawings from an early 11th century calendar.  While these drawings were generically Anglo-Saxon, we associated them with the West Stow Village Site to try and portray the Anglo-Saxon lifestyle which would have been in practice at West Stow.

Curating all of this content proved to be the most time consuming aspect of the project, since the images needed to be sourced and then described and classified.  This required domain specific knowledge and was impossible to automate.  Fortunately some of the more general elements of the metadata generation could be allocated to non-specialists at the BL, but ultimately we needed an archaeologist to curate and oversee all metadata associated with Sites.  Fortunately we had the help of a University of York Masters student studying Medieval Archaeology, Alex Peterson, who did a placement with the ADS and did much of the heavy lifting in curating the medieval sites within the app.  His archaeological expertise was also useful in other categories not specifically related to the medieval period, and proved invaluable in the overall content curation of the app.  Quantifying the actual time it took to curate all of the content for the app is difficult, but it is safe to say that it took considerably longer than the technical development of the app.

Future Development

The next development task will be to create an iPhone version of the app, which should be a straightforward process of modifying the app for less screen real estate.  The bigger task will be to develop an Android port of the app, which we hope to do at some point in the future.  This will require a bit more time and effort than creating an iPhone version, so work on this in the immediate future is not foreseen.

Another relatively simple enhancement would be to add more sites to the app.  Since the time of release, the Royal Commission on the Ancient and Historical Monuments of Scotland (RCAHMS) has responded to a request for content related to Skara Brae, so this would be a simple (and significant) site to include.  There are a number of other sites that didn’t make the final cut for version 1.0 of the app, including those from the Greater London area.  London sites were left out to keep the app simple, but there are many potential sites in a number of categories that we can investigate.  We would also like to add Archsearch records to add contextual information to the sites.  Archsearch contains HER records, which often include interesting information about events and other monuments found at or near a site.  This information would help build a more complex narrative of the site, but requires more curation to filter out the less useful Archsearch records from the useful ones.

Another feature that was discussed but not implemented in version 1.0 was the ability to accept user-generated content, such as photographs and stories about the site.  This would create a “living” archive of user experiences and photographs.  The only potential issue with enabling this is maintaining a server for uploading content and then managing the data itself, including copyright (which could be a major potential headache).  Additionally features such as “checking in” to sites and selecting favourites was also discussed, which would fit alongside any system which supported user-generated content.

We will also be releasing the source code for the app for others to reuse.  The content will obviously be left out (since much of the BL content is under their copyright and control) as well as the graphical elements, but the framework and code will be available.  This will hopefully be useful to anyone else wanting to build on the great work already done by Ed, particularly if the app they are creating follows a similar What/When/Where model.  Some of the “under the hood” features of the app may also be useful to other people developing apps, such as the image caching for the site gallery or the full page image with zoom view.


Overall developing the app was a good experience for the ADS, and we learned a lot about the process.  Getting good content was the key, but curating that content properly was very important and therefore took time.  The technical development of the app, while not trivial, took considerably less time then the content curation process.  We also think that keeping the app and features simple was useful, since in retrospect the original version of the app we had discussed in the planning stages would still be well into development.  We also simplified the content where we could in an effort to get the app out the door, which meant we left out some sites and metadata, but we now have the opportunity to add that content in subsequent versions (when we have the time) while still getting and being able to react to feedback from users.  Trying to release a “complete” app for version 1.0 would have been fruitless and a potentially wasted investment.

The app has been seen as a first foray into one small sector of the world of mobile app development for the ADS.  Currently we are anticipating adding more content to the app (such as the Skara Brae site) and extending the metadata further.  We would also anticipate porting Archaeology Britain to the Android platform as well as developing more apps for the ADS and its users, but this all depends on funding and time.  While we are happy with the first version of Archaeology Britain, it is by no means a complete app.  We hope users get some value and enjoyment out of the app, and can hopefully look forward to future enhancements.

3 thoughts on “Archaeology Britain Mobile App Development

  1. Great work! One question tho: why you did not implement this as web-app? As your content does not require access to device sensors you could run it in any web-browser. That would have made it much more accessible on different type of devices, more future-proof. So maybe instead of Android version you try web-app instead.

    1. That’s a good point, however we didn’t want to rely on a network connection for the app to work. The current app doesn’t utilise GPS but we do anticipate future versions to include Archsearch/HER data and therefore provide “What Monuments/Events are near me?” kind of functionality. People using the app in the field would also require on-device content since we can’t expect 3G at most sites, so a pure web app wouldn’t be useful.

      We could have developed an HTML5 app inside of a iOS or Android wrapper, which would have been slightly more flexible and future-proof, but we got the feeling that native apps provide a better experience. We are very happy to be disproven though!

Comments are closed.