Higher-or-Lower Premium Card Game THIS DOCUMENT IS NOT YET COMPLETE
Overview
Higher-or-lower is a deceptively simple card game where the player has to decide if the next face-down card (in a sequence of cards) is higher or lower than the current face-up card.
The player places a wager on whether or not they can guess the next card correctly until they either guess all cards correctly, or they lose their wager and have to start again; the game ends when all cards, in a pack, have been played, or the player has used up all of their points.
For this website, the gameplay reflects an amended version of higher-or-lower premium. This offers better odds than just the single wager, with the number of possible winning points increasing dramatically when placing a wager on, and then guessing correctly, the appearance of a specific suit, matching card, a specific card, or a run of cards.
In the UK, higher-or-lower was the basis for the popular 1980s television game show Play Your Cards Right, where contestants answered questions to guess a longer sequence of cards than that typically used in the classic higher-or-lower card game.
Site Preview
Site Link
The live site is hosted by Github Pages.
Index
- Overview
- Site Preview
- Site Link
- User Experience Design
- Strategy
- Key Business Goals
- Key User Goals
- User Experience
- User Expectations
- User Stories
- User Personas
- Scope
- Existing Features
- Future Features
- Structure
- User Flow Diagram
- Logic Flowchart
- Skeleton
- Wireframes
- Mobile
- Tablet
- Desktop
- Surface
- Colours
- Typography
- Media
- Content
- Testing
- Deployment
- GitHub Pages
- Forks
- Local Clones
- Gitpod Workspaces
- Credits and References
- Technologies Used
- Acknowledgements
User Experience Design
Strategy
Key Business Goals
- To attract players to the game and provide a fun experience.
- The value provided to the website owner is from increasing visitor numbers to the website.
- The call to action on the website will be “Play Game”, or similar.
Key User Goals
- Users of all ages visit the website as a way to relax and enjoy playing an easy to understand, and exciting, game.
User Experience
- Target audience:
- Any age.
- Could be a student, employed, or retired.
- A casual or firm interest in puzzles.
- Possibly casual or serious gamer(s).
- Those looking for ways to relax and have fun.
User Expectations
- The website:
- functions as expected; for example, buttons are easy to identify, and behave like buttons.
- is accessible and responsive.
- is easy to navigate.
- has an appropriate and appealing visual design that reinforces the purpose of the site.
User Stories
First time visitor goals
- “What is this website about?”
- “How do you play the game?”
- “What are the rules of the game?”
- "What can I win?"
Returning visitor goals
- “How many points do I have from the last time I played?”
- “What other versions of the game are available?”
Frequent visitor goals
- “Where am I ranked among other players who use the website?”
User Personas
The website is designed to appeal to all demographics, but the following personas are meant to represent a range of potential users:
- User 1: Male, student, age 18-21.
- User 2: Female, works part-time, mother of young children, age 25-30.
- User 3: Male, works full-time, professional qualification, age 35-55.
- User 4: Female, retired, grandmother, age 60-80.
User 1
“As a student, I want something I can play during my journey to university, so that I’m not bored”
Acceptance Criteria
- The website is responsive and displays correctly on a mobile device.
- All messages are clearly displayed and easy to read on smaller screens.
- Any audio prompts can be easily muted when on public transport.
Tasks
- Style a responsive website using Bootstrap, Tailwind, and / or media queries.
- Display any system messages in a larger format.
- Add the ability to disable audio feedback.
User 2
“As a mother of two, I want an easy, quick game to play while looking after my children.”
Acceptance Criteria
- The website is quick to load and saves user progress.
- The length of the game can be amended.
Tasks
- Ensure the website has excellent load performance on Google Lighthouse.
- Add an option to specify the number of cards used in a game.
User 3
“As a project manager, I want a game that I can play to take my mind off my stressful job”
Acceptance Criteria
- Gameplay is streamlined and easy to understand.
- The game offers different experiences to maintain user interest.
Tasks
- Add an FAQ page that explains the game, its rules, and other playing modes.
- Create additional gameplay modes for the game.
User 4
“As a retired schoolteacher, I want a fun game that I can enjoy but also possibly use to teach my grand-children about numbers”
Acceptance Criteria
- The game has a visually interesting design with a captivating (but not annoying) soundtrack.
- Cards and scores are displayed clearly and are easy to understand.
Tasks
- Implement a design that is bright and colourful, with appropriate sound effects and music.
- Display scores clearly on all screen sizes.
- Ensure cards are easy to see and understand.
Scope
Existing Features
-
General
- All pages will be responsive at different screen sizes, and change layout accordingly and appropriately.
- All screenshots shown in this section were taken from the desktop site, to give the clearest examples possible (apart from the Header section which also shows the header as seen on mobile devices, with a hamburger menu).
-
Browser Icon:
-
Header:
-
TBC
-
Footer:
-
Home (index):
-
FAQ:
-
TBC
-
Custom 404:
Future Features
- Add the ability to play the classic version of higher-or-lower.
- Add the ability to play the switch version of higher-or-lower.
- Expand site to include different card games.
- Add ability for users to create an account.
- Allow users to be place real wagers in a currency of their choice.
Structure
User Flow Diagram TO BE UPDATED TO FINAL VERSION
This diagram shows how the user may interact with the website during a game; dashed lines indicate optional routes.
Logic Flowchart
The following flowchart explains the logic used for the gameplay:
Skeleton
Wireframes
The wireframes presented here show my initial ideas:
Mobile
Home
FAQ
404
Tablet
Home
FAQ
404
Desktop
Home
FAQ
404
Surface
Colours
The following colours, taken from palette 406 of the Sarah Renae Clarke Colour Catalogue, Volume 2, have been used to add interesting backgrounds to the website, with white (#FFF) as a contrast:
Link state colours for social media icons:
Hover
Active
Typography
The fonts used on the site were chosen from Google Fonts:
Media
The following images, used on the site, have been taken from Deposit Photos:
Content
All website copy has been written by myself.
Testing
Deployment
GitHub Pages
The site was deployed using GitHub Pages, as follows:
- Navigate to the GitHub repository.
- Click 'Settings'.
- Under 'Code and automation', select 'Pages'.
- On the 'GitHub Pages' section, under 'Build and deployment > Source' select 'Deploy from a branch'.
- Ensure that the 'main' branch has been selected, and then click 'Save'.
Forks
To copy the repository to your own GitHub account, so you can make changes without affecting the original version, you can fork it:
- Navigate to the GitHub repository.
- Just above the 'About' section, on the right of the page, click the 'Fork' button.
Local Clones
To deploy the project on your own computer you can clone it:
- Navigate to the GitHub repository.
- Click the green '<> Code' button above the list of project files.
- From the 'Local' tab, select either HTTPS, SSH, or GitHub CLI as the method of cloning, and copy the associated link.
- Open the terminal or Bash prompt.
- Navigate to the directory where you want to store the cloned copy.
- At the prompt, type
git clone
and add the string copied earlier.
- Press 'Enter' to create the copy.
Automatically Create a Gitpod Workspace
Click the button below to create a Gitpod workspace from this repository (requires the Gitpod browser extension).
Credits and References
The following references were used for general advice and help in implementing specific functionality on the website:
Technologies Used
- The website was built using HTML, CSS, JavaScript, and Bootstrap..
- Google Chrome Developer Tools was used for website troubleshooting, and testing (including Lighthouse reports).
- Google Chrome was used for website testing.
- CSS Tools: Reset CSS to reduce browser inconsistencies.
- The Responsive Viewer extension was used in all browsers (except Firefox, which does not seem to support it) to create images of the website's pages on a variety of devices.
- The GoFullPage extension was used in all browsers (except Firefox, which does not seem to support it) to capture full-sized images of the website's pages.
- Microsoft Edge was used for website testing.
- Firefox was used for website testing.
- Opera was used for website testing.
- Safari was used for website testing, and mobile screenshots ofan iPhone 12 Pro Max and iPad Pro (12.9-inch) (2nd generation).
- Figma was used to create the user flow diagram, logic flowcharts, and wireframes.
- Deposit Photos was used for these images on the site:
- Baize background image TBC.
- Sarah Renae Clarke's Colour Catalogue V2 was used for the website's colour scheme.
- Font Joy was used for font pairings.
- Google Fonts was used to source all fonts.
- Brand Palettes was used to source the correct Instagram and Facebook link state colours.
- Microsoft Photos was used to edit all images.
- RespImageLint was used to ensure all website images were fully responsive.
- To WebP was used to compress images into webp format.
- FontAwesome was used for social media icons.
- GitHub was used for version control.
- GitHub Pages was used to host the website.
- Gitpod was used as an online IDE.
- Markdown was used to create the README.md and TESTING.md documentation.
Acknowledgements
TBC