Programming: A new approach to the detail view

Previously, we the details for each clause stored in a different view controller. This meant that when one of the clause overlays was tapped, the view would change to the new controller, giving a different full screen page which would have the details about the clause on.

This is what it looked like:

After having a meeting with the client, to show them our progress thus far, he had a different idea for how we could display the information. Instead of sliding across from the side, he’d like it so slide up from the bottom, overlaying the Magna Carta image.

Doing this meant we had to take a completely different approach to the way we were doing it. We started by deleting the old view controller, it worked, but wasn’t the right thing for the job. To get the detail view as an overlay, we created a new UIView which would appear on top of the image view (Magna Carta image); this would be the container for the detail view. To start with, we made this view to be 500px tall, so it take up around the bottom third of the screen. This size is likely to be updated as we fill it with information to better suit the shape and size of the text filling it.

We decided to do this programmatically rather than using the interface builder as it would allow us to have better control over positioning elements and it made it easier to keep track of animations and functions. A lot of this was due to personal preference. As we have struggled with using the interface builder in the past, we opted for using the route we were more comfortable taking.

We created an instance of the detail view, giving it a position and a size where it would appear off the bottom of the screen. A boolean was used to keep track of weather or not the detail view was showing. When an overlay is tapped, the boolean switches from false to true, causing the detail view to animate into position on screen.

With this there were a few inherent problems which would need to be solved. The overlay would show and hide when tapped perfectly, when the image wasn’t zoomed in. Once you zoomed into the image, the position of the box was completely wrong and nonfunctional, as shown in the gfycat video below.

This was a problem due to how the view,  image view, the scroll view and the subviews were set up. Pretty much how everything so far was connected, was wrong. This meant changing a few lines of code to fix the way the different views were connected. The image view needed to be a subview of the scroll view so that it could be zoomed and scrolled. The clause overlays also needed to be in this scroll view so that they would move with the image and stay in the correct positions. We then had to put the detail view as a subview of the view, rather than the scroll view so that it would appear separately and not be moved or zoomed with the image and other overlays.

This solved the problem with detail view overlay allowing it to appear separately from the scroll view and be immovable.

UPDATE: In the first instance there was very basic functionality when interacting with the clause overlays and the detail view. For example the only way to close the detail view was to tap on one of the clause overlays again which would flip the boolean to false and make it hide. There was also a problem that if, for example, clause two was showing and the user then tapped clause 3, the information in the overlay would change to the new clause but it would still close the detail view (again, because of the boolean).

This is why we added a few new functional features to make the interaction a lot more intuitive for the user. By adding a nested if statement that meant if the detail view was already showing, and if another clause overlay was tapped, it would just switch to the right information for that clause rather than close the view. At the moment this switch is very sudden, and we think it might not be very clear to the user that the information has updated. In the future we plan to add animations to the text so that it updating it a lot more visible and aesthetically pleasing.

We also added a swipe gesture recogniser to the detail view. As mentioned before, using built in gestures makes the app more intuitive to use. We wanted to use this feature by having a swipe down gesture to hide the detail view; functionality that can be seen in many other apps.

We also added a tap gesture recogniser, to the image view. This meant that if the detail view was open and the image view was tapped it would again, dismiss the detail view. This again is another functionality feature which can be seen in other apps. When there is a view present on top of another, tapping the one behind often dismisses the top one so the behind one can be better seen.

Adding these little gestures has made the app instantly feel much more like an iOS application. It is the addition of small, seemingly insignificant features which make a large impact on user experience, making it far more pleasurable and enjoyable for all.

Below is yet another gfycat video of the app so far. The overlays are different to what you’ve seen before as there are a few incomplete changes which need to be finished and will be blogged about in the future. The video shows the new interactions, albeit very quickly and rather difficult to follow. It shows opening a clause’s details (And then accidentally closing it), then opening a clause, switching to a new clause then swiping down to close the details. Then finally opening a clause and tapping the image view to dismiss the detail view.

Content Gathering & Approval

As discussed in the previous post our application for the Magna Carta exhibition is going to translate the latin document into English, provide information regarding the clauses and give them some context for audience to expand their knowledge when in the exhibition. The application is information based and will be view by a range of audiences with a large verity of understanding of the document. As this application is connected to the cathedral it needs to be historical and factually accurate to inform all audiences appropriately.

The sources of information for the application need to use reliable and available for use within our application. This means they need to be produced by an academical recognised person or institution making the credible to use within a historical documentation. Copyright needs to be consider also being careful not to break any law when reproducing other people work or content.

The British Library have provided a translation of the document to use which is considered very reliable as its completed by an internationally recognized organization. The donTranslations – (Creative Commons Licence)

Dear Nicholas

Im Ashley Wilkie a student from Bournemouth University. 

We are currently working on an app project with Salisbury Cathedral creating a translation and contextual description for clauses within Magna Carta. The cathedral have recently installed a new exhibition for the 800th anniversary, which we are creating an application to go with. 

They have asked our group specifically to create an iPad application which will be displayed next to the new Magna Carta enclosure allowing visitors to see a translation of the the document and a context of the clauses to understand them further in an interactive way. 

We found your work on The Magna Carta Project the most comprehensive and useful in proving contextualisation for the clauses. We would like your permission to use the content within our application as we feel it best suit our needs. Could you confirm its possible to do so. We would obviously provide acknowledgements within the application of the contribution towards this.

Our contact at the cathedral is Seif Elrashidi, – 

The University contact is Stephanie Farmer –

They both would be happy to answer any of the questions you have.

Kind Regards, 

Ashley Wilkie


When we approached The Magna Carta Project we had hoped that they would be willing to work with us to help develop and enhance the experience for audiences when attending the exhibition via our application. Unfortunately for unforeseen circumstances, copyright issues and information protection it is not possible for them to provide the context/commentaries for our application. After much exploration into clause contexts, we felt there work best fitted with what we were trying to achieve in the application however, its now not possible to do so and an alternative source will have to be found.

The cathedral with the help of the client Seif have come forward to help us with this part as they feel that an element of specifically tailored information written by the cathedral itself could fit better. We feel this would also benefit the applications as it would keep it further tied to the exhibition and the location of the document. Going forward were discussing with the cathedral what would be wrote for each clause commentary and look forward to their input within our application.

Sourcing Information

For any digital project there is always a process of asset and information collection.

For the project we require specific information from the client in regards to historical information so that the app is accurate historically and contextually. This is the client’s area of expertise so they will be able to provide the content we need. As discussed in our application ideas and most recent MoSCoW, the application aims to let users to see the translation of Magna Carta into English and if possible to provide further contextualisation of the individual clause. This will be done using Magna Carta as a navigation interface, by tapping the location of the clause to see more detail. For this, we need:

  • High resolution image of Magna Carta (The client will provide this)
  • Access to some of the cathedral’s images for use in the application
  • Clause translations (This is a book the client has)
  • Location of each clauses on the document (we don’t know who would have this knowledge and something to be discussed with the client)
  1. Salisbury cathedral during the recent refurbishment of the document enclosure for the 800th anniversary, took a high resolution image which they can provided for us to use within the application.
  2. Its been suggested that images could be added later to provide further contextualisation and detail for the clauses in the app.
  3. Translating the information of Magna Carta from Latin to English and contextualization has been done for us by the British Library.
  4. Our client has a close connection with the cathedral and has been able to provide us with some images highlighting the start of each clause and some interesting factors of the visual appearance of the document. These have been the biggest hold up during the development as without this we couldn’t move forward with producing anymore prototypes for the client to see.

MC%2520with%2520clauses MC%2520with%2520clauses%2520and%2520annotations

With this information the client provided some additional note about that clause that we should consider in categorising them.

  • I think we should definitely highlight the 4 that are still part of the law at least.

  • (1,13,39 and 40) the preamble (in the king’s name etc) who the document applies to .

  • Some clauses are fun and perhaps the group could also highlight these (17, 23,28,30,31,33)

  • 35 – the standardisation of weights and measures is an interesting one

  • 7, about the inheritance of widows

These have been highlighted on the document below. Moving forward with this we need to start looking into categorisation and ways to frame the clauses. This can then be take forward into the design where we can find a creative way to display the different categories on the document with a stylish and sleek format thats easy for any audience to understand and interact with.