Fix the order and arrangement of elements in the profile page

[mtthwhggns]

Currently, the profile page looks like this:

The current issues are:

• Avatar is just described as "avatar"
• input (API key) not associated with any label
• select (language) not associated with any label
• The explanation about the avatar comes much later in the reading and tab orders than the element itself (due to the columns).

Other possible considerations:

• Are the avatars used anywhere?
  • If not many places, do we need them?
  • If many places, can we justify forcing every student to get a WordPress.com account to set one?
• "you must update them on your identity provider." is quite jargon-heavy and could be replaced with something much clearer, maybe identity-provider-specific with a fallback.

Related: https://apluslms.github.io/accessibility-audit/patterns/fixable-a/semantic-markup-and-sequences/

[raphendyr]

Are the avatars used anywhere?

To my knowledge: no. I think there were a placeholder. It's possible some group stuff used those too.

LTI protocol includes a field user_image, which can include an url to a "profile picture". Though, that field is not provided by the A+ yet. I had an idea that for pseudonymised user info, we could generate these images our self and provide link for those. Nevertheless, using gravatar is kind of not so nice...

[markkuriekkinen]

I think the avatars are used in student groups. A student can see the avatars of his/her group members in the group selection. The student's "create a group" page also shows them.

[markkuriekkinen]

We should decide if we want to remove the old avatar feature completely. We don't like the dependency on gravatar.com and the avatars are not used much in the system.

The other issues in the profile page are straightforward to fix. The layout of the whole page can be changed so that the DOM elements are also defined in the right order.

[mtthwhggns]

I'd vote for remove the Gravatars and anywhere they appear.

Later, if we find it would be useful (maybe if we get more collaborative features), we can implement our own/explore getting one when the user authenticates (for example, logging in with Google could use the Google Account avatar).

Let's give everyone a day or so to add their comments here if they have any feelings, then maybe it's time for a final decision.

In the meantime, I'm part way through a mockup of an alternative layout for the profile page, which I'll share soon.

[mtthwhggns]

I'd suggest we stick with the dl, but tweaking the layout so that on desktop it stretches horizontally, and stacks up like it is now on mobile.

Separate sections show what comes from elsewhere and can't be changed (with a heading including the name of the identity provider), and which things are configurable/otherwise usable.

Mobile:

Desktop:

I've also tried to simplify some of the complex wording here, but none of this should be considered a serious suggestion yet - more work is definitely needed.

Things to check:

• Does it make sense to show the "username" here. It's slightly confusing as it looks like an e-mail address, but isn't a real e-mail address.

[markkuriekkinen]

@mtthwhggns that looks good. What will happen from the language change button? Is there a separate form or can the form be embedded into the same page?

I would keep the username there. Sometimes users use Google login when they should use Aalto login and there must be a way to see which account is being used.

[raphendyr]

Few things:

• It might be hard to say "these come from Aalto" as the name "Aalto" is not so clear. Texts used in login page might be usable here with some hacks. We currently include strings "Aalto" and "MOOC"
• In the future, there should be multiple of API tokens (one per service). Tokens should list only the title and you should be able to copy them only after creating (i.e. to be able to copy, you need to first create a new).
• There can be a lot of those automatic logins. Though, I don't remember if the javascript grouped them by the service or service + course.
• The automatic logins are stored in the client device and not on the server, if that matters. For example, two devices will have a different list of these.

The page should actually allow changing password for those users who have it. However, username and email should be locked as that could easily expose problems (existing user is searched using email too...). Only the password change would be usefull.

I guess I would sort information:

• user details, and the information about not editable here could be hidden behind a tooltip (click or hover)
• preferences (e.g. language)
• api tokens with ability to remove and create new tokens (as future plans from this issues point of view, e.g., comment in the code so we remember to do it correctly when it's done).
• per device data (i.e. cookies and local storage data). This should list everything we store on the users computer including cookies as well as we know (e.g. they exist for this url). Session cookie should have a button "logout" instead of "remove" (which of course requires that django wouldn't have a session cookie for not logged in users).

[mtthwhggns]

In answer to @Mankro 's question:

What will happen from the language change button? Is there a separate form or can the form be embedded into the same page?

My idea ws to render a form inline, replacing that row teporarily. No additional pages needed. I need to explore a little more how to acheive that accessibly, but it should be possible.

@raphendyr I won't answer all of your points, I agree with most of them. To be clear, this is an idea for a general layout, not a highly-specified final version.

My only concerns from your points are;

• Are you saying that we don't have a single object that represents an identity provider which is related to the user? That might be a challenge. I was imagining we could have strings like Information from [INSTITUTION NAME] for internal users and replace [INSTITUTION_NAME], for external users could have something like Information from [IDENTITY_PROVIDER]. If so, I guess we stick with Information from the identity provider
• The last three categories you've stated include one field each at the moment. This seems like a lot of headings containing one definition each. I'd suggest keeping the sections a little broader for now, and splitting them when we have more fields to add.
• You've listed a lot of nice-to-have features (cookies, change password, create API tokens) that don't exist yet. Can these be moved to other issues? I suggest we keep this one focused on how to we fix the broken layout, but let's build it in a way that's easy to add fields to.

[markkuriekkinen]

About the identity provider: at the moment, the username is the best way to guess the identity provider since Aalto users have the @aalto.fi ending. That information comes from the Aalto identity provider server. When you use Google login, the username is not guaranteed to have the gmail.com ending. I'm not sure how it works but the database certainly has users that have usernames ending with arbitrary domains. I don't know how Google login enables that.

About the scope of the issue: indeed, the manual password change and multiple API tokens can be left for another issue.

[raphendyr]

Are you saying that we don't have a single object that represents an identity provider which is related to the user? That might be a challenge. I was imagining we could have strings like Information from [INSTITUTION NAME] for internal users and replace [INSTITUTION_NAME], for external users could have something like Information from [IDENTITY_PROVIDER]. If so, I guess we stick with Information from the identity provider

Exactly, there isn't clear information from user model point of view and there is no exact string in db or settings.

The last three categories you've stated include one field each at the moment. This seems like a lot of headings containing one definition each. I'd suggest keeping the sections a little broader for now, and splitting them when we have more fields to add.

Sounds good. I kind of hope there is just idea how a new section is added. E.g. current layout assumes there won't be new sections as the layout is not very extendable.

You've listed a lot of nice-to-have features (cookies, change password, create API tokens) that don't exist yet. Can these be moved to other issues? I suggest we keep this one focused on how to we fix the broken layout, but let's build it in a way that's easy to add fields to.

Sure, this issue shouldn't consider them more as a note about what is possibly happening in the future. Like, I wouldn't like to do full redesign again. It would be nice if the additions would fit the design done here.

[raphendyr]

I don't know how Google login enables that.

I think they pass the primary email of the google account (which doesn't need to be @gmail.com).

[mtthwhggns]

I've done some more design work on this and written a little code, but I propose that it goes on hold until the the SASS stuff is done (at least https://github.com/apluslms/a-plus/pull/606), as doing this without SASS, then migrating it to SASS later is easily double the work of just using SASS from the start.

[markkuriekkinen]

SASS groundwork has been completed, hence I removed the "status: blocked by" label.