A busy two days, spent learning all about the ecology of the Broads area and beginning to design some app prototypes, ready for ethnographic testing which will take place on Friday April 5th.

March 21st 2019

Erica Murray from the Broads Authority came in today to give us a talk about the biodiversity and ecology of the Broads. The information she provided was particularly useful for our wildlife finder app prototype as it gave us an idea about some of the fauna and flora species that are living in the Broads. Whilst she was talking I took some notes, below:

Wildlife information

  • Oulton Broad has the least biodiversity of the five sites.
  • Wildlife may not vary from season to season. May need to accept that wildlife doesn’t always change.
  • Lots of rare snails in grazing marshes in the Waveney valley. Grazing marshes attract rare birds which feed in these environments.
  • Could include conservation designations in the app.
  • ‘Ramsar sites’ are protected by European conservation designations – Breydon Water and Carlton Marshes are examples of these.
  • Reeds and Fen are important. Fens are richer than reedbeds – they have lots of plants in them. Important habitats are on peate soil.
  • Peto’s Marsh is arable land – farmers sold the land and going to create a big reedbed there. Marsh Harriers will likely reside here.
  • Oulton Broad is suburban – ducks and swans but not a lot else. Not the richest place. Used mainly for sailing which can limit ecology.
  • There are over 200 species of dragonfly in the Broads.
  • Beccles Marsh has barn owls and snails.

Ecological threats to the Broads

  • Chinese Water Deer escaped from a wildlife park(?)
  • The Broads are under threat from rising sea levels, high tides affect the area. High tides push in salty seawater – Broads has freshwater so this makes the water more saline. Fresh water species e.g. fish are often killed because the water is too saline. There are tidal barriers to help prevent this. Pollution (e.g. nitrates and phosphates) can get into the rivers – from farming. There are efforts to reduce this leakage, but leakages still happen. Some species won’t cope in warmer and wetter weather. Ecology & biodiversity could be linked to climate change.
  • Climate change links:
    • Impact of farming on environment (e.g. pollutant runoff)
    • Map showing historic, current and future sea levels and how it affects the area
    • Information on how species may be affected by climate change in the future
    • How you can enjoy the environment without affecting it
  • Hot and dry weather means that fires spread.
  • Soil erosion from walking is not a big issue at the moment. Soil erosion in the Broads tends to be from sediment that runs off the surface into rivers and increases the river load/sediment.
  • Ditches have been ‘over-managed’ in the past – too much dredging. This removes insect and plant species. Broads Authority have an obligation to dredge rivers for navigation. Water Voles are the fastest-declining mammals in the Broads because of habitat destruction and Mink release (a few decades ago) from farms that are hunting the Water Voles. Mink are not native. Minks are being caught by gamekeepers humanly – ‘cruel to be kind’. They’re hard to eradicate. Otters have returned to the Broads. Otters fight with Minks and push them away. Minks are American.
  • Seals can sometimes get into the Broads – North Norfolk.

Protecting the Broads

  • Organisations work collaboratively to protect the Broads and talk about projects. They also work together in funding groups.
  • Should have the ability to ‘find out more’ or ‘find out how to get involved’ so that users who are interested can look at this.
Erica left us with a detailed map outlining the ecology of the area.

What we got from the talk

We now have a much better understanding of the wildlife and ecology that visitors can expect to see at the Broads and we also know more about the factors that are affecting conservation at the Broads. Naomi was very keen to include details about climate change in our app because it will affect this region heavily – not just because land may flood and some species may not adapt to higher temperatures, but also because water may become more saline and this may be the eventual death of several species. The app needs to tell people about the ecology and wildlife and also how that is likely to change in the future, but I didn’t want climate change to be the main focus of the app because there are so many things that need to be focused on too. I am also aware that climate change has become a highly political topic over the past few years and this is app is not meant to spread any kind of political agenda – mentioning the effects of climate change would be far from spreading propaganda, but I know that some people are quite sensitive to an overload of information about this and may take it the wrong way.

Now that we have a better understanding of what is there in terms of ecology we can begin to prototype one of the experiences, which is a wildlife finder/identifier and ensure that it only finds wildlife that is actually present at the sites. For this reason alone, the session was a good use of time and it was great to show another stakeholder from the Broads Authority the ideas that we had.

Designing a grid

I’ve spent some time lately prototyping various ‘websites on a grid’ using jQuery firstly and then CSS scroll snapping later. These prototypes prove that it is possible to construct a website on a grid and be able to navigate across the grid. This was a good start because it proves that our idea for a potential ‘timeline on a grid’ experience where the user is able to swipe down to navigate through the ages and swipe across to navigate through the years is possible to construct – even if there are pitfalls (as described in those linked posts).

We spent some time today discussing the implications of the grid and where we might want to allow and disallow the user to scroll. Look at the example layout below:

If the user is reading information about the site in the year 1200, then they swipe down and to the left, they are taken to the year 1500, then to 1800, then to 1980 and then to the future. Is this going to be provide a coherent experience? If the user is reading about the year 1550 and then accidentally swipes downwards instead of to the right they’re suddenly taken 250 years into the future and are reading about 1800. Is this going to work well? Is the story going to make sense if you miss out hundreds of years at a time? We weren’t so sure, but I personally think it depends on how this is laid out.

Another question that was raised was how do you move from 1400 to 1450 and 1650 to 1700 and so on? I.e, how do you move ‘from the end of the row’? What would that interaction be? How would that look on an app? We weren’t so sure, so we started drawing some ideas.

The first solution was a grid that we affectionately named ‘the staircase’ because of the way it looks.

This was mainly Chloe’s idea and solves the problem with ‘reaching the end of the row’ and the problem with users swiping and potentially missing out hundreds of years (or if we end up adopting this design for the app in general, lots of content) by forcing the user down a more linear pattern where they have to scroll through the entire timeline (or content). Here are the positives and negatives of this idea:

Positives:

  • User sees all content.
  • Less interaction, so harder to ‘get lost’.
  • Possibly a more logical approach for the user to follow – they expect to be guided through an app rather than left to their own devices (most of the time).

Negatives:

  • Less interaction could mean a less-interesting experience
  • Works well for timelines and content that should be displayed in a chronological order, but doesn’t work as well for content that doesn’t need to be displayed chronologically because the user has to scroll through a lot of content until they reach what they want to see.
  • For long timelines it doesn’t offer the ‘two dimensions’ that the basic grid does – i.e. users can’t skip through ‘generations’ like they can on the basic grid.
  • Possibly more complex to code.

A lot of the negatives can be overcome by using buttons and menus to skip to certain sections, but this means a more cluttered interface and potentially more for the user to learn in terms of ‘what to press to do the action they want’.

In the end, Zach proposed that we modify the basic grid layout so that it did more of what we wanted it to do. He suggested that we simply limit the directions in which the user is able to swipe depending on which page they are on and then when you get to the end of the row, you move onto the first column of the row beneath it, as shown in the diagram he drew on the board.

Zach’s diagram of how the grid could work.

This idea does work well in my opinion if we stick to the layout of having the ages down the left-most column and then the information separated into the appropriate years/decades in the columns to the right of that. I’m just not too sure how the interaction will look between the end of the row and the beginning of the next – that’ll be for Ameer, our interaction designer, to figure out.

We then had a discussion about how best to inform the user of how to move across the grid. My thoughts were that you could have little speech bubbles with instructions that pop up. On the landing page of the grid (i.e, upper left corner) there could be two buttons – one pointing left (inciting a swipe interaction) and one pointing downwards (inciting a scroll interaction), each with instructions – see my drawing below:

My ideas for instructions within the app.

The speech bubble for the swipe arrow reads ‘Swipe across to go through decades’ and the speech bubble for the scroll arrow reads ‘Swipe down to go through the ages’. I felt that this was simple and got the message across. I felt that by using bright colours and pulsing animations on the buttons it would be be possible to grab the attention of the user and get them to tap on the buttons to reveal the speech bubbles – or maybe the speech bubbles could be visible without any prior interaction? My idea reminds me of what Microsoft did with Windows 8.1 when it came out in 2013. They wanted the user to know how to use Windows 8.1’s ‘hot corners’, so after you installed Windows 8.1 for the first time there were these dialog boxes that would appear instructing you how to use the hot corners and they wouldn’t go away until you completed the action that the dialog box wanted you to do – see the example of one below.

These instruction dialogs were generally disliked in Windows 8.1, but might work well for our app.

‘Hot corners’ were a way of switching between apps and programs and showing the ‘charms bar’ (which featured links to system settings and similar) in Windows 8 and 8.1. Hot corners were introduced to try and make it easier for mouse and keyboard users to use Windows 8, which was arguably more of a touch-based operating system. One of the criticisms of Windows 8 when it was launched was that there was not enough tuition in Windows to teach users how to use the new interface, so Microsoft implemented the ‘help tip’ dialogs in Windows 8.1. These, and hot corners, were removed from Windows 10 – probably because they were not received very well in Windows 8.1 at all. In fact, even years after Windows 8.1 went to market the internet is awash of tutorials explaining how to permanently disable the hot corners and these dialog boxes explaining how to use them. They probably didn’t work too well in an operating system because:

  • There’s lots of things that a user can do in an OS, so these were popping up left, right and centre all the time.
  • This means that there’s also a lot of things that the user might want to do without the need for instruction like this. What if you don’t want to switch between apps right away?

For a small phone app with just two buttons (or actions, even) to learn about, it could work quite well. They could go away if the user completed the action. Unlike in Windows 8.1, where you could use the operating system without any of the swipe actions at all, you can’t navigate around our app without swiping, so you have to know what to do.

Naomi suggested that it would be interesting to potentially A/B test the two grid systems (basic and staircase) and see which worked best for our application.

After this, the graphics students had lectures and critique sessions to attend for their other projects (non-related to this) and I went away to finish developing the Storehouse website and plan for Storehouse Issue 18’s launch.

March 22nd 2019

Today Chloe and I worked on modifying the 360 degree image experience that I developed several weeks ago and took images for at Oulton Broad on Tuesday. Ameer and Zach designed the interface for the grid system and Naomi and Corrina designed the other app screens and worked more on a consistent UI that we could use across the app.

Chloe and I started off by looking at how we could modify the existing information dialog boxes in the 360 experience. We decided that due to the screen estate (or lack of it) on a mobile device it’d be better to make information dialogs full-screen so that we could display as much information as possible. Firstly though, Chloe and I spent some time designing icons for the information dialogs using the components of icons that the graphic communication students made a week or so ago.

We started by acknowledging that most information icons are a circle or square with a lowercase ‘i’, which represents ‘information’. We decided that we would stick to this convention and so designed an ‘i’ using bits of the main Angles Way brand mark that the graphic communication students had developed. The ‘body’ of the i would be formed by rotating the Angles Way brand mark and cutting it down and the dot would be just simply be a circle.

The body of the ‘i’ was formed from this brand mark.

 

We experimented with two different cuts of the brand mark to make the body of the i, shown below.

The information symbols that Chloe and I designed.

Feedback from our peers showed that the icon does look a little like a person jumping with their arms out, but besides from that people liked the i and felt that it fitted the branding and styling of the app nicely and looked consistent. We went for the icon on the right.

The theming for the app that the graphics students have come up with uses a red colour for the culture theme, a yellow colour for the landscape theme and a blue/turquoise colour for the ecology theme. Chloe and I are working on a 360 degree image experience which is probably best-suited for the cultural theme, so we decided to use the red colour as the background colour for the little hotspots that the user taps on to bring up the information dialog, shown below.

The 360 degree image, emulated running on a Google Pixel 2 XL.

We also made the hotspots a little smaller so that they didn’t cover so much of the image.

I made some changes to the code of the hotspot buttons so that it looked better with our icon. Originally the hotspots were divs that the user tapped on to reveal the content – and they still are, but the image for the hotspots was defined in HTML code and the size was defined using CSS, meaning that if you wanted to make the buttons bigger or smaller you needed to change several CSS properties (such as width and height of the individual image in the hotspot and the width and height of the class that the hotspot divs were contained in) or if you wanted to use another image you needed to find an image that was the exact same aspect ratio of the previous one and remember to change all references to it in HTML.

By modifying the HTML so that the div was empty and then setting the icon as the background image, now all that needs to be done to make the hotspots bigger or smaller is change the width and height of the hotspot class (called ‘reveal’) – the icon will scale to fit the new width and height. Additionally, to change the image all that needs to be done is change the path of the background image and it is changed across all of the hotspots that use the ‘reveal’ CSS class – much better than having to manually modify the link to the icon in each hotspot HTML div.

Here’s the new CSS code for the reveal class.

.reveal {
    width: 50px;
    height: 50px;
    background-color: #C25747;
    background-image: url('../img/info.png');
    background-position: center;
    background-repeat: no-repeat;
    background-origin: content-box;
    background-size: 30px;
    border-radius: 50%;
    margin-left: 0;
    text-align: center;
    cursor: pointer;
    transition: height .3s ease-in-out, width .3s ease-in-out, border-radius .3s ease-in-out, margin .3s ease-in-out;
    border-radius: 50px;
}

There’s a lot of background-image properties in this – here’s what they do:

background-position: center;

‘Does what it says on the tin’ – aligns the background image so that the centre of the image is aligned with the centre of the div that it is the background of.

background-repeat: no-repeat;

Again, as it says – prevents the background image from repeating itself, sometimes called ’tiling’.

background-origin: content-box;

Not one that I often use, this sets the background image to be aligned to the top left of the corner of the containing div, I did this to help increase the padding between the edge of the divs and the icon.

background-size: 30px;

Sets the scale of the background image. Without this, the background image occupies the whole div and there is no padding at all, so this combined with background-origin helps add some padding by making the background 30x30px when the div size is 50x50px.

Whilst I was coding all of this I was explaining it all to Chloe who was really interested in learning about what I was doing. I’ve often thought about going into teaching computer science and even teach children at tech clubs in Norwich how to code, but today I really saw how hard it can be to ‘teach and do’ at the same time! I was coding it as I was telling Chloe what I was doing and I, rather embarrassingly, kept making mistakes! But at least I was able to show her how I check for errors in my code, how easy it is to make mistakes (most of them were silly things like getting div class names incorrect – probably as I was preoccupied talking to Chloe) and how to Google for solutions! I was also able to explain to her the difference between an ID and a class – something that took me years to fully understand! I look back at my old code sometimes and laugh at all the IDs I used to use that should have been classes!

Chloe went on to design some prototype screens for the information dialogs in Illustrator, all of which are shown below.

The copy that Chloe used in her designs is all genuine text from our historian that could be featuring in the final app release.

I really liked the design of these and they fit really nicely with what Corrina and Naomi were designing in regards to the colour tints, the angle of the images, the fonts and the colours used. Below is a screenshot of their work.

The app screens that Corrina and Naomi designed.

Ameer and Zach were working on how the screens on the grid were going to look, below is a sample that they made.

An example of one of the screens on the grid, designed by Ameer and Zach.

It’s very clear to see how each of the three pairs worked together to come up with different parts of the app that carry the same identity and styling. The styling looks modern and sleek, but these are all prototypes at the moment and are all subject to change with usability testing.

Coding Chloe’s designs was quite simple, even getting the angle on the image is simple thanks to the use of CSS clipping paths which allow you to create custom shapes in CSS by plotting points and ‘joining them up’ with lines – a little like a dot-to-dot drawing. Knowing points to plot in the CSS can be quite difficult , but thanks to a website called ‘Clippy’ it is possible to draw shapes in the browser and then copy and paste the generated CSS clipping path code for the shape, see the screenshot below.

‘Clippy’ is an excellent website for generating CSS shapes.

I drew out the trapezium shape that Chloe designed in Illustrator and then used the following CSS code.

.reveal-content img {
    width: 100vw;
    opacity: 0;
    transition: width .01s ease-in-out, opacity .01s ease-in-out;
    -webkit-clip-path: polygon(0 0, 100% 0%, 100% 40%, 0% 100%);
    clip-path: polygon(0 0, 100% 0%, 100% 40%, 0% 100%);
}

The image on the information dialog is held in a class called ‘reveal-content img’, by adding a CSS clipping path to the class styling it ‘cuts’ the div into that shape. Clippy generates the code with the ‘-webkit-filter-‘ prefix applied so that the code is cross-browser compatible – some browsers, such as Safari, won’t execute the code unless that prefix is in place.

Setting the class to be 100% of the viewport width of course ensures that it is the full width of the device display.

The code for the rest of Chloe’s design is fairly straightforward.

.reveal-content {
    position: fixed;
    width: 100vw;
    height: 100vh;
    background-color: #2D303F;
    opacity: 0;
    text-align: left;
    pointer-events: none;
    transition: opacity .01s ease-in-out;
    z-index: 1;
    padding: 0;
}

The only major change that I had to make to the information dialog was setting the position of it to fixed so that it filled the browser window, setting the width and height to 100 viewport and setting the padding to 0 so that the image was not padded in. However, if you look at Chloe’s designs you’ll note that the text is padded, so inside the ‘reveal-content’ div class there is another div titled ‘content’ which contains all of the text (both the heading and the body copy) and this has a padding of 15px so that just the text has padding.

The final result is shown below.

The coded version of Chloe’s dialog box prototype.

The other designs should be easy to code as well, they are just variations of this one with different clipping paths for the image. It would be cool at some point to write a JavaScript function that automatically adjusts the clipping path of the image based on the length of the string in the body copy. It could be done – all I’d need to do is figure out which bits to change as the string length increases. Something to look at in the future to save time – and to ensure that the image angle is always uniform.

More immediately, I need to work out how to get this dialog box to display in the ‘current view’ – or open so that the top left corner of the dialog div is anchored to the top left corner of the device viewport (meaning that it is full-screen). At the moment when you tap on the hotspot the dialog box is displayed, but it is displayed just beneath the location of the hotspot button. This is leftover from when the hotspots were just displayed a small div. There is probably some JavaScript or maybe even CSS code somewhere that is determining the anchoring and thus location of the dialog.

Chloe was really pleased with how her design looked coded and it went down well at the critique delivered by Jamie and graphics tutor Amy. Jamie suggested that perhaps the dialog box didn’t need to be full height and that it could cover the centre of the screen, showing the image more behind it as to not take the user away from the experience. He also suggested that the image could be removed and a ‘tinted window’ could be used in its place, allowing the user to see the image behind it. These are both valid ideas that I’d like to explore.

Design principles

Usability is very important in the design of this application, so one of the best set of design principles to follow are those from Dieter Rams, a famous functionalist industrial designer who designed some of Braun’s most famous consumer electronics in the later 20th Century. His design principles revolving around ‘functionalism’ put form before aesthetic, which is what usability testing is all about. Yes, designs need to look aesthetically-pleased, but in my discipline the usability has to be there before the appearance.

This Braun radio is one of Rams’ most famous functionalist designs.

Dieter Rams’ ten commandments for good design dictate that:

  • Good design is innovative: it brings something interesting and unique to the table.
  • Good design makes a product useful: the product has to serve some kind of a purpose and the design should help the product do this.
  • Good design is aesthetic: it looks good, but its looks do not interfere with its functionality.
  • Good design makes a product understandable: the user can understand how to use it – it should be intuitive to use.
  • Good design is unobtrusive: it should not interfere with the natural user flow.
  • Good design is honest: it doesn’t promise to be something that it isn’t.
  • Good design is long-lasting: it doesn’t follow trends or fashions so strictly that it becomes outdated when that trend or fashion does.
  • Good design is thorough down to the last detail: the user is guided on how to use it – nothing is left to chance and everything has a purpose.
  • Good design is environmentally-friendly: producing and using the product does not affect the environment negatively.
  • Good design involves as little design as possible: ‘keep it simple’ – don’t over-engineer things.

If these principles can be stuck to then the design will be both usable and aesthetically-pleasing – a perfect combination. Our designs are already showing some of the signs of these principles. The colour palette and shapes are beginning to become consistent and are looking elegant, but modern and trendy. We hope that these design can be translated into similar designs for other experiences that may be added to the Angles Way app or for apps for other walks, such as the Wherryman’s Way. This will help to make the app long-lasting and use as little design as possible as elements can be reused in other parts of the app. This also helps to improve the consistency of the design.

Hopefully these simple design ideas will make the app intuitive and easy to use, but user testing will determine whether that is the case or not.

What’s next?

I’m writing this post about a week after this happened. The past week has been extremely busy with thinking about my dissertation idea and the launch of Storehouse Issue 18 – which I still need to write a post about. As a result, I haven’t been able to experiment any more with this or jQuery Mobile, meaning that tomorrow (Thursday 28th) that is what I’m going to be doing. Jamie suggested to Ameer last week that using my jQuery or CSS scroll snap examples might be a good place to start before we look at jQuery Mobile.

We are testing this with users in an ethnographic manner on Firday 5th April, so from now until then we will be producing fully-coded prototypes and continuing to work collaboratively.

References

Vitsoe.com. (n.d.). Dieter Rams | About Vitsœ | Vitsœ. [online] Available at: https://www.vitsoe.com/gb/about/dieter-rams [Accessed 22 Mar. 2019].

Vitsoe.com. (n.d.). Good design | About Vitsœ | Vitsœ. [online] Available at: https://www.vitsoe.com/gb/about/good-design [Accessed 22 Mar. 2019].