Programming: Styling the Side Menu and Navigation bar

With the navigation and Side Menu the styling for this was a little bit more tricky than the styling that we had done for the rest of the App. As majority of the app was made programatically it was easy to see where we needed to add/change the styling eg colour, font size, font style etc but there were elements in the side bar that were created in storyboard.

The navigation bar was done programatically. Using the same colour scale that we used for the detail view all we needed to do was specify the exact RGB values. The line of code “barTintColor = UIColor(r: 76, g: 61, b: 61, a: 1) ” Is the code that changes the background colour for the navigation bar. From this we were able to speciy the colour for the burger  ( menu button), The line for that is “tintColor = UIColor.whiteColor()”. As there is an image within the navigation bar, you need a UIImage and from there you can frame how big you want it too be and what image to use. See below on the code that implemented the logo and the colour of the bar.

Screen Shot 2015-05-19 at 00.03.10From this it achieved the logo we wanted and the colours scheme to match our designs.

Screen Shot 2015-05-19 at 00.12.19The title for ‘filter categories” was styled in the same manner as before. The line of code “barTintColor = UIColor(r: 239, g: 233, b: 211, a: 1)” Is the code that changes the background colour behind the text. From this we were able to specify the colour for the text that was being displayed. The line for that is “.titleTextAttributes = [NSForegroundColorAttributeName: UIColor(r: 76, g: 61, b: 61, a: 1)]” See below full code. Note this is very similar to the styling of the navigation bar as it is but for the SideMenuController rather than ViewController.

Screen Shot 2015-05-19 at 00.21.18However to change the styling of the categories was needed to be done in the storyboard. This was only tricky because we had’t been using storyboard which meant I was a little bit ropy on how to change elements. Once I had realised where to go and how to change this elements it was plain sailing from there.

StoryBoard make it very easy to change the colours of each of the cells. You just need to click on the particular cell that you want to add some styling too then on the right hand side there are attributes such as background colour, tint, alpha levels which can all be adjusted to change the colour of each element you want to change.Note: you must make sure that you select the correct element you want to change colour.

Screen Shot 2015-05-19 at 00.25.55As you can see from above all the different cells have been coloured in. By selecting these cells you can also change any labels (text) that you have. This is done in the same way.

Screen Shot 2015-05-19 at 00.34.50It was important to make sure that the styling for the app matched the designs that were created and that we made sure that the colours and style conformed to the original style guidelines that were given to us by salisbury Cathedral and Red Balloon. We believe that the overall look for the navigation bar and side bar with the design icons that were made, meet the criteria of these guidelines.

Screen Shot 2015-05-19 at 00.38.40

Programming: App Icon and Splash screen

At the beginning we mentioned that our app is now going to be a separate app that is designed for iPad and going to be an installation that sits next to the Magna Carta document. We felt it necessary to provide Salisbury Cathedral with a complete packaged mobile application. That includes the actually app itself packaged with all the features the client wanted but also a Splash screen so when the app is opened (and for our case a long time) it shows an image of what the app is that’s being opened and an Icon to display on the launch pad on the iPad device.

Using the design guidelines set by Salisbury Cathedral we created these elements that conformed to the styling. Making sure that all the colours that were used were colours that we defined by the guidelines, all the fonts that were used were the same as the other work that will be displayed in the exhibition and making sure all image assets are copyright free or the cathedral hold the copy right for them.

Below the design that was created for the app icon. Using a online icon generator  I was able to make the image Icon on a square 1024x 1024 then it created the images into all the sizes that we need for the app icon to work.


See below the exported images that all the different sizes that are needed within the app.

Screen Shot 2015-05-18 at 14.56.28Of which can be then put into the imageAssest’s appIcon file which when xCode builds the app it will take the images and compile them into the app. See below all the images in the asset file for an iPad device, we could also put in the sizes for iPhones however as we are explicitly making it for an iPad we haven’t included these.

Screen Shot 2015-05-18 at 16.04.03The method for the splash screen was very similar, however there wasn’t a website that created all the different sizes which would mean I would have to export all the different sizes myself. Luckily enough there is a LaunchScreen.xib that allows you to create the splash screen on a storyboard* which I added a UIImageView to place the same image as the app icon. See below splash screen.

splash However as the splash screen is scaleable depending on what iPad model it is. Therefore we have separated the background image to the text. This way the background can be scaleable but the text will remain the same size and centred by using constraints within the launchscreen.xib.

* This is a self-declared storyboard which is for a launch screen it has the same layout however it doesn’t hold the same properties as a storyboard.

Programming: Hidden Details Cateogory

The Magna Carta has special facts and details that are hidden within the app. Either historical context of the Magna Carta or additions and accidents that have happens to the document that we thought were important to the app and will give the audience a new insight to the document itself.

Below is an image of where the little details are featured within the app. While it is cool that each of the details have been highlighted, this is just an initial reference to where all the details are, as it isn’t easy to see what is being pointed out.

Screen Shot 2015-05-14 at 12.02.00

Using photoshop (other design program are out there) we drew boxes around each of the details making sure there was enough room around each of the detail wasn’t covered up by the boxes by using the same border thickness size we would use within the app. See below.Screen Shot 2015-05-18 at 13.36.15From this document we were able to get the co-ordinates of each of the boxes that we needed to use and place them within Xcode. This was achieved by pressing Command ⌘-T which allowed you to transform the object however it also tells you the X and Y axis positioning and the height and width the box is, then this information was placed in the correct hidden detail, the same way as the over co-ordinates for the clauses.

It was great that we had all the boxes mapped out, however these particular overlays would need to be transparent inside the boxes and translucent for the edges so that each detail is highlighted in a big enough area but you can still see what is actually inside the boxes. Like the photoshop document, however the overlays we had created only used a background colour.

To achieve this within the overlay.swift we needed to create an function that gave all the overlays a border however we only want the hidden details to have the border therefore we created a if statement that will set the default of the function to false and only when the function gets called within the clauses.swift the border will appear.  See below, the function.Screen Shot 2015-05-18 at 13.47.17

Therefore within the information about each of the clauses and the overlays, it was possible to specify whether the isHidden function is needed within the clause. See Below.Screen Shot 2015-05-18 at 13.53.55

In addition to this we set the hidden details to have a different background colour ( colour3) which would allow us to make the background colour transparent. By using “let colour3 = UIColor.clearColor() “. From this it has allowed us to show the hidden details within the document however it doesn’t stop the user from being able to see the detail itself which if we used the same overlays for the clauses it would. See below the result. Screen Shot 2015-05-18 at 13.59.39As part of the mystery of the hidden details and part of the charm of the document, we have kept the hidden details are a category on its own as we think they are important to the document but also didn’t want to distract the users from the content itself. Therefore they aren’t within the ‘All category’. They would overlap many of the clauses which would look messy.

Programming: Swift Vs. Objective-C

SWIFT: The NEW language to create applications on iOS and OS X.

Previously developers used Objective-C to program the apps that we love and use. However, in 2014 Apple created their own language for developers to use to create applications for iOS and OS X. The code works side-by side with objective-C which allows the code to run fast. It is concise and is fun to code.

Whats the Difference between swift and Objective-C ?

Except for the syntax and a lot of new paradigms. Swift is very easy to get to grips with and there were a few things that made the code easier to write than Obective-C. Unlike Obective-C, Swift doesn’t need the use of brackets when defining parameters or semi colons to end the line of code. In addition the code isn’t pedantic and doesn’t return errors when spaces are missed out or the sentences are structured in a different order. This allows the programmer to focus on the app rather than the code.On the performance level, Swift is more impressive than Objective C. This is because Objective C does not allow a compiler to do a lot of optimisation due to its dynamic nature. With Swift, there is much more room for optimisation at compile time. Apple states that Swift is 2.6 times faster than Objective C code. Overall, it results in much better performance. There is still a lot of debate on the web, but it’s mostly about tools and less about language – buggy issues and surprises due to the young age of Swift.

How is Objective C better than Swift?

First of all, Swift has all of the capabilities of communicating with Objective C code, as you can incorporate parts of objective-C within a swift project. However, libraries are not the most pleasant to work with. There are some challenges to constructing the Swift code, e.g. many nested blocks to unwrap the optional values. Overall, it ends up becoming a huge tree – some call it a pyramid of doom. There are ways to overcome this, but it is still not perfect. Talking about advantages of Objective C would likely lead to discussing Swift pain points, because there is not much Objective C has that is better than Swift.

We use swift because it is the future of coding. It has only been around for a year however it has already made massive advancements on Objective-C and once the buggy issues get sorted it will be far superior.

Programming: Styling the detail view

As we already have a basic skeleton of the app (prototype) and the designs of how the app will look like once completed, we got to work with putting some of the styling into the app that the designers had produced and intended.

As we hadn’t incorporated the menu bar into the application yet, we started with styling the detail view which can be found in the detailView.swift. The detail view is where all the information about the different clauses are going to be displayed; the english translation and contextualisation.  In the detail view there are two elements to the view. The title which is detailTitle and the text as detailText. Originally we had both of these elements as UILabel but with a label it required constraints for the text. However as we had decided to make the app programatically, it was easier to make the detailText a UITextView. The reason this made it easier as UITextView has already got constraints within the view to stop the text going further than the boundaries.

The UITextView is primarily designed for areas of text that can be edited or added too therefore to allow the text to fill the area and not go over the restricted boundaries but to not be edited by users there were some statements that we had to add in. As you can see from the screenshot below, I have disabled the user interaction, this stops the text being editable and by setting the background colour to nil this makes the text field use the defined background colour for the whole detail view.

Screen Shot 2015-05-03 at 20.33.29

The main styling for the detail view, seen below, was designed on having the background as the dark brown of the colour guideline, with the main body of the text in a yellow/gold colour and the title in a different font family in a off-white colour

Detail View Design

To achieve we had to change the UIColor from a default colour guide that is set within Xcode for certain colour eg. white is UIColor.whiteColor() and red is UIColor.RedColor(). However as these colours aren’t default colours, you have to define the RGB’ colour values. This had to be done through an extension. This is due to each RGB value needs to be represented as a decimal value, which is 255 divided by the original number for Xcode to produce the exact colour code. Therefore if the first value in the RGB scale is 57 (for the RED) then the decimal will be 0.224 however instead of having to work that out every time you can implement the extension so that it will allow you to enter all the values as a whole number. See below of the extension and below that is the colour for the text of the body represented as an RGB using the extension.

Screen Shot 2015-05-03 at 21.36.08

Colour Extension

Screen Shot 2015-05-03 at 21.47.38
RGB Colour Values

The different font families and font size were all done in a similar way however these didn’t need an extension as it is already an element the Xcode recognises. This is changed by giving the detailText and detailTitle a UIFont. The main body also needed to be justified which is done the same by giving the detailText a NSTextAlignment. Which can also be seen below.

Screen Shot 2015-05-03 at 21.59.43
UIFont and NSTextAlignment

As you can see below, from the iOS Simulator,  by adding the styling to the detail view it looks very similar to the designs that were made.

Screen Shot 2015-05-03 at 22.18.25
Detail View in the Simulator

Next step is to get the logo of the Magna Carta embedded within the detail view for each of the clauses and to style the navigation bar so it looks the same as the designs that have been made for the application. Our initial thoughts are to possibly load an image slightly over the text or implement each clause title as an image. Then once the menu has been programmed within the app, styling will be applied to the side menu. This will take us further into icon and element styling looking at how users interact with them.

Programming: Sidebar Menu Prototype

For the app, we wanted to create a sidebar menu so the user will be able to select certain clauses within the app and hide other clauses. These categories included; the main clauses, church related, money orientated, justice, peace, women and royalty. As we are using a very high quality image of the Magna Carta for the basis of the Magna Carta, we were very keen on creating a function that will allow the user to hide the overlays, that display the translation and contextualisation for each clause.The reason behind this is that there are tiny details within the app that aren’t visible until you zoom into the document; for example a piece of wood stuck into the parchment. We feel that these details are valuable to the heritage of  the document and an interesting factor that people may not consider. Also as all the clauses will be highlighted using overlays it could be very distracting and may take away the impact and power of the document, therefore this function will limit this.

Some of the examples of different side bars that we have looked include;

Spotify Side Bar Menu
Peterest Side Menu
BBC Weather Side Bar








From these examples we found that the applications use libraries that have been already coded and import them into the app, very similarly to the map kit Apple supply to create apps with maps. We looked at an open source library called SWRevealViewController to build the sidebar menu. Though the library was written in Objective-C,  however it is possible to integrate it into any Swift project. This is done by accessing and interacting with Objective-C classes using Swift.

As we hadn’t created side bar menu’s before we decided to create a separate project working out how the side bar would programmatically work then after we had a prototype for the side bar, we would amalgamate the two together.

Below is a screenshot of the Storyboard for the prototype. It uses the side bar menu as a new screen which which is then navigated through the navigation controller to the views of the various screens. The custom SWRevealViewControllerSeguePushController (which is the side bar menu view) segue automatically handles the switching of the controllers. This can be seen from the lines connecting the view controller to the navigation controller to the clause views.


Below we can see, the SWRevealViewController provides a method called revealViewController() to get the parent SWRevealViewController from any child controller. It also provides the revealToggle: method to handle the expansion and contraction of the sidebar menu. We set the target of the menu button to the reveal view controller and action to the revealToggle: method. So when the menu button is tapped, it will call the revealToggle: method to display the sidebar menu.

Implementation of side bar
Implementation of side bar

The premise behind this side bar menu is that it uses segues to navigate from one screen to another which works well for the majority of Apps however our Magna Carta app will be using UIview’s within the same screen therefore the Side menu Bar that we have created here won’t be able to simply pull together with our original prototype. Therefore hopefully with the help of Marc or Kyle we will be able to use the menu that we have created, adapt it a little and be able to have a menu that works within our Magna Carta app.

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.

Project Management Approaches

This term way introduced in 2001 by 17 software developers to create an efficient way of working and producing within a team. An Agile workflow stimulates forward planning, development within the product, quick prototypes, continuous improvement, and encourages the response to change the product rapidly and effectively. The group created a set of principles that have been defined as the “Agile Manifesto”.

These principles underpin the practise that constitutes an ‘Agile workflow’
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity (the art of maximising the amount of work not done) is essential.
11. The best architectures, requirements, and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
(Beck et al. 2015)

The most common and traditional workflow (methodology) that has been widely adopted is known as the ‘waterfall model’. However the limitations on the model is very high. If problems are discovered within the product it is difficult to make changes as the project progresses as the model doesn’t allow an iterative process. Whereas the ‘Agile Workflow’ adopts an adaptive approach, which allows the designers/developers to change, the process if the needs of the project changes.
Below is a diagram of how an ‘Agile methodology’ would be carried out within a workplace.


There are various other approaches that could be adapted when creating an adaptive workflow such as a ‘Scrum Methodology’ which would include ‘Daily stand ups’ and ‘Sprints’ leading to an ‘Agile approach’.

Scrum Methodology

The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasises collaboration, functioning software, team self-management, and the flexibility to adapt to emerging business realities.
( 2015)

Daily Stand Ups
In Scrum, on each day of a sprint, the team holds a daily scrum meeting called the “daily scrum.” Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day’s work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.
(Cohn 2015)

In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review (Rouse 2015). A sprint uses a sprint board where all aspects of the sprint or product will be outlayed for work to be completed on. An employee will take a task to complete, assign it to themselves. When finished they move it down into the next section for someone in that team to complete. .

Moving forward, our group has decided that we will try and use the ‘Agile Workflow’ as best as we can, as there are obstacles in the way of sticking to a truly ‘Agile’ methodology. This is due to the client that we are making the app for isn’t in direct contact with us as we (the university) is working for a company which is designing the overall app for the client. With that in mind the workflow won’t be as ‘agile’ as we would like it to be however by adopting this approach it will mean that hopefully the client we receive an app that they feel is fit for purpose rather than producing an app that isn’t useable or isn’t what the clients wanted in the first place which can happen when using a ‘waterfall’ approach.


Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., C. Martin, R., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D., 2015. Principles behind the Agile Manifesto. [online] Available from: [Accessed 6 Feb. 2015].

Cohn, M., 2015. Agile Topics | Mountain Goat Software. [online] Available from: [Accessed 6 Feb. 2015].

Rouse, M., 2015. What is sprint (software development)? – Definition from [online] Available from: [Accessed 6 Feb. 2015]., 2015. Scrum Methodology & Agile Scrum Methodologies. [online] Available from: [Accessed 6 Feb. 2015].

Our Agency

Today our agencies were formed and we are really excited with the group we have formed. Our  ideas that we presented to one another, are either very similar or carry the same weight and style within the idea itself. From this, we believe we will be a real success at creating an app that Salisbury Cathedral really wants and needs, by pulling our brains together and forming an uniformed idea.

The members of the group are listed below, with links to our personal blogs. At the moment we haven’t, assigned each other to a specific role within the agencies however have come to the agreement that Ashley Wilkie is going to be the project manager. We feel that Ashley will really bring the best out of all of our skills within this unit and using his understanding of design and code to be able to use each of our individual strengths to benefit our group.

digital-agencies copy

Our first meeting is on Monday 23rd February, to discuss our idea in greater detail. At the moment we each have our idea that we can use however after visiting Salisbury Cathedral and speaking with the overall project manager of the exhibition it turns out that the ideas that we have formed might no be able to work as limitations within that the Church has implemented on the project. These limitations are, little or no sound and limited amount of text.