Evaluation & Learning Outcomes

This will be the final Blog post as part of The Magna Carta Translation Application. Today we have finished and handed over the project to the client alongside this we are concluding the assignment in terms of submission of all appropriate material.

We started this project back in March where we was introduced to the design brief and project requirements. Since then we have developed as a group/agencies learning skills that will be vital to progressing into the same client based projects outside the university. Starting with no prior knowledge of applications, how they were developed or the work that needs to go into producing a successful application, delivering the application shows how far we have come.

Completing the application has allowed us to gain swift coding, design, client communication, team working and documentation skill in connection with a client lead project. Throughout the project we have tried to remain transparent by communicating information, issues and requirements to the client as to keep the project as progressive and slic as possible.

Our Application

The Final Application we feel has been a huge success. We have achieved many things we didn’t expect to from our outset, initially we were sceptical about producing and information based application however this made us focus much more on delivering a professional application for the client.

With clear communication and presentation the the client we proposed and application that they felt fitted a very functional and specific requirement. Initially there was ambitious ideas thrown around by the client that we framed proposing and application that fitted both parties expectations and needs. One main achievement was overcoming a client proposed idea of The Magna Carta image as a form of navigation between clauses with the document. We initially felt this was slightly ambitious as our knowledge of Swift and application programing was very basic but with some support from tutors we managed to formulate an understanding of Swift which then allowed us to create this application.

Some other successes with programming was gaining and understanding of iPad specific application building and Split View Controllers, that allows 2 different types of view controllers to run within a single view. This is something even the tutors were mystified by initially but we managed to negotiate it well creating a useful feature of the application.

Working With Live Brief

Creativity and Professionalism is part of any client based interaction work no matter the product in production or timescape of project. Creativity is need  throughout all aspects of the project weather is designs, innovative ideas or pitches/discussion with clients. Creativity not only is the ability to produce ideas Remaining professionally throughout the project even when tricky and potentially problematic situation arose. Client negotiation is one situation where we had to remain professional, taking on board their ideas and feedback working with them to develop a product that they wanted and we could build successfully. Secondly when issues surrounding content and from the cathedral and 3rd party sources it was essential to remain professional and taking control of potentially problematic situations.

The Team

As part of a team we have work effectively and efficiently through good communication and organization of the work and timings. Using a social media site we were able to communicate effectively to each other gaining quick responses from all members of the team. Because of it ubiquity meant all members were quickly notified of discussions and organisations of meeting meaning workflow wants hindered or disturbed but miscommunication or un attendance as a point of contact was readily available.

Facebook Group
Facebook Group

Trello was used in organizing the workflow and delegation of tasks similar to that of a scrum board. all members had access to a live scrum board where they could interact with tasks that needed to be completed within the project. This highlighted if there was any issues or backlog with work as it was regularly checked and assessed by all members of the team.


Google Drive was used to shear and distribute files between members of the group, Being able to upload revisions of files ment there was less confusion and the the project documents were kept in the same place.

Google Drive
Google Drive

A Git repository was used in the development of the application also to track the development of the application, allowing merging between programmers files and back logging where needed. The git repo additionally gives any developer who needs to pick up the application after handover the ability to see how it was made and where specific changes took place. This is a great form of documentation for the client as it gives them a breakdown of how the application was made and the process that went through its development.

Keeping to Guidelines 

During the project there was a series to guidelines of which we had to follow and be aware off.  Firstly the design guidelines given to us by Salisbury Cathedral and RedBallon that we had to keep to pedantically making sure we always referred to there style guidelines. These outset design guidelines were colour, font and style based and it was necessary to keep to their exhibition they have recently built tieing the application and exhibition together.

Secondly keeping to apple guidelines with programing and styles of elements within the application. Specifically we looked at the design guidelines paying particular attention to sizing, icons and gestures that meant the application fitted smoothly within an apple device using its ubiquitous apple.


Through this live brief we have produced professional application fitting clients requirement learning lots of vital skills along the way. Handing the application over to the client now it will be great to see it working within the desired location helping and informing tourist visiting the Salisbury Cathedral for filling its purpose.

App Testing on Devices

Testing the application upon the desired device is essential to any product development not only apps. We have been tasked by the cathedral to create a specific application for their exhibition of which we have had many discussions about the limitation of small mobile devices. We highlighted the issue that a iPhone was to smaller device for the application they wanted us to achieve therefore, we suggested that a larger device eg iPad would be better suited to the specific needs of the app.

Using an iPad permanently place within the exhibition would be beneficial to both client and design team.

  • An iPad has a far greater screen size than most mobile phones meaning there is a lot more potential for larger presentation of images, text and information making it easier for audiences to see.
  • Secondly it allows more that one  person to look at the device and any one time because there is less need to hold it close up meaning a group of people can interact together creating joint learning experiences.
  • Finally its useful as the devices and be easily secured within the exhibition, having a permanent place free to use by any visitors. This means there is no need for downloading application within the cathedral an issue already discussed as there is a limited WiFi service.

Coming towards the end of the building process it necessary to test the application on a device to see if there is any issues cause by this transition from simulator to final device implementation. With the superior nature of the XCode simulator we can feel confident that there shouldn’t be any issues however, this is never a given as there may be issue with placement of elements or loading of files. One main issue we may encounter is load time of the large Magna Carta image that has been discussed previously may be an issue especially with the limitations of a mobile device and the amount of memory they have.

To do this XCode allows syncing and use the Developer account to put a test app onto a device. This saves a lot of time for developers as there is no loading to the app store or getting approval from apple themselves meaning quick alterations can be made if necessary, instead of re uploading to the app store and downloading updates

Magna Carta Test Application from Ashley Wilkie on Vimeo.

Above is the video of the application working on the iPad a specified by the client. This test worked as we hoped, no major issues and the load time wasn’t an issue either. A few thing we need to obviously finish with the application’s main functionality and some additional features to consider like the app icon and load screen that will be chased up with the design team.

Moving forward we hope to fix these issues in the coming days and test again when the app is in the final stages of completion.

Handover & Submission

Preparation for handing over any digital project is key to reduce problems that can occur with the exchanging of information. Key to this handing over process is documentation of work and assets that coincide with the project. This documentation comes in the form of universally readable text files .md which can be read by any PC, Mac or Linux allowing any such persons to understand the project.

The first thing for us to do was create a directory which would house all the files needed for the project. We were asked to complete it as if we were giving the client, or someone else the folder and then and then disappearing. We had to ask ourselves, did we include everything they need for them to use it or continue it? Would the know where everything was? What software would they need? What versions would this software be?  These are just a few examples of the things we needed to consider for this directory.

Readme’s in plain text files:

  • Description of the files within the folder/directory
  • all versions of software that the files were made in creating asseste/files
  • locations of folders connected to folder/directory
  • licences for files within folder/directory

In addition to this the project files must contain:

  • all folders must have a readme
  • include all files even huge ones
  • Copywrite on readme.md

Writing read.me files for a universal accessibility means they need to be wrote in a ubiquitous language. This is know as markdown, a simple text format that can be understood and converted by a larger range of diverse to be read comfortably. This is essential as at any point someone could need to look at the documentation for the application meaning that it should be readable at any time readily available.

  • Readme.md – Markdown version to create a read me which then can be converted into a nice version of ms, pdf, plain text, html.
  • directory for documentation (screenshots and stuff relates but isn’t part of the app)


Copyright and Legality

Working with digital project, assets and copyright is always a concern when dealing with client based projects. When dealing with assets like images, data and information it’s necessary to be aware of the copyright obligation attached to these paying special detail to if they are available for redistribution personally or commercially.
Copyright laws & legislation were introduced in 1988 as a way to protect individuals intellectual property from being stolen, reused or reworked. Copyright can protect works such as:
  • Literary works
  • Musical works
  • Dramatic works
  • Pictorial or graphic
  • Motion pictures or audiovisual works
  • Architectural works
  • Computer software

Different levels of copyright can be handed to any given work by the producer. These depend of the type of work and how widely available they would like their work to be used, viewed or distributed. Below is 3 copyright laws we have had to consider when working in this project specifically on image and literature we were trying to obtain from outside sources.

Attribution-NoDerivs – This license allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to you.

This relates to the large scale image we obtained from the cathedral that they had sourced from a specialist photographer. His licence to us was Attribution-NoDerivs as discussed above we was allowed to use his image within the application however, we have had to ensure that we properly acknowledge him within the documentation of the application itself.


Attribution – This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered. Recommended for maximum dissemination and use of licensed materials.

The cathedrals historical team have written some information for some clauses details and additional information for the application. This information is based on a standard copyright licence as it’s going to part of their app however, still has a licences as they have provided it for us to then work with.

Attribution-NonCommercial-NoDerivs – This license is the most restrictive of our six main licenses, only allowing others to download your works and share them with others as long as they credit you, but they can’t change them in any way or use them commercially.

This licence applies to our own work, the code and assets we have produced ourselves for the client will all have this licence applied to them when handed over to the cathedral.

During this project we had an issue with copyright licence as the producer of the works was unable to let us re-distribute his work. He felt that it was being used for a commercial venture and therefore decided to deny licence of the the information. It was good that we had asked him to use the information and not just cited him expecting licence to agreed otherwise it could have repercussions on our client, then upon us and the project.

We feel that throughout this project we have managed acquiring information very well considering that it had to be obtain from outside sources contacting them getting the required licences where necessary.


Copyright.com, 2015. The Campus Guide to Copyright Compliance. [online] Available from: https://www.copyright.com/Services/copyrightoncampus/basics/law_protected.html [Accessed 15 May 2015].

App Progress Flow chart

Communication with the client is essential when working on a project. Good communication means that time isn’t wasted working on aspects of a project that the client isn’t interested in, meaning an overall rise in quality of work as client expectations are met.

As per the request of our client, they wanted to see exactly what ideas we had in mind for the app. We presented them with a flow chart of the current state of the prototype, and the stages of development we hoped to follow. This was valuable for us too so that we didn’t loose sight of our idea, and we were able to receive some comments from the client, informing future design decisions.

The Prototype Flow Chart can be seen here.

After showing this to the client, they had a better understanding of how the app worked, as its far more easy to communicate visual ideas through images and captions than it is just words.

The client was pleased with the current progression. It used the Magna Carta image as a navigation interface which they requested, it took into consideration time constraints by proposing only highlighting the key clauses first (key clauses which were pointed out to us by the client), and our future plans to add a filter system to the clause overlays.

Their one significant point of feedback was to change the way clause details were displayed. In the current prototype, tapping a clause overlay caused the app to transition to a new screen, which would house all the details about the clause. They client suggested that rather than transitioning to a new screen, the details appear modally on top of the Magna Carta image, as a translucent overlay.

This idea will be something that we will consider in the next iteration of the prototype design, before feeding back the new stage of the progress for their consideration.

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. http://www.bl.uk/magna-carta/articles/magna-carta-english-translation
  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.



MoSCoW is a technique for helping to understand priorities where a projects time has been fixed, understanding the relative importance of things is vital to making progress and keeping to deadlines. MoSCoW allows prioritisation to be applied to the required tasks and meet the requirements set out by the client. For the team instead of saying a problem is high or low importance and priorities MoSCoW has a specific uses like Must, Should, Could or Won’t.

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have this time

Have that implies when the result that are produced it will meet these constraints and demands set out in this section. For the client it states what the product will consists of providing a way to determine whether a project has been a success or failure due to if the set out MoSCoW priorities have been met.

An example of this could be an apple and shows how an apple has to meet the demands of the client (consumer). This can be applied to any client who has requirements and demands to be met.

  • Must – be the fruit Apple
  • Should – Be Edible
  • Could – Be red
  • Won’t  – be a Banana

Group MoSCoW

In developing the idea with the clients we have been asked to outset a MoSCoW initially as a discussion between the group and clients. This will allow us to determine the expectations of the project. This will then give us the opportunity to justify if our project was a success depending on if we meet the demands of the outset MoSCoW.

Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

  1. Must use the High resolution Magna Carta image within the application. Large zoomable image where users can see the small details in the document.
  2. Must have a translation of at least the key clauses from Latin into English.
  3. Must have specific details about the document such as explanations of abbreviations and crossings out.

Should: Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

  1. The application should be made and optimised for an iPad.
  2. We should make it to be displayed in the Cathedral chapter house as a digital installation.
  3. We should use default gestures that are recognised by everyone to zoom into Magna Carta image, swipe gestures to access different parts of the application.
  4. We should have a variety of description of the clauses for different age ranges.
  5. Some supporting media (image) for each clause.

Could: Describes a requirement, which is considered desirable but not necessary. This will be included if time and resources permit.

  1. We could make it so it can be used in an iPhone/Mobile but realistically it would be too small to look on a phone.
  2. We could make different translations of the document (Limited to what translations the cathedral already has)
  3. Could have a range of multimedia to support the clauses (video, audio)

Won’t: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

  1. We wont have the Magna Carta image as the centrepiece of the application with hotspots imbedded as clauses.

 What Next??

When the project progresses further and the MoSCoW will be updated if any of the factors change due to client impact. Project development could also impact the outlined MoSCoW. Prototyping and testing could force it to be changed. At the point where the client and group both feel the MoSCoW is achievable there will be no further changes made as this is the requirement that both are expecting to meet.

Dsdm.org, 2015. 10. MoSCoW Prioritisation | DSDM CONSORTiUM. [online] Available from: http://www.dsdm.org/content/10-moscow-prioritisation [Accessed 18 Mar. 2015].

Update: Updated Moscow