search

akvo / akvo-product-design

Products Design Documents
GNU Affero General Public License v3.0
12 stars 9 forks source link

RSR v3 - Registration #52

Closed adriancollier closed 9 years ago

adriancollier commented 10 years ago

A redesign of the registration process from a user experience point of view.

Part 1 of the work being carried out in #51

danrowden commented 10 years ago

Registration wireframes from last week: https://www.dropbox.com/s/bm2zcxaivzcynzt/registration%20140819-1.pdf

adriancollier commented 10 years ago

Great work @danrowden

Some thoughts: I think we need to have a Terms and Conditions box on the main registration page. We don't have this fully in place right now, but it will probably end up being a link to a Wordpress page in Web. But in the meantime we can have it as a dead-link.

I think in this redesign process, we should also scope out the emails that we send and work on the content (or at least have available templates to coordinate with Comms if they want to write the content). @loicsans do you have any thoughts about standardised email templates (HTML/Plain text) that we should use within all products?

The My Details page will in the future, also contain elements such as profile image and maybe a personal description. Is this something we see can be put into the same UI as present, or will we be separating this out in the future?

I think it might make sense to have some static text on each page that provides information to the user explaining what needs to be done or what is possible to be done on each page.

danrowden commented 10 years ago

I think that if the personal details (image, description) are added, maybe the password could be moved to a "Change password" page. Otherwise there are three different forms/actions on one page.

mato74 commented 10 years ago

Great work indeed! I had a look too.

My input:

adriancollier commented 10 years ago

The idea is that one person should be able to connect with a single email address to multiple organisations. If they have a different email then they will actually have a different account - as email will form the basis of the account (no more usernames).

What we want to try and do is have a "short sign up" which has no organisation - so people can be an Akvo Member without being connected to an organisation. Once they have an account, it makes troubleshooting etc much easier.

These are wireframes, so the sizes of the fields will be adjusted when they are inserted into the final designs. They will of course need to be made large enough for long emails to be used.

mato74 commented 10 years ago

clear, thanks!

adriancollier commented 10 years ago

So, after some discussions it seems that there are several options for the implementation of this plan.

From my point of view I think it is important to roll out all of the major process and structure changes for this process at the same time rather than staging these in steps.

Our users may need to receive some additional training or support during the changing process, as well as the need for us to do outwards communication about this that is much easier with a larger solution that is less likely to change.

In terms of development I think we should continue to work on the above functionality with the expectation that it will be released as a single "chunk" of work - meaning we do not need to consider half completed or missing functionality within the roll-out plan.

The items we need to consider (and I will pick this up when I am back next week) are:

zzgvh commented 10 years ago

Quick brain dump: One part of rsr.akvo.org that has to stay is of course the admin. Another piece of functionality that's not in Pages yet is donations. I guess both of those parts could be "hidden" meaning that you access them via links/redirects on the Pages site you're on, but they have no public facing of their own. I don't remember exactly, but I think some part of the RSS feeds is also running only on rsr.akvo.org. The API is also rsr.akvo.org only. And a bunch of widgets.

I think that the messaging service is to be involved in this, right?

bjelkeman commented 10 years ago

As we are working on this, there is one high level requirement which isn't clear for me, based on the discussions about one user account and one email address.

Do we in RSR want to, over time, build up a record of the type of updates a person has done over time? The idea that the username is entirely based on mail address has several issues in my mind:

  1. Many people work for more than one organisation in this sector. Many people are consultants. It would really be very strange to force them to have to sign up for multiple accounts when they wear their different hats. That would be like having to create different Facebook accounts to have different Facebook pages that you are managing.
  2. Many people working in this sector will get their first RSR account when they work with an organisation. Which means that they will probably get one with the email address from that organisation. When they move to another organisation, then they have to sign up for a new account, loosing the historical record for this person. All the good work they have done using RSR is now disassociated with them. This is not a good way to build up a product that is supposed to build up online trust. The user looses the incentive to build a great online profile and we loose the history.

In other words, having the mail address being the user account (only) is counter productive relative to the bigger goals we have with the product. Specifically as you are planning to associate user with organisations in a way which allows a user to participate in multiple organisations anyway, then it doesn't make sense to slave the account to a particular email address. You should be able to leave an organisation, but keep using your user account in other contexts than that organisation.

  1. As the Akvo platform goes bigger, with integrated login services for FLOW, RSR, DASH etc. forcing one login account per email address you are using just doesn't seem to make sense.

I see several ways of dealing with this:

  1. Allow usernames (many systems you can log in with your username or your email address).
  2. Allow alternate email addresses for password recovery. (Many people leave an organisation and they loose their email and can then not use that user account anymore.)
  3. Allow changing of email addresses, but you probably always need one active address.
bjelkeman commented 10 years ago

When building new login services for Akvo RSR, we must consider whether this is the right time to integrate the Single Sign On system for the Akvo Platform. It doesn't seem to make a lot of sense rebuilding the whole login service and then not use SSO at this point.

adriancollier commented 10 years ago

Thanks @bjelkeman

On point 1 - we are also proposing that users are able to add multiple organisations per account, so a single person would not need to sign up for more than one account if they are connected to more than one organisation.

Additionally, while I do understand this is a potential user - I see very little actual evidence of these types of accounts within RSR. Doing a scan of the user base sorted by name, I found very few instances of users with multiple accounts for different organisations - most people who had multiple accounts actually were registered for the same organisation.

On point 2 - I have already proposed a process to allow a user to change their email address, as mentioned within the MyRSR specification https://github.com/akvo/akvo-product-design/issues/57 and https://github.com/akvo/akvo-product-design/blob/976bd24b4ee6c1db2cece144195afc1e9bc0e46f/RSR/Features/57-RSRv3_MyRSR/2-RSRv3_MyRSR.md#my-details

If we allow multiple email addresses then we also need to work in a whole set of notification preferences and routing to ensure that the right notifications get sent to the right email. This is likely to generate issues with duplicates where we send the same email to the same person multiple times if their orgs are both involved in the same project. We also reduce the ability for us to look at summary emails. In fact we would probably need to create multiple instances of all MyRSR pages in order to have the different "hat" views based on each of their roles.

A common issue we face within user support requests is the fact people forget their username/email combination. By combining these we reduce the overhead of our users to remember an additional piece of information that is not used outside of RSR (their username).

After analysis of user feedback and the support emails and tender, I noticed that around 80% of requests are related to registration/login. This is a huge issue for us, and the most important thing to tackle first in terms of good user experience.

A simplification of this process, should pave the way for an easier integration with SSO. We will have the pages and functionality fully defined and available for routing from a single source of permissions/authentication. This is covering a lot of the RSR requirements within https://github.com/akvo/akvo-product-design/issues/25 and provides the UI for users to interact with this.

When we go forwards with SSO - I believe a good opportunity here would be to allow users to register from any of the products separately, pushing those details to the SSO service creating a general "Akvo account" for the user, that can also be used to login to other products.

As all the products actually have their own portals and processes, it seems logical for users to register to the product they want to use. They could also of course register for a general Akvo account maybe directly from Akvo Web. (Why expose users to the complexity of many Akvo products if they are only utilising one of them?)

So, we would need registration, admin and permissions functionality in all products in place to then put an SSO service on top of this to synergise the effort should users want to expand beyond a single product.

adriancollier commented 9 years ago

New Registration process has been implemented within RSRv3. Need to do some follow up related to email notifications, communication and upfront user introduction.

All use cases covered in this specification have been fulfilled.