search

apluslms / a-plus

A+ frontend portal - A+ LMS documentation:
https://apluslms.github.io/
Other
68 stars 73 forks source link

Standardise button colours #601

Open mtthwhggns opened 4 years ago

mtthwhggns commented 4 years ago

Separating this out of #598

Consistency

As highlighted in #585 , we have some inconsistent use of button colours.

We have some cases where we use colours which have a functional or semantic meaning because we want different colours. >One example might be the "danger red" 'Login using Google' button.

Since we shouldn't rely on colour to make differences between things clear, (WCAG 1.4.1) One idea would be that we have a single style of button, and replace all buttons with this style. Perhaps we have a second style for "destructive" actions (delete).

I'll give some thought to the right way to approach this and add a new comment to this issue soon.

It seems to make sense to deal with the two issues in isolation.

I had a discussion with @etanttila and @saarasat about this. I'll write up the results soon.

mtthwhggns commented 4 years ago

Proposed Guidelines

For now, this doesn't consider the "multistate buttons" from js-jquery-toggle or the colour-coded "color labels" - they need evaluating separately.

While I say "in every view", these might not always be whole web pages. It will likely make sense in each modal, and each embedded exercise to be considered a different view.

Implementation

To start with, we could use the existing Bootstrap classes we have now. In this case, I'd suggest mapping "Default button" to btn-primary, "Secondary" to btn-default and "Destructive" to btn-danger.

plus cs aalto fi_accounts_accounts_ (1)

In the future, we should consider the colours, maybe maybe the default button in a more distinctive colour (compared with, for example, the top navigation bar). We also don't need to stick with Bootstrap here. We could consider making them ourselves if we want to tweak the styles a little.

Changing these would be a small task, as we can list all uses of btn-* classes in each project, set them all to the "Secondary" style, then pick the "default" action per view.

Example

Here's a page with lots of buttons. I did a quick find & replace on the classes as described above. I also added a "seriously destructive" button to see how that could stand out.

Before:

localhost_8000_def_current_teachers_

After:

localhost_8000_def_current_teachers_ (1)

To me, this interface is less busy and less distracting. It's feels a little "monochrome", but that potentially makes it easier to focus on.

saarasat commented 4 years ago

Personally I like this idea of simplifying and clarying the UI for the users. I think the idea of using three semantically-reasoned buttons works well. Also that probably would help the possible event of migrating to Bootstrap4.

The only concerns or rather questions I have, is for situations for instance where there might be many equal primary actions present in the page? Eg. 3 different exercises and no general "save"-button. Would the correct way here is to have three primary "submit"-buttons?

markkuriekkinen commented 4 years ago

I mostly like Matthew's proposal, but I am a little concerned about removing the possibility to use colour for very different kinds of buttons in the same page. Matthew's screenshot is great since the edit course page has some green buttons for different actions (add new learning object, renumerate contents) and removing the colour makes it harder to see those buttons. Of course, it is different when we add a colour to all secondary buttons since now they are white.

mtthwhggns commented 4 years ago

@saarasat do you mean three separate exercises with one submit button each?

If they're in clearly separate blocks, ideally with a border, then I think each can have one primary button. That's what I was trying to describe when I wrote;

While I say "in every view", these might not always be whole web pages. It will likely make sense in each modal, and each embedded exercise to be considered a different view.

Does this clarify it? Or is there a case I've not thought of?

saarasat commented 4 years ago

Does this clarify it? Or is there a case I've not thought of?

This clarifies it :)

raphendyr commented 4 years ago

I personally see the "white" button as "unimportant, no need to click". However, the bootstrap 4 version is a bit better as it's gray and not white.

Any case, I think those three colors are pretty good. However, I would like to be able to differentiate "this action might not be what you want, but it's recoverable" from "this action is permanent and can not be recovered from". Former would be btn-warning and latter btn-danger.

The warning should be used rarely. Or alternatively, the button to "remove" could be a warning and when you click it you will be shown a confirmation page/dialog/new button which would use btn-danger to indicate that the action can't be reverted after that point (but it was before pressing the yellow).

For example, when removing an exercise, we should show a red button as that operation is destructive. In contrary, when removing a student from a course, we could show yellow as that operation can be reverted (when it's implemented as planned).

(btw. in the later image, remove exercise buttons should be btn-danger by the definition, which would make the view look cluttered)

I tried to think a bit, but I didn't come up uses for btn-success or btn-info. So at least those can be easily removed.

Nevertheless, colors for btn-success and btn-danger should be selected so that they look someway different even with the most common color blindness. In addition, primary vs. warning should be checked too, as they fit the second most common variation of the color blindness. Most importantly, every button should always have a glyph icon!

On a related note, I personally feel the links in the action list are missing button space reservation, i.e., they don't seem to fit there. Basically, just adding very unimportant border might be enough. However, they should still look and behave like links.

I think that page should look something like this:

image

Note differences in:

I personally don't like btn-default with white background. Though, version with light gray requires other changes to that page too..

image

p.s. (I was checking Jutut for reference, but I think that service needs a similar revisit on button colors.

raphendyr commented 4 years ago

On a side note, that page should be removed, or more exactly moved to some other service. Courses should use automatic deployment, thus being able to edit this information from A+ is problematic as the changes will be overwritten on next update. Thus, we probably should think more relecant views as an examples. Hoever, it wouldn't hurt to fix that page before it's removed as it might still take quite much time for it to be removed.

raphendyr commented 4 years ago

For dange buttons, we could use button with red border and white background (same as with default). When hovered, the background would change to red. See comment editing buttons here in github (with newer, June 2020, theme).

mtthwhggns commented 4 years ago

I just want to clarify two of @raphendyr 's points, then I'll leave the others until we've had a little more feedback.

localhost_8000_def_current_teachers_exercise_3_delete_

Now, this, does warrant "serious, destructive consequences" style, in my opinion.

mtthwhggns commented 4 years ago

We have new guidelines written up and ready to use.

I suggest waiting until after #594 (and #606) to try implementing this to test, as it will then be trivially simple to tweak the colours without needing to find/replace the styles.

mtthwhggns commented 4 years ago

Now that the new styles are implemented and available, it's time to migrate to them.

Here's a list of files in the a-plus project that include the substring btn at least once (excluding CSS).

They need checking and swapping. While I'll start on soon.

Anyone else who needs to heavily touch one of these files if welcome to do this too.

mtthwhggns commented 4 years ago

I've been through the simple ones and will make a pull request very soon.

The following haven't been swapped yet because they're customised or impractically hard to test:

markkuriekkinen commented 3 years ago

Assuming that the list above in Matthew's latest comment is up-to-date, then most of the work was done in the PR #661, but there is still something left to do. It would be nice to finish this and close this issue properly.