Review of Project Objectives and Wire-frames
I will still be working on the original focus of following Hick’s Law and not presenting users with too many stimuli in the menu bar. After reviewing the results of my prototype test, however, I will be applying some fundamental changes to the information architecture itself. I will be keeping all of the original content of the website but the first and second tier menu options have been revised. This has resulted in a change to the information wire-frame I previously created and is pictured below.
Additionally, the test has made me look at the whole project in a slightly different light. It has come to my attention that I should put more focus on adapting the menu features to accommodate content rather than my first approach of trying to fit content into predetermined headers I thought were correct.
Analytics
Unfortunately, Tigger does not have any Google Analytics currently set up on his website so I do not have any concrete evidence to compare my results to. I will be working purely from assumptions perceived from information Tigger provided me with during our last meeting and user data I have gathered from my survey. In my final build, the main analytics I plan to capture are listed and explained in more detail below.
- Event tracking on buttons such as VOLUNTEER and DONATE – Volunteering for and donating to The Greenhouse Trust are vital to the success of this as it is a charity organisation. By correctly monitoring the traffic through these buttons and pages they feature on, it is possible to maximise the size of the audience it reaches. If these turn out to be low, I will know that I have not made them obvious or eye-catching enough.
- Event tracking on call-to-actions – I plan to use these on the homepage because the parallaxes will mainly contain big call-to-actions with some smaller, informative text. These will lead users to other pages within the website and it will be interesting to see the bounce rate in conjunction with this.
- Bounce rates – Bounce rate measures how many visitors to the site looked at the page they were brought to and then abandoned the user flow by visiting another website entirely. If the content of the site is laid out correctly and is engaging, the bounce rates should be reasonably low. This site already attracts a lot of users who want to find out about current events and interesting articles. Tigger has placed all of the most important content at the top of the homepage so I assume his bounce rate is high. I hope to change this by creating links on the homepage to other interesting pages of the website, therefore extending average page clicks and extending user flows.
- User flows – I want to see how and why users visit the website so priority can be given to these main aspects. I can use the data from the survey as a good starting point, however, this information is taken only from six users and is written in their own words. Naturally, some people are more descriptive than others so these tests aren’t as reliable as being able to monitor people interacting with the website, creating raw statistical data. This ties well in with monitoring session times as well because
- Visits and visitors – Visits refers to what used to be called ‘hits’. This is the number of times someone visits the website, whereas visitors refers to a person who visits the site. If the same person visits the website twice, the visit rate will show two but the visitor rate will show one. If The Greenhouse Trust wants to attract new clientele, this is a very good way to measure how well it is achieving this.
- Page views – Plain and simple page view monitoring will show me which pages get more attention than others and this may lead to possible improvements on the weaker pages. Either that or they will need more attraction given to them from pages on the site. A low page view rate may be the result of poor navigation and signposting to that content throughout the site.
- Device visits – My survey showed that 83% of users view this website on desktop/tablet and the remaining percentage are active on mobile and tablet. Even though this survey was only sent to six participants, this is still a considerable amount of people who are swayed towards desktop. I wonder whether this is because the site does not scale well to mobile or tablet, therefore users simply do not wish to try and view it on other platforms.
White Box Testing Methodology
White box testing is a means of software testing where the testing participants are fully aware of what is happening in the background of the piece of software they are testing. For example, they know I am using WordPress and CSS to accomplish my final website design. All of my testers know how to use WordPress and how to code CSS so they will be able to give me a knowledgeable insight into any improvements I can make on the back end of my website. If any bugs or errors occur, we can go straight into a discussion about the possible source of the issue. This goes beyond testing just the user interface and ensures fully functioning code.
Alpha Testing
The main aim of performing an alpha test on my product will be to ensure readiness for the Beta test. I need to make sure the website works and does not produce any bugs or errors. This will be very unlikely to happen to me because I am using WordPress as my content management system (CMS). In light of this, any errors that do come up are most likely to appear in the form of missing pages, poorly named pages or missing content like images or anything downloadable. These tests will be carried out by my peers who are very knowledgeable about tech as this is very common for alpha testing because the aim is to confirm technical functionality. I will be using the white-box testing methodology because we are all familiar with using WordPress so I will be able to benefit from tailored feedback. I will simply be asking the testers to perform a set of predetermined tests and from this, I can conclude whether the build is adequate to be released for Beta testing.
- Mac Sierra V10
- Windows 7
- iPhone iOS7
- Android (Find version history)
- Firefox Quantum 58.0.2
- Chrome Version 64.0.3282.186
- Safari Version 10.1
- I have installed a number of APIs on my WordPress site to make it more interactive and to enable certain tasks on the website to be executed with ease. I will be making a note of any other APIs I install during the build process so I know to confirm their functionality during the alpha test.
- I have installed a contact form plug-in called Contact Form 7. I need to make sure this is fully functioning by asking the tester to submit a query using this platform. If the query goes through to the correct e-mail address then I will know the test has been successful.
- The load time of these extra features must not hinder the quality of the whole website.
- The website needs to be responsive to tablet and mobile.
- Media query breaks are able to turn the main menu system into a burger menu on tablet and mobile.
- When a tablet or mobile device is rotated to landscape view, the elements need to stay in the correct place and still respond to gestures. E.g. buttons still work as they should and are linked correctly.
- Linked buttons bring the users to the correct pages.
Project Plan
This my two-week build plan. I am subject to let it change along the way as I haven’t completely decided on what needs to be done when.
Bibliography
Blankley, B. (2012). Analytics – Who’s Visiting Your Site, and Why? | Charity & Biscuits. [online] Charity & Biscuits. Available at: https://www.charityandbiscuits.com/charity-website-toolkit/analytics-visiting-site-why/ [Accessed 1 Mar. 2018].
Freiler, L. (2011). Alpha vs. Beta Testing. [online] Centercode.com. Available at: https://www.centercode.com/blog/2011/01/alpha-vs-beta-testing/ [Accessed 1 Mar. 2018].
Farcic, V. (2018). Black-box vs White-box Testing. [online] Technology Conversations. Available at: https://technologyconversations.com/2013/12/11/black-box-vs-white-box-testing/ [Accessed 2 Mar. 2018].