Feedback

[esin87]

Project 1 Feedback

Code Quality - Performing

Criteria: Is the code well formatted? Are variable and function names semantic and sensible? Is the code easy to read and understand?

Strengths:

• Code is well-formatted with semantic and sensible naming throughout. Relatively consistent syntax and conventions followed throughout.
• Code is easy to read and understand. Good job adding comments to your script.js that explain what the code is doing. Code is well-organized as well within individual files.
• HTML and CSS both pass validators with no significant errors or warnings.

Areas for Growth:

• In terms of your HTML markup, I would not use a div or br element just for spacing. I'd use CSS to add margins around the adjoining elements that you want to space farther apart. The div and br elements have their own meaning, and as we learned during the web accessibility study, it's important to use these elements semantically. In terms of semantic HTML, a div is a container element meant to hold other elements when more semantic containers like header, section, etc. don't fit the bill. And br is actually a line break element meant to be used within blocks of text (i.e., inside a p element) to break up the lines of text like addresses or poems. How could you introduce some more semantic elements into your HTML?
• In the vein of accessibility, specifically regarding buttons, I would also include some text in your gameplay buttons, perhaps making them transparent so that sighted users don't seee them.
• You did a terrific job writing some complex logic and reaching some advanced stretch goals in your JS! I have a couple suggestions for DRYing up your code and making it a bit more efficient. First, instead of keeping the player and computer sequences in arrays, those can be strings of indices, with 0,1,2,3 corresponding to the different colored squares. You're already stringifying the arrays to compare them, so why not improve your time and space complexity by using a primitive data type here? How might that affect the rest of your code? Secondly, there are a few opportunities for you to allow the power of variables to DRY up the code for you and make your functions leaner and more dynamic. For example:

function addColor() {
    //use const instead of let for any variable not intended to be reassigned
    const randomIndex = Math.ceil(Math.random() * 4);
    // instead of a long if/else sequence, just pass the number to colorSequence
    // then you can use the indices to grab the right element out of the colors array to light up
    selectButton(colors[randomIndex - 1]);
    colorSequence.push(randomIndex);

    // if (randomIndex === 1) {
    //  selectButton(blue);
    //  colorSequence.push(1);
    // } else if (randomIndex === 2) {
    //  selectButton(red);
    //  colorSequence.push(2);
    // } else if (randomIndex === 3) {
    //  selectButton(yellow);
    //  colorSequence.push(3);
    // } else if (randomIndex === 4) {
    //  selectButton(green);
    //  colorSequence.push(4);
    // }
}

In a similar vein, how could you DRY up your loop function?

• There are a few instances where you can DRY up your CSS styles. For example, for the difficulty menu buttons' styles, I'd extract their common properties and place them in their own class-based rule like so, then give them modifiers for their different colors:

.difficulty-menu__btn {
    height: 10%;
    border: 0;
    color: white;
    border-radius: 4px;
}

.difficulty-menu__btn .difficulty-menu__btn--easy {
    background: lightskyblue;
}

.difficulty-menu__btn .difficulty-menu__btn--med {
    background: gold;
}

.difficulty-menu__btn .difficulty-menu__btn--hard {
    background: lightcoral;
}

The corresponding markup would look like this:

<div class="difficulty-menu">
    <button class="difficulty-menu__btn difficulty-menu__btn--easy" id="easy">
        EASY
    </button>
    <button class="difficulty-menu__btn difficulty-menu__btn--med" id="medium">
        MEDIUM
    </button>
    <button class="difficulty-menu__btn difficulty__btn--hard" id="hard">
        HARD
    </button>
</div>

Note that we're using classes to select elements to style, and reserving the ids for JS DOM manipulation. You can name your classes in any way that makes sense and is sustainable -- the pattern I used here is something called Block Element Modifier (BEM), but there are many more.

Technical Requirements - Excelling

Criteria: How does the project stack up to the requirements for this project? Is the developer making use of the material we've covered in a way that makes sense?

Strengths:

• Your application meets all the technical requirements for Project 1. The app renders in the browser and no errors were observed in the console during game play. Nice job getting your app deployed to GH Pages, and also having a good history of commits dating back to the start of your project.
• Really nice job reaching a number of your stretch goals. The difficulty levels are super engaging and well-thought out and implemented. I'm impressed with how you managed your workload and time during project week to achieve these post-MVP features.

Areas for Growth:

• GitHub repo shows a good history of commits, but work on both the consistency of your commit message formatting as well as their content. Commit messages should be concise, descriptive, and consistently structured -- 'more README updates' is not ideal, though we're all guilty of having messages like that at one point or another. The standard is usually 'present-tense verb + description of what was done' for each and every commit. For example, 'Add styling to game container' or 'Refactor API call'. This is my favorite article on how to write good commit messages and why it's an important focus for developers.

Creativity and Interface - Performing

Criteria: Is the application easy to navigate? Does it work well in every major browser? Is it responsive? Does it incorporate modern UI Themes?

Strengths:

• App is straightforward to use and easy to navigate.
• The design is clearly mobile-first and looks good and is responsive on a number of screen sizes.
• I like the light color palette! It's refreshing compared to the usual dark Simon themes.

Areas for Growth

• I'd double check that the color contrast between the white text on the buttons and their background colors is sufficient for a11y purposes.
• Add a custom favicon to your site to put the finishing touches on your UI.

Functionality - Excelling

Criteria: Does the application work without errors or bugs? Does it present a complete app, where every feature is fully implemented in a way that makes sense?

Strengths:

• The application works without errors observed in the console during normal game play.
• App presents a mostly complete product, with a clear beginning, middle, and end.
• Features are implemented in a way that makes sense. Bonus features are implemented as well!

Areas for Growth:

• As you mentioned, it would be great if the game errored out at the user's first incorrect choice instead of having them finish the sequence.
• The only other suggestion I'd make for functionality is making the board not clickable during the computer light sequences. You can use .removeEventListener to achieve that!

Presentation - Performing

Criteria: Is there adequate documentation? Is the repository well organized and free of clutter?

Strengths:

• The README.md looks great! You covered the important areas, such as a screenshot of your app, technologies used, installation instructions, and unsolved problems. This is the first point of contact to your application, and does a great job of introducing your application.
• Nice work including your planning documents here as well.
• Good job adding a description of your app and a link to your deployed game in the About section.

Areas for Growth:

• I would delete the .vscode settings folder from your GH repo -- it only appears to have a setting for Live Server to run on port 5501.

Hard Requirements - Complete:

• [x] Render in the browser
• [x] Include separate HTML / CSS / JavaScript files
• [x] Use Javascript for DOM manipulation
• [x] Be deployed online, using Github Project pages and/or to a custom domain.
• [x] Use semantic markup for HTML and CSS (adhere to best practices)
• [x] Show a good commit history with frequent commits

Necessary Deliverables - Complete:

• [x] A hosted copy of your game, built by you, hosted on Github Pages
• [x] Your HTML/CSS should pass the HTML5 Validator and CSS Validator
• [x] A git repository hosted on Github with frequent commits dating back to the very beginning of the project
• [x] A link to your hosted project in the URL section of your Github repo
• [x] A readme.md file, including explanations of the technologies used, the approach taken, installation instructions, unsolved problems, etc.

Grade: Pass :tada: :tada: :tada:

Kaleb, excellent work on this project! Super impressed at all the effort you put into creating this deluxe, modern version of Simon. The design is clean and professional, the code is easy to read, and the functionality is above and beyond MVP. There are some areas to revisit as you continue working on this project, such as refactoring your HTML to be a bit more semantic, making your CSS rules more efficient, and DRYing up your JavaScript, but overall, you did a fantastic job. Thank you for all your hard work on this, and for delivering a project that goes above and beyond the requirements. Can't wait to see your continued progress in the course!

[esin87]

One more thing I forgot to add -- it's faster to add Google fonts via link elements in HTML than in a CSS @import. Just be sure to add the links before your own stylesheet so that font names are accessible, and be sure to grab the pre-connect link as well.