Button style and layout

[jancborchardt]

From the Material buttons page, this fits our case nicest:

• The primary button is filled and the secondary button only outlined (not grey) because it is less important.
• Both are right-aligned and the primary action is on the right, just like we do in the web interface for notifications for example.

(Copied over from discussion at https://github.com/nextcloud/android/pull/2778#issuecomment-406193365)

[tobiasKaminsky]

This indeed looks way better.

Do you want to have this on all dialogs? What about dialogs with three items?

[jancborchardt]

Yes, it’s probably good to have it on all dialogs! Especially because the screenshots you show illustrate how currently the primary action ("Yes" for the left one and "OK" for the right one) is not highlighted at all.

And any cancel action (like "No" for the left one" and "Cancel" for the right one) maybe is even better as a text-only link without outline, so only the primary one is highlighted. In the case of deletion, it would be that "Yes" is primary, "Local only" is secondary (outlined) and "No" is cancel (text-only). What do you think?

[AndyScherzinger]

Looking at the material guidelines text-only links are preferred for dialogs. While we could still have them colored differently for primary/secondary/action. What do you think? Having "primary buttons" on dialogs also seems very bold-styled to me and a bit heavy. Also checking the Google apps I am not aware of any app using buttons with boders or even filled ones but only borderless/text-only buttons.

[tobiasKaminsky]

https://material.io/design/components/buttons.html --> Text button

https://material.io/design/components/buttons.html --> Placement

As @AndyScherzinger said, text-only buttons should be used in materials design, and they are also not colored. But then we are already very close to the guidelines…? :thinking:

[AndyScherzinger]

But then we are already very close to the guidelines…? :thinking:

As for dialogs, yes we are material design compliant :)

As for the other buttons we are material design 1.0 compliant while all the screenshot now show the material design "2.0" updated guidelines and that needs some (minor) work.

[jancborchardt]

Yeah, in the guidelines they say text links. But it does seem strange to not directly have the primary action highlighted, don't you think? At least one primary should be a bit highlighted (whether it be by looking like a button or else).

[tobiasKaminsky]

At least one primary should be a bit highlighted

Though it is not really MaterialDesign, I like the idea.

[AndyScherzinger]

Though it is not really MaterialDesign, I like the idea.

Me too! :+1:

To sum things up

• move to the "new", material design 2.0 styling for "bold"-buttons
• keep text-buttons for dialogs but color-code the primary action / secondary action

Any idea how we can show secondary actions in text-links since grey might well be mistaken for disabled-state? Is black to heavy or would that work in your opinion?

[jancborchardt]

Any idea how we can show secondary actions in text-links since grey might well be mistaken for disabled-state? Is black to heavy or would that work in your opinion?

@AndyScherzinger the secondary actions are fine like they are, with the primary color as text color. :)

[AndyScherzinger]

@AndyScherzinger the secondary actions are fine like they are, with the primary color as text color. :)

Okay :smiley: :+1:

[jancborchardt]

(Basically just like in the first screenshot I posted, minus the grey border around the button. :)

[AndyScherzinger]

(Basically just like in the first screenshot I posted, minus the grey border around the button. :)

While we argued that actions in dialogs would be text-only buttons so the primary actions wouldn't have the filling which is displayed in your original screenshot :) Hence the question

[jancborchardt]

@AndyScherzinger ah ok, I thought by

move to the "new", material design 2.0 styling for "bold"-buttons

you meant the filled buttons – sorry I misread. Is there a documentation or screenshot for that? Is it simply just bolder text for the primary action? If that’s the standard then I’m fine with trying that out. :) Important is that the primary action looks sufficiently different from the others.

[tobiasKaminsky]

Maybe it is better to have some visual image snippets to show, @jancborchardt. I think this makes talking about it way easier.

These are from material.io: high emphasis: real button with primary background medium emphasis: real button with white background, primary text color low emphasis: text "button" with primary color

So if we use "low emphasis" all "text buttons" we can have the primary bottom with our primary color. But what about the other one? (keep in mind that there is also black/white (which then is grey for buttons) as primary color)

[AndyScherzinger]

This is exactly the point I am struggling with and not having come with a good solution. According to Material Design the dialogs should use "low emphasis" all "text buttons" buttons which then means the users can't visually distinguish primary/secondary/tertiary actions since the text buttons all look the same. We can distinguish primary/secondary/etc. with "normal buttons" like in the screenshots posted while that is not the type of button styling Material Design proposes for Dialogs. :/

I also think choosing different colors for primary/secondary text buttons should be fine while it is like @tobiasKaminsky said it's tricky to pick the secondary action color. Even then we will still have an accessibility issue since this might still be hard to discover for colorblind users :/

[jancborchardt]

I also think choosing different colors for primary/secondary text buttons should be fine while it is like @tobiasKaminsky said it's tricky to pick the secondary action color. Even then we will still have an accessibility issue since this might still be hard to discover for colorblind users :/

Yes, exactly. But even apart from that, this is not only about people who have difficulties distinguishing color. It is very difficult in general to distinguish by color alone, that’s why the form should also come in. (This is very important. ;) Especially on mobile, you don’t really want to spend time thinking about which action to pick. Highlighting the most likely path is crucial and takes cognitive load from people.)

That’s why I think a good start for us would be basically it’s like it is now, with only one step improved and that is that the primary action styled as a real button. All others are text only.:

When the primary color is grey, the button should also be grey. At a threshold of #555 grey in the web interface we do not go brighter with the button or other elements and keep that value. cc @juliushaertl This is how we should do it for Android too.

[tobiasKaminsky]

I am fine with this idea :+1: Let us see how it works out.

[AndyScherzinger]

Yeah, I am also fine with this approach. It might not be fully material design for dialogs but I agree with @jancborchardt argument that it is about cognitive load and that this is actually not solved properly in the material design guidelines. :+1:

[tobiasKaminsky]

@jancborchardt please check together with @ZetaTom (who will start again Monday) and create a list of all things that needs to be changed, then Tom shall estimate it.

[ZetaTom]

Overview

This is an overview of the changes that need to be made. These suggestions are based on the guidelines provided by the current Material Design and on the recommendations from @jancborchardt.

Dialogues

• dialogues should follow the new Material Design style and its guidelines
• forms - dialogues that require user input - should include a title
• dialogues sporting a supporting text longer than one sentence should include a title
• all dialogues need to be checked against these guidelines

Actions - Buttons

https://m3.material.io/components/dialogs/guidelines#befd7f4d-1029-4957-b1b5-da13fc0bbf3c

• dialogues should have a maximum of two actions
  • one confirming and one dismissive action
  • both actions should be end-aligned, with the dismissive action placed on the leading side of the confirming action
  • a single - confirming - action may be provided iff it's an acknowledgement
• primary buttons (confirming actions) in dialogues should use the filled tonal button style
  • this should tie in well with our web-interface

Specific Dialogues

• file deletion: transition away from specific dismissive actions (e.g. Keep) to generic actions, such as Cancel
• auto upload (SyncedFolderPreferencesDialogFragment): possibly extend to full-screen dialogue
  • dialogue provides many inputs in too little space
• Wait a moment dialogue: this dialogue should be phased out
  • this dialogue is presented as a blocking dialogue; users may not expect this behaviour, which leading to a frustrating and overall sluggish experience
  • other UI elements should be used to indicate progress
  • where possible, we should assume a positive outcome and update the UI accordingly
    • when a negative response is received or an unexpected event occurs, the UI should react as expected and provide sufficient feedback to the user
    • feedback may be provided as a snackbar or dialogue
  • if there is no other viable alternative, this dialogue should be used sparingly, with an appropriate description instead of the current Wait a moment

Notifications

https://developer.android.com/design/ui/mobile/guides/home-screen/notifications

• coherent appearance
  • action buttons should use sentence case
  • action button labels should be localised
• all notifications produced by the app should follow to these guidelines

Specific Notifications

• media player notifications
  • rename TOGGLE to the respective action (Play or Pause)
  • optionally the media template may be applied
• on-going download
  • title: Downloading file.pdf
  • supporting text: 96%
  • alternatively the progress template may be applied

Miscellaneous

• new folder dialogue: title should be changed to Create new folder, to reflect the current action
• Move to... dialogue: title should include the filename of the file to be moved; e.g. Move file.pdf
• Copy to... dialogue: title should include the filename of the file to be copied; e.g. Copy file.pdf
• rename dialogue: title should reflect the original file/folder name; e.g. Rename file.pdf
  • if this would result in obnoxiously long dialog titles, the following alternatives are to be considered: Rename file or Rename folder, respectively

Sharing Tab (FileDetailSharingFragment)

• this fragment should be migrated to the current Material Design
  • buttons
  • toggles
  • bottom sheet - to modify existing shares

[alperozturk96]

@ZetaTom @tobiasKaminsky @jancborchardt

After updating components we should also update these.

• Update "styles.xml" parent tags to use the "M3" instead of "MaterialComponents". e.g parent="@style/ThemeOverlay.MaterialComponents.BottomSheetDialog" to parent="@style/ThemeOverlay.Material3.BottomSheetDialog"

• Upgrade the "com.google.android.material:material" dependency.

• Set the API Level to 34 for the latest material design library compatibility.