WIP : Documentation ux

[EchoLoGeek]

New Interface for documentation

[lmag]

@eldy it's beatifooul ?

[eldy]

What do you mean with "New Interface for documentation" ?
Can you provide screenshots ?

[EchoLoGeek]

Yes of course.
This is an update of old pages located in the public/test folder

Before:

After:

The goal is to have an interface allowing graphic designers and developers to know how to use the graphic elements implemented in Dolibarr

[eldy]

The page are page that users can access without being logged (no need as it is test/documentation).
Such pages myust always be stored into /public directory.
Any other directory contains pages that need credentials to access to.
Can you move /documentation into /public/documentation
Also i think we must not introduce documentation into core of application. We already have the wiki for full documentation (even if we should enhance its interface). So the page must be limited to test or experiment UI components in live mode (this was the main goal of old page: testing all ui components at one place to validate non regression after js, or browser change). For this reason, the name documentation looks not a good choice, creating confusion with real documentation. So may be you can use name instead /public/ui ?

[lmag]

We were not really convinced for the name "documentation" public/ui seems better for me either.

[EchoLoGeek]

Ok I will prepare an update in this direction.

[john-botella]

@eldy

EN :

The page are page that use can access withiut being logged.... Such pages myust always be stored into /public directory.

not always, and it's likely to be mainly pages with admin access, the aim being to enable a dev to understand how his environment works with examples, for me it should be limited to admins.
arbitrary example: how can you give an example of how to use a third-party selection form in public without exposing customer data?

what we're talking about here is a tech doc to enable people to play with legos, but also to be able to carry out rapid integration and design tests, allowing front-end devs, for example, to quickly see the impact of their modifications.

We already have the wiki for full documentation

The wiki doesn't allow you to consult this doc with the exact rendering of curent theme, my dolibarr version and the modules installed at the moment? This is something frontend devs need ;-)

---

FR :

The page are page that use can access withiut being logged.... Such pages myust always be stored into /public directory.

pas toujours et ça risque d'être essentiellement des pages avec access admin, le but est de permettre à un dev de comprendre comment fonctionne son environnement avec des exemples, pour moi ça doit justement être limité aux admin.
exemple arbitraire : comment donner un exemple d'utilisation d'un form de sélection de tiers en public sans exposer les données clients ?

on parle ici d'une doc tech pour permettre de jouer aux légos mais aussi de pouvoir faire des tests rapide d'intégration est de design en permettant par exemple aux dev frontend de voir rapidement les impactes de leurs modifications.

et dans le cas d'une doc plus générique, sans access admin, le fait de devoir être loggé permettra en face d'une fonctionnalité de justement pouvoir indiquer à l'utilisateur qu'il n'a pas les droits correspondant, car pour rappel il y a une option dans doli pour griser ou ne pas afficher les boutons ou autre action lorsque l'on n'a pas le droit. Perso je désactive l'affichage des élément si l'utilisateur n'a pas les droits ça évite de polluer l'UX, mais du coup les utilisateurs débutant dans l'entreprises peuvent ne pas s’apercevoir qu'il leur manque un droit vu que toute façon il ne connaissent pas le logiciel... alors sur une boite de 5 personne ça passe mais sur les grosses boites...
Mais cela permettra aussi, si on fait ce genre de distingo, d'afficher une doc filtrée ou non sur les droits utilisateur et donc de simplifier l'affichage (par defaut) de la doc aux éléments accessibles par l'utilisateur.
Ok c'est un voeux pieux, mais si on se donne pas les moyens de base de le faire alors ...

Et aussi, si nous pouvions éviter de donner trop facilement aux hackers des infos sur la version est les modules installés en se connectant simplement à la doc public ...

We already have the wiki for full documentation

Le wiki ne permet pas de consulter cette doc avec exactement le rendu du theme actuel , de ma version dolibarr et des modules installé à l'instant T? C'est un truc don à besoin les dev frontend ;-)

[lmag]

Terme use by google is
Material
See : material.google.com

[eldy]

@eldy

EN :

The page are page that use can access withiut being logged.... Such pages myust always be stored into /public directory.

not always, and it's likely to be mainly pages with admin access, the aim being to enable a dev to understand how his environment works with examples, for me it should be limited to admins. arbitrary example: how can you give an example of how to use a third-party selection form in public without exposing customer data?

True.
So lets move out of /public. Because it is not a module and limited to admin logged users, why not storing this into directory /admin/ui ?

[eldy]

@eldy
EN :

The page are page that use can access without being logged.... Such pages must always be stored into /public directory.

not always, and it's likely to be mainly pages with admin access, the aim being to enable a dev to understand how his environment works with examples, for me it should be limited to admins. arbitrary example: how can you give an example of how to use a third-party selection form in public without exposing customer data?

True. Currently test is done on

if ($dolibarr_main_prod) {
	accessforbidden('Access forbidden when $dolibarr_main_prod is set to 1');
}

But i don't like this, sometimes the dolibarr_main_prod may be modified in production to get more technical infofor debug purpose.

So lets move /public/test out of /public.
Because it is not a module and limited to admin logged users, why not storing this into directory /admin/ui ?

For information /admin/* pages are pages that are all protected with

if (!$user->admin) {
	accessforbidden();
}

A CTI test will be probably added in the future.