Adding Design Features into the App

After a long period of structural development on the app we got to a point, where everything is relatively working and the skeleton of our code is completed. We needed to start designing the look of the app. The design side of our team made some mock-ups of how they thought the app would best look, in relation to the guidelines and it was our job now to implement these designs into a functional app.

The first major part of the design to do was simply to add a background colour to  all of the views. At first I though it was a simple task, as I assumed that there was a straight forward colour picker on the interface which would automatically change the colour of the view, but unfortunately there wasn’t. After a bit of research I found to set the colour of the background you need to call the backgroundColor class of that particular view and then set it with a UIColor an example of the code is used is below:

self.view.backgroundColor = UIColor.redColor()

The next task was to reformat the design of the buttons. The positioning of the buttons were already done as it was included in the structural design of the app.  The design of the buttons in the mock-ups were ones which are the full width of the view, with a proportional height and the colour was the blue supplied in the design guidelines as you can see below:


To achieve this style of button, it relied heavily on constraints. As the buttons had to be dynamic, change size depending on the screen size. Especially in the case of the question view (as you can see below) where there is a cluster of 4 buttons the spaces between the buttons had to relatively stay the same but the height of the buttons had to change in proportion to the screen size without going too small. The rest of the button design was simple, which was colour and opacity which is accessed and changed on the user interface.

Finally, the last thing I had to do was add in content created externally, for example turning the play button into an image and also adding a different variations of our ‘Magna-Carta man’ for example a image of him with his thumbs up when the user gets the correct answer. This process also involved me using constraints for positioning and keeping the aspect ratio of the images. The image on the play button is below:



The final design of the app is below, which includes all of the design features originally intend and is being previewed on an iPhone4s simulator.



Implementing the JSON.

After establishing that we’d be using JSON to store data for our questions, it was time to actually implement this in the code.

The bulk of the code written to implement JSON data storage.

The bulk of the code written to implement JSON data storage.

This is the main section of code that we developed in order to make data storage possible with JSON. As we have discussed elsewhere, due to limitations with the environment in which the app will be used we are opting to store our data locally. This code therefore essentially locates the local JSON file, and parses it as an array of objects of the question class we declared at the start of development of the project.

In the main ViewController for the quiz section of the app, an array is declared and set to the result of the loadQuestions() function above, so that the code in the main body of the app essentially remains the same as it ultimately interfaces with the same array of objects, but more code has been implemented on the back end in creating this array from our JSON file, a snippet of which can be seen here.

Snippet of the JSON file.

Snippet of the JSON file.

File storage, P-lists and JSON.

Having previously discussed here the benefits of separating the data for the app’s questions from the functionality in the code, the question still stood on how to best go about achieving this goal.

Speaking to our tutors, and doing our own research as well, there appeared to be several different options to explore which could provide a suitable solution in the context of our work.


P-lists, more formally referred to as property lists, are files used  in OSX and iOS programming to store serialised objects. They are generally utilised to store a user’s settings for an app, however can be leveraged to store various information about applications. In this current context, a property list file could be used to store information about each question contained within our app.

These files are most commonly formatted in either an XML or a binary form, and can be edited in a text editor. Additionally, the Xcode environment has built in support for editing property lists. These files can be viewed in a hierarchical manner and edited in a similar fashion.

An example of viewing a P-list file in Xcode.

An example of viewing a P-list file in Xcode.


JSON, standing for JavaScript Object Notation, is a commonly used, lightweight data interchange format ( The format uses human-readable text to transmit data which is comprised of pairs of attributes and values. Its most common use is to transmit information between servers and web applications, similarly to the XML format. JSON is a format that was originally derived from JavaScript, a scripting language that is well-used on the web. Despite this, the format of JSON itself is language independent, meaning JSON data can be created and interpreted in many varied programming languages.

Usefully, one such programming language with support for the JSON format is Swift. Even more usefully, we have already been given somewhat of a head-start on using JSON in Swift, due to a tutorial workshop that was given which covered some of the basics. Storing our data in the JSON format makes sense at it is somewhat of a standard for data transfer, being somewhat easier to use that XML-based solutions, and after some trial and error I have had more success adapting the currently stored information to this format than to a property list-based structure. The JSON format also, similarly to P-lists, has the benefit of being easily human-readable and understandable in its text-based representation. Unlike the property list format, there is no visual hierarchical editor built into Xcode, but I do not think this is too big a consideration, since part of the point of separating the data from the code to begin with is to make it easily editable by people with no knowledge of the code base of the application – people who would likely not wish to use the Xcode software to make these changes anyway.


After deciding that our data will be stored in the JSON format, there is still the question of where exactly it will be stored. This format lends itself well to communicating with an external server to fetch data over the internet. This, however, would add an additional layer of complexity to the development process and would come with its own set of problems and limitations. We are unsure at this moment in time whether to go down this road or whether to store our data on the local filesystem with the application, as these methods both have their relative strengths and weaknesses. In either case, however, a JSON-based approach to providing the code with data for the questions is likely to be feasibly achievable, and therefore we have decided to adopt this technology moving forwards. I will post the progress we make with implementing this functionality as it is made.



Introducing JSON [online]. Available from: [accessed 15 May 2015].

Easter Progress Report

Meeting with RedBalloon

We were now well underway in the design process of the app, and felt it appropriate to organise a meeting with RedBalloon for an assessment on the progress of our project. We discussed the need for a functioning prototype to evaluate, as a basis for looking at what needed changing or modifying if need be. Overall the feedback we received from RedBalloon on our application was that the mechanic we had opted to use, of a sound being played, and matched to a multiple-choice answer was appropriate and well-suited, but we needed to ensure the content was relevant and well-designed as the idea was primarily content-centric. We noted this as a priority for development and decided it could be checked by user testing with relevant professionals for our demographic – a primary school teacher and the education officer for the cathedral.

Additionally, one of the main needs for a basic functioning prototype was to organise a meeting with the client and present the prototype for feedback which could then be incorporated into the next iteration of our design. Discussion of the project with the client would help us to see what still needed work on in order to meet the needs of the client and ensure we were headed in the right direction – as well as to make use of any ideas suggested in the process.

Lastly, we discussed the need for user testing of the prototype, in order to ensure it was suitable for the target age group. It was suggested that this could be achieved by meeting with the education officer at the cathedral, who dealt typically with school groups, in order to assess and discuss the intentions of the project and its current manifestation for suitability with the target demographic. We also planned to get into contact with a primary school teacher for a similar style of review as a form of user testing.

Ultimately the project had now reached a breaking point most important, with 4 weeks to go, where we needed to assess the upcoming prototype against the original MoSCoW analysis in order to ensure we had met the criteria set out, as well as the criteria set by the brief, and the client. We would look at the mechanic, by discussing it with the client and other parties involved, and decide whether it would work for the final build in its current iteration. We would do the same for the style of the content – as we needed to start making definitive changes and finalising aspects of the project, and anything that needed changing would need to be done so now.

We also identified a few potential issues at this stage of production – we had to address issues with a potential data cap for apps accessed via a mobile network on the iOS system, as well as fidelity of the content. We still needed to implement progression and narrative system into the app to instill some emotion and sense of achievement, as per the MoSCoW analysis.

Our final priorities for the development of a finished prototype were to source sounds for the content, complete a successful JSON database for the integration of content, re-word some of the content, test the prototype on an iPhone to ensure that it works as intended on a physical device, as well as develop final broader priorities for the final 4 weeks after a prototype had been developed and checked properly.

Annotated MoSCoW Analysis


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

Sounds to describe phrases must be of high quality and clearly audible for the user, and should not breach any copyright or intellectual property laws

Sounds being played to the user is an integral part of the concept and so is deemed absolutely necessary to include in the final build. The sounds must be high quality to the point they can be clearly heard by the user to offer both a solid user experience and to not detract from the mechanic of the app

Sounds must make sense in their connection with answers, and relate to corresponding phrases through use of word-sound association as per detailed in examples

The main mechanic of the concept revolves around the connection between the sound effects being played and the phrase that they correspond with – so the logical link between them needs to be feasible and make sense, else the concept falls apart, and the concept breaks at this point, as the user will not be able to make connections.

Sounds and their connections with answers must elicit relevant information to the magna carta history, and legacy as per the current part of the app, and with appropriateness to the target demographic group

The brief states that there must be a close connection to the Magna Carta as a general concept – therefore it is imperative the factual elements of the correct phrases elicit accurate information in order to meet the brief. The factual information must also be understood by the target demographic.

Sounds must be able to be manually played by the user with the option to repeat if needed

Users must be able to repeat the sound if needed, as they may require a second guess or attempt at listening to the sound in order to confirm their choice. This is a must, as the user may otherwise get stuck and not be able to move on through the app.

The app must save progress on closure automatically, requiring no input from the user to do so, and be persistent during total closure of the app, or shutdown of the device

The persistence of user progress on app closure is a must-have feature as failure to do so will likely cause the user to not want to use the app, as they will have to repeat questions in order to achieve their previous score.

The app must offer the choice of three different answers to the sound combination, of which one is unequivocally correct and two are incorrect

When the correct answer has been chosen there can be no debate as to why it is correct, and the others are incorrect, as this will cause the app to appear to lack integrity. Likewise, more than one correct answer would go against the central concept of the mechanic and multiple-choice quiz conventions, and will be confusing for the user.

The app must include a separate view in which the relevant fact or info is displayed for the correct answer, and be of a legible font, colour, size, and arrangement

A separate view for the facts being revealed after choosing a correct answer is key, as they will not be able to fit alongside the content already being displayed without resulting in an unclean interface and composition, producing a poor aesthetic for the user, potentially dissuading them from continued usage of the application. The font must be legible in all sense of the term in order for the user to easily read, and make use of the information supplied.

Graphical elements and the design of the app must be adaptable and fit on all proposed devices properly.

The visual design of the application must be adaptable – as per the brief, the final product will likely be adapted by a senior designer in order to be built into a large application framework for final release to the client. The graphical elements must be easily adapted to the brand bible supplied by Haley Sharpe design, and the components must fit on all proposed devices in order to avoid incompatibility which could render the app dysfunctional.



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.

The mechanics of the game should be self-explanatory and easy to understand through the use of appropriate design cues, visual hierarchy and consistent graphical elements

Self-explanatory mechanics are an ideal feature to have in the app, as it is reasonable to assume a well-formed connection with the game and the user will improve engagement with the concept as a whole, however should this not be included the user can still refer to instructions in order to learn how to use the app.

The app should suggest to the user, or prevent the user from, playing sounds during prayer times at the cathedral, taking care not to sound patronising or offensive, perhaps through the use of looking at the system timer and displaying a relevant message

This feature would be useful to have included as it shows an element of responsibility in the production of, and encouragement of using the app as well as showing awareness of the environment, however the creators are ultimately not responsible for the ways in which users make use of, and the times they use, the app as there are too many outside factors that could circumvent this, including, but not limited to, other applications available to the user in the final product.

The app should have a clear visual sense of progression narrating the structure of the game

This element was suggested in a sense through feedback from the client and university staff – that there should be an emotive element to the game. The inclusion of a progressive narrative through the application helps to reinforce the concept of a storyline to the user, and fosters connection with the subject matter.

The incorrect answers offered should be feasible, and/or believable as correct ones, in order to provide a challenge to the user when selecting a response

If the incorrect answers available to the user are completely, unequivocally wrong due to an obvious tone of speech or subject matter, in stark contrast to that of the correct answer, then it could be argued the content would offer no challenge to the user, and potentially no hook to keep the user interested due to a lack of challenge.

The app should explain how the sounds provided result directly in the correct answer as opposed to the incorrect options through literal description, or potentially synchronised animation with the sound clips in the “correct answer” fact view

Including this feature has the benefit of explaining to the user how the connection is formed, which could in turn elicit a type of rationale the user could apply to following questions, in order to better understand the mechanic and the process through which the sounds have been matched with the answers.



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

The app could include a mascot character narrating the playthrough if it appeals to the target demographic, which can be explored through user testing prototypes with said demographic or looking at available research

The inclusion of a mascot would add greatly in terms of emotive appeal and the support of a strong narrative in the app, however is not strictly necessary and this could be achieved in other ways. The addition of a mascot would however be highly beneficial to the value of the app, if time allows this.

The app could include a view showing instructions explaining the mechanics of the game which would be clearly legible and in line with other graphical elements of the game, providing a succinct yet helpful tutorial on playing the game

The mechanic chosen for the game is categorically self explanatory due to the nature of the quiz format being used as well as visual hierarchy and user cues that will be naturally picked up on – however if time allows, the addition of an instructions screen will help to engage users and ensure that full understanding of the concept is achieved.



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

The app wont rely on QR codes as previously discussed due to adding a further layer of complexity and possible issues with architecture in the location

The base mechanic of the application is standalone and the content is not contextualised in an explicit sense that requires QR codes to be attached to the environment. This can be ruled out as a feature due to the sensitivity of the environment, also.

The app won’t be geolocated in the environment as previously discussed due to possible issues with GPS in the cathedral and a lack of necessity for the current feature set

GPS requires a view of the sky to work correctly and/or accurately, and the application has been designed with this in mind. While the concept could be adapted to make use of GPS, it would add another layer of complexity that could block engagement between users and the main intentions of the concept.

The app won’t have a unique or irrelevant visual style in order to remain adaptable to other apps and the design guidelines

As previously stated, the visual style must be matched to the Haley Sharpe design guide as per the brief and client’s wishes, as well as to ensure maximum cohesion with the other aspects of the project as a whole.

The app will not be available in a landscape orientation, due to the lack of content that affords this, and the types of usage by the user that might require this

Landscape orientation compatibility will not be built into the application as a form of usage sanitation, as the content will not be best suited to a landscape orientation and there is no need for the layout to be adaptable to such, for this particular application, as it will offer no salient benefits for the user.

The Border Design and Creation.


With the architecture of Salisbury’s Cathedral being such an allure for visitors both new and returning, and with the best kept version of Magna Carta Being displayed at salisbury cathedral. Although the cathedral isn’t completely intrinsic with the Magna Carta. Given however, that the environment of the church will be the setting in which people will be experiencing the app along with the fact that we want to give a historical yet playful feel to the app. It therefore made sense to include the cathedral within the app. So this required some further research.

It became apparent from both my own experience and its reputation that the architecture is very aesthetically pleasing, and definitely leaves a lasting memory. This is one of the key factors behind why it was chosen to be incorporated into the graphics of the app. It was decided an effective way of including this would be to create a border in the style of the architecture. The Cathedral is a very well kept example of Early English architecture. Salisbury Cathedral is unique in that it was built within a short time span (c1200-1275), thus its architectural style is predominantly Gothic. Upon further research into gothic architecture. It has become apparent  Quatrefoils are a big part of the design, they were popular back then and have remained popular through out the ages and can now be seen in a variety of different design circumstances. They are crucially about using symmetrical and geometrical designs to create beautiful complex looking shapes from simplicty. The basis of the design of a quatrefoil is 4 identical circles overlapping. As can be seen below.


the part of the cathedral of particular interest to me which served as my inspiration was this part.



As Illustrator is a vector based image creating software and the border would need to be created so that it could be re-sizeable through scaling it allowing for responsive design without loss of quality. This Meant the software used would need to be a vector based software for definite. I therefore chose to utilise the tools of adobe illustrator to create the design.


MAGNAMAN Trumpet with border

The design of this was then re-designed in regards to the use of colours so that it complimented the other elements better.


in play screen

Separating data from function and the Model-View-Controller architecture pattern.

With the basic structure of the application done, and a class made to define the custom question objects we’d be using, the question was raised of how the data would be stored to populate these objects. Each question needs to have stored a sound file, multiple options for users to choose from, and a value to determine which of these is the correct answer. As well as this, a fact needs to be stored relating to each question, however this functionality has not yet been implemented into the application.

So far, the relevant information has simply been stored in the code as an array. This is an array of our custom question objects, and is statically declared in the code before any functionality takes place. This works well for the basic prototype, as it allows the core functionality of the app to work with a small sample of example questions. However, this is not a solution which lends itself well to being easily updated with additional questions in the future. It also doesn’t make understanding this data and where/how it is stored very easy if anyone needs to change the information for any reason.

Both of these issues would be solved by storing the information about all of the questions in the application in a single file, separate from the main body of the code. This  would allow the questions to be updated and changed more easily, since the code of the application itself would not need to be changed at all. The person changing or adding a question could simply open this file, change the text for the relevant question or add a new one, and then drop an accompanying sound file into the right folder within the application directory. This not only makes this process faster to do, but also allows people with no knowledge of the Swift programming language, array declaration, or our custom class structure to add in their own questions or change existing ones without a steep learning curve.

Separating the data from the functionality and appearance of an application in such a way is a common and useful strategy. This way of designing a system is referred to as ‘model-view-controller’ or MVC. As described by Burbeck (1992), “In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task”. In essence, MVC is made up of a model, which manages the data of the application, a view, which manages graphical/text output, and a controller, which interprets and responds to user inputs and updates the model and view where necessary. In this instance, separating the data for questions into a separate file will create a distinction between the model (this new file) and the controller (the existing ViewController in the Swift code).

To this end, I intend to go about the reworking of the code that has been produced thus far so that these elements can be effectively separated out while still maintaining the intended functionality of the application. This will involve moving the question data to a separate file, and producing some accompanying code in the controller to fetch this data at the right time so that it can be used and displayed in the view. In order for the data to be used within the app, it will likely still be pulled into an array in the code so I expect the implementation of functionality after that point to stay largely the same, however work will need to be done on developing a system to fetch the data and interpret it in the right way. I am not yet certain what form or file-type the data will take, or how exactly the code to manage it will function, but I am certain that completing this task will be beneficial to the general functionality of the application and the ease with which we will be able to continue to work on it.



Burbeck, S., 1992. Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) [online]. Available from:    [Accessed 15 May 2015].