XWiki 12.10.2 - introductions & image editing userfriendlyness suggestion

Dear XWiki folks,

To introducte myself: being a big fan of wiki’s, I was using Confluence privately for notes, as in the past I’ve done a professional projects to tune it to clients needs and my employer uses it as well.
What has drawn me to XWiki is that their company recently announced to adjust their pricing to exhorbitant heights and as a result I decided to see if XWiki is the equaly amazing wiki I got as a first impression.

Having installed it I feel there’s quite some things better then Confluence: the advanced and simple user modes is absolutely amazing, design wise the breakcrumbs and the design looks more smooth, the way the page scales is better and the inline editing functionality is a great plus.

Getting used to XWiki however, I did sincerely miss one piece of functionality that will hopefully be added at some point in the future: on the image baloon toolbar I can’t find buttons to resize images to Small, Medium, Large or Original size with one click. Currently resizing is always at least three clicks away: (1) a dialog needs to be opened (2) you need to choose a size (3) then you need to confirm. I used the one-click functionality a lot and find it hard to live without.

Working my way around the absense of default image-size buttons, I found it very hard to determine image sizes, as XWiki doesn’t always show the original image size in the dialog window I have no reference values. For this I spend a day to write a piece of code myself that adds these regardless:

require(['deferred!ckeditor'], function(ckeditorPromise) {
  ckeditorPromise.done(function(ckeditor) {
    ckeditor.on('instanceCreated', function(event) {
      // The editor instance was created but it not yet initialized. Unfortunately the configuration object passed when
      // the instance was created has not been merged with the global configuration yet.
      event.editor.once('configLoaded', function(event) {
        // The editor configuration has been loaded (the instance configuration has been merged with the global
        // configuration) but the editor has not been fully initialized yet so we can modify the configuration.
		event.editor.on('dialogShow', function(e) {
			var dialogName = e.data.getName();
			var dialogData = e.data;
			if (dialogName == 'image2') {
				var dialogModel = e.data.getModel();
				//If no width and height is shown, enter it:
				if ((e.data.getContentElement('info', 'width').getValue() == "") && (e.data.getContentElement('info', 'height').getValue() == "")) {
					//Set the height and width, it will get adjusted by the plugin:
					dialogData.getContentElement('info', 'width').setValue(dialogModel.element.$.width)
					dialogData.getContentElement('info', 'height').setValue(dialogModel.element.$.height)
				}
			}
		});
      });
    });
  });
});

For attaching this to XWiki, I used the method of attaching this as a JavaScriptObject, that the fix for external links not opening in an external window also uses, e.g.:

As you’re aiming at an easy XWiki UI by default, perhaps the addition could be considered as an contribution to the XWiki project, if you also agree it’s more userfriendly ?

PS: I didn’t try to change the image balloon toolbar, as this was too challenging, though if I’m going to move forward with this later, which option is preferred to contribute such code to XWiki ?

Awesome :slight_smile:

Sounds great. I’ll let @mflorea comment since he’s the one who knows the WYSIWYG editor the best.

Also letting @mflorea comment on this since I don’t have expertise here.

The feedback you started providing, comparing XWiki and Confluence is great. I’m very interested by that.

We have also tried writing a comparison page at https://www.xwiki.org/xwiki/bin/view/Compare/XWiki-vs-Confluence/ but we’re not Confluence experts so maybe you could help us improve it even more? Or at least give us ideas to improve XWiki over Confuence.

Thanks!

Hi,

I agree. Would be good to report an issue on https://jira.xwiki.org/projects/CKEDITOR/ . The code for the CKEditor Integration is here https://github.com/xwiki-contrib/application-ckeditor where you can see there is a custom ‘xwiki-image’ plugin that enhances a bit the standard image2 CKEditor plugin. So the improvement to show the original image size should go in there.

Regarding your solution, I would rather use the placeholder attribute than the value in order to avoid having the original image size saved within the wiki syntax.

The image balloon is configured by the xwiki-image plugin I mention above. Adding new buttons on it is relatively easy:

  • first you need to define 4 commands: image-small, image-medium, image-large and image-original. When any of these commands is executed it sets the size of the selected image (if any) to the corresponding value (percent).
  • then you need to define 4 buttons that would call the previously defined commands
  • finally you need to add the buttons to the image balloon

Pull Requests are always welcome!

Thanks,
Marius

@vmassol
We have also tried writing a comparison page at https://www.xwiki.org/xwiki/bin/view/Compare/XWiki-vs-Confluence/ but we’re not Confluence experts so maybe you could help us improve it even more? Or at least give us ideas to improve XWiki over Confluence.

Happy to hear my comments provided some valuable insights. Perhaps I can continue to share about a few features, that - coming from a Confluence background -, worked a bit unexpected. While most of these points felt like rough edges that I could get used to, I hope it helps to get ideas on where there’s room for improvement.

First I would like to share a few more definite plusses that seems to be missing in the overview. There are things I noticed having spent a bit more time with XWiki:

Image resizing:
XWiki actually resizes the images before transmitting it, which saves bandwidth, while Confluence always transmits the original image in full size and performs client-side resizing.

Maximum page name flexibility:
XWiki allows multiple pages with the same name to exists, which means you can create the following hierarchy:

  • Toyota
    • Model
  • Porche
    • Model

In Confluence this would have triggered the error that the page “Model” already exists.

On the points of what I struggled with and where there might be some room for improvement I have the following three to share:

Image click zoom:
This is a matter of personal preference, but Confluence by default has the option to click on a picture to zoom in on it. The only time I considered this a downside was when building a website with Confluence, during which I had to perform some tweaks to turn it off. For normal “wiki”-use I find it a great upside, as it allows to easily fit thumbnails of pictures in a page, which the additional option to zoom-in with one click when you need to see more detail. It’s probably still possible to see the original in XWiki, but its more clicks and less intuitive.

I noticed there’s a PRO plugin that seems to provide the zoom-in as well, but since I’m using XWiki for personal notes, the PRO package is way out of budget and hence I’m unable to comment on its quality. Perhaps the guys offering the XWiki PRO package could consider to introduce a low-budget - up-to-10-users license - for this package?

This could even be a way to enhance market share: offer such a bundle to small companies that don’t have budget anyhow. If they grow in FTE and profits, they will likely simply upgrade to a license with more users, which they can afford at that time

Navigation expansion:
In XWiki navigation gets limited by an x-number of entries, after which you have to ‘click to expand’ to see more navigation entries. The advantage I see in the XWiki approach is that it enforces users to break down content in manageable chunks, however it would be easier to migrate if the administrator can decide from what point onwards there’s simply too many navigation items.

My habit previously was already to break stuff up, but apparently I had a higher limit in mind, as I’m still confronted with the ‘expand to see more’ in XWiki occasionally. If the amount would be configurable I would even view this part to be “better then Confluence”, as the latter has no functionality to address excessive hierarchy creation.

Navigation sorting:
I had a few pages named the following (with numbers to influence their order).
= 1. Page one
= 2. Page two
= 2b. Page two bee

Somehow in XWiki page 2b now comes earlier then page 2, which is a little strange.

Similarly I used to name a page _Home. Due to the underscore it then came on top. XWiki seems to ignore punctuation characters altogether when sorting however.

Are there any tricks to influence sorting in XWiki ?

PS: What might be additional interesting to share on sorting, is that there seems to be an ISO standard created for it: ISO/IEC 14651. Several databases have implemented collation & sorting based on these. A project PostgreSQL borrowed it’s collation implementation from is: http://userguide.icu-project.org/collation, which uses the Unicode Collation Algorithm (UCA) (Unicode Technical Standard #10). The advantage of going in this direction would be that it’s possible to customize the way sorting is handled across what countries expect for their alphabets. I’m not sure if apart from ignoring punctuation XWiki already follows such standards, but if not I would recommend it for internationalization efforts.

@mflorea
Pull Requests are always welcome!

First off, thanks for the advice you shared, perhaps I’ll still give it a try somewhere later if I manage to find some time. The steps pictured help quite a bit on what the focus on in the solution, as the documentation of the editor is quite an ocean.

@mflorea
Regarding your solution, I would rather use the placeholder attribute than the value in order to avoid having the original image size saved within the wiki syntax.

I see your point and I do agree that if the “default image size”-buttons would be there, the placeholder attributed values would probably be the better solution.

Without the buttons however it doesn’t cover the use-case in which one wants to ctrl-c a particular image size value and then ctrl-v it to another image on the same page, which is what I currently do as a workaround.

Probably time-best-spend would be to focus on the final solution with standard-size buttons and have the placeholder attributes. An intermediate best-of-both-worlds-approach I could still think of, is to extend the current workaround with an “OnSave”-filter that removes the sizes if they’re the same as the original. Would you agree that would indeed be better, or would there be a use-case in which it would be useful to have the original sizes explicitly defined?

Thee are great to know, thanks. We always hear the elements where we’re less good but a lot less often where we’re better so it’s great to know that too :wink:

I think this is the case (would need to ask XWiki SAS company which is separate from the open source project here), as I remember that XWiki SAS have prices depending on the number of users. Which plugin are you thinking about? Also note that XWiki SAS pro extensions are open source and can be built from sources if you have the technical knowledge. Now for a feature such as zoom-in, I’d personally be happy to have it in XWiki Standard by default.

We could make that configurable maybe? I guess the rationale is that the less number the faster the page loads.

Feels strange indeed. Maybe raise a jira bug issue about this.

Maybe open a jira improvement issue for this one.

Thanks a lot again for your feedback, keep it coming :wink:

You can increase the number of navigation entries for document tree based elements. Take for example the Navigation Panel. Open the panel page (<SUBWIKI>/view/Panels/Navigation). Click Edit (confirm that you will be Force Editing) and scroll to the bottom of the Content field. In the document tree macro call add the parameter limit and set it to the maximum number of child pages that should be displayed. Click Save & View.

Before:
{{documentTree showTranslations="false" showAttachments="false" compact="true" openTo="document:$openToDoc" exclusions="$exclusions" /}}

After (we use a limit of 100 elements):
{{documentTree showTranslations="false" showAttachments="false" compact="true" openTo="document:$openToDoc" exclusions="$exclusions" limit="100" /}}

I haven’t tried to change the number of entries displayed in the breadcrumbs dropdown so i don’t know how you would proceed there.

1 Like

Maybe the (open) Xwiki feature request 1. XWIKI-16453 “Provide Some Explicit “Ordering” for Pages and Sub-Spaces in a Given Space” might be interesting in this regard.