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.

Trello
Trello

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.

BitBucket
BitBucket
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.

Summary

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.

Advertisements

Final Application

Now that the application is essentially finished, we thought we’d write a complete breakdown of the aesthetics and the functionality of it. Warning, this is a long and detailed block of text which describes what we hope is every aspect of the application we considered.

[0 :00] The app is called “Magna Carta Translation” as is written on the application icon seen on the iOS springboard. When opened the splash screen shows while the app loads, which has a similar image, enlarged to full screen. Compared to other apps, this one takes a while to load. This is due to the large image file being loaded into the scrollView which allows for the functionality required.

[0:10] Once loaded, the user is presented with an image of Magna Carta covered in alternating translucent coloured overlays over all of the individual clauses. As Magna Carta is a solid block of text, the alternating colours allow the user to see when one clause ends and the other begins – avoiding confusion which would arise if all overlays were the same colour. On load, all of the clauses are highlighted, giving a good overview of the whole document.

[0 :14 ]The image of Magna Carta can be zoomed into and enlarged up to 2 times the original resolution of the image file. As the original file is already quite large, allowing another 2 times zoom lets the user go even further without affecting the resolution and appearance of the image too adversely. Allowing the user to zoom in this far lets them explore minute details in the document which aren’t clear to the naked eye without magnification. This allows the user to view the document in a more fun and interesting way as they can spot details which could’ve never been seen otherwise. The overlays are sized so that they cover as much of the text they are trying to highlight as possible without overlapping other clauses. Towards the latter end of the document, the lines start to bend, making it more difficult to accurately cover the clauses.

The image is placed within a prebuilt feature of Swift called a UIscrollView. This allows for the zooming and panning of the image placed within. Zooming uses the iOS standard gesture of pinching; spreading the fingers to zoom in, and bringing them together to zoom back out. Panning, again, is another standard gesture where the user holds and drags the image once zoomed in. The image moves with their finger as they *drag* the document about giving a very tactile and fulfilling experience. Scroll and zoom bouncing have been disabled so that users can’t scroll past the edges of the picture, or zoom too far out of the picture. Scroll/ zoom bouncing are the built in features of iOS which allow the user to scroll further than the page/image so that it bounces back to the edge. We also enabled features such as ‘double tap to zoom’ which should be intuitive to many iOS users as it is another standard feature of the operating system.

[0 :17] In the top left corner on the navigation bar, a burger icon (three horizontal lines) is placed which toggles the appearance of the filter menu. This placement and icon have been chosen as they have become synonymous with activating a menu or navigation feature in many other applications. We wanted the app to appear familiar to the user so that it was intuitive how to use its features.

The menu feature is a splitViewController. To the layman this is a view which appear only over part of the screen. When opened, the menu covers approximately the left 2/5 of the screen, so that the Magna Carta image is still visible on the right. The menu consists of a list of words and icons which are categories for common themes within the document. As well as the themed category filters, there is an option to show all clause overlays (like when the app first starts up) and to hide all the overlays. Hiding the overlays lets the user explore the document in its full glory without any distracting coloured overlays blocking their view. The icons are symbolic of the menu feature they represent. For example, the ‘church’ category has an icon of a church next to it – anchoring the text and its meaning. Some icons are more symbolic. For example, the ‘all’ option has a quill which is symbolic of writing. The icons are very simple images which are clear and easy to distinguish. They add yet another aspect of familiarity as many other Apple lists (in menus and such) are often accompanied by iconography to help enforce the meaning the button.

[0 :20] The side menu can be opened by either tapping the menu icon or swiping from left to right when the image is fully zoomed out. This is an intuitive feature as if the user is dragging the menu from off the left side of the screen into view. Similarly, the menu can be closed by swiping from right to left as if pushing the menu back out of view. As the list of filters is longer than the length of the screen, it can be scrolled to show the rest of the options. This scrolling feature, again, is standard within iOS and is intuitive for many users familiar with touch screen devices. On a side note, the ‘hidden details’ category is placed at the bottom of the list. We really like the placement of this category is it in itself is initially hidden, playing with the function of the category. When a category filter is touched in the menu, the colour changes to show which one has been selected. Once the tap has ended, the menu closes and the clauses from the chosen category are highlighted on the document image. The overlays fade in rather than suddenly appearing. This subtle aesthetic feature makes the experience just that little more pleasurable for the user and nicely transitions the change of information.

[0 :25] Each coloured overlay is essentially a button, toggling the appearance of the detailView which contains the translation of the selected clause. The clauses have tap-gesture recognises on them which, when tapped, cause the details of the clause to slide into appearance from the bottom of the screen. Once a clause has been selected, the other clauses shown on screen fade out so that only the chosen one is shown. This allows the user to clearly see which clause they have tapped and is a pleasant aesthetic transition alongside the appearance of the detailView. The detail view ‘springs’ into place from the bottom of the screen. When it appears it slides up past its final resting place and bounces back to where it stays. We added this animation as it makes the interaction more fun and playful – something we wanted to add to what could be considered a rather dry and boring application.

The detail view covers approximately the bottom third of the screen which provides ample space for the app the display the number of the clause and its translation. This view is on a slightly translucent background so that the document can be faintly seen behind it. This translucence follows a common theme within iOS 8 wherein views appearing on top of others tease at what is behind. On some clauses where the body of text is too large, the text view itself can be scrolled to reveal the rest. There are multiple ways for the user to close the detail view. The first is for them to swipe down from top to bottom on the view to dismiss it. This is a built in gesture within iOS and is used in other places in the operating system. We feel this feature works quite well as the view slides up from the bottom – making it logical for the user to be able to ‘push’ it back down out of view. The second way is the tap the Magna Carta image above to ‘dismiss’ the detail view. Again we felt this feature to be relatively intuitive as it conforms to similar themes within Apple’s operating systems – tapping the object behind to dismiss/hide ones on top of it.

[0 :30] When the detail view is dismissed, the other clauses in the chosen category fade back into appearance so that another can be selected. If the menu is opened while the detail view is also opened, the detail view is forced closed so there isn’t too much information cluttering the screen.

Colours were carefully chosen to provide enough contrast to ensure it is fully legible and to conform to the design style set by the client and RedBalloon. Throughout the app, shades of brown, gold, cream, and blue are used which all match the guidelines provided to us. Also conforming to the guidelines is the Magna Carta logo at the top of the screen inside the navigation bar. This logo nicely fills the empty space, and helps the anchor and contextualise the image of the document.

As for typography, the app in its current state isn’t using the fonts set out by the guidelines. This is because we don’t have a license of the font so we are unable to put them in at this point. We made sure to make the font slightly larger than the default size so that it was easy to read without strain.

The translations used within the app are very simplified versions. This is so there isn’t too much text in the app which would cause the user to lose interest. It also makes it so the average person would be able to understand them. Some clauses are accompanied by further contextualising or interesting information which also make the app more interesting and fun to read.

[01 :00] Above, a ‘hidden details’ category was briefly mentioned. This was added as the Cathedral wanted to point out some details about the document itself and not just the words written on it. The overlays in the category are presented as outlines, rather than filled translucent boxes so that what they’re highlighting can easily be seen without being obscured by the overlay itself. We even chose to not show the hidden details in the all category. This was actually done because it would mean overlapping of clauses in certain places, but we like to believe it was done to emphasise the mystery of them being ‘hidden’. The hidden details category is arguably one of the most valuable as some of the information isn’t available anywhere else.

Below, videos of the app in use can be seen, demonstrating the function and usability of the app as described above.

Magna Carta App from Ashley Wilkie on Vimeo.

Magna Carta App Front from Ashley Wilkie on Vimeo.

Magna Carta App Second from Ashley Wilkie on Vimeo.

The Final Push

We are heading into our final week of the Magna Carta Application development for Salisbury Cathedral. This week, we have a lot of finishing up business to compete with the application and blog from all members of the group.

Trello has been used throughout this project to specifically to control the groups workflow however, coming into the final stages it’s now more specific tasks that need to delegated to members of the team. An openly available document on a team Google Drive folder or the Group connected social media group has become essential for quickly communicating tasks to members when away from group meeting.

Currently list heading into final week:

Programming

  • Fix the fatal error getting the filters to work
  • Get the final colours sorted out
  • Put the app icon in
  • Make and put in the splash screen
  • Add category for hidden details.
    • Get Kayley to make icon
  • Put the right details and get new shapes for the hidden details.
    • Put the Hidden Details icon in
  • Maybe show which category is selected somewhere
  • proofread the clauses – names, categories etc.

Blog

  • How the programming meets the learning objectives
  • Make videos of the app working to blog about
  • The animations (Spring, fade, etc)
  • App icon and splash screen
  • Debates about swift (why we used it)
  • Hidden details category
  • make a video of a user interacting with the app

Other

  • Gather all the project files
  • Make the file tree in a single directory
  • Make readme files for the directory
  • set up wordpress on Dakar
  • copy wordpress content to new blog
  • create index.html page as a directory for our project

Design

  • Draw up final designs – blog about them
  • Make a nicely annotated final design with as many details as possible
  • Blog about meeting the learning objectives with the design process
  • Make the icon for the hidden details
  • Edit the money icon (possibly others)

We are aiming to get all these tasked finished with a few days to spare giving everyone time to assess each other’s work before the hand it to the client. This will mean we can ensure the app and blog work is to the high standards expected throughout the project.

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)

https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

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.

http://creativecommons.org/licenses/

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].

Content Gathering & Approval

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

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

The British Library have provided a translation of the document to use which is considered very reliable as its completed by an internationally recognized organization. The donTranslations – http://www.bl.uk/magna-carta/articles/magna-carta-english-translation (Creative Commons Licence)

Dear Nicholas

Im Ashley Wilkie a student from Bournemouth University. 

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

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

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

Our contact at the cathedral is Seif Elrashidi, – s.elrashidi@salcath.co.uk 

The University contact is Stephanie Farmer – SFarmer@bournemouth.ac.uk

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

Kind Regards, 

Ashley Wilkie

Update:

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

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