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.
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.
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.
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.
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.
This post discusses how we have met the intended learning outcomes within the design processes.
Creativity: Throughout the design processes, we have been creatively thinking of appealing ways to visually produce our application. Lots of design experimentation was carried out, with many beneficial amendments being made along the way. We aimed for our app to be intuitive and easy for anyone at the Magna Carta exhibition to use and hence the simple sophisticated final design helps to achieve this. We creatively experimented with using a range of Salisbury Cathedrals style guide colours, in order to see which colours worked best on our app. We choose the brown and gold as the main colours for our app as they were the most aesthetically appealing, complementing one other well as well as signifying the importance of the Magna Carta document. Additionally, we experimented with different creative ways to display the clause information when it an overlay is selected. Coming up with a few ideas: on a new screen, pop up box or sliding up from bottom. We choose to have a slightly transparent details box sliding up from the bottom of the screen, this arguably can be regarded as an Apple convention as it is used on the iPhone. A prominent design feature in our app that highlights our creativity is the iconography within the menu bar. We had to creatively think of inventive yet understandable ways to visually represent each of the Magna Carta clause categories. An example is the ‘all clauses’ icon, it is a feather quill writing, this is inventive as we have related it to the Magna Carta and the way it was written in 1215. Some other icons which emphasise creativity could be feudal and justice, they are quite unique and show that we thought outside of the box to come up with the inventive icon designs.
Originality: Our app and the features it offers users are original ideas that we have developed over the course of the project. We have tried to be original within our designs but at the same time have adhered to conventions in order for it to suit other iOS apps and hence live up to iOS users expectations. The use of categories filtering is a original feature, that we used to clearly enable users to interact with the Magan Carta. Without the category filtering technique, the document is covered in overlays, making it look less aesthetically appealing and also more confusing for users. Initially, the icons used to represent each of the categories were taken from the internet. However, to avoid copyright issues and to enhance creativity and originality we designed our own. Designing our own original icons was advantageous, helping to make our app more unique and memorable to users. Due to this being a live brief with clients, we were limited to the extent to which we could be original as throughout the design processes, we had to ensure our app suited the clients requirements. Also, we had to adhere to Apples conventions to maintain iOS users expectations and thus originality was further restricted.
Conventions: Our app adheres to Salisbury Cathedrals style guide, having distinctly used their chosen colours and fonts throughout, ass well as using their Magna Carta logo within our navigation bar. This is extremely important as it ensures that our app will fit well within their exhibition and maintains consistency throughout their other products. We have also adhered to Apples iOS developer guidelines throughout the design processes. This is extremely important due to producing an iOS application. We have followed Apples conventions with the sizing of design elements including navigation bar, menu, icons and font sizes. We have used the conventional apple menu button (burger shaped) within our applications. Users will most probably have existing knowledge on Apples icon and thus the icon will be readily understood. This is important as if users don’t understand what it means, they may not click on it and thus the menu bar will not appear for them to easily filter down the clauses on the Magna Carta. When creating our icons for each of the categories we further followed Apples guidelines, helping to make our icons look more professional. Apples suggestions was consistency throughout the family of icons, we achieved this through using the same size, colours and stroke weight. Although some icons can be regarding as inventive and unique, others can be regarded as quite common such as the ‘key clauses’, ‘women’ and ‘jews’ icons. Apples convention are that icons are outlined and then when selected they fill. We adhered to this convention by designing unselected and selected icons, however did not have enough time to incorporate this feature. Following conventions could again be seen as limiting design creativity and originality, however it extremely helps to make designs more professional looking and hopefully more successful with both the clients and users.
Professionalism: Our final design is sophisticated and professional looking, the simplicity making the app clear and easy for a range of ages to use and understand. Searching and adhering to Apples conventions portrays that we have been a professional agency, designing a suitable app to fit the iOS market and maintain user experiences. We have also been professional in regards to our agency -> client communications throughout the project. Keeping clients updated on the progress of our app and always following their suggestions. A main example of this is the ‘hidden details’ category that the clients strongly recommended and thus we included this within our app, showing the intriguing, random things about the Magana Carta document. As an agency we have been professional by assigning job roles and tasks. Following an agile methodology, we used trello to create and assign tasks and follow how individuals are progressing. Communication between the designers and programmers was strongly maintained throughout the project, which is crucial as programmers needed to know what to visually program the app like, and what colours and icons to use. Working on a live brief has extremely developed our professionalism in working within an agency and thus will be useful when going to work in industry.
The following image is a technical drawing which highlights significant elements of the designs and describes how each of the assets were designed to make the user experience as intuitive as possible while at the same time meeting the needs of the client. The technical drawing displays how the design elements have been distributed over the available screen space along with annotations which explain the particular elements significance in the app. The technical drawing also includes the client’s style guide document enabling the reader to clearly identify where we have used their desired typography and colour scheme. The technical document is a relatively important design document as it enables project programmers to identify what the designers consider to be the central focus of the app and is usually accompanied by a pseudo code document which is a simplified coding document in which the designer expresses the desired functionality of the app too the programmer.
After the completion of the initial prototype we identified that displaying all 63 of the clause hotspots on the screen at one time visually overwhelmed the user and wasn’t very attractive therefore the implementation of the “clause category filter” enables users to highlight hotspots associated with particular categories therefore making the app much more user-friendly and accessible.
The second technical drawing addresses the implementation of the filter system by displaying the various clause categories in a the form of expandable side bar.
Objectives set out by the Client
Application needs to display their high-resolution image of the Magna Carta Document.
Our application was ultimately build around the high-Resolution image the client provided. Prior to receiving the required image from the client we were able to produce an initial prototype from another image of the Magna Carta which enabled us to establish whether the vision of the client was indeed feasible or not. One of the major issues associated with using the raw high-resolution Magna Carta image is the file-size, one of the problems associated with having a considerably large image is lag which hinders the overall functionality of the app particularly when loading and navigating the app. This objective also influenced us to implement navigational gestures such as zoom-in and zoom-out as users with larger fingers may of found it difficult to select specific clause hot-spot if the image was fixed especially as they are so close together.
The application must provide Latin-to-English translation for at least a number of clauses.
A significant section of the screen space on the application was allocated to the clause translation text and utilized the QuaySans font expressed in the client’s style guide. This particular section uses an opaque background which prevents the translation text from blending into the High-Resolution image which would of hindered the visual clarity of the translation text. There is still a large section of the Magna-Carta document unobstructed enabling the user to still select clause hotspots. We were able to translate all 63 of the clauses from Latin into English by the deadline and it’s possible that the clauses could be translated into other languages in the future.
The application must appeal to a wide-audience (Young + Older).
The way in which we ensured that the application was visually appealing to all audiences and functioned intuitive was to keep to both the Apple and client style guides. By utilizing generic touch gestures and design elements it reduced the risk of cognitive-friction which may of been present if we attempted to implement complex means of navigation. By following the style guide set by the client it will ensure that our app appears connected to the parent application therefore ensuring a smooth visual transition between the two .
The client asked for miscellaneous elements of the Magna Carta Document be highlighted and have hot-spots.
This was an objective set by the client quite late in the development of the project which resulted in use needing to produce additional logos for the filter menu as well add additional hotspots to the outside of the document. The client continued to ask for additional hot-spot elements to be added up to 2 days before the deadline.
In a recent lecture, we were taught about the importance of properly preparing project files for handing them over to a client. This has been mentioned previously but here I will go into more detail about the directory itself.
Below is a screenshot of Terminal. I navigated to the directory and typed ‘ls’ which lists all of the files and sub-folders inside. Here you can see the initial organisation of the files, and the essential readme.md which contains more details about each of the files and folders. Below that I used a wonderful homebrew function called ‘tree’ which creates a file tree of the directory and all of the subdirectories and files. As there are a lot of files here, it only shows a small snippet of it, but you get the idea. The indentations are used to show the nesting of files and folders so you can easily track their locations and parent directories.
We have tried our best to minimise duplicate files. This is essential so that there is only one location of the file as to not cause any confusion when working collaboratively. However there are some unavoidable duplicates in this directory. When we copy images into the application, it then makes a copy of the file in its directory, as well as the original inside the assets folder. This is pretty much unavoidable as all the files the app needs need to be in its directory. It is important to remember that if someone decides to update one of the image assets in the assets folder, they then need to update the copy of the image in the app folder to keep it up to date.
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.
Throughout this whole project, we made sure that we used source control (otherwise known as version control) to keep track of all the changes and files used in the app code. Recording these changes allows you to jump backwards to older code, incase something breaks or the project files are lost. It allows you to compare changes over time and track the progress of the project as it evolves.
Using source control in todays day an age is an essential professional practice as it allows you to easily work collaboratively with other people – as was done in this project with two programmers.
We put our code in a private repository on Bitbucket. This repository is on a remote server and can only be accessed by people who have permission. This is great when you want to keep your code/ project a secret, and is something we had to do as mentioned in the contract signed at the beginning of this project. We use this repository as a backup of the code. When either one of the programmers makes any changes, we are able to push them up to the repository where they will be saved.
Below is a screenshot of our Commits page on the bit bucket repository. Here you can see all of the individual commits made and pushed to the server. A commit is made after some lines of code are changes, a comment is then added so we know what the changes were in the commit – making it easier to find where to jump back to if we ever need it. It also helps us keep track of what has been done so we don’t waste time repeating processes. If you were to click on one of the commits, it would take you to a new page were you can easily see which files were changes and which likes of code were edited.
Locally, this source control was used in a couple of ways – either through Xcode itself or using Terminal. Inside of Xcode it has options for you to commit changes, push changes to the remote repository or pull changes from the repository. This is all done with a pretty graphic interface making it nice any easy to use. My personal favourite way of doing it is through Terminal, using the command line to do the same functions to source control my work.
Below is a snippet of the same commit log above, but presented through terminal.
To be blunt, using source control for our code helps us meet the learning objective:
02 Originality, creativity and professionalism in the interpretation of a live brief, production conception, pitching, management and realisation of interactive media artefacts;
It is a professional practice which allows us to work swiftly (pun definitely intended) and collaboratively on this project. While I believe we did a fairly good job at making regular commits for the changes to the code, they could’ve definitely been more regular if it was possible. One of the biggest downfalls is that a lot of the code was only written on Thursdays and Fridays while we had workshops. Within these workshops we were able to quickly get help as and when we needed it, rather than searching endlessly on the internet wasting valuable learning time. As a lot of progress was often made in short stretches of time, remember to stop and commit the changes wasn’t done as often as it should, and would usually be done at the end of the day after too many changes were made to accurately keep track of. That being said, source control has proved itself invaluable to this project and was an essential part of the whole process.
Today we encountered a large problem when trying to load the app onto an iPad for testing. The problem was that the app was using too much memory for the iPad to handle loading the app. We were testing on an iPad 2 which only has ~1gb of RAM. We had to significantly reduce how much memory it was using to get it well below this 1gb threshold as the iPad still needs to run iOS as well as the app.
Once the app started up, it was using 1.53gb of RAM to run it. We never noticed this problem before as it never had an issue running on my laptop during the development as it has 16gb of RAM. During our short time learning how to program for iOS we weren’t taught about this kind of issue and what to look out for.
Xcode has some built in debugging tools which can be used to find issues within the app. With the help of the swift magician, Marc, we were able to find where about the problem was. We saw that as soon as the app opens, the memory spikes up to an exceedingly high value and they stays there for the duration of the app running. This make us think it was something to do with the Magna Carta image in the scroll view. Our suspicion was confirmed when we changed the image file to a far smaller one and it was using significantly less memory.
As mentioned in a previous post, we already had to compress the Magna Carta image as the original file was far too large. This file was compressed down to ~188mb, about half the size of the original. Apparently this image is still far too big. When loaded into to the scrollView to display the image, the memory needed vastly increases to approximately 3 times the size. We’re not entirely sure why it uses so much memory, but if we reduce the image file size enough, it will be able to run on the iPad.
The original image we were using was using over 60,000 colours. This gave us a good level of fidelity when zooming into the image. Unfortunately we had to vastly reduce this amount to compress the image to make it usable in the app. We reduced the image down to 128 colours, saving 73% on file size. This reduced image size meant that the app only used ~380mb of RAM to run. While this is still very high, it is just small enough for the iPad to be able to run it without crashing.
The client has said that they will be purchasing an iPad so they they can use our app in the exhibit. We are hoping that they will be buying one of the newer iPads as they have more memory than the one we’ve been testing with – meaning that the app will be more stable while running.
As we come up to the final week, we’re just adding the final touches to the application to make sure that it is the best product we can provide for the client.
Last week we were given the final translations and contextualisations to use in the app from the client, so the first step was to add these into the code. After we did this, we noticed that they were significantly smaller than before. Because of this, the detailView seemed far too tall compared to the text inside it.
Originally the detailView was 500 high. This value was just an estimate size as it stuck throughout most of the development. First we tried lowering this down to 300. This worked well with some of the shorter clauses as the box didn’t drown them, but with the preface and suffixes, it seemed to be far too small and required too much scrolling. We went for the final option of 400 high. This was a good middle ground between being small enough for the shorter clause translations and big enough for the larger ones.
While doing this, I went through and cleaned up the code. This meant adding comments to functions and deleting excess line breaks to make it neater and easier to read. Commenting the functions and code is essential when handing the project over to someone else, and is always good practice to do just for myself. It is a way of always knowing what the code does and why it works/ was included. Sometimes what seemed like a simple thing to write at the time can seem complex and difficult to understand a week later. Commenting the code speeds up the workflow and is a good professional practice to get into so the code is clear and easy to read, edit and understand.
I also removed the swiftyJSON.swift file from the code. This remained in there from when I experimented with using JSON to get the translations into the code. There were also some old image files left in the project folder from when I was testing for the best solution and images to use. It is good practice remove excess files and text to keep file sizes to a minimum. Its not good to bulk out the project with assets and code which aren’t even being implemented as it makes it cluttered takes up unnecessary space.