Prior to our Monday morning session, we were all allocated alpha testing slots. This was to enable us to be able to prepare accordingly, for either the morning or afternoon. I was given an afternoon slot so I joined my peers in the morning to test their digital experiences. It was an insightful task to be able to look at what stages my classmates were at and to see how much progress had been made over the 2 weeks build. It was also comforting to know that I was at a suitable stage in comparison to them because I had some previous concerns that I was dragging behind. Part of my alpha test was to ask questions to my testers about their opinions and views on some design aspects of my site. By helping someone else in my class who wasn’t sure on what to ask, I found myself thinking up new ideas of how to improve my own.
My tests took a long time to complete five times over because of the open-ended nature of my questions. Naturally, some participants are more talkative than others and are available to offer more insightful descriptions of their thoughts whereas others are quick on their feet and want to get their point across quickly and efficiently. I appreciate a healthy blend of both when my work is being assessed by others and a perfect example of this cropped up here. One of my peers is always very descriptive when they talk and work. They are always very detailed and this test proved no different. As usual, I got a lot of extremely useful opinionated data with substantial evidence to back up their thoughts. On the other end of the spectrum, one of my testers regularly shy away from written work and isn’t as detailed as the aforementioned student. Having said this, he is a superb creative and I have noticed his problem sorting skills are peculiar in that there is always an ‘away-of-the-norm’ way to fix things. It was this second student that pointed out that I had not presented the information in a way that is easy to consume. Upon questioning him of why he suggested this, he pointed out there are not a lot of visual prompts and the meaning of the site wasn’t obvious enough from the first scrolls through the page. It then dawned on me – was I so involved in my own project that I forgot to make the meaning obvious enough to new customers? Due to the minimal numbers in my class, we are usually all moderately aware of each others project themes, but even then he was still confused. In addition to this, he mentioned that the café and shop section only states that there is vegetarian and vegan food. Another query popped into my head in that I could not answer whether they serve any meat or not. Again, I was so involved in particular points of the project that possibly, I had forgotten to look at the bigger picture.
Immediately after I had completed my alpha test in the afternoon, I could already identify plenty of running themes within my qualitative data. I will be writing up these themes in full in the coming week after I have done more analysis into where and why similarities lie. However, from an initial look at the comments, most of the issues arose from plug-in incompatibility.
With the practical part of my behavioural testing complete, during Tuesday’s session, I wanted to look at the performance aspect of my alpha test. This involved testing three pages of my website on varying internet speeds to determine load time and in turn, efficiency. I used the throttle feature in Google Chrome’s browser because the web developer user interface, for this particular task, is a lot easier to navigate than it’s close competitor, Mozilla Firefox. Chrome features two in-built throttling presets, namely Fast 3G and Slow 3G. Alongside this, I referred to the Web Deployment Record sheet we are required to fill out and hand in with any web based development projects as this includes some more recommended presets. Though tedious, I enjoyed this task because I realised that initially, my homepage was loading very slowly because of the size of my images. My classmate saw me struggling and kindly suggested to me that I should save my images as PNGs instead of JPGs and keep them down to around or under 5MB to keep the quality up and the load time down.
I only had one type of testing left to perform and this was existential testing. To carry this out, I was to load my website on a range of desktop, tablet and mobile browsers. Due to existential testing concentrating more on the device and how it performs within different screen sizes and mobile browsers, I knew this would take a long time to complete as there were a lot of devices at my disposal. In light of this, today I started on desktop and mobile devices. Using a combination of my laptop and the university computers (to be able to include Safari and Internet Explorer) I set about opening the homepage on each browser and finding the version numbers and screen sizes along the way. This was easy to accomplish and the only browser that didn’t comply was IE. This didn’t surprise me and only requires a small bit of code to resolve. Surprisingly (or maybe not for my fellow iPhone users who are familiar with AirDrop), my biggest challenge of the day was trying to figure out the best way to transfer files from the Samsung S7 onto either my laptop or university computer to upload onto my blog. I spent a silly amount of time trying to be clever with Bluetooth, Dropbox and other file-sharing platforms until James suggested I just use a cable. Lo and behold, it worked and I was successfully transferring files from here on out. By the time I uploaded files and formatted the results on my blog, existential testing my website on desktop and mobile browsers took the entirety of the afternoon to complete.
As a slight side note, apart from the file transfer complications, I was greatly impressed with using the Samsung phone and in particular its Scroll Capture feature. I haven’t been Android’s biggest fan since I bought an iPhone7 after owning a Sony phone for 2 years, and realised why they are so popular. Looking at a Samsung, Huawei would not be up my street. Having said this, I hadn’t seen this feature on a phone before today and I realised I should give Android another go and let me make a judgement on their new technology rather than my memories of its integration on a three-year-old device.
As a continuation of Monday’s work, I transferred my written data from my interviews with my testers into tidy, collapsible sections in my blog. I was able to do this with the help of the Spoiler plug-in, a recommendation from one of my classmates. I like this plug-in and try to use it whenever I need to write up results from interviews because it keeps all the information in logical, easy-to-read sections. The main part of my day, however, was writing up my thematical analysis. I was originally suggested to look at my results in this way by my tutor, Jamie. He suggested this because I have a qualitative data set. I’m really glad this was suggested to me because I hadn’t considered this before and this technique of looking at data is new to me. I was excited to learn something new and do some research on the benefits of this method.
To finish my week, I needed to tie up loose ends in my tests and make sure all testing was completed and documented before the Easter break. Firstly, I finished existential testing by testing my website on tablets. I do not own a tablet myself, therefore I was to use the ones provided by the university. I was given two tablets, one iOS and one Android, so I could at least cover the most popular bases. This was an easy task to complete as I used a cable to transfer files again so I didn’t have the same issues as on Wednesday. Generally, it is always a bit of a treat for me to be able to use a tablet because, as I previously mentioned, I do not own one myself. I think they are great devices and a nice halfway point between mobile and desktop but for my own personal needs, having one wouldn’t fit into my life. Unfortunately, I can’t justify buying one when I can easily achieve everything I need to (work related and socially) on my MacBook and iPhone. However, to touch on Android briefly, I was impressed by Samsung’s scroll capture feature again, even if the general user interface hasn’t quite won me over yet.
The second half of my day consisted of commenting the rest of my CSS and PHP code, writing a to-do list for my readme.md file and writing the rest of the readme file itself. Whilst writing my CSS code, I had already commented it along the way so today, I added detail where necessary and made sure it was completely clear what each code block does. I’m very pleased that I commented my CSS code along the way, not just because it was a requirement for the unit, but because otherwise I genuinely would be very lost. Due to the nature of my project, I do not have access to the HTML or JS files for my child theme, only the CSS. Each time I wanted to edit a part of my theme, I had to open the web dev tools and click the icon that allows me to hover over an element in the page and find its div in the HTML. The theme is written using the Bootstrap framework so I could make sense of some of it, but I never got on well with it in past projects. I tried to tackle and understand it when I didn’t understand coding in general very well and as a result, that put me off and confused me quite a lot. Nevertheless, even with a brief knowledge of Bootstrap, I knew I couldn’t remember every element’s relevance to the site off by heart. An example of this type of code is below:
/*parallax white background box*/
.col-md-8.col-md-offset-2.col-sm-10.col-sm-offset-1.text-center {
background: rgba(255, 255, 255, 0.7);
border-radius: 50px 20px
}
As you can see, I have commented that this code snippet relates to the white box in the parallax sections. It is clear to see that I would not have been able to remember this from reading the class name alone. On the other hand, commenting my PHP file was even easier because I only define one function and that is to enqueue the child theme to the parent theme. I considered commenting it in more detail but decided this to be too pedantic. Following this, I drafted up a to-do list from memory and wrote my thoughts down in a bullet-pointed list. I then skimmed over my user testing comments and smoothed the points off into well-rounded pieces of text so that even anyone outside of the project would understand. I now had to write a readme.md file which would feature my to-do list along with other pointers. I have never written a readme file before and in all honesty, I wasn’t entirely sure of its purpose until I did some research over the course of this week. I now see why it is relevant and, if written well, is extremely useful for users to gain knowledge of the project it speaks of. Upon the recommendation of one of my classmates, I used stackedit.io to create my readme file and found it a great platform to get the job done. I will definitely be using this online tool to create readme files for future projects. As soon as all of this was complete, I asked James for some help using GitHub and uploaded all my work for submission.