I don’t think there can be any form of personality as long as we choose to use that framework as is, whichever that is.
Any form of personality would be extra work on top of a framework, which would offer the base. Having a framework would also ensure that components are available to application developers even if XWiki didn’t have time/ressources to handle them specifically (because they’re part of the framework and the framework would be available). For this last reason, having a framework used without many changes is not only a design / branding decision but also a practical decision about cost.
Note that XWiki also has its own layer of “framework”, even if it’s thin, here https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/FrontendResources/#HStyleSheetresources . We can maybe intervene on this layer with a bit of personality, or enrich the layer with additional elements and personality it but I really think we should try to remain aesthetically compatible within a framework, for reasons of cost.
I don’t think this is possible. We have color themes so at least the color of the buttons and other UI elements won’t be the same as in the framework. But it’s not just colors: we may want to use a different font, different margins, padding, border radius, etc. All UI design frameworks offer variables that we can and should use to make the XWiki UI stand out.
@mflorea we mean the same, I just used this vague term of “aesthetically compatible within a framework” without explaining it.
What I meant by this is roughly something along the lines of making sure that whatever changes we do on a framework, using a (new) component of that framework that was never used before in XWiki (and therefore not ‘audited’) should not yield a visual result where it’s visible that that component is not ‘matching’ the others.
Thus, all work on fonts, colors, paddings, borders, margins, as long as it’s done in a way that is compatible with the customizations that the framework admits and therefore applies to all components, it’s fine.
However, having customizations of the framework that implement XWiki’s personality that need to be applied individually to each component of the framework may result in work needed whenever a new component of the framework needs to be used in XWiki. For example, animating elements on hover to make them “react” would be such an example (we don’t want to do that, but I can’t think of a better example now): it can be implemented, and some work would need to be done for each individual component to decide how it will be animating and writing the CSS. Using a new component of the framework that was not looked at before (or one that was added in a new version of the framework) would need work to animate it as well, otherwise its behaviour won’t be coherent with the rest of XWiki, so that component would feel ‘off’, not implementing the XWiki personality.
I hope it’s clearer now what I meant by “remain aesthetically compatible within a framework” .
Yep, this all makes sense.
It seems like we are all pretty much saying the same stuff: stay close to a framework and implement small/ time-efficient changes that are cohesive with the entire UI