These are meeting notes of an internal meeting with:

• Ludovic
• Clément
• Marius
• Manuel

Day 1

Goals

• Update on the Research Project funding
• Come back on the discussions from February
• 3 meetings on Wiki 3.0
• Dual project goal
  • Solve an issue specific to XWiki : separation of front-end / back-end
  • Take this opportunity to create a modular software, that can be integrated with something else than XWiki
    • Talk from Jitsi at FOSDEM on modularization ; see video from 44mins to 46mins : https://fosdem.org/2022/schedule/event/rtc_jitsi/
    • Success of OnlyOffice has been built on a modular component that gets integrated in other applications
    • Goal : have 1 component on wiki edition that we master, with the capability to integrate with multiple storage backend
      • The UI exposes capabilities that are supported by the backend (eg realtime editing, notifications, structured data, …)

Long term vision

We need to also consider the needs of our current clients towards XWiki, especially the need to be able to easily customize the interface ; change (add / modify) specific features, ...

• It can be interesting to have a system similar to the component-based architecture that we use today in XWiki to provide this flexibility
• It's not sure if having the same level of customization as XWiki is that important, however it's important to think about the fact that at the start of XWiki, this capability to answer specific needs of clients was really interesting to get early business

As part of the project, take the opportunity to build more on standards : focus on having components that rely on existing, proven standards. Don't try to create new standards (was done in XWiki, because at that time no standard existed for some features).

• Example of JSON-LD (https://json-ld.org/) and SOLID (https://solidproject.org/) which are interesting standards for handling structured data

The idea of having different backend will provide quite some challenges for some features

• E.g. querying the backend
• Search (potentially need to have local − client side − search if the backend does not support server side search)

Extensibility : the extension system in XWiki is interesting and provides flexibility. There can be an interest of thinking about the extensibility of the Wiki 3.0, both on the front-end side and the back-end side.

Separation of content vs code : while still being able to quickly edit the code of an extension ; have the code stored in a different place than the content (currently, it's a big issue with XWiki and custom projects)

• Option to consider Git as a standard way to store extensions : having 1 git repo = 1 extension
• One of the goals to separate contents vs code is to solve the current issue that we have in XWiki where upgrades are actually modifying wiki pages (some of which can be content)

The idea of multi-tenancy : possibility to have, from 1 UI, multiple storage backend

Some other things to look / think about :

• Realtime by default ; currently important from a user perspective
• Design : currently lacking in the team, one of the big challenges will be to find a designer

Questions of licensing

As part of the research projects, we agreed with the consortiums to provide the wiki30 as a re-usable component in their proprietary solution for at least the duration of the research project.

It means that on the short term, we'll probably have to license the project under a permissive license. Then we can revise this afterwards (question of how to change the license ; cla ?)

Questions about the syntax in which we store the content

Ludovic : use Markdown ; or a derivative which is bijective with HTML ; the use of Markdown is interesting as it's standard.

Buuut, need to be compatible with XWiki syntax (at least on the long term). Two options for supporting multiple syntaxes :

• Either have the parsers / renderers of the different syntaxes we want to support be available client-side
• Or have the backends be able to parse / render syntax

Using scripts within pages

With the separation of code / content, not possible to include a script within a page directly.

• Possibility to have either the front-end or the back-end automatically create a separate "module" distinct from the content of a page to store code seamlessly, when someone is editing a page
• This would help keeping the same user experience as what we have today in XWiki, where a user has the option to include a piece of script in a page easily, however we make the process of creating a separate space for the code seamless

Important to think about indirections in the page data

• The page name is an attribute, the page can be identified by an ID, which is not based on its name
• Same idea if we ever have to define the equivalent of XClasses

Question of using the wiki as a development platform : create / edit extensions directly from the wiki

More long term ; maybe we don't need to develop the extensions directly from the wiki UI if the wiki doesn't bring additional value.

What is interesting is to have a fast turnaround time for developers to go from writing code to actually be able to view the results in the wiki30 front-end. ==> Make the development more smooth where a development instance is able to automatically reload new code whenever a change is being made.

On the even longer term, we would need to think about this same process, but for extensions developed on the server side.

On the topic of security

• Separate the role of a user vs the role of a developer

Think about the separation of roles

Rights are actually very dependent on the backend. We could think about having the possibility to have the option to add rights coming as an extension.

With XWiki, we've seen that storing rights with the content can cause issues.

On the short term, we could think of a very simple wiki, where everyone can edit ; there would not be any specific notion of rights initially, even though it could come up later.

On the topic of editing

The question is to choose whether to go with a WYSIWYG editor ; or a block editor (à la Notion)

Open question for now

Projectional editor: https://martinfowler.com/bliki/ProjectionalEditing.html : possibility to have 1 way to store data, than can be then projected into different views

If we have block editing ; should we still be using Markdown ?

Wiki.js provide choices between different document formats Markdown, WYSIWYG (HTML), and then you can convert between compatible formats.

One option is to have documents that start with markdown, and as soon as they become more complex (start being edited as block), then their syntax is switched to something more complex complex (maybe including json, …)

On the topic of contents we actually put in the wiki

The idea is that a wiki is a set of pages, a page can be many things :

• Text
• Block page (à la notion)
• An office document ?
• A diagram

So we could have different "types" of pages, each type can refer to an office doc, a diagram, or contain some content like what we have today in XWiki

Next steps

• Try to think about the behavior, the usage of the wiki
• From the POV of the following personnas, how would the integration go
  • User
  • Administrator
  • Integrator (someone that wants to integrate Wiki30 in a new platform that currently does not support it)
  • Developer
• Get to write some user stories
   

Day 2

Projects to integrate with:

• Nextcloud
• Jalios
• CryptPad
• XWiki

Other platforms frmm the research projects :

• Jamespot
• Wimi
• Twake

Other platforms to think about :

• Bluemind ?
• Matrix / Element
• "old school" intranets / websites

NextCloud

Option to either provide Wik30 as an editor of files or as a dedicated application (like Calendar / Notes)

If dedicated application, important to focus on the standard on which Nextcloud works for storage (WebDAV), so that we don't enter the specifics of Nextcloud APIs

For storage, issue storing content in the same folder as an existing content (example with the Notes app using the Notes folder to store its contents ; this folder could already be used)

Question : when accessing a content, should it be directly editable, or should we go with the "transactional" way of editing that we have today in XWiki, where we are accessing content in view mode, and we need a user action to switch to edit

Important to have the UI not crowded by default by editing tools (done by default in Notion). Users will prefer a transactional way of editing, while others won't.

Another issue when having content directly editable :

• Management of the history
• Management of who is saving a document version (being marked as the version author in the history), when users are in a realtime editing session

Notion of workspaces (from Notion) : could allow to manage multiple backends

Let's try to write some user stories :

Entry point :

EP1 : As a user, I am able to load the UI of wiki 3.0 from a website. This website won't store anything in its backend. It is just a server that serves the javascript resources necessary to run the application (similar to element.io web app)

EP2 : As a user, I am able to load the UI of wiki 3.0 from an application that integrates wiki 30 : eg. Nextcloud, CryptPad, … . This UI will be automatically configured to be connected to the backend from which it was loaded.

EP2.1 : As a backend administrator, I am able to allow or deny users to configure the wiki 3.0 to work with backends different than the one I am providing

EP3 : As a user, I am able to download a heavy client containing the wiki 3.0 ui on my laptop (similar to element-desktop)

Backend configuration :

BC1 : As a user, I am able to configure my wiki 3.0 to connect to a specific backend by providing a URL to this backend

• From the URL, Wiki3.0 is able to infer the type of backend

BC2 : As a user, I am able to configure my wiki 3.0 to "create"

Question : nested workspaces ?

Separate the notion of "Backend" and "Workspace"

• A backend is really the server you are talking to, a backend can have multiple workspaces
  • Could be similar than the notion of "servers" and "spaces" in Matrix
  • Backends could potentially provide a list of available workspaces (discoverability)
• A workspace is a logical entity stored on a backend
• Could be nested workspaces (if we consider the workspace selection as a tree), however it's a challenge to make it easy to understand in the UI

Question : is the notion of "backend" too technical for a user ? Ie : not to be seen by the end users

Wikis could be potentially very open (allow incoming / outgoing links from other wikis) ; other wikis could be completely locked --> It depends on the choice of the administrator

Adding new pages

* Could a page in the tree be just a file (no to be mistaken with the office import we have today, it would be just a file)

Difference between the

Thoughts on Notion :

* Page creation through a modal ; asks only for extra steps when needed

* A lot of UI components not shown by default to give more space to the page (which can contain complex content) : comments accessible only through the click of a button. Could be the same approach for rights.

Thoughts on Wiki.js :

* Content disposition : the content is shown a lot to the right of the wiki

* Administration : dashboard showing the status of the wiki as a whole on the admin home page (last docs modified, number of users, …).

* Also the localization part shows the percentage of translation coverage.

* "In place" extension install : when going in a category of the administration, like "Analytics", I also get a direct way to install analytics related extensions (along with the different configurations of the extensions already installed)

* Multiple deployment options

About history support : depends a lot on the backend and the storage mechanism : some backends will be able to have very specific history, while others won't support history at all

Minimum viable product :

• Be able to create new pages (simple pages with title and content)
• Be able to create links between pages
• Be able to save pages on 1 supported backend
  • Implies that we need to be authenticated with the backend
• Be able to display a navigation tree that allows to switch from one page to another
• Be able to show who is editing a document in the UI (the author)
  • Get an information about the user identity from the backend
  • Show it in the UI
  • Use this information to save the contents

Search comes later

Day 3

Going back on the MVP of last time ; adding some technical points

• Have a decision on the fundamental technology choices in which the client will be written
  • VueJS ?
  • CSS / Design framework ?
  • Accessibility requirements ? Design system ?
  • Testing framework ?
• Have a decision on the way we handle documents (document format) in the wiki
  • Have a decision on the syntax that is being put in place in priority (Markdown ; but which flavor ?)
  • Have a decision on how we handle the data model (JSON-LD ?)
  • Have a decision on the global principles behind the API
• We also need to consider having at least 2 backends integrations, in order to make sure that we are creating APIs "the right way", to avoid having APIs created just to ease the integration with a specific backend
  • Eg : XWiki ; NextCloud
• Packaging : targeting the desktop application ; allows to add a feature to existing XWiki users (we don't have electron clients for now)
• Try to find a proper name

On the other long term requirements

• Have an option to display external documents, that could not fit with the data model of wiki 30 in a "failsafe" mode, eg through an Iframe
  • Would be interesting with XWiki pages containing velocity for example
  • Would be interesting when migrating users to wiki 30
  • Important to see quickly if this feature would be really doable, as it will be important to decide how Wiki30 it to be introduced to existing customers / to the market

Design system

Abstract as much as possible some UI components so that they are easier to update

Look to already existing design systems

• UK
• France

Architecture proposal :

• Focus on Javascript clients
• Javascript wiki API that communicates with any backend through HTTP or through any other protocol
• Then, javascript frontend (modular), that communicates with the javascript wiki API directly in JS

Diagram

Timeline / next steps

Currently, we're waiting on the results of the research projects

Question of choosing how the project is integrated with the XWiki community : for now, it is interesting to start from within the XWiki community as we already have some tools / processes.

Code names for the project / for each release : to be thought about

References of platforms to look into

• https://crypt.ee/
• https://skiff.com/pages
• https://startinblox.com/en/