Shopify UX Developer Challenge - Winter 2019

This is a project developed for the UX Developer Intern (Winter 2019) challenge.

Shopify describes a UX Developer as someone who is able to "write well-structured semantic HTML, build maintainable and scalable CSS and work with modern JavaScript (ES6+, ReactJS)". It's also important to create high quality experiences for EVERYONE.

These goals were set as the foundation of this project. You can read more about the decisions I've made to fulfill them on the Methodology section.

Table of Contents

• 1. Demo
• 2. Requirements
• 3. Installation
• 4. The Challenge
  • 4.1. Goal
  • 4.2. Screenshots
• 5. Why React?
• 6. Methodology
  • 6.1. Accessibility
  • 6.2. Form Validation
  • 6.3. Components
• 7. Technology Stack
• 8. References

1. Demo

View demo on CodeSandbox.

2. Requirements

• Node.js
• NPM

3. Installation

1. First, clone this repo using Git or download the zip

git clone https://github.com/LucasLacerdaUX/ShopifyUXDeveloperChallenge-W2019.git

2. Use npm to install the dependencies

npm install

3. Start the Parcel bundler to run the project on localhost:1234.

npm start

4. The Challenge

4.1. Goal

Build a single-page responsive website for a fictional tech startup – AcmeStack. You must recreate, as faithfully as possible, this single-page website.

You can view the detailed project specification here.

4.2. Screenshots

• Desktop (1440 x 900)
• (Mobile) iPhone 5 (320 x 568)
• (Mobile) iPhone X (product render)

5. Why React?

After a long time studying Vanilla JavaScript (ES2015, ES6+), I've recently started using ReactJS. As a Designer, I usually start my projects from the smallest isolated components up to the full solution, building a rich and consistent Design System.

I found React components to be a perfect way of translating my libraries of UI elements to code. It also helps me ensure that each component meets its best accessibility standards individually. React is powerful, flexible and maintainable.

6. Methodology

6.1. Accessibility

This project was built with a goal in mind: make it usable for everyone. The components make use of alternative text and labels to provide an inclusive experience with images, inputs, and buttons. The final result has been tested with both mouse, touch and keyboard navigation and with the help of a Screen Reader (SR) to make sure it's completely usable.

However, there are still some improvements that could be made to the user interface, like always displaying the text label on inputs and improving the contrast ratio in some areas. These were not changed on this project since the goal was to recreate, as faithfully as possible, the provided layout.

Most of the decisions made on this project were heavily influenced by the Techniques for WCAG 2.0 accessibility guidelines and by recommendations set on Shopify's own Polaris guidelines.

6.2. Form Validation

The implementation of form validation has many different approaches. The pattern chosen for this project was based on recommendations by the WCAG 2.0 and the form validation section of Polaris Guidelines. This is how it works:

• The field is considered invalid when it's been touched AND its content is either empty or outside the valid length range.

• Validate on Submit: When the user presses the form submit button or the ENTER key, all form fields are validated, regardless of whether they have already been touched or not.

• Validate on finish typing: The validation occurs when the keyboard focus moves away from the field. This avoids marking the field as invalid while the user is still typing a possibly valid input. As soon as the user presses the TAB key or clicks somewhere else on the screen, the field is marked TOUCHED and its contents are compared with the validation rules.

• Real-time validation on invalid fields: Once a field is marked as invalid, the validation checks occur after each keystroke. This helps the user to immediately notice when the issue has been fixed.

The invalid fields are instantly marked with aria-invalid="true" and visually highlighted with a red border. A live region using aria-role="alert" and aria-live="assertive" not only displays the error but also makes sure it's always readen by SRs, allowing any user to understand what needs to be fixed. As recommended by the W3C's ARIA19: Using ARIA role=alert or Live Regions to Identify Errors technique, "each time a new submit is attempted the previous error messages are removed from the container and new error messages injected". That simply means we need to force React to re-render the error region's DOM on each submit, even if its content does not change.

6.3. Components

The components built on this project are intended to be reusable. Not only can their labels and visuals be customized by the containers that use them, but they've also been made as dumb as possible to allow you to customize their behaviors.

Each component folder contains its own documentation.

7. Technology Stack

• React
• SASS
• ESLint w/ Airbnb style guide + Prettier
• Parcel Bundler (CodeSandbox does not support SASS on Webpack yet)

8. References

Techiniques for WCAG 2.0

1. G83: Providing text descriptions to identify required fields that were not completed
2. G85 - Providing a text description when user input falls outside the required format or values
3. ARIA19 - Using ARIA role=alert or Live Regions to Identify Errors
4. ARIA21: Using Aria-Invalid to Indicate An Error Field
5. G131: Providing descriptive labels
6. ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls
7. G89: Providing expected data format and example
8. H44: Using label elements to associate text labels with form controls
9. SCR18: Providing client-side validation and alert

Other

10. Shopify Polaris - Error Messages (Form Validation)