Assignment 7

Release 1.4

Links to Submitted Files

• Frontend repository
• Backend repository
• Updated use cases as per discussion between Tony and teaching team

Progress and Contents Summary

In this release, our team has made significant progress in . . . literally everything. This submission includes:

• The Dashboard UI, implemented and dynamic (interacts with backend, fully wired)
• The Reading Karaoke flow, imported and providing real feedback (interacts with backend, fully wired)
• A settings page (which doesn't interact with the backend but allows users to change the language they're using on the frontend for demo purposes)

Summaries of Issues Addressed

In the time since A5 was due, many many issues were addressed spanning all parts of our application. You can see them through this link to Jira

Changes to the Roadmap, Architecture, or Use Cases

Use Case Updates

• Certain items were moved out of scope, after discussion with the teaching team. For details, see #41.
• Note that "Button to go to aggregated feedback" is actually more like "button to go to sentence overview page".

Additional Notes

Code Quality

We enforce code quality across both our backend and frontend codebases by integrating linting tools into our CI workflow.

On the backend, we use Ruff, a fast and modern Python linter. Ruff is significantly faster than traditional Python linters like Flake8 or pylint, which allows it to be seamlessly integrated into our CI without slowing down the pipeline. It enforces a wide set of style and correctness rules, helping us catch issues such as unused imports, undefined variables, and stylistic inconsistencies early in the development cycle. Ruff's zero-dependency design and compatibility with common configurations (like Black or isort) make it an ideal choice for maintaining clean, maintainable Python code.

On the frontend, we use ESLint with a custom configuration tailored to our team’s coding standards. Our ESLint setup includes rules for both stylistic consistency and best practices in React and modern JavaScript/TypeScript development. For example, it enforces consistent hooks usage and prevents dangerous patterns like direct DOM manipulation. Our custom rules are designed to promote readability and consistency, reduce bugs, and maintain a high standard of code across the team.

Both tools are tightly integrated into our GitHub Actions CI pipeline. Every pull request runs linting checks automatically, and code cannot be merged unless it passes. This ensures continuous enforcement of our code quality standards. Note that we have three separate workflows that are run on every push to a branch with an active pull request. For the sake of illustration, consider PR #25 on the frontend repository.

1. Build and Lint. This is how we ensure our entire frontend codebase is properly formatted, as this workflow fails if npm run lint produces any issues.
2. Playwright Tests. This ensures that the PR does not introduce breaking changes that would affect core flows within the application.
3. Enforce our PR title naming conventions. This maintains a standard naming scheme and allows us to easily trace which PRs correspond to which Jira tickets.
   Once all of the above is complete and one other developer ensures any issues they've seen are resolved and approves the PR, we then automatically deploy the newly-merged code.

The backend pipeline behaves similarly. For example, with PR #20 on the backend, we have:

1. Build, Test, and Lint building the backend, running our PyTest unit tests, and then running Ruff to ensure our code is properly linted. Notice that one of the actions includes a generating a code coverage report and uploading to CodeCov. As shown in this report, we have 65%+ test coverage. For the purposes of this submission, this is our chosen CI example run.
2. Enforce our PR title naming conventions.

We track maintainability through Code Climate:

• Frontend: Currently rated D for maintainability. We recognize this as an area that needs improvement, and have started identifying high-complexity files and refactoring opportunities as part of ongoing cleanup efforts (e.g. the page.tsx for the Reading Karaoke is very large, and should be broken down similar to the page.tsx for the Dashboard).
• Backend: Currently rated B for maintainability. This is acceptable for now, though we continue to monitor and address hotspots as they arise.

Our current linting and test coverage are satisfactory on the backend and somewhat satisfactory on the frontend for the team at present. We will continue to improve our code's quality and reduce our technical debt as the codebase evolves in our pursuit of making Pera a world-class pronunciation trainer.

Accessing the application

Pera can be used at https://pera-dydhd2huhybjakgg.canadacentral-01.azurewebsites.net/.
To get started, you can login with the following (this account has some practice history):
Username: tony@gmail.com
Password: test

Alternatively, you can create an account here:
https://pera-dydhd2huhybjakgg.canadacentral-01.azurewebsites.net/sign-up

WCAG Checklist

Guideline	Summary	Description of how you accommodated this
1.1.1 – Non-text Content	Provide text alternatives for non-text content	All graphs on our dashboard have tooltips that summarize the content in text form when the user hovers over it. We also have alt text on some images.
1.2.1 – Audio-only and Video-only (Pre-recorded)	Provide an alternative to video-only and audio-only content	We do not have any pre-recorded audio or video content
1.2.2 – Captions (Pre-recorded)	Provide captions for videos with audio	We do not have any videos on our application.
1.2.3 – Audio Description or Media Alternative (Pre-recorded)	Video with audio has a second alternative	We do not have any videos on our application.
1.3.1 – Info and Relationships	Logical structure	Our website follows general standards used across most modern websites (e.g. Having a navbar in the top or left half of the screen).
1.3.2 – Meaningful Sequence	Present content in a meaningful order	Our website follows general standards used across most modern websites (e.g. Having a navbar in the top or left half of the screen).
1.3.3 – Sensory Characteristics	Use more than one sense for instructions	We do not have non-visual items to help with navigation or instruction at this time, but hope to create sample audio in the future
1.4.1 – Use of Colour	Don’t use presentation that relies solely on colour	Most graphs on the dashboard only have color as an aesthetic instead of a data source. Highlighted text on errors is only one color, for instance, and we use a dark color so it is very distinguishable regardless.
1.4.2 – Audio Control	Don’t play audio automatically	We do not have audio to play.
2.1.1 – Keyboard	Accessible by keyboard only	Users can use the tab and enter keys to navigate between buttons and click on them.
2.1.2 – No Keyboard Trap	Don’t trap keyboard users	We do not use the tab or escape keys for any purpose with our application, so users are not prevented from un-focusing UI elements (and so are not trapped).
2.2.1 – Timing Adjustable	Time limits have user controls	No time limits are used.
2.2.2 – Pause, Stop, Hide	Provide user controls for moving content	No content can be moved, except for a slider which can be selected by tabbing and then the value can be changed with arrow keys
2.3.1 – Three Flashes or Below	No content flashes more than three times per second	No flashing content in the application.
2.4.1 – Bypass Blocks	Provide a ‘Skip to Content’ link	No content is present that blocks the flow of the user, like popups.
2.4.2 – Page Titled	Use helpful and clear page titles	Page titles prominently at the top of every page
2.4.3 – Focus Order	Logical order	Focus goes in order of nav buttons followed by top down left to right buttons on main content
2.4.4 – Link Purpose (In Context)	Every link’s purpose is clear from its context	The only links come from buttons to sign up or email us, and the text on the buttons clearly indicates this.
3.1.1 – Language of Page	Page has a language assigned	English is set in a cookie.
3.2.1 – On Focus	Elements do not change when they receive focus	No focusable elements are animated or cause major changes.
3.2.2 – On Input	Elements do not change when they receive input	No focusable elements are animated or cause major changes.
3.3.1 – Error Identification	Clearly identify input errors	Errors are displayed in text that suddenly appears and shows up below the input field.
3.3.2 – Labels or Instructions	Label elements and give instructions	Instructions are provided for any non-intuitive parts of the application (e.g. Reading karaoke)
4.1.1 – Parsing	No major code errors	N/A or obsolete
4.1.2 – Name, Role, Value	Build all elements for accessibility	Important components are named in our application
Colour Part II	Colours are chosen in a way that won’t make things difficult for colour blind users	Color scheme has high contrast and serves primarily an aesthteic purpose

Video Demo

You can watch a video demo of Pera in action here

What just happened?

• Navigated to deployed site
• Showed sign-up and login screens
• Logged in using provided credentials
• Visited dashboard and explained various features
• Visited settings and changed language
• Visited reading karaoke feature
• Imported text and started reading karaoke activity
• Explained various functions of reading karaoke
• Revisited dashboard to see updated stats
• Generated text and and experimented with options