Material design for "insert image" editor action

Question

I'm developing an online document editor using Google's Material Design.

The editor has a toolbar with actions such as Bold, Italic and Insert Image.

When tapping on Insert Image the user shall be able to choose an image to insert. The image can be selected from one of several sources:

• Local: User can choose an image on the local file system, which is then automatically uploaded and attached to the document being edited.

• Attached: User can choose an image that is attached to the document. Either because the user uploaded it previously or because someone else uploaded it.

• Library: User can choose an image from the underlying repository to which the document belongs.

• Web: User can also choose an image from the web (using an integrated Google Image Search feature).

In addition; the user can, optionally, also specify settings for how the image shall be inserted. For example, specifying image position and size.

My first idea for this design was to popup a dialog when the user clicks on the Insert Image toolbar button.

That dialog would have one tab for each image source (see above). Each tab would have a search field for filtering images along with some source-specific search options.

However, I just learned that this design may be way to complex for a dialog. The design spec says:

Dialogs present a focused and limited set of actions, which are generally affirmative or dismissive.

One idea for simplifying things could be to have all sources in a single list (no tabs). However, I think it is important to clearly separate these source because the inserted image will behave differently depending on source. For example, web images are more or less just a reference while images from the library are managed (workflow, permissions etc) along with the document. This could be solved by visually presenting images from different sources in a distinct manner.

As an alternative to a dialog, I've been thinking that maybe I could present the Insert Image action in a navigation drawer (sidebar).

So, my questions are:

1. Is a dialog appropriate for something like this?

2. Is it a bad idea, in general, to have tabs in a dialog?

3. Would it be better to use a navigation drawer instead of a dialog for more complex actions such as this?*

Any pointers or ideas on how to go ahead with this design would be appreciated!

Answer 1

Before I proceed to answer your questions, let me point you to the part of the spec you quoted, which seemingly deems your dialog too complex:

Dialogs present a focused and limited set of actions, which are generally affirmative or dismissive.

This part of the spec is referring to the action buttons that populate the bottom of the dialog, and when speaking about a focused and limited set of actions, the guide is inferring that the buttons should be affirmative or dismissive in their actions, such as an Okay or Cancel set of actions.

Moving on, I'm going to try and address your queries to the best of my abilities:

Is a dialog appropriate for something like this?

Dialogs inform users about critical information, require users to make decisions, or encapsulate multiple tasks within a discrete process. Their sudden appearance forces users to stop their current task and refocus on the dialog content.

Given your use case, a dialog is a perfect solution, since it warrants immediate attention once the user taps on the Insert Image action, and since it encapsulated the entire image picking process into one clearly defined sheet of material

Is it a bad idea, in general, to have tabs in a dialog? Would it be better to use a navigation drawer instead of a dialog for more complex actions such as this?

You definitely wouldn't want to replace a dialog with a navigation drawer entirely, given that a navigation drawer is primarily for top level navigation. However, given your scenario, I'll point you in the direction of the Documents app on Android Lollipop, which uses an always open navigation drawer within the dialog on tablets and desktops, and a hidden drawer on mobile. This is a better option, since tabs occupy a significant amount of vertical space, and using them on platforms that have more horizontal space than vertical is a no-brainer. However, tabs would do well for mobile, but since consistency is one of the most important aspects of Material Design, a closed drawer is your best option

Answer 2

First thing I thought of is how would Google do it.. so I opened Quick Office and they don't use either a dialog or a navigation drawer. When you select the "+" on their toolbar you get a Menu with the option to add an image from your library or to take one with your camera (plus other options not image related).

To answer your questions:

1. I would say no. You quote the design guideline itself where it says actions are usually affirmative or dismissive - selecting an image doesn't fit as either of those.

2. This seems like a bad idea. Dialogs are meant to be quick selection - that seems like the opposite of something that has four tabs. Here's what Google says about tabs:

   Tabs make it easy to explore and switch between different views or functional aspects of an app or to browse categorized data sets.

3. Navigation drawer doesn't seem like a great option either. By using the navigation drawer you're implying that you navigate somewhere.. all the user wants to do is quickly add an image.

Last thoughts: Your four options are confusing to me. How are local and library different? Attached to what? If you're using only Google image search, is "Web" an accurate/clear of way of describing it?