Cosmo keys is a typing game that has been designed for visually impaired users. Everything has been created to suit their needs e.g colour choices, spoken elements and responsive functionality. However, it is also aimed to appeal to sighted users. It is a fun, interactive game with different levels of difficulty to accommodate different levels of skill.
- STRATEGY FOR THE WEBSITE
- GAME DESIGN AND ROLL OUT
- FUTURE ROLL OUTS
- ACKNOWLEDGMENTS
Table of contents generated with markdown-toc
Cosmo keys has been designed following conversations with a visually impaired (VI) individual. They explained how typing (especially on a mobile device) is very difficult, but that there is no opportunity to practise typing as most typing games rely on the user being able to see the letters they are asked to type. A platform that gives them a fun way to practise typing would allow them to gain some muscle memory and learn where their fingers need to be to accurately type each letter. This prompted the development of Cosmo Keys, a typing game for the visually impaired
Using UX design principles, I outlined the key features a typing game would require and what a VI user would require to ensure they could use the game.
- Clean, concise display pages with easy to find information (big buttons, high contrast etc)
- Compatibility with screen readers
- Simple game play that reads the target letter/words for the user
- Different levels of play
-
-
To have clear, concise information that is easy to navigate and is accessible on multiple screen sizes and to those using screen readers.
-
To link to the games social media site and improve the visibility of the webwise.
-
To create a game that can be used by VI and sighted users with little differences in functionality.
-
-
-
I want to play a game to practice my typing.
-
I want to be able to navigate the page without any difficulties inc using a screen reader or computer magnifier.
-
I want to be able to find the rules of the game and understand game play.
-
-
-
I want to be able to alter the level of difficulty that matches my current skill level.
-
I want to be able to quickly navigate to the game play page.
-
The following opportunity matrix summarises the key features that could be implemented in the game Cosmo Keys. It outlines what was addressed in this roll out (phase 1) and what could be implemented in the future (phase 2).
| Opportunity | Importance | Viability | Score |
|---|---|---|---|
| Rules | 5 | 5 | 10 |
| Information about the game/purpose | 3 | 5 | 8 |
| Level selection | 5 | 3 | 8 |
| Volume control | 1 | 2 | 3 |
| Leaderboard | 2 | 3 | 5 |
| Contact form | 3 | 4 | 7 |
| Increase social media presence | 3 | 5 | 8 |
| Level 1-3 play | 5 | 3 | 8 |
| Level 4-6 play + | 1 | 3 | 4 |
| Ability to pause the game | 5 | 3 | 8 |
Based on the score, the opportunities were summarised into their roll out phase.
| Opportunity | Phase for Roll Out |
|---|---|
| Rules | 1 |
| Information about the game/purpose | 1 |
| Level selection | 1 |
| Increase social media presence | 1 |
| Level 1-3 play | 1 |
| Ability to pause the game | 1 |
| Contact form | 1/2** |
| Volume control | 2 |
| Leaderboard | 2 |
| Level 4-6 play + | 2 |
** I decided that for roll out 1 an email address could be displayed giving the user the ability to contact the game designers if they wanted to but that a contact form would be delayed until roll out 2.
The game will consist of an introductory page that allows the user to see the rules and about information. This will give context to why the game looks and functions as it does (i.e a platform for VI users to improve their typing accuracy). A button will move the user to level selection which will then take them forwards to the game play area.
As this is a game and not an informative website the pages will not take up the whole screen page, it will look like a game, taking up a position in the centre of the users screen. Furthermore, it will have functionality and visuals that are typical of games.
- Home (index) page
- Large, distinctive buttons.
- About and Instruction buttons pop up JS modal with relevant information. About inc contact information for the page (modals chosen to minimise the use of back buttons for VI users).
- Play button to take the user to level selection.
- Links to social media platforms (as not a real game, will just be to the home pages).
- Level selection
- Colour relevant buttons which aid VI users to select a level of difficulty without having to read the words. Take the user straight to the game play page.
- Upper left “back” button takes you to the home page
- Game play
- A button which starts the game, giving the user the opportunity to look at the page before the game starts.
- Buttons to pause the game, restart and move back to the level select page. This was chosen over a level-change button to minimise the amount of content a VI user needs to find in the game play area.
- Rules modal in case a user needs to remind themselves how to play the game.
- A timer area.
- Score counter for correct answers.
- Boxes which display the computer’s challenge and the user's response.
- Error pages (404 an 500)
- Large, distinctive buttons.
- Informative
- Links back to home page (index.html)
The following wireframes outline how the content will be viewed on different devices. They were created using balsamic.
-
1 Home page (all devices)
-
2 Home page example of how the modal will look
-
Level selection page (small screen)
The level select page on other devices matches the home page layout.
-
1 Game play page (small screen)
-
2 Game play page (large screen)
Each page will be responsive and the user will be able to navigate between pages using the back button. There will be multiple opportunities for the user to interact with the page and play the game in a way that suits them.
I wanted the typing game to be fun for people of all ages. Space is a popular subject and there are lovely images and graphics that can be found to make the page engaging for everyone. Additionally and most importantly for my VI inspired game, space is dark! Which makes using contracting colours easy. They fit into the theme and are best for VI users to differentiate different parts of the screen.
As a consequence of this subject I named the game "Cosmo Keys". Cosmo links to space and also implies speed, whilst Keys informs that the game is for typing (keys on a keyboard).
I found my background image on Freepik and used this for all subsequent design elements.
From my background image I selected base, high contrasting colours using ColorZilla (purple #8a38e3, light blue #70caf5, orange/red #f2624a and dark blue #07043C).
This dark blue was used for my overlay on all pages (with transparency) and I created gradient backgrounds (using colourSpace) using the other colours as a starting point to use across my buttons.
Other colours were selected to complement these e.g the red, orange and green used on the level page and the grey on the game play page.
The two fonts I have used for Cosmo Keys are from the Google font library. "Audiowide" was used for the title and impact words as it has a very game-like appearance and linked with my space theme.
The more informative text was written using Lexend. This was selected after reading the article by google fonts titled "Introducing accessibility in typography". It states that Lexend was designed to be easier to read, ensuring each character is distinctive from others.
The sounds for the "correct", "wrong" and "game-over" were selected from freesound. They are short, snappy sounds that don't take up too much time as part of the game and have distinctive tones which match a users expectations for right, wrong and the end of a game.
To create the talk-back functionality of the game I used the Web Speech API created by Mozilla.
The website is comprised of a home page, a level select page and a game play page.
All pages are responsive and have:
-
A faviocon in the browser tab. This was generated by cropping the background image.
-
A title which links back to the home page.
-
Buttons/links (and surrounding container) change colour when they are hovered over to a blue colour that is consistent through all the pages.
-
The back button for all pages will be positioned in the same, typical place (top left corner) to improve UX as this is where users expect a back button to be.
The home page captivates the user with a distinctive and clean game-like imagery which has a container displaying the game's name (Cosmo Keys) and its key purpose, "The accessible touch typing game". There are links to the games social media platforms which additionally make the game feel more professional.
Below this there are three buttons which allow the user to:
-
View the rules of the game or the "about” the game info.
Both of these display as modals to improve VI usability. The about modal tells the user that the game has been designed for VI users and gives the contact information for players to get in touch. The rules modal instructs the user how to play the game. For each, the user does not need to find the "x" button and can simply click anywhere on the screen to exit.
-
Move on to play the game (play button), and select the level of play.
The game play for phase 1 roll out has three levels:
- Level 1 - 1 letter play
- Level 2 - 2 letter play
- Level 3 - 3 letter play
To aid VI users these are colour coordinated from green to red so a level can be selected based on colour (easier to see) than having to read the words with a magnifier.
This page is designed to make viewing it (on any device) easy for VI users. Therefore, whilst still being appealing to sighted users, there are some design elements which may have been modified if this was for sighted users only e.g the size of buttons/boxes are purposefully larger than needed and colour choices are more stark than they might otherwise be.
There are buttons which allow the user to reload the game (before a game has finished) or re-read the rules. This navigation-like bar at the top DOES NOT toggle to a burger on smaller devices. This was a conscious choice to aid VI users as these menus can be cumbersome (the screen reader reads out every option, every time it is selected).
The level that has been selected is displayed on the page, coloured to correspond to the level of difficulty.
On small screens a box is added to notify the users that the page has space for their keypad (see TESTING user stories). Additionally, the reload button moves to the bottom of the page to ensure the playing space is maximised and all content is visible.
During game play:
-
To aid VI users the timer, which counts down from 60 to 0, has been designed to change colour as the time reduces, so a user doesn't have to read the numbers to know how long is left. This is done from green to red.
-
Using a web speech API, each letter/word is read to the user. The speech utterance is cancelled if a user gets part of a word/letter set wrong. It is also cancelled if (a sighted user) types all the letters quicker than the speech utterance. This speeds up the game and prevents the speech being left behind the sighted user. Additionally, at the end of the game the score is announced.
-
Following a right or wrong answer a corresponding sound is played to improve UX for all users. I chose not to announce the players typed letter/word to improve how the game runs (even though this would help a user identify how they are going wrong). The game is NOT case sensitive. This ensures users on a mobile device don't have to adjust their keypad to lowercase letters. The score box increments with each correct answer. Additionally, there is a display that announces an answer as "right!" or "wrong!", improving UX for sighted users.
-
The start game button turns into the pause button. This positioning is to help VI users find it as often their display/mouse is left hovering over this element during game play.
The 404 error page displays the Cosmo Keys title, which like on the other pages, acts as a link back to the home (index) page. There is a message on the page that notifies the user there has been a problem (error) navigating to their desired page. The "Go Home" button will redirect the user back to the home page to start again. I chose not to give the user options as this keeps the page simple and ensures a level is selected before game play starts.
The 500 error page displays if there is an error calling the API. The Cosmo Keys title links back to the home page. The Error message notifies the user there has been an error trying to retrieve their challenge letters. As above, I have only given the user the option to navigate home with a "Go Home" button.
The accessibility of this game was a huge consideration throughout it's development. In addition to the design features already discussed (colour, contrast, size ets). I also ensured:
- Screen reader compatibility.
- Aria labelling to identify different parts of the page.
- Semantic HTML.
Furthermore I checked the accessibility of my website using Google's Web Disability Simulator
Here are two examples of how pages looked using the yellow/blue and red/green colour blindness filters.
I also tested the game using Silktide's accessibility extension for google chrome. Each page passed all checks for contrast and colour and could be read successfully by a screen reader. Additionally, I got user feedback from a VI player.
| No | Bug | How I solved the issue |
|---|---|---|
| 1 | Play button on index.html not styling like the rest of the buttons.  |
I attempted to adjust the padding settings for each screen size but couldn’t line it up perfectly. I solved this bug by putting a span of text either side of the icon which has an opacity of 0 (therefore cannot be seen). Therefore the padding renders to this and keeps the boxes the same for each element on the page. |
| 2 | Level ID in game.html could not be set from level.html using my original code. Bug 2 level id. This successfully logged the level but didn’t transfer this data onto my game.html page (therefore the content wasn’t loaded to the DOM) | After some internet searching, I found this article which outlined you can store a variable using local storage which means you can then access and retrieve the variable on a subsequent page. I chose local storage as I want the level id to be retained even if the game is reloaded (without moving back to the level page). |
| 3 | Player initiates a new letter with every letter typed (even if the turn isn't over). | After going back over the Simon game CI tutorial and some YouTube game examples I concluded I needed to add a boolean variable that set a computer turn to false for when the player could move and true the rest of the time. I also removed the listening capability of the event listener so it could no-longer detect a player's input. |
| 4 | After pausing the game, the focus moved to the beginning of the player answer box (and therefore immediately incurred a wrong result when the player started typing again). | I first tried to use a focus.point on my querySelector using the length within my player answer box to move the cursor to the end. However, this didn’t work. This is because my element in not an input, but a contenteditable. Therefore I had to use the range method as described here by Phuoc Nguyen |
| 5 | Screen reader content showing | Upon loading each page the screen reader content showed briefly. This was due to Bootstraps sr-only class being applied slower than the rest of the content. By making my own sr-only class the content remains hidden at all times. |
| 6 | On Apple devices and on the browser Firefox my fix to get the letter "a" to sound like "ay" didn't work as the computer was pronouncing it like "i". This was incompatable for a VI user playing on these devices. | I had to try numerous different ways of spelling the sound "ay" to get it to sound ok across browsers. When researching how I could spell it i came across this YoutTube video that promted me to try "eigh". |
| 7 | On Apple devices, level 2 and level 3 play were not saying the computer letters. However, after pausing they worked | I first tried to input the focusAtEnd() features (minicing the pause event) into the player turn function but this didn't work. I then asked chat GTP why a speech() using the API might not work straigt away but work on subsequent rounds. One of the suggestions was to "Introduce a small delay before calling speakLetter to allow the input element to gain focus." This made sense as it would explain why the function worked correctly after the game had been paused. i therefore put a slight time delay for the computer's letter speech which solved the problem. |
-
UX could be improved by forcing the keypad on phones to load when the game play page is loaded, automatically. This would replace the box I've added saying "your keypad will be here". I searched multiple slack forums and tried several methods to force a .click() event in javascript after setting the .focus() of the player answer box but none of the methods I tried worked.
-
A user can continue to type into the box when they have a.finished a word or b.entered a wrong answer. To solve this I stopped the player answer box from being "content editable" after a wrong answer (or at the end of the correct answer). The example here shows how the funtion was written:
and then returned it when it was the player answer turn. This required a click and refocus to put the cursor back in the box.
This solved the problem for google chrome and android devices. However, this did not work on apple devices. Furthermore, as a result of this modification the keypad on mobile devices kept hiding and then displaying again which was a poor user experience:
Video of keypad showing/hiding
I therefore removed this feature and simply turned off the event listener to prevent typed letters being logged. It would improve the UX to prevent a user from typing when they should not be able to whilst retaining the mobile device keypad.
Please see the separate TESTING.md file for testing carried out on Cosmo Keys.
HTML, CSS and Javascript.
-
Gitpod and Visual Studio Code Desktop Version - to create the site (IDE's).
-
Balsamiq - to create wireframes.
-
Github - to save and store the files for the website.
-
Git - for version control, using the Gitpod terminal to commit to Git and Push to GitHub.
-
Bootstrap version 5.3.2 - to input different features of the website including buttons and modals and to assist responsive styling.
-
Font Awesome: - to add icons and improve the UX.
-
Google Fonts - for the fonts used on the website.
-
ColorZilla - to pick colours from the background image and get hex codes.
-
Google Developer Tools - to view responsive styling and troubleshoot/solve issues.
-
Favicon.io - to create the Cosmo Keys favicon.
-
ColourSpace - to create the colour gradients.
-
TinyPNG - to compress background image.
-
Am I Responsive? - to show the website on different devices/screen sizes.
-
Web Disability Simulator - to view the website under different accesibiity filters.
-
Silktide Accessibility Checker - to check the website for accessibility and sample the screen reader function.
-
GitHub Wiki Toc generator - to automatically create my contents page in the README.md file.
-
Web Speech API - by Mozilla to generate the talkback features of the game.
-
Datamuse API - to generate words for level 2 and level 3 play.
-
Jest - to undertake automatic testing of my JavaScript.
The Cosmo Keys game was deployed using GitHub pages using the following steps:
- Login (or signup) to Github.
- Navigate to the project repository ( e.g Cosmo Keys)
- To deploy the site to Github pages:
- Click the settings button at the top of the page.
- Select pages in the left hand navigation menu.
- Under Build and Deployment, click the "Branch "dropdown menu and change it from "None", to "Main". Then click save.
- To find the site:
- Click on "Deployments", on the right hand side of the repository.
- Under the Deployments menu on the left, select "All Environments".
- The page can then be selected from the Active deployments section.
Both forking and cloning the repository follow steps 1 and 2 above.
Then to fork:
- Click on the "Fork" button at the top right of the page.
To clone:
- Click on the code button and under the "Local" tab and select how you would like to clone (HTTPS, SSH or GitHub CLI.)
- Copy the link and use it to create a new workspace in your chosen IDE (code editor).
Words for level 2 and level 3 play are generated by the Datamuse API.
All other content for the game was written by myself.
In addition to the articles and videos mentioned above.
-
My modal code is taken and modified from Bootstrap. I also used Bootstrap grid systems and other classes that I to make the page responsive.
-
To understand how to fetch from the datamuse API I watched the YouTube video by ByteGrad. I modified this to map data results into an array amd to have the twoLetterWords variable be available outside of the findwords function.
-
I used this video by Web Dev Simplified to see how someone might structure the javascript for a typing game. However, I did not directly take any code from this tutorial.
-
The only image used on this site was taken from Freepix, with specific credit to vectorpouch (Designed by vectorpouch / Freepik)
-
All sounds were selected from Freesound with specific credit to LittleRainySeasons for the "right" sound, Gronkjaer for the "wrong" sound and fupicat, for the final, game over sound.
This game could be developed in several areas in the future. Firstly I'd like to address the features that were outlined for phase 2 in this table. This would be to add:
- A separate area for a contact form.
- The functionality to control the volume from the game itself, rather than relying on the device's controls.
- Features that would allow the population of a leaderboard. e.g a username and then a page which would save and display.
- Additional levels of increasing word and the option to select symbol practice (something that is particularly difficult for VI users).
I would also address other issues that arose during the development of the game. These are:
-
To investigate and possibly implement an alternative talkback API as Web Speech is a little slow on level 2 play.
The WebSpeech API does not allow you to trigger multiple Speech’s at once, i.e separate the two-letter array into its individual characters and then speak them “simultaneously”, but in reality use a timeout feature to separate their utterance by a few ms. This is something I would modify for the future. Putting in place a different API that allows for “simultaneous”speech or using audio files for each letter which will allow for parallel play.
-
Alter the use of the modal
Modals were selected to limit the amount of page navigation a VI user would have to undertake (you can exit the rules modal by clicking anywhere). However, some screen readers recite everything underneath the modal before reading its content. This is a recognised issue for VI users and appears on the most commercial of website's (e.g the BBC). However, as this game is designed specifically for VI users this is a feature that shouldn't occur and therefore development of how the rules/about info is presented would be advantageous and would improve UX.
-
Uppercase/lowercase presentation
To improve UX I would redesign the game slightly so that the lowercase/uppercase functionality of playing on a phone matches what the computer asks. E.g making typed uppercase letters lowercase on the screen or making the first computer letters uppercase to match how the keypad on a phone loads.
-
Homonyms
On level 3 play you may get a word like "bye" that could also be spelt "buy". A VI user cannot see the letters and therefore doesn't know which word is being asked. For future roll outs I would ensure that the API array is ammended to remove these homonyms.
Furthermore I would address and fix the known bugs.
I would like to thank:
-
The Code Institute for all course material and their tutors for their aid when I was stuck with Jest.
-
My friends and family for testing the game and letting me talk my code at them, helping me figure out how to fix it. This is espeially true for my sister who had to repeatedly test the apple functionality of the game.
-
The City Of Bristol 2023 September cohort, for providing support on slack and specifically Chloe for making me feel less alone in my Jest/javascript struggles.
-
My mentor Jubril Akolade for the support, feedback and encouragement that he gave me during this milestone project.
-
My tutors at the City of Bristol College for their support when this project was just an idea and their feedback once it was complete.