Oral History request UX improvement thoughts

Owned by Jonathan Rochkind
Last updated: Oct 26, 2023
4 min read

Focusing on people who request multiple OH’s, a regular (couple times a week?) use case.

  • In a few cases they request a whole collection (only TCSA so far?) – maybe once every few months?

  • In other cases (couple times a week), they request 2-6 (or as many as 25 or more) disparate OH’s

 

 

Three basic elements:

  • The user’s request process

  • Staff’s process of approving requests

  • The user’s process of accessing fulfilled requests (and possibly request status) process

 

Request process

  • For the majority of people who only request one OH, we don’t want to increase clicks/friction – the ease of request is probably contributing to current volume of requests

  • For the more common case of disparate multi OH requests, the user is still going to have to click to identify each OH they want to request

Simplest thing that could help?

What if the same process is there now, but we “remember” the answers to the form (for a day/week/longer), such that if the user is using the same browser, the form is “pre-filled” with their previous answer(s)? (If they switch from phone to desktop or browser, it would not be)

Other ideas?

Access process

Right now if they request 2-5 or 10-20 OH’s, they get one email per OH, with file list and links in that email.

  • Is this annoying/problematic for people? Or is it just fine? Does it need improvement?

  • Is getting this delivered by email, and one per email, working for people? Or would they rather have web access, once approved?

  • We don’t want to give people an account with a password, people are sick of that, and it’s added friction. If we are going to have them “login”, we can do it with an emailed login link – we are already emailing, but can email a link to click on to go to a “dashboard” of sorts.

Dashboard/portal refactor

  • Consideration: try to discourage sharing. while we already allow user to download files they technically could share, we don’t want to make mass sharing through our system easy. Our current emails include download links that are only good for 7 days, to make it so you can’t just share the links and have them on the internet working forever (although they are working for 7 days!)

 

  1. instead of getting emailed files, user gets emailed a link to login to their Request portal/dashboard/delivery area.

    1. Unclear how/when/how often they’d get this email. Every time they request? Every time an approval happens? (or rejection – do you ever even do rejections?)

    2. This login link will still expire after – 7 days? (user can always request another login link though)

 

  1. Clicking link takes you to a “dashboard” or “portal” listing all your requests, status, and any notes or comments added by OH staff.

    1. (Do these things remain approved forever, or for a limited time? Need to re-request to renew?)

 

 

  1. When you click on an approved item,

    1. you could go to list of files with download links, similar to what is received in email now –

    2. OR, you could go to an ordinary OH web page, like we have now for public items, with an audio player and everything, that you are now authorized to see because your request has been approved?

      1. Eg https://digital.sciencehistory.org/works/4j03d084r

      2. But perhaps with any staff notes about the nature of your approval prominently displayed as well

 

 

Approval process

Because even within a collection different OH’s can have different approval considerations, it still needs to be a manual process of specifically designating what you want to approve, I think? And you still need ability to enter and attach access restrictions/notes seperately for each item?

But I guess we could group requests by person, and allow you to use checkboxes to approve a bunch at once?

How much is the current process actually a problem/inconvenience, to have to click ‘approve’ for each one individually? Is it super annoying waste of tiem, or no big deal?

  • Note only one “statement of purpose” for all requests

  • Trying to let you bulk approve with checkboxes… but since still need individual notes, and ability to approve/deny individually… hard to provide both options sensibly.

  • The actual LIST of requests, do we need to change it, or still list them all separately, but when you click on one you get this form? Maybe list needs to be filterable by pending/approved/rejected

  • EXPORT is still the same format, with separate requests?