This app, User Verification System, is a basic CAPTCHA-style program to verify the end-user is a human rather than a bot. It can also be utilized for machine learning applications related to picture recognition. Click here to launch the app!
This project is Unit 1 end assignment from General Assembly's Software Engineering Immersive program. For more information on the specifications of the assignment please reference Appendix A: Unit 1 Project Assignment from General Assembly.
Click here to see the currently deployment version of this app.
- Instructions for Use
- Version Notes
- Tech Framework
- APIs
- Future Plans
- Contribute
- Special Thanks
- Appendices
The user starts on a page with a random picture of either a dog, a car, or pizza. Next to the image are four buttons:
- Dog
- Cat
- Pizza
- Other
The user clicks a the button matching the subject of the image. When this happens the image will be shown a new image and repeat the process. After the user attempts to identify the subject of six images they'll be given a report based on their success.
Success If the user successfully identifies the subject in at least 5 of the 6 images they'll be congratulated as either a human or a computer program developed by an engineer with strong skills in machine learning.
Failure If the user fails to successfully identify the subject in at least 5 of the 6 images they'll be informed they are likely a computer and console the engineer about its performance.
- A number of features in the program were implemented to prevent reasoned guessing at the subject of the image without being able to identify it visually.
- The API results will appear in a randomized sequence. There is no correlation between the subject of one image and the next.
- The APIs will be queried for twice as many pictures as the user will be shown. Correct answers will not be evenly distributed between the three categories.
- All pictures are of dogs, cats, or pizza. The Other button will never be the correct button short of either more API calls being implemented at a later date or one of the APIs erroneously supplying an off-theme image. The developer looked at several hundred images and did not find any such images.
- The user is not informed how many guesses they have made correctly or incorrectly. The app will also show 6 images in total even if the user reaches the threshold of incorrect answers to trigger failure.
- This is a mobile-responsive app although the mobile and desktop/tablet variants are functionally identical. The only differences are minor stylistic changes related to maintaining a reasonable size and scale for a smaller screen. Please reference Appendix B: Product Screenshots & Images for further information.
- The event listener for button clicks has a different argument hard-coded into each place it's called in the template HTML. This argument is compared to metadata in each image JSON to determine whether the correct button was clicked.
- The number of pictures the user must correctly identify to be verified as a human as well as the total number of pictures the user is shown by the app can both be modulated easily.
- Change the value of
state.turingThreshold
to positive integer to adjust how many correct guesses the user needs to log to be judged human. - Change the value of
state.maxWrong
to any positive integer to adjust how many wrong guesses the user will be allowed to make and still pass the verification test. - These two values are the bedrock values that the app uses to function. So long as both numbers are positive integers the code will adjust to them. If someone forks this repo and uses the app as a module in their project they don't need to worry about entering incompatible values that cause to crash or needing to make other adjustments to the code.
- Change the value of
- Clicking the app title User Verification System will re-initialize the app while resetting necessary values in
state
to their initial values where necessary.
The 1.1.2 version of this app is currently uploaded. In cases where I update the README without any updates to the website itself I do not update the version number or use branches for my work. Each version number will lack a commit number until the next version is uploaded. The current commit number is always added retroactively. In general, for version number format X.Y.Z:
- X: increases in this number represent a complete overhaul of some section of the website, source code, or UI
- Y: increases in this number represent a major functional change/aesthetic change or addition to the app
- Z: increases in this number represent changes that are relatively minor but still warrant a new commit
Version 0.1.0 is the first version with the full range of intended functions successfully implemented. Version 1.0.0 is the first to be both full functional and styled with optimized coding.
- Set up boilerplate HTML in
index.html
. - Linked
styles.css
andscripts.js
toindex.html
.
- Created basic HTML containers.
- API calls are set up and returning positive results.
- API results are being formatted into JSONs and populated into an array in state appropriate for use by the app.
- Sequence of API results in the results array is now randomized.
- First picture in the API results array is rendering.
- Buttons are rendered.
- Created click handlers and attached them to buttons.
- App is applying logic to determine if button clicks are correct or incorrect.
- No significant changes. I accidentally made a commit in this directory while working on a different project. Oops.
- App now loops through every picture in the array.
- Created remote repository on GitHub and pushed code.
- App displays results of Turing test once all pictures have been looped.
- Basic functionality is complete (needs additional work before initial deployment).
- Built out
README.md
. - Increased the number of API calls made by the app to increase picture set randomization.
- Added custom fonts.
- Worked on object centering and spacing.
- Added an instructions box.
- Implemented a color scheme.
- Buttons highlight with an outline on mouse hover.
- App is styled, optimized, functional, and ready for deployment.
- Fixed vertical spacing issues.
- Added
<header>
and<footer>
sections. - Refactored code for several improvements.
- Better separation of concerns.
- Reduced functions to one-liners where feasible.
- Functions only run asynchronously when necessary.
- Added mobile-device responsiveness.
- Added screenshots of product variants and wireframe mockup to
README.md
file.
- Fixed mis-labeled images in
README.md
file.
- Refactored
getImages()
to run with ado...while
loop instead of afor
loop. Thewhile
condition runs API queries a number of times relative tostate.turingThreshold
. This will increase stability by reducing the chance someone else forks and uses the app and changes values to produce an insufficient number of images compared tostate.turingThreshold
for the app to work. - Refactored user-interactable elements (all
<a>
elements and hyperlinks) out of template HTML and into variables. Variables are then injected into HTML template literals.
- Removed
console.log()
statements and other testing/validation code.
- Deployed app to surge and updated
README.md
with a link.
- Fixed errata in Version Notes in
README.md
file.
- Made a document title to the
index.html
file<head>
section. - Added TODOs in the
README.md
file. - Created alt-text for images in the
README.md
file. - Added a favicon.
- Fixed formatting issue with alt-text in
README.md
images.
- Fixed spelling and grammatical errors in the
README.md
file I'd somehow missed. - Fixed script compiling error in HTML
<head>
related to favicons.
- Reorganized file structure holding images. Only affects images in the
README.md
, updated filepaths where they're linked. - Added a Table of Contents and internal hyperlinking to
README.md
. - Refactored app to make the total number of allowable incorrect guesses easier to modulate.
- Moved HTML template generation out of
turingTest()
and into a dedicated functionrenderTestResult()
. - Clicking the app title in the
<header>
element re-initializes the app and resetsstate
values as necessary.
- Fixed formatting error in
README.md
Table of Contents. - Added a link to the
surge.sh
hosted site in theREADME.md
Introduction.
- Fixed formatting error in
README.md
Table of Contents. - Added a link to the
surge.sh
hosted site in theREADME.md
Introduction.
- HTML5 and CSS
- JavaScript ES6
- VSCode version 1.53.2
- Google Chrome version 88.0.4324.192 (Official Build) (arm64)
- Homebrew 3.0.2
- Zsh 5.8 with Oh My Zsh
- GitHub (online, not desktop)
- macOS Big Sur version 11.2.1, Apple M1 chip
Dog images were supplied by the Dog API. This API is free, open-source, and does not require authentication. The Dog API welcomes your support to help it continue providing its services.
Cat images were supplied by the random.cat API. This API is free, open-source, and does not require authentication. You can support the random.cat API at the prior link to help it continue providing its services.
Pizza images were supplied by the Foodish API. This API is free, open-source, and does not require authentication. You can support Foodish to help it continue providing its services.
- Refactor the code to exist entirely within JSON to increase modularity.
- Compartmentalize
<header>
and<footer>
elements so that they're easier to remove if incorporating the app as a module in a larger project.
- Compartmentalize
- Incorporate more subject-specific picture APIs to increase validity of the Other button.
- Eliminate
state.currPictureSubject
by havingclickHandler()
look directly in the picture's metadata rather than holding the current image's type in state. - Refactor app to decide number and types of images and then query APIs rather than to query APIs and choose pictures from returns. This will reduce the number of API calls and decrease initial loading time.
- Refactor the app to process API calls and other processes on the back end so that the user cannot access metadata used for verification in the front end.
Although I'm always interested in meeting new collaborators I prefer to keep this an individual project as a skills demonstrator.
I'm happy to let anyone reuse my code so long as you contact me for advance permission and give attribution where appropriate. Some materials are specified in this README as proprietary material from General Assembly and should only be used with the direct permission of General Assembly.
If you'd like to learn more about the developer, please visit my website and my GitHub.
-
Instructors and peers from the General Assembly SEIR-EC-2-22 cohort for collaboration in developing this app. While this app represents my own original work we gave each other assistance in developing our own versions thereof.
-
All the APIs used in this app were found through public-apis, published by the Public APIs Project. All the APIs are free, open source, and do not require authentication. Please refer to the APIs section of this file for more information on each.
-
Formatting this
README.md
file was easy with the help of the Markdown Live Preview tool and GitHub Guide's Mastering Markdown page. -
I found the font Poppins through Google Fonts. It was created by Jonny Pinhorn and the Indian Type Foundry and made available for use through the SIL Open Font License.
-
The color palette was developed with the help of Coolors.co and tested for accessibility with Color Safe.
-
Deploying this app was made easy by surge.sh with a free version adequate for my needs.
-
I used Whimsical to generate the wireframe images seen in Appendix B: Product Screenshots & Images.
-
The favicon was generated with the help of favicon.io, a free utility developed by John Sorrentino. You can click here to support him.
Information in this section was reproduced with the permission of General Assembly. Please do not copy or republish without the direct permission from General Assembly to do so.
Your first SEI project will be something cool - an app that makes API calls!
Everyone will get a chance to be creative and work through some tough programming challenges. You got your feet wet with Tic-Tac-Toe, and we built the guessing game during class and the YeTay App we coded together in class - now it’s time to step it up a notch.
You will be working individually on this project.
As a reminder, GA has a zero-plagiarism policy - your project’s code must be substantially yours. Do not copy code from similar projects or other sources. However, using code from StackOverflow to accomplish general techniques/algorithms is okay - for example, a line of code that replaces a character at a specific position in a string.
You will have an absolute maximum of 8 minutes to present your project following these guidelines:
- Introduce the Project:
- Intro your app by paraphrasing the README.
- Demonstrate the Project:
-
Launch the app by clicking the link in the README.
-
Demonstrate the app!
- Show/discuss your code:
-
Briefly show the HTML & CSS.
-
Show the JavaScript and discuss your favorite function.
- Share the experience:
-
What was your biggest challenge?
-
What are your key learnings/takeaways?
Q & A + Feedback may also follow your presentation but is not part of the time structure.
How you structure your presentation is ultimately up to you as long as you cover the above points, but others have found success by following the above order and spending a roughly equal amount of time speaking to the above 4 points.
Your App MUST:
-
Render an application in the browser.
-
Use either Bootstrap, Materialize, or your own custom, well-styled CSS.
-
Include at least two (2) APIs with different endpoints
-
Include separate HTML, CSS & JavaScript files.
-
Have properly indented HTML, CSS & JavaScript. Additionally, vertical whitespace needs to be consistent.
-
No remaining dead or commented out code (code never called).
-
Have functions and variables that are named sensibly. Remember, functions should typically be verbs and variables (data) named as nouns.
-
Have consistent code choices. For example, choose between your preference for function declarations vs. function expressions.
-
Be deployed online so that the rest of the world can use it!
-
The code for a working application that meets or exceeds the above technical requirements, built by you, and hosted on the internet (covered next week).
-
A
README.md
file with these sections:-
<Your app’s title>: A description of your app. What was your inspiration?
-
Getting Started: Include a link to your deployed app and any instructions you deem important.
-
Screenshot(s): Images of your actual app.
-
Technologies Used: List of the technologies used, e.g., JavaScript, HTML, CSS…
-
Next Steps: Planned future enhancements (icebox items).
- Don’t underestimate the value of a well crafted README.md. The README.md introduces your project to prospective employers and forms their first impression of your work!
-
-
Frequent commits that date back to the very beginning of the project. Never delete your repo to “start over”. Commit messages should be in the present tense. Be sure to create the repo on your personal GitHub account and ensure that it is public.
-
Theme your app to give it a more personal touch and make it more unique!
-
Use your Development Tools (Chrome DevTools rock!) to debug and solve issues.
-
Please keep it simple. Minimum Viable Product (MVP) functionality that looks great is better than extra functionality added to an app without polish.
-
Review and check the Project 1 Code Review regularly to ensure that your project will meet the minimum requirements.
-
Consult documentation and other resources to understand methods, etc.
-
Write DRY (Don’t Repeat Yourself) code. Check for repeating code and refactor into functions that accept arguments.