Finder Prototype/Group Work

To protect the identities of those working for The Broads Authority who are featured in this post, I will be using pseudo names throughout.

Finder Prototyping – Wednesday 27th March 2019

Following our work from last Friday in creating the prototype screens for the core pages, I thought it best to invest some time in creating prototype pages for the Finder experience. We still hadn’t received information from Elizabeth, the ecology expert, so the next best thing is to have the visual design ready to input the relevant information.

When ideating the layout for the Finder experience, I took a lot of inspiration from the angular features in the core pages. I wanted to keep the same style where images are encapsulated in shapes and include text, but the Finder needed its unique look, so I started experimenting. Pinterest is also an excellent place to go for outside inspiration, so I had a quick browse.

A couple of angular designs I found on Pinterest

The first iteration used angled bars, much like the theme selection page, but placing padding in between them made it slightly different. I like the use of negative space in the Pinterest examples shown above, so I made the bars odd lengths to add asymmetry and make the page seem more “interesting”. I must say, I do not pride myself in visual design as I have found my niche in UX, so throughout the day I was eagerly waiting for Thursday when I could ask the GCS for their opinion.

First iteration – Asymmetrical angled selection bars

I liked the general style but wondered if I could be any more experimental. I had the TV on whilst I was working, so I let myself zone out for a short while and see if I could gain any inspiration from an outside source. I was watching people carry boxes across my screen and thought I could try and replicate that. I imagined the image bars as banners across boxes, so I created invisible squares to stretch the image across. To play around with the text, I placed it on top of the images, at an angle (this technique keeps coming up but then I remember the usability issues) and finally underneath. It looked best underneath the images because the white showed up better against the blue background.

Second iteration – Imaginary boxes

I wasn’t sure if I liked where this was heading. It looked odd, boring and I wasn’t sure how we would handle having an odd number of options on the page. If there were three, would there be two on the top and centralised on the bottom? Would the third on the bottom be left-aligned? I’m not sure if I liked how complicated this could potentially become while still having to put input all the content. I wanted to keep the design as simple and effective as possible.

For the third prototype design, I went back to the original idea of having bars across the screen. This time, I placed the bars on the left-hand side of the screen and incorporated the angle by cutting off the right-hand side, letting the bars only cover half of the screen width. I left-aligned and placed the text to the right to fill the space.

Third iteration – The screen width is made up of half image, half text

As well as the layout of the options, the app needs to be capable of showing the user where they are along the chain of selections. We requested to Elizabeth that the experience has roughly four options to choose from until they see the information page for a specific animal or plant. Throughout the process, the user should be able to see what stage they are on. I researched some ideas on Pinterest.

Side menu options

I explored this layout with a pen and paper.

Paper prototyping a breadcrumb selection menu

I thought the selections could show in little angled boxes up the side of the screen with dots in the middle to differentiate them. These would build up to the final information screen that would either appear at the top or bottom of the screen, depending on whether the new options would show on top or underneath the last, and I could perform an A/B test to measure which would work best. The problems I encountered with this were:

• Text or icons? – Then seemingly never-ending decision between the use of text or icons in a mobile app came to light once more. There isn’t a lot of real estate on mobile screens so that icons would be best, but then we would have to conduct icon recognition testing, and that could turn out to be a mini-project of its own.
• A/B test – If we are to conduct an A/B test, we would have to prepare for this separately. Conducting mini-usability testing for one aspect of the app could be time-consuming when we have two other experiences, a map and set of core pages to test as well.
• Box overload! – With the number of boxes and bars and text all on the screen already, I had to ask myself it would be wise to add more into the mix.

After careful consideration, I came up with a possible solution. I created a breadcrumb menu along the top of the screen as there is nothing else there and each breadcrumb would inherit the first letter of the option the user has selected. To prototype this idea, I chose the third iteration of the option selection designs.

Digital prototype breadcrumb selection menu

My concern with this method is that the letters are too small on the screen. If they are going to act as clickable links, then they must be more prominent, or not be links at all. I would be discussing this in more depth with the team on Thursday.

My last task of the day was to mock up the information page. This is the final page that the user will reach and should include an image, the name of the plant or animal and a description. I made this look similar to the landing page of the app but placed the image at the bottom of the screen, as not to hide the menu I had just created.

Final information page

The symbol on the right-hand side is a “back to the beginning” button. I see this symbol mainly on music players to indicate that the user can go back to the beginning of the song, but this is only a spur of the moment idea.

My final thought for the day went back to the menu. I found myself on Pinterest again, looking at menu tab designs and interactions. I found a few examples of interactions that I liked and that could fit into the app.

I liked the way this design flows between each selection

The “kink” at the top of the selection is a subtle touch

Having the current option darker than the rest is a common solution

After this, I called it a day and caught up on some blog writing. I saved all my findings in a Pinterest board so I could off show my research tomorrow.

Group Work – Thursday 28th March

To kick-start, all BSc and Graphic Communications students and our BSc tutor gathered in SA-108 to figure out what hasn’t been started yet,  what has been prototyped, what is currently being coded up and what is completed.

• Core pages: Prototyped and ready to be coded up.
• 360° pages: Coded but the information boxes are still being redefined to be completely on-brand.
• Grid: Prototyped and on track to be completed this week.
• Finder: Prototyped and waiting for the content to be sent over.
• Map: Prototyped and Jason will start work on this during the week.

We were in an OK place but realised we needed to get a wiggle on if we were going to be ready for user testing in just over a week. However, the progress we are making is happening at a steady pace, and if I work through the week during unscheduled hours (Monday, Tuesday afternoon, Wednesday and Thursday afternoon), I will be able to catch up with my workload.

It was at this point that I realised I may have bitten off more than I could chew. I had not only agreed to code up my Finder experience that was going to contain God knows how many possibilities, but also the five core pages. For someone who isn’t necessarily a “fluent” coder, I could see myself struggling. Nevertheless, I explained my concerns to the rest of the team and my tutor and we agreed that I would carry on working on my assigned tasks and if I needed any help and support along the way, it would be catered for accordingly. Jason has already agreed to sit with me during University development hours if I ever have a panic moment. As much as I would love to sit and figure it out all for myself, we just don’t have the time or manpower that would enable me to take a meticulous approach.

My first port of call for the day was to show Corrina my core pages and Finder prototype designs. She said she liked where I was going with them, and they had sparked a few ideas of her own. She knew I had a lot of coding to get started with, so she took them off my hands and started refining them.

In the meantime, Jamie had started to look at the angle we were going to use throughout all of the designs. We started experimenting with the coordinates. The code of the final result was this:

.card img {
    width: 100vw;
    clip-path: polygon(00, 100%0%, 100%48vw, 0%60vw);
    -webkit-clip-path: polygon(00, 100%0%, 100%48vw, 0%60vw);
}

The angle of the bottom of the header image will be used across the whole experience

Landing page

Before the end of the morning session, I caught up with Corrina to see what she had come up with for the layout of the Finder and I was not disappointed. She had taken my designs, considered the best and worst bits and had come up with a brilliant solution.

Using Adobe XD, she had created a layout that ticked all of the boxes. The use of angular shapes coming in from the right and separating them with slight padding, the user can view the options without the page looking too cramped. The bars cut off vertically on the left to complement the logo placement at the top. I placed the text on top of images that have been purposely chosen to flatter each season, and the colours let the white text remain legible.

Corrina’s Finder design

My biggest challenge of the day was placing the logo on the header image on the landing page. This frustrated me a great deal, and I couldn’t figure out why it wasn’t working. I had created a CSS class called .logoRed :

  .logoRed {
      width: 10vw;
      height: 15vh;
      top: 0;
      margin-top: 1vh;
      margin-left: 5vw;
      z-index: 5;
      background-image: url('img/logored.png');
      background-repeat: no-repeat;
      background-size: 25px;
      background-position: center;
  }

Misplaced logo

After reading the same ten lines of code over and over again, it became apparent that position: absolute; was missing. With this line of code in the CSS, the logo was placed on top of the header image.

.logoRed {
    position: absolute;
    width: 10vw;
    height: 15vh;
    top: 0;
    margin-top: 1vh;
    margin-left: 5vw;
    z-index: 5;
    background-image: url('img/logored.png');
    background-repeat: no-repeat;
    background-size: 25px;
    background-position: center;
}

Today has been an excellent start for the development chapter of the project, and I am fortunate to have such a supportive team around me. In between my coding troubles, I have been able to help other members of the team with usability issues. All of our strengths are shining through, and we are slowly learning about each other to utilise our best qualities.

Group Work – Friday 29th March 2019

All screenshots taken are in the Firefox desktop web browser size to iPhone 6/7/8.

Fridays are our only full day of scheduled University time, so we were in for a big day. We had made a good start with development, but now it was time to get stuck in. Our progress report looked like this:

• Core pages: Prototyped with 1/5 pages coded.
• 360° pages: Coded and ready for testing.
• Grid: Prototyped and being coded, making steady progress.
• Finder: Prototyped and waiting for the content to be sent over.
• Map: Prototyped and Jason will start work on this today.

It was all systems go and my first port of call, to carry on from yesterdays work, was the theme selection page.

Jamie had been doing some work on Thursday afternoon to figure out how the code for the theme selection design. We needed three responsive strips across the page for each of the themes. This is the base design that was uploaded to our BSc GitHub.

First iteration – Theme selection

This was coded up using HTML and in-line CSS.

Base code for the theme selection page

The code was basic and easy to mould to fit our specific needs. By changing the CSS classes to those featured in the stylesheet for the landing page, the theme selection soon looked on brand.

Referring back to the prototype design, we needed relevant images with coloured overlays on top; this was a job for the designers. They imported the images into Photoshop, applied their magic and sent over the files. I renamed the ids #headerA #headerB #headerC to #nature #heritage #landscape and input the correct images. I was pleased with the result.

Second iteration – Theme selection

This was a great start, so I showed the designers. They weren’t happy with the coloured overlays of the photos, so they decided to change it.  I also had to incorporate an exit route, this would be in the form of a left facing arrow in the bottom left corner. The map tab was still to be included, but that could come later. For all of this to happen, however, the strips across the screen had to be slimmer, but this was easy to fix. I changed the height from 30vh to 33vh and this was applied to all three elements in .headerGroup. This is the code for the theme selection page:

[CSS]

.header {
    width: 100%;
    height: 30vh; /** viewport height chanegd from 33vh to 30vh) **/
    overflow: hidden;
    background: #212220;
    background-size: 100%;
    background-repeat: no-repeat;
    background-size: cover;
    color: #FFFFFF;
    -webkit-clip-path: polygon(0 12vw, 100% 0, 100% calc(100% - 12vw), 0 100%);
    clip-path: polygon(0 12vw, 100% 0, 100% calc(100% - 12vw), 0 100%);
}

With the new images in place as well and the text left aligned, this was the result:

Third iteration – Theme selection

Each element has been made with classes and ids that will make it easier to code into jQuery mobile. We have kept this in mind throughout the whole development process to make life easier for ourselves when the time comes to program it all.

After lunch, I started on the theme information pages. They are very similar to the landing page, so I found making these very easy. The only differences were that the h1 text would be on top of the header image, the logo would be changed to white to show better against the coloured header images and there would be a left facing arrow in the bottom left corner as well as a right facing arrow in the centre of the right side of the screen. Each page’s header would inherit the image of its title strip across the theme selection page. Once completed, the pages looked like this:

Theme info page – Nature

Theme info page – Heritage

Theme info page – Landscape

By mid-afternoon, the five core pages of the app were (mostly) completed. This brought a great sigh of relief as I had been worrying about this for weeks prior. Taking into account that I still had to make the Finder experience, half the battle had now been won.

After this, I was told that we had received a document from Elizabeth, the ecology expert, containing the content for the Finder experience. It came in the form of a word document so I had to rearrange it a bit.

Word document from the ecology and biodiversity expert containing content for the Finder experience

This document presented a few issues:

• Flora and Fauna: In previous user testing sessions, not enough users intuitively knew the meaning of flora and fauna. This would become a severe issue when the app is available to a public audience. However, this could be solved by using images as well.
• Marginal and Aquatic: Marginal plants are those that grow on land whereas aquatic grow in water. Much like the flora/fauna predicament, would users know what they mean?
• Habitat or Species: Not a difficult decision, but a decision nonetheless. Should I organise the app by habitat or species?
• The number of options: Each final stage has a different amount of options (e.g. Winter > Flora > Marginal species had two options. Summer > Flora > Aquatic species has five options.) so how would we present this many options on the page? Would our bar layout still work?
• IA map: The content needed to be converted into an information architecture diagram to visualise the information for the next stage of the design process.

However, the issues turned out to be simple to solve:

• Plants and animals: Considering the broad demographic, I decided against flora and fauna so children, adults and the elderly would all understand.
• Marginal and aquatic: In contrast, I kept marginal and aquatic to try and educate the user. People mostly know what “aquatic” means because of wildlife, so it will be interesting to see how they react to “marginal”. If during user testing, this shows to be a significant problem, I will explore other ways to word it.
• Species:  By choosing to organise by species, the users have more options to choose from throughout the experience making it more engaging.

Corrina had completed her other tasks for the day, so I asked her to design the flora/fauna selection pages and the breadcrumb bar. I briefed her, explaining that the flora/fauna selection pages had to follow a consistent design and cater for multiple options and I showed her example fo the breadcrumb trail I had found on Pinterest. Meanwhile, I converted the document into an information architecture diagram using draw.io.

My information architecture map for the Finder experience

It was nearing the end of the day, and Corrina had completed the prototype designs, so we agreed this would be the last task of the day. She began by showing me the breadcrumb designs.

Corrina’s designs in Adobe XD

She tried to incorporate the angle, but it proved to be a pain. It didn’t fit in with the rest of the design of the page and would be a pain to try and code. The first design was the best because it was small enough to fit in above the map tab and follows the K.I.S.S. (keep it simple stupid) design rule.

It was more challenging to choose a layout for the item selection page.

Selection page

All of the options were semi-viable used with a scroll element, so I used the power of deduction. Option two was the weakest because the circles contrasted the angled design too much and the images would be too small on the screen; I counted this out. Option one would require specifically rectangular shaped images which we didn’t have the time or resources to create, so this wasn’t possible either. Option three would be easy to pick images for and fit in the page nicely, but even though the corners are sharp like the angular design in the rest of the app, it looked too dull and uninteresting. Only option four was left and possed all the benefits of option three while satisfying the middle ground between the shape of options two and three. We chose this one.

Conclusion

This week has been a beautiful fusion of intense and productive. I’m feeling fatigued as we have covered a lot of different bases in a concise space of time,  but I’m very proud of what we have achieved.

In particular, I’m very proud of myself or completing the core pages of the app. It was particularly tricky for me as I am not very confident with code and it would not have happened without the help of the rest of the team, so I’m feeling very grateful. This shows how well we have all been able to communicate with each other and that we appreciate what has to be done to succeed as a team.

The next challenge will be to create the Finder experience, and I expect that to occupy the majority of next week. I am nervous and excited, so I will take each day as it comes.