Icon Designs

Originally the icons used in the designs were taken and edited from the internet. To overcome copyright issues and to enhance creativity and originality, we decided to design our own icons to use within the menu bar. Using Adobe Illustrators shape builder tool and pen tool to do so. Here are the initial icons designed for the original categories:
initial icons
Adhering to Apples iOS conventions, we used a consistent stroke weight and colour to ensure consistency throughout the icons. We didn’t like the fact that four of these icons were building like, and agreed that some of the icons needed to be more inventive yet still readily understood by users. We also decided that the categories we originally planned to use were quite odd, making clauses quite complicated to distinctly categorise. Therefore, we decided to use the categories that features on this website: http://magnacarta.cmp.uea.ac.uk/read/magna_carta_1215/Introduction__Magna_Carta_1215 . Consisting of: Church, Feudal, Forest, Jews, Justice, King’s Officers, Misc., Money, Peace, Trade, Wales&Scotland and Women. This made the categorisation a lot more clearer and shows how we have adhered to some conventions. We also decided to include categories for: Key clauses, All clauses, Hide Clauses and Hidden details. These were suggested by our clients, hence showing how we have been a professional agency, by communicating with our clients throughout the processes, complying to their suggestions. The Hidden Details in particular is a category that the clients emphasised upon, this includes highlighting intriguing, unusual things on the Magna Carta such as the piece of wood and ripped seal, thus helping to make our app feature more original and interesting aspects regarding the Magna Carta.

Here are our icon designs for the new categories:unselected icons-01 (designs by Kaylee)

Apples iOS guidelines suggest ‘to create a coherent family of icons, consistency is key’. We have strongly adhered to this convention as all icons are the same recommended size, using a consistent stroke weight and colour. Apple suggest that icon designs should be:

  • Simple and streamlined. Too many details can make an icon appear sloppy or indecipherable.

  • Not easily mistaken for one of the system-provided icons. Users should be able to distinguish your custom icon from the standard icons at a glance.

  • Readily understood and widely acceptable. Strive to create a symbol that most users will interpret correctly and that no users will find offensive.

categoriesWe have complied to these conventions, through designing simple, original custom icons that can be readily understood by users. We have been inventive in the icons we have designed, by thinking out of the box for ways to visually represent some of the categories. For example, the ‘All Clauses’ icon is a feather quill, and the ‘Feudal’ icon is a knight chess piece. This shows how we have creatively thought of ways to visually and clearly represent the categories. Some of our icons could be regarded as being quite original and inventive whereas others could be seen as being quite conventional.

Apples guidelines also suggests that you should provide two versions—one for the unselected appearance and one for the selected appearance. The unselected is normally outlined (image above) and the selected is normally a filled in version. To further adhere to conventions, we designed some selected icons. If we have time, the programmers will try to incorporate this element into the app, so that when a category is selected the icon appearance changes to clearly show users what category they are viewing. However, due to the short time period it is not a fundamental, so is just an added bonus if we can include this feature.


Here are the selected icon designs:

selected icons (designs by Kaylee)

Overall, by designing our own icons to use within our menu bar, it helps to make our app more original and avoids multiple copyright issues. We have clearly adhered to Apples conventions when designing the icons to ensure consistency and to help make our app look more professional. As an agency, we have been professional by constantly communicating with the clients throughout the processes, and have included categories of which they suggested. We have been inventive with the icons, producing some original and creative designs to visually represent the categories.

Apple, 2015. Bar Button Icons [online]. Available from: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/BarIcons.html#//apple_ref/doc/uid/TP40006556-CH21-SW1 [Accessed 12 May 2015].

Arts and Humanities Research Council. The Magna Carta Project [online]. Available from: http://magnacarta.cmp.uea.ac.uk/read/magna_carta_1215/Introduction__Magna_Carta_1215 %5BAccessed 12 May 2015].

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: https://gfycat.com/LateFalseAracari

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.


Design Experiments

Based on the various improvements that we agreed upon from our initial designs, we have creatively experimented further with different designs to consider for our app. We experimented with a range of colours from Salisburys’ style guide in order to see which colour scheme worked best for our application. We also experimented with different ways to display the detailed/selected clause information, for example on a new screen that would totally cover the Magna Carta document (1), sliding up from bottom which half covered the document leaving the top exposed (2), and a temporary pop up box which would be centrally placed  stopping navigation briefly but showing the document was still there(3,4). Here are some of the design experiments:

1.designs 2. designs2 3. designs3 4. designs4
(designs by Kaylee)

We liked the addition of the navigation bar in these improved designs and felt this helped to make it more accessible for the menu. The use of the apple menu button (top left) also helped to make it adhere more to Apples iOS Guidelines and using these common button icons means most iOS users will already have existing knowledge as to what it means. The slide out menu of categories is another feature that the group liked, allowing users to easily filter their search on the Magna Carta clauses. If there was no filters, the whole document would have overlays due to the vast amount of clauses, so the use of categories helps to narrow down the overlays, making it a lot clearer for users. The use of icons to go alongside each of the categories helps to make it more visually appealing; it is important that the icons we use are readily understood, hence why we have used a key icon for key clauses and a money icon for debt etc. We decided that our favourite colour scheme was the dark brown with the gold overlays (3). We felt that these colours stood out most and fitted best with the design. The blue was slightly to powerful and took away from the documents importance. The simple design helps to make it clear and easy to navigate and read without difficulty or prior knowledge. We decided that having the clause information/detail slide up from the bottom of the screen worked best as it allowed users to still see some of the document unlike the others, also it was more native to apple devices. The clients, Seif and Steph also said they liked the idea of the details of the clause popping up from the bottom, and covering the lower half of the screen with a translucent background (similar to design 2). A main improvement to consider is proportions, as at the moment the font and icon sizes are too big. Apples Guidelines suggest – ‘Text should never be smaller than 11 points, even when the user chooses the extra-small text size. For comparison, the body style uses a font size of 17 points at the large size, which is the default text-size setting’ (Apple 2015). It is also important that ‘all icons in your app look like they belong to thScreen Shot 2015-04-27 at 12.41.21e same family in terms of perceived size, level of detail, and visual weight’ (Apple 2015). This is another feature that needs to be improved upon as at the moment some of the icons are filleScreen Shot 2015-04-27 at 12.40.04d in whereas others use an outline. Apples iOS Developer Guidelines suggest ‘you should provide two versions—one for the unselected appearance and one for the selected appearance. The selected appearance is often a filled-in version of the unselected appearance’.

From this, we will go on to further improve the designs, making amendments to the proportions, including menu, text and icon size. We will also make sure all icons are consistent and create unselected and selected icons in order to further adhere to Apples conventions. Also, in the above designs the colours are only rough so we need to get the hex codes of the colours to ensure they exactly match the style requirements. Additionally, we will go on to further research the Magna Carta clauses in order to clearly define the categories that will be displayed in the menu bar.

Apple, 2015. Designing For iOS [online]. Available from: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/[Accessed 21 April 2015].

Initial iPad Designs

Here are some of the initial iPad designs for our app. It is important to consider the designs in both orientations, as users may expect to be able to interact with the app in both portrait and landscape orientations dependant on their preference and how well it suits the screen space.

Portrait Designs: portrait designsLanscape Designs lanscape designs Both designs are fairly simple, with a clear organised layout, this is important as users need to be easily able to navigate and use the app without encountering problems. Apples iOS developer guidelines state ‘Avoid gratuitous changes in layout’ (Apple 2015), hence the layout for both the orientations should remain consistent. We have adhered to this convention by using a similar layout for both orientations, with the use of a clear menu bar. The menu bar in the portrait design, would appear when users swipe left on the screen, or press the menu icon in the top right. The menu in the landscape orientation would automatically appear due to the larger width, but users can be given the choice to hide the menu bar when interacting with the Magna Carta. After making these designs there was a realisation that the menu bar is on the right side (portrait) and then moves to the left when it is in landscape. This is the kind of inconsistency that needs to be avoided in order to make our app more professional.

-simple, clear layout making the most of the limited available screen space
-full screen Magna Carta which the user can zoom into and explore
-use of menu bar and categories to let the user easily filter which clauses are highlighted

-needs to look more like iOS app by incorporating more of their design elements.
-doesn’t use Apple’s button icons
-wrong font used (But this is primarily due to not having the files at this point)

After discussion we have decided that the designs need to adhere more to Apples iOS Guidelines. Specifically, the menu bar needs to look more like an iOS app component, and the addition of a navigation bar at the top is a conventional iOS element that we need to consider. We also need to incorporate Apple’s button icons into the designs, as these will be familiar with users, helping to maintain user experiences of iOS applications. Experimenting with different ways to display the clause information is also something else to consider further.  For example, whether when touched it will slide left across to a screen containing the translation and further information, or if it will slide up from the bottom, or if a translucent box will appear over the top. We will also try out different colours from Salisbury Cathedral’s style guide in order to see which works best, by experimenting with changing the menu bar colour, clause information colour and the colour of which the clauses are highlighted. In the revised designs, we will also use Salisbury’s selected fonts (Eidetic and Quay Sans), in order for it to remain consistent with their existing products for the exhibition. From this, we will go on to improve our designs based on all these refinements.

Apple, 2015. Designing For iOS [online]. Available from: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/[Accessed 15 April 2015].

Design Guidelines

As we are producing our app for iOS devices (iPad, and possibly iPhone), it is important that we look at Apple’s iOS development guidelines. This ensures that the app we produce would be suitable for the iOS market and that it adheres to conventional iOS themes. ‘Although crisp, beautiful UI and fluid motion are highlights of the iOS experience, the user’s content is at its heart’ (Apple 2015). We plan to create a simple and well designed information based app that will allow the user to quickly and easily access relevant content related to Magna Carta. After reading through the iOS developer guidelines, we picked out some of the most important iOS themes to consider in our app designs:

  • Screen Shot 2015-04-08 at 16.45.00Translucent UI elements – we could consider this so that when users taps on a clause, a translucent overlay appears with more information regarding the selected clause.
  • Use of negative space – it is important that we use plenty of negative space within our app in order to make it clear and easy for users to understand. We have to consider not putting too much information over the Magna Carta image as it could easily be overwhelming for the user.Screen Shot 2015-04-08 at 16.46.32
  • Simple colours – using the Cathedral’s style guide, we will use their chosen colour scheme in order for our app to be consistent with existing products.
  • Ensuring legibility – we will use the font suggested by Salisbury Cathedral (Eidetic), at a suitable, easy to read size.

It is important to also be aware of the basic UI elements in order to help us make further decisions about the design of our app.Screen Shot 2015-04-08 at 16.14.41

  • Bars (navigations/tab) – contain contextual information that tell users where they are and controls that help users navigate or initiate actions.
  • Content Views (collection/table views) – contain app-specific content and can enable behaviours such as scrolling, insertion, deletion, and rearrangement of items.
  • Controls (buttons/sliders) – perform actions or display information.
  • Temporary Views (alerts/actions) – appear briefly to give users important information or additional choices and functionality.

Using conventional iOS gestures is also essential and something we need to consider when creating the design of our app. ‘Using gestures gives people a close personal connection to their devices and enhances their sense of direct manipulation of onscreen objects (Apple 2015). Some of the common iOS gestures that we could incorporate into our app include: tap, drag, flick, swipe, pinch, and double tap.

It is also important to use Apple’s built in features (UI elements and gestures) due to the time constraints we have to make the app in. Given our current skill level, it is essential for us to stick with what we’re familiar with and are being taught so that we can produce a fully functioning, and hopefully aesthetically pleasing app before the deadline. Creating our own UI elements can be far too time consuming and difficult for us, and will only be done if it is essential for the app to function.

Here is Salisbury Cathedrals Guidelines that we were given. We will adhere to these within our app through using their chosen colour scheme, fonts and existing graphics. This is important in order for our app to be consistent with their existing products for the Magna Carta exhibition.

From this, we will go on to create some initial designs for our app taking on board the above Apple and Salisbury Cathedral guidelines.


Apple, 2015. Designing For iOS [online]. Available from: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/ [Accessed 6 April 2015].

Second Prototype: Development

The second prototype builds upon our first one, taking a couple of small steps to get us in the right direction for the final application. At this point we’re still focused on working out the basic functionality of how the app will work and users will interact with it while the design for the application is still being finalised.

The main difference here is the addition of a navigation controller into the app. The navigation controller allows us the switch between different views. In this case, we have the initial view of the zoomable Magna Carta image, and it needs to switch to a different view which will contain the details about each clause when tapped on.

We also added a couple more hot spots onto the image to test and implement the class made to control the coloured overlays.

Below is a screenshot of the Overlay class. It takes three pieces of data at this point (but more can be added if needed). For it to be initialised, we need a name, a colour (which later will be used to separate categories) and a frame (which is the size and location of the overlay rectangle).

Screen Shot 2015-04-19 at 13.09.20
The class for the overlays

In the View Controller, the overlays are stored in an array as it seems to be the easiest and tidiest way to store all the initialisation data. The benefit of this method is that it is very tidy, easy to read and will be easier to implement later when we place the overlays on the image.

The array used to store the overlay data.
The array used to store the overlay data.

The overlays are then placed on top of the image using a for loop which uses iterates through and places all of the overlays in the ‘overlays’ array. They are placed down by added a subview on top of the Magna Carta image in the Scroll View Controller and then a Tap Gesture Recogniser is added to each overlay so that it can act as a button.

When one of the overlays is tapped, it transitions to a new view, which is the view where the details of each clause will be. At the moment the prototype transitions to the same page for every overlay as we, again, wanted to show the client our progress so they could get a better understanding of the type of functionality we’re aiming for. Much like the overlay class, A ‘clause detail’ class will need to be made to store all the information for each of the different clauses and create unique links on each clause.

Below is a Gfycat image of the prototype in action. Showing the zoom and scroll functionality and the transition to the detail page for the clauses.


In the future we want to add more functionality to this, which we will be working on as we can. One of the main things we’re interested in is adding some sort of filter for the clause overlays to separate them by categories/ themes (where the colour coding will come in handy). One of our main concerns at this point is that if we have too many overlays it could overpower the Magna Carta image and ruin its aesthetic. One possibility here could be limiting the clauses we have highlighted to only the most important or interesting ones so that the app isn’t flooded with too much information which will make it less user friendly.

First Prototype

Producing a prototype for the client to see is an essential part of client to agency development. We have been working in recent weeks in developing our ideas with the clients to create a section of the application to fit their needs and requirements.


From our creative ideas, the discussions with the client and the requirements  of a heritage applications we have established understanding of an application which would fulfill a specific need for the client/Cathedral. The idea was disscussed in the pervious post feedback.

From our MoSCoW (the application requirements) we have produced a prototype of the hot spots on the image working.

The idea for this prototype was to get a basic understand of how the app with function and look, both for our sake and for that of the client. For this prototype we used an image found online as a starting point as currently we don’t have the official high-resolution image we’d need to use in the final app.

The image was put into Photoshop so we could find the exact pixel coordinates so that we can draw the hot spot boxes over the clauses in Swift. At this point we don’t actually know where each clause starts and ends, so we made random selections as examples to show how it looks.

For this prototype we only had one hot spot as it would be a waste of our time at this point to bother making more as we don’t have the correct image, and we don’t know the actual locations of the clauses.


Below is the code that was commented to help the project move along, so the teams members that we programming the application would be able to understand what parts of the code do what. The main focus for the first prototype was to work out the gestures and basic functionality of the app.

Screen Shot 2015-04-20 at 11.27.31
Code for User Interface

From the code above, it defines what image is going to be used for the user interface. This code is important and its the basic structure of how the application will be used as the client wants the High res image of the Magna Carta as the core navigational structure.

Screen Shot 2015-04-20 at 11.27.43
Code for Double Tap Recognition

As part of the gestures that will be used in the application this is the double tap gesture. The benefit of using this gesture is that everyone that owns or uses an iPad are familiar with this gesture therefore to conform to the style of apple products it makes sense to have this gesture included within the app.

Code for maximum zoom
Code for maximum zoom

As we are used gestures to be able to zoom into the image, it is important to define how far we want the image to be zoomed into otherwise the user will be able to zoom into the tinniest pixel which isn’t useful therefore we have defined it by 5x zoom.

Screen Shot 2015-04-20 at 11.28.43
Code for alert

The whole concept for the app is to be able to click on parts of the Magna Carta on the clauses therefore it was crucial for our first prototype to have an element of this. This part of the code is the start this. The function that is called is when the overlay is tapped something is meant to happen, in other versions it will pull the information of the clause that is selected but as an initial prototype this code activates an alert.

Screen Shot 2015-04-20 at 11.29.10
Code for Gestures

It was important that within the tap gestures that we defined how much the double tap will scale in (zoom). At the moment we have defined the number at 1.5 so each time you double tap it zooms in by an appropriate amount. As you can see by defining the ‘newZoomScale’ of and setting a maximum it has achieved this.

View the whole commented code here.