Blank state improvements

Feature Ideas
1

I open this topic to collect ideas on how to improve the “blank state” of Tryton.
The “blank state” is the screen people see when using the application for the first time. In Tryton it can happen at any time because a module can be activated at any time and so this module could create new screen which will be empty.

Here are some thoughts about this topic: https://basecamp.com/gettingreal/09.4-the-blank-slate

2

In order to explain what modules do and what data they required we should create configuration wizards which explain the new activated features and provide shortcuts in order to load the new required data. Some examples may be:

  • Load some parties in the database when installing parties (directly using a form or with csv import)
  • Create products when installing product module
  • Create boms when installing production module

Of course if the all of the 3 modules are installed on the database, the wizards should take care the module dependency. I don’t know if using the sequence field is enough.

3

I do not think it is very good UX to have wizard because it does not help to discover the UI, it is a blocking workflow (the current necessary wizards, we have, are already a little bit painful).

I do not see how a new user will be able to load parties without knowing anything else. And it is even more complex (maybe impossible) via CSV (I never did it).

Why having a different workflow for blank state? It does not help to learn the UI.

4

A new view that inherits the wizard could be created to display screenshots of the module with data, explain concepts and go on a walk through of the UI.

The walk through could be similar to intro.js for sao. I don’t know if this is possible in GTK.

5

I’m not sure to understand what you explain.
But I’m not sure that screenshots are relevant.

About that, I thought that the first time a user open an empty list, we could display instead it, a small text explaining what should be there.

This could be interesting to have a format to store similar scenario that could be run on both clients. Because of the specific design of both client, I think we can not reuse an existing library.

6

After re-reading the post, I think this is the only option that we have to explain the user what he has to fill in each screen. For example, for price list we can add: “Create records to define different sets of prices for each customer”.

7

Here are two usefull links for the topic:


After reading them I think the best option for tryton is to add a Translatable text on the Model, which will be used as call to action to let the user know which kind of records should be created on the screen.

Another option is to include a link to the module documentation but this will not work for third party modules.

1 Like