All of the artworks are made and animated using SVGs. This is because they scale better than canvas and are require less code to animate.
All of the artworks are made and animated using SVGs. This is because they scale better than canvas and are require less code to animate. They have the same aspect ratio so that they all fit in our page layout, and use viewbox to scale with the window size.
### Sound
You can choose between three different soundtracks to each exhibition piece. These are royalty free songs gathered from www.bensound.com. We felt it made more sense to only switch between the three same tracks rather than three different tracks for each exhibition piece. This is partly due to the amount of files the user would have to download, but also the increased complexity of implementation. As Google Chrome has blocked autoplay of audio we decided to put the controls for starting, changing and stopping the music in the settings drop-down menu.
...
...
@@ -28,7 +28,8 @@ Sessionstorage has been used to saved the selected options for each exhibition p
To make the website responsive we have used media queries and scalable elements. The site scales well for different screen sizes because the SVGs are in a scalable viewbox. We found that iPad aspect ratios are not too far from PC screen aspect ratios, so we have not made specific media queries for tablets. We have queries both for vertical and horizontal phones and have focused on iPhone screen sizes. The vertical queries changes the layout to a strictly vertical one, while the horizontal queries uses more columns and less rowns in the grid to take advantage of the wide aspect ratio.
### Testing
TODO
//Legg inn om snapshot-test//
We have tested that our page acts appropriately in different browsers with different window sizes. When testing mobile screen sizes (vertical and horizontal) we have used the browser built-in inspect mode that represents common screen sizes for mobile phones.
### Gits
We have used different branches and issues to complement our workflow. If we implemented features that required more than one commit, we would branch off the master branch and implement those changes there. This ensured that the master branch had stable changes. On merges with master, the relevant issues for the merge request should be referenced. Optimally, we would have only referenced the issue on merges, though we have been somewhat inconsistent here.
