Feature #7462: Always redirect Open Humans user back to OH - Tapestry - Arvados

Actions

Copy link

Feature #7462

closed

Always redirect Open Humans user back to OH

Added by Madeleine Ball over 8 years ago. Updated over 8 years ago.

Status:

Resolved

Priority:

Normal

Assigned To:

Category:

Target version:

Testing and Upgrading + PGP.ca features

Story points:

Description

Always redirect the user to 'openhumans.org/study/pgp/return/'.
If there's an origin parameter that's been received, include it as a parameter in the redirect.

This probably involves a small change to the logic here:
https://dev.arvados.org/projects/tapestry/repository/revisions/6961-simplify-open-humans-account-link-flow/entry/app/controllers/open_humans_controller.rb#L101

Rationale: User feedback suggests that users expect to "finish" processes like this on Open Humans, even when they start elsewhere. To accomplish this, we want users to always return to the Open Humans site after the PGP Tapestry backend has received their token and completed the data connection.

For users that are believed to have started the process on the PGP site (i.e. no "origin=open-humans" parameter), Open Humans offers a choice: "Return to Harvard PGP" or "Continue to Open Humans". Users with origin=open-humans are currently sent to their research data page (as Tapestry currently does). This behavior is implemented and currently present in the Open Humans staging site.

See also: https://github.com/PersonalGenomesOrg/open-humans/issues/224

Related issues

Actions

Copy link

Updated by Madeleine Ball over 8 years ago

Addendum for "rationale": see also the user flow document described here, 3a and 3b are both on Open Humans
https://personalgenomes.mybalsamiq.com/projects/update-pgp/prototype/Updating%20PGP%20Harvard%20connection?key=30090b9af29d405942c7403dec78fb37c4ff5b62

Actions

Copy link

Updated by Madeleine Ball over 8 years ago

We reviewed this in Harvard PGP staff meeting, albeit with very low attendance.

The argument against this redirect is that establishing this connection is akin to authorizing access to Facebook or Twitter. The OAuth2 process technically concludes with the user on the PGP site.

The argument for this redirect is that the PGP participant will perceive this as "joining a new activity" (akin to other 3rd party activities) and likely expects to continue interacting with the activity. Needing to return the user to the PGP's website to perform authenticated transfer of ID (instead of trusting the participant to faithfully report it) is an artifact of the OAuth2 process.

Initially staff had mixed opinions. After discussion, they seemed to concur that "ending on Open Humans" made sense, especially if users were provided the "stay-or-return" page as is currently implemented.

Certainly I have a strong personal bias here. I would like Open Humans to retain the attention of these users when they join the activity. But I do sincerely believe (especially after watching users go through these processes) that participants expect to explore a new activity/website, and are confused/discouraged from interacting with Open Humans when the process automatically lands them back on the PGP's website.

Actions

Copy link