Default Wiki Improvements (1.x)

Last modified by Vincent Massol on 2024/02/26 17:54


XWiki is a platform for building wikis. Our default Wiki is a demo wiki showing what can be done with XWiki. We need to improve it so that it can stand the competition with the nicest wikis available out there. Here's a list of things to improve to get it on par.

All related JIRA issues: XWiki Enterprise User Experience Improvements

Better navigation.

It's really hard to navigate and have an overview. Some ideas: 

  • Redesign/reimplement the AllDocs page including the drag and drop treeview to reorganize pages and spaces. Note that the treeview widget iself it also needed for the WYSWIG editor.
  • Redesign/reimplement the old navigation panel using the new Treeview to have something like that:
  • Ensure that when you make an action you go back to the current page after the action is executed. For example, if you are on the AllDocs page and you click on edit page for a page in the list, once you have finished editing the page you should come back to the AllDocs page. Same for lots of other cases.

Redesign the home page

The home page is the first page users see when they arrive on the wiki. Thus it plays a key role in letting users finding their way through the wiki when they land on it. As of today, the homepage has very little value in this process unless it is customized by the wiki owner.

  • List existing spaces on the homepage (this would require hiding special spaces)
  • Edit content to match the main steps that a brand new wiki user would want to take to get it started
    • Link to add users
    • Link to edit rights
    • Link to change the skin
    • Link to create new pages

Redesign the tags page

Tags are currently underused as a way to classify information in XE, partly because the interface for adding and browsing them is poor. The interface for adding tags has recently been improved (addition in view mode though the new footer). However, the interface for browsing tags is really sober (an alphabetical list of words).

  • Use a tag could to display tags
  • Write the number of entries next to each tag
  • Optimize the tags page for performance
  • Make tags even easier to add through the footer

Item Creation

Improved Page Creation

Right now, page creation can take place using at least 3 different methods, each with its own advantages and drawbacks:

  • By clicking on a "wanted link"
    • PROS: this is the standard wiki way, it automatically fills the "parent" field
    • CONS: not intuitive for users that have never used a wiki before
  • By using a creation form (Page creation form available in a panel, creation forms available in various applications such as the blog)
    • PROS: easy to understand for new users
    • CONS: tendancy to create orphans pages & pages without parent
  • Programmatically, through an API call
    • PROS: useful for developers
    • CONS: has no direct impact on most users

To summarize: the user can either create a new page easily but it will lack context, or she can create a new page that fits in the wiki structure but doing so is less intuitive for new users.

For me (Jerome) the new UI for creating page should :

  • Guide or force the user to choose good wiki name for their pages. (i.e. something like "LeSongeDuneNuitDete", not "Le+Songe+d'une+nuit+d'été" - though I agree it first mean we have to define what we consider being a good XWiki page name. I think no special chars + no spaces is a good start).
  • Make it clear what will be in the URL, and what is going to be the title of the created document. For this, we can for example have two fields, the first one being the page title, and the second one the page name, computed with rules we define as the user type in the first field (but leaving him the possibility to change it, still) 


Improved Space Creation

As of today, spaces are created when a page is created in that given space. This means that there can be spaces that do not have a WebHome nor a WebPreferences page. 

  • Create the WebHome & the WebPreferences page automatically upon space creation

Improved object creation

There is no standard way to add objects in view mode. Each time we create a new application we need to provide a custom interface when it comes to adding objects in view mode. Examples include ratings, tags, comments, blog posts... JV has a great proposal to make object edition part of the normal edition mode some time ago, we may want to look at it again.

Improve the current UI

The current User Interface (not the skin) has evolved very little since its inception 2 years ago. The only noticeable difference has been the refactoring of the wiki's footer. A number of ideas could be given a try to make the wiki easier to use overall.

  • Remove the top action bar and make action button closer to the content.
    • Right now, users have a tendancy to click on section edition buttons rather than on the edit button located at the top left of the page since they're way easier to see.
  • Have the edit button always visible but ask to log-in/register if not logged in for wikis requiring logging it to edit
  • Change the default Fonts.Most people do not customise the default install, and in my view, the default font sizes for h1, h2 etc are too big
  • Add a background color to the rights table to show the inherited rights settings that apply to empty checkboxes

Easier Menu Customization

  • Make it easy to find the Panels space. Right now users can find the panel wizard in the administration console but there isn't any link towards the Panels.WebHome page per se.

Improved Search

With navigation, search is one of the 2 most important ways for users to find the information they're looking for in the wiki. Therefore we need to offer a search interface that's easy to use and lets people find what they're looking for.

Right now there are 2 interfaces available for searching: the standard SQL one and the Lucene one. The SQL search only offers exact matching for queries and can be quite performance-consuming on big wikis. The Lucene search addresses these concerns through an index and a richer query language but it requires mastering a specific syntax. Lucene search also adds relevance sorting where SQL search lists results in a random order. Offering 2 potential search interfaces is perturbing for end users, specifically given both of them do not necessarily return the same set of results. We need to standardize on the most performant one and make sure it works fine.

Other issues with the current search implementation are the fact that it is hard to extend. For instance, once the ratings application will be ready it could be interesting to add sorting / filtering depending on the page rating. Right now this is very hard to do.

Rich search options has been highlighted as an interesting feature by one of our customers -> ability to write boolean queries. Are those available in the Lucene search?

  • Improve default search
    • Allow users to build up a search pattern (adding multiple search criteria). (should work with the Lucene search)
    • Search in rendered content (maybe with an option for users with programming rights to search in scripts)
  • Make the Lucene search the standard one
    • Use Compass to make the search page more google-like and remove the need for the specific Lucene syntax
  • Choose a results display interface
    • Do we want to keep the current grid view or do we want to go more "the search engine way" and provide a google-like results listing?

Quick Access Feature

We could implement a feature similar to the one available in JIRA, facebook & spotlight: when typing in the search field, a list of suggestions appears below the search input field. Suggestions are displayed as you type, so additional characters entered trigger fewer results. The list can be navigated using up & down keys. Hitting enter sends the user straight to the relevant page.

This would make seaching for specific items faster. Additionaly, it would turn the search into a quick access tool.


  • Reloading entire wiki every time you select a different page is bad over long distance VPN lines (and slow internet connections).
    • This doesn't look a Default Wiki issue but rather something in the core. Do you have an implementation idea? --VincentMassol
  • Improve documentation to show how extendable XWiki is, without extensive sweat over the details. Better documentation of the API is a must.
    • This doesn't look like a Default Wiki issues but rather a documentation issue --VincentMassol
  • Improve PDF formatting to show what the user sees on the screen.
    • This not an issue with the default wiki but bugs to be fixed :-) --VincentMassol
  • Easier housecleaning (deleting old/erroneous classes/properties, etc).
    • This also looks like a general XWiki improvement not targeted to the default Wiki, is it? --VincentMassol


Get Connected