Technical Preview 1 Onboarding Plan

[rhuss]

This is a brainstorming issue about how should the onboarding / offboarding procedure for registered should be performed technically. This should result in a list of tasks to perform for the onboarding process.

• How to manage registration requests (e.g. spreadsheets ?) ?
• Installation script for setting new users ?
• Monitoring usage ?
• De-installation script ?
• Communication with users (automatic mails, mailing-lists, forum) ?
• Registration page ?
• Feedback form ?

@syndesisio/all The goals is to have a plan for the onboarding process at the end of this sprint 15. Please add your thoughts and ideas to this issue.

[dsimansk]

What about following Obsidian's approach? https://launch.openshift.io

And maybe reusing similar wizard https://launch.openshift.io/wizard/launchpad-new-project/1

[rhuss]

Good idea, @dsimansk

As this is more about productisation than the project itself, I opened a JIRA issue at https://issues.jboss.org/browse/IPAAS-339

Let's followup the discussion there (but keep this issue open as a reminder)

[jludvice]

EDIT: comment moved to jira

[kahboom]

This should also include the documented user walk-through, or guided tour: syndesisio/syndesis-ui#57

[kahboom]

I'd also recommend having issues for each feature as part of the FTUE (well, at least for the UI I find it helpful as opposed to several PRs in the case of such a big, overarching task), but whatever works for everyone else is fine with me.

[kahboom]

@rhuss @jimmidyson - A few questions:

1. Are we wanting to persist the on-boarding experience for first time users to the REST API? i.e. If a user has already started the guided tour, what step they are on, if they've selected to opt out of it. If so, we will need another REST API endpoint, which I can add to the proposal. If so, do I just write whatever data model I want for this situation in JSON format or is there something specific you'd need?

2. Will the documentation we were discussing in the other issue (for tooltips or even the guided tour, from an AsciiDoc file, extracted via a Maven plugin) be provided as JSON from the REST API? Assuming we will need yet another endpoint here as well.

Thanks! :)

[rhuss]

1. I don't think that we should persist the steps server-side. If required, the step states should be stored client side.

2. I'd prefer to have the tooltips pre-generated into the syndesis-ui repo, e.g. as part of the build process. This step should fetch a JSON file from e.g. raw.github.com and then put it into syndesis-ui so that it can be committed. This would avoid any latency and connection issues to the backend and is the most performant one. You can safely assume that you will have a tooltips.json as static file.

[kahboom]

On second thought, I'd guess the only important thing to persist in terms of #1 is whether or not this is the first time they've logged in, as it would be ideal that users be able to re-start/close the guided tour at any moment either way, so it should mostly be done on the front end, but we'd still need to know if it's the user's first time logging in.

[kahboom]

Ah just saw your response @rhuss , thanks! Do we have an example of what the format of that tooltips.json will contain? We could likely use something similar for the guided tour, but we'll just store that in the client in the front-end I guess.

[rhuss]

@kahboom I was asking the same question in syndesisio/syndesis-documentation#20 (comment) so not sure yet. I try to figure this out tomorrow.

[rhuss]

Now that we are at TP1 I think that can be closed. The open tooltip discussion has been already tackled with the introduction of a maven plugin which needs to be activated for the build still. There is open issue syndesisio/syndesis-documentation for this.