Re: [Dolibarr-foundation-board] Fwd: Re: Propositi on d'intégration de CustomFields dans Dolibarr

[Laurent Destailleur (eldy)]

Le 12/09/2012 11:39, Cyrille de Lambert a écrit :

Bonjour,

Pour les interfaces et le thème, Emmanuel propose de décliner en plusieurs couleurs ce qu'il a fais en orange.

Si c'est jute le changement de couleur, je ne suis pas sur que cela soit utile.

Mieux vaut une variable ou l'utilisateur choisit sa couleur avec un theme dynamique, que n themes à maintenir.
(exemple: Ceci est opérationnel avec le module skineditor et le theme edly. Cela pourrait etre décliné sur les autres themes). La difficulté est qu'il ne faut plus utilisé d'images mais uniquement du css pour faire les dégradés sans quoi cela n'est pas déclinable par couleur.

Cyrille

Le 12/09/2012 11:12, Régis Houssin a écrit :

je suis d'accord avec toi sur le fait de ne pas surcharger l'application avec des fonctionnalités superflues et trop de codes à gérer.
reste à déterminer ce qui est superflu et ce qui est utile pour 99% des cas

exemple mon module Milestone, il s'avère que ce type de fonctionnalité est utilisée par beaucoup et c'est pour cela que j'ai décidé de l'intégrer aussi.
en ce qui concerne les champs personnalisés, ceci est aussi très utile.
reste à voir si ce module est user friendly et pas trop tourné geek
j'ai moi même créé un module de champs personnalisés, que je laisse en module externe pour le moment.

un onglet module expérimental serait le bienvenu, au lieu de les disperser dans les différents onglets.
je propose aussi de créer une section pour stocker toutes les constantes cachées, déjà pour éviter de les chercher à droite à gauche, et pour se souvenir si oui ou non elles sont activées.
(petit aparté) tu as fusionner des menus systèmes, c'est un peu brouillon, il faudrait des menus/sous-menus en plus.

maintenant Laurent je suis ok pour une application simple, mais il faut aussi prendre en compte les remarques de la majorité des utilisateurs afin de coller au plus grand nombre et à la demande du marché.
j'ai souvent des remarques de personnes qui découvre Dolibarr et me demande si c'est fait uniquement pour les TPE ou association. Ils n'ont pas confiance !

Je penses qu'il faut changer de discours et ne plus se restreindre dans les capacités de Dolibarr.

PS: et revoir l'interface et les thèmes car pour certains nous sommes obsolète au possible...

Le 12/09/12 10:42, Laurent Destailleur (eldy) a écrit :

Pour info

Le 10/09/2012 13:46, Stephen LARROQUE a écrit :

Bonjour Laurent,

Je te remercie d'avoir étudié ma proposition avec sérieux.

Je vais ici répondre point par point à tes interrogations:

- Au sujet de la licence, aucun soucis, j'avais indiqué dans un mail précédent que je suis tout à fait d'accord de mettre le module en licence GPLv2+ comme Dolibarr.

- Je suis aussi tout à fait d'accord avec le fait que le module devrait être committé en experimental en premier lieu.

- J'ai déjà étudié la solution de mettre le module sur Dolistore et n'ai pas retenu cette solution.

- Le module n'est destiné à la fois à l'utilisateur lambda et à l'intégrateur (mais surtout à l'intégrateur) et aussi au développeur: il y a des niveaux de fonctionnalités et de complexité pour chacun. Pour l'utilisateur lambda, il n'y a aucune notion nécessaire, ils peuvent créer leurs champs simplement dans l'interface et les utiliser dans leur modèles ODT sans aucune connaissance technique. Les fonctionnalités avancées sont réservées à ceux que veulent plus d'options et sont décrites dans le wiki.

Certes, mais le seul fait de "voir" des fonctons avancées avec des notions non comprises (comme clé étrnagère, ou requete sql), suffit our ne pas etre compris par l'utilisateur, meme si c'est optionnel, c'et genant.

- Au sujet de rajouter des écrans d'information, effectivement j'ai anticipé et ai déjà rajouté un petit encart en haut de l'interface d'administration, qui indique les actions basiques et pointe vers le wiki pour plus d'informations sur les fonctionnalités avancées. Si tu as d'autres idées d'aides à rajouter, je me ferai une joie de les implémenter car je souhaite que le module soit bien documenté et le plus facile possible à utiliser.

- Le module peut également être mis dans la page "complémentaire" si souhaité.

- Quant au fait que "le module n'apporte qu'une plus-value faible par rapport à la fonction déjà existante en standard" pour l'utilisateur lambda, je ne suis pas de cet avis: CustomFields supporte déjà la quasi-totalité des modules de Dolibarr, permet d'utiliser un plus grand nombre de types de champs, gère les champs contraints (ex: lié à une autre table Dolibarr comme llx_user)

Ceci n'interesse pas l'utilisateur lambda, il ne sait pas ce qu'est un lien.

et gère l'intégration dans les templates ODT et PDF;

ceci sera aussi dispo avec le module standard

sans compter les fonctionnalités de customization avancées pour l'intégrateur et le développeur.

Ceci n'interesse pas non plus l'utilisateur lambda

C'est d'ailleurs pour cette raison que je me permet de proposer à l'équipe de l'intégrer.

Et je t'en remercie.
Toutefois, il faut comprendre la stratégie. La cible est la suivante :
* Ne mettre dans Dolibarr que les fonctions qui assure les besoins types standard
* Ne pas mettre de fonctions en doublons sur les fonctionnalité basiques, si la plus value ne concerne pas les utilisateurs lambda.
* Ne mettre dans Dolibarr que des fonctions compréhensibles par un utilisateur lambda. Même si une fonction qui n'est pas pour lui est optionnelle, si on peut ne pas la faire apparaitre pour ne pas lui faire peur, il vaut mieux.
* Et pour pouvoir malgré cela offrir un logiciel riche et puissant et donc garder un compromis entre simplicité et richesse, ce qui est hors de ce cadre doit être fourni en module complémentaire (si possible).

Bon, c'et la base, dans la pratique, c'est dur de trouver le bon compromis. Mais c'et justement la la supériorité reconnue de dolibarr ar rapport au autres.

N'hésites pas à me dire ce que toi et l'équipe en pensez, et si vous souhaitez toujours intégrer CustomFields à Dolibarr.

On pourrait en effet, ajouter des tas de modules aux fonctions avancées ou aux options variantes, mais cela grossit dangereusement le code à maintenir. Hors la politique est de le réduire pour rendre les choses plus modulaires et externaliser les fonctions.
C'est certes un choix uniquement "tactique", et qui peut etre discutable, mais dans la mesure ou les concurrents prennent le chemin inverse (grossir leur coeur pour avoir plein de fonctions), c'est une maniere de se démarquer et d'être seul sur un segment abandonnée. C'était aussi l'engagement pris quand l'auteur du projet m'a demandé de reprendre son projet.

Ce choix de laisser et rendre encore plus simple (tout en permettant une utilisation avancée mais sans forcément avoir ces fonctions avancée maintenu par l'équipe principale) est donc un choix sur le long terme (car comme toute stratégie, cela n'a d'effet que sur le long terme), et seul l'avenir sera capable de dire si il était bon. D'autant qu'il n'y a pas qu'une seule bonne stratégie, il peut y en avoir plusieurs. Mais pour un projet donnée, une seule ne peut etre appliquée à la fois pour avoir un sens. Aussi il en faut bien une, et l'évolution de popularité et l'agrandissement de la communauté ces dernières mois avec les dernieres versions, montre que meme si il y en a d'autres, de bonnes stratégie, celle n'a semble faire partie des payantes, même si c'est l'une des plus dur à suivre (la facilité étant d'integrer chaque commit de chaque besoin de chacun).

Ce que je propose, c'est que, comme ton modules est non intrusif, son ajout mais aussi suppression pouvant se faire sans risque, c'est de le mettre en experimental.
Je vais l'intégrer aussi dans une nouvelle section dont je n'ai pas encore trouvé de nom pour signaler que le module évoque des concepts techniques, a moins que je ne fasse une rubrique "experimental" pour y mettre les modules experimental plutot que dans leur rubrique dédiée. Hum, y aura surement des retours à mon mail pour me faire trancher.

Je te dirais quand c'est commité (j'espere faire cela cette semaine).
On verra apres comment cela évolu.

J'ai mis le bureau en copie, car pour une fois que j'explique certais letimotiv, cela ne peut pas faire de mal.

Cordialement,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------

--

Cyrille de Lambert
address@hidden 26 bis rue des olivettes 44300 NANTES	Tél : +33 (0) 2 51 13 50 12 Mobile :+33 (0) 6 29 41 81 22 Fax : +33 (0) 2 51 13 52 88 http://www.auguria.net

-- 
Eldy (Laurent Destailleur).

EMail: address@hidden
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: address@hidden
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: address@hidden
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net