Impact of allowing macros to have several categories on the CKEditor Macro dialog

Hello all,

Following the “Add concept of hidden macros” discussion. I’d like to discuss the impact of this change on the CKEditor Macro Dialog.

Note: I’ll use the term “categories” but at the time of this post, there is still an ongoing discussion regarding the definitive name (i.e., categories/tags/labels).

Currently, the UI looks like the screenshot below, and clicking on one of the lines of the dropdown menu filters the macros list with the macros of the selected category (a macro can only be linked to a single category).

image

Migrating to several categories for each macro requires to adapt this UI. The goal is to allow users quickly to list macros from interesting categories.
For instance:

  • Listing all non-hidden macro form the Content category.
  • Listing all macro from the Navigation or Notifications categories.

To do so, I propose the following UI:

image

Each category comes with a toggle button. All the toggles are on by default except the one for the Hidden category which is only ON if the user sets her preferences to show hidden macros by default. The Hidden entry is only visible to Advanced users.

The macros are listed if all of their linked categories have there toggle sets to on For instance, in the screenshot above, the Layout and Hidden categories are set off.

  • Macro A [Formatting, Hidden]: not listed, because Hidden if off
  • Macro B [Formatting]: listed because Formatting is on
  • Macro C [Deprecated, Formatted]: listed because Deprecated and Formatted are on

Other notable changes:

  • Clicking on the categories labels does nothing
  • “All macros” proposes a refresh button to revert the toggles to their initial positions
  • The button aside the search bar now always display “Categories” instead of the selected category.To see the filtering status of the categories, the user must unfold the menu.

Note: should we also make other categories unchecked by default (e.g., Deprecated, Internal). Or should we introduce a configuration to configure the list of categories unchecked by default?

WDYT?

PS: See Macro Visibility Control (Proposal.MacroVisibilityControl) - XWiki for the corresponding design page.

Hi, thanks for moving on this subject.
Frankly I’m not a big fan of this UI, I see two major drawbacks:

  1. the UI is very heavy when looking on the screenshot I see plenty of things and I’m almost lost
  2. when the categories menu is close I have no idea what are the categories displayed, which can be quickly tedious

So I propose instead to reuse the same concepts as we have with tags: basically the idea would be to add a small div below the filter input listing the enabled categories. When you click on a category to filter it it’s added to that list presenting the enabled categories side by side with a small x to allow switching off the filter on them.
That way you can quickly see all filters enabled (they’re all displayed outside the menu) and the UI is much simpler.

Thanks for the suggestion. Your proposal is interesting.

Do you have in mind to list the included categories, the excluded categories, or both ?

Without both, some thing could be missing to the user (either what is excluded, or what is included, or what can be included/excluded). But with both, the UI get heavier again.
Unless we also provide an auto-suggest of the allowed categories.

Also, I think we need to support something equivalent to a click on “All Macro”, with a reset to the default filter. I’m not sure how to do that with your proposition (if needed at all).

So the way I see it is the following: by default all macros are displayed but no category filter is displayed in the area I mentioned since it’s the default filter. When you open the category menu and click on a category it only displays the macro for that category, so it’s an include filter only. And you can only add more includes filter. I don’t really think users needs capability to have an exclude filter in such UI.

Regarding the capability to reset to all macro, I do agree it’s needed, it could be either as you presented in the category menu, or it could also be a reset link in the area displaying the list of categories selected.

This is not great as it’s not generic. All categories need to behave the same or it seems that hidden is not a real category.

For example this can be made generic by having an Admin UI option to set which categories are enabled by default.

It thinks that answers:

Also, do we want all those special categories to be hidden from non-advanced users by default too?

Yeah I was going to say that’s unless it’s to just obey the “hidden” flag for viewing documents. That could be enough for our stakeholders sponsoring this issue but OTOH I’m not sure that this is always going to be the case. I can see some UCs where admins would want to explicitly prevent users from using some macros (such as internal macros brought by extensions), even when users can see hidden documents.

So we need to list all the UCs/requirements re hidden:

  • Ability for Admins to force some macros to be used over others
  • Ability for Admins and Extension developers to prevent users from using internal macros that the extension uses for its code
  • When users don’t see hidden docs, also don’t display hidden macros
  • more?

Following @surli proposal, I made a small poc. See the screenshot below.

The second field is a xwiki-selectize field, with an autosuggest of the existing categories.

image

The macros are filtered according to the following parameters:

  • hiddenCategories: a list of categories hidden by default
  • selectedCategories: the list of categories selected by the user
  1. All the macros containing a category which is part of hiddenCategories, unless it is also part of selectedCategories are excluded from the results
  2. if selectedCategories is not empty, all the macros not containing any category which is also part of selectedCategories are excluded from the results
  • The drop down menu is not required anymore (we lose the count of macros of each category)
  • The reset action is not required, the user cal just remove all selected categories from the xwiki-selectize field

iiuc, this two use case are covered by a combination of:

  • admins being able to add new categories to macros (e.g., Hidden)
  • admins being able to make a category hidden by default

Of course users can still see hidden macro if the want to, but they have to circumvent the UI to do so (since these macro are not presented by default).