Following my previous journal, here is the journal for the 5-9th February.

Monday 5th February 2018

No morning session today, so I delved straight into creating my prototype for the website using Axure. Before I did that though, I had a meeting with Tom Haczewski from The User Story about running an event to promote my course and NUA. The meeting was held in the user research lab at The User Story’s offices in central Norwich (which is more like a lounge than a lab) and whilst Tom was telling me about the design of the room I pointed out the desktop computer in the room. He mentioned how it seemed that a lot of people when presented with the desktop computer in this day and age freak out about how they ‘don’t know how to use a mouse or keyboard anymore’ because they are so used to browsing the web on a tablet or smartphone which fulfils their computing needs adequately. He said how people are now using computers whilst being constantly distracted by things like TV, so The User Story now has to take this into consideration when they are running their user testing. It was an interesting point for a UX professional to make and further enforces the reason why learning how to create fluid, responsive websites that work with the devices that people are using these days is critical for creating a great user experience for a large majority of users.

Analysing the data from my survey

Last week I created a short survey asking users what they’d expect to find on a nursery website, why they’d visit one and how they expect it to look. I posted the survey to my town’s Facebook group and in five days received ten responses. This is a low number – lower than I was hoping in fact – however this is only ‘provisional’ data as this week I intend to post the survey on Mumsnet so that more people can answer it and in a couple of week’s time I hope that Nellie’s Nursery will send the survey out to parents with their newsletter. The first step to creating a prototype is to analyse this data because this data dictates what should be on the site and how it should look. So, here is the data.

Firstly, it was great to see that the survey only took on average 2 minutes to complete. I didn’t want the survey to be time-consuming or feel like a laborious task for the user. This proves that my choice of questions were easy to think of answers for and the fact that the majority of my survey was composed of closed questions did help to make the survey quick to answer. If the survey takes forever to answer, people get bored and either don’t complete it or just write anything or check any box to get it over and done with. There was no incentive to complete this survey and the people who answered it volunteered to do it, so it can be assumed that the following answers are all correct.

Secondly, 90% of users said that they had visited their child’s nursery website. The one person who didn’t gave the following reasoning for not visiting the site:

Usually because we can see what our child is up to on Tapestry. And we don’t really need to visit the website because the information we need comes up on Google anyway.

Having worked in a primary school with a nursery before starting university, I know that Tapestry is a system that teachers can use to send pictures, journals and reports back to parents over the internet. The parent receives an email notification when something has been sent to them via Tapestry and they can log in and see what has been sent to them. Tapestry is a popular system and a lot of nurseries are beginning to adopt it – it’s very interesting to see how for some parents it can replace a website though given that I had thought that the website would be providing different information such as fees, session times and information about the nursery.

This particular parent says that the information shows on Google when you search for the nursery. In recent years Google has implemented a feature which shows basic information of businesses and attractions when you search for them, such as a location (shown on a map), opening hours and reviews. I hadn’t considered that this could also potentially replace an entire website, but thinking about it is easy to understand how it could potentially replace a website if all the user wants to find out is basic information. This information is available at just a glance too – there’s no need to try and navigate several menus or pages of a website to find this information if you want it.

The next question was about finding out why my users visited their child’s nursery. If I know what they went to the site for, I can tailor my site to fit these needs.

Generally there were a mix of reasons. interestingly, it seems that none of my users could think of any other reasons for visiting the site, so it seems my options were all applicable! Although 2 of my users said that they’d visited the website to receive information about their child (through a service like Tapestry or something similar) and to sign up to a newsletter, 6 of my users said that they’d visited the site to find contact details for the nursery (phone and email) and to find out more about the nursery. These were the main reasons why my users visited their child’s nursery website. Locating the nursery and finding out about features and facilities of the nursery were also quite popular options, but it certainly seems that the website needs to serve as a source of information and also provide contact details. Implementing a feature to send data back to parents might take time for this project and not be terribly necessary given that it seems that it is not all that important to users.

This data is all about what users would say is the most important information to find on a nursery website. Information on nursery fees came top here with 9 of the 10 respondents saying that this was one of the most important pieces of information they expected to find on a nursery website. Information on nursery facilities came a solid second and nursery news and events were also a popular feature with 7 of the 10 users saying they felt it was important. Interestingly, information on the nursery ethos and values, information on things like special needs support and admissions weren’t that important to my users with only 4 of them saying that they felt these were important. To them, information on their child’s daily routine and information on the staff was more important.

Victoria at Nellie’s Nursery wants there to be a lot more staff information on the site, however it seems that whilst half of my users said it was important, it’s not a headlining feature of a nursery website for half of my users. Time might be better spent on making sure that information on the nursery facilities and fees is very clear and easy to read if this data is anything to go by. I find it interesting how information on the ethos didn’t seem that important – perhaps it is too similar to information on daily routine so most people chose to select that option instead.

Coming up with a question about theming and visuals without asking the user ‘which do you prefer?’ and showing them two or three different designs to pick from. Sadly, I can’t do that with Microsoft Forms or any other survey engine I can think of. My tutor suggested that I ask which children’s book to theme the site around. It was a great idea – each book has unique illustrations and a unique style of illustration so asking which the users felt would work well on a nursery website would give me some idea about colours and illustration style.

The Very Hungry Caterpillar is one of the most popular children’s books of all time, so it is no wonder that it scored a swooping majority. Charlie and Lola and The Gruffalo are also very popular. This is an anonymous survey so I can’t give much data away about the users, but it’s interesting that they chose the modern children’s books over the classics like Room On The Broom and Where The Wild Things Are – most of the users who answered the survey were quite young.

The next question was asking what they felt the nursery website should look like. There’s no easy way to make this a closed question, so the easiest way to get an answer for this is to use an open question and ask the user to write their thoughts. The responses I got were:

Inviting and colourful.

Simple, bright.

Very bright and eye catching. With a lot of key information.

Simple, uncluttered and friendly.

Fun but professional.

Colourful, informative and uncluttered.

Inviting with an idea of what kinds of things my child may get to experience.

Easy viewing. Pictures of what the children do. Bright.

Catching with pictures of the nursery and all relevant information.

To be honest, none of these answers are a surprise – in fact they are very much welcomed! These are all the sorts of things that I would have expected and also that Victoria wants. As I’ve been saying for several weeks, the challenge of designing a nursery website from a visual perspective is trying to make it look friendly and childlike yet professional but certainly not corporate. The way to do is to use a mix of colours, illustrations and photos but use white containers to hold text and use a professional font for most of the copy text.

After talking to Tom Haczewski today and hearing how he is finding that increasingly more and more people are shunning traditional desktop and laptop computers for tablets and smartphones. This data really speaks for itself – 8 of the 10 people who completed the survey said that a smartphone was a device that they’d view the site on, so it is critical that it is responsive. Interestingly, desktops and laptops came higher than tablets in this sample at least – chances are that it’s laptops given that sales of desktops are pretty low and most people use laptops instead. There were no other devices that the user sample could think that they’d view the website on.

This is interesting. 90% of users felt that the website could be a link of communication between parents and staff. When I was writing this question I was thinking more from the perspective of a teacher could post information on the site (securely) about a child that their parent could see. This data could suggest that although most users didn’t really rate having some kind of system to allow parents and teachers to exchange information about the pupils on the website (as learned from question 4), 90% of the users feel that it could be possible. The question might well have been interpreted quite literally – perhaps it was interpreted in a way that made the question seem like it was about communicating basic information such as the location of the nursery, its opening times and nursery fees to the parents.

To summarise:

• It is useful having a website for the nursery.
• It needs to include information about the nursery such as the children’s daily routine, contact details, nursery fees, nursery facilities and news and events.
• Staff information, being able to view children’s reports and information on things like special educational needs support aren’t as important to my user sample.
• Any illustrations and themes should draw inspiration from The Very Hungry Caterpillar.
• It should look bright, fun, simple, professional and inviting.
• Mobile compatibility is a must, but the site must also look good on more traditional devices such as laptop and desktop computers.
• The website should act as a communication link between the nursery and parents.

Before I put this on Mumsnet to get more data, I want to make the following changes:

• I’d be interested to find out which web browsers people are using, that way I know which browsers to include for. The trend is that Google Chrome is the most commonly used web browser in the world with Firefox second. I’d expect my data to reflect this. Some browsers support different things, for example Firefox does not work particularly well with web animations without extra lines of code and Internet Explorer 11 has trouble supporting modern web standards such as Flexbox which means that any elements that are set to display as ‘flex’ may not be rendered correctly in Internet Explorer 11. If I know which browsers people are using, I will be able to better support them and decide if it is worth spending time making the site fully compatible with all browsers.
• I want to think about how I can reword question 8 to make it more obvious that the question is asking whether or not the website could be a useful tool to distribute information about children to parents – a little like what Tapestry already does.

I would really like to get a lot more data from Mumsnet. In an ideal world I’d love to get about one or two hundred responses, however I don’t really know how realistic that figure is. Now that I know that the survey only takes an average of 2 minutes to complete, I can entice Mumsnet users to answer it by informing them that it will only take a couple of minutes to complete (and of course really help me!)

Creating a clickable wireframe

Usually before I begin to make a prototype I draw some sketches on paper first so that I have a rough idea about what I am going to try and make, but I felt that this time I had an idea about what I wanted the first prototype to look like, so I jumped straight into it. When I was creating the prototype for my presentation two weeks ago, I based it on the Angels Nursery website because I felt it looked professional, yet fun and childlike at the same time. The information hierarchy is also pretty good and information is plentiful and clear and easy to read and find. I therefore based my clickable wireframe on this website’s general design too.

I started off by looking at the existing website’s information hierarchy and deciding that whilst there was a lot of information on some of the pages, a lot of it was repeated. I feel that repetition of information on a website is not ideal, so the aim with my design is to try and minimise repetition. I noticed that page on the existing website which details the various groups at the nursery especially have a lot of repeated information. Firstly, there is a separate page for each group and then on each page the session times, fee information, the eating arrangements, the rooms that the groups are run in and the staff who run them. It’s near enough the same for each group, so there is so much repetition here that can be removed. The session times also appear on the home page! My design focuses on minimising repetition by having the information communicated once, either in one page or at the top of a page, which makes the information easier to find and also in the event that it needs to be changed or updated, it only needs to be edited or updated in one place. I propose to have a ‘Meet The Team’ page which will have a photo of each staff member and underneath it a short description of who they are, what their specialism is and which groups they work with instead of having the photos of the staff members on a dedicated page for the group. Some staff work with multiple groups, so their photos currently appear on more than one page. I propose to just have a single page for the groups and the shared information (fees, eating arrangements and session times) at the top of the page. The page will be quite long, so to make navigating less of a chore I propose to have buttons at the top of the page to the different groups and then using anchor points, clicking on a group button takes you to the relevant part of the page (e.g. if you click on ‘Little Lions’ button, the page will scroll down to the ‘Little Lions’ section). These are two ways in which I aim to reduce repetition.

Next week I want to get users to test the information hierarchy, so over the the course of this week I will develop two or three high-fidelity prototypes in Axure, each with a different way of laying out information, and do a simple A/B/possibly C test to find out which layout my users prefer, then take this into the first evolutionary prototype which will be developed in the coming weeks. Later I will prototype different visual styles and designs and get users to test A/B/C prototypes of these. Using the feedback I receive from the information hierarchy testing and then from the visual style testing, I will be able to combine the two and make prototypes that take my user testing data as well as my user research data into consideration.

In previous blog posts I have mentioned why Axure is an ideal tool for prototyping. Axure RP 8 is industry-standard software that makes wireframing and prototyping simple by allowing you to drag common elements such as placeholder images, boxes and text onto a blank canvas to prototype your design. Using events, elements can be linked to one another to make the prototype interactive. I found that by using page masters (which you can drag and drop onto new pages to apply all of the assets to the new page) I was able to create a wireframe of a complete website prototype quite quickly and use case events to link buttons to pages to make the wireframe interactive. Below is a screen recording of the first wireframe of the website that I produced running in Google Chrome.

Axure allows you to publish your work to ‘AXShare’ which is their public cloud server. You can upload your work to AXShare and then give people a link so that they can look at your work in a browser. You can view my clickable wireframe on AXShare here.

As mentioned in my Designing for Function project which I completed over October and November 2017, a wireframe is not supposed to look pretty or really include any kind of colour apart from shades of white, grey and black. You use a wireframe to plot where your elements will go, get an idea of how it will all look, make changes as needed and then use the wireframe as a guide for building a prototype.

Tuesday 6th February 2018

Today I considered what I was going to do going forwards with my prototyping. I had thought about making high-fidelity prototypes on Axure and getting my users to test those next week since that would be quicker than trying to build several prototypes using code. Unfortunately, the project brief states that prototypes need to be evolutionary, so I do need to code my prototypes and then keep building on them to make future prototypes. I will begin doing this tomorrow (Wednesday 7th) and tonight focus on creating a mobile version of the clickable wireframe that I produced yesterday.

Real people (peers on my course) will be testing my prototypes and to get a different perspective I will get some of my other peers on other courses at university to test my prototypes too, but I will also develop a couple of user personas and use empathetic testing to consider how they might use the prototypes. As explained in the article I wrote about user personas and identifying pain points, very detailed and well-thought-out user personas are not a replacement for real human testers, but can give an insight as to how a certain person might use your product. They are especially helpful if the persona is completely different to any of your testers, effectively broadening your user test base.

I posted my survey on Mumsnet. I chose to post it on Mumsnet because it is of course a community filled with mothers and parents of children, many of whom will have children of the nursery age, or will be about to go into nursery. I hope to get a lot of data from Mumsnet providing that my thread is viewed often enough and that people complete the survey. Within three quarters of an hour of posting it in their ‘NFP Surveys’ section (NFP standing for ‘not for profit’), I had already received 2 responses from Mumsnet users, bringing my total up to 12 responses. To be perfectly honest, had I been able to make a small focus group of parents and staff at Nellie’s Nursery I likely wouldn’t have had as many as 12 members in it, so this is more data than I would have received had I set up a focus group, even at this point in time. I hope that soon more users see the thread and answer the survey. The thread can be viewed here.

There was no external speaker tonight, so I spent the evening creating a mobile version of my wireframe. Essentially it is the same as the desktop wireframe I created yesterday, but the information has been moved into a single column and the menu has been replaced by a collapsible hamburger menu. Some of the pages have become longer as a result of the information being moved into a single column, so although my wireframe does not have it I can see myself making the header sticky (or at least making stick at the top and get a bit thinner as the user scrolls) so that on a mobile device the user can easily access the navigation menu and move between pages without having to scroll all the way up to the top of the page again. See a video demonstration of my mobile wireframe below.

I have published this to AXShare here.

Wednesday 7th February 2018

Today I started creating the first prototype. I knew that I wanted to test information architecture and usability, so I decided to focus on making two prototypes, each slightly different and then do a simple A/B test on them to see which my testers preferred. Both prototypes were coded from scratch using Visual Studio to write the HTML, CSS and JavaScript code and then tested on several different devices in my home before being used for testing which will take place next Wednesday.

Today’s focus was on creating an index page that resembled the wireframes I had made previously. At the moment I’m only focusing on creating a desktop website and will add responsiveness later using media queries. When I last wanted to create a prototype I tried to use the Bulma framework but discovered that it had some interesting limitations that prevented me from being able to fully code the design I wanted, including an odd inability to be able to overlay divs onto images. I’ve decided not to really use frameworks again and instead just code from scratch for the following reasons:

• It’s better for learning – by coding yourself you are always learning new tips and techniques as well as new syntax and finding ways to resolve new problems, without relying on a pre-written CSS framework and simply typing a lot of pre-defined HTML out to piece a website together.
• It’s better for troubleshooting – not only is it easier to find out where errors are because your code is likely easier to read and understand than that of a framework’s and you wrote it so you should know exactly what does what and where things in your code are, it also helps you realise what the problem is and learn from it. Too often when I was using frameworks like Bootstrap, Bulma and even Furtive (to a degree) to write websites, I was getting errors and after spending ages looking through hundreds of lines of CSS (mostly endless classes) I found what the issue is, just though ‘hmm that’s weird’ and moved on without actually considering what the issue was. That’s because these frameworks are often so ‘proprietary’ that the CSS-related errors you’re going to get with them will often never apply to your own code, so why bother really considering what the issue was?
• You can be more flexible – you have a blank document (or two, or three!) and on that document you can write code that can render anything you want on the screen. With frameworks you are limited as to what you can do – you have to use pre-defined styles unless you spend hours modifying the framework to make it look like you like – that probably requires enough time and skill as coding from scratch does, so why bother?

With that established, I spent several hours this afternoon creating the index page which ended up looking a lot like my wireframe. The index page consists of a ‘feature image’ which is positioned underneath a container with rounded curved edges at the top. There are several paragraphs with a large title at the top of each to give some basic information about the nursery and there is also a slideshow showing some images of pupils at the nursery and its facilities.

The header and page navigation buttons at the top of the page are fixed so that the navigation buttons are always present. There is quite interesting psychology behind the accessibility of navigational buttons, apparently it has origins to the cavemen era and humans wanting to feel secure and safe in foreign lands! I wrote a little bit about the psychology of navigation in this reflective journal on January 16th, but the idea of it is that being cared for and feeling you are know what you are doing on a website is more important than many people take for granted. In Liraz Margalit’s article on ‘The psychology behind Web browsing’ she states that stress responses in the brain, similar to those felt by human ancestors when they were in a foreign environment, are triggered!

I’ve witnessed visitors start scrolling along a page and suddenly realize they don’t know where they are anymore. It’s a thoroughly modern phenomenon but it evokes the same fear triggers that our ancestors felt when they were in a foreign environment and suddenly didn’t know how far they were from home.

It’s interesting how closely web browsing can be related to the ancient parts of our brains that influence our behaviour. Margalit later goes on to say:

Our prehistoric ancestors used trail markers in order to not get lost. And websites that understand human psychology can also do something similar, employing sticky navigation – website menus that move with the page as the visitor scrolls, “sticking” in place and always remaining visible – to keep visitors feeling in control.

This is a very interesting concept that very few websites actually employ. Some users find navigation that ‘follows’ them down the page a little irritating, but think about news websites: usually they have a sidebar filled with articles which could possibly act as a reminder to the user as to their whereabouts on the website. For example, if you’re reading a news website and reading a political piece, it is likely that the other articles in the sidebar are also of the same nature. Little things like this could sub-consciously ensure that the user that they are not lost and know where they are.

By having fixed navigation at the top of the page, the user is always able to access another page (like an ‘escape route’) and therefore feel that they know which page they are on.

Creating the index page

The biggest challenge with creating the index page was actually always keeping the container positioned a certain distance away from the top of the page. The screenshots below show that no matter how big the browser is, the container always stays the same distance from the top of the page.

In the past I might have used code that looked a little like this (where ‘#featureimage’ is the image and ‘#textcontainer’ is the container containing the text that I want to place over the div).

#featureimage {
     position: absolute;
     top: 0%;
     width: 100%;
     z-index: 0;
}

#textcontainer {
     position: relative;
     top: 20%;
     width: 75%;
     z-index: 1;
}

This code would position the feature image underneath the container and position the image at the very top of the page and make it 100% of the page width. The container would be positioned 20% from the top of the page and consume 75% of the page width. The problem with this code is that 20% from the screen is different for different resolutions. 20% of a screen with a height of 1080 pixels is less than 20% from the top of the screen with a height of 1440 pixels so the container would be further down the page on the screen with a height of 1080 pixels than the one with 1440 pixels. 20% of a screen with a height of 768 pixels is even less than 20% of a screen with a height of 1080 pixels, meaning that the container would be even further down the screen. The ‘top’ (and also the ‘left’, ‘right’ and ‘bottom’ properties) CSS property is generally not very helpful unless you need to position items 0% or 0px from the screen edge.

The solution is to set ‘top’ to 0 and then use a ‘margin-top’ to set a margin from the top of the container that the ‘textcontainer’ element is held in (the entire website is held in a container simply called ‘container’). This way, the ‘textcontainer’ element is always positioned at the top of the screen, but there is always a set margin [of 20% in my example] that means that no matter what size the browser is or what screen resolution the website is running on, that element is always 20% from the top of the screen. It’s a nice enough work around and quite logical when you think about it.

The next thing to implement was the slideshow that is present in my wireframe. Last week my course tutor ran a short tutorial session of Siema which is an open-source JavaScript, CSS and HTML slideshow framework. I know that I vowed to not use frameworks again, but there is no really easy way to implement a slideshow I didn’t know how to code my own. The internet is awash of slideshow tutorials and I have tried many of them in the past with varying degrees of success (I still don’t understand where there is not a HTML 5 control for slideshows, they are so common that it seems that it would be logical to have some basic slideshow functionality built into HTML 5 in this day and age), but Siema is by far the best slideshow framework I have used.

Siema is simply a JavaScript file that you download and link to your HTML page and by writing your own short piece of JavaScript you basically toggle through images held in a div. Siema is touch-optimised and by default does not advance slides (the user either needs to click and drag slides to the left or touch and drag slides to the left to advance the slide) but it does have previous and forwards buttons for those on non-touch devices. The buttons are just simple HTML buttons (so you can apply your own button class styling to them, like I did) and are defined in the same div that the source of the images are. Styling and positioning the Siema slideshow can be done easily in CSS by simply putting the Siema slideshow in its own ID or class and then applying styles to that ID or class as you would with any HTML element.

Victoria made a point about making sure that the site remained ‘homely but professional’. A lot of nursery websites use ‘fun’ and handwriting-like fonts on their headers, so I did the same for Nellie’s. I found a font called ‘Child’s Play’ which is easy to read (for a header, you wouldn’t want to write paragraphs in it) and looks like a child’s handwriting – quite fitting for a nursery I feel (the idea being that a nursery is somewhere you send your child to learn these skills). The trouble with using custom fonts on a website is that they’ll only display on client machines and devices that have the font installed. Child’s Play is not a font that is included with any operating systems to my knowledge, so in order to get it to display on any device the font files need to be saved in the website directory and then read by the website. This is done using CSS using ‘font-face’ – you define a new font and then set the font file as the font source. By including *.ttf (TrueType Font), *.eot (Embedded OpenType) and *.woff font files in the website directory, virtually any browser can read at least one of these font files (generally Chrome and Opera can read *.ttf, Firefox and Safari *.woff and Internet Explorer *.eot) meaning that browser compatibility is improved. The fallback font is Arial – this font will be displayed in the event that the browser cannot read one of the font files.

Below is the CSS code to define a font and set its sources in the web directory so that the font will be loaded on any device.

/*Font*/
@font-face {
    font-family: "Childs Play";
    src: url(../fonts/child.ttf) format('truetype');
    src: url(../fonts/child.eot) format('embedded opentype');
    src: url(../fonts/child.woff) format('woff');
}

Which is exactly the same way you set any other font.

By the end of today I had made a basic first prototype that contained the feature image, container, slideshow and some CSS rollover effects on the menu button to change the colour and font size to enlarge the button (a little like the basic prototype I made two weeks ago for my presentation). Below is a screen recording of the prototype as of Wednesday 7th February at 11.10pm after working on the prototype all afternoon and evening. The site is not responsive at this point.

Thursday 8th February 2018

Focusing on the tiles shown in my wireframe was today’s task. Before I did that though I delivered a presentation to my peers outlining the stage I was at and where I was headed with my work. We each had to do a presentation like this just to find out where everybody else was at and also give an opportunity to see what other people are doing, critique work, get feedback and ask questions. It turns out that I am at about the right stage which is partway through a prototype.

I started my presentation by showing some of the data that I collected last week from my survey, explained what it meant and what it means in terms of how the site will be designed, a little like I did at the beginning of this blog post. I then went onto show a quick video of the Angels Nursery website which my site draws design inspiration from and explained why I liked that particular nursery site and why I was using it to base my work on. This was followed by a video of the basic prototype that I made using Bulma to show my peers the first stage of my prototyping and then by the videos of the Axure wireframes which are also in this blog post to show my peers the wireframes. As these videos were playing I was explaining how I made the content that was being shown and my design choices and inspirations. Finally, I showed the video of my current prototype shown above to show my peers where I was. I explained that the next stage was to make the prototype responsive to fit the project brief and of course my user research data which shows an overwhelming percentage of my sample size prefer to view websites on mobile devices. The presentation was well-received with the only comments being some small concerns about font loading times, but I explained that the font files were so tiny (usually under 30KB) that they had no measurable impact on page loading time.

Initially when I thought about making tiles on the website I had hoped to give Bulma one last try by basically taking its tile element CSS and HTML and implementing it into my own website. Unfortunately, due to the nature of how Bulma’s CSS is laid out and the time I had (not a lot – I have to make an A and B prototype, both fully responsive, by Wednesday next week for the first round of user testing!) I didn’t completely accomplish this. It’s a bit of a shame because I liked and used Bulma’s tiles in my Bulma prototype because they look attractive and scale perfectly on mobile devices. It is likely that when I copied the code that creates tiles from Bulma’s CSS to my own I missed out some vital classes (wouldn’t surprise me, Bulma is full of classes) that meant that the elements were not rendering correctly, but I couldn’t figure out which classes I was missing and so I went on pursuit of creating my own tiles framework.

I looked online and found W3 School’s tutorial on flexbox. Flexbox is something I have touched on before – when I first looked at Bulma, in fact. Bulma is made up of flexbox elements, that’s why it’s so responsive without the need for lots of media queries. When I was first writing about Bulma, I said the following about flexbox: The benefit of using Flexbox is that it provides better arrangement for elements on a webpage that behave in a predictable mode. It does this by accommodating elements inside of flexible boxes which ensures that every element on the webpage is displayed perfectly on any screen resolution – meaning that no matter what device is being used the site will display perfectly. Flexbox has been around for nearly 5 years now, but has only recently been adopted by web developers, mainly because it is incompatible with older web browsers which a lot of users were still using when Flexbox was first introduced in 2013. Microsoft Edge 13, Mozilla Firefox 44, Google Chrome 48, Safari 9 and Opera 34 were the first browsers that had complete support for Flexbox with older versions of these browsers not fully supporting it. Microsoft Internet Explorer 11, released in October 2013 with the release of Windows 8.1, is only partly compatible. Microsoft Edge 13 was not released until May 2015.

All of that still stands, so using the CSS flexbox module seemed an ideal way to make my own tiles. The code is very simple. Whilst researching how to make tiles I learned that ‘masonry’ is the name of the technique of display information on a website in tiles, so I called my flexbox class ‘masonry-container’ and my own framework ‘masonry’. The class is written in HTML of course, but first the CSS.

.masonry-container {
     position: relative;
     width: 100%;
     display: flex;
     flex-wrap: wrap;
}

The class is 100% as wide as its parent container and by setting the display to ‘flex’ and then setting the ‘flex-wrap’, the container will use the flexbox module and become responsive without the need for media queries.

Then I made some additional classes.

/*Default styling for all tiles, additional properties can be added using the CSS classes below*/
/*Example: <div class="masonry green width60 one-col> makes a green tile, 60% wide and one column*/
.masonry {
     color: #FFF;
     display: inline-block;
     border-radius: 25px 25px 25px 25px;
     padding: 15px 15px 15px 15px;
     margin: 10px 10px 10px 10px; 
     text-align: justify;
}

.masonry.green {
     background-color: #aed2a7;
}

.masonry.yellow {
     background-color: #fbc477;
}

.masonry.six-col {
     flex: 6;
}

.masonry.ten-col {
     flex: 10;
}

There are more, but these are just some examples. As said in the comment in the code snippet above, to apply a style in one of the classes I defined simply use the class names in the div tag in the HTML. By display the individual tiles as an inline-block but the container that they are in as flex, the tiles will fill up the container meaning that they automatically ‘snap’ next to each other’ and create a grid (which is what I’m after) rather than just appear on top of each other.

Another thing to note is that the flexbox specification has some odd guidelines about margins and padding. The margins and padding always resolve around the longest edge of each ’tile’, meaning that using percentages for margins and padding values does not work in all browsers. The exception is Google Chrome which ignores this rule. To get around this and use margins and paddings in flexbox without calculating percentages based on edges, use pixels to determine margin and padding distance instead. This works in all the major browsers.

I reason I chose to make the classes I did was to keep in-line with the Nellie’s Nursery branding. The logo features a green elephant and a yellow/orange elephant. The exact colour code of the green elephant is #ae2a7 and the colour code of the yellow elephant is #fbc477, so the buttons are these colours and so are my tiles. I feel that branding and maintaining consistent branding and theming across the site is important as it gives the site identity.

The HTML is quite simple, below is a sample.

By naming the div class ‘masonry green six-col’ it is using the ‘masonry’, ‘green’ and ‘six-col’ classes defined in the CSS, so the formatting of the text and the element itself is taken from the ‘masonry’ class (which holds the ‘default’ styling), then the properties in the ‘green’ class is applied, then the properties in the ‘six-col’ class is applied. So, the tile is six columns wide, is green and has all of the other styles in the ‘masonry’ class applied (the font, the padding and so on). The next tile is yellow and ten columns wide and so on.

The result is this:

These also scale to different screen resolutions, of course.

The reasoning behind using tiles to hold information is that it makes information bold and clear to see. It looks a lot more interesting than simply having a table or simply writing paragraphs. Using tiles to store information also encourages you to be concise in your writing. You don’t want massive tiles, so you deliberately try to write concisely and only put little bits of information in them. The bold colours, interesting design and the small of information in the tiles draws the viewer to the tile to consume the information and it is less-likely to be skipped. A viewer might see a paragraph of text and just skim read it or not read it at all.

Browser compatibility with these tiles is generally good. It works in all of the latest versions of the major browsers and it even works fine in Internet Explorer 11. Internet Explorer 11 is now over 4 years old so as a result it can be incompatible with more modern web technologies (like flexbox) and its market share is slumping, but it still needs to be considered at this point in time. Soon it won’t be considered at all, but there is still a small market using it (those on operating systems older than Windows 10 who insist on using Internet Explorer, mainly), so sites still need to be tested in it.

Amazingly, the flexbox tiles even work in Internet Explorer 10 even though Internet Explorer 10 is not thought to be compatible with flexbox. The screenshot below shows the prototype running in Internet Explorer 11, but with the document mode changed to version 10 and the Internet Explorer version being emulated changed to 10 – so the site is running as it would in Internet Explorer 10. Internet Explorer 10 was first released with Windows 8 in 2012 and is an old browser with little market share.

In Internet Explorer 9 and older the tiles are displayed, but they are stacked on top of each other and not side-by-side due to the browser lacking support for the ‘flex-wrap’ CSS property. Internet Explorer 9 was the first version of Internet Explorer to support CSS 3, but it does not support all of it. Internet Explorer 9 was first released in March 2011. The only reason for using it in 2018 is if you are using Windows Vista and are intent on using Internet Explorer as 9 was the last version of Internet Explorer to work on Windows Vista – but both of these products have insignificant market share now and are unsupported, so Internet Explorer 9 compatibility is not an issue.

Friday 9th February 2018

There are currently two things missing from the prototype: one is content, at the moment there is a lot of Lorem Ipsum and placeholder images (of my cousins) and the other is responsiveness. With the exception of the flexbox tiles, the site is not responsive at all. To make the site responsive, today I wrote a separate stylesheet filled with media queries to make the site responsive. I’ve touched on media queries several times before, the first being in October 2017 when I tried it with little success to make a responsive website and the other being the other week when I mentioned that I was using media queries to make the Storehouse magazine website responsive. Using the media query stylesheet I wrote for the Storehouse site I was able to start writing media queries for this website.

This is where wireframing is important. The great thing about having the mobile site wireframe that I made was that I was able to have a guide to work to, so I was able to visualise how the site should look on a mobile device. Basically, all of the columns should squash down into one and then something needs to be done about the navigation on mobile devices. The wireframe I made for mobile devices suggests that I use a hamburger menu which at this point in time is considered the ‘obvious’ or ‘traditional’ way to handle navigation on mobile devices, but upon reading some articles on two different UX websites I learned that some UX professionals do not advocate using them.

UX Planet says the following about the hamburger menu:

When it comes to controversial UI, the hamburger navigation pattern has had its fair share of criticism, dismissed as everything from ‘mystery meat’ to ‘the devil’.

They then go onto the talk about alternatives even suggesting quite alternative and radical ideas such as navigation bars with vertical lettering and links in each of the four corners of a page as well as some more conventional ideas such as tabbed navigation, progressively collapsing menu, menu bars at the bottom of webpages and/or phone apps and finally a hamburger menu with the word ‘Menu’ written in the toggle button rather than the three lines icon that most of us have become used to seeing.

The main concern about the hamburger menu seems to be that ‘navigation that is not made obvious to the user is not good’, meaning that because the hamburger menu hides items away from the user so the user may not know that there are items to see and pages to navigate to. Furthermore, the hamburger icon itself is often criticised for not being particularly obvious, hence why UX planet recommended using a button with ‘Menu’ written in it to activate the menu rather than the traditional hamburger icon.

TechCrunch is not a big fan of the hamburger menu. They say that various testing including interaction theory, A/B testing and the evolution of popular mobile apps has proven that ‘the hamburger button is bad for engagement, and you should probably replace it with a tab bar or other navigation scheme.’ They say that ‘what is out of sight is out of mind’ and explain this by saying:

Any navigation options you hide behind the hamburger will be forgotten, or at least used a lot less. It doesn’t help that the button is often placed in the top left corner — the hardest place to reach when using the phone with just your right hand.

They make a very valid point about ergonomics too, given that most people use a smartphone held in one hand and use just one thumb to operate the phone. It therefore does seem to make sense to place the buttons at the bottom of the phone – after all, that’s why hardware manufacturers put physical buttons (or software buttons more and more in this day and age with current phone design trends like the Samsung Galaxy S8 and the iPhone X). TechChrunch goes on to make a good point about efficiency too and the number of clicks required to even access a menu to move to another page or screen (the point is tailored more at smartphone apps, but is valid for mobile websites too).

Hamburger buttons are less efficient, since you have to tap once before you’re even allowed to see the option you want. They clash with the navigation patterns of many mobile apps, forcing you to swipe or ‘back’ through multiple screens just to arrive at the hamburger button. And they’re less glanceable, preventing you from seeing notifications about specific areas of an app such as notifications, messages, or new content without first opening the side menu.

TechCrunch feels that the hamburger menu is still a popular choice because it is ‘an easy way to cram a ton of functionality into an app. They’re especially tempting if you’re trying to translate a full-featured web app into a mobile one. But in the end, they obscure what’s special about your product.’

They suggest using a navigation bar at the bottom of the screen instead and though they appreciate that it does take a small amount of screen estate, they are more practical because they are better ergonomically, remind the user of the pages available to visit, only requires one tap to navigate between pages and use an A/B test case study from the mobile app Zeebox to demonstrate that by going from a hamburger interface to a menu bar interface you can increase user engagement. Zeebox found that running an A/B test on both menu systems resulted in the fixed menu bar at the bottom of the screen rendering a 55% average weekly frequency of use increase and an 8.7% higher average daily frequency than the hamburger menu did. It seems that a menu bar at the bottom might be a great way to increase user engagement and make using the website a more pleasurable experience.

When you think about it, it seems logical to emulate what the big mobile apps are doing. Facebook, Instagram and Twitter are just a few examples of mobile apps that are now using fixed navigation buttons at the bottom of the screen. If it’s working for them, then surely using it on the mobile version of my website would be a good design strategy?

The ‘hamburger debate’ (as I like to put it) will probably never end. On one hand the hamburger increases screen estate, hides potentially untidy menus and is so commonly used these days that most people know what the icon does (or if not, they’re bound to click on it out of curiosity and find out). On the other, the menu bar requires fewer clicks, is always visible to the users and the ‘big names’ are starting to use it more. Interestingly, Terika Seaborn-Brown from Foolproof told us that she did not like the hamburger menu and icon when she visited us about a month ago to deliver a presentation on research. She had found in her personal research that people did not always understand how to activate the hamburger menu or what it was for.

All of this gave me food for thought. I originally had intended to make the mobile site use a hamburger menu, mainly because I couldn’t really think of any good alternatives. But after doing some research and thinking about what smartphone apps today are doing, I decided that I’d make one mobile site with a hamburger menu and the other with a fixed menu bar at the bottom of the screen and then get my users to A/B test them as part of the prototype testing next week, maybe even use eye tracking to see which was the most successful.

The current responsiveness of the website

The current site is a bit odd when it comes to being responsive. When viewed in a desktop browser it is not responsive at all – as the browser window is resized it does not respond to the change at all. However, when viewed on a physical mobile device (smartphones only though, on a tablet like an iPad the desktop site is shown) a more mobile-orientated site is displayed. The existing site is made with Wix so it is likely that Wix is using some kind of meria query to only display a mobile layout when the physical device width and height is detected as being ‘in-bounds’ rather than just detecting a change in screen resolution. The video below shows the differences between responsiveness on a desktop browser and in a mobile browser.

 

 

Creating the mobile website prototype

Creating the mobile site itself involved using media queries to define properties of certain elements at various screen resolutions. I identified the following elements would need to be responsive:

• Menu buttons: they need to be large on high resolution displays and positioned to the right of the screen. As the browser window or screen resolution reduces, they need to gradually get a bit smaller (but not stack on top of each other, remain next to each other in a line) until eventually they need to disappear and turn into either a menu bar fixed to the bottom of the page, or a hamburger menu icon in the top right of the page.
• Header: it needs to remain fixed on the mobile prototype with the hamburger menu so that the user can always access the hamburger menu without having to scroll up the screen. It needs to remain present but not be fixed on the prototype with the fixed menu bar to help increase screen estate.
• Feature image: it needs to essentially remain fixed and always have a decent proportion of the image visible. As the resolution or browser window gets smaller, it needs to shift slightly down the page so that it doesn’t go too far underneath the header and become partly hidden.
• The container: it needs to get wider as the screen resolution or browser window gets smaller. By default it is 75% wide but as the resolution shrinks that needs to become closer to 100% so that the text can be more easily read on mobile devices (and not squashed in the middle of the device screen with wasted screen space on each side).
• Text: needs to become slightly smaller as the screen resolution or browser window gets smaller so that more lines of text can be displayed on smaller and/or lower resolution devices, reducing the need for scrolling.
• Siema slideshow and other images: the width needs to always be set to 100% meaning that it is as wide as the parent container that it sits in. The height of the images needs to be proportionate to the width at all times, so it needs to be set to auto. This will make it responsive without using media queries.
• Tiles: these need to eventually stack on top of each other, flexbox takes care of this so no media queries are required.
• Footer: this needs to just be set to 100% page width at all times, if so it will be responsive.

With this considered, I was able to start creating some breakpoints in the media query CSS code to alter properties of elements depending on screen resolution. There is of course another stylesheet that has all of the ‘default’ properties of these elements.

The first prototype I made features the static menu bar at the bottom of the screen.

/*Screen resolution breakpoints*/
@media only screen and (min-width: 1100px) and (max-width: 1170px) {
    .button {
        margin-top: 3%;
        font-size: 12px;
    }
}

@media only screen and (min-width: 1000px) and (max-width: 1100px) {
    .menu {
        margin-top: 5%;
    }

    .button {
        width: 100px;
        height: 45px;
        font-size: 12px;
        padding: 0px 0px 0px 0px;
    }

    .button:hover {
        font-size: 13px;
    }

    #textcontainer {
        width: 90%;
    }
}

The code above is CSS media query that has two breakpoints in it. The first specifies that if the resolution width is between 1100 and 1170 pixels, the button margin from the top of the page is set to 3% and the font size changes to 12 pixels. This makes the buttons slightly smaller and to account for that, the margin from the top is adjusted to keep the buttons positioned in the centre of the header area.

The second breakpoint specifies that if the screen resolution width is between 1000 and 1100 pixels, the menu (which is the class that contains the menu buttons) is positioned 5% from the top of the screen to keep the menu in the centre of the header area, the button width changes to 100 pixels, the height to 45 pixels, the font size to 12 pixels and the padding from the button is removed. This makes the buttons smaller by removing the padding, more text can fit in the buttons. When the user hovers over a button, the font size will change to 13 pixels. The width of the container is also changed to 90% to make it cover more of the screen area and make better use of the screen space available.

The next media query is a little more interesting.

/*Display bottom menu, make font smaller, move feature image down the page*/
@media only screen and (min-width: 600px) and (max-width: 1000px) {
    h1 {
        font-size: 50px;
        text-align: left;
    }

    p1 {
        font-size: 20px;
    }

    #header {
        position: absolute;
    }

    .menu {
        visibility: hidden;
    }

    #featureimage {
        top: 0;
        padding-top: 15%;
    }

    #textcontainer {
        width: 95%;
    }

    .bottommenu {
        visibility: visible;
        text-align: center;
    }

    .button {
        width: 90px;
        height: 45px;
        font-size: 12px;
        padding: 0px 0px 0px 0px;
    }

    .button:hover {
        font-size: 13px;
     }
}

This media query does the following things if the screen resolution width is between 600 pixels and 1000 pixels:

• h1 text: reduce the font size to 50 pixels and align the text to the left. Previously, h1 text was 60 pixels large and justified but on mobile devices large text is easier to read (and looks better) if it is not justified.
• p1 text: reduce the font size to 20 pixels.
• Header: change the position to absolute so that the header is no longer fixed, thus increasing screen estate and making the best use of available screen space.
• Menu: set the visibility to hidden – it is no longer needed as the mobile navigation menu is activated.
• Feature image: move the feature image so that it is now 15% from the top of the page to keep most of the image in sight.
• Text container: increase the width to 95% to make the best use of the available screen space.
• Bottom menu: make it visible and set the text alignment to center so that elements are centred. This is the sticky bottom menu bar that replaces the menu bar at the top of the page.
• Button class: change the width to 90 pixels, the height to 45 pixels, the font size to 12 pixels and remove all padding to make the buttons smaller but still contain the same amount of text.
• Button class hover: set the font size to 13 pixels.

From here on, the only real change is that the button size gradually gets smaller and the feature image is moved further down the page as the screen resolution decreases. The other breakpoints are between 400 and 600 pixels wide and 0 and 400 pixels wide.

The static menu bar is simply a div class called ‘.bottommenu’ which contains exactly the same buttons as the regular ‘.menu’ class does, only the buttons don’t have text in them – they have icons instead – and it is positioned at the bottom of the screen and is fixed. It also only appears if the screen width is 1000 pixels or less.

For a video demonstration of the responsiveness of this prototype, watch the video below.

I uploaded this prototype to my student web space and tried it on my brother’s iPad 4 from 2013. Interestingly, on an iPad when viewed in portrait mode the menu bar at the bottom of the screen is visible, but in landscape mode the desktop site is shown. I think this is quite good as it gives the user the option as to which site they use and actually in landscape mode on a device like an iPad the menu bar at the bottom doesn’t make much sense, but in portrait mode it works nicely. This five year iPad has no problems running the site, but it does have the latest iOS and Safari installed on it.

Challenges and problems

There were two major challenges with this. The first was identifying the breakpoints to use. Sadly, there is no tool to tell you what resolution your browser is running in, so I had to make do with running the page in Google Chrome’s responsive mode, making a note of the resolutions I noticed bugs or ‘ugliness’ at and at first guess the resolution breakpoints, code it, then test it to see how it looked and try again. I got it pretty accurate first time, but for a long time there was an annoying bug with the menu where between 851 and 896 pixels wide and 1171 and 1215 pixels wide the buttons would be too big and temporarily move out of the header area and onto the feature image (because they hit the logo in the left corner, so the browser automatically shifted them down). Eventually I was able to fix this modifying screen resolution bounds and I kept on doing this until I got the bounds correct and perfect. It took a lot of time and patience. I also fiddled around a bit with the button size to help fix this.

The other problem was coming up with icons for the buttons. The home and contact pages were easy to come up with icons for – a home icon speaks for itself and the telephone icon for a contact page is hopefully so commonplace now that people know what it is, but the others were harder. For the ‘Day-To-Day’ page I really couldn’t think of anything that was in my mind 100% logical or obvious, so I just went for a baby’s face hoping that it seemed more relevant than logical. The groups one I chose to use a giraffe icon for given that one of the groups there is called ‘Jolly Giraffes’. The ‘Meet The Team’ page has an icon showing a group of people which I felt was fairly logical and the parent’s area has an icon of a parent next to a child – it seemed logical enough. I think user testing next week will likely reveal that my users don’t know what all the icons mean or might guess wrong and that a label or something is required, so it is possible that in usability testing the hamburger menu might come out superior. But, I will be getting my users to test the systems on mobile devices and I think they’ll agree that the menu bar at the bottom with its fixed position at the bottom of the screen right by where their thumb that they’re using the operate the handset with will make the menu bar come out on top in ergonomics.

Saturday 10th February 2018

A bonus day! I did a lot of work today so it is worth recording it here. I do often do a lot of work for university over the weekend, often it goes undocumented or is written up in the Friday of the current week’s post or in the following Monday’s.

Today I took the prototype that I created yesterday, removed the menu bar and added a HTML/CSS/jQuery hamburger menu to it to make the ‘B’ prototype for testing. I found a simple yet effective hamburger menu example on CodePen.io and modified it to make it suitable for my website. The example works by putting the menu items in a simple div class and using jQuery to toggle this div class. The hamburger and cross icons are just lines defined in CSS code, so there are no images to load. The example CSS code is quite long because a lot of different classes and hover states for the text and buttons in the hamburger menu are defined, but I deleted most of this code and instead used my own button class to hold the menu text. That way I maintain the button styling, button sizes and all of the media query that I wrote for the previous prototype (the two prototypes share very similar media query code – they have the same breakpoints so they respond in exactly the same way). The only changes I made was changing the button radius so that only the corners on the left of the button were rounded and changing the button width to 100% so that the button consumed 100% of the hamburger menu.

In the end, the only code for the hamburger menu is the following CSS (in its own separate CSS document at the moment) that defines its styles:

/*Menu properties and formatting*/
.menu {
    z-index: 1000000;
    font-weight: bold;
    font-size: 0.8em;
    width: 100%;
    background: white;
    position: absolute;
    text-align: center;
    font-size: 12px;
}

And in the main stylesheet for the prototype there is just the code that creates the buttons. These classes are just for creating the icons – not the actual hamburger menu itself.

/*Hamburger menu buttons, only visible on mobile*/
/*Hamburger button class*/
.hamburger {
    background: none;
    position: absolute;
    top: 0;
    margin-top: 5%;
    margin-right: 3%;
    right: 0;
    line-height: 45px;
    color: black;
    border: 0;
    font-size: 2.8em;
    font-weight: bold;
    cursor: pointer;
    outline: none;
    z-index: 10000000000000;
    visibility: hidden;
}

/*Cross button class*/
.cross {
    background: none;
    position: absolute;
    top: 0px;
    margin-top: 5%;
    margin-right: 3%;
    right: 0;
    color: black;
    border: 0;
    font-size: 5.8em;
    line-height: 65px;
    font-weight: bold;
    cursor: pointer;
    outline: none;
    z-index: 10000000000000;
}

Like the static menu bar on the other prototype, the hamburger icon is activated using media query and is activated when the screen width is 1000 pixels wide or less. To activate the hamburger menu, the .hamburger and the .cross classes are made visible using media query in all breakpoints where the screen width is less than 1000 pixels wide. In this prototype, .menu is the class that holds the hamburger menu links (in the other prototype, .menu is the menu bar at the top of the page) and .menubar is the menu bar that is only visible when the screen width is over 1000 pixels wide. The .menubar class is hidden when the hamburger menu is made active.

There is a small amount of JavaScript which relies on jQuery. All this does is show and hide the .menu class (the hamburger menu) and animate the transition.

$(document).ready(function () {

    $(".cross").hide();
    $(".menu").hide();
    $(".hamburger").click(function () {
        $(".menu").slideToggle("slow", function () {
            $(".hamburger").hide();
            $(".cross").show();
        });
    });

    $(".cross").click(function () {
        $(".menu").slideToggle("slow", function () {
            $(".cross").hide();
            $(".hamburger").show();
        });
    });

});

That’s all there really is to the hamburger menu prototype! The video below shows this prototype in action.

Challenges and problems

There weren’t that many challenges or problems associated with creating this prototype. It uses the same codebase as the previous one, so already my work is evolutionary. Since it uses the same codebase, a lot of the problems with breakpoints that I had last time had already been solved for this prototype. The biggest challenge was actually changing the size of the hamburger and cross buttons in CSS to make them a look similar, a rather minor and easy to fix problem really.

When I was recording a video showing how the prototypes performed on different devices, I found two bugs with the hamburger menu:

• On most 720p and 1080p mobile devices, when the device is in landscape mode and the hamburger menu is activated, not all of the elements in the menu are shown.
• On larger devices like an iPad, if you have the device in portrait mode and open the hamburger menu, then rotate the device to landscape, the hamburger menu goes away and the menu at the top returns, but the cross to close the hamburger menu remains present.

Both of these are very easy to fix. The first issue can be fixed using media queries to detect the device orientation and adjust the size of the buttons as appropriate (to make more appear on the screen) and the second issue is just a case of setting the visibility of the .cross class to hidden when the screen resolution is 1000 pixels or higher.

 

 

Device compatibility

Asides from the two bugs mentioned above, compatibility of both prototypes is generally very good. Watch the video below to see how the prototypes perform on an Apple iPad 4, a Nokia Lumia 925 and a Nokia Lumia 930. These are all fairly dated devices but all still work fine with my prototypes, even the Lumia 925 which is 5 year old hardware and is running software of around the same age!

Testing the prototype on physical devices in both portrait and landscape modes gave me an opportunity to find bugs that I otherwise would not have done. It was also an opportunity to see how the site felt to use on a real device – I could see for myself if the design of the site was suited to swiping and how the page performed on actual hardware. Testing responsiveness by dragging the browser window is good for testing portrait responsiveness, however to test landscape responsiveness and how the site actually feels to use in practice, there’s no better way to do it than try it on a physical device.

End of week thoughts

It’s been a very busy week indeed, however at the time of writing I feel that I am a good position. I have the bases for my two prototypes created, both are fully responsive (with only a few bugs to fix) and I should have two prototypes to test for my A/B testing session on Wednesday 14th. I do enjoy coding and have really gotten into responsive web design using media queries – I really love them! As ever, I have learned a lot and can use the skills that I have learned this week to develop other websites and side projects, such as the Storehouse Online magazine website for university and continuing with development of Inspix with my friend Emma which has been on hold over the past few weeks whilst she has been completing work for her deadline which is next week.

Going forwards…

With the base prototypes completed, now it’s time to add content and consider different ways I can display information on the prototypes to test information architecture and it’s also time to really think about exactly how I am going to run the prototype testing. I need to think about if I am going to set the testers goals to complete. if or how I will guide them, whether the test will be done on a desktop device or a mobile one and what I really want to get out of my testing. I also need to consider how I am going to measure my results. At the moment all I really know is that one prototype will be using the static menu bar at the bottom and the other the hamburger.

Those bugs also need to be fixed but that won’t take long. I also need to add some content to the prototypes and make a few of the other pages work.

Next week I also be looking at the data I’ve managed to collect by posting my survey on Mumsnet and seeing what additional data has been collected to shape the development of the prototype.

Bibliography

W3schools.com. (2018). CSS Flexible Box. [online] Available at: https://www.w3schools.com/css/css3_flexbox.asp [Accessed 8 Feb. 2018].

Wagner, C. (2016). What is flexbox and why it is going to change forever the way web applications are developed. [online] Medium. Available at: https://medium.com/@carlos.afw/what-is-flexbox-and-why-it-is-going-to-change-the-way-web-applications-are-developed-7362ffd70e14 [Accessed 6 Jan. 2018].

Cao, J. (2018). 14 Design Psychology Articles for UX Practitioners. [online] Studio by UXPin. Available at: https://www.uxpin.com/studio/blog/14-design-psychology-articles-for-ux-practitioners/ [Accessed 16 Jan. 2018].

McConell, I. (2018). How Bad UX Makes Users Blame Themselves. [online] Studio by UXPin. Available at: https://www.uxpin.com/studio/blog/bad-ux-makes-users-blame/ [Accessed 16 Jan. 2018].

Margalit, L. (2015). The psychology behind Web browsing. [online] The Next Web. Available at: https://thenextweb.com/lifehacks/2015/06/09/the-psychology-behind-web-browsing/ [Accessed 16 Jan. 2018].

UX Planet. (2017). Alternatives of hamburger menu – UX Planet. [online] Available at: https://uxplanet.org/alternatives-of-hamburger-menu-a8b0459bf994 [Accessed 9 Feb. 2018].

Constine, J. (2014). Kill The Hamburger Button. [online] TechCrunch. Available at: https://techcrunch.com/2014/05/24/before-the-hamburger-button-kills-you/ [Accessed 9 Feb. 2018].