2

The Material Design guidelines for fullscreen dialogs state, that the action (like SAVE in the screenshot) should be shown on the top right. Cancel always is shown as an X on the top left.

EDIT

Now I have a case, where a user enters data into a fullscreen dialog - here SAVE on top is okay.

Afterwards a different user can ACCEPT or DECLINE the data. For this, I am showing the same dialog, just with read only data, but at top right is no place for both actions. So I'm thinking of showing them on the bottom, although this does not follow the guidelines.

Any other ideas or suggestions?

Improve this question
4
  • Can you clarify which instance are we looking at: is this design for an author's view (creating or editing an event) OR is this design for a recipient's view (reading the event and needs to RSVP)?
    – jhurley
    Commented Mar 7, 2018 at 14:29
  • 2
    It sounds like either the dialog isn't the correct interface solution or Accept and Decline aren't the correct words. Dialogs are usually used for subtasks. In the example the user is just entering a date, not making a decision. What are the users Accepting or Declining?
    – moot
    Commented Mar 7, 2018 at 14:34
  • @jhurley You are right, that are two different things. I edited the question.
    – Ridcully
    Commented Mar 9, 2018 at 8:52
  • Please don't edit your original question and examples. You can add to your question and examples but don't remove or change your original question. We're commenting and answering questions and examples that aren't here now.
    – moot
    Commented Mar 10, 2018 at 5:15

2 Answers 2

Reset to default
1

In my point of view, you can put buttons at the bottom. it will be better. I know, this does not match with Google's recommendations, but they also can not cover all possible cases.

Few examples

Improve this answer
3
  • 2
    You've not said why it would be better. If you're suggesting a certain approach then I'm sure you have your reasoning for suggesting it.
    – JonW ♦
    Commented Mar 7, 2018 at 14:58
  • I accepted this answer for its example from the Google IO app.
    – Ridcully
    Commented Mar 9, 2018 at 8:53
  • Answer «Why?» is possible to get after a lot of A/B Tests. But I can next points: ● It's easy to reach bottom part of the screen. Last year, Google added Bottom navigation, because they realized it. ● I don't fully understand your UX case, but «Agree» and «Disagree» buttons != «Ok» and «Cancel» from Material Design pages, what you show. Ok/Cancel it's primary & secondary action buttons. But Agree/Disagree have a same priority. Like Dialogs. So, in Dialogs we always put buttons at the bottom according to all guidelines, what I know.
    – Max Tsvetkov
    Commented Mar 12, 2018 at 11:27
0

I don't know your specifics, but it seems like full-screen dialogs, as Google defines them, aren't right for your use-case. Here's a run-down of when to use them:

Full-screen dialogs may be used for content or tasks that meet any of these criteria:

  • The dialog includes components (like pickers or form fields) that require an input method editor (IME), such as a keyboard
  • When changes are not saved in real time
  • When there is no draft capability in the app
  • When performing batch operations or queuing changes prior to submitting them

Now, you haven't described your specific use-case yet. I can think of two options:

A) You have a read-only dialog with text that one can either accept or decline. In that case, don't use a full-screen dialog, but either a standard dialog (potentially with scrolling, if need be) or a separate screen.

B) You have a dialog with input and a portion that needs to be confirmed—e.g. "Terms of Service". In that case, use a checkbox within the full-screen dialog for confirmation.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.