Macro insertion UI for Cristal

Cristal
1

When inserting a macro in XWiki, we already have a UI that allows selecting a macro and configuring the various options.

In Cristal, we have no such thing. Hence the question: what should we use?

Two main options appear to me:

  1. We can either re-use the UI that already exists in XWiki ;
  2. Or we make a new UI tailor-made for Cristal

I would personally lean towards option n°1, the only downside I see is that the dialog may not have the exact same design language as Cristal’s.

2

+1 for this option.
The plan is to make elements distributed by xwiki platform reusable outside of it.
Having differences thanks to the selected design system is expected so all good.

1 Like
3

+1 for option 1, it will be easier to maintain one element for two design systems than develop and maintain two different elements. It will also be a good way to highlight how compatible the design systems are and what’s missing :slight_smile:

1 Like
4

+1 for option 1 as well

Thanks!

1 Like
5

Hello @ClementEXWiki Thanks for asking this question.

I don’t see why it would be related to Cristal (I supposed you mean Cristal standalone?). For me, this is an XWiki question since the Blocknote editor lives in XWiki and I guess the macro insertion UI you mention is the Blocknote one.

AFAIK @mflorea has already reused the XWiki macro dialog in Blocknote, for now (for simplicity) but the idea more long term is to rewrite it.

+1 for 2 (but not for Cristal standalone. For XWiki, and specifically for Blocknote :)).

What we’re being asked more and more is the ability to directly insert a macro in blocknote without going through a dialog, i.e to have a real wysiwyg experience on macros (ie acting as a live preview basically). Going through a dialog looses that streamliness and preview feature. Then, once inserted, on hover, it should be possible to click on additional settings. Basically something that @tkrieck already proposed at Macro integration UX proposal

We would need to discuss how we handle mandatory macro parameters (e.g. the include macro). There are several options (using some defaults that can be modified, showing these params directly in the wysiwyg editor, opening a dialog).

BTW am I wrong in thinking that this topic you started is actually a dup of Macro integration UX proposal ? Should we continue there or here?

Thanks

6

The macro dialog is actually not specific to any editor, it’s a global component that’s shared between editors. There will still be the option to insert macros directly, the slash menu already allows it for instance, which inserts the macro with default parameters.

And it is a different topic from the other UX proposal, as this is about deciding whether we unify the design between XWiki and Cristal standalone or whether we keep separate design, with the existing one staying in XWIki, and the new one going into Cristal standalone. Which would mean two separate UIs to maintain, twice the amount of the code, and different behaviors based on whether the user is using XS or Cristal, which could be confusing for those who use both products.

7

And this is located inside Cristal standalone code base? If so then that’s a mistake as I believe we need it shared and located inside the XWiki code base, making it an XWiki feature (and not a Cristal Standalone one).

ok, sorry then. I find the title is a bit misleading (and the description too since it doesn’t mention that).

The answer to whether we unify or not the designs between XWiki and Cristal standalone is always yes by default for me, for all features (provided we’re talking about features that exist in both products ofc), for the following reasons:

  • We want consistency between products
  • We want simpler maintenance and thus not redo stuff
  • If one design is better, then there’s no reason that the other product gets a suboptimal design. This is true because the L&F of both products are being merged completely.

So I’m +1 to unify designs for all features (not just the Macro dialog), and thus put the code inside the XWiki code base (for common features). But I don’t necessarily agree with option 1 “We can either re-use the UI that already exists in XWiki” since, it’s not because it already exists in XWiki that we shouldn’t improve it (and we know we need to improve the XWiki Macro UI).

Thx

1 Like
8

Indeed some code is not shared between the two codebases, hence my proposal to unify it as a single UI instead of maintaining two different ones.

Indeed I could have described it better, it was clear in my head but apparently not in writing.

Given everyone is voting for option 1, we’re going to go that route. Thanks everyone :slight_smile: