remove sign in from AAQ process



5 years ago
5 years ago


(Reporter: atopal, Assigned: mythmon)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: u=contributor c=AAQ p=2 s=2013.8)


(2 attachments)



5 years ago
The page where we ask people to sign in or sign up should be simplified to just offer sign-up. details coming
Created attachment 738019 [details]
AAQ remove sign in

To clarify, we'll be removing the sign in form from the AAQ flow. Also any code in the view that handled that form.
This is AAQ, need to be extra careful. => 2pts
Whiteboard: u=contributor c=AAQ p= s=2013.8 → u=contributor c=AAQ p=2 s=2013.8

Comment 3

5 years ago
I'll do this next.
Assignee: nobody → mcooper

Comment 4

5 years ago
Created attachment 739888 [details]
questions.user.login, logout, and registrations

Although I have a pretty good grasp on how to do this, I'm a bit fuzzy on the "why". Is there a back story about this somewhere in an etherpad or something? It would be useful to have a link to that if it exists.

Also, should there be a way for a return user to login without leaving the flow at all? It sounds like after this change, if a user who has an account but is not logged in gets to the screen they will lose anything they have done, which sounds bad.

I tried to get some data from graphite about this (since I noticed a couple of graphite counters in the view). I'm not very confident in the data, because it looks a little strange to me, but it seems that a significant number of login attempts are happening. This statistics currently don't show if the attempt was successful or not, however. I've attached a graph from graphite that shows what I'm talking about.

I'm not saying we should *not* do this, only that I don't see any evidence that there is a good reason to do this. I assume that this evidence is in a conversation that led up this bug that I haven't seen yet.

Comment 5

5 years ago
After talking with Kadir about this, we've decided to

a) Not remove the login process, just hide it by default. This way users can still login without breaking the flow.

b) Instrument things better, so we can decide if all those logins from graphite are successful for not.

c) Check if our various sources of data agree (Graphite, Google Analytics, and Apache). This might be a new bug.

Comment 7

5 years ago
This is on master now.
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 8

5 years ago
Since there were more questions about this. Here is the rationale:

Almost all of our users are first time users. Even if they came back after several month, it's unlikely they'd even remember their login information. We don't care about people signing up twice, it doesn't hurt us or anyone. But the sign-in form is confusing, stats show a significant number of login attempts, even though almost all of our users are first time users. Making the sign-in form less prominent is therefore one way to reduce confusion and removes a hurdle to asking a question.
Rather late in the day to comment when we are about to go over to Persona.

However it my be useful to retain this as an alternative back channel as newbie posters may not even understand what Persona is. The procedures could probably do with reviewing and improving though. For more comments and back story relating to current procedures see a couple of sumo contributors threads

Comment 10

5 years ago
John, people don't need to understand Persona, it's just another way to sign in. Even better: in 1/3 of the cases (GMail users) they won't even need to use a different password.
You need to log in before you can comment on or make changes to this bug.