ENH: Change collapsible arrows to detail the direction of the changing content

[jamesobutler]

This contribution is an example of contributing back design changes based on some design research that I have read. I mentioned at a recent Slicer weekly meeting about research based design systems and being willing to contribute back design changes. I encourage reviewers to read the linked nngroup article below.

---

This reverts 952d5dc (cc @pieper)

https://www.nngroup.com/articles/accordion-icons/
[Laubheimer and Budiu, 2020]

This research looked at the difference between the following indicators for accordions (ctkCollapsible type widgets) and found the caret (downward-facing-arrow) performed the best.

Caret (or downward-facing arrow)
Plus
Right-facing arrow
No icon at all

We placed the accordion icon to the right of its associated label, close to the edge of the screen and right aligned. (We acknowledge that another possible position is to the left of the label — our results may not generalize to that placement.)

^For now I have left the icon on the left side of its associated label, but that could be under consideration as well. This would position that indicator like it is for a combobox.

Use a caret icon to designate an accordion, whether on desktop or mobile — our study found that of the standard set of icons used in this context, only the caret performed better than either no icon or a nonsense icon at indicating that than it was an accordion.

master	This PR

[pieper]

Hmm, since the cited paper didn't explicitly test the arrow the way it's used currently in Slicer I don't see how it can be cited as a justification for changing the current convention. I do appreciate the concept of using evidence based principles to drive the design changes but this one falls short of the mark IMO.

The convention we use in Slicer is certainly not uncommon (e.g. [1]), and I've never heard that anyone was confused by it, but I think I at least would be confused at least for a while if the meaning of the downward arrow suddenly changed from meaning that the area was current open to meaning that it was currently closed.

Is this motivated by anything other than being an example let's discuss further. If you are looking for examples I hope there's an example of a more compelling improvement.

[1] https://maxalley.wordpress.com/2015/02/20/bootstrap-style-the-accordion/

[jamesobutler]

I have utilized the learnings from specifically research based design systems such as IBM Carbon and GE Healthcare.

The GE HealthCare design system allows for the controller (icon) position to be either to the left of the label or to the right. However it does specifically say to avoid pointing the indicator to the right (https://edisondesignsystem.com/accordion?tab=1).

The IBM Carbon design system recommends the controller (icon) position to be on the right side, though in rare cases could be on the left for tree like functionality. It also indicates the orientation of the icon should be downward facing for the collapsed state and upward for the expanded state. https://carbondesignsystem.com/components/accordion/usage#states

The convention we use in Slicer is certainly not uncommon

Indeed the current convention is used by other places, but I haven't found research yet to back up that the current usage is because it is the best variant. Your link was a post from 2015 and maybe there was research out there that showed the style was the best at that time, however the research I've linked to at least appears to be the latest with the paper published in 2020. I definitely don't aim to make a change just to make a change, but rather to back it up with principles of research based design systems.

Is this motivated by anything other than being an example let's discuss further.

This proposed change is purely motivated by showcasing research based design to make a visual change. These collapsible buttons are frequently used in Slicer, so it was an obvious visual change that I started with. There very well may be future changes to other components that I contribute that are bigger improvements over the current design, but this is where I have started.

[jcfr]

Here are some examples.

Summary:

• When the open/close are one the right side, all examples show 🔼 and 🔽

• When the open/close are n the left side, I found only one occurrence (VS Code settings) with ▶️ and 🔽

Right Side

GitHub UI / Settings

In this case, the arrow is also located on the right and the behavior if consistent with the referenced publication.

Closed	Opened

CoreUI / Vue Accordion Component

See https://coreui.io/vue/docs/components/accordion.html

Closed	Opened

Qt Creator Build settings

Closed	Opened

Left Side

WebSite

See https://www.smashingmagazine.com/2017/06/designing-perfect-accordion-checklist/

Guardian	PremiereLeague

VS Code Settings

Closed	Opened

qaccordion

In this Qt implementation, the CARRET_ICON_OPENED and CARRET_ICON_CLOSED icons match what we are using.

Closed	Opened

References:

• https://github.com/crapp/qaccordion/blob/9fcafc27a8ade4b4c7cf6358f38bf2ce9fea98fe/src/contentpane.cpp#L214

[jcfr]

In addition of moving forward with 🔼 and 🔽 as it is now expected by users of many modern application, I suggest we also move the icon on the right.

By applying these changes in additional of the one of @jamesobutler , I created a few screenhots:

diff --git a/Libs/Widgets/ctkCollapsibleButton.cpp b/Libs/Widgets/ctkCollapsibleButton.cpp
index 2ef07081..da7689c7 100644
--- a/Libs/Widgets/ctkCollapsibleButton.cpp
+++ b/Libs/Widgets/ctkCollapsibleButton.cpp
@@ -104,7 +104,7 @@ void ctkCollapsibleButtonPrivate::init()
   this->MaximumHeight = q->maximumHeight();
 
   this->TextAlignment = Qt::AlignLeft | Qt::AlignVCenter;
-  this->IndicatorAlignment = Qt::AlignLeft | Qt::AlignVCenter;
+  this->IndicatorAlignment = Qt::AlignRight | Qt::AlignVCenter;
 
   q->setSizePolicy(QSizePolicy(QSizePolicy::Minimum,
                                QSizePolicy::Preferred,

Here is what we have:

Module	Before	After
Welcome
GaussianBlur
GrayScaleModelMaker
Sequences

[pieper]

Moving it to the right side would make it a more explicit change from the current convention and hopefully less confusing to users as a result.

[jcfr]

This quote makes sense to me and is consistent with the proposed approach:

visual connection: If you see an arrow that points up, you expect something to happen in that direction.

Source: https://ux.stackexchange.com/a/87351

They also discuss an example where someone referenced an example¹ of hierarchical accordion, an the next comments² are also interesting.

Footnotes

1. https://codyhouse.co/demo/multi-level-accordion-menu/index.html ↩

2. https://ux.stackexchange.com/questions/87350/which-way-should-arrows-point-for-a-dropdown-button/87351#87351 ↩

[lassoan]

I agree that it is a good approach to make GUI decisions based on experiments/measurements and would welcome to start doing it more in Slicer.

I think this particular study was incomplete. They should have evaluated pair of icons (collapsed/expanded). In collapsed state, down-arrow and right-arrow works about equally well and the study has confirmed this (there might be a statistically measurable difference, but i does not mean practical difference). What the study missed is that if they use down-arrow for expanding then they need to use up-arrow for collapsing, which is really ambiguous (is it going to jump to the top of the page?, is it going to expand something above?) They have also missed evaluating all the options when the icon is on the left side. This is significant, because one concern was that right-arrow can be interpreted as navigating away from the page, which is not a problem if the icon is on the left side.

So, overall, this incomplete experiment is not very convincing to me. I would be completely fine with using the down-arrow for expand action (even if the quantitative results show that difference is just barely measurable), but I would prefer not to use the down-arrow/up-arrow combination for expand/collapse because based on my personal experience it is confusing (compared to the very clear right-arrow/down-arrow on the left side of the text).

Another problem with the change that it cannot be made in isolation. Down-arrow has slightly more advantage when it is on the right side of the text. But moving the icons to the right would make the collapsible section look like a combobox and make the GUI confusing: there is a lot of text on the left side and a lot of almost-identical looking up, down, up/down buttons quite far, on the right side (giving hints that those text lines are actually collapsible sections, node selectors, spinboxes, etc.) - see in the Grayscale model maker GUI example above. To know what will happen if you click on the text, you need to follow that row from he left to the right, which is quite challenging.

If we want to start to make the Slicer GUI look more similar to other software, there would be more obvious changes to make. For example, we could consider moving checkboxes to the left, as it is done in every other software. Or we could think about how to create a ribbon-style toolbar. Or focus our attention on improving the icons.

[jcfr]

more explicit change from the current convention

Ditto.

To move forward, we could add an option to use the "new convention" for the icon

Now how do we consistently apply this change to Slicer and extensions.

Doing the following would work:

• change default alignment
• change default icon convention

To address this a more complex approach involving global static may have to be implemented (e.g similar to QGuiApplication::setLayoutDirection(Qt::LayoutDirection direction), a function like ctkCollapsibleButton::setPreferredIconAlignement and ctkCollapsibleButton::setPreferredIconStyle could be added.

But moving the icons to the right would make the collapsible section look like a combobox and make the GUI confusing

Ditto. I also observed this while looking at CLIs user interface.

[jamesobutler]

But moving the icons to the right would make the collapsible section look like a combobox and make the GUI confusing

To address this the components in the container could be made to not fully extend the width of the container. Overly wide objects reduces the value when the indicator is far to the right of the content that is left aligned.

I hope to use the primary and secondary research that UX designers used such as on the GE HealthCare design system since their expertise in design principles is a valuable resource. The Slicer community does not have dedicated UX designers, but does have many developers that can implement cool new functionality using the design principles documents as guidance about how certain components should “best” function to avoid settling for “ok” or possibly even confusing designs.

In this PR I was attempting to address a specific change without going down the rabbit hole of fully redoing an application in a single PR. I’m up for additional changes here, but I want to be mindful to not accept too much creep, but commit to incremental improvement.

For those interested in more general UX content of collapsible buttons - frequently linked regarding accordion component types:
Accordions Are Not Always the Answer for Complex Content on Desktops

[jamesobutler]

Here is also a link about accordion designs including icon usage and positioning. The author mentions test and experiments run, though all of the details are not given. It is a longer read, but also quite interesting:
https://www.smashingmagazine.com/2017/06/designing-perfect-accordion-checklist