Poor user experience when trying to flag an annotation when not logged in

[seanh]

Bug report form

Steps to reproduce

1. Log out (or don't login) to the client
2. Visit a publisher page that has the sidebar embedded and the moderation feature enabled
3. Click the flag button on one of the annotations

Expected behaviour

Some sort of user friendly error message that explains:

1. What went wrong - flagging the annotation failed
2. What the user can do about it - login

It might be nice if the actual error message could contain a clickable login link / button?

Actual behaviour

An unfriendly error message is shown:

Flagging annotation failed

404 Not Found. Either the resource you requested doesn't exist, or you are not currently authorized to see it.

After a few seconds the error message disappears by itself. If you click on the error message it disappears immediately.

Problems with this error message:

• Contains technical jargon:

  • 404 Not Found is an HTTP response type
  • By "resource" it's referring to HTTP resources
  • "not currently authorized it" (instead of not logged in)

  All three should be removed from the user error message.

• It says that either the resource doesn't exist or you're not authorized, but in fact we know the resource does exist and the problem is definitely that the user isn't authorized (and also, both "the resource doesn't exist" and "you're not authorized" are meaningless jargon to the user).

• It doesn't tell the user what they can do about it.

Your solution

Even though I think they're terrible, I'd suggest still using the floating-red-toaster-bubble-that-disappears approach to error messages (since that's not unique to this error message, it's the main way the client currently has for showing error messages, replacing that is a bigger job), and for now simply changing the error message. Maybe something like this:

Login to flag annotations

You must be logged in to flag annotations.

I said above that it'd be nice if the error message itself could contain a login button or link. Unfortunately I don't think these toaster bubble error messages can - clicking anywhere on the bubble causes the bubble to disappear.

Additional details

• I think it's important to realise that this is related to The client needs to handle OAuth-related errors in a user-friendly way #169 (the client needs to handle OAuth-related errors in a user-friendly way) - when the user gets logged out of the client because their OAuth token expires then flagging will start producing the error message above.

  The client needs to handle OAuth-related errors in a user-friendly way #169 runs into a similar problem - when the user has been logged out because the client was unable to refresh their OAuth access token (this will happen sometimes, unavoidably) we currently don't have a great way to display an error message to the user.

  So I think there is general issue here along the lines of the client lacks good ways of showing error messages.

  But importantly when the user has been logged out because the client was unable to refresh their OAuth access token (this will happen sometimes, unavoidably) they will still be logged in to the eLife website. So telling them that they need to "log in" doesn't really help - from the user's point of view they're already logged in. They need to reload the page. But one of the (many) things that will start going wrong when this happens if that flagging will show this "404 Not Found. Either the resource you requested doesn't exist, or you are not currently authorized to see it" which of course doesn't help the user (to know that they need to reload the page).

  Suggestion: When this OAuth logout has happened and the user needs to reload the page, I think we need to put the client into a "broken mode" where they can still read public annotations, but trying to do anything (annotate, highlight, reply, flag...) shows a "You need to reload the page" error message. But this is for The client needs to handle OAuth-related errors in a user-friendly way #169.

• This could be handled as a separate issue - if you click on the flag multiple times it creates multiple error messages:

  

  If it's possible to implement easily (I'm not sure whether it is) it'd be better to:

  1. Not create multiple of the same error at once
  2. On subsequent clicks flash the existing error for attention
  3. Each subsequent click should reset the lifetime of the existing bubble (so it doesn't disappear while the user is reading it)

• Not really part of this issue, but maybe worth noting for information, what happens when you click on the other button on annotations when you're not logged in is completely different:

  

  In a way this is actually better:

  • I think you could put a log in button / link in this error message
  • The error message doesn't disappear by itself
  • Multiple clicks doesn't duplicate the error message (although they don't do anything to draw attention to the existing message either - user may think clicking is just doing nothing)

  On the other hand:

  • It says you must be logged in to create annotations when the button the user clicked was reply
  • The error message is under a collapsible hide/show replies thing as if it is a reply

  Anyway, that's a separate issue. (And of course you can also try to create annotations or highlights when logged out, which produces another two different error message behaviors.)

[chdorner]

I'm guessing the client should either show a similar message to when a logged-out user tries to annotate, or we should just hide the flag button for logged-out users.

[robertknight]

I think this is just a flat-out bug. We shouldn't be showing the "flag" button for logged-out users because in our model flags are fundamentally associated with an (annotation, user) tuple aren't they?

[seanh]

IIRC the general approach throughout the client is not to hide buttons when you're logged out. Not saying that's a good idea necessarily, just that we should be consistent until we decide to change it everywhere. So yes, I think just display a more friendly error message.

But note the additional details discussion above - this error message when flagging can show for two reasons. 1. User is not logged in, and needs to login (to eLife, which will then automatically log them in to the client). 2. User is already logged in, but their OAuth token has expired, and they need to reload the page. So we need two different error messages (since the required user action is different).

[seanh]

I think this is just a flat-out bug. We shouldn't be showing the "flag" button for logged-out users because in our model flags are fundamentally associated with an (annotation, user) tuple aren't they?

I think this is a perfectly reasonable position to take, but by the same logic we shouldn't show reply, annotate or highlight buttons when you're logged out. So the counter-argument would be that the flag button should be consistent with the rest of our buttons?

[robertknight]

So the counter-argument would be that the flag button should be consistent with the rest of our buttons?

That's a fair point and I suppose it does make sense to clue the user into the fact that they can flag an offensive annotation, even if they don't have an account to do so.

[seanh]

I think there is a general lesson here that API error messages from the server should not be shown directly to users. I'm guessing this super technical error message comes directly from the API response. The client should always handle server errors by translating them into good user friendly error messages (or somehow avoiding running into the server error at all, or avoiding showing an error to the user at all, if possible, yes, but when you do have to show an error make it a good one)

[seanh]

So the counter-argument would be that the flag button should be consistent with the rest of our buttons?

That's a fair point and I suppose it does make sense to clue the user into the fact that they can flag an offensive annotation, even if they don't have an account to do so.

Yeah. I'm not sure I have an opinion either way, but I just think we should probably keep it consistent throughout. (Or maybe we shouldn't always? If there is good reason to deviate in one case.)

[robertknight]

Notes from backlog refinement:

• The backend stores flags associated with a user, so fundamentally doesn't support unauthenticated users flagging an annotation

Possible solutions:

• Don't show flag button to logged-out users: 2 points
• Show a nicer message when a logged-out user flags an annotation: ?

[robertknight]

Note from backlog refinement: There is a very simple and dumb option here (hide the button for logged out users), and an option that will provide better UX but will take a bit more work. @ajpeddakotla can we catch up about this when you're free?

[seanh]

I think there are actually four options here, @robertknight :

1. Don't show the flag button to logged out users. Not consistent with other buttons in the client (annotate, highlight, reply...) but would work. 2 points.

2. Do still show the flag button to logged out users (as we do with other buttons: annotate, highlight, reply...) and show the same red toaster bubble-type error message as we do currently, but just change the text of the message to something friendlier. "You must be logged in to flag annotations".

   

   We haven't pointed this one.

3. This would be my preferred option. Stick with the toaster bubble style error messages but use them well:

   1. As in option 2 above, make the error message text more user friendly. Something like "You must be logged in to flag annotations".

   2. Make the error message contain a clickable login or call to action link. I said above that the toaster bubble error messages cannot contain clickable call to action buttons or links but this isn't true, they actually can:

      

      And I think we can make the button say whatever we want, not just "yes" and we can make it do whatever we want (e.g. open the login form) on click.

   3. Don't fill the screen with the same error message several times if you keep clicking the button. I think this can actually be done using the toaster bubble error messages if you use the "Prevent Duplicates" option. See this demo: http://foxandxss.github.io/angular-toastr/

   We haven't pointed this one.

4. Move away from toaster bubbles entirely to a completely different and better way of showing error messages that achieves everything that option 3 above achieves but better. Needs design. Not pointed.

[seanh]

hypothesis/client#374

[seanh]

hypothesis/client#375

[ajpeddakotla]

Just a thought here ya'll - and apologies for wading into this a little late in the discussion.

The red toaster messages really aren't that great. We haven't moved towards a UX like this before and I don't think we should start now.

Can we simply hide the buttons when users aren't able to use them?

Right now, the reply button shows when a user can't reply. Can we hide buttons that aren't available for users to act on when they are logged out? How complex of an idea is this to implement? @robertknight @seanh

[seanh]

I think the short answer is that hiding flag and reply (and also page note) when you're not logged in would be easy to do (I say 2 points per button) but hiding buttons actually can't avoid all red toaster messages when you click on a button, it can just reduce the likelihood of them.

Details:

Was just chatting to @fatbusinessman about this in standup, and he made a good suggestion that I think we should follow: let's make the existing red toaster messages friendlier right now and then look into hiding all the buttons.

1. Let's merge Proposal: Allow to hide a specific user's post or arbitrary posts using thresholds #374 and Proposal: When the annotations tab is empty and the pagenotes tab is nonempty, focus the latter #375 first:

   • They're already done
   • They just take the already-existing red toaster message and make it into a friendlier text and prevent duplicates from showing. To be clear: red toaster message aren't new, they're the main way that the client shows errors currently and always has done, including for the flag button. Proposal: Allow to hide a specific user's post or arbitrary posts using thresholds #374 and Proposal: When the annotations tab is empty and the pagenotes tab is nonempty, focus the latter #375 just make the existing toaster errors friendlier.
   • Even if we hide the flag button when you're not logged in we can't completely avoid the situation when someone clicks the flag button and it fails. For example login, but sleep and wake your laptop so that its access token expires, click the flag button, you'll get an error. And this isn't the only way - there'll always be many ways for it to go wrong when you click a button. So it's good for that to be a friendlier error.
   • Hiding the buttons when you're logged out may take a bit longer and become controversial (see below) so lets fix bad error messages first and then look into hiding buttons.

2. After doing 1 and making the error messages friendlier, then lets try to reduce how often the error messages appear by hiding the buttons when you're not logged in. We could just hide the flag button but then it'd be inconsistent with the other buttons and also the same problem (of clicking a button and getting an error because you're not logged in) would still be present with the other buttons. So I think we have to hide them all.

   To answer @ajpeddakotla's question this is how complex I think hiding all the buttons when logged out would be:

   1. Hide the flag button: easy (we previously pointed this as 2)

   2. The reply button: also 2. In this case by hiding the button we wouldn't be avoiding a toaster error, we'd be avoiding an even worse broken behavior instead.

   3. Page Note (on the bucket bar): also 2. Again right now it's not actually an error message but just brokenness that you get, if you click the page note button while logged out.

   4. Annotate (in the popup when you select text in the doc). I don't think we would want to hide this because: Select some text, popup with annotation button does not appear, wtf why is Hypothesis broken? (Since the sidebar isn't open, you can't see that you're not logged in.) So I think we probably want some sort of "You must login to create an annotation" message, but something better than what we currently have. (But I think we can still hide the first 3 buttons without fixing this one yet.)

   5. Highlight (in the popup when you select text in the doc), same as annotate button.

   Did I miss any?

[seanh]

Update: hypothesis/client#374 and hypothesis/client#375 are merged so the error message is not as bad any more, but we can still also make it hide the flag button when you're not logged in so that the error message doesn't show at all? Scored as 2.

Talking to @fatbusinessman about this a minute ago I think there's a good argument for hiding the flag button only when not logged in, but not necessarily hiding other buttons (reply, page note, annotate, highlight), because those buttons are more core to what the product offers so we may want users who don't have accounts to see that those actions are there, whereas flagging is probably not core.

Also hiding just the flag button is less work and I think probably less controversial.

So I think we have 3 options now:

1. Close this issue now - go with the improved error message that we now have
2. Hide just the flag button when logged out
3. Hide all the buttons that you can't use when logged out

@ajpeddakotla ?

[ajpeddakotla]

Agree w/ your assessment @seanh and @fatbusinessman - Let's close the issue - we're fine with the error message we have now.

[nickstenning]

Ok, closing and marking as done in the Not-Really-A-Sprint.