Resolve "Sign in" vs "Sign up" confusion

[vyruss]

Annotating original issue w/ up to date UX Wireframes @JEK-III - http://h90c3m.axshare.com/#g=1&p=home

New language is: Sign in / Create account Related issue #305

Support staff has reported a number of users have been confused by the similarity between Sign in and Sign up and create unnecessary helpdesk calls.

• This will only get worse as the tool(s) see more usage.
• Propose new lingo for this, such as:
  • Log in and Sign up
  • Log in and Register

[stephaniesimms]

the UX team is working on this as we speak. we can review which MVP features we asked them to assess/redesign for us. they're documented in Pivotal — we'll be transferring those tickets over to GitHub Issues asap.

[briri]

From pivotal ticket: https://www.pivotaltracker.com/story/show/132209329

"During accessibility testing, it was noted that the registration to first login to profile view flow is complicated involves email validation and unnecessary field entry. Re-think flow of activities so that users can have a streamlined entry experience when registering and using Roadmap for the first time."

Here is link to wireframes (http://h90c3m.axshare.com/).

[vyruss]

As beta testing date draws closer, can I propose that for now we replace verb "Sign Up" with "Register" which is unambiguous and will help non-native English speakers who use the site in English?

References:

• http://uxmovement.com/buttons/why-sign-up-and-sign-in-button-labels-confuse-users/
• https://ux.stackexchange.com/a/1084

[stephaniesimms]

UX Wireframes recommend "Create Account" - http://h90c3m.axshare.com/#g=1&p=home This is not an immediate priority and will be addressed for the larger MVP

[stephaniesimms]

"Sign In / Create Account" language should also be used for the link in upper right corner on appropriate public pages (screenshot)

[briri]

It now says 'Create account' on the new sign in/create account workflow pages.

@vyruss I just submitted a PR that replaces them all for you on the development branch.

[stephaniesimms]

there is some potential for confusion when following the links to Sign In or Create Account in the upper right corner. If a new user selects Create Account, they won't be presented w/the option to sign in using institutional credentials. it might be necessary to drive them to the homepage instead where they can see both options.

alternatively, we can present the "Sign in with Your Institution" button for both Sign in and Create account paths so users are aware of the option regardless of the action they select. will confer w/ @JEK-III during Wed UX mtg.

@sjDCC For DMPonline users, does everyone have institutional credentials?

[sjDCC]

I think it could get very confusing if we add the shibboleth link to both poup boxes, especially how it's currently phrased, but will defer to @JEK-III on usability.

Currently they see this if they're going to sign in:

And this if they're creating an account:

I guess we want to avoid them creating a basic DMP account (i.e. not using institutional credentials) if we can avoid it. One option might be to add a secondary button / route to the create account popup so there are two options:

1. Create an account using my institutional credentials (effectively same as signing in with them for first time)
2. Standard create account webform to add email, org, password etc

Not all UK users have institutional credentials. Some unis use openathens or other local sign ons that I'm not sure are shibboleth compliant...

Will you still ask unis to submit LDAP details and once that's done their single sign on works. Do we need to add this step or is the current redirection to UK Access Federation sufficient on our end?

[briri]

@sjDCC we setup our filtered list of institutions as something you can turn on/off in the application's configuration. If its turned off it will let shibboleth send you through to the federation. If its turned on it will provide the filtered list of institutions. We set that up in the same way we did for users (anticipating orgs needing to have multiple ids for things like crossref, etc.) so we will have a new org_identifiers table. The super admin section will have a way to manage that table and those connections.

[sjDCC]

Given that this ticket is mainly about just changing terms, I think it can be closed out. The sign in workflows and SSO still need some work, but that's addressed in ticket #305 Referencing that here so notes from this ticket can be considered there.