Finder Development – Wednesday 3rd April
All images of the experience used in this post include images that were added at a later date. At this stage of development, we used placeholder images, but I did not record these.
This was the last week to perfect our experience ready for user testing on Friday. Our status was:
- Core pages: Coded and ready for testing.
- 360° pages: Coded and ready for testing.
- Grid: Coded and ready for testing.
- Finder: Prototyped and waiting to be coded.
- Map: Coded and ready for testing.
I had a horrible feeling in my stomach and a niggle in my brain saying “You’ve bitten off more than you can chew”. I did not want to admit it, so I pushed on to complete the task at hand.
Much like last week, it was tough to record the events as they were happening on this afternoon because I found myself deeply immersed in progression most of the time. When I was working on developing the Finder experience, the process consisted of working through technical pieces of code that I understand but find challenging to regurgitate and explain. Additionally, because of the strict time restraints, I found myself wanting to push on and get things done. In other circumstances where we all bore an equal workload and had more time, I would have been able to record the process more thoroughly. Coding this experience had also been a considerable challenge for me and developing the pages on this day was particularly challenging; I had to ask Jason to sit with me and help. Luckily he said yes and was willing to guide me through, so we spent the day developing the pages for my Finder. This is the IA for the Finder experience for reference throughout this post:
Information Architecture of the Finder experience
The main issues we encountered during the day were:
- Stages one, two and three: Develop separate skeleton pages to hold different amounts (2, 3 and 4) of selection bars.
- Stage four: Develop a page that can hold up to seven final-stage options.
- Stage five: Develop a page to hold the information about the items.
- Polygons: These tricky little things were an absolute pain to figure out to be able to code from scratch to create the exact shape and angle we desired.
We tackled each step one-by-one and by the end of the day, were able to complete all of the tasks ready for inputting the images.
Polygons
To begin the day, we took a look at the theme selection page. I thought that we could manipulate the layout of this page to suit the prototype version we had. I tried to adapt the code to hold the same shape but change the dimensions to suit my needs. This turned out not to be possible, so we had to start from scratch and figure out how to create polygons from scratch.
Up to this point, Jason and I had been using Clippy, a free online CSS polygon generator. I thought that if I created a shape in the box and copied the clipping path into the stylesheet, then it would work; it wasn’t as simple as that. The clip paths were correct but were placed differently from the image on the generator. I don’t know whether this was because of the way it converted to HTML or something else wasn’t quite lining up, but after an hour or so of troubleshooting, the problem was becoming tiresome. So, instead of trying to make the generator sync up with our scripts, we aimed to figure out polygon shapes for ourselves.
We tried to research a solution, but we found nothing about how CSS polygons are constructed. We needed to figure out the maths for ourselves. After another hour or so, we had concluded, and when tested, it worked.
The polygon coordinates are calculated by four separate points. These points lie in a square with an x-axis and y-axis spanning from 0%-100%, and the top left-hand corner of the square is 0,0.
Polygon coordinates
Using these calculations, we were able to create our polygon shapes. The clip-path for each selection bar looks like this:
CSS clip-path: polygon(20%37%, 100%12%, 100%75%, 20%100%);
Each coordinate requires an x and y percentage, so from the above coordinates, we can see that point A starts 20% along the x-axis and 37% in the y-axis. Point B is 100% along the x-axis and 12% down the y-axis and so on.
We were so pleased, and this was our most significant achievement of the day.
Stages one, two, three
Now, we were able to start positioning them on the page. Stage one was simple because it only consists of one page with four seasonal options.
Stage 1
Stage two was also straightforward, but each season required it’s own page to all JavaScript click throughout later on, so four identical separate pages were made but named accordingly. (Spring, Summer, Autumn, Winter)
Stage 2
Stage three was slightly more tricky. Creating the skeleton pages was as simple as the others, but we did have to create a new page to hold three items.
Stage 3 (Summer)
Now that we had enough skeleton pages, we had to consider how many different pages were required to be able to link them later. This was when I had to start thinking about each season’s user journey seriously. Each season needed two separate pages for plants or animals, resulting in eight stages three files in total.
Stage 3 files
Stage four
Stage four’s architecture became more complicated as it builds on options presented in stage three.
Stage 4 files
Creating the layout for this stage didn’t take long because we took the design straight from the theme information pages but added content boxes underneath the header image instead of text. These boxes are individual div classes inside a div class called content.
<div class="content">
<h1>Birds</h1>
<div class="boxes">
<divclass="info-box reed-warbler">
<p>Reed Warbler</p>
</div>
<divclass="info-box sedge-warbler">
<p>Sedge Warbler</p>
</div>
<divclass="info-box grasshopper-warbler">
<p>Grasshopper Warbler</p>
</div>
<divclass="info-box cettis-warbler">
<p>Cetti's Warbler</p>
</div>
</div>
</div>
Stage 4
Stage five
Stage five was the most simple of all but the most time-consuming. Each page had to be coded up, but that was a job for Thursday. For now, we were happy with our template that was ready to have images and text inserted.
Stage 5
Group Work – Thursday 4th April
The work we had completed the day before had set me up very nicely for a big dev day of inputting content into pages and finalising the stage five pages. This day was laborious and time-consuming, but not particularly difficult. All the hard stuff was completed on Wednesday, so now it was a case of inputting images and connecting the files up using JavaScript.
There are 23 information files in total all with the same layout. This is the body code for each information page:
The base code for stage 5 files
It was simply a case of changing the hero image, <h1> text and <p class = “info”> text. Each file name was to be saved as the name of the item to be able to link buttons in JavaScript later. Jamie had created a word document of body copy, so I just had to copy and paste the relevant content.
Item information
Once all the pages were complete, I was able to link everything with JavaScript. Taking the Black Headed Gull as an example, this is the JavaScript click path the user would take to get there:
//stage 1-2
$('#autumn-button').click(function () {
location.href="stage2/autumn.html";
});
//stage 2-3
$('#autumn-animals-button').click(function () {
location.href = "../stage3/autumn-birds-mammals.html";
});
//stage 3-4
$('#autumn-animals-birds-button').click(function () {
location.href = "../stage4/autumn-animals-birds.html";
});
//stage 4-5
$('.black-headed-gull').click(function () {
location.href = "../stage5/black-headed-gull.html";
});
This shows how the user clicks through the different stages of HTML files to reach the final item information page.
The adjoining finder.css file includes all of the button <ids> organised by section.
/*Seasons*/
#autumn-button {
background-image: url('../img/options/autumn.jpg');
z-index: 12;
}
/*Birds/mammals*/
#birds-button, #spring-animals-birds-button, #summer-animals-birds-button, #autumn-animals-birds-button, #winter-animals-birds-button {
background-image: url('../img/options/birds.jpg');
}
#mammals-button, #mammals-button2, #mammals-button3, #summer-animals-mammals-button, #autumn-animals-mammals-button {
background-image: url('../img/options/mammals.jpg');
z-index: 11;
}
/*Items*/
.black-headed-gull {
background-image: url('../img/specimens/black-headed-gull.jpg');
}
I was drained after staring at this much code all day but felt incredibly proud of what I had achieved. All the hard work was now completed, and I was ready for a day of testing.
User Testing – Friday 5th April
To protect the identities of the test group candidates I have erased their faces from all images included in this post.
After a long month of ideation and development, I was feeling a mixed bag of emotions on test day. I was nervous to show our creation to a user group but excited because we are all so proud of how far we had come. The user group, consisting of three ladies from the Women’s Institute who we had met during Stage 1, were very helpful and enthusiastic during our first meeting, so I had high hopes for us to gather qualitative data.
We set off from University just before 10 am and after encountering a short delay, arrived at Oulton Broad at roughly 11 am. We parked in the same place as when myself and the other students visited a few weeks ago and walked through Nicolas Everitt Park to the waterfront. As we got closer, we saw the WI waiting for us by the café in front of the yacht station. We all greeted each other, ordered some teas and coffees and sat down on some tables outside.
Beginning the session in the sun
Once we were all settled and ready to begin, the GCS brought out a poster prototype of signage they had designed that features the QR code. They talked the WI through their design, explaining how this would be bigger and on a walking trail. However, unfortunately, the weather was not on our side as it was very windy and we nearly lost the poster a few times.
Showing the WI the prototype signage
This was a minor setback, but we couldn’t afford too many as the WI were only available for a few hours, so we took the meeting inside the café. It was a small and intimate space, but luckily there weren’t a lot of other customers. We were able to tuck ourselves in the corner.
We made a base camp in the café
Each tester was assigned a phone each, but due to the experience being optimised for use on a Samsung S8 and the University only able to provide us with two phones, we had to use one of our own. This was quite unprofessional of us and if we had more time, would optimise the app for an iPhone 7 as well so we could rent another test device from University.
Now, we started to really test the app experience. The ladies knew what a QR code was but struggled to scan it easily. This could be resolved by including some short instructions, next to QR code, on the signage. With each tester holding their own device, they ended up going off on their own journeys. Jason and I kept an eye on them, recording their actions, thoughts and opinions, but this did prove to be quite tricky. With people conversing in the background and the coffee machine in regular use, it was difficult to keep a track of what was happening at all times. This, coupled with the seating arrangement (we were sitting across the table from each other in a small corner) also limited the amount of data we could really gather because we couldn’t observe all of their actions for our own interpretation. A lot of ethnographic research relies on the interviewer’s professional interpretation of the tester’s actions, not just what they say about the experience (these can be wildly different in some cases) and this situation wasn’t ideal.
A small corner with a lot of people
As expected, there was an abundance of data gathered from the testing session, even if slightly discombobulated. I took notes for each of the sections which were core pages, theme selection, finder, grid, 360 and map along with general notes about the overall experience.
Core Pages
- These first pages of the prototype were described as seamless, easy to use and intuitive.
- They were not interested in reading any of the introductory text.
- When navigating between the first five pages, they were hesitant to use the arrow buttons and were expecting to swipe.
- They weren’t sure how to navigate from the theme selection pages apart from the Nature information experience that read “Touch the right arrow to navigate through to the Nature Finder experience”.
- After displaying difficulty with navigating through, one tester admitted “I don’t know what the signs mean, they’re all so modern. I think your generation would be able to figure it out. It’s too sciencey for me.”
- Would this be easier to show to a younger demographic? Has this experience been geared more towards a younger generation?
- The app may be too specific to a younger generation and middle-aged demographic. Did we become too self-involved in the making of the application and didn’t spend enough time in the mindset of the user persona?
Improvements
- Amount of copy text: The WI wasn’t interested in reading long copy text other than when using the Finder experience. This is a bias towards the purpose of an information experience but could still be indicative of too much text being featured on the core pages. A next iteration could significantly cut down on the amount of coy text throughout the experience.
- Swipe functionality: The WI much preferred the swipe functionality and should be integrated within the whole experience.
- Instructional guidance: All theme selection pages should include instructions about how to navigate through the rest of the application like quoted in the nature information page.
- Map/location pin: After testing it became apparent that the symbols may not be suited for the wide demographic this experience is aimed at. Where applicable, it may be worth including words rather than iconography.
Map
- Upon closing the X to close the map from within the theme selection and 360 experience, users are shown a blank, empty blue screen.
- Some users couldn’t find the map tab at all.
- We had to show them how to use the majority of how to use the map.
- They couldn’t find how to select a new location.
- Should clicking on a new location changes the whole experience to show content from that place? (Upon reflection – no. The experience is always based on the physical place where the user is.)
- All of the icons were recognised with no doubt.
- I told one user to click on the map tab when she was using the 360˚ experience. In turn, she thought it could only be accessed from there.
- Should the map only be accessed through the core pages?
Improvements
- Familiarity: Depending on the user group, they will either be familiar with digital map technology or they will not. This is difficult to adapt to everyone because naturally, everyone will have different capabilities. The best we can do is do enough user research to be able to design for a target demographic.
- Accessibility: The next iteration should test whether the map only be accessed from the core pages is a suitable change. Having access from each page may be too much information every single page of the experience.
Finder
- One user knew what marginal species means but commented that this might not be obvious for everyone.
- The “Birds” option includes an image of a barn owl. They commented that barn owls aren’t found in Oulton Broad.
- Users were very confused with the Season > Animals > Birds architecture because they didn’t class birds as animals; they see birds as birds. However, they understood that this was included because mammals and reptiles were involved in other seasons.
- They would have like to have seen more types of duck and common animals because they seem them there a lot. The purpose of the experience is to look inside the hidden habitats of locations along the Angles Way.
- The information that was included was incoherent because I stayed up late and got mixed up. All information needs to be relevant to the animal or plant in question.
- Users have to press the back button repeatedly to get back to the beginning.
- I had initially included black text on the image item boxes of the name of the item (e.g. Grey heron, Yellow Iris) but during development, these inherited the <p> class and were changed to white (against a white background.) I only noticed this during testing and interestingly, one user commented that this was a good idea. She thought it would have looked cluttered if there was text on the image.
Improvements
- Jargan: The ecology expert gave us some technical words to figure out and understand so I decided which to include and which to change to simple English. I kept “Marginal” but changed “Flora and Fauna.” As our testing group consisted of older ladies, this was OK. It could be used to teach young children, but that is putting all of your eggs in one basket. We would need to decide whether this is aimed at teaching people new terminology as well.
- Relevance: Images are to be season/location specific. This can quickly be resolved with more time and research.
- Birds IA: Should a layer of the IA be taken out for the bird’s sections? This could be resolved by rearranging the IA to include more options in the animal’s section?
- Include common animals?: Further research should take place to find out how much people already know about the wildlife in the Broads. The purpose of the experience (to show people hidden habitats) is quite a broad scope because people might see animals every day but not know what they are or anything about them.
- Retrace your steps: The user needs to be able to press a point in the breadcrumb trail to jump back to that stage and a “back to the beginning” button should be on all information pages.
360˚
- All three women really struggled to find the option (situated in the top right-hand corner) to change the experience from having to drag the image to be able to utilise the gyro sensor in the phone.
- Additionally, they struggled to figure out that they were even able to drag the image with their finger.
- This lead to them not being able to find any more information hubs and their initial reaction was not joyful.
- After commenting on the incoherent text in the Finder experience, I was surprised when they didn’t pick up on the text in all the information hubs being the same. Did they not read it or were they more open to the text not being perfected yet?
Improvements
- Iconography: The gyro icon used was not as indicative as we had hoped. This lead to the ladies not enjoying the experience at first. This whole issue can be resolved by keeping the icon in the top right as an optional change but setting the default load state to using the gyro sensor. This means that when the mobile even slightly moves in the user’s hand, they will see the image move and want to try to move it more. Thus, exploring the rest of the app.
Grid
- The testers didn’t have a lot to comment without a prompt.
- They thoroughly enjoyed it, along with the animations. They were very impressed with the images and especially the grid in the corner that shows where they are on the timeline.
- Each user was struggling to click on the directional arrows because they are too small.
- They preferred the swipe action.
- They found it simple and easy to use.
- I didn’t feel as if they knew the purpose of the experience or what was going on when they used it. After giving the experience praise, I asked for their thoughts on what they thought it was and they didn’t comment on the timeline concept whatsoever.
- They used the back button in the browser a lot more than the in-app left arrow. Is this because that is what they are used to when using the internet? Would they be more likely to use the in-app button if this wasn’t web-based but an app by itself? (I think yes)
Improvements
- Arrow size: The arrows must be made significantly bigger so that users can press them with ease.
- Swipe: Having said that, they preferred to swipe anyway. I don’t think everyone will though, so it would be worth running an A/B test with one experience relying on swipe and the other with arrows to see what is more prevalent in general.
General Observations
- The women are already very familiar with the area. They questioned the content a lot which made us wonder about our demographic. Do we want this experience to be for more visitors or locals? Both demographics will wish to find out more but locals may be expecting certain information and could question the credibility when it’s not how they know it.
- They didn’t take time to read the body copy, so time needs to be taken to figure out what information needs prioritisation. Chop away the dead wood.
- The main pages should include short pieces of text, or even just a tagline and information pages are to be marked. If the user wants to read more they can on some pages but are not subject to it throughout the whole experience. All the testers became interested in the copy when they got to the Finder because they knew they were there to be educated.
- Due to time constraints and the volume of the work, we didn’t prepare any test questions. This meant that we went in with no direction and we received good and bad comments with no context.
- Having such a small test group of a very particular demographic was very tough. The data gathered, although dense, is very bias towards an older, less technologically intuned generation.
- This test was vastly different from every other testing session we have conducted because instead of learning solely about how the app could be improved, they focused heavily on content. It turned from a usability test into a content audit/interface test.
- I felt very emotional about the technically orientated constructive comments they made about my experience. Upon reflection, I realise I felt this way because I had created, designed and developed it. Normally, I wouldn’t have become so attached because I would only be responsible for research and architecture NOT development. I took their comments to heart when the copy was wrong, and the text was the wrong colour because I knew that it was because of my lack of skills in that particular field. I felt like it was because I wasn’t good enough at the development when in fact they were pointing out possible improvements.
The end of the testing session was rather rushed because the testers could only be with us for a finite amount of time. After the courteous thank yous, we parted ways.
We finished the afternoon by having lunch in the local pub and reflecting on the day’s findings. I had a lovely roast and spoke about the difficulties of making iterative decisions based on the opinions of three elderly ladies. Others spoke in-depth about how the text should be significantly cut down, and the designers expressed their happiness of how it all went. The ladies had nothing but nice things to say about their branding and designs, so they were very proud of themselves (and they should be!).
I felt exhausted on the way back and was looking forward to getting home and having a cup of tea. It had been an extremely long, intense and muddled month working on this project and I was looking forward to the Easter break.
Conclusion
Even though the week was off to a hectic start, we were rewarded with a relaxed and fruitful ending. I achieved a lot in the last few days and had a lot to reflect upon. Similarly, part of me couldn’t believe it had nearly been completed. This project had occupied almost every waking moment of my life, and I was always dreaming up innovative ideas and user-friendly solutions. Although, I did have a lot of writing to catch up on so I was looking forward to some free time to catch up.