This is a very interesting discussion. Thanks for bringing it up. Don’t hesitate to post the link to this response in the NextCloud forum. Hi to NextCloud devs ! We love what you do.
The first thought here is that the difficulties there are with office files, is a big reason why Wikis have been created. Office files tend to push user towards a system that is centered around the individual user versus the group and which does not allow to properly link information and also to categorize. The file format itself does not include the features that bring the documents together and the most tools that work with office files are trying to answer the need of editing, storing and sharing but not as much the need of categorizing it.
Wikis have been created trying to take the problem from a new standpoint, based on the fact that we have new technologies available like browsers, online editors, databases and so on. A wiki is an online system which allows anybody to edit documents and link them between each other. A key aspect of wikis is that it should allow to quickly go in edit mode, make a change and save.
Now the issue is that:
- users still have a tremendous amount of office files and habits of working with them
- office file editing is very rich and this is compelling when you are doing more advance things
- offline editing seems more easy as you have offline tools and conflicts are not taken into account (which can work when document are more user centric instead of group centric)
- integration between the wikis and office files and between wikis and office files management tools is lacking
- office file management tools have been becoming more collaborative trying to answer some of the problems listed, however they have not solved all the issues and some of the issues will be very hard to solve as they are contradictory with features of these tools (for example: while having tons of editing features is nice, it goes in the way of fast & easy editing)
In the end there is a sort of competition between wikis and office files, and depending on the use case one if more appropriate then the other. It would of course be super interesting to improve the integrations between the tools.
So first it is important to choose the right tool for the task based on the objective, and then second see how to connect to tools if it makes sense to do it.
If the main use case is creating documents and sharing them one by one, I would tend to go for office tools.
If the main use case is documentation or procedures or management a set of knowledge and collaboratively edit it and organize it and then make it nicely browsable and accessible, I would clearly go towards a Wiki.
I’ve created XWiki because I believe we need new ways of collaborating and the office file not adapted to these new ways. New ways to organize the content and group it together are needed. Unfortunately standardization is very hard in this area and big players are still going the office file way (Microsoft & Google).
Now XWiki’s goal is to capture & organize information. It is not said that all editing tools and content should be in XWiki and organizing content that would be stored and editing in other tools make sense to the goal of XWiki. We have Office365 and Google Apps plugins allowing to display files from these tools, and doing with other tools and in particular NextCloud would be very interesting.
So now how to treat your particular use case and how could it be possible to solve your problems and as well make the tools work together. I’d like to point out that I would love if we could make the XWiki & NextCloud tools work better together. If there are any companies that are ready to sponsor this work it would be great and we would be happy to do this in collaboration with NextCloud which I believe would be necessary because our initial studies of integrations show that there might be missing APIs and functionalities for such integrations to work well.
Let’s look at your issues and problems and how these could be solved:
Indeed. Office editors are more advanced for spreasheets. This could be improved indeed in XWiki.
Now in XWiki you can also create databases using App Within Minutes which can give more structured content which can be very useful for documentation.
XWiki also have OnlyOffice integration to edit office files, including XLS. We chose OnlyOffice because we are also using this technology for CryptPad, because it is full Javascript and allows us to encrypt the collaboration which would have been impossible with Collabora CODE. It’s true that Collabora has more office support as it’s built on top of LibreOffice. Integration would be possible in order to have a choice. It’s significant work however which is why it hasn’t been done yet.
Indeed, offline Wikis would be nice, but given the more active collaboration on Wikis it’s a significant problem. We can’t expect that the majority of editing will be only one user at a time, which is what offline support of office files in most tools is assuming. Conflict management is all or nothing.
Wikis are made to be more realtime… “What you see is what you get”, and assume you always have Internet. It’s hard for us to choose… spend our effort towards realtime or support use-cases that are slowly going away.
Indeed, but XWiki also allows scripting on the database and you can manipulate the data in the system. If you go for structured data, you will have this ability. It is not manual though which is what folders and files allow…
Here the key point is that you get all this from file management, because file management lacks all the interconnection and metadata features. It is more complex to provide in Wikis because you have them.
If you move to Wikis it should not be to replicate files and folders.
Indeed, and this is something that could be improved in XWiki. We’ve talked about the “sharing” URL. We have even talked about a “CryptPad” extension as it would also work with Wikis behind the firewall, but still allow sharing on the Cloud in an encrypted database. If we did this we would get all the features you are mentioning (passwords & limited lifetime).
We’ve talked about allowing Drag and Drop in the tree. This would be nice to help in this area.
It’s supposed to be more advanced, but we noted the bug you have. It’s been introduced by an improvement we did to protect from editing through different methods and we failed to take into account attachment uploads. In XWiki 11.4 we now have a much better method, so we should deactivate the protection in the realtime module. We will look into this to have a version that works well with it and also a version where you can deactivate this feature all-together for older versions.
This is one of the key reasons to move to Wikis is the basis of the differences between files & folders and Wikis, but it’s not the only one. In addition to linking, the choice in Wikis is to allow simpler editing (less features in the editor). It’s actually a choice not to have all the office bells and whistles in the editor. It allows users to focus on the content itself. Users tend to over-focus on the presentation which can go in the way of having actual valuable content. Another aspect is that you have an unbalance between the skills of users at using Office capabilities and some will use it and other not. This leads to some users not participating to documents of other users. In Wikis the objective is to favor collaboration. The key elements for this is to be simple and fast. Now it’s interesting to have better presentation methods for content in order to help readability and also ease editing. The approach in Wiki is to go towards either macros in Wiki documents or towards structured documents with metadata. This makes it much easier and faster for people to make nice documents. XWiki has a powerful macro system which allows you to build your own macros.
Yes this is a serious difficulty a lot of users face. What we suggest in this area is:
Option 1/ Import the office documents and transform them to Wiki pages, which will allow interlinking
Option 2/ If this is not a good solution because the content is very rich, import the documents in a structure data page which would contain meta-data that represents the office documents (categories, etc…) and attach the office file and use the structure data view to insert an office viewer for the office documents. We have also in the past converted the office files to PDFs before attachment them which creates a more consistent user experience but means the documents are not editable.
Option 3/ Keep the documents in NextCloud and create the structured XWiki page that would link to the NextCloud document and possibly add a NextCloud viewer and buttons to collaborate in NextCloud (see later, but unfortunately some tech is missing for that). It could also be possible to automate the Wiki page creation from the NextCloud files being in a specific folder.
This can be done with the batch import tool and creating an excel file representing all documents and including their metadata. The batch import tool can import the office files as attachments and the excel columns are matched to AppWithinMinutes fields.
I see your problem here with 2 different tools. At this point the office editing in XWiki is OnlyOffice. We don’t have better. The alternative would be option 3 and leave the content in NextCloud and use Collabora Code. See later.
I would not go in this direction. The File Manager has been made to bring legacy content in XWiki not to have an advanced user experience about these files. We don’t expect the File Manager to be on par with NextCloud. I would continue to use NextCloud which is a great tool for file management.
It’s unclear how this would work well. You pointed right that we don’t invest too much on WebDAV. The reason is that often it has to be blocked because of enteprise authentication systems and it’s not an option for many companies. Also WebDAV is made for folders and XWiki has a hard time representing the XWiki content as folders & files.
It would be interesting to see if this works and if NextCloud can sync that offline for example. This could be a solution to expose the attachments.
Now maybe what XWiki should have in this case is a WebDAV only focused on the attachments based on the XWiki nested pages structure and then have this syncable over tools like NextCloud. Some experiments would be needed to see if this could be a viable option.
Now what I would try based in the information I have is:
1/ Either importing fully the content in XWiki as structured pages with meta-data and allow editing of these office files from a online editing tool (OnlyOffice at this point or get an implementation of Collabora Code integration → this could be sponsored).
2/ Create (through import or manually) the structure of the documentation in XWiki and keep the files in NextCloud using linking and work on a viewer integration between XWiki and NextCloud similar to what XWiki has with Office365 and Google Apps. Our initial studies show that there is a missing feature in NextCloud to have “public url” for viewers that can be embedded. Some security settings would also be necessary to allow iframe embedding of this NextCloud content inside the XWiki instance. Here there is a integration that could be developed both in XWiki and NextCloud.
The drawback of this solution is that there is no search integration and some integration would be necessary here. In our Office365 module we have included a extension suggesting searches from Office365 in XWiki. With the proper API in NextCloud this could be possible. An alternative approach would be to index the content. As we have the links in XWiki to the NextCloud content, XWiki’s search engine could download the files and index the content provided it has the rights to do so. The content could also be replicated but there is a risk it’s not the latest one if it’s edited in NextCloud and XWiki does not have a way to update the content.
3/ Implement ActivityPub. NextCloud has a federation mecanism and XWiki could implement that mecanism. This would allow to “share” a document with XWiki and it might (this needs to be validated technically) be possible to push a document to XWiki and then have XWiki and NextCloud be informed if the document is modified on either side. So documents could be edited in NextCloud and then pushed to an XWiki page for publication.
This is a different ways I would go. We would be interested in working on integrating NextCloud with XWiki. We believe NextCloud is a great tool and our companies are both trying to liberate users from proprietary softwares. I personally believe more integration between OSS tools is necessary but everybody struggles to find the way to finance it.
Ludovic