[](https://gitpod.idi.ntnu.no/#https://gitlab.stud.idi.ntnu.no/it2810-h20/team-35/prosjekt-2/)

[[_TOC_]]

## Page contents
For this task we have created an online art exhibition. The art exhibition includes 7 animated artworks, with unique poems and audio for every installation. On our page the artwork is placed in the center, covering most of the screen.

The poem itself is also placed at the center, in front of the artwork. Below the poem, the user will find a component to play, pause, mute, fast-forward, rewind and alter the volume of our audio file. If the page is opened on a computer, the left side of the page will display our tab options, allowing the user to switch which artworks, with poems and audio, they would like to display. The right side of the page displays the parameterization options. If the page is displayed on an phone or tablet, these components will be shown on the top as well as the bottom of the page.

The user can switch between 7 different artworks by clicking the different buttons on the left side of the screen. These buttons will change the artwork, music and display a new poem. The user can also interact with the artwork by using the slides on the right side of the screen, or control the music with the controls below the poem.

This images shows off installation selection (on the left), the installation itself(in the middle) and the user paramaters(on the right).

## User Parameters

The user are presented three range sliders to manipulate the content on the page. These range sliders control different attributes of the artwork in the background. The first slider changes the size of the particles. The second changes the velocity of the particles and the third one changes the color of the background. We chose to use sliders because they are easy to understand and use. It also enabled us to change the range of the slider to fit its purpose. E.g. the slider which controls the background color goes from 1-255 instead of 1-100 because it is is better to represent color. We considered having two buttons to either increase or decrease the speed or size, but thought it would fit and look better to implement a slider.

This is how the parameter component looks on smaller screens. The modal can of course be opened or closed.

## Choice of components
The react application uses 3 main components:
- The "selection" component, which lets the user choose which of the installations to display. When on smaller screen sizes (such as mobile phones) the selection component is moved and made smaller. Arrows are added for changing installtion, and thus we do not have to display every option at once.

- The "installation" component, which draws the canvas and displays the audio and poem.
- The "parameters" component, which lets the user change some parameters to influence the installations. This component is also very different on mobile devices, where it is implemented in the form of a modal that can be opened and closed.

The projects include mainly functional components with hooks, but we have also included one class component to show that we understand how these work. The AudioPlayer components is a class component, it is located at src/components/installtion/audio.tsx.

The component structure looks like this:


## State Management
The main state of the application is the activeTab, which chooses which installation to display. The activeTab is integrated with the context API, and we have created a custom hook "useActiveTab" to access the context. The app itself is wrapped in a context provider, which provides the global state to the installtion component. The function for updating which tab is active is provided to the selection component through props. Additionally the "parameters" and the "FetchPoem" components have a local state, using the useState hook.

## Asynchronous JavaScript / AJAX
If no poem is found in localstorage, we fetch poems from poetryDB using async/await calls and the fetch function. Using the "async" keyword before our function ensures it will return a promise. Then, we fetch from poetryDB with the "await" keyword, resuming only when we receive the data. By using an asynchronous function, our program can "pause" the function while it waits to receive data, and run other functions in the meantime.

 const fetchDataAsync = async () => {
        const response = await fetch(
          "https://poetrydb.org/title/" + poemTitles[activeTab] + "/.json"
        );
        const data = await response.json();
        localStorage.setItem(activeTab.toString(), JSON.stringify(data));
        setData(data);
};

The data from poetryDB is stored with localStorage (along with the tab-number), to ensure that the user keeps the current state if f.e. the page is refreshed.

## Testing

We test our components using Jest and Enzyme. Jest is a unit test framework, which allows us to test snapshots easily using the expect().toMatchSnapshot() functionality. Enzyme makes writing tests easier, as they can be written using regular assertions. The tests can be run using 'npm run test' in the terminal.

### Unit tests
The components App, Selection, Installation and FetchPoem are unit tested. For example, the app component is tested by simulating clicks of different buttons, and checking that the expected canvas is rendered.

### Snapshot tests
Snapshot tests are written for App, Selection, Installation and FetchPoem. Snapshots are generated for all components in a working state, and the snapshot tests ensures that they continue to behave as expected. By using 'Enzyme-to-json' we ensure that only the components own markup gets serialized into the snapshot.


### Responsiveness
We have tested responsiveness on several different screen sizes on different devices. We have also tried resizing the browser window manually and used Google Chromes developer tools to resize it to different sizes of different devices. We have tested the webpage on an iPhone 8 as well as mulitple browsers, e.g. Chrome, Safari and Firefox.

## Responsive Design
Describe how we do responsive design
To make our webpage responsive for all devices we have made most of our components resize dynamically, depending on the screen size of the client. All components will resize to fit the screen automatically.

If the screen is smaller than 768px the layout of the webpage will change. The right tab will be display on the top of the page, and it will be possible to click through the artworks using arrowbuttons. The poem and audio controllers will still be placed at the center of the screen. The tab for changing parameters for the artwork wil be accessible through a menu in the top right corner.

When implementing a responsive design we have used:
- Viewport
- Media-queries
- Canvas which scales with screen
- Flexible layout

This is how to application looks on different screens:

Big screen | Smaller screen |Mobile
:----------------:|:------------------:|:---------:
||

## Animations
All of the installations have a unique artwork/animations. These animated pieces of art are implemented using a Canvas component, which takes in a draw function through props. All of the artworks have separate draw function.

Here is an example of such a draw function:

class Code {
  // Code class
  x: number; // X position
  y: number; // Y position
  size: number; // Font size of character/code
  velocity: number; // Downwards velocity
  symbol: string; // Which symbol to draw

  constructor() {
    // Code constructor
    // position is randomly chosen on the screen, rounded to nearest 10'er
    this.x = Math.round((Math.random() * window.innerWidth) / 10) * 10;
    this.y =
      Math.round((Math.random() * (window.innerHeight + 100) - 100) / 10) * 10;
    this.velocity = 1;
    this.size = 16;
    this.symbol = Math.random().toString(36).substring(2, 3); //Generates random character
  }

  update() {
    // Update position on each render
    this.y += this.velocity; // Move down on screen each render
    if (this.y >= window.innerHeight) {
      // When reaching bottom of screen reappear in random pos at top
      this.x = Math.round((Math.random() * window.innerWidth) / 10) * 10;
      // Chooses random Y in the 100px above screen, this is to prevent big blocks of characters to clunk up
      // when screen goes from small to big
      this.y = -Math.round((Math.random() * 100) / 10) * 10;
    }
    if (Math.random() > 0.8) {
      // 20% of rerenders change character to new random character.
      this.symbol = Math.random().toString(36).substring(2, 3);
    }
  }

  changeSize (size: number) {
    //Update radius from user input
    this.size = size/3;
  }

  changeSpeed (speed: number) {
    this.velocity = speed/10;
  }
}

// Create code characters
let codeList: Code[] = [];
for (let index = 0; index < 4000; index++) {
  codeList.push(new Code());
}

const codeDraw = (ctx: CanvasRenderingContext2D, frameCount: number) => {
  ctx.fillStyle = "green";
  const inputSize: number = +(document.getElementById("size-slider") as HTMLInputElement).value;
  const inputSpeed: number = +(document.getElementById("speed-slider") as HTMLInputElement).value;
  codeList.forEach((code) => {
    ctx.font = code.size + "px serif";
    ctx.fillText(code.symbol, code.x, code.y);
    code.changeSize(inputSize);
    code.changeSpeed(inputSpeed)
    code.update();
  });
};

export default codeDraw;

## HTML Web Storage
SessionStorage has been implemented to store the activeTab number, this is to prevent the page to reseting to installation number 1 every time the user refreshes the page.

We have also used localStorage, which is a more permanent storage. When the poems are fetched for the first time they are also stringified and saved in localStorage. The next time a user wants to see that installtion, the application will use the poem stored in localStorage instead of requesting the poetryDB again. We have done this to reduce loading times, as the poetryDB REST API has a seemingly high variance in response times. Another way to solve the loading time issue would be to save all loaded poems in state, but then they would have to be fetched again the next time the user closes the website. Seeing as we had to use localStorage for something, we thought this was a good use for it.

## Git Workflow
Our workflow using GitLab has been as follows:
- Create issue in GitLab. Issues have been seperate task so that our team can work independently from eachother.
- Create branch from issue. Every team-member have created a new branch from the newest version of the project and worked in the seperate branch.
- At each commit the curret issue has been tagged. Some commits have deviated from this standard.
- When the issue has been completed/solved a merge request is created. If the code fullfils its issue and is stable it will be merged in the development-branch.