Define TodoMVC onboarding specification
slorber opened this issue · 9 comments
The TodoMVC is a pretty simple app, but the onboarding should be complex enough so that it is challenging to implement.
I want popups, tooltips, highlights showing/hiding/blinking everywhere.
The onboarding should also be meaningful. I don't want to display a congratulation popup that hides after 5seconds user inactivity just for the technical beauty of it.
Maybe we could also simulate some API calls with a local API implemented with setTimeout ? not sure if it would be in the scope but real world onboarding usually query some backends so that you can import your facebook friends or whatever...
Any idea on what we could build?
Some app-/webapp-onboarding related tasks that usually are needed to convert a plain TodoMVC to a meaningful app:
- registration/login <- add validation
- reset password <- add validation
- add personal data/social profiles <- add validation
- set some basic preference on how to use TodoMVC
- guided process of adding first item into Todolist
It would be interesting to add ability to:
- Import todos
- Export todos
- Reset, Merge, ...
Hi,
I created this repo essentially to build an onboarding. Don't you think that the features you ask are out of the scope of an onboarding?
Or maybe the community would be more interested in a real world implementation of TodoMVC (including onboarding + other meaningful features) ?
Hello @slorber,
thanks for this excellent idea!
I believe we need a brief description what "onboarding" actually is, because I got an impression from the comments above that people are a bit confused about terminology. Could you please elaborate on this?
Or maybe the community would be more interested in a real world implementation of TodoMVC (including onboarding + other meaningful features) ?
I would say no - it's much easier to point out positives of the architecture while implementing "non-complex" yet non-trivial feature request on top of well known application.
Also very important detail - The purpose of this "challenge" is not to prove that architecture XYZ can bring us the cleanest and nicest implementation of onboarding. The purpose rather is to prove that architecture XYZ is easily extendable because this is the "selling" point which lacks all the architecture comparisons.
I believe we need a brief description what "onboarding" actually is, because I got an impression from the comments above that people are a bit confused about terminology. Could you please elaborate on this?
I mean that the TodoApp starts with an user onboarding that explain the features of the app. It is a step by step guide that invite the user to click on buttons by adding tooltips to the buttons, making the buttons blink...
We can define a list of goals that the user has to do to complete the onboarding. Each goal should be done after the other (maybe?), and there should probably be a view that list all the goals and show them as completed or not so that the user has an idea of how much remains to be done.
If the user doesn't seems to progress anymore in a goal for more than 10 sec, maybe we can give him additional help.
Some goals can be simple actions or more complex actions like:
- Create a todo
- Toggle a todo
- Create 3 todos, mark 2 of them as completed, and delete all completed todos at once
Also very important detail - The purpose of this "challenge" is not to prove that architecture XYZ can bring us the cleanest and nicest implementation of onboarding. The purpose rather is to prove that architecture XYZ is easily extendable because this is the "selling" point which lacks all the architecture comparisons.
I want to show if an implementation can scale on large apps. I don't want to show which implementation has less boilerplate.
I suggest:
-
Mark a TODO as complete, and then immediately change it back to incomplete (This means there cannot be any user-initiated actions between them, but there can be other actions like responses coming back from the server)
-
Create 3 todos, mark 2 of them as completed, and delete all completed todos at once. (Order does not matter)
-
Create a todo named "secret", mark it completed, delete it. Create another todo named "code", delete it. (Must be done in exactly this order, but other events may intervene)
My goal was to define moderately complex tasks which interact with the state and action history in different ways.
@slorber Trying to lay out a more abstract model. Then maybe using it as a base framework to build a more concrete spec.
Definitions
- Onboarding consists of a sequence of tasks the user should complete
- Each task consists of a sequence of one or more actions the user should perform
- Each action consists of one or more user inputs leading to some intermediate state (i.e. user inputs not necessarily sequential).
- Onboarding has a state (current task/action, started, aborted...), should be persisted per user between app restarts
UI interactions
- At the start of the application,
- Load the OB state
- If the OB hasn't yet started displays an Invitation i.e. a description and a list of the OB tasks
- If the OB has already started resume to where we stopped last time
- Proposes commands to either start the process or skip it or aborts it (never show again)
- If the user accepts, display a description of the next task
- proposes commands to either
- start the task
- skip the task
- pause the process to resume it later.
- During a task, display visual cues to assist the user on where and how to perform the next action (tooltip, blink the target ...)
- Each action has a 'longest possible time of completion'
- If the user takes too much time (time > estimated time) to perform an action display a message and proposes some kind of help
- If the user perform an action that's not expected, display a message to (gently) warn the user, and ask him if he'e still willing to complete the onboradning process or abort it