2.1 Design Frame

Systems Diagram

My design frame

The diagram above shows the major sectors of this project that I will be creating through out development. The diagram is split into three major sections that then have their own sub-sections to help simplify each part.

The main sections are the following:

  1. The Protocol - This is a summary for how the computers on the network will interact, construct data and validate it in order to create what will be known as the MonoChain.

  2. The Web-portal - This is the website that will allow users to interact with the MonoChain through a few basic functions which are shown in the diagram.

  3. The Node Software - This is what people who want to contribute to the MonoChain through the validating of transactions and data in order to "mine" coins on the network will use on their computers/servers.

Throughout the development stage I will initially focus mainly on the Node Software and the Protocol, and then once they are up to the point at which the network somewhat works I will also start developing the webportal as when the network doesn't work the portal doesn't have much of a use. I have also decided to break down the diagram into those specific subsections in order to roughly align with the Success Criteria.

Usability Features

Usability is an essential aspect to my project as I want it to be usable and understandable to both developers who have a prior understanding of blockchain technology and non-developers who have never used it before.

Effective

I need to ensure that users can do what they are trying to accomplish as easily as possible and part of this will include configuring their settings and generally using the software. The effectiveness of the usability is also relevant when discussing how intuitive the project is to use, which usually comes in the form of questioning how much assistance a user needs from documentation and other people before they figure out how to use part of the project.

Aims

  • Ensure that the user can use the majority of the project without having to get much support and thus the software is intuitive.

  • Make the software as easy to understand as possible such that the user has high autonomy

Efficiency

The Efficiency part is concentrated on the speed and accuracy to which a user can complete whatever they are trying to do. This equates to making the UI for both the web-portal and the node software as simple and easy to navigate as possible. In my case, part of this will be also based upon how important the information/part of the project the user is trying to get to is, as if it is important and commonly accessed it should take very few clicks to get to but less important information that isn't accessed that much is okay to take more clicks.

Aims

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

  • Allow users to setup a node and have it start running within as small a time period as possible.

Engaging

Making a blockchain and it's mining software engaging is not a simple task, however in order to keep the project on the whole interesting to the user the focus will be the web-portal. This is because this is the part of the project a user will visit before deciding whether to actually use the rest of the project and since the node software is designed to be left alone and let to run so it doesn't matter as much how engaging it is.

To keep the web-portal engaging, it will require bright, colourful graphics and design to attract users alongside short slices of information that tell them all they need to be told without overwhelming them with information. However individuals who are already interested in the software and wish to understand the technical side better should also be able to find out as much as they want to know, which will be done through select pages of which contain a much higher quantity of information.

Aims

  • Create a simple, clear Homepage for the web-portal.

  • Stick to a simple, repetitive art style so the user recognises all parts of the web-portal as being a part of the project.

  • Create more detailed sections/pages of information for users who wish to understand the technical detail better.

Error Tolerant

No part of the project should crash completely, as this can be terrible for user's opinions of the project.

If the web-portal was to crash it would likely result either in the user coming back later or just not using that section of the website as due to the nature of being a client sided website it is very difficult to crash the entire site.

However, if the node software was to crash it could have much worse effects, as it is designed to be left to run and users should only be expected to check on it once every few days, hence a crash could result in days of missed processing which is not only bad for the network but could also lead to users giving up on the project completely.

Hence to solve this problem I will be writing the code to catch and prevent as many run-time errors as possible, and to handle any errors which do occur without crashing which will be made easier through the use of a compiled language that runs most of it's error checking during compilation.

Aims

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

  • The Webportal should have no code-breaking bugs, with the only errors that make it through to production being styling/graphics based bugs.

Easy To Learn

The solution should be easy to use and not be over complicated. To do this, I will create a simple command line based interface for the node program, which contains only the options and input required without confusing the user. Then for the web-portal, the locations of buttons and the transportation to different parts of the website should remain constant through updates and are categorised so that users only have to worry about the sections they actually want to visit and aren't overwhelmed with choice.

Aims

  • Minimise the amount of user input required to operate the Node software.

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

Pseudocode for the Node project

The main function

The main function of which operates the node will be very simple, due the general design of the software being split up into lots of different files and functions to be reused in different parts of itself and to abstract as much of the program as possible.

MODULE main
IMPORT server
IMPORT configuration

PROCEDURE main():
    OUTPUT "Launching MonoChain Mining Software"
    config = configuration.get_config()
    server.start(config)
END PROCEDURE

The server start function

This is the function for which the server initialises a connection to the network and sets up all the routes for other nodes and programs that use the network to request to.

MODULE server

init_ref = "https://nano.monochain.network"

FUNCTION start(config):
	// start server on a new thread
	api = RUN http_server ON PORT config.port
	
	// wait to make sure server is up before proceeding
	WAIT 2 SECONDS
	
	// ping the node's entry point to connect it to the network
	server.start_handshake(init_ref, config) 
	
	// bring server process back to main thread
	api.wait()	
END FUNCTION

A generic route on the server

This shows the basic layout of code for a route within the api server which is started in the main program.

module server

HTTP ROUTE ("/", GET) index(request):
	// the request object contains all data from a traditional http request.
	
	// some data would then be calculated
	DATA = "This is the api route for a node running on the Monochain network."
	
	// this data is then sent back to whoever requested the route.
	RETURN app.text(DATA)
END ROUTE

Pseudocode for the Webportal

The webportal will be built using react, next.js and typescript, the way in which these technologies can be used (and will be used in this project) allows for each web page to be placed in a separate file. Therefore each file would be fairly similar in terms of structure yet very different in terms of content, so the below pseudocode contains some example components with some example css parsing to represent the structure of a webpage in this format.

FUNCTION Page() {
  // any code that is put here is just typescript code
  // it will be executed prior to the webpage being sent
  example = "hello world"

  RETURN (
    <Generic Component
      width = "full"
      height = "full"
      textAlign = "center"
      padding-x = 10
      flexDirection = "column"
    >
        <Text>
          {example}
        </Text>
    </Generic Component>
  );
};

EXPORT Page;
Previous1.7 Hardware and Software RequirementsNext2.2.1 Cycle 1 - The Framework

Last updated