Popovers vs modals vs docked tools

Question

When conceiving a CMS and a wysiwyg, I'm not sure of which options to choose to display editing tools. I'm more a dev than a designer, so I prefer avoiding as much as possible modals, because I'd like to make real-time changes, and it's more useful to see the changes, but there are cases where it's the best choice (an image manager/chooser).

When displaying the tools in popovers either below or above, it can be fine as long as the size of the content is not too big, and also having dropdowns in that popover feels really awkward.

Finally the last option is really tempting, really similarly to chrome/firefox devtools (quick ugly demo).

Do you think that solution is clear for users? That 'console' (looking for a better term) could trigger modals for images, etc.. . There would still be very light popovers for just buttons, or just a quick text input, eventually a 'dropdown text search input'. Google docs and https://www.froala.com/wysiwyg-editor are some inspirations.

examples scenario:

• 1. user mousedown/hover table, 2. a few buttons are displayed for quick table edits (rows+/-,merge), and buttons that would trigger the console, 3. user edit things in console and see the changes, eventually revert.
• 1. user mousedown a link, 2. small popover with browse to link, edit, delete, 3. edit menu triggering a new popover or the console...

I guess it's better to stay consistent, and try to have similar scenarios for elements

edit (in reply to comment):

• It's a general CMS that contains basic site pages, and the idea is to have a blog section on them too
• content will be text, images contained in 'components' that are reorganized with drag/drop
• Mobile support isn't important for the moment

Answer 1

It seems to me that what you are describing is a custom text editor or am I wrong?

If this is the case you should find plenty of examples (microsoft word, google docs, libre office, any e-mail program) where you can look at common patterns. Generally the controls to edit the text are at the top and users are very familiar with this pattern. Also, "toolbar" seems a better name than "console".

If you really need editing for a selected element, I would suggest it to either be an overlay or use the left or right side of the screen. Microsoft Visio does this when editing elements:

Whether to pick a slide in container or an overlay depends highly on the use case as you already mentioned above. If you need real-time edits where people need to experiment with the right setup, you should not use a modal. For things like changed/adding an image though this seems totally fine.

Answer 2

Difficult to answer something else than 'It depends' as your problem is not really well defined. We do not grasp the underlying needs from your description.

The interaction techniques you are comparing are not meant to solve the same issues. It's not a one-for-all situation.

Let's see what you are comparing

• Popovers: They provide contextual information or actions without taking too much space, but they are hidden at first. It's appropriate to use it for quick and with context editing. Having a complex popover may be out of tone from the conceptual model a user has (this is maybe why you said: dropdowns in that popover feels really awkward). You can make them more discoverable by adding signifiers (like a dashed underlined text)

• Modals: They disrupt user flows and you lose context. It is a good choice for when your users need a focus on something specific. You probably want to use it for something like editing an item that can lead to some consequences.

• Docked tools: All of your controls are in the page, they are in context and visible. depending on the frequency of each of the actions you may represent them as ico only or label only or ico and label. It can take up a lot of space and give a clogged aspect. The more controls are in the dock, the more difficult it is to find the right one. Be sure to stay below 12 options.

The process I would follow

Here is the process I would follow to design something adapted to the end users:

1. List all the possible actions
2. Understand the context they are used in
3. Design something that associate each one of them with the best fitting interaction
4. Test and iterate