Proposals for improving the Onboarding Experience

[vmassol]

Thanks for working on this and proposing!

General

@gabrielc I’m not sure to understand what you’re proposing or trying to achieve globally. It feels like you’re proposing something that XWiki SAS could build, not something done by the xwiki.org community and in XS. Is that correct?

I’m asking since this thread is about the onboarding on xwiki.org/inside XS by default (AFAIU).

If that’s correct, I’d propose that you start a new thread about the development of a new contrib extension (for example), so that we separate the 2 topics.

See at the end though.

Analysis

@gabrielc

1. This UI would guide an instance owner through configuring the instance based on their organization’s needs.

2. This would be done using a series of questions about their usecase and expected features.

3. Towards the end of the flow, the Admin is asked if they want to configure their instance based on their answers.

As a user I’d really hate that flow and run away… Having to answer questions I don’t want to answer and then being asked if I want to use my answers doesn’t seem right. You should start by asking if the user wants a config based on replying to some feature usage questions. And if not, skip the question altogether.

The devil is in the details. For ex you list:

@gabrielc

Installing certain Extensions based on the Admin’s needs (e.g.: if the Admin said they’d like to review pages before publishing them, the Change Request extension would be installed)

It’s possible to ask such a question for every single extension. Is your plan to ask 200 questions to know if the 200 extensions should be installed? If not, how do you choose what question to ask/which extension to install.

Also, the user know their need better than any question so it feels to me we should rather teach them to use the Extension Manager and then they can install whatever they need. And if the extensions’ descriptions are not good enough to understand them, we should improve them IMO.

@gabrielc

The extension would be implemented separately from the Distribution Wizard. It would be named, let’s say Customization Wizard. See explanation below.

1. how does it interact with the DW? Does it appear before it or after?
2. Why separate? That’s not a great UX for users to have 2 competing systems.
3. The DW is made to be extensible and contain new steps if needed so I don’t see the need for a different system.

@gabrielc

The extension should be developed to allow data collection when it comes to the user’s answers. This functionality could be disabled by default on XWiki.org distributed packages, but it would allow other environments to gather insights about the most picked usecases and features.

We don’t need to send that info… we kind of already have it and in a better way. For ex, imagine that a user installs some extension later on, you won’t know it. What we have now, as part of Active Installs, is the anonymous list of installed extensions on all instances that share anonymous data.

What we are lacking is not this but whether the features are used. This is a different thread though.

@gabrielc

Making it an independent extension would allow for quicker development, plus it would be easier to iterate on the extension.

How does it get installed? You won’t have it when you install XS and go through the DW…

Does it mean you suggest that organizations (like XWiki SAS) which want to have your feature should provide a custom distributions that includes that extension?

@gabrielc

Ideally, in the future, the Distribution Wizard and the Customization Wizard would be merged (if it makes sense). This WIP design page made by Thiago on the topic of Distribution Wizard UX improvements looks really nice. Especially the part mentioning user onboarding.

IMO it’d cost a lot less to reuse the DW and add a step than recreating a new UI/system from scratch.

@gabrielc

Offering a new onboarding experience quicker would allow new users to better evaluate if XWiki is a good fit for their needs. Interest in XWiki is up lately compared to the same period last year.

What you’re suggesting is very close to the concept of Flavor. It’s basically a “dynamic” flavor. The problem I see is that a Flavor is not just a set of features that you install. It has a theme/consistent UI and usage flow, and requires a lot of work. XWiki SAS tried this in the past with the Procedure Flavor and it took very long to develop and maintain.

So IMO what you propose is either too hard to develop (Flavor) or with too little added-value (just installing a set of extensions doesn’t make an environment targetd to a specific usage).

What we could do

However, I think it has value in a simplified form and we could easily have a step in the DW that lists a set of recommended extensions that the user could select and that will be installed. This recommended list would be taken from the list of supported extensions. We could even send a vote to modify the governance of XWiki.org (https://dev.xwiki.org/xwiki/bin/view/Community/Governance) so that the Top Sponsoring Company is allowed to provide a few extensions to be displayed in that extension list.