This post provides more detail about my Spendr online banking prototype.
This project served one purpose: Demonstrate for employers my competency with React and Redux. I think it achieves that purpose, but I will follow it up with another React project.
While the subject of the site is a new approach to online banking (one that attempts to reduce spending frequency by requiring explicit approval of each transaction before the transaction is processed) my focus is more on the execution and technique of creating the website.
I'd like to call attention to a few noteworthy parts:
- The visual appearance is clean.
- Information is clearly presented.
- All colours (fonts and backgrounds) meet W3C (World Wide Web Consortium) WCAG 2.0 (Web Content Accessibility Guidelines) minimum contrast ratio of 4.5:1.
- HTML (hyper text markup language) is structured with necessary W3C ARIA (Accessible Rich Internet Applications) attributes to deliver a screen reader capable experience. See video demonstrating screen reader usage.
The visual appearance looks nice, in my opinion, and the design is clean and simple, which I think delivers the information well.
Google now presents contrast information in their widget for picking text colours. Making an accessible web application has become easier.
When I first tried using screen reader software on Spendr I found out it was impossible to understand. After a day of learning to use Google Chrome's Vox screen reader extension, and making plenty of changes to my HTML structure and employed ARIA attributes, I finally created what I think is a screen reader capable site. Below is a video demonstration of myself using a screen reader to navigate the Spendr site.
A lingering question I have regarding Redux is: What state do you leave out of Redux?
- Current list of transactions: Put in redux.
- Currently detailed transaction: Put in redux.
- Currently focused transaction: Hmm...
For example, redux doesn't store the entire state of the interface, such as the current DOM (Document Object Model) nodes. It would be ridiculous to store all that information in redux. Yet, my understanding of redux is that it stores all of your application state. Isn't the state of the interface, even what transaction is currently focused by the browser, part of the state of the application?
The issue I ran into was in trying to manipulate the DOM, such as focusing specific elements, but not having sufficient information in my Redux state to do what I wanted. I didn't want to put that information into Redux, and so stored it other places.
But the question remains, what application state (like interface state) do you leave out of Redux?
I think I will become better able to answer that question as I gain more experience with React and Redux.