Inject not yet installed macros in the WYSIWYG macro picker

Development
#1

Hi everyone,

I’m currently working on the idea to make easy for an admin to insert a macro which is not yet installed but available in one of the compatible available extensions right in the macro picker.

First, a disclaimer regarding an important limitation of this kind of macro: the only info we have about them if their ID and the extension which provide them. The reason is that everything else about the macro is dynamic, so we cannot access it unless we install the extension.

So here is a proposal (with the help of @mflorea) of how it could look like:

  1. The general idea is to list “extension macros” along with the regular ones (but at the end in my current proposal).

picker

  1. All those macros would be part of the “Extensions” virtual category

category

  1. To avoid problems, I propose to list only macros from extensions which:
  • are compatible with the current context (compatible with current wiki or root namespace when on the main wiki)
  • the current user is allowed to install it in the current context (that means only admins will see them and only users with PR in the case of JAR extensions)

Since we don’t actually have the macro name and description, my proposal is to “emulate” them with information of the extension: the macro id plus the name and version of the extension to make clear this macro is special and the extension summary as description (which, sometime, might not have that much to do with the macro itself but hard to do much better).

When you select one of those macros you get an “Install” button instead of the usual “Select” one:

install

When you click install you get to the second step which install the extension and then show you the usual macro form. This second step is already designed to wait, so for a first version I was planning to not pollute the user with new UI for now and simply run the installation in non-interactive mode as part of the already existing wait, which would simply be a slightly longer wait most of the time. Of course, it could be a much longer wait if the extension has a huge number of dependencies, but I don’t think we have the case currently.

Here are some possible variations ideas:

  1. have two clearly separated lists instead of a single one containing the two kinds of macros ?
  2. use the extension category instead of grouping all those macros in the same “Extensions” category ? Some other name better expressing the subtleties of “macros located in not yet installed extensions” ?
  3. show all macros, but disable the install button when selecting one you are not allowed to install ?

WDYT ?

#2

Is there any way to actually display a dedicated icon to quickly spot those macros are not yet installed? Or maybe to add a horizontal line to split between the installed one and the others?

Another idea: it could be good IMO to have the “Installed macros” and “Not yet installed macros” along with the “All macros” categories.

#3

Cool proposal :slight_smile:

I like the idea of having the installed process directly in the main UI, one way or another. I think it’s better for discoverability.

+1 as long as the user has an explanation for why the action is greyed out.

Ideally I’d make the installation a separate step in the UI, but I’m ok with having that in a second time.

#4

Most macros (if not all), come from extensions so I’m not sure what the Extensions category means. I’d prefer to have Not Installed category instead.

It would also be nice when displaying the macros to show some indicator that the macro is not installed. One idea would be to display the categories next to the macro name, in a rounded box (can’t recall the official name for this ;)).

I wouldn’t display the version as I don’t see what it brings. Or if you think it’s needed, then display it but in small and not as part of the macro name, possibly using the same L&F as for displaying the categories (see above).

I think the Not Installed category could be enough.

Yes, I think it would be a good idea to list all macros but when you don’t have the permission to install them, to display some message explaining it and to tell the user to contact an administrator or someone with the permission required to install them.

I guess, for XAR macros, we could extract and index more information like the macro name, description and more. It’s more work for sure and might not be needed in the first version.

The rest sounds good, it’s nice that we’re making progress on this!

#5

I prefer the solution suggested by @vmassol to show the category in a badge, after the macro name, of course, only when “All Macros” category is selected (otherwise if all macros are from the same category it’s redundant).

I don’t see the need for a “Installed macros” category. Having a category for not installed macros is enough IMO. I agree with @vmassol that naming the category “Not Installed” (rather than “Extensions”) is better. We could also show this category at the end in the drop down, after a separator, to emphasize that it’s different than the others.

The idea is not to show the Extension Manager UI but to perform a quick non-interactive install, using default settings. So no install plan, no merge conflicts, no logs, no questions. For this just a simple loading animation or progress bar on the macro parameters step is enough. If you want more control then you need to install through the Extension Manager UI.

+1. I would also place this category at the end of the drop down, separated from the rest, to emphasize that it’s different from the rest.

+1 for a category badge after the macro name, but I’d show this only when All Macros category is selected, otherwise the badge is redundant (if all shown macros are from the same, selected, category).

I guess Thomas wanted the administrator to see what version of that extension is going to be installed. Using a badge as for the category would emphasize it too much IMO. I would either remove it or keep it as is (in the extension name).

I would make the Install button disabled and show a tooltip on hover.

Thanks,
Marius

#6

So what the UI would be showing if a decision needs to be taken by the user (e.g. in case of conflicts)? Just an error specifying that the macro cannot be installed?

#7

Non-interactive mode just apply the proposed resolution (what you get when you just click Continue).

#8

Thanks everyone for all the suggestions, here are some updates based on them:

categories

Category renamed to “Not installed” and separated from the others.

notinstalled

I customized a bit the display of not installed macros:

  • no more automatic uppercasing, to make it more accurate (it’s the id here and not some display name)
  • special style for the extension (I’m actually not fully happy with it, but honestly don’t count on me to do much better, if someone have a complete css suggestion I can just copy/paste don’t hesitate :slight_smile: )
  • a new badge to emphasize the fact that this macro is not installed yet, I just used the badge class which looks nice, but I’m wondering if it would be better to use a different color

Regarding what happen after you click “Install”, I honestly think it does not worth it to complexify the UI with a new dedicated step and progress. As @mflorea indicated, it’s not like it was the only way to install an extension.

Of course, even if we only list compatibles and authorized extensions it’s still possible that something fail the installation in which case we still need to do something: so I plan to show an error “step” instead of the macro form.

#9

Looks good to me.

#10

It’s now pushed and will be part of XWiki 14.4.

I totally forgot to implement the suggestion to show all macros but disable those the current user is not allowed to install. I created [CKEDITOR-447] Show all compatible macros but disable those you are not allowed to install - XWiki.org JIRA for it.

#11

Hello all,

I’ve seen this in the released version of XWiki, hence my late feedback about it - I know it would have been better to bring this up before implementation.

One more information is essential for this objective, the status of the extension that would be installed. From what I tested, there is no information in the wysiwyg dialog about whether the extension is recommended or not.
Since when installing from extension manager the recommended status of an extension is very visible - including it being used for default filtering - I think it needs to be the same when installing from the editor, otherwise this feature is introducing a stability risk.

Currently the UI does not warn clearly enough about the fact that a whole new feature will be added to the wiki in order for that macro to be brought in.

For example, take the following situation:

  • an admin edits a page, with a somewhat “experimental” mindset
  • they see the macros in the wywisyg
  • they pick diagram or ideasrecent macro from the list and click Next (Install)
  • they get transparently to the next step (not even a confirmation message)
  • they fill in the parameters and add the macro in their page, or not even, because they don’t know what to fill in, it doesn’t actually matter that much

They exit the edit mode:

  • now, a new application is displayed in the applications menu on their wiki (Diagram or Ideas).

In some situations this is probably what the users are expecting, or they find this normal, since they wanted to add this new feature to the wiki.

However, I can easily imagine situations where the users are not really aware that they are adding an application to their wiki, nor what exactly does that application. Also, it’s an administration action that is outside the administration, so I can imagine admins that are doing this not being aware that they are making changes to the wiki that are of the same “gravity” level as the actions from the administration.

Otherwise it’s a very interesting feature, we just need to make sure we warn properly the admins of what they’re about to do.

#12

Good point.

I thought the current hints were enough, but you are probably right, and getting a very explicit alert when clicking install would not harm.

#13

Personally I would find the following behaviour perfectly acceptable (and normal), a good balance between discoverability and warning about making significant changes to the wiki:

  • everything until clicking on the “Install” button can stay the same
  • when clicking “Install”, a confirmation popup / screen is displayed, explaining to the admin that:
    • “you’re about to install an extension on your wiki”
    • the extension you’re installing is this one, with this name, this description, this version (the ones displayed in the admin area)
    • the status of that extension - recommended / not recommended, as displayed in the administration area
    • the information on the extension that is displayed in the description tab in the administration should be, if possible, displayed in this confirmation screen as well (authors, links to website, sources, etc).
  • a confirm button would be displayed here and then everything happens as it’s implemented today (silent install)
  • a cancel button would allow the admin to change their mind
  • probably a bit too much but maybe a button should allow the admin to open the extension in the administration → extensions area, to be able to get more information about the extension to install, etc. This would achieve the objective of connecting this administration action from wysiwyg with the administration action from the administration (which is where users would expect to find administration actions).

Thanks,
Anca

1 Like
#14

OK, thanks for the design ideas @lucaa , I was thinking about something similar (but also with a “Recommended” marker in the list).

Created the following issues by the way: