I’ve been locked in building this tool, I haven’t stopped to write anything about it. I decided to create a web app dashboard that will provide a better UI for our clients to view their bookings. If you’re interested in the details of our current UI you can read about it here. Long story short, a row in Google sheets isn’t very mobile friendly!
My requirements
- It has to be dead easy.
- It has to be security conscious
- It has to allow access for multiple parents or guardians to their related client.
- It has to allow a parent or guardians to access multiple related clients
- It has to integrate with existing systems
- It HAS to be mobile friendly
- Data has to stay fairly fresh
Our clients are from all walks of life and don’t have the time, motivation, or mental energy to learn a new system or deal with a frustrating Auth process. To provide a simple UX, the page has
- list / calendar view
- Filters for All / Confirmed / Waitlisted / This Week
- Refresh button to fetch bookings without page reload. This button triggers automatically after 15 mins
- Toasts, skeletons and spinners for user action feedback
- Subtle movements to emulate a sense of “aliveness”
- no html forms
Security
Front end / back end separation in Google App Script web apps is interesting. Only two file types are allowed: html and js/gs. Js/gs contains all server side code, with private functions and classes ending in an underscore (e.g. const SPREADSHEETID = …). html contains all front end code, declared within script tags placed in the body. Data is sanitised before being passed to the front end, so all that is passed through is a client name(s) and their bookings.
Authentication is handled by Google, with access requiring a Google account. I’m not going to build a more robust authentication than Google.
The Authorisation strategy was a fun one to figure out. The meet requirements 2-4, I decided to implement a tokens. Tokens are generated when a sheet is first created, and are rotated whenever all sheets are batch updated. Tokens are stored in a separate sheet along side a user-token association sheet and an access log sheet.
A link containing a current token unique to each client is added to a given clients spreadsheet each time it is updated. Client spreadsheets are only editable by Care Culture. Both parents, grandparents, and who ever has access to the clients BookingBuddy can access this link. Clicking the link opens the web app which will add new association, verify the user, and fetch and display bookings. After the initial association the user can visit bookings.careculture.com.au and view all their associated clients bookings (as long as they’re logged in). The only identifiable information is the clients name, no other personal data is available in this web app. As such, the choice to use rotating tokens and Google account related association for my authentication and authorisation strategy carries very low risk. The low friction this strategy provides a single click sign up followed by pseudo-loginless* access to the app.
- Google pretty much always logged in anyway!e no
To fix:
- Push badges to bottom
To do: Utilise an additional sheet that is updated when the bookings are updated to sheets so they are in sync with them and data doesn’t change too frequently. Flow is
- Save and update yada yada
- Update client sheet (updates hidden master sheet)
- Update all (updates hidden master sheet)
- User goes to their dashboard - bookings retrieved from hidden master sheet
UI ideas:
- Hi (if name && name 2 || name)
- Fetching bookings….
- Upcoming bookings
- List mode, calendar mode
- Send message regarding X Client bookings flow
- Get user email, check if true and if on whitelist - whitelist from BookingBuddy
- If all true, add fetching booking element, getBookings, then return to page
Areas to test
- Are accesstokens double created? Should old tokens be remove?
- AccessLog generates a tone of data. 4921 rows over 6 days
- Change time until to
- Today
- Tomorrow
- 3-13 days = n days
- 2-7 weeks = n weeks
- 8+ weeks = n months