first volunteer coordinator – usability – a click analysis

I am co-volunteer coordinator for the NYC FRC (FIRST Robotics Competition) regional. The volunteer system could have better usability.  I’ve been thinking about writing up a “click analysis” for common workflows. The idea being that good usability shouldn’t take a large number of clicks to do something common. When my friend asked how to cancel an application, I finally decided to it.  (cancelling is at most 4 clicks once logged in which isn’t bad. )

But on to the most common volunteer task once you are logged in as a volunteer coordinator. How many clicks and are they all necessary.

Accepting a volunteer – 9-12 clicks

  1. Click on the regional name [if you only manage one event, this click should be inferred and not something you have to do each time]
  2. Click on the role you want to assign
  3. If you don’t already know the person, right click their name for details (to open in a new tab)
    1. Click current applications
    2. Click assignment history
  4. Either drag the person’s name to the table at the bottom or click the checkbox and then
    “move applicant into schedule”. I find dragging slower, so this is two clicks for me.
  5. Drag tentative to the table once per day the person wants to volunteer. (Or drag once and expand the bar to cover all the days). So this is 1-3 click/drags
  6. Click complete assignment
  7. Click checkbox for name again
  8. Click assign and notify selected
  9. Type message
  10. Send

Seeing all unassigned volunteers = 3 + 2n

There’s a report called “all unassigned volunteers”. But it doesn’t have links from the person’s name to their profile. Which means you can’t assign from there and have to do it the long way.

  1. Click on the regional name
  2. Click a role. Ideally without any unassigned volunteers
  3. Click unassigned applicants
  4. Right click each to open new tab
  5. Click current applications

 

 

how to cancel when volunteering for first (frc/ftc/fll)

A friend asked me how to switch from one volunteer event to another on firstinpires.org. It isn’t intuitive at all.

The answer:

  1. Logon to firstinspires.org
  2. Click “My dashboard”

If you were already assigned to the role

  1. Expand “assigned event volunteer roles”
  2. Click “Role options” pull down
  3. Click message coordinator and write a message that switched to Saturday

If you were not yet  assigned to the role

  1. Expand “pending applications”
  2. Click “Role options” pull down
  3. Click “withdraw application”
  4. Click “withdraw”
  5. Hope it worked. The role still appears in your list so you aren’t automatically withdrawn (not great usability)

[2018 oracle code one] JWT’s suck

JWTs Suck
Speaker: Randall Degges
@rdegges

For more blog posts, see The Oracle Code One table of contents


JWT (JSON Web Token)

  • pronounced “jot”
  • JSON data
  • cryptographically signed
  • Not encrypted most of the time
  • Prove that some JSON data can be trusted
  • Common use case: Website generates JWT after validating credentials. Website then sends JWT to browser and browser stores in localStorage. Then browser sends to website for subsequent requests.
  • There are stateless and stateful JWT. The later maps to a session id. People don’t use stateful JWTs.
  • 2012 – Spec came out
  • 2014 – began gaining adoption/marketing
  • seven of the first 10 hits on jwt are marketing pitches

Cookies

  • JWT stores session id as JSON blob. In cookie, just a string.
  • Session cookies are underappreciated
  • Use HttpOnly flag
  • Use SameSite-strict flag
  • Use secure flag
  • Browser sends cookie header to website

HTML Local Storage

  • JavaScript only accessible
  • Store key value pairs in browser

Myths about JWTs

  • JWTs are easier to use – JWTs require additional tools, libraries and knowledge to function. Developer effort. Vs session cookies which are built into all web frameworks.
  • JWTs are more flexible – Cookies can store one piece of data per cookie or serialize into a cookie. JWT has claims which are certain pieces of data that always included – ex: when token created/expires. Cookie actually expires at expiration times. Tokens don’t disappear automatically
  • JWTs are more secure – Cryptographically signed and can be encrypted. However, actually using the encryption feature is rare. The spec is complicated and libraries vary in support. Also multiple vulnerabilities in past two years.
  • JWTs prevent CSRF – Cookies are susceptible to CSRF because sent to server automatically. Local storage is safe from CSRF because developer needs to write JavaScript to send the data. However, you are now vulnerable to XSS which is worse. CSRF is far easier to fix than XSS because most websites link to Google Analytics, third party jquery, etc. OWASP recommends not storing any sensitive information in local storage.
  • JWTs are better for cross domain authentication – Good when create temporary token that lasts for 10 seconds. It is used between the login service and your app.
  • JWTs are more efficient than cookies – 179 bytes. If just sign the id part, is 64 bytes. Difference even greater when add data.
  • JWTS are easy to revoke – Could change signing key of application, but that also logs out the other users. Alternatively, use the revocation list pattern so can invalidate one. But now you’ve introduced state/database/cache.

Better use cases for JWT

  • Short duration (one minute or less) for one time use
  • ex: downloading a file, reseting a password

My take: I hadn’t heard of JWTs. So I learned a lot! It was fun hearing the audience questions/comments/statements was fun. That said, I need to read up on the topic to see the other point of view.