[MGNLUI-3585] Action bar is not well structured when there are many actions Created: 30/Apr/15  Updated: 11/Mar/21  Resolved: 11/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: actionbar
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Andreas Weder Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: blocked, feature-work, mh5371, overwhelms-me, pain-point, team-priority, ux
Remaining Estimate: 0d
Time Spent: 4d 1h
Original Estimate: 3d

Attachments: PNG File Desktop05_04_Action bar.png     PNG File Desktop05_05_Action bar.png    
Issue Links:
Relates
relates to MGNLUI-3626 Deprecate hack for multiple selection... Closed
dependency
depends upon MGNLUI-3398 Redesign action capabilities: multi-i... Closed
duplicate
is duplicated by MGNLUI-5784 Collapsible groups in action bar Open
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Story Points: 5

 Description   

We already have large sets of actions in some Action bars. The design concept behind Action bars actually also asks for sections, not only groups (we already group actions). Sections bundle related actions under a title and can be opened and closed.

The design ideas behind sections are:

  • Sections bundle related actions under a common topic (e.g. "Personalization", "Versions")
  • By default, only the first (primary) section is open, all others are closed. In addition, you can configure a particular section to be also always open by default.
  • On mobile devices, mainly the primary section is available. Optionally, a second section can be made available as well. Sections don't show their titles, though.
  • In the secondary menu opened on right-mouse click, only the primary section is available.

Having a clear distinction between the primary and other sections requires developers and designers to decide on the core set of actions they want to offer in any given app or sub app. It also helps in keeping a low UI complexity in cases there's not a lot of space for showing actions.

As for the current state of implementation, we already do have limited support for sections. We can configure them, but not open and close them. In addition, action availability is not aware of sections.



 Comments   
Comment by Mikaël Geljić [ 29/Jan/16 ]

Summarizing a few points after PoC review:

  • Preview section: we keep it at the bottom of the bar, with its darker background; it can still become collapsible
  • Section "arrows": we try to use upwards/downwards arrows, like an accordion component. (unlike in the visual designs)
  • Collapsed action bar: we only display sections currently expanded when action bar gets collapsed. We preserve vertical positioning of actions like now (there will be white space between sections).
Comment by Sang Ngo Huu [ 18/Feb/16 ]

Problem when implementing this ticket:
Multiple section always show (MGNLUI-3096). Following wiki https://wiki.magnolia-cms.com/display/WIKI/Options+for+solving+multiple+actionbar+availability and there are the results:

  1. Consider "multiple" sections obsolete and remove them
    no-go, non-deterministic, how about custom apps
  2. Only enable multiple sections for specific apps (privileged)
    a) enable new behavior with config flag or class? => Tried with multipleSection flag, it works, but seems like a hack
    b) re-configure availability rules => There are many apps, and custom apps need to re-configure
    c) custom AvailabilityChecker, and make it default in next version? => Promise, but still not have solution for it
    d) use the correct type for multiple availability in "upgraded apps"
    + either by overriding type mapping
    + or by adding property (back to the correct one)
    class: info.magnolia.ui.actionbar.definition.ConfiguredActionbarSectionDefinition
    => This is a good solution, clean up the mess in multiple configuration now. But it should be in next version.
    e) complement (d) with workaround in BrowserSubApp to:
    only display at least one available section if one of them is a DeprecatedActionbarSectionDefinition
    allow multiple sections if all available sections are proper ConfiguredActionbarSectionDefinition
    => Implemented, and it works now, but it is a workaround solution
  3. Check redundant actions between sections
    + and hide section if empty?
    + a second available section would only add actions if not already present in the first one
    => Tried, it works but it is not make sense, if user want to kept the duplication. And if user remove one of actions in multiple section, this section still show as redundant

My conclusion:
I prefer workaround solution 2. e), and after that, we clean up the mess in multiple configuration in next version.

Comment by Mikaël Geljić [ 29/Mar/16 ]

Let's get another opinion on a high-level first:

  • config/naming (I don't know why I'm somehow skeptical on having both collapsible and collapsed on the definition, but cannot see much other way)
  • is option 2e. a good fit for current (5.4.x) and future plans?
    • and how it is hooked within BrowserSubApp

Worth re-iterating that these changes should have no effect right now, until we start applying a new section scheme, starting in pages app (ticket to follow).

Apart from that, widget changes seem to be pretty ok. I won't mention ctors/deprecations yet; this we can still decide and do last.

Comment by Aleksandr Pchelintcev [ 01/Apr/16 ]

After looking at it - I must say I like the approach chosen, it would allow us to update the apps to the new schema one by one.
Some observations:
1) multiple rule is quirky - it applies to all the defs which have property multiple = true + if the selection contains only one element => section multiple applies to all the single nodes. It looks to me that we are lacking an availability rule which demands the selection to be multiple (if we wanna keep the multiple sections which I think makes sense).
2) root section also almost always shows up in the list of visible sections - need to do something with it too.
3) UI: the triangle collapser control needs some better alignment.
4) I did some minor polishing and also rebased the thing on the current master here https://git.magnolia-cms.com/projects/PLATFORM/repos/ui/compare/commits?sourceBranch=refs/heads/improvement/MGNLUI-3585, sang.ngo, feel free to use it for the PR
5) re: presence of both collapsible and collapsed - I am personally alright with that, given that we normally don't have to configure both of them, i.e. have reasonable defaults and maybe some fuzzy logic, e.g. when there's just one section visible - it can't be collapsed etc

Comment by Mikaël Geljić [ 10/May/16 ]

As part of specifying the guidelines for content apps, we took another look with weder, and re-visited some of the points from before:

  • We try to scroll secondary sections together (while the primary section remains fixed), alternatively we may scroll all sections altogether
    (currently they all scroll individually, I know, I implemented that)
  • Collapsible preview
  • Accessibility: we should ensure actions inside collapsed sections can still be reached
  • We should use upwards/downwards arrows, like an accordion component (it was mentioned before, but wasn't the case when I tested it)
    • We also need these small arrows on the collapsed actionbar
      visual design like the collapsed preview section here: Master template
  • Icing on the cake would be transitions, but we can dismiss those for now.

Re: configuration & multi-selection, we don't want to multiply configuration, so we'll have to find options (decorating the action bar main title dynamically?).

Generated at Mon Feb 12 09:08:05 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.