♻️ Re-rethink the onboarding process #1076
Comments
shankari
changed the title
I think would solve the problems we've encountered with confusion over "scan to access the join page" then "copy and paste the string" that I have experienced while onboarding users, and would still allow for the "distribute personal opcodes" option. I don't think the generation in the app would be all that confusing, people don't seem to pay much attention to the opcode anyways until I tell them to save it. So for the "presenting" version of onboarding, I think this would be helpful. It would prevent anyone who might have been saving the opcode to/from their laptop to do that anymore, do we have an idea or any way of knowing if anyone was saving them that way? I could also see confusion if people were interacting with the join page independently, I wonder if people would think the |
|
I think all of the above ideas are great and could definitely make the onboarding process smoother. Here is my take on how we could potentially make it easier for users. A lot of the confusion comes from the op code website as Abby mentioned yesterday. It definitely makes sense too because there is that added layer of the user needing to get that op code into their app some how, which can for sure add confusion. I was thinking what if we just made the entire onboarding process be on the app so there is no need for scanning or copying OP Codes? My thought process was that we can auto generate the OP Codes in the app itself, and do what Jack mentioned, make a button saying Generate UNIQUE OPCode or something like that. To deal with the study specific op codes, I say we just add a screen, before the generate opcode one, that asks for a study identifier. Here is a rough visual implementation of the flow of the onboarding process I had in mind. 
I feel like if we were to do it this way it would be a lot easier for Abby to guide everyone through it as everyone stays on the app the whole time, and the only real help they need is to type in the study identifier. |
|
The problem with asking people to type things in is that they can make mistakes while typing - e.g. dfc_fermata versus dfc-fermata versus dfc_germata ... Maybe if we can validate as well, that would work |
|
Thats a great point, I think that could definitely cause some confusion. Maybe we can make the study codes the users are supposed to input a short hand version of the one we maintain on the backend, and have some type of mapping between the two (i.e. the user would input DFC, but we represent it as dfc_fermata in the backend like we already do). This mapping would give us that validation aspect as we could provide an error message if the study code they entered doesn't exist. |
|
After thinking about this, I agree that for studies where
How about having the QR code on the join page not be an OPcode at all? This way there will be no need for a "stub" OPcode that could potentially confuse people. No OPcode will even exist until it is generated on the phone |
We would still have this problem though, where there are 2 QR codes / links. The first QR code (included in a group presentation) is an What we'd really like is 1 QR code / link, which is an Maybe the next best thing we can do is have the in-app QR scanner work with the first QR code, eliminating the need for a second QR code. We can also provide an
|
I don't know that we would have to have 2 links in the presentation, since the only reason (at least when I was doing this) that I was sending users to the join page was to get an OpCode. I'm imagining, with the "autogen is generated in the app" paradigm, that people could install the app directly from the app store, then scan the code from the screen. This does circumnavigate the join page, but in the presentation setting people aren't reading it anyways, and we can include it and the link to the general openpath page as options to learn more. The summary and privacy policy show the important study specific information in the app. With your proposal above, it looks like we could still do it that way, and the code would do something no matter if you scanned it with your camera or with openPATH, which might be helpful. If we could boil the "group" onboarding process down to "download the app from the store, scan the code on the screen, follow the prompts in the app" I think that would resolve most of the confusion |
|
This is resurfacing as an issue with the Laos project, they are doing everything they can to get to 500 users and the onboarding process seems to be the next barrier they would like to address. Evidently, last night CO time, instead of scanning the QR code to individually access the join page, it sounds like they projected the join page and everyone scanned the same code ... they caught it and were able to get it fixed it seems, there are >80 new users now. However, it sounds like they think this also happened in March, maybe with people sharing a laptop? It wasn't exactly clear how it happened but it sounds like join page/opcode sharing is a barrier on the path to 500 users. We'll be meeting with them to discuss sometime next week. |
e-mission/e-mission-docs#1076 OPcodes are meant to be used by only one person. For autogen studies, generating them on the join page introduces the possibility that users will misinterpret the instructions and share OPcodes with others. Instead, we can provide a "join" link which takes users to the app and generates an OPcode there. The "join" link includes the same parameters that the join page can have: study_config, sub_group, and tester. If viewing the join page on a mobile device, we provide the join link as a button which directly links to the app (assuming it has been installed per instructions). Otherwise, we provide the link as a QR code. We also provide the link as text to easily copy and paste. Several of the functions related to token generation are no longer needed here and are being moved to e-mission-phone. a derivative of _getStudyName is still kept, called getStudyNameFromUrl, consistent with what e-mission-phone will have.
e-mission/e-mission-docs#1076 With the generation of OPcodes now occuring on the phone, several of the functions related to opcode generation will be moved from the join page to the phone. I put these in a separate file "opcode.ts" which will also pull in several of the functions from dynamicConfig that are related to validating and parsing opcodes While doing this, I adjusted the names of these functions to a unified convention, so let me describe where each one came from: generateRandomString: from join page's _getRandomString getStudyNameFromToken: from dynamicConfig's extractStudyName getSubgroupFromToken: from dynamicConfig's extractSubgroup getStudyNameFromUrl: from _getStudyName which was on both join page and dynamicConfig generate generateOpcodeFromUrl: from part of join page's validateAndGenerateToken (For reference, here is the current version of the join page that some of these functions are sourced from: https://github.com/e-mission/nrel-openpath-join-page/blob/main/frontend/index.html#L515) getTokenFromUrl and joinWithTokenOrUrl are new and help us handle 3 types of input: i) an actual token, ii) 'login_token' link that contains a token, and iii) 'join' link that gives parameters for a token to be generated on the phone
|
This is now on production; closing this issue. |
We last rethought the onboarding process in Spring 2023
Related issue: #850, particularly starting at #850 (comment)
Related PR (scroll down for discussion about links versus copy-paste): e-mission/e-mission-phone#973
We think that the changes have generally been positive, but we have still encountered some confusion with the new workflow.
Concretely:
It seems like with the previous changes, we got the pre-generated opcode case working smoothly, but autogenerated could be improved
nrelop_dfc-fermata_default_autogen. In the onboarding, replace the'autogen'string with an actually autogenerated opcode. On the server, reject any opcodes that have the'autogen'opcode.@jiji14 @louisg1337 @Abby-Wheelis thoughts on UX welcome!
The text was updated successfully, but these errors were encountered: