Blank state improvements


(Cédric Krier) #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://gettingreal.37signals.com/ch09_The_Blank_Slate.php


(Sergi Almacellas Abellana) #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.


(Cédric Krier) #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.


(Felipe Morato) #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.


(Cédric Krier) #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.