Last week was Reading Week and in this time I did a number of interesting things. Firstly I visited Redgate Software on Tuesday 20th which you can read all about here. I made some progress with the Storehouse Online magazine website which now features a vibration when you tap the buttons on mobile devices using the vibration.js library as well as using jQuery to switch between light and dark modes rather than switching stylesheets and numerous other smaller changes. This has helped to keep me on top of my coding skills without having to necessarily work on developing the next prototypes for Nellie’s Nursery, speaking of which the testing data and a full analysis is now available for the February 2018 prototypes of the Nellie’s Nursery website. I’m also starting another project with my friend Emma (on top of Inspix) which I will be writing about soon! It’s very exciting and unique, so look out for it!

Monday 26th February

Today I was back at university and was introduced to the agenda for this week, which is:

• Reviewing the project objectives and modifying wireframes to suit based on the resting data collected two weeks ago.
• Considering what kind of analytics should be collected on the website to create useful data for further developing the website after the first version has been released.
• Planning an alpha testing strategy. Alpha testing is done internally, so this will be done in a similar kind of fashion to my prototype testing strategy (which could be considered alphas).
• Plan the project using project management software (I’ll likely use Microsoft Project Professional since I have it) to plan the software development schedule between March 5th and March 16th which are the two weeks in which the full website is developed. However, the evolutionary nature of my prototypes means that the foundations of the site has already been developed.
• Begin looking at the UX industry and finding out about jobs, careers and companies that my industry could take me into. The visit to Redgate is a good start and the post I wrote about that is a good start, as is reflecting on the opportunities I’ve had with Neon Tribe, The User Story and Foolproof recently. On March 21st and 22nd  I am attending the University of East Anglia’s Move On Up event with Tom Haczewski to promote BSc courses at NUA where I study, so this will another insight into the industry and working with industry professionals to deliver a total of 10 presentations about UX over the course of two days.

Reviewing project objectives

When I changed my client to Nellie’s Nursery on Wednesday 17th January I felt that it was going to preempt the project objectives because I was producing a nursery website, so I looked at existing nursery websites and saw what kind of information they had on them and noted what they had. On Tuesday 23rd January in preparation for a presentation that I was due to deliver two days later, I wrote a very basic list of requirements that the website needs to have, notably:

• It is typically the mother who is most interested in their child’s education and has a big say over where and how their child is educated, so therefore the site is more likely to be accessed by women than men.
• The site’s function is to inform potential parents of children about what the nursery has to offer and why Nellie’s is the nursery for their child.
• Parents want to easily find information to help making the decision about which nursery to send their child to easier.
• Parents want to know that the nursery is going to be a fun, friendly place for their child to go.
• Parents want to feel secure in the knowledge that their child’s education and safety/security is the top priority at a nursery.
• Many parents use mobile devices such as tablets to play games with their children, so it is important that the site works on mobile devices and looks attractive for children too (even though the site isn’t directly targeted at them). Parents may wish to show information on the website to their children to help get their child interested in going to the nursery, so it is important that content is also age-appropriate.
• Not to mention that a large amount of internet browsing is done on mobile devices these days.

On Tuesday 30th January I visited Nellie’s Nursery and met the MD, Victoria, and using what we discussed, wrote this requirements specification:

What is it?

• It’s a website for Nellie’s Nursery.

What does it do?

• The aim of the website is to inform prospective parents about the nursery, what it has to offer and why Nellie’s Nursery is the nursery to send their children to. It is entirely an information website and can be also be used to access policy documents that the parents need to sign in order to send their child to the nursery.

Who is it for?

• The website is strictly targeted at adults. It is not aimed at children and there will be nothing there for them or any particular reason for them to visit the website due to the website not having any content appropriate to them. This does not mean that the website is ‘adults only’ or contains adult material, it means that the nature of the information on the website is targeted at parents and may use language that children won’t understand.
• Parents are the main target audience, specifically prospective parents. The site needs to sell the nursery to them. However, there is currently a ‘staff area’ that they want to develop and get the staff using more to access more policy documents that are applicable to only the staff.
• Parents of current students are a target audience. The website should tell them all about what their child is doing at nursery and how the nursery is helping their education. It should be an information communication platform between the nursery and the parents. There should be helpful for current parents on the website such as menus and newsletters.

When and how are they going to use it?

• The website should be accessible all the time – whenever somebody wants to know about the nursery, they should be able to access the website and the information should be there.
• The website should work in all modern browsers. The current site does not work on anything older than Internet Explorer 10 which at the time of writing is a 5 year old browser. Thus, support for older browsers is irrelevant.
• The website must be responsive since it is believed that a lot of traffic comes from mobile devices. It must scale to mobile phones and tablet computers and have a touch-friendly interface for these devices.

What are the benefits?

• Compared to the existing website:
• It will bring Nellie’s Nursery more in-line with competitor websites, thus increasing their traffic and hopefully an increase in students and staff.
• The information hierarchy on the new website will be superior to that of the existing site, so information will be much easier to find and read. This will reduce the bounce rate and also reduce the length of time that a user has to spend on the site to find content.
• It will look a lot more attractive which again will help to draw traffic and increase the number of customers.

What are the restraints?

• The project needs to be completed before May 2018 and there is limited time to code a website.
• Communication must be frequent in order to help develop a website that has the client’s needs in mind. Regular feedback will be required in order to move forwards with the project.
• It is possible that the client and I may have differing ideas about the website which could lead to conflict.
• A lot of the user research data will be based on people answering the survey honestly, so any dishonest answers could corrupt user research data and then potentially mean that the site includes things that people don’t really want.

In addition to the requirements statement, Victoria also mentioned:

• She doesn’t want any kind of payments for anything to be placed through the website.
• She wants the staff to feature more heavily on the new website so that the parents know who they are and what they do. She wants a short bio of each staff member that states their specialism, the children that they work with and their interests.
• She wants to keep the site looking ‘homely’ and friendly, but doesn’t want the new site to look corporate. She personally prefers subtle colours and the soft colours used on the existing website.

After having tested my first three prototypes (desktop, Mobile Prototype 1 and Mobile Prototype 2) last week, it can be assumed that these requirements do not need to change. Every tester who participated in the testing on February 15th and 18th said that they felt that the prototypes looked like they contained all of the information that would need to find on a nursery website. Going by this, the information that the prototypes suggest will be on the final versions is plentiful and meets these requirements, which is to inform prospective parents about the nursery.

Updated wireframes

Testing concluded that the desktop site was the most favourable prototype which users enjoying using the prototype and praising its easy navigation and attractive appearance. Testing also concluded that users were split between Mobile Prototypes 1 and 2, with users praising Prototype 1 for having icons and fixed navigation at the bottom of the page which they felt made it interesting and unique, but criticising it for using illogical icons that made navigation confusing and visiting a page more ‘luck of the draw’ than being able to navigate to it safe in the knowledge that it would take you to the correct page. Prototype 2 was praised for being easy to use but a little ‘common’ and some testers didn’t like how it required you to tap a button before you could navigate to the different pages on the site.

Reflecting on these comments, I have concluded:

• The desktop website does not need to be changed – content just needs to be added and the tiles changed on it in-line with what was suggested during prototype testing on February 15th.
• The next mobile prototype needs to be a mix of Prototypes 1 and 2.

The answer for the mobile prototype problem could be creating a prototype where commonly used pages have fixed icons at the bottom of the page for quick access and lesser-used pages are hidden in a hamburger menu, which is also placed at the bottom of the page for the best ergonomics.

Reviewing the user data that was presented on February 5th, the most common reasons for visiting a nursery website are to find out about the nursery itself and to contact the nursery.

Reviewing the prototype testing data for Mobile Prototype 1, the icons that the testers found the hardest to initially interpret were the Day-To-Day. Meet The Team and Groups icons that were used in that prototype.

 

So, given that the key reasons for visiting a nursery website are apparently to find out a bit of information (that could, and should, be summarised on the home page) and contact the nursery, and on Mobile Prototype 1 these icons were understood by all of the testers, it seems that making the home and contact page buttons static at the bottom of the page would be a logical decision since these icons were easy to understood and these pages are likely going to be the most visited ones. Having the home icon present on every page at the bottom of the page also provides the ever-important ‘escape route’ that forms a key part of UX psychology. It’s been mentioned in previous reflective journals, but basically escape routes are important in UX because they use prehistoric antics in us to help us feel in control. The quote below is from an article written by Ivana McConnell about psychology behind UX.

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.

By having the home button present at the bottom of every page, it can be assumed that if the user ever feels confused or lost on your website, they will tap on the home icon to escape. If you look at hardware a similar idea is used. Most smartphones have a ‘home’ button or a button that takes you back to the initial operating system ‘apps screen’ placed at the bottom of the device and in the centre. On iPhones and most Android phones this is actually called the ‘home button’ and on Windows Phones this is called the ‘Start button’ (just like the Start button on the Windows operating system). This idea works well on hardware, so why not apply it to software as well?

The home button on the iPhone (left) is a circular button and is the only button at the bottom of the device. On Android phones (centre), the home button can be hardware or software, but it is always located in the centre of the device at the very bottom and accompanied by an ‘all apps’ button and a ‘back’ button. On the Google Nexus shown in the image above, the ‘back’ button is to the left of the ‘home’ button and the ‘all apps’ button is to the right, but on some Android handsets this is switched. On Windows Phones, the buttons can be hardware or software (usually hardware, only the later Windows Phones like the Lumia 650 and 950 series had software buttons) but there is always a ‘Start’ button in the centre (depicted by the Windows logo) which takes you back to the Start Screen, accompanied by a ‘back’ button (left) and a ‘search’ button (right). On Android and Windows devices, pressing the home or Start button often makes the phone vibrate a little to let the user feel like they are pressing a tactile button. Using the vibration.js library that I learned how to use last week to make buttons vibrate, I could employ a similar tactic on the next prototype of Nellie’s Nursery.

Furthermore, analytics data could be used to see which pages are being visited the most and then the icons for the two or three pages that are being most frequently visited can be put on the fixed menu at the bottom – then you know for sure that only links to helpful pages are always accessible and the other pages in the site that aren’t as frequently visited are slightly more hidden.

When designing software it’s always important to consider the platform that the software is being written for and how the user might interact with the software on its target platform. Here, I have two target platforms: desktop and mobile. Ergonomics are an important part of the user experience – something that is difficult to’thumb’ or use on the device it was intended for won’t be pleasurable for the user to use and might result in the user not using the product! When asked if they preferred the ergonomics of Mobile Prototype 1, which featured a fixed menu at the bottom of the page, or Mobile Prototype 2, which featured a hamburger menu, a massive 86% of testers preferred the ergonomics of the fixed menu system in Mobile Prototype 1. This indicates to me that the successor to these prototypes needs to also include fixed navigation, likely at the bottom of the page again.

I sketched the first wireframe of a successor to the original two mobile prototypes on February 18th after all of the testing had been done. It featured a layout similar to what I have described. In this sketch only the home icon is always visible with the other buttons all being hidden away in the hamburger menu. When I met my friend Emma during reading week she suggested that I have the most commonly used icons ‘docked’ to the bottom of the site, not just the home page icon. All things considered, I think that this is the way forwards.

 

Today I went back onto Axure RP 8 which I used to create clickable wireframes of the other prototypes and made a mobile wireframe of the next prototype. The new wireframe which is for Mobile Prototype 3 includes the fixed menu system as seen on Mobile Prototype 1, but also a hamburger menu located in the centre of the menu that the user can tap to reveal the pages. As mentioned earlier, this retains the favoured ergonomics of the fixed menu system and also retains the ease of use that Mobile Prototype 2 had. The home and contact buttons are the only buttons outside of the hamburger menu so that they can be accessed quickly and provide an ‘escape route’.

The video below shows the new clickable wireframe being used. The animations in the menu in this wireframe version of Mobile Prototype 3 may not make it into the real thing, but using jQuery to toggle classes it may be possible to do and would add a nice effect to the menu.

The wireframe can be viewed on AXShare here. Please note that as mentioned in the video, in the real prototype the menu bar will be fixed at the bottom of the display – I’m not sure if it is possible accomplish this in Axure hence why the wireframe doesn’t show this. Also note shown is the rollover colour. Just like in Mobile Prototypes 1 and 2, when the user rolls over the buttond they will change colour and the current page will be highlighted too.

As the desktop site is not being changed, the wireframe is still the previous one which was made on Tuesday 30th January.

Changes to the home page following testing

The navigation was a core component of the prototypes that needed to be changed. Another area that I have identified for change is the home page. Testing of my prototypes concluded that only 29% of testers initially thought to look for basic information such as the nursery session times on the home page and 71% instinctively looked on the Day-To-Day which didn’t have the session times on it. The 0% represents users who initially tried to look for the information on the Groups page, which did have the information on it, but nobody thought to look there.

By placing the home button on the fixed menu at the bottom as one of only three buttons on the whole menu, the idea is that the home page will be the source of basic information about the nursery that the user can quickly refer to to find out information about the nursery. If only 29% of people are thinking to look for basic information, such as the session times, on the home page then there is little point having the home page icon on that menu. Mobile Prototype 3 and the updated desktop prototype will make the home page more of a ‘basic information page’ by making information much easier to find, much more obvious and crucially, much closer to the top of the page so that when users land on the home page they are greeted with this basic information.

Provisional thoughts on the usability of the new navigation system in Mobile Prototype 3

This new navigation system is the result of user data and prototype testing data put together to create something that hopefully works. Without having really asked anybody if this is what they’d like to see or what they want. I can only assume that since it takes the good points of my previous prototypes and puts them together it will be popular.

My biggest concern with this type of navigation system is that with the advent of ‘bezelless’ smartphones such as the Samsung Galaxy S8, Huawei Mate 10 Pro and the Apple iPhone X which were all launched last year and have been very popular, those hardware buttons that I mentioned earlier are ever being replaced with software buttons. It won’t be long at all before mainstream models adopt the ‘bezelless’ design style that these flagships have – in fact the mid-range Samsung Galaxy A8 which is due to launch in the UK in April this year will look a lot like its bigger brother, the S8, and it will not feature any hardware buttons on the front of the phone just like the S8.  The Samsung Galaxy S9 was announced a day before this was article was written and looks a lot like the S8 – it’s definitely the way smartphones are headed. This means that designs like my own which have buttons at the bottom of the app may become slightly harder to use on these newer smartphones because it could be easy to accidentally press the ‘home’ button of the phone or the ‘back’ button of the phone rather than one of the icons on my menu. This could prove to be a UX nightmare.

However, the hardware and software vendors are aware of such an issue and realising that the whole point of these bezelless smartphones is to increase screen estate and viewing area, many of them feature phone menu buttons (e.g. on Android the ‘home’, ‘all apps’ and ‘back’ buttons) that can be toggled so that they are only accessible when the user requires them and the rest of the time they are hidden so that they are not accidentally pressed and there is more space to view content. This is fine, but often they are activated by tapping at the bottom of the screen, so by tapping on the icons on my fixed menu at the bottom may accidentally toggle the operating system’s own menu buttons. The solution may be to ensure that the buttons in my menu have some padding between the bottom of the buttons and the bottom of the phone, so that tapping on the buttons doesn’t inadvertently activate any kind of menu.

Other than this issue, I don’t perceive any massive usability issues with this prototype since the confusing icons from Mobile Prototype 1 have been removed. A benefit of only having three visible buttons on the menu bar is that they can be made bigger, meaning that they will be easier to tap and still display quite large on smaller and lower-resolution smartphones, improving device compatibility and usability in the long run.

Provisional thoughts on testing Mobile Prototype 3 during Phase 2 Testing

In the post about the February 2018 testing at the end I mentioned various different testing options for the future prototypes. At this point in time I don’t think there will be a ‘Mobile Prototype 4’ to go hand-in-hand with Mobile Prototype 3 at least since what was described ‘Mobile Prototype 4’ in the testing post is essentially what I have begun to think about designing in this post. Other than moving the buttons around and maybe removing all of the buttons on the fixed menu bar the hamburger menu button, I don’t yet feel that there is a lot of variation I can do with this design. I can ask the testers whether they’d prefer to have the buttons in a different order or whether they’d rather just have the button for the menu fixed rather than also having the home and contact buttons instead of have to develop a prototype that only has that change. It would mean that I could spend more time refining one prototype. These are meant to be evolutionary prototypes too, so surely which each iteration the number of new prototypes/designs that are being tested should be reduced?

With that in mind, Phase 2 Testing will likely be an A-B-C test of the desktop site, Mobile Prototype 2 and Mobile Prototype 3, but to get fair data I will need to get a whole new set of people who haven’t seen the desktop website or Mobile Prototype 2 to do this test. The aim will be to find out if Mobile Prototype 3 is an improvement from the previous generation Mobile Prototype 2.

Tuesday 27th February

Alpha testing is the focus of today. Alpha testing has arguably already begun really with the testing of the first mobile prototypes. Alpha testing is in-house testing where the aim is to find bugs with the software and correct these before the software is released for beta testing. Since the prototypes were not tested by anybody at Nellie’s Nursery, it could be said that it was tested ‘in-house’ at university with my peers.

Device testing

I will endeavour to test the prototypes on as many devices as possible, however it is important to understand that older devices running older software will not necessarily be able to run the prototypes properly. It is more important to make sure that the prototypes work properly on the devices and in the browsers that are most common today and not to get too hung up on making sure it is compatible with older devices and older software that very few people are actually using.

In my January 8th-12th reflective journal I evaluated this data from Statista.

As can be seen from the graph, Android and iOS have always been the two most popular platforms (or at least between January 2013 and May 2017 which the data shows). Windows Phone was once definitely the ‘third platform’ and was popular between about June 2013 and August 2015, but since then its popularity has been declining as fewer devices running the operating system have been launched (only a handful have been launched since the release of Windows 10 Mobile – only around 5 handsets in fact!) and in October 2017 Microsoft eventually discontinued Windows 10 Mobile and started focusing their attention on developing apps for Android instead. Microsoft now even has popular Android handsets such as the Samsung Galaxy S8 in their store preinstalled with Microsoft Android apps. It’s a similar story with BlackBerry which has had almost 0% market share since April 2014. The company no longer produces their own BB OS mobile operating system and instead now produces handsets running Android. ‘Other’ could be a range of operating systems including Java-based operating systems such as Samsung Bada which was Samsung’s own proprietary mobile operating system that most Samsung flagships ran before the company started selling flagship devices with Android in 2010 starting with the Samsung Galaxy S. It could also include Nokia Symbian which again was another proprietary mobile operating system that most Nokia flagships ran before the company started using Windows Phone on most of their devices in 2011. ‘Other’ could even include Palm OS which was once a very popular operating system for Palm PDAs and smartphones but has long been discontinued now. These operating systems made up around 0% of the market share even back in 2013, some 5 years ago, so are not at all relevant today and very few people are still using devices old enough to run these operating systems as ‘daily driver’ devices.

Looking at the most current data in this graph, Android and iOS are the two most popular mobile operating systems, therefore it’s important that the websites run on browsers compatible with these operating systems. With the market share of Windows Phone/Windows 10 Mobile, BB OS and ‘other’ being somewhere between 0 and 2% in May 2017, it would be nice if the site also worked on these devices just to serve the few who do still use them (myself included, at the time of writing I’m still using a 2014 Nokia Lumia 930), but it’s really not a problem if the prototypes don’t work great on these less-common devices.

The next thing to consider is browser market share for Android and iOS. This is something that I researched back in December when I was writing about Bulma and web analytics. Whilst there are many browsers available for iOS and Android, generally iOS 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. It’s evident then that the prototype needs to be compatible with Safari on iOS and Chrome on Android. It should also be tested with Chrome on iOS too.

Desktop testing is important too since the site needs to work on desktops too. There are two things to take into account when testing on desktop and laptop devices. The first one is the browser again. When I was researching this in December to explain my web analytics data, I found out that 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. It’s therefore essential that the website works in this browser. Firefox is the second most widely-used browser in the world with 13.9% of the market share so it is also important that the site works well in Firefox too. Other browsers such as Opera and Microsoft Edge and Internet Explorer are likely not that important. My user research concluded that Google Chrome was the preferred browser of my user research sample.

I added this question to the original user survey that I made several weeks ago after I had received 10 initial responses and then put the survey on Mumsnet in the hope of collecting more data. Unfortunately, only 4 people on Mumsnet answered the survey which is why I haven’t written up a full analysis of the extra data collected from Mumsnet, but here it can be seen that the majority of users use Chrome. Not surprising given that it is the most commonly used web browser in the world.

Screen resolution is the next factor to consider which also ties in nicely with a critical part of the testing which will be assessing whether the media queries break at the correct point to make the site responsive across a range of resolutions. On desktop devices, the most common screen resolution is 1366×768 (‘HD’) which the displays on most 15.6″ mid-range laptops that people own have. 1920×1080 (‘FHD’ or ‘Full HD’) is the second most common screen resolution – this is common on televisions and most 22-27″ monitors have this resolution. At the beginning of the decade 16:10 resolutions such as 1280×800, 1440×900 and 1680×1050 were common on laptop displays and desktop monitors but these days the widescreen aspect ratio is generally now 16:9 so the likes of 1366×768 and 1920×1080 are more common. ‘Square’ 4:3 (1024×768) and 5:4 (1280×1024) displays were also common but are rare now and have been replaced by widescreen monitors.

So, the media queries need to make the site look good on 1366×768 and 1920×1080 displays but really the media queries should be able to make the site look good on a wide range of resolutions.

List of devices I envisage to test the next prototype on

Based on the research above and the devices that I have available to try the prototypes on, I aim to try the website on the following devices. Devices in italics are devices that I don’t personally own or have direct access to but either the university or my friends own that I hope to be able to borrow.

Desktop prototypes

• Desktop PC with Windows 10 with Google Chrome, Mozilla Firefox, Opera and Microsoft Edge installed. 24″ 1920×1080 16:9 and 22″ 1680×1050 16:10 monitors.
• Lenovo ThinkPad T440s Touch with Windows 10 with Google Chrome, Mozilla Firefox, Opera and Microsoft Edge. 14.4″ 1920×1080 16:9 touch display.
• Desktop PC with Windows 7 with Google Chrome and Mozilla Firefox installed. 27″ 2560×1440 16:9 monitor.
• Apple MacBook (Google Chrome and Safari installed, various specifications and screen sizes – I have several friends with them)

Mobile prototypes – Apple

• Apple iPad 4 (November 2012), iOS 10.3.3, Safari and Chrome installed (9.7″ 2048×1536 4:3 display)
• Apple iPhone 6 Plus (September 2014), iOS 11, Safari and Chrome installed (5.5″ 1080×1920 16:9 display)
• Apple iPhone 6s Plus (September 2015), iOS 11, Safari and Chrome installed (5.5″ 1080×1920 16:9 display)
• Apple iPhone 7 (September 2016), iOS 11, Safari and Chrome installed (4.7″ 750×1336 16:9 display)
• Apple iPhone 7 Plus (September 2016), iOS 11, Safari installed (5.5″ 1080×1920 16:9 display)
• Apple iPad (‘2017’ / ‘5th generation’) (March 2017) , iOS 11, Safari and Chrome installed (9.7″, 2048×1536 4:3 display)
• Apple iPhone X (September 2017), iOS 11, Safari installed (5.8″ 1125×2436 19.5:9 display)

Mobile prototypes – Android

• Samsung Galaxy S4 Mini (July 2013), Android 4.4.2 Lollipop, Chrome and Samsung Browser installed (4.27″, 540×960 16:9 display)
• Samsung Galaxy A5 (2017) (January 2017), Android 6.0.1 Marshmallow, Chrome and Samsung Browser installed (5.2″, 1080×1920 16:9 display)
• Samsung Galaxy S6 (March 2015), Android 5.0.2 Lollipop, Chrome and Samsung Browser installed (5.1″ 2560×1440 16:9 display)
• Samsung Tab S2 8.0 (September 2015), Android 5.0.2 Lollipop, Chrome and Samsung Browser installed (8.0″ 2048×1536 4:3 display)
• Samsung Galaxy S7 (March 2016), Android 6.0.1 Marshmallow, Chrome and Samsung Browser installed (5.1″, 2560×1440 16:9 display)
• Samsung Galaxy Note8 (September 2017), Android 7.1.1, Chrome and Samsung Browser installed (6.3″, 1440×2960 18.5:9 display)

Mobile prototypes – Windows Phone/Windows 10 Mobile

Note: due to low market share mobile Windows platforms are not testing priority, however the prototypes can be tested on the following devices to check compatibility.

• Nokia Lumia 710 (December 2011), Windows Phone 7.8, Mobile Internet Explorer 9 installed (3.7″, 480×800 5:3 display)
• Microsoft Surface Pro (February 2013), Windows 8.1 Pro, Internet Explorer 11 and Chrome installed (10.6″ 1920×1080 16:9 display)
• Nokia Lumia 925 (May 2013), Windows Phone 8.1 Update, Mobile Internet Explorer 11 Update installed (4.5″, 768×1280 5:3 display)
• Nokia Lumia 625 (July 2013), Windows Phone 8.1 Update, Mobile Internet Explorer 11 Update installed (4.7″, 480×800 5:3 display)
• Nokia Lumia 930 (April 2014), Windows 10 Mobile (Anniversary Edition, Build 14393), Edge 38.14393 installed (5.0″, 1080×1920, 16:9 display)

This is a large range of devices that represents three or four different operating systems, different browsers and different devices ranging in age between 7-8 years old and less than a year old as well as some flagship, some mid-range and some low-end devices. If I can test the prototype on all of these devices or at least some of them then I can be fairly sure that the final site will be compatible on the devices that it needs to be compatible with.

Testing with real hardware vs emulations.

Sometimes things need to be tested on real hardware because emulations aren’t always accurate. Look at the photo below of the current Nellie’s Nursery website running on an iPhone 7 (in my hand) against how Google Chrome’s device emulator believes the page will render on an iPhone 7 (the video demonstration of this from my 5-9th February 2018 reflective journal is also beneath the photograph). As you can see, it looks completely different when running on actual hardware, possibly due to the current mobile site being activated only when a certain media query is triggered which clearly only triggers on physical hardware (it’s likely that the max-device-width and max-device-height properties were specified in the code rather than simply max-width and max-height).

 

Another oddity that I have seen first-hand is how mobile sites are rendered in Microsoft Edge. I know that I’ve said that Windows Phone and Windows 10 Mobile is not a priority for compatibility due to its ever-shrinking market share, but it’s interesting to note that the latest prototype (version 5.5) of the Storehouse Online magazine website that I have been developing for my university displays very different in the desktop and mobile versions of Edge – despite them actually being the same app. The prototype is shown running in the desktop version of Edge on the left (but the window has been resized to mimic that of a mobile device and activate the media query), but shown right is a screenshot of the prototype running on the mobile version of Edge (essentially the same app because Windows 10 UWP apps, which Edge is, are the same app!) on the Nokia Lumia 930.

The only explanation I can come up with for this is that the slightly older version of Edge running on the mobile device has trouble rendering the page correctly or isn’t handling media query correctly, but the point is that had I not tried the prototype on the mobile device I might not have spotted this mistake until after the product had been launched. In the case of it not working great on Edge, it’s not a huge deal – especially since it’s the mobile version and with the market share of Windows 10 Mobile devices being very very small it’s likely nobody would have complained, but had this also had been on issue on Safari or Chrome running on Android or iOS devices it would need to have been resolved especially if most traffic is anticipated to be coming from these browsers running on these devices.

As it turns out, it runs fine on those browsers and platform, but there are some other small bugs that need to be ironed out.

The emulation mode in Edge itself isn’t particularly accurate. Look at the animation below – firstly it shows the page is rendered perfectly on all of the Windows 10 Mobile devices I tried it on (the Lumia 650, 950 and 950 XL) which if the screenshot above from the (slightly older, admittedly) 930 is anything to go by, is wrong. Secondly, if the page does render properly on a large device like the 950 XL, it will actually render a little like it does in the screenshot below which is taken from an iPhone 8 Plus – a similarly-sized phone. Even on the older and smaller Samsung S4 Mini this site renders better than the Edge emulation thinks a Lumia 650 would – which is crazy. If you were to actually open up this site in Edge on a Surface Pro 4 you’d also see the desktop site – not a mobile view as the emulation mode suggests.

Testing in emulators also does not give you any kind of idea about the ergonomics of the website either. When you actually use the website on a device you’ll be able to see if buttons are too small to tap or so far away that you have to stretch your fingers which makes it uncomfortable to use. Ergonomics play a large part of user experience and can sometimes be forgotten about when designing mobile sites. Sometimes I feel developers get too carried trying to make sure everything ‘fits’ rather than considering how you actually hold a smartphone or a tablet and where the buttons need to be placed on the website so that they are easy for you to press whilst using the device. You can also rotate the device and see how the website looks when the device is rotated.

If you test it on real hardware it’s also easier to hand the prototype over to a user to test as well.

And as has been demonstrated twice now, although the emulator in Google Chrome is for the most part accurate, there are big benefits to actually testing on real hardware. I will initially test on an emulator and then upload the site to the internet to try it on mobile devices.

Footprint and load times

Load times is something to be wary of. As I discovered when doing my initial research on nursery websites back on January 17th, too many nursery websites have a lot of multimedia content on the pages that means that they can take a long time to load even on decent internet connections. My internet speed at home where I researched nursery websites that evening is 28.16 MBps download and 1.82 MBps upload. The average UK broadband speed in April 2017 according to Ofcom was 36.2 MBps download and 4.3 MBps upload. However, different sources online will quote different figures, A Guardian article from August 2017 for example quotes the average UK download speed being 16.5 MBps which they say is slower than 19 other European countries, New Zealand and the United States and only 31st fastest in the world. An article on Wired which was written at the same time (August 11th 2017) quotes the same download speed figure and the same ’31st fastest in the world’ ranking. It can be assumed then that the average UK download speed is somewhere between 15 and 35 MBps and that my connection at home is probably ‘very average’. The site therefore needs to loads in a reasonable amount of time on speeds like this.

With caching disabled (to imitate a ‘first time visit’ in which no files downloaded from the website have been stored on the user’s computer to improve the load time), the current prototype loads in 890 milliseconds on my connection and downloads 1.2 MB of data from the server on my 28.16 MBps down internet connection. The biggest file it downloads is the feature image which is a 680 KB PNG image and takes 587 milliseconds alone to download. That makes this image roughly 57% of all data downloaded and roughly 66% of the site’s load time is loading this image on my connection. At the moment the prototype features very few images but there are several ways in which this load time can be improved:

• The file type can be changed from PNG to JPEG to make it smaller.
• The resolution of the file can be changed.
• Host content such as images and videos externally to speed up load times (and save web space!)
• A preloader written in JavaScript and HTML can be used to only load assets that need to be displayed on the page at the point of loading to speed up page load times.

I have spent the past month researching preloading content for the Storehouse Online magazine website which is a very multimedia content-heavy website. By writing my own preloader for the site using JavaScript and HTML I was able to reduce the site’s load times dramatically (almost halving them). When the current prototype of that website (version 5.5) is loaded with cache disabled on my connection it takes 1.47 seconds to load the home page, yet is transferring around four times the amount of data that the Nellie’s Nursery prototype is. It manages to load reasonably quickly because the preloader is optimising the Storehouse website’s home page to load only the assets that are required at the point of the home page loading. There are other images on the site that are stored on the server, but they are not downloaded until the user needs to access them, meaning that initial load time is much-improved. At the moment, the images in the slideshows are taking a lot of time to download and contributing to slower loading times – these don’t need to be loaded until the user actually starts swiping the slideshow, so a preloader can be used to only load these images when they are required too.

Expected download sizes and load times

I don’t envisage having a lot of data on the Nellie’s Nursery website, certainly no more than about 15-20 MB and on the average UK broadband speed the site should should load in well under 3 seconds (with or without the assistance of a preloader).

With this being mobile-friendly too, mobile broadband speeds also need to be considered. On Google Chrome’s ‘Fast 3G’ preset (which throttles your broadband speed to that of ‘fast 3G’), the present prototype, which does not have a lot of content on it yet, takes 8.54 seconds to load with 7.07 seconds (83%) of that load time being down to the feature image again. On ‘Slow 3G’ the site took a massive 30.85 seconds to load, with 25.97 seconds (84%) of that being the feature image again.

The average UK 4G download speed according to Ofcom research in November 2014 is 14.82 MBps (I calculated this by working out the mean speeds of the five providers Ofcom provided data for). I made a preset in Google Chrome to throttle my download speed to this and recorded the results. It took 1.92 seconds to load the home page, with 1.60 seconds of that (83%) of that being to load the feature image. Interestingly, I was able to calculate that the average time taken to load a page on 4G in the UK using Ofcom’s data is 1.054 seconds, so my prototype taking 1.92 seconds is slower than average – because there is not yet any optimisation.

Given that the full site isn’t finished yet and that the average page takes just over a second to load on 4G, I expect that on 4G my site should not take more than 1.2 seconds to loaf (with or without the assistance of a preloader) and on 3G my site should not take more than 15 seconds to load (with or without the assistance of a preloader).

On mobile devices it may be possible to download smaller, lower resolution versions of images to help improve load times, reduce the amount of data downloaded and then in turn reduce the user’s mobile data bills. If possible I will implement this.

Responsiveness and media query breakpoints

Extensive testing of Mobile Prototypes 1 and 2 which is documented in the past few reflective journals has proven that the current media query breakpoints are almost perfect and ensure that the prototypes display well on a wide range of mobile devices (both modern and slightly older) and also work fluidly in web browsers. See the video below.

The current 5-point break system of Mobile Prototypes 1 and 2 works very fluidly when resizing the browser window and also when viewing the site on different devices. It likely won’t need to be changed an awful lot but some elements will need realigning a little and the landscape orientation media queries need to be written to ensure that the site works properly in landscape mode too. Perhaps in landscape mode having the menu bar at the bottom will take too much screen space, so maybe it will be repositioned to either the left or right side of the device. The tiles may need realigning and in landscape mode the hamburger menu will need to be made smaller.

The way responsiveness will be tested is by trying the site on different devices, emulators and different browser sizes – keep dragging the browser and see if there are any glitches or elements out of line at certain resolutions.

Wednesday 28th February

The snow was so thick today that the bus companies cancelled all of their buses meaning that I was housebound. Never seen snow as thick as this in my life – I went out briefly for a bit with the camera to get some photos and at some points in the fields the snow was actually knee-deep! Being stuck at home was no problem for home-working though as I knew that today I wanted to focus on thinking about what analytics to collect on the final version of the site when it goes live.

Why collect analytics?

When writing up about my web analytics project which was completed in December 2017 and early January 2018, I explained the importance of web analytics. The first few paragraphs of that post go into detail about the importance of web analytics and even give some hypothetical scenarios about why web analytics, but to summarise web analytics are essential because:

• They can help developers further improve a website by analysing user actions and using this data to improve usability and add functionality, thus hopefully enabling a better user experience.
• They can be used to see which devices and browsers the site is being visited from, so the site can future be better-optimised for these devices and browsers that the client-base is using, thus enabling a better user experience.
• Analytics data such as user locations, user age and even things like the number of button presses to complete tasks can be used to better-optimise customer experiences depending on regions and also help identify certain parts of a website that need to be improved.
• Different departments of a company can use analytics to benefit their department and meet department needs. For example a marketing department might want to see which products are selling best and which product pages are having the most views by looking at analytics. They then know which products are selling well and could be promoted to increase sales even further. Or, they can see which products are not selling well and need promoting.

These are just a few general reasons why web analytics can be useful.

Why collect analytics on the Nellie’s Nursery website?

For the same kind of reasons as described above really. All of the below should have already happened in testing but the site can be developed post-launch and when developing post-launch you have solid customer profiles to work with to develop features.

To measure usability and information architecture event flows produced by web analytics can be used to see if users are mistakenly clicking on pages combined with the length of time that a user spend on pages and the bounce rate. If the bounce rate is high and the users are not spending long on a page but are visiting it frequently it could be considered that it has been clicked on mistakenly perhaps and therefore the information architecture needs adjusting so that the information that the user is trying to find is on the correct page.

To improve the experience on common devices, the devices and browsers that the users are accessing the site with can be analysed and then the site can be fully tested and optimised for these devices.

The menu system in Mobile Prototype 3 will essentially be based off user testing at first with the testers being the ones who will be asked if the home and contact buttons should be fixed or whether other ones should be too. Analytics data when the site goes live will confirm that these are the most commonly-used pages on the nursery website (as initially inferred by user research) and if they’re not, the two most visited pages will have the icons fixed on the menu bar.

What data to collect on the Nellie’s Nursery website?

Luckily, the basic Google Analytics collects a lot of data with only a few lines of code added in the head tag on each HTML page, such as:

• User location
• User device, browser, operating system and screen resolution
• Event flows, bounce rate and time spent per page
• Most visited pages and acquisition channels

All of this data is more-than-likely enough to measure the usability of the site and also which pages are getting the most hits, which is only really all that needs collected. Device and software data is also good to have too for reasons mentioned earlier.

The only thing that Google Analytics doesn’t do by default is event tracking – you need to code that in. Event tracking isn’t something particularly important on this website since it is going to be a fairly basic information website, not really a website with a lot of interactive content like videos and games. It would be good to have event tracking on the buttons so that it can be seen which buttons are clicked on the most which will help to measure usability and page popularity. Event tracking could be added to slideshows – it would be useful data to have to identify if the users are interacting with them or not (and on which devices). If the users are not interacting with it much then it could be assumed that it is not intuitive to use. Testing data from February 15th and 18th already suggests that this could be the case with some testers.

Testing data from the initial prototype shows that only 43% of testers instinctively thought that swiping the slides would advance them (even though during the testing the desktop prototype was running on an iPad – a device with a touchscreen).

Thursday 1st March

A bit of project management and remote working today since I am still stuck in Wymondham due to the snow.

Project management

One of the tasks to complete this week is to create a Gantt chart of the two week development time which begins on Monday 5th March and ends on Friday 16th March. In this time I have two weeks to develop my prototype and hopefully come close to producing a final functioning website. The Gantt chart is designed to help you think carefully about the tasks that need to be completed and also help to think about how long these tasks are going to take to complete in the order in which they need to be completed in in order to have a good outcome. Like the last time I had to make a Gantt chart, I made it in Microsoft Project Professional because it is quick and easy to do and I own a copy of Project Professional 2016 so it makes sense to use it.

I started by thinking of all of the individual steps that will eventually lead to Phase 2 Testing which I hope to do on Friday 16th March in the UX lab at university with students from other courses at NUA. I quite like doing things in chronological order, so although not all of the tasks are dependant on the previous one being completed first, they will all be done in the order shown in the timesheet view on the left of the Gantt chart.

Since the prototype is evolutionary, the next prototype will be an evolution of Mobile Prototype 1, so the majority of the code has already been written and tested (including the media queries), so developing the next prototype should only really involve implementing the new menu system which has been described earlier in this post, making sure that images and other elements are aligned properly and also adding actual copy and content to the site. There will also likely be smaller refinements that need to be made to ensure that the page looks and performs as good as it can.

An embedded PDF version of my Gantt chart is below, but please note:

• Although the times shown on the Gantt chart are when sessions at university are running, it is more than likely that I will continue to work on this whilst I am at home and during hours that aren’t marked on the Gantt chart. This means that the project may be completed faster than expected on the chart or that some more complex tasks can be done within the timeframe specified on the chart.
• All timescales are approximate. The timescales are based on how long I personally think it would take me to complete the given task based on my knowledge, skills and of course the complexity of the task and what kind of issues I might run into whilst trying to complete that task and how long they might take me to resolve. I have an idea of some issues that I may run into and how I can resolve them (and more importantly how long that’ll take), but the ‘unexpected’ may occur. For example it took me almost a whole day to resolve an issue with running multiple Siema slideshows on the same page prior to the February 2018 testing. I was not expecting to spend that long on a problem like that, so unfortunately the ‘unexpected’ can be just around the corner and sometimes things that should be easy to fix can take the longest to fix!
• There are no tasks scheduled for Friday 9th March because I have a very busy schedule on this day and I know that I probably won’t be able to get a lot (if anything) completed. Instead, the tasks that I would have done on 9th March have been moved to Saturday 10th March. I’ll likely be working over the weekends on this anyway though.
• Not on the Gantt chart, but a massive consideration: whilst I am doing all of these tasks I will also be documenting it in my production diary.

For a non-embedded version of the Gantt chart, please click here.

Some of the tasks I have set myself are more like ‘sub-tasks’ than actual tasks, for example Tasks 2, 3 and 4 could all be grouped under one task called ‘Create the new menu system’ which would theoretically take from 15:00 on March 5th to 13:30 on March 8th to complete, but to be more precise, help time management and consider what is involved with creating a new menu system, I have broken it down into three separate tasks. The provisional testing has also been broken down into two tasks for the same reasons.

Explanation of the tasks

• Copying Mobile Prototype 1 and removing the menu system: the new prototype will be built on the codebase used in Mobile Prototype 1, so this prototype will be copied so that I don’t have to rewrite code and the menu system will be removed to allow for the new menu system to be put in its place.
• Creating icons for the new menu system: there are only two to make and although Mobile Prototype 1 already has these icons, they are going to be too small. I will make bigger ones. ‘Home’ and ‘contact’ icons are so common that it is likely that Adobe Photoshop already has built-in shapes for these that I can use, so this task will probably be extremely quick to do.
• Create the new menu system: this involves creating a fixed div at the bottom of the page, putting the buttons on it and then taking the code for the hamburger menu from Mobile Prototype 2 and copying it into the new prototype. This could be complex, but the hamburger menu icon does not need to change to a cross (‘X’) once the menu is opened, so it is a little less complex.
• Refine the menu system: once it is working there might be minor improvements to make such as implementing the hover effects, altering the speed and animation of the hamburger menu and making sure that all of the items on the menu bar are aligned.
• Provisional testing: I want to get two or three of my peers on my course to try my design to see if they suggest any improvements before development goes further.
• Make changes to the menu: any changes that my peers suggest will be acted on to further improve the menu system.
• Reevaluate the media queries and refine as needed: check to make sure that the 5-point break system is working correctly and as expected. I may need to modify the media queries for the menu bar depending on the size of the new menu.
• Ensure that all images are responsive: in Mobile Prototypes 1 and 2 the Siema slideshows are responsive but the picture buttons for the groups on the Groups page aren’t, so these need to be made responsive probably using media queries.
• Add copy to the pages to replace Lorem Ipsum: it’s not just copy text, it’s also actual content such as photographs. I may be able to visit the nursery to take photographs, but I may not be able to. I’m not sure how much Lorem Ipsum I will be able to remove, but I’d like to remove as much of it as possible to give the prototype the feeling of a higher-fidelity piece of work. Full copy and content should definitely be applied over the 3 week Easter break if it can’t be applied at this time though.
• Run a testing session with people on other NUA courses: for reasons explained in the February 2018 Prototype Testing post, the next round of testing should be done with people who have never really seen the prototype before and study different courses so that I can get different insight.
• Review testing data and create a strategy for the next stage of development: testing data will be analysed and evaluated a little like it was previously and this data will be used to shape the direction of the project. I will create a strategy for where the project needs to go moving forwards. At the moment I assume that this will be making minor changes that user testing has suggested and also adding more actual content onto the site.

My personal thoughts on project management and Gantt charts

My thoughts are mixed!

On one hand, the project is exciting and interests me and it’s important to not just jump into things and do it all without thinking or planning, but on the other I find making Gantt charts a bit boring and I just can’t get excited making or looking at Gantt charts. I also have trouble sticking to them as I tend to be too strict with myself when creating them, i.e. I don’t allow enough time for tasks or try to factor in ‘the unexpected’ that makes tasks take longer than I initially anticipate. By breaking tasks down into smaller tasks I have subconsciously managed to give myself more time to complete the ‘whole task’ and have also thought more thoroughly about the individual tasks involved, so this exercise has helped me really think about what needs to be done and how long they might take.

Sometimes I can get excited about the future of a project when planning – and this time I really am! I can’t wait to start making the next prototype and test it out and see what people think. I don’t think I find planning boring or unnecessary, sometimes I just find it not as interesting as the other parts of the project but it is vital in order to achieve a great outcome that fulfils the requirements specification.

I’m going to try and stick to this Gantt chart just to see if I can plan a project (or part of it) and actually stick to the timetable.

Initial stages of Prototype 3 testing planning

Planning for Mobile Prototype 3 (and the updated desktop prototype to go with it) is already underway even though no code has been written for it yet! As of 11.00pm tonight I have six people who are available on Friday March 16th to test Prototype 3 in the UX lab at university, namely:

• Callum Brown (Year 2 BA Graphic Communication)
• Jeremy Downes (Year 2 BA Graphic Communication)
• Elena Lockyer (Year 2 BA Graphic Communication)
• Emma McIlwaine (Year 2 BA Graphic Design)
• Harriet Taylor (Year 2 BA Fashion Communication & Promotion)
• Joshua Garner (Year 3 BA Visual Effects (‘VFX’))

There is the possibility that there might be some other people who can test the prototype too.

The UX lab has been booked for March 16th, so testing will go ahead on this day unless lots of my testers decide they can no longer make it or for whatever reason the prototype isn’t ready to be tested.

I know that Emma has already contributed a bit to the design of this project as I have shared a bit of my work with her, but she doesn’t know my testing procedure or what she will be tested on, so whilst she will have a slight advantage in some areas (for example navigation), I am still happy to include her in my testing. I have deliberately held back from telling her about my testing strategy as I had her down as a potential tester before I asked her. The other students don’t know much, if anything, about the prototype and certainly nothing about my testing strategy. They are all friends of mine so I will have to make sure that I don’t reveal too much about what I am doing to them in general conversation in order to help keep the test fair.

I feel that this time round I will have a much better mix of men and women testing my prototype and it’s good to have people who are not doing BSc courses test the prototype to get different perspectives. The only thing that these people do have in common is that many of them come from a design background (which the typical nursery site user wouldn’t necessarily) and they are all of the same kind of age. But this doesn’t matter too much given the small scale of the project and the fact that at this prototype testing stage people who have interest and knowledge in design can provide very insightful feedback

Since none of these people have tested my previous prototypes, it’s absolutely fine to use the same questions and testing strategy. I will be doing an A-B-C test of the desktop website, Mobile Prototype 2 (the previous generation prototype) and Mobile Prototype 3. The aim will be to see if:

• Information is easy to find and where the tester expects it to be.
• Users prefer the menu system on Mobile Prototype 2 or Mobile Prototype 3.
• Users prefer the ergonomics of Mobile Prototype 2 or Mobile Prototype 3.

And of course I will interview each tester afterwards to allow them to discuss their experience with me and suggest any changes, just like last time.

I will be using the mobile device testing rig again and using eye-tracking – but this time I appreciate that whilst it can be useful, it is not the end of the world if the data it produces isn’t 100% accurate as observation and the answers that the candidates give in the interview afterwards is more important to me as it is easier to interpret.

Remote working

So, being stuck in the snow for the past few days has opened up some remote working opportunities for me. Yesterday I was on Skype with Emma working on our next project (details to follow soon!) since we couldn’t meet at university to discuss it. We found Skype’s screen sharing functionality quite helpful as Emma was working on the project on her MacBook and sharing the screen with me over Skype so that I could see what she was doing. Today I have also been using Skype to communicate with peers on projects, this time I was on Skype with four members of the Storehouse team who I am working with to make the Storehouse magazine website. We talked a little about content layout for the article pages but interestingly, we were also talking about how we could employ analytics on the Storehouse website to measure how popular certain articles were and promote those that weren’t getting as many page views. We also discussed how we could use event tracking in Google Analytics to see which videos were the most commonly played. I also introduced the team to the idea that analytics data can be used to further enhance the website once it has been launched because we will be able to tailor features to our target audience, including making sure that the website is fully compatible with the devices and software that our readers browse the site most with. It’s great to see that I learn on this BSc User Experience Design course can be transferred to other projects outside of my course too.

Thoughts on remote working

Remote working or working from home is often deemed to be ‘the way that the office is going’ and has benefits such as you don’t need to commute to work, thus saving time and money and potentially helping to save the environment by not burning fossil fuels when travelling, but generally it’s not really something that I would choose to do. When I work at home I can get a lot of work done because I am alone and there is little (besides the internet and my phone!) to distract me, but working at home I find can be quite lonely and I like to talk to peers and ‘bounce ideas’ off from them. If I just need to get a lot of work done that doesn’t require input from other people, for example writing this post, then I am fine with doing it at home alone with some music to accompany me. But if I am working with people on projects or really need to talk to them in order to get work done, then I’d much prefer to go and see people and talk face-to-face with them. But it’s great that I can rely on technology as a second resort for when this isn’t possible, like recently when the weather has prevented me from being able to get into university.

For some industries where not a lot of team work or talking face-to-face is required to complete a task, I can see that remote working is potentially a good alternative to having to pay for an office that staff need to commute to in order to work. However, for the creative industries I feel that remote working simply won’t take off that much because we need to talk to each other in order to move forwards with our work. The only time I can really see Skype or similar being used in place of an office for the creative industry is if you need to communicate with people who are a long way away from you or if you are freelancing and want to connect with clients without having to meet them all the time. When I went to Redgate last week I saw this as my peers and I sat in on some Skype calls with Redgate employees who were working overseas which gave us an insight to remote working in the creative industry. Sometimes I find Skype and similar products a little annoying to use because the call quality depends on the internet connection of both parties and the audio quality is never that good unless you are both talking through a dedicated microphone (not one that’s built into a webcam that picks up all sorts of background noise), so communicating can actually be quite hard!

I went to university to meet new people and make more friends to bounce ideas off, so to me personally remote working defeats the idea of going to university. This is why I always try and attend as many sessions at university as possible and have gotten involved with a lot of different societies and projects with a wide range of people.

Friday 2nd March

Today I thought about changing the names of my prototypes to make referring to them easier and also started looking at possible careers in the UX industry.

Introducing Elebase!

‘Elebase’ (pronounced ‘Ella-base’) is the name of the framework (or codebase) behind my prototypes (and eventually the final version) of my nursery website. ‘Ele’ is derived from ‘elephant’ (referring to the elephants in the logo for Nellie’s Nursery) and ‘base’ is derived from ‘codebase’ – the ‘base’ of the website.

It can be assumed from now on that all future Elebase prototypes will have a desktop and a mobile version, so instead of referring to the prototypes as ‘desktop prototype’ and ‘mobile prototype’, I will simply refer to future prototypes as ‘Elebase 3’, ‘Elebase 4’ and so on. This will help to make referencing the prototypes easier.

As of now I have renamed ‘Mobile Prototype 3’ to ‘Elebase 3’ which also refers to the 3rd generation of desktop prototype too.

Entering the wonderful world of UX as a career

Today I began looking at careers in the UX industry. I’ve always wanted to work in technology, and in fact I did for a year! When I was much younger I was interested in aircraft, specifically military aircraft, so I felt that a career in the Royal Air Force would be ideal for me. However, I didn’t want to be a fighter pilot (I knew that my hearing and later my eyesight meant this wasn’t possible anyway), I wanted to either be a mechanic, work in air traffic control or work in the RAF’s IT department. The idea of plugging Eurofighter Typhoons into diagnostics hardware to diagnose hardware or software faults with them interested me! As I grew older and became an Air Cadet and saw what life might be like in the RAF, I decided that I’d stay as a civilian, but I wanted to work in technology still. I had big ambitions of working for companies like Microsoft, Dell, HP, Lenovo, all the big brands, but I never really knew what I wanted to do. I got more and more into photography and even considered working as a wildlife photographer for the likes of National Geographic or a wildlife videographer for the BBC as my dream job. I very nearly pursued an A level subject choices that would take me into a media-based career like these. Then, quite by accident, in November 2013 I began a four year relationship with Microsoft (which has really only just ended at the time of writing this) which reignited my interest in working in the technology again – but I didn’t know what I wanted to do!

My work with Microsoft involved working with the UK (and later worldwide) Education team to promote the use of the new (at the time) Surface Pro 3 tablet and Office 365 software as a perfect hardware and software combination for students to use to record their notes in class. The school that I was attending at the time became a Microsoft Showcase School in November 2014 because of how we were using Microsoft technology in our school in such an innovative way. As a student I was able to use all of this groundbreaking hardware and software in my lessons and fully understood how they were impacting students’ lives in a positive way and Microsoft had their attention on me. Earlier in 2014 as all of this was starting I was invited to visit the Microsoft TVP in Reading which is Microsoft’s UK Headquarters to learn about the new features of Office 365 and new devices that were going to be available. I was one of the very first people to use the Surface Pro 3 in the UK! In May 2015 I was able to attend the Microsoft E2 Global Educator Exchange at their worldwide headquarters in Redmond, Seattle, USA, where I even got to meet Microsoft CEO Satya Nadella and learn more about how Microsoft technology can be used in education as well as deliver some presentations about how I felt that a curriculum could be delivered through the means of technology. Later on in October 2015 at the Microsoft Redefining Learning event in London I also delivered a presentation about technology in education. This event was also the first time that the SurfaceBook and Lumia 950 and 950 XL Windows 10 phones were shown in the UK so again I was one of the very first people to have used these devices. The event also featured the launch of ‘The Feed’, a Microsoft in Education publication that was sent to schools in the UK to encourage them to use technology in education and also to tell them about the latest Microsoft Education news. My photograph of a Surface Pro 3 sitting on a pile of folders to symbolise the fact that the Surface and OneNote could replace several heavy folders went on the front cover.

Microsoft also filmed a slightly slapstick/humouristic video of how students can be used to enhance IT support in schools at our school in October 2015, which myself and several of my then-friends appear in! One of the people in the video, Ben Leach, also attends NUA (he studies BA Photography).

I did all of this when I was 16, 17 and 18 and for a long time felt that my career was dead-set in the direction of education. After I finished A levels in June 2016 the Microsoft links with my school ended and I worked at my school (and a local primary school) working in IT support for a year which I did not enjoy so much. I felt that it wasn’t stretching and one technician’s job is much like another and there is little opportunity to grow in this career path, so changing careers meant I would need to retrain. I also felt that I was capable of more than diagnosing computer problems – I wanted to be on the ‘front-line’ working with the latest and greatest technology! What better time to retrain than when you are 19 and still young, free and have very little commitments and responsibilities – and have only been away from education for a year so still have that mentality in you? This is why I am now at NUA, learning the ins-and-outs of UX design. I am absolutely loving the course (as I hope my attention to detail and the amount of time – and words! – I put into it shows!)

I feel that the UX industry is definitely the industry that I want to go into now and there are so many places that I can go with these skills: Microsoft, Adobe, Dell, HP, all the big brands again, but there’s also UX in other industries besides ‘tech’ that really interest me. I’d love to explore UX in healthcare, the energy sector, motoring, flying, communication and all of these other disciplines that this course and the knowledge it is giving me can open me up to!

To see my research on careers in UX, please read my Careers in UX page.

Bibliography

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].

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].

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].

Ispreview.co.uk. (2017). Ofcom 2017 Study – Average UK Home Broadband Speeds Rise to 36.2Mbps – ISPreview UK. [online] Available at: https://www.ispreview.co.uk/index.php/2017/04/ofcom-2017-study-average-uk-home-broadband-speeds-rise-36-2mbps.html [Accessed 27 Feb. 2018].

Sweney, M. (2017). Average UK broadband speed slower than most of Europe, report finds. [online] the Guardian. Available at: https://www.theguardian.com/money/2017/aug/08/average-uk-broadband-speed-europe-germany-spain-singapore [Accessed 27 Feb. 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 27 Feb. 2018].

Ofcom. (2014). Ofcom publishes 4G and 3G mobile broadband speeds research. [online] Available at: https://www.ofcom.org.uk/about-ofcom/latest/media/media-releases/2014/3g-4g-bb-speeds [Accessed 27 Feb. 2018].