gbv/login-server

Cleanup user interface

Closed this issue · 5 comments

  • Get feedback from someone new to the service -> #77
  • Add a header with "Connected Identities" ("/account", the link via user name is not obvious) and "Sessions" (move the link from footer to header)
  • Add the user URI at "/account"
  • Add German translation -> #21
  • check whether account creation is understandable -> #48

To be honest, I sometimes get confused myself with the different subpages of login-server. These are my thoughts at the moment:

  • When accessing / and the user is not logged in, it should redirect to /login.
  • What's now under /account should actually be under / (or / redirects to /account if the user is logged in).
  • But the information (maybe in a more concise form) from / should be somewhere, maybe shown on /login?

When accessing / and the user is not logged in, it should redirect to /login
What's now under /account should actually be under / (or / redirects to /account if the user is logged in).

The text shown at / could be put under "/about" or "/help" (see #27) and / perform a redirect to /login or account. To better organize the subpages I recommend a header navigation with three pages:

  • about (the current /): general information about the service
  • account: name and connected identities or login. "logout" and "delete user account" can also be moved this page
  • sessions or "clients": active sessions. This would be more informative if we had information about the client a session originated in. We could add a static list of known client applications (BARTOC, coli-conc, coli-rich), at least.
  • /about is already an API endpoint for information about the server, so we should use /help instead. But in the navigation it can still be called "About", that definitely works better.
  • I would still show "Logout" in the top right of the page, but I'd be fine with removing the "Logged in as" text.
  • I'll take a look at the sessions page and try to improve it.

I added the header and restructured everything a bit (haven't looked at sessions yet though). Please take a look, @nichtich:

Screen.Recording.2021-01-12.at.11.22.32.mov
  • sessions or "clients": active sessions. This would be more informative if we had information about the client a session originated in. We could add a static list of known client applications (BARTOC, coli-conc, coli-rich), at least.

I'm not sure how to determine where a session originated. I guess we could save the referrer (i.e. when the user logs in from Cocoda). My suggestion: On the server, when either /login or /login/:provider are requested and a referrer other than the login server URL is given, and if the user is not currently logged in, save that referrer inside a field in the session.