As mentioned earlier, I found that using the Bulma message box element has uses other than showing a message, in this example I’m using three separate message boxes to display the suspect, the weapon and the room that the user has selected. By placing each message box element inside a separate column, it’s possible to display these message boxes next to each other when the screen that the site is being displayed on is in a landscape orientation and the screen resolution is high enough to display the elements side-by-side. Viewing the site on a mobile device, resizing the browser window or changing the display mode in the browser to a mobile device shows that when viewed in portrait orientation on a mobile device, the elements are rearranged using Flexbox to be underneath each other, but the size of the actual elements does not change. This is all coded in Bulma’s CSS.

The items that the users can select are displayed beneath the message boxes at the top of the page which contain the image of the item that the user has selected and the text for the item that the user has selected.

Beneath the bottom row in the screenshot above is another row showing the rooms that the user can select.

The HTML code for the items that the user can select is the following:

The code above displays the first five items in the ‘suspects’ section. The code is exactly the same for the sixth item in the section and also the items in the weapons and rooms section. The code is fairly simple, each item is placed in a div and inside each div is an article class which contains the subtitle text (simply the name of the suspect, weapon or room) and the image of the item is stored in a figure class. The figure class for each image is in a class called ‘3by4 grayscale’, meaning that the aspect ratio of the image is set to 3:4 (the source images are also 3:4 so that it displays properly) and all colour from the image is removed to make the image greyscale. The ‘is 3by4’ class is a default Bulma class, however the grayscale bit is a piece of custom CSS code, shown below.

Using CSS filters, the grayscale ‘percentage’ of the image is set to 100% when this class is applied to an element. Think of the ‘grayscale percentage’ as saturation – if it were set to 50% the image saturation would be half that of the original source image. The ‘-webkit-filter’ line allows it to be compatible with most browsers compatible with webkit filters and the ‘-moz-filter’ line ensures that this feature is displayed correctly in Firefox and other browsers based on Mozilla source code (such as Pale Moon). The ‘transition: all 1s ease;’ line gradually desaturates the image over the course of a second.

I also made a class called ‘colourscale’ which is the same as the ‘grayscale’ class, except the grayscale percentage is set to 0% meaning that the images are fully saturated.

That’s it for the HTML, the JavaScript is where it becomes slightly more technical.

When the user clicks on an item, the image, name of the item and the description are shown in those message boxes at the top of the page.

This is done using jQuery and JavaScript.

Firstly, variables called ‘suspectImage’, ‘weaponImage’ and ‘roomImage’ are created. In jQuery, putting a dollar sign in front of a CSS ID (or class) in brackets and assigning it as a variable essentially means ‘this variable means get this CSS ID or class’. For example, the variable I’ve created called ‘suspectImage’ is a jQuery reference to the ‘suspect-image’ ID defined in CSS.

Variables called ‘suspect’, ‘weapon’ and ‘room’ are also created but not assigned any value – this technique is called initialising a variable.

When the user clicks on an image, the following code is executed.

The code above is for when the user clicks on a suspect, but the same code is used for the weapons and rooms section. Each image in the suspects section is a clickable item and when the user clicks on an item the following happens:

• Lines 17-19: The code recognises that an item in the suspects section has been clicked and gets the CSS class ‘a.suspects’ and the click function is executed.
• Lines 21-23: The colour is removed from the image that has been selected by adding the ‘grayscale’ and removing the ‘colourscale’ CSS classes to the image.
• Lines 24 & 25: The source of the image that the user clicked on is found and then the ‘colourscale’ class is applied – this is the image that is shown in the message box at the top of the page.
• Lines 26 & 27: By default, the div that contains the item title and the item description is hidden, but these lines send the item title and the item description to the message box.
• Line 30: This line finds the source of the image so that it can be displayed in the message box at the top of the page.
• Lines 31 & 32: These lines get the text for the suspect title and the suspect description and display them in the appropriate divs inside that message box.
• Line 33: The tracking event is sent to Google Analytics. The event is a button click (more on this later).

This is all of the code for the Cluedo cards game. My own website builds upon this code.

‘Discover London’ Website

The completed website can be visited here.

This website is built on exactly the same codebase as the Cluedo site, but it uses some extra JavaScript and some additional Bulma HTML elements not used in the Cluedo cards game to make the website more user-friendly and look better. If this website were to be a commercial site, its goal would be to allow users to book a day out in London, offering a range of attractions to visit and also transport to take them to these attractions.

The quick demonstration video below shows how the site works and some of the features it has. Users click on a hero image (a standard Bulma HTML element) to reveal a London landmark, attraction and transport method that they can book through the website. When a hero image is clicked, a message box is revealed which contains the items that the user can click on. When the user clicks on an item they are presented with information about it in a modal box. At the bottom of the modal box are buttons to find out more about the item, add the item to their day out or close the modal box. The message box (which acts more as a container) containing the items that the user can select can be collapsed either by clicking on the X in the top right corner of the box or by clicking on the hero image again.

Thanks to Bulma being based on Flexbox, the site generally scales to most mobile devices very well. The site is shown running as if it were on an Apple iPhone X (2436×1125, 5.8″) in Google Chrome’s device emulator. At the time of writing, the iPhone X is the highest-end Apple smartphone.

 

However, due to the site running on Flexbox, it does not work particularly well in Internet Explorer 11 which struggles to render all elements on the page correctly. The page looks fine in the browser but Internet Explorer 11 struggles to render modal boxes correctly, firstly aligning them to the right of the screen rather than the centre and it is not possible to scroll on modal boxes, meaning that the user cannot even see, let alone press, the buttons at the bottom of the modal to add the item to their day out or find out more about the item. There is code that can be added to the website that could alert uses of Internet Explorer to use a different browser instead, so if this site were to be commercial this would be required. See the video below to see how the site performs in Internet Explorer 11.

In this website, the find out more button simply redirects the user to Google, but if the site were for a real organisation this button would redirect the user to the website of the item that have just clicked on and it would open it in a new tab.

Modal boxes play a large part of the UI on this website. The benefit of using a modal box rather than a message box to show information is that the modal box can be hidden when the information inside it does not need to be displayed, see the screen recording of my website below showing the items that a user has added to the day out.

 

When no items have been selected, the following message is shown:

This is just the default text, but when items are added to the day out this text is overwritten with the title of the item selected and the other empty boxes are populated with the item description and an image of the selected item.

The code is very similar to that of the Cluedo website, however there are some alternations. Firstly, the code for a modal box is all HTML and looks like this:

The ‘Central Content Area’ modal is the modal box shown above – it’s the one that contains all of the information about the item that the user has clicked on. This is given an ID of ‘cca’. The ‘modal-card’ class is a default Bulma one. Putting content in the modal box is as easy as adding a section underneath the header and putting divs inside this section which can be filled with text and images. The footer area contains the buttons which are outside of the divs meaning that they are not inside the ‘boxed area’.

The other new HTML element I added to the Discover London website were the hero images which act as buttons which reveal the items to select. Again, these are a Bulma HTML element and the code is as follows:

This is the code for the famous landmarks hero. The ‘hero is-medium is-primary is-bold’ class is a default Bulma CSS class, medium being the size, primary being the colour of the hero (by default, primary items in Bulma are a very light green), however the ‘has-bg-img-third’ class is my own that I added to the end of the Bulma CSS stylesheet which simply puts a specified background image in the hero area instead of the default green background. The other heroes have different background image classes, such as ‘img-first’ and ‘img-second’ so that each hero can have a different background image appropriate to the items that clicking on the hero button unveils.

There is a lot of additional jQuery and JavaScript code which is manly for opening and closing modals – below is some of the code and an explanation of how it works.

The first difference between the Discover London site and the Cluedo site is that where the Cluedo card used a separate functions for the suspect, weapon and room to add the details to the message box at the top of the page, this site only uses one function to send the information about the item that the user selected to the ‘CCA’ modal. The code is the same as the code explained earlier for the Cluedo cards game, however there is one major change.

At line 33 there is an if statement which executes if the number of items that the user has added to the day out is less than 4. The brief was that the user was to only be able to add one landmark, one attraction and one method of transport, totalling three things in their day out. If the user starts adding more items to their day out, items that are already in the day out will be overwritten without warning. This isn’t great UX at all, so if the site were to be launched a warning about this would have to be given or the ability to add more than one item from each category would need to be implemented. If fewer than 4 items are selected, the information about the item (title, description and image) are sent to the CCA modal and displayed in the appropriate divs.  The divs are called ‘selection-message’, ‘selection-description’ and ‘selection-picture’, the contents of each is obvious.

Buttons that close modals usually have calls to a function I wrote called ‘toggleModal’.

The toggleModal function is shown below.

The toggle simply ‘clips’ all content in the HTML body of the website and displays the CCA modal box. However, it’s a toggle, so if the function is called again the opposite is true for both, hence how the code can be used to close the CCA modal as well as open it.

A lot of buttons on the site activate a function called ‘toggleDayOut’. This calls a function that opens and closes the ‘Day Out’ modal box, which is the modal that shows the details of the items that the user has added to their day out.

The toggleDayOut function is fairly complex, mainly because there’s some tracking code in this function which will be explained in the next section of the article, but the basic code of it is similar to that of the toggleModal function where one element is clipped and the other is made active to toggle the modal.

That’s the JavaScript and jQuery code for the website. A lot of this website is built right on top of the Cluedo cards website, code was added to the same files that the Cluedo cards files used and variable names and filenames were changed to reflect the new site.

Google Analytics

The actual core purpose of the Discover London website is to use Google Analytics to investigate which buttons users are clicking on and whether calls-to-action are clear.

Calls-to-action on this website are mainly buttons and hero images that the user can click on to find out more about items or add them to their own day out. By making each item that the user can add to their ‘day out’, it is possible to track which items are most popular (the ones that get clicked the most are of course the most popular).

Implementing Google Analytics

The first step is to create a Google account and activate analytics, then obtain the unique tracking code which Google uses to track activity on the domain. The code is active at the domain-level, not page specific, meaning that you don’t need to have a unique code for each page on the website.

In the head section of the HTML on the index page, the following code needs to be written – or copied and pasted from Google Analytics since they provide this code for you!

Replace ‘xxxxxxxxxx’ on line 16 with the unique tracking code provided by Google. This code sends all of the data to Google and also sends user events, such as button presses. However, the specific buttons that need to be tracked have to JavaScript code added to them so that when the user clicks on the button a function is called that sends the tracking data to Google. This function is shown below.

When this function is called, it sends several strings to Google Analytics, namely ‘send’, ‘event’ and ‘Discover London’. These are shown in the Google Analytics web panel as ‘event: ‘ and then the name of the action. The action and label are specified when the function is called (more on this later). An action might be something like ‘button press’ or ‘form open’ and the label might be ‘close button’ or ‘payment details’ – but this is all user-specifiable.

To actually track a button, it’s as simple as calling the ‘sendTrackingEvent’ function inside a button click event and send two strings with that function call – the first being the action and the second being the label as described above. The example below shows the tracking events being sent to Google when the user clicks on the button to close the day out modal box.

In Google Analytics, the event will show up as ‘Action: Cancel dayout, Label: Cancel button pressed’. By being able to specify what you want Google Analytics to show for certain events, you are able to more easily analyse your data and make more sense of it. Below is a screenshot showing the event actions as shown in Google Analytics.

Clicking on an action will reveal the different events that that action can have, so clicking on ‘Your Day Out Modal’ reveals the following:

The top event on this element was ‘Open’.

In order to track the state of modal boxes (the states would be ‘opened’ or ‘closed’), the following JavaScript code is used in the ‘toggleDayOut’ function.

Lines 150 and 151 are the lines that are to do with tracking in this code. Line 150 creates a new variable called ‘state’ which is set to ‘Open’ or ‘Closed’ depending on whether the modal box is active (open) or clipped (closed). The question mark and colon in line 150 acts as shorthand for ‘if else’ – it’s called the ternary operator. As can be seen in the Google Analytics screenshot above, ‘Open’ and ‘Closed’ are seen as events for the element ‘Your Day Out Modal’ – the same strings that are written in the tracking code.

Collecting data

When I had finished coding the website, I uploaded it to the web server and began the task of collecting data. I wanted to get traffic from a variety of sources – direct links (emails and telling people in person to ‘type this URL into the address bar’) and social media would be my main sources since my domain isn’t listed on search engines and I don’t have any ad campaigns running.

I started off by emailing my course tutor the link to my website who then put links to my website and my peers’ on a sub-page of the NUA Computer Science website so that each of us could try the websites. We were advised to get a minimum of 5 unique users to test our website to collect useful data from a variety of users.

I also emailed the link to my website to my peers.

I sent the link to my brother, mother and father so that some people who weren’t my university peers could open the website and collect data for me.

My brother forwarded this on to everybody in the company where he works to get additional data for me. He sent the email at lunchtime so I received a lot of visits at lunchtime on that day, presumably as employees looked at the site during their lunch break!

I sent a message via Facebook Messenger to some friends at university who I am working on an online student magazine with to get more people looking at the site.

I also used Facebook Messenger to send the link to everybody at the pub I worked at when I was collecting data from this website.

I also put the link on my personal social media accounts. I used Instagram, Facebook and Twitter to also spread the link.

As a result of all of these methods I used to send my link out, I received 71 unique visitors, 83 sessions and 145 page views on December 13th 2017 which was the day that the site went live and the day that the social media posts were written. Interestingly, 37 of the 83 sessions were from the USA. I know I have some followers on social media who are from the US, but I didn’t expect almost half of all sessions on that day to be from the US!

I decided to run the data collection between December 13th and 31st and then analyse the data that I collected over this period. Any data collected after December 31st 2017 will be disregarded.

Analysing my data

Google Analytics makes it very easy to export data from the web dashboard to a PDF file. To make analysing the data easier, I focused on an individual section of data to analyse at a time – Google Analytics can provide so much data that at first it can seem overwhelming!

All of the analytics data from Google Analytics about my Discover London website collected between December 13th and 31st 2017 can be viewed as one PDF file here.

Audience

All audience statistics are available to view here.

Audience statistics relate to where the users are visiting the site from (this can be viewed by country or city), the devices users are using to view the site on, the browser they are viewing the site on, the operating system they are viewing the site on and also more basic statistics, These include details such as how many users visited the site, how long they spent on the site, how many page views a site got and what the bounce rate was.

Quick stats – user numbers and locations:

• 104 sessions with 86 unique users and 172 page views.
• The average user looked at 1.65 pages per session (this is a single-page website anyway – the only link to another website is to Google when/if the user clicks on ‘Find Out More’).
• The average user spent 3 minutes and 25 seconds on the website.
• The bounce rate of users was 29.81%
• 79.81% of all sessions were by new users.
• The site was most commonly visited by IP addresses in Norwich, with 73.08% of all traffic coming from the city – this is 76 of the 104 sessions. For comparison, London came second with just 8.65% of all traffic, which was 9 of the 104 sessions.
• 98.08% of all traffic was from the United Kingdom – this is 102 of the 104 sessions. There was one visitor from the USA and one from the Ukraine, however it is likely that the visitor from the Ukraine may have been a bot.

Explanations for these statistics:

• The site was sent to a lot of specific people on December 13th 2017 via email and private messaging on social media networks for the purpose of collecting analytics data. These people viewed the website, however since the site didn’t much attention from public links there was a limited number of people that the link had exposure to. Had the site been listed on a search engine or gained more attention from public social media posts, the number of sessions and unique visitors would have been much higher. It is interesting note that several users must have visited the website multiple times hence for there being 104 unique sessions but only 86 unique visitors over the time span measured.
• The average user visited 1.65 pages per session – an interesting statistic since there is only one page on this website. It is possible that Google Analytics was also recording visits to Google from the ‘Find Out More’ button.
• The average user likely only spent a few minutes looking at the website because I only instructed my users to look at it for a bit and click on some buttons to gain analytics results. There isn’t masses of content on the site and most of the feedback I got in person from my users after they had tested it generally suggested that it was easy enough to use and seemed simple to use.
• The bounce rate was 29.81% which seems fairly low given that technically the website is only one page. The bounce rate is the percentage of users who leave a website after having visited just a single page. Technically the bounce rate should have been much higher since there is only one page to look at, but it is possible that people clicked the link from the social media private message or email, it opened the link in a new tab or browser window and then after they had visited the site they closed the tab or the browser window instead of pressing the back button on the browser. This would mean that technically they did not ‘bounce’ since to ‘bounce’ you have to have to been looking at a website prior to and immediately after visiting the page.
• It does not surprise me that the site was visited mostly by Norwich IPs. The link was sent around the whole of a medium-sized Norwich business and accessed heavily by its employees at lunchtime. I also sent the link to a lot of my university peers who live in the city and would have either opened the link at home in the city or at university, also in the city. There are other locations in the list that I would expect to have some visits given that I know that some people who had access to the link live in these other locations. It is possible that some of my public links on social media gained attention from people in London that follow me or saw the link online.
• For similar reasons as described above, it does not surprise me that the site was most commonly visited from the UK. It is likely that the visitors from the USA and Ukraine are actually bots given that my domain is a WordPress site and has had a lot of spam from the Ukraine and Russia recently.

From this data I am able to learn the following:

• Where my users are from, meaning I could tailor content to the location where most of my users visit the site from, e.g. by using Sterling and British English rather than American English and Dollars if most of my traffic is expected to be from the UK.
• How long users spend on the site, meaning I could judge if there is enough content to keep a user engaged or on the other hand, assume that my site is quick and easy to use. So easy in fact that users needn’t spend more than 5 minutes on the website in order to complete a task.
• See how many users and sessions I am getting on my website meaning that I could find ways to increase exposure if the site is not attracting enough users.

Quick stats – devices users were using:

• The most commonly used browser was Google Chrome with 54.81% of all sessions visiting the site from this browser (57 of the 104 sessions). Safari came second with 12.5% (13 of the 104 sessions). Firefox came 6th with just 3.85% of all sessions using this browser (just 4 of the 104 sessions).
• The most commonly used operating system to access the website was Windows with 60.58% of all users using this operating system to view the website (63 of the 104 sessions). iOS came second with 14.42% of all sessions coming from this browser (15 of the 104 sessions). Android came a close third with 13.46% of all sessions (14 of the 104 sessions).

Explanations for these statistics:

• Google Chrome, as of January 10th 2018, is the most commonly used browser in the world with 58.9% of the market share according to Net Marketshare. Interestingly, Firefox is the second most widely-used browser in the world with 13.9% of the market share but in my data at least, it was actually one of the least-commonly used browsers. No version of Internet Explorer is fully compatible with my website, yet all versions of Internet Explorer hold 13% of the global market share. In my data, Internet Explorer was so used by so few of my users (possibly none at all) that it doesn’t even appear in the list of browsers used to access the site. According to my data, Opera was the least used browser with just 2.88% of all sessions coming from this browser (3 sessions). Even Microsoft Edge was more commonly-used in my data, with 6.73% of all sessions (7 sessions) coming from this browser. Edge holds 3.78% of the global market share for browsers and of course is only compatible with Windows 10, so only 3.78% of users using a Microsoft web browser will be able to use my site properly.
• As of January 10th 2018, Windows is the most commonly used desktop operating system in the world, holding 88.87% of the market share, so it is not a surprise that most of my visitors used this operating system to view my website. Android is the most-used mobile operating system in the world, holding 68.69% of the market share and iOS is the second most-used holding 29.26% of the share, however in my data iOS was the most popular mobile OS to view the site on with and the second most popular OS in general. This is likely to do with the generally young audience that I sent the site link to and iOS and Apple products in general being popular with the younger generation.

From this data I can learn:

• Which browsers I need to target to attract the largest audience and create the best viewing experience. Should compatibility with Internet Explorer be considered given that it holds 13% of the global market share for browsers, but no users in my data used this browser? Similarly, I can learn that Chrome was the most commonly-used browser in my data and it is also the most commonly-used browser in the world, holding the most market share by far.
• I can begin to learn which operating systems the site needs to be compatible with. This is less important than browser since the browser determines compatibility. For example on a computer running Windows 7 you could view the site in Internet Explorer 8, 9, 10 or 11 (all of these versions are compatible with Windows 7) and the site won’t be functional, but use the latest version of Chrome, Firefox or Opera (also all compatible with Windows 7) and the site will be fully functional. Operating system is really only an important statistic to consider if there is only one compatible browser for the OS, like Windows Phone or Windows 10 Mobile or Google Chrome OS, all of which have very small market share and are not mainstream products.

Technology

All technology statistics are available to view here.

Technology statistics relate to the devices that users are using to view the site on. There is a lot of crossover with the stats about browsers and operating systems discussed in the ”audience’ section, but there is additional data that can be analysed such as the resolution of the screen of the device (very important) and the IP location of the session.

Quick stats – technology:

• The most commonly-used screen resolution was 1920×1080 with 28.85% of all sessions (30 of 104) being made on devices with a screen of this resolution. 1280×1024 was the second most commonly-used resolution with 17.31% (18 of 104) sessions being made on devices with displays of this resolution.
• 39.42% of all sessions (41 of 104) were made from a single static IP address, indicating a home user. 18.27% of all sessions (19 of 104) were made from IPs registered by my university, Norwich University of the Arts. It is possible that up to 4.81% of all sessions (5 of 104) were made on dial-up connections (or ADSL).

Explanations for these statistics:

• Whilst 1920×1080 is one of the most popular desktop resolutions in the world at the time of writing (in fact in 2017 it was the second most-common desktop resolution), in fact the most common resolution is 1366×768 primarily because this is the resolution most low-to-mid-range laptops have and with laptop computers outselling desktop computers, it’s not surprising a resolution common on laptop displays would be popular. Just under 30% of all ‘desktop resolutions’ (meaning laptop and desktop displays) to access the web in 2017 were 1366×768 and just under 20% were 1920×1080. It’s interesting that 1280×1024 appears in my data, it is still mildly common with just under 10% share in 2017, but then I remembered that many schools and businesses still use older monitors with these resolutions due to the cost of upgrading and of course my website was sent around a medium-sized firm who likely use older hardware.
• It’s not a surprise at all that most visits were made from home users or that a high amount were from the Norwich University of the Arts campus where my friends and testers are. I will never know if anybody did use dial-up to access the website since Google Analytics puts ADSL and Dial-Up connections in the same statistic, but it is certainly possible that up to 5 sessions could have been made on dial-up.

From these statistics, I can learn:

• That screen resolution is a massive consideration when designing a website. There are many different resolutions and several different aspect ratios to consider when designing a website. Generally, the older ‘square’ 4:3 and 5:4 aspect ratios are not as common as the newer ‘widescreen’ 16:9 (and much less commonly, 16:10) aspect ratio and are being phased out. The fact that until April 2012, 1024×768 was the most common desktop resolution indicates a need to try and design as responsively as possible, but at the same time obviously bearing in mind  that widescreen is more common in this day and age so that is the standard to design for as it caters most people better. It also shows that aspect ratios stay around for years as people don’t generally purchase new monitors very regularly and that although new standards such as 21:9 ultrawide monitors are on the horizon and are used now by enthusiasts who favour screen width, it probably won’t be a standard for a very long time especially given that 16:9 is still popular even with 4K monitors.
• Loading times and asset size are also important. Although the average broadband speed in the UK as of August 11th 2017 is 16.51MBps down and that is slower than most of Europe and some developing Asian countries, it is still the 31st fastest in a world of over 3.8 billion internet users as of January 10th 2018. Many of these are using slower connections than the UK and some users in remote parts of the world (developed or otherwise) and developing countries are still using dial-up internet. In January 2017 it was reported that there were still 2.1 million people using dial-up internet from AOL alone. Although this is a minority of users and very few people are using dial-up internet compared to ADSL, it is possible that many people have ‘slower-than-average’ ADSL connections and so page loading times and asset size is still an important consideration to take into account.

Mobile

All mobile statistics are available to view here.

Again, there is a lot of overlapping with the ‘audience’ and ‘technology’ categories, but this data gives a little more insight to the specific mobile devices that visitors are using, enabling you to tailor more specifically to visitors’ mobile browsing needs.

Quick stats – mobile:

• 65.38% of all sessions (68 of 104) were made on desktop computers and 34.62% of all sessions (36 of 104) were made on mobile devices.
• The iPhone was by far the most popular mobile device with all iPhones used (6, 6s, 7 and 7 Plus namely) totalling 15 of the 36 mobile sessions, representing 41.67% of all mobile sessions. By comparison, all of the Android devices total 14 of the 36 mobile sessions, representing 38.89% of the share. However, this 38.89% is over a mix of several devices manufactured by LG, OnePlus, Huawei, Google and Samsung, so the most popular device still remains the iPhone.

Explanations for these statistics:

• The site was viewed by a lot of people in businesses during their lunch hour, likely at their desktop computers because that’s where their email client is installed and set up. Many people also eat lunch at their desks at work and since very few businesses give employees access to the Wi-Fi networks for personal devices, most won’t want to incure the mobile data charges for viewing online content on 3G or 4G connections.
• The iPhone is a very popular device. Various iPhone models from the past few generations such as the 6, 6s, 6s Plus and 7 dominate the list of top 10 best-selling smartphones in 2017 according to GadgetsNow. Android devices may have more overall global market share than Apple devices, but in terms of single devices the iPhone is a very high seller.

From this I can learn:

•  It is just as important to ensure that the website works on desktop browsers as it is mobile browsers. The general design philosophy in 2018 is to ‘design with mobile first’, but when 65% of your traffic is still coming from desktop users it’s very important not to alienate them.
• The iPhone is a very popular mobile device and Android devices are very common too, so it is impotant to ensure that a mobile website is functional with popular mobile browsers for these platforms. Generally, Apple users use Safari on their mobile devices with over 96% of internet traffic from Apple devices coming from the browser. On Android, Chrome is the preferred browser and is the default on all devices which have the Google Play Store enabled. Chrome and the stock Android browser make up roughly 95% of all internet traffic from Android devices and the various other browsers that are available for Android such as Firefox Mobile and Opera Mini only make up for around 5% of traffic share.

Acquisition

All statistics for acquistion are available to view here.

Acquistion is all about the study of where your users come from – whether that be from direct links such as emails or private messages, or public links found on social media posts and search engines.

Quick stats – acquisition:

• 72.1% (75 of 104 sessions) of my acquisitions were from direct links and 27.9% (29 of 104) of my users were from links found on social media.
• The bounce rate of users from direct links was 37.33% and for those from social media links it was 10.34%.
• Those from direct links spent an average of 4 minutes on the website whereas those from social links spent an average of just 1 minute and 54 seconds on the website.

Explanations for these statistics:

• As mentioned previously, most of the people visiting my site likely would have had the link sent to them via email and their email clients are on their desktop computers, so it would be convenient for them to simply click on the link in the email they received and view the site on their desktop computer.
• Navigation on a desktop browser in terms of actually going backwards and forwards between websites (not just navigating between multiple pages on the same website) is generally a lot easier and more inuitative than it is on mobile browsers and generally pages don’t open in new tabs or browser instances, therefore it is easier to go back to a previous page on a desktop browser. On mobile browsers, new pages tend to open in new tabs, often without the user really realising it. When a user is finished with a website on a mobile browser, often they’ll press the Home button on the phone (or equivalent), which often has the same effect as simply minimising the browser window, and continue with another task, or they’ll close the browser app all together. This means that it is harder to actually ‘bounce’ between pages as you not ever actually returning to a previous page.
• Perhaps on a phone people tend to be multi-tasking and doing things quite quickly, for example listening to music and occasionally opening the music app to change the track, or quickly checking social media or emails or quickly opening up the browser to check something online. It’s likely that very few people actually sit down on their phone and spend a long time ding tasks.

From this I can learn:

• That more public exposure is required. It’s not good enough to simply rely on direct links for most of your user acquisition because that requires at least one person finding your website in the first place. There needs to be far more exposure on social media and search engines and for big companies, word of mouth and a reputation, since that is how people are ultimately going to find your website. There needs to be good content on the website that is desirable to consume else there is no reason for the visitors to want to visit the website in the first place.
• Expanding on the last point, for mobile users the experience needs to be so pleasant to use and the content needs to be so engaging that it keeps them engaged and wanting to explore the site for a good length of time.

User Behaviour

All statistics for user behaviour are available to view here.

User behaviour is all about how users behaved on a website, for example the length of time they spent on the website, which pages they visited the most and whether they returned to a website or not. A lot of this has already been covered in previous categories, but the behaviour category in Google Analytics makes some additional information available.

Quick stats – user behaviour:

• The most visited page on the website was obviously the index / home page since this is the only page on the site.
• 34 of the 104 sessions lasted under 10 seconds. Disappointingly, it seems that most sessions lasted under 10 seconds. 20 of the 104 sessions lasted between 61 and 600 seconds and 18 of the sessions lasted between 11 and 30 seconds and again, 18 lasted between 31 and 60 seconds. It seems that most people spent between 0 and 60 seconds on the website.
• 79.81% of all sessions (83 of the 104) were new sessions and 20.19% (21 of 104) were sessions done by returning visitors. This suggests that the site orbit is fairly moderate.
• Returning users usually had a much longer session time, on average 7 minutes and 11 seconds. whereas new users had an average session time of only 2 minutes and 27 seconds for comparison.

Explanations for these statistics:

• The index page is the only page on the site.
• It is likely that users opened the website, had a quick look and then closed the site and reminded themselves to have a look later, maybe once they had finished work or it was a time for a break from work. This is especially likely given the final statistic about the session duration of new and returning visitors. Alternatively, it could mean that the site is so boring or frustrating to use that users simply don’t want to spend any great amount of time on it or in my case perhaps it was because I generally advised people that they only had to spend 30 seconds on it. There are so many reasons why this particular statistic is what it is.
• It is possible that some users opened the site initially to see what it was or what it was like and then closed it and opened it again at a later time, meaning that they became a returning visitor. They may have tried the site on multiple browsers on the same device which would have made them a returning user.
• The fact that returning users generally had a much longer session suggests that the scenario where the user initially opened the site, had a very quick look, then closed it and looked at it again in more depth later is likely true.

From this I can learn:

• Content needs to be engaging enough to make users want to return to the website as generally the returning users spend longer on the website, so it is desirable to get users to come back. This would eventually build up a fairly loyal user base, but it must also be kept in mind that you also want to attract new users to the website, especially if the site is commercial and attracting new users to the company website is a way of attracting new customers.
• When working on websites with multiple pages it is important to apply the principles above to all of the pages on the website.

User Events

All statistics for user events are available to view here.

User events are the operation of call(s)-to-action on the website, such as the clicking of buttons or the completion of forms. When people think of web tracking, this is generally what they have in mind, they envisage data being sent back every time a button is clicked and that’s exactly what is happening on my website. Every button has a tracking action. Generally, this is frowned upon as it can produce so much data that you don’t know what to do with it or can’t possibly be producing 100% useful data, but on my small site which only has a few buttons I was able to track each button to test how users completed tasks without producing an excessive amount of data.

Quick stats – user events:

• Opening the ‘Your Day Out’ modal was the most common event on the site, with it accounting for 20.07% (167 of 832) of all events tracked on the site. Of these 167 events, 89 were to open it (51.5%) and 81 were to close it (48.5%).
• Opening the ‘CCA’ modal was the second most common event on the site, with it accounting for 14.9% (124 of 832) of all events tracked on the site.
• More users clicked on the ‘Transport’ hero button than they did the ‘Attractions’ or ‘Landmarks’ hero buttons, making 14.42% (120 of 832), 12.98% (108 of 832) and 11.78% (98 of 832) of the share respectively.
• The least common event on the site was closing the ‘Transport’ section by clicking on the close button in the upper right corner of the collapsible container (which is actually a Bulma message box) with this only accounting for 4 events (0.46% of all events).
• Closing the ‘Landmarks’ and ‘Attractions’ sections in this way were also some of the least commonly-performed events, accounting for only 6 (0.7%) and 5 (0.58%) of all events respectively.
• The most closed item was the ‘Your Day Out’ modal, accounting for 4.21% (35 of 832) of the events on the site. No other item was closed as often.
• The non-functioning ‘Find Out More’ and ‘Book’ buttons were both hardly used with the clicking on the ‘Find Out More’ button accounting for 1.68% (14 of 832) of all events and clicking on the ‘Book’ button accounting for 1.32% (11 of 832) of all sessions. Cancelling the items in the day out accounted for just 1.08% of all events tracked – that’s just 9 of the 832 recorded events.
• 32 of 71 first events were to click on the ‘Your Day Out’ hero image button. 13 of the 71 were to click on the ‘Landmarks’ hero image button, 11 were to click on the ‘Attractions’ hero button and 8 were to open the ‘Transport’ hero button.
• In total 35 items were added to days out by users, with London Zoo being the most common being added 8 times (22.86% of all items added to days out). The Natural History Museum came second being added 4 times, representing 11.43% of all items added to days out. The least popular was travelling by Tube which was only added once (representing 2.86% of all items added to days out).
• 7 items were only added to a day out once.
• 11 of the 65 second events were to press the ‘Cancel’ button on the ‘Your Day Out’ modal. Subsequently, this resulted in 11 of the 65 second events being that the ‘Your Day Out’ modal was closed. 5 were to close the ‘Attractions’ hero button by clicking on the hero image again, 4 were to close the ‘Landmarks’ hero button using the same method and an additional 4 were to open the ‘Your Day Out’ modal. There were an additional 18 unique events which included adding items to the day out.
• 18 of the 58 third events were to close the ‘Your Day Out’ modal and 6 were to click on the ‘Attractions’ hero image. An additional 6 were to click on the ‘Landmarks’ hero image and a further 6 were to click on the ‘Transport’ hero image. 4 were to open the ‘Your Day Out’ modal. There were an additional 14 events which included adding items to the day out.
• 9 of the 53 fourth events were to click on the ‘Landmarks’ hero image, 7 to click on the ‘Attractions’ hero button, 6 to open the ‘Your Day Out’ modal, 5 to close the ‘Your Day Out’ modal, 4 to open the ‘Transport’ hero image and there were 13 additional events, including adding items to the day out.

Explanations for these statistics:

• It is likely that the ‘Your Day Out’ modal was the first thing that most users clicked on because it was the first clickable button on the website. It appears at the top of the page underneath the header. Perhaps users expected clicking on this button would allow them to add items to their day out, but instead what it does is simply show them what they currently have in their day out. After the users discovered that opening the ‘Your Day Out’ modal actually just shows them what they have in their day out already and as it was the first thing they clicked on there would be nothing in there, they likely would have immediately closed it which is why this modal was the most commonly closed item on the website.
• The ‘CCA’ modal is the modal that contains information about the item that the user has clicked on before it is added to their day out, so it is not surprising that it was opened so often.
• With the ‘Transport’ hero image button being at the very bottom of the page, perhaps users scrolled through the site and then eventually realised that they could click on the hero images to expand the sections and see the options that they had to add to their day out.
• It’s not surprising that closing the sections with the little close button in the upper right corner was not a commonly-performed event. The button is tiny and so must users probably wouldn’t have noticed it in the first place and it also likely seems much more logical to close the section by clicking on the button that they used to open it. It was interesting to see which of the two methods of closing the sections users would favour and it was not surprising that they favoured clicking on the hero image again.
• There are likely two reasons why the ‘Find Out More’ button was not clicked more often. Firstly, it might be that enough information is provided already so there is no need to have a dedicated button for finding out more, or maybe these landmarks, attractions and transport methods in London are so well-known that the user already has enough knowledge of them to know whether it’s something that they’d want to add to their day out. The second is that they may have clicked the button once and found it took them to Google and then not bothered to click on it again after they discovered this.
• It’s possible that the ‘Book’ button was not pressed often by the users because they may have felt that pressing it would actually book tickets to the items they had listed in their day out, but of course this is not the case. Perhaps some prior explanation would have helped. Pressing ‘Book’ is also only something that the user needs to complete once, whereas adding items to the day out or closing modal windows are events that the user would likely perform multiple times.
• There is no particular reason why the user added London Zoo to their day out the most. Perhaps the image of the tiger was more attractive and/or exciting to them than the images for the other attractions so naturally users gravitated towards this option or maybe the people who tested my site just felt that London Zoo was an attraction that they would be interested in visiting. The Natural History Museum is also another famous attraction in London that users of my site perhaps felt they’d be interested in visiting on an excursion to London.
• It seems that the users didn’t really follow any kind of order when expanding sections to find items to add to their day out. Users didn’t click on ‘Landmarks’ before clicking on ‘Attractions’ generally, users browsed the site and its features in their own order and did what they felt was appropriate for them. No order was enforced, but it’s interesting to note that ordering the hero images / sections in this way appeared to have no impact at all on how the users browsed the site.
• It also seems that users did keep opening the ‘Your Day Out’ modal to check whether items that they had added to the day out had appeared, hence why opening the modal appears as third and fourth events as well as the first and second. This shows that the users did at least understand the purpose of the modal and knew exactly what information it would be showing them.

From this I can learn:

• The positioning of the button to open the ‘Your Day Out’ modal is perhaps not ideal. The modal is a little like a shopping basket and on most e-commerce websites the shopping basket is accessed by clicking on an icon in the upper right corner of the page (or similar) – it is generally not accessed by clicking on a large hero button that spans the width of the page, has a nice picture in it and is located right at the top of the page directly underneath the website header. It is evident that the positioning and nature of the button to open the modal confused users as they felt that it would maybe begin the process of adding items to the day out, despite there being a caption on the button that says ‘Click here to see items currently in your day out,’ but maybe this is misleading too because it may imply that by default several items are already added. It is not particularly good user experience to visit a website, open what is effectively a shopping basket and then have to close it again after you discover that it is indeed empty by default and that you have to add items to it. Talking in person to some people that tested the website afterwards, they said that this button was the first thing they noticed on the website and this is why they wanted to click on it first. If I were to redesign this site I would likely but a thin bar at the top of the page which had a button for opening this modal in the bar so it was more like a conventional shopping website.
• If this was a commercial website, using the data that I collected about which items users added most often to their day out I could see which items were popular and which were not and then using this data either discontinue the items that were not popular (because I would be losing money on them) or I could find a way to promote these items to help increase sales.
• It seems that although you can try to ‘push’ content by putting it higher up the page to try and get the users’ attention, it isn’t guaranteed to work because at the end of the day they will browse the website in the way they want and click on the items that they want to interact with.
• Toggle buttons are most logical to the users to use.
• The users treated this website a little like a shopping website, constantly checking back at the ‘Your Day Out’ modal to check which items they had added, so they understood the purpose of the website and it could indicate that the design of the website was intuitive and easy to understand.
• When testing, users take directions fairly seriously. I told them that they’d only need to spend 30 seconds or so on the website clicking buttons and most did that, but I didn’t tell them that the site doesn’t actually work (in that it won’t actually book you a day out in London), so had I told my users this they may have been more prepared to try things like the ‘Book’ button, safe in the knowledge that this is a little like a prototype website. I would also tell them to try and book a day out in London using this site that they’d be interested in doing so then I would be able to find out exactly which items were really popular and which weren’t, without having to guess that London Zoo was the most added item because the picture was attractive or my users liked the idea of going there. If I got the users to actually test the site as if they were trying to book an enjoyable day out in London (rather than just tell them to press buttons for the sake of collecting data) I would have collected less data, but it would have perhaps been more meaningful as I’d be able to see the order in which the users were clicking on buttons and adding items to the day out and so on.

Conclusion

Thoughts on Bulma as a framework

Bulma is probably my favourite responsive CSS framework to date. There are plenty of attractive and useful default elements that can be used for multiple purposes. The framework is easy to customise and is easy to code (for example, the ‘is-primary’, ‘is-bold’, ‘is-green’ etc syntax is really easy and logical to code and remember). The framework scaled really well to desktop and mobile devices and where other frameworks such as Furtive only really look good on one platform, Bulma works well on both. I was impressed with the framework and would use it again.

Thoughts on my project

It was very interesting learning about Google Analytics and collecting this data. It’s interesting to see exactly what devices users are using and what their behaviour on the website is like. From my data I would be able to consider the design of my website and ensure that it works properly on the devices that the users are using and more. This project didn’t generate the most useful data for the reasons outlined earlier about me not really directing my users to achieve any kind of goal, but I would definitely implement Google Analytics on another website that I create and ensure that more useful data is collected. I have learned that collected data is invaluable if you want to truly improve the user experience of a website and discover how you can make the experience better for customers.

Bibliography

Usability.gov. (2018). Web Analytics Basics | Usability.gov. [online] Available at: https://www.usability.gov/what-and-why/web-analytics.html [Accessed 6 Jan. 2018].

Kaushik.net. (2010). Beginner’s Guide To Web Data Analysis: Ten Steps To Love & Success. [online] Available at: https://www.kaushik.net/avinash/beginners-guide-web-data-analysis-ten-steps-tips-best-practices/ [Accessed 6 Jan. 2018].

Kaushik.net. (2007). Standard Metrics Revisited: #3: Bounce Rate. [online] Available at: https://www.kaushik.net/avinash/standard-metrics-revisited-3-bounce-rate/ [Accessed 6 Jan. 2018].

Wordle.net. (2018). Wordle – Beautiful Word Clouds. [online] Available at: http://www.wordle.net/ [Accessed 6 Jan. 2018].

Dubois, L. (2010). 11 Best Web Analytics Tools. [online] Inc.com. Available at: https://www.inc.com/guides/12/2010/11-best-web-analytics-tools.html [Accessed 8 Jan. 2018].

Bulma.io. (2018). Bulma: a modern CSS framework based on Flexbox. [online] Available at: https://bulma.io/ [Accessed 7 Jan. 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].

Rascia, T. (2017). If Statements, If Else Statements, Nested If, Ternary Operators | DigitalOcean. [online] Digitalocean.com. Available at: https://www.digitalocean.com/community/tutorials/how-to-write-conditional-statements-in-javascript [Accessed 8 Jan. 2018].

Netmarketshare.com. (2018). Browser market share. [online] Available at: https://www.netmarketshare.com/browser-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22browser%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22browsersDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-01%22%2C%22dateEnd%22%3A%222017-12%22%2C%22segments%22%3A%22-1000%22%7D [Accessed 9 Jan. 2018].

Netmarketshare.com. (2018). Operating system market share. [online] Available at: https://www.netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22platform%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22platformsDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-01%22%2C%22dateEnd%22%3A%222017-12%22%2C%22segments%22%3A%22-1000%22%7D [Accessed 9 Jan. 2018].

2016, D. (2017). Desktop screen resolutions used in the UK | 2010-2016. [online] Statista. Available at: https://www.statista.com/statistics/487487/leading-desktop-screen-resolutions-uk/ [Accessed 9 Jan. 2018].

Lardinois, F. (2012). Move Over 1024×768: The Most Popular Screen Resolution On The Web Is Now 1366×768. [online] TechCrunch. Available at: https://techcrunch.com/2012/04/11/move-over-1024×768-the-most-popular-screen-resolution-on-the-web-is-now-1366×768/ [Accessed 9 Jan. 2018].

Bradley, S. (2017). You shouldn’t be surprised that UK broadband speeds suck. [online] Wired.co.uk. Available at: http://www.wired.co.uk/article/uk-broadband-speed [Accessed 9 Jan. 2018].

Internetlivestats.com. (2017). Number of Internet Users (2016) – Internet Live Stats. [online] Available at: http://www.internetlivestats.com/internet-users/ [Accessed 9 Jan. 2018].

Tracy, P. and Bond, J. (2017). It’s 2017, and 2.1 million people still use dial-up internet from AOL. [online] The Daily Dot. Available at: https://www.dailydot.com/debug/dvd-rental-windows-3-aol-2017/ [Accessed 9 Jan. 2018].

Bureau, G. (2017). Apple iPhone 7 Plus – World’s 10 highest-selling smartphones revealed | Gadgets Now. [online] Gadget Now. Available at: https://www.gadgetsnow.com/slideshows/10-highest-selling-smartphones-revealed/apple-iphone-7-plus/photolist/57859680.cms [Accessed 9 Jan. 2018].

Bott, E. (2016). Which browser is most popular on each major operating system? | ZDNet. [online] ZDNet. Available at: http://www.zdnet.com/article/which-browser-is-most-popular-on-each-major-operating-system/ [Accessed 9 Jan. 2018].