4.2 Evaluation of Usability Features
Effective
1
Ensure that the user can use the majority of the project without having to get much support and thus the software is intuitive.
Partial Success
2
Make the software as easy to understand as possible such that the user has high autonomy.
Partial Success
The questions from usability testing relevant to this section:
80% Agreed, 20% Disagreed. The vast majority of users had atleast a basic understanding of the idea of the project.
40% Agreed, 40% were Neutral, 20% Disagreed. A large minority of users understood the different projects with the majority being somewhat unsure.
40% Agreed, 40% were Neutral, 20% Disagreed. A large minority of users knew how to setup the node software with the majority of users indicating that they would probably need atleast some level of assistance.
80% Strongly Agree, 20% Agree. All users knew how to use the website at atleast some basic level with the vast majority being confident in how to use it.
Feature 1
Ensure that the user can use the majority of the project without having to get much support and thus the software is intuitive.
Based upon the usability testing responses supplied in the above table we can immediately see that the majority of users understood the general idea of the project and how to use the web portal/website but only 40% seemed to understand the node software. This then means that that 40% were likely the same 40% who stated that they understood all the different parts of the project.
This is sufficient evidence to state that this feature was partially met as it was not required that all users can use and understand all of the project but rather the majority of the project and since the vast majority of users understood the fundamental idea of the project and how to use the website/webportal it is clear that the vast majority of users understood the essential parts of the project. However it can also be shown that the vast majority also did not grasp the concepts and understanding of the node software which is a large portion of the project which hence prevents this feature from being a complete success.
Feature 2
Make the software as easy to understand as possible such that the user has high autonomy.
Similar to feature 1, we can see from the responses given in the above table from usability testing that the vast majority of users knew how to use the website but were less stable on the node software meaning that they would have high autonomy with anything related to that website but not the node software. Therefore this feature is partially met.
Efficient
1
Ensure users can get from one point on the website to any other within 3-7 clicks, with 3 being for major sections such as the home page and 7 being the more detailed sections such as the documentation for the configuration file for the Node software.
Success
2
Allow users to setup a node and have it start running within as small a time period as possible.
Partial Success
Feature 1
Ensure users can get from one point on the website to any other within 3-7 clicks, with 3 being for major sections such as the home page and 7 being the more detailed sections such as the documentation for the configuration file for the Node software.
All pages on the webportal can be reached within 2 clicks of the homepage and since it takes a maximum of 1 click to get to the homepage from any other page, any page can be reached from any other page within 3 clicks.
All major sections can be reached in 1 click of the homepage on desktop meaning that all major sections can be reached within a maximum of 2 clicks on any platform and any page can be reached within 3 clicks on any platform meeting the requirements for this feature.
Feature 2
Allow users to setup a node and have it start running within as small a time period as possible.
If the user is on macOS or a precompiled architecture and wishes to setup a worker node, setup and running can be done very quickly. This is becuase the supplied example configuration file needs very little setup and can be done through the terminal control of the node software itself which is built to be fast and simple to use.
The software can also be compiled for other operating systems such as Windows and Linux which would allow this to be the case for an even larger pool of users but that would require doing so on a windows/linux computer which I did not have time to do every time I updated the software. Although if the project was being ran by a large enough user pool to warrant doing so it could be done.
The issue here is that if the user wishes to setup a leader node they must carefully configure their configuration file manually and ensure they have set up the correct open ports and networking settings within their local network which can take some time. Or if the user is trying to run the software on a non-precompiled architecture they must download the source code of the project and the Vlang compiler in order to compile and run the software. In either case the node cannot be setup very quickly hence preventing this feature from being completely successful.
Engaging
1
Create a simple, clear Homepage for the web-portal.
Success
2
Stick to a simple, repetitive art style so the user recognises all parts of the web-portal as being a part of the project.
Success
3
Create more detailed sections/pages of information for users who wish to understand the technical detail better.
Success
The questions from usability testing relevant to this section:
Feature 1
Create a simple, clear Homepage for the web-portal.
Homepage is a simple, somewhat minimilistic page that gives a basic insight into the project without going into too much detail and gives the users some options for where they could navigate to next.
Feature 2
Stick to a simple, repetitive art style so the user recognises all parts of the web-portal as being a part of the project.
The website sticks to a consistent colour scheming and art style throughout the web-portal, using a solid white background, a solid black or white typeface with a consistant font and the use of purples ranging from mid to light in order to emphasise certain parts of the site
The navigation bar is also consistent throughout the site dependent upon platform type
Feature 3
Create more detailed sections/pages of information for users who wish to understand the technical detail better.
There are various sections throughout the site that give users slightly more information on anything they may wish to learn about such as the proof of trust summary on the homepage, and there is an "info" page which contains some key questions and technical ideas to explain those in a lot more detail to users who are interested.
Error Tolerant
1
The Node should never crash completely, parts of it may stop working until the user comes to check on it but it shouldn't completely stop processing.
Fail
2
The Webportal should have no code-breaking bugs, with the only errors that make it through to production being styling/graphics based bugs.
Success
The questions from usability testing relevant to this section:
60% of Users responded "lots", 40% responded "some", showing that all users encountered atleast one crash.
80% of Users found atleast one error/bug in the Node software.
All bugs reported were in relation to the node software's messaging demo, with 50% referencing that errors occoured when lots of messages were sent in a short period of time.
Feature 1
The Node should never crash completely, parts of it may stop working until the user comes to check on it but it shouldn't completely stop processing.
As shown in both the question responses from usability testing summarised above and the tests within the checking of development tests, the node software crashed under continued use or heavy load. This means that when more than 2-3 users tried to talk to each other using the messaging demo built upon the communication layer or when a user sent more than 1 message a second for atleast 10 consecutive messages their own or someone else's node would crash. This would need to be addressed within the short term fixes for this project but as I suspect that it is partially due to limitations in the language of which the node software is written in it would likely also become a long term limitation of the project.
Feature 2
The Webportal should have no code-breaking bugs, with the only errors that make it through to production being styling/graphics based bugs.
The Webportal has never gone down after initial publication. This can be shown both by the lack of bug reports by testing users and can be reinforced by the fact that as of writing this documentation the last webportal update was pushed and uploaded 77 days ago and the server has not logged an error since.
Some users may encounter client side exceptions due to losing connection whilst loading the site or other similar client side issues but simply refreshing the page will fix these aslong as this server stays up.
This has been accomplished due to the server having to be compiled from typescript and Next.js before it can be ran which catches errors that would otherwise crash the site and hence prevents the site ever having a non-working version being pushed to the public as the server will just run the most recent working version in the occourance of a faulty version being pushed.
Easy To Learn
1
Minimise the amount of user input required to operate the Node software.
Success
2
Categorise web-portal transportation methods to simple, easy to understand groupings such that users are not overwhelmed with choice but instead can make a few simple choices to get to where they need to go.
Success
Feature 1
Minimise the amount of user input required to operate the Node software.
Assuming that the user wishes to setup a worker node all they are required to do is launch the sofware and run through some very basic inputs to generate the defualt configuration file and wallet/keys and then the software can be ran without any further input. This limits user input to very minimal levels.
If the user wishes to setup a leader node they have the same amount of inputs required to generate their configuration file and wallet/keys but they must then edit that configuration file to meet their networking setup but since this cannot be avoided without forcing leader node users to use specific networking setups it can be classified as the minimal level of inputs hence achieving this feature.
Feature 2
Categorise web-portal transportation methods to simple, easy to understand groupings such that users are not overwhelmed with choice but instead can make a few simple choices to get to where they need to go.
Web portal navigation is grouped and on the desktop view does not show more than 4 sections per grouping so as to make navigation as simple as possible. This is done both on the home page and the navigation bar, with the mobile navigation bar showing 5 sections due to the fundamental difference in use case.
Last updated