Objective
In the process of moving my work to xwiki , one of the important tensions (and thus potentials) I see is the ability for serious content creators to speed up the page creation process.
Rationale
The logic for this is my observation that content creation in the current years, is moving from:
- channels with single item deliverables (like blogs and youtube channels)
- to websites with wiki-style interlinked pages
- to networked thinking portals
- to decentralized collective intelligence ecosystems (supported but not controlled by ai)
So the emerging pattern is more co-creative production, but also as a workstyle the individual co-creates with themselves by āseedingā and āharvestingā multiple development streams of interconnected content. Allowing the content creation steps to simplify would be needed.
Content structure
In this emerging pattern the building blocks are moving away from the concept of page to a more flexible information unit, which can be presented as a combined deliverable in a variety of ways. In practice, this means that users will be creating these building blocks much more often than regular pages.
Xwiki as discussed in aprevious post, was not designed for this atomic structure, since at its initial years of development, the focus was on the page-based wiki structure. Nontheless, I think that the ability of XWiki to use classes and objects is very powerful. We could extend that philosophy to the concept of pages itself, in that a new kind of entity can function as a type of dynamic page that displays a selection of other pages.
Real life application
Without running ahead with these assumptions, I like to test an application with āreal lifeā challenges. Of course āreal lifeā depends on the type of user, the type of work and the best workflow that serves this.
I think that platform developers need to regularly rethink the purpose and potential users, taking into account the social and technological shifts that are happening.
Practically, the growth and success of a platform depends on quality and quantity of users, but in my own experience with the founding of social movements, real growth and impact depends often on the power users and their personal and business networks. The power users create massive amounts of high quality content, and the speed of doing that is much higher, because of the way they contiuously seed and connect their ideas. Content creation is thus more like the simultaneous emergence of deliverables, like a gardener sows and harvests its crops.
For example, I can compare my style with professional content creators that have a continuous input of creative ideas, which are continuously converted to elements in simultaneous streams of research, development, connectivity, co-creation. In practice, such content creators often work on multiple connected pages at the same time. This not only relates to their ability to interconnect ideas, but also the ability to branche texts into multiple other texts during the writing process.
Single Click Page Creation
This thread topic presents a context which may offer the motivation to prioritize the workflow and user experience of professional contenporary content creators. The main tension here is the many clicks before an editable new page is shown. There are different ways we can solve this, for example:
- Panel: There is a page creation panel, which still asks for a page type (class). This could allow to set defaults. The panel also assumes a new page is a child. But in real life, I hardly ever work with hierarchical relations, all content has a many-to-many relationships, as well as symantic tagging.
- Inline link: Inline wiki link syntax create a new page when clicked, with the dialog to select a page type. This could be set to a default, to skip this step.
- Modal frame: My workflow is that I create new referenced pages while writing a page. This means that I donāt want to leave the primary page when I create and edit a secondary referenced page. I mentioned this already in a previous related post, in which options were discussed to āget back to the primary pageā. In the context of the current post, creating a new page inline could be offering a default of opening it in a modal frame. This allows for more or less simultaneous work on two pages, untill the secondary modal frame is closed.
- Browser extension: Because Xwiki is a web based application, its direct working environment is always a browser. I think that this fact is underrated in Xwikis development, Xwiki is currently limited in its interconnectedness with other web apps, and thus it appears to me relatively isolated in its own ecosystem. This is counter the current trends. A first step would be to create a chrome browser extension for making pages instantly. Clickup did a very good job with that, it includes simple bookmark creation as well as the ability to paste text from clipboard in a popup window for the creation of a new entry.
Questions
Of course there are many platform users that have the more classic workstyle, or their own different workstyle. You have probably developed your own style. I have the following questions for you, related to what I wrote above:
- Do you personally recognize the tension described in the Objective?
- What are your personal tensions related to the Content structure? Does it support your creation flow or do you feel you have to adapt a lot to the standards of the platform?
- In the way you and/or your organization uses Xwiki, do you see that real life applications and tensions push for a new type of more decentralized, atomic content creation process?
- Would the simple implementation of Single click page solution help you? How do you see that work for you.
