The simple but honest main reason for our organisation (>400 office workers) to start integrating XWIKI is that we are not allowed to use cloud products and XWiki seems to be the most promising Confluence on-premise alternative in terms of user friendlyness (for “normal” everyday office users!!). Atlassians datacenter prices are not acceptable for us currently - but that will probably depend on how our users will accept XWiki.
In our organisation we in the IT department have quite the decission making capability and decide which exact solution will be implemented. The organisation wants an user friendly modern Wiki solution - we in the IT department decide how we fulfill that desire.
For making the willingness to integrate XWiki much higher, standard convinience things especially coupled with Windows Active Directory environments should become much easier and much better documented.
In my opinion it possibly scares it companys away, that to implement stuff like SSO they have to bring in external consultant companys just to build / configure SSO into XWiki. I understand fully that XWiki needs funding, but during the “demo” phase of testing possible solutions things should be easy as possible and costs should be low. But when companys are confronted very early on with quite some costs to implement convenience things, that are very often considered as “standard” by todays measure, people start to wonder why bothering with it at all instead of just simply using a wider known commercial solution.
We had exsactly such discussions internally and for exact this reason and to not kill the project, we decided to start our XWiki with the default XWiki authentication and without Active Directory coupled SSO and accept that this inconvencience will probably lead to less people tring and using XWiki. If our users are accepting XWiki in the long run, we will probably invest into things like SSO and so on, but this approach will definetly slow things. I as the admin am currently not feeling that the current SSO documentation would lead me to successfully configure SSO in a acceptable timeframe.
But what im most afraid will be keeping our users from actively using XWiki is, that even though the editing is in place WYSIWYG, many macros feel extremely fiddling to use and not at all “seamlessly” integrated.
As negative examples: The inline tasks of Task Manager (Pro) and many other macros feel like unfittingly thrown into the Editor: Super strange borders arround the macro, not at all “flowing” with the Text, users have to set where the stuff gets stored and so on.
In my opinion it is absolutely acceptable that very specific macros that are targeted to very “techy” people are not super convenient to use, as “techy” people will probably understand and accept how to use these macros anyways. But macros that are meant to be used by “normal everyday office users” should be super easy and fool-proof to use and feel seamlessly integrated into the editor and XWiki.
As positive examples:
The quick actions and the Mentions are very good changes to XWiki compared to how things were back a few years ago when we compared XWiki to Confluence Server. They now feel very good and quite “seamlessly” integrated. Also the design of XWiki keeps getting more modern and better, even small simple things like flattening the button design in 15.8 or changing the corner radius in 15.9 are improving the look very much and are signaling XWiki is getting better and better.
The most wanted feature for our users in XWiki definetly would be an stable realtime WYSIWYG collaborative editor, prefferably with in place editing.
In the long term also a modern block editor would be very nice - but it also should offer realtime / collaborative editing.
I don’t think XWiki really needs to put too much effort into advertising. If an (open source) software feels very good to use, the advertisement will be done by the end users themself.
