XWiki 10.x cycle roadmap

Hi all,

Here are some ideas I have about what XWiki 10.x could focus on. Feel free to propose your ideas and comment on whether you agree/disagree. This list is obviously not a commitment to anything.

Global Topics for 2018:

  • Fix inconsistence of WebHome appearing everywhere when using references in macros and API calls.
  • Autocomplete everywhere, especially on reference. Note: This would lessen the issue with WebHome.
    • Example 1: In object editor when the type is “Page Reference” + picker
    • Example 2: In WYSIWYG macro editor when a macro has a reference parameter + picker
  • More generally Improve WYSIWYG macro editor to make it really usable simply and without the need to type wiki syntax.
    • Idea: For macros having wiki content, let the user enter it in the WYSIWYG directly. When hovering over the macro allow editing content + have some icons to edit parameters (similar to the CKEditor easy image feature: https://github.com/ckeditor/ckeditor-dev/issues/932 They call it a “balloon toolbar”).
  • Navigation panel needs overhaul to be able for the user to blacklist nodes and control better its content
  • Performance improvement to go back and be better than the performances of XWiki 8.x (we’ve regressed in 9.x). Examples:
    • Especially focus on Navigation Panel perf since it’s an issue that’s been raised a few times
    • Test performance of notifications
  • More generally work on preventing the wiki from breaking. XWiki needs to be rock solid and not feel like you’re going to break it when you touch something. It should’t be possible to break anything (either we support it or we disallow it). Examples:
    • prevent deletion of important pages and spaces,
    • make it simpler to understand/handle merge conflicts during upgrades,
    • prevent or make moving applications work
  • Paying app feature in EM
  • Less navigation to perform things. For ex, inline editing and generally simplify edition flow.
  • Visible save (work started in 8.x and needs to be finished)
  • Skin refresh. No new skin since too much work but refresh of Flamingo

Top 3 priorities:

  • Autocomplete everywhere
  • Improved Navigation Panel
  • Performance

Smaller priorities:

  • Paying app feature in EM
  • Less navigation
  • Visible save
  • Skin Refresh

Thanks
-Vincent

5 Likes

Hi! Thanks for the message, Vincent!

Even though I’ve not followed the development of XWiki during these past few years, I kept using by using some old installations. I understand that to move this old installation to new ones running the newest stable releases won’t be an easy task, and that is perfectly understandable. But I keep thinking that, in general, the upgrade process is too hard to follow.

I would like to promote UPGRADE high on the Top priorities list. In your message, there is only one instance of that word upgrade when you talk about merge conflicts resolution, but I think that it deserves much more attention as the nice page explaining the process available at…

https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Upgrade

… depicts a hard time for anyone facing the process!

Once again, thank you so much for your work and for making this great toolscape available for the community!

Well, it’s been several years that we’ve worked on improving upgrades. Maybe your experience is from old installs?

I’m all for continuing to improve upgrades since I’m sure there’s more stuff to be done but we need help from you. Could you tell us what issues you’re still getting when upgrading to recent versions of XWiki and what you suggest that we should do?

Right now the hardest thing IMO is to merge default pages that you’d have modified and that are also modified in the distribution (normal since they’re default pages ;)). What we’ve done in 2017 is preventing their deletion and what we’re planning in 2018 is to make it hard/prevent users from modifying them so that there’s never any conflict when upgrading (obviously to the exception of some pages such as the home page which we’ll need to handle differently and make the user content have priority over the default content for example).

Keep the suggestions coming and very importantly with details of what should be done in your opinion.

Thx!

Thanks, Vincent!

I’ve recently installed a 9.11 release in my development box. I’ll upgrade to 9.11.1 and report back with new experiences!

Cheers!

Excellent!

Sounds good to me!

On my wish list I would like to see a few more page edit macros or widgets to help slicken the editing experience and make keeping a theme on large wikis easier. Don’t get me wrong, it’s already very good, and the CKeditor works nicely, but stuff like mentions (I know someone has already done some work on this), multi image layout, autoimage thumbnails, D3 graph macros.

I plan on tackling this soon on our instance, but thought I would mention it here as it would probably be useful to everyone using XWiki as a wiki, maybe not so much for websites.

About this one, there’s this extension that you could find interesting: http://extensions.xwiki.org/xwiki/bin/view/Extension/Chart.js%20Integration/

Hi Vincent,

Thank you for this feedback. I think that Interoperability between apps is the key of success especially in collaborative tools.

So I would love if XWiki will be more integrated with Jira, with more specific Jira extensions like sprint burndown chart, velocity chart, etc.

Thanks

I’ve tried hard to do this one several times but it’s very hard to find info about this on the JIRA side. It seems JIRA partially implement the long-deprecated opensocial spec from google and that XWiki would need to implement it too in the same manner for jira gadgets to work in XWiki.

I’ve created https://jira.xwiki.org/browse/JIRA-23 to keep track and continue the discussion. Thanks.