iOS

Previously, we the details for each clause stored in a different view controller. This meant that when one of the clause overlays was tapped, the view would change to the new controller, giving a different full screen page which would have the details about the clause on.

This is what it looked like: https://gfycat.com/LateFalseAracari

After having a meeting with the client, to show them our progress thus far, he had a different idea for how we could display the information. Instead of sliding across from the side, he’d like it so slide up from the bottom, overlaying the Magna Carta image.

Doing this meant we had to take a completely different approach to the way we were doing it. We started by deleting the old view controller, it worked, but wasn’t the right thing for the job. To get the detail view as an overlay, we created a new UIView which would appear on top of the image view (Magna Carta image); this would be the container for the detail view. To start with, we made this view to be 500px tall, so it take up around the bottom third of the screen. This size is likely to be updated as we fill it with information to better suit the shape and size of the text filling it.

We decided to do this programmatically rather than using the interface builder as it would allow us to have better control over positioning elements and it made it easier to keep track of animations and functions. A lot of this was due to personal preference. As we have struggled with using the interface builder in the past, we opted for using the route we were more comfortable taking.

We created an instance of the detail view, giving it a position and a size where it would appear off the bottom of the screen. A boolean was used to keep track of weather or not the detail view was showing. When an overlay is tapped, the boolean switches from false to true, causing the detail view to animate into position on screen.

With this there were a few inherent problems which would need to be solved. The overlay would show and hide when tapped perfectly, when the image wasn’t zoomed in. Once you zoomed into the image, the position of the box was completely wrong and nonfunctional, as shown in the gfycat video below.

http://www.gfycat.com/BeautifulMassiveHypsilophodon

This was a problem due to how the view, image view, the scroll view and the subviews were set up. Pretty much how everything so far was connected, was wrong. This meant changing a few lines of code to fix the way the different views were connected. The image view needed to be a subview of the scroll view so that it could be zoomed and scrolled. The clause overlays also needed to be in this scroll view so that they would move with the image and stay in the correct positions. We then had to put the detail view as a subview of the view, rather than the scroll view so that it would appear separately and not be moved or zoomed with the image and other overlays.

This solved the problem with detail view overlay allowing it to appear separately from the scroll view and be immovable.

UPDATE: In the first instance there was very basic functionality when interacting with the clause overlays and the detail view. For example the only way to close the detail view was to tap on one of the clause overlays again which would flip the boolean to false and make it hide. There was also a problem that if, for example, clause two was showing and the user then tapped clause 3, the information in the overlay would change to the new clause but it would still close the detail view (again, because of the boolean).

This is why we added a few new functional features to make the interaction a lot more intuitive for the user. By adding a nested if statement that meant if the detail view was already showing, and if another clause overlay was tapped, it would just switch to the right information for that clause rather than close the view. At the moment this switch is very sudden, and we think it might not be very clear to the user that the information has updated. In the future we plan to add animations to the text so that it updating it a lot more visible and aesthetically pleasing.

We also added a swipe gesture recogniser to the detail view. As mentioned before, using built in gestures makes the app more intuitive to use. We wanted to use this feature by having a swipe down gesture to hide the detail view; functionality that can be seen in many other apps.

We also added a tap gesture recogniser, to the image view. This meant that if the detail view was open and the image view was tapped it would again, dismiss the detail view. This again is another functionality feature which can be seen in other apps. When there is a view present on top of another, tapping the one behind often dismisses the top one so the behind one can be better seen.

Adding these little gestures has made the app instantly feel much more like an iOS application. It is the addition of small, seemingly insignificant features which make a large impact on user experience, making it far more pleasurable and enjoyable for all.

Below is yet another gfycat video of the app so far. The overlays are different to what you’ve seen before as there are a few incomplete changes which need to be finished and will be blogged about in the future. The video shows the new interactions, albeit very quickly and rather difficult to follow. It shows opening a clause’s details (And then accidentally closing it), then opening a clause, switching to a new clause then swiping down to close the details. Then finally opening a clause and tapping the image view to dismiss the detail view.

http://www.gfycat.com/WiltedDefensiveHarvestmouse

As we are producing our app for iOS devices (iPad, and possibly iPhone), it is important that we look at Apple’s iOS development guidelines. This ensures that the app we produce would be suitable for the iOS market and that it adheres to conventional iOS themes. ‘Although crisp, beautiful UI and fluid motion are highlights of the iOS experience, the user’s content is at its heart’ (Apple 2015). We plan to create a simple and well designed information based app that will allow the user to quickly and easily access relevant content related to Magna Carta. After reading through the iOS developer guidelines, we picked out some of the most important iOS themes to consider in our app designs:

Translucent UI elements – we could consider this so that when users taps on a clause, a translucent overlay appears with more information regarding the selected clause.
Use of negative space – it is important that we use plenty of negative space within our app in order to make it clear and easy for users to understand. We have to consider not putting too much information over the Magna Carta image as it could easily be overwhelming for the user.
Simple colours – using the Cathedral’s style guide, we will use their chosen colour scheme in order for our app to be consistent with existing products.
Ensuring legibility – we will use the font suggested by Salisbury Cathedral (Eidetic), at a suitable, easy to read size.

It is important to also be aware of the basic UI elements in order to help us make further decisions about the design of our app.

Bars (navigations/tab) – contain contextual information that tell users where they are and controls that help users navigate or initiate actions.
Content Views (collection/table views) – contain app-specific content and can enable behaviours such as scrolling, insertion, deletion, and rearrangement of items.
Controls (buttons/sliders) – perform actions or display information.
Temporary Views (alerts/actions) – appear briefly to give users important information or additional choices and functionality.

Using conventional iOS gestures is also essential and something we need to consider when creating the design of our app. ‘Using gestures gives people a close personal connection to their devices and enhances their sense of direct manipulation of onscreen objects (Apple 2015). Some of the common iOS gestures that we could incorporate into our app include: tap, drag, flick, swipe, pinch, and double tap.

It is also important to use Apple’s built in features (UI elements and gestures) due to the time constraints we have to make the app in. Given our current skill level, it is essential for us to stick with what we’re familiar with and are being taught so that we can produce a fully functioning, and hopefully aesthetically pleasing app before the deadline. Creating our own UI elements can be far too time consuming and difficult for us, and will only be done if it is essential for the app to function.

Here is Salisbury Cathedrals Guidelines that we were given. We will adhere to these within our app through using their chosen colour scheme, fonts and existing graphics. This is important in order for our app to be consistent with their existing products for the Magna Carta exhibition.

From this, we will go on to create some initial designs for our app taking on board the above Apple and Salisbury Cathedral guidelines.

Reference:

Apple, 2015. Designing For iOS [online]. Available from: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/ [Accessed 6 April 2015].