Opened 9 years ago

#3636 new enhancement

Usability: Authorisation Required dialog and workflow needs reworking

Reported by: CycleStreets Owned by: potlatch-dev@…
Priority: major Milestone:
Component: potlatch2 Version:
Keywords: Cc:


The Authorisation Required dialog has a number of problems here. It's particularly important to improve this because it will put people off for life if, having spent half an hour on some changes, they give up at this stage.

Both Simon and I ended up doing the usual 'click Cancel' because we didn't read the dialog in detail, which is a definite indicator of usability issues. Dialog boxes in general should avoid the need for much text, because people simply don't read them, especially when lots of technical terminology is present.

Analysing in detail, the usability issues here are:

a) The text and title of the box refer to 'Authorisation Required' and 'Authorising this app'. I can see that this terminology stems from the OAuth nature of the login but it is confusing because normally it is the website that does the authorising, not the user. People will ask "What is the app" and "Why am I being asked now to approve something when I've just been using it for half an hour without any problems". Instead they will be expecting a standard Login system of some kind.

In general this talks about 'Authorising this app', which is highly technical language for what 99% of people would actually understand as 'Log in to OpenStreetMap to save changes'. I know personally that's not technically what's happening but it has the same effect and is more obvious what's going on. Perhaps some compromise wording can be found.

b) The action that everyone really has to do to make this succeed is to click on the URL. Yet in order to understand what that URL does, one has to read two sentences beforehand. As with a webpage, clicking on URLs is not great (except where the URL is so self-obvious); instead a clearly-labelled button should be used. (A URL with 'oauth/authorize' in it is definitely not in the self-explanatory category!) The button should have a clear action verb like 'Log in' though there is no problem with having small, greyed text underneath it like 'This will ask you to authorise this editor at'. That gives the best of both worlds: the techy info for the cautious people, and a clear action for the 99% of the rest of the world :)

c) Clicking on the URL results in a new window being opened. By default it looks like it doesn't give a message indicating that the next stage is to go back to the editor tab/window of the browser.

Can you set things so that the (now button) that is clicked on turns into an iframe or a div layer over the application - rather than a whole new window - perhaps with new window being the DHTML fall-back? Something which self-disappears would be sensible.

d) 'Remember authorisation' is ticked before the authorisation is done, which is confusing. Effectively that option is (I think?) only relevant after you have gone to the external URL and just before you click 'Try Access'. I think it basically shouldn't appear until after the URL stage is done.

e) The URL seems to remain visible after the authorisation is succeeed. I think that area of the screen (hopefully now a button) should be modal: Either a login button or a clear tick-style indicator showing that no more action is needed there.

f) 'Try access' is odd terminology for what most people would regard as meaning 'Save' or 'Proceed'.

g) In general I would consider prototyping a Wizard-style interface here, because the dialog is effectively asking for a two-stage process. I'm not 100% sure whether that would work because I don't really understand fully how the OAuth stuff works, e.g. whether auto-closing iframes and so on are possible. But I have this niggle about the way that the URL appearance and Try Access can both appear at the same time. It seems confusing.

Or one possibility is a box like this:

                                 [X =Cancel]
[Quick explanatory text here]

|   1. Login          |

|   2. Save changes   |


where 2 is grayed out until 1 is done.

I think that is probably the flow that most people will be understanding. Dealing with the new window issue though would definitely fix a big part of the confusion here even if the other changes aren't made, because state changes to the dialog will then be more obvious.

Change History (0)

Note: See TracTickets for help on using tickets.