The How reasonable is icon on Cancel/No button? topic drifted to the area of toolboxes, so I created a new thread here.

Original question (we discussed toolbox as a special case for toolbar where buttons are places):

Heiko Tietze wrote:

jstaniek wrote:* Similarly, how about explaining toolbox buttons and their icons somewhere? Krita has these buttons without text by default.

Do you have the mentioned toggle button in mind?

Yes, it's not obvious to me that (if) https://techbase.kde.org/Projects/Usabi ... le_Buttons refers to tool boxes. How about giving example from Krita at https://techbase.kde.org/Projects/Usabi ... ns#Example ? And explicitly mentioning toolbox as an example (or typical) use in the Purpose section?
And these points are not quite in line with how we see tool boxes:
* "Prefer radio buttons or check boxes outside the toolbar. " - buttons in toolboxes are positioned (statically, do not rearrange themselves, for a good reason) in a grid if there are just too many buttons (see Krita http://wstaw.org/m/2014/11/10/plasma-desktopsH3979.png) - buttons are not put in a traditional toolbar which is a line of buttons.
* "Align groups of toggle buttons horizontally rather than vertically. " - toolboxes are so often vertical
* Calligra Flow's and Qt Designer's toolboxes are implemented using Qt's QToolBox-like widget with icons and texts. That's still perhaps a kind of toolbar optimized for large sets of actions (here: tools, dynamic): http://wstaw.org/m/2014/11/10/plasma-desktoplq3979.png

Now, the "Do not use a toggle button to initiate an action." is interesting. Toolboxes switch the global mode (so called tool in calligra, from paint using brush, to draw lines for example). That's fine. But in the already mentioned Calligra Flow and Qt Designer apps, the action of inserting is initiated because it's expected that user drags any element of the toolbox onto the document's surface. (I don't say it's good or bad, could you please tell more about this?; in Kexi we do not have this behavior). You can try it in Qt Designer easily. Does it mean that toolbox deserve separate page of the HIG? Or special mention?

Also, "Implementation" section could mention a solution for the toolbox, I guess it could be just a grid layout, as I don't know anything higher level used in many apps.

Is there a difference between toolbars and toolboxes? At least not from a user POV except of the default position.

Examples are always a good idea. So yes, add it to the page. Perhaps with another screenshot of a standard toolbar to make sure that we talk about toolbars and -boxes.

"Prefer radio buttons or check boxes outside the toolbar." Those controls have a label and easier to understand. Applications are less complex when toolbars/-boxes don't include too many buttons. Just try to have a simple command structure.
"Align groups of toggle buttons horizontally rather than vertically." It would be very uncommon if you place the toggle buttons for text alignment left vs. right not side by side. But the text don't forbids to do it vertically which might be necessary sometimes.

"Do not use a toggle button to initiate an action." Yesterday I talked about this issue with people from the Libreoffice team. The idea is to have add/delete columns in the toolbar. And I think it feels strange to initiate actions and especially destructive actions there. It's different when you have the functions in a floating toolbox that is not the standard toolbar. We could either introduce a separate page for toolboxes or we add a disclaimer to all points that don't fit in case of "secondary toolbars" (did I get it right now?). Or we keep it as it is, and trust in common sense .

Hello,

Is there a difference between toolbars and toolboxes? At least not from a user POV except of the default position.

There is one. Toolboxes usually contain a set of tools the user can use to modify a document (select, paint, ...) that are mutually exclusive. One cannot use both the "Select rectangle" and "Brush" tools at the same time.
Toolbars, on the other hand, contain actions that are not specific to one tool : open, save, cancel ; set background & foreground colors, set font, ...

Louis

louis94 wrote:Toolboxes usually contain a set of tools the user can use to modify a document (select, paint, ...) that are mutually exclusive. One cannot use both the "Select rectangle" and "Brush" tools at the same time.

I'm not sure whether "toolbox" in this context actually refers a QToolBox (ie. basically some kind of vertical tab widget) - neither Calligra nor Qt Designer uses the latter (from what I can say)

luebking wrote:

louis94 wrote:Toolboxes usually contain a set of tools the user can use to modify a document (select, paint, ...) that are mutually exclusive. One cannot use both the "Select rectangle" and "Brush" tools at the same time.

I'm not sure whether "toolbox" in this context actually refers a QToolBox (ie. basically some kind of vertical tab widget) - neither Calligra nor Qt Designer uses the latter (from what I can say)

The QToolBox is a very very bad name choice. Toolboxes traditionally are what both jstaniek and louis94 describe as such:



Those things that look a bit like vertical toolbar, but are indeed different from an interaction perspective, for the exact reason louis94 mentions: A toolbar is used mostly to initiate actions (or toggle modes with toggle buttons), whereas a toolbox is normally used to switch to a certain tool. Therefore, the whole toolbox is basically just one big toggle button.

So jstaniek is right: A toolbox does violate the "no vertical toggle buttons" guideline if we do see it as one big toggle button. I'd still agree with Heiko that those things that clearly belong together should be next to each other, if possible.

jstaniek wrote:Now, the "Do not use a toggle button to initiate an action." is interesting. Toolboxes switch the global mode (so called tool in calligra, from paint using brush, to draw lines for example). That's fine. But in the already mentioned Calligra Flow and Qt Designer apps, the action of inserting is initiated because it's expected that user drags any element of the toolbox onto the document's surface. (I don't say it's good or bad, could you please tell more about this?; in Kexi we do not have this behavior). You can try it in Qt Designer easily. Does it mean that toolbox deserve separate page of the HIG? Or special mention?

These are not toolboxes, because the user doesn't choose a tool there. They are more like "object explorers", as they just host a set of objects to be placed in a document. They are more like the "Add Shape" docker every Calligra application offers.

Okay, all this does sound to me like we should indeed write an HIG for toolboxes where we define what a toolbox is and how it should be done. Any takers?

Let me have a try. Forgive my English if I made mistakes.
I took the toolbar HIG and modified it. I had a look at both Inkscape, Krita and The Gimp. Okular's toolbox (F6) may also be worth looking at.

Louis

Purpose

A tool box is a graphical presentation of tools optimized for fast access. Tools are the different ways an user can manipulate a document. Only one tool can be enabled at any given time.

Examples

Guidelines

Is this the right control

• Provide a toolbox every time there are different ways of manipulating a document.
  
• Provide a toolbox in addition to the menu bar, but do not replace the menu bar.

Behavior

• A tool bar should contain all available tools. If the number of operations is above 5 they have to be grouped with separators.
  
• Don't execute any operation immediately; do not require additional input from user.
  
• Provide a keyboard shortcut to allow fast switch between tools.
  
• Do not use menu buttons in tool boxes. They do not fit well the concept of fast access.
  
• Do not hide tool boxes by default. If configurable, users should easily be able to make the tool bar viewable again.
  
• Disable buttons that do not apply to the current context.
  
• Consider to provide customization for tool bars in respect to position and content.

Appearance

• Use icon-only flat toggle buttons.
  
• Use a tooltip. As the user has no mean of knowing what it is, describe it to the tooltip.
  
• Toolboxes should be placed on the left side of the document by default.
  
• Toolboxes should look good in both vertical and horizontal mode.
  
• Use and design toolbox icons with special care. Users remember location of an object but rely as well on icon properties.
  
• A distinct association between the underlying function and its visual depiction is crucial. Follow the advice for icon design.
  
• Do not simulate Microsoft's ribbon controls. KDE stays plain and simple.

Implementation

• If there are less than 11 tools, use a QToolBar.
  
• If there are more than 10 tools, use a QToolBox with a QBoxLayout with a direction depending on the orientation. For each group, use a flow layout (FIXME: there is none in Qt) with a direction perpendicular to that of the container.
  
• Use QKeySequence::toString() to add the keyboard shortcut to the tooltip, don't hard-code it.

louis94 wrote:Let me have a try. Forgive my English if I made mistakes.
I took the toolbar HIG and modified it. I had a look at both Inkscape, Krita and The Gimp. Okular's toolbox (F6) may also be worth looking at.

Thank you for doing this, excellent work! Just two comments:

Is this the right control

• Provide a toolbox every time there are different ways of manipulating a document.
  
• Provide a toolbox in addition to the menu bar, but do not replace the menu bar.

I'm not sure if "every time there are different ways of manipulating a document." is a clear enough criterion. Kate offers "different ways to manipulate a document" as well, yet I don't see how it could benefit from a toolbox.
Maybe we should say "Provide a toolbox if there are different modes for manipulating documents directly using the cursor (such as e.g. in most graphics applications)", because that's what makes the difference for me.

Behavior

• A tool bar should contain all available tools. If the number of operations is above 5 they have to be grouped with separators.
  

tool bar -> toolbox

• If there are less than 11 tools, use a QToolBar.
  
• If there are more than 10 tools, use a QToolBox with a QBoxLayout with a direction depending on the orientation. For each group, use a flow layout (FIXME: there is none in Qt) with a direction perpendicular to that of the container.
  
• Use QKeySequence::toString() to add the keyboard shortcut to the tooltip, don't hard-code it.

That's for developers to check, not my area

Otherwise it looks great to me!

Is this the right control

• Provide a toolbox every time there are different ways of manipulating a document.
  
• Provide a toolbox in addition to the menu bar, but do not replace the menu bar.
  

I'm not sure if "every time there are different ways of manipulating a document." is a clear enough criterion. Kate offers "different ways to manipulate a document" as well, yet I don't see how it could benefit from a toolbox.
Maybe we should say "Provide a toolbox if there are different modes for manipulating documents directly using the cursor (such as e.g. in most graphics applications)", because that's what makes the difference for me.

Agreed.

• If there are less than 11 tools, use a QToolBar.
  
• If there are more than 10 tools, use a QToolBox with a QBoxLayout with a direction depending on the orientation. For each group, use a flow layout (FIXME: there is none in Qt) with a direction perpendicular to that of the container.
  
• Use QKeySequence::toString() to add the keyboard shortcut to the tooltip, don't hard-code it.
  

That's for developers to check, not my area
[/quote]

Well, QToolBar will look like regular toolbars, and QToolBox like Krita's toolbox. Maybe this should be rephrased and moved to Appearance. The 10 items limit is to be discussed.

The second item is also related to appearance : it tells how the buttons should be laid out. The principle is to have them behave like words in a text. In this layout, categories are like paragraphs, and individual tools like words. So a narrow toolbox would look this way :

Code: Select all

A B
C D
E
---
A B
C D
---
A B


whereas a wide one would look like this :

Code: Select all

A C E | A C | A
B D   | B D | B


Questions to devs having a deeper Qt knowledge than mine :

• What's the best way to implement a layout like QML's Flow element that arranges widgets like words in a paragraph ?
  
• How to react to shortcut changes ? Listen to QAction::changed() ?

Louis

louis94 wrote:

• Provide a toolbox every time there are different ways of manipulating a document.
  
• Provide a toolbox in addition to the menu bar, but do not replace the menu bar.

I'm unsure if toolbox plus menubar fits our command structure. What if tools are available but the rest of the app is very simple?

louis94 wrote:

• Don't execute any operation immediately; do not require additional input from user.
  
• Provide a keyboard shortcut to allow fast switch between tools.
  
• Do not hide tool boxes by default. If configurable, users should easily be able to make the tool bar viewable again.

I'd say operations have to start always without any further user interaction, as stated in the second part. So it is immediately (opposite of first part).
The keyboard shortcut provides access to other toolboxes, not every toolbox item, right? Is it always required?
Usually the toolbox is hidden unless the user wants to start this kind of operation like drawing shapes in a word processor, IMHO.

louis94 wrote:

• Toolboxes should be placed on the left side of the document by default.

Although I don't disagree this guideline sounds a little bit too restrictive. Opinions?

louis94 wrote:

Code: Select all

A C E | A C | A
B D   | B D | B


Can we align the content side by side in both vertical and horizontal layouts? I still read from left to right... And by the way: Does it make sense to flip the content for RTL languages?

Code: Select all

A B C | A B | A |
D E   | C D | B |


We should mention as well accessibility for toolboxes. I don't know how well this concept works for impaired people because it's not possible to tab through the items.

Nevertheless, great work, louis94!

Heiko Tietze wrote:

louis94 wrote:

• Provide a toolbox every time there are different ways of manipulating a document.
  
• Provide a toolbox in addition to the menu bar, but do not replace the menu bar.

I'm unsure if toolbox plus menubar fits our command structure. What if tools are available but the rest of the app is very simple?

Same as for toolbars : the toolbox should not replace the menubar if there would be one otherwise. If we change this, we need to change the toolbar HIG too (the second bullet was copied from there).

Heiko Tietze wrote:

louis94 wrote:

• Don't execute any operation immediately; do not require additional input from user.
  
• Provide a keyboard shortcut to allow fast switch between tools.
  
• Do not hide tool boxes by default. If configurable, users should easily be able to make the tool bar viewable again.

I'd say operations have to start always without any further user interaction, as stated in the second part. So it is immediately (opposite of first part).
The keyboard shortcut provides access to other toolboxes, not every toolbox item, right? Is it always required?
Usually the toolbox is hidden unless the user wants to start this kind of operation like drawing shapes in a word processor, IMHO.

There needs to be some change to the interface : available options change, mouse cursor changes, etc. I don't consider these changes as operations, as they don't modify the document. Tools are ways of doing operations. Think of the "Select rectangle" tool : the current selection should not be changed when the user chooses to use it.

Heiko Tietze wrote:

louis94 wrote:

• Toolboxes should be placed on the left side of the document by default.

Although I don't disagree this guideline sounds a little bit too restrictive. Opinions?

It is indeed. If we have only a small set of tools (say ~5), they could as well be integrated to the toolbar. I'd still put them on the left, before actions.

Heiko Tietze wrote:

louis94 wrote:

Code: Select all

A C E | A C | A
B D   | B D | B


Can we align the content side by side in both vertical and horizontal layouts? I still read from left to right... And by the way: Does it make sense to flip the content for RTL languages?

Code: Select all

A B C | A B | A |
D E   | C D | B |


The reasoning behind it was the following : When you scan the toolbox, you don't do it line by line but rather from left to right. Implementing it this way is also easier (not a good reason, I know) Looking at them, your solution is better. Seems developers will need some extra lines of code

Heiko Tietze wrote:We should mention as well accessibility for toolboxes. I don't know how well this concept works for impaired people because it's not possible to tab through the items.

Whether it's implemented as a QToolBar or a QToolBox, there is no problem, tabbing is always possible. But shortcuts should be available to make accessing tools faster.
[BTW, on-canvas manipulation (the typical use-case for toolboxes) is really an accessibility nightmare.]

Heiko Tietze wrote:Nevertheless, great work, louis94!

Thanks !

Louis

louis94 wrote:

Heiko Tietze wrote:I'm unsure if toolbox plus menubar fits our command structure. What if tools are available but the rest of the app is very simple?

Same as for toolbars : the toolbox should not replace the menubar if there would be one otherwise. If we change this, we need to change the toolbar HIG too (the second bullet was copied from there).

Yes, we should change the toolbar HIG, too, as it is confusing. Actually, I think that specific guideline can be removed from both, as the command structure patterns already say which combinations of menu- and toolbars make sense where.

louis94 wrote:

Heiko Tietze wrote:

louis94 wrote:

• Don't execute any operation immediately; do not require additional input from user.
  
• Provide a keyboard shortcut to allow fast switch between tools.
  
• Do not hide tool boxes by default. If configurable, users should easily be able to make the tool bar viewable again.

I'd say operations have to start always without any further user interaction, as stated in the second part. So it is immediately (opposite of first part).
The keyboard shortcut provides access to other toolboxes, not every toolbox item, right? Is it always required?
Usually the toolbox is hidden unless the user wants to start this kind of operation like drawing shapes in a word processor, IMHO.

There needs to be some change to the interface : available options change, mouse cursor changes, etc. I don't consider these changes as operations, as they don't modify the document. Tools are ways of doing operations. Think of the "Select rectangle" tool : the current selection should not be changed when the user chooses to use it.

I'd agree with Louis here: I wouldn't see changing a tool as an "operation". However, we might change the wording to "Do not put any buttons that directly modify the document in the toolbox. Selecting a tool in the toolbox only changes the mode of operations. The document is only modified when the selected tool is applied to the canvas." to make it more clear.

louis94 wrote:

Heiko Tietze wrote:

louis94 wrote:

• Toolboxes should be placed on the left side of the document by default.

Although I don't disagree this guideline sounds a little bit too restrictive. Opinions?

It is indeed. If we have only a small set of tools (say ~5), they could as well be integrated to the toolbar. I'd still put them on the left, before actions.

Hm. It's a "should" guideline, so I think it's okay to put that as a default recommendation. Designers are still allowed to place the toolbox somewhere else if that makes more sense for their individual application.

louis94 wrote:

Heiko Tietze wrote:Can we align the content side by side in both vertical and horizontal layouts? I still read from left to right... And by the way: Does it make sense to flip the content for RTL languages?

Code: Select all

A B C | A B | A |
D E   | C D | B |


The reasoning behind it was the following : When you scan the toolbox, you don't do it line by line but rather from left to right. Implementing it this way is also easier (not a good reason, I know) Looking at them, your solution is better. Seems developers will need some extra lines of code

Agreed, Heiko's suggestion is better.

There seems to be enough agreement to put it online. Louis, will you do it?

What else can we take into consideration?
* docking (I'd appreciate a simple method to dock toolboxes since dragging dockable side is sometimes annoying; something like QtDesigner have in its decoration)
* open/close via menu (relates to my keyboard question)
* resizing with realignment
* filter for extended content
(so far my first brainstorming)

Heiko Tietze wrote:There seems to be enough agreement to put it online. Louis, will you do it?

I've added it : https://techbase.kde.org/Projects/Usability/HIG/Toolbox
I don't know how to include the layouts we defined (in fact, I'm too lazy to draw them). There is also the question of how the shortcut should be displayed in the tooltip (bold, between [] or (), ...). We need a rule, or every developer will come with a different solution.
As there are still a few issues, I haven't added it yet to the Editing and Manipulation page. Maybe a few other pages should be linked from there too (the ones listed under the Actions header in Viewing And Navigation).

Heiko Tietze wrote:What else can we take into consideration?
* docking (I'd appreciate a simple method to dock toolboxes since dragging dockable side is sometimes annoying; something like QtDesigner have in its decoration)

This should be implemented in Breeze, so all dockables would benefit from it.

Heiko Tietze wrote:* open/close via menu (relates to my keyboard question)

I don't understand what you mean. What do you want to close ? The toolbox ?

Heiko Tietze wrote:* resizing with realignment

Related to the layout we have already discussed, isn't ?

Heiko Tietze wrote:* filter for extended content

If you have Qt Designer's widgets box in mind, I don't think it's a toolbox. Qt Designer has four tools : Edit Widgets, Edit Signals & Slots, Edit Friends and Edit Tab Order (translating from French here).
Filtering must not be necessary in toolboxes, because it's quite slow and kills the "fast access" feature.

Louis

louis94 wrote:* open/close via menu (relates to my keyboard question)
I don't understand what you mean. What do you want to close ? The toolbox ?
* resizing with realignment
Related to the layout we have already discussed, isn't ?

Yes. What if I want to hide stencils in a graphics tool until I need them? I would look for activation at 'menu > view' plus 'tools' perhaps, assuming it's a checkbox item.

Heiko Tietze wrote:* filter for extended content
Filtering must not be necessary in toolboxes, because it's quite slow and kills the "fast access" feature.

Accepted. Then we can add "Do not extend the toolbox by other controls than tool- or toggle buttons. It contradicts the quick access purpose."

louis94 wrote:

Heiko Tietze wrote:What else can we take into consideration?
* docking (I'd appreciate a simple method to dock toolboxes since dragging dockable side is sometimes annoying; something like QtDesigner have in its decoration)

This should be implemented in Breeze, so all dockables would benefit from it.

The default QDockWidget titlebar has a button to re-dock the floating dock.
I'd stay away from messing w/ a non default titlewidget.