Re: [Dolibarr-foundation-board] Installation wizard

[Régis Houssin]

en parlant de clic, un exemple simple de l'utilité des templates et/ou
de la séparation du code, nous avons souvent dans une fiche plusieurs
onglets qui peuvent devenir pénible au niveau clic pour les renseigner
ou les visualiser, le système de template pourrait permettre une
meilleur souplesse au niveau de l'ergonomie, nous pourrions disposer ces
différents onglets comme des blocs sur une même page par exemple, alors
on peut me dire de bouger le code actuel dans une même page !
oui pourquoi pas, comme on pourrait mettre tout le code de Dolibarr dans
une seule page !

Rien que la page /compta/facture.php me fait peur quand il faut rajouter
des fonctions ou rechercher un bug ! visualisation, création,
modification et liste sont tous regroupés dans une même page !

pas mal de code pourrait être mutualisé.


Le 16/08/11 08:32, Jean Heimburger a écrit :
> Bonjour à tous,
> 
> C'est intéresant d'avoir ce débat avec plusieurs voix et idées qui
> s'expriment.
> 
>    Je n'ai pas vraiment d'éléments de comparaison pour l'ergonomie
> souhaitable. Dolibarr est reconnu pour être simple à utiliser et à
> prendre en mains. Donc l'ergonomie ne doit pas être si nulle que cela.
> Les écrans sont clairs, avec les informations attendues... Maintenant
> tout cela est certainement perfectible. Depuis pas mal de temps, une
> chasse aux "clics superflus"  améliore l'ergonomie. Il faut continuer
> dans ce sens.
>    Mais, dans un ERP, il y a forcément des circuits de validation, et un
> clic ou une cofirmation veut aussi dire que l'utilisateur a effectué une
> vérification fonctionnelle avant de cliquer. Un clic n'est pas seulement
> là pour embèter l'utilisateur, mais à l'assister dans son tavail en
> demandant une confirmation qui lui évitera bien des soucis plus loin
> dans le processus de gestion. On rencontre la même problématique avec
> des utilisateurs d'applications métier client/serveur ou non dans les
> environnements windows, basés sur des fenêtres et les inévitables boites
> où il faut cliquer ou cocher une case.
>    Alors Ergonomie, Design, IHM bien sûr. Mais pas au détriment du
> fonctionnel. Je reste persuadé que c'est plus le fonctionnel qui aidera
> une entreprise à adopter Dolibarr que le design.
>    Dolibarr est aussi un outil de gestion, à destination d'associations
> et de professionnels qui ont besoin d'un outil qui réponde à leur
> besoin, alors, même s'il faut travailler sur l'ergonomie, le design,
> l'IHM, il faut surtout entendre aussi les besoins des entreprises qui
> ont choisi Dolibarr et qui ont peut être besoin de fonctionnalités
> nouvelles ou améliorées. Ce que dit Cyrille, pour les besoins dans le
> domaine de la CRM, j'ajoute aussi une amélioration des fonction de
> recherche de produits. Les fonctions actuelles sont limitées pour des
> catalogues importants (20 000 référneces et plus).
>    Qui pourrait nous faire un petit topo sur commet séparer les couches
> de code sans tomber dans des usines à gaz de template et d'API ? Quelles
> seraient de bonnes habitudes à prendre pour le développement de Dolibarr
> (qui se veut simple à développer, je le rappelle)?
> 
> @+
>   Jean
> 
> 
> 
> 
> Cyrille de Lambert a écrit :
>> Bonsoir,
>> Concernant les différents points :
>>
>>     * Je ne suis pas du tous d'accord avec l’ergonomie qui est
>>       meilleur que tous les produits libres et propriétaires
>>       concurrents (certain n'ont jamais fait d'OpenERP !!!). Les
>>       utilisateurs voient tous de suite ce qu'il faut faire avec
>>       l'application. Les principaux points d'amélioration à faire sont
>>       sur la partie CRM
>>     * Le graphisme actuelle ne fait pas ressortir cette ergonomie. On
>>       finalise le graphisme bureau2crea cette semaine.
>>     * La partie code de la formation est largement à revoir pour
>>       séparer les couches. Mes collaborateurs ont du mal avec cette
>>       non séparation qui dénote avec leurs habitudes de travaille. La
>>       façon dont c'est fais actuellement est illisible pour toutes les
>>       améliorations futures des thèmes. Je suis d'accord avec Régis et
>>       les personnes qui se sont exprimées dans ce sens.
>>
>> On en reparle début septembre
>> Cyrille
>>
>>
>> AUGURIA
>> Cyrille de Lambert
>> address@hidden
>> 9, rue Alfred Kastler
>> BP 50752
>> 44307 NANTES CEDEX 3     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
>>
>>
>> Le 15/08/2011 19:48, Pascal Aubry a écrit :
>>> Bonsoir à tous,
>>>
>>> Je vois dans l'ensemble du fil de la conversation le mot Design qui
>>> revient régulièrement mais pour moi, même si nous pourrions
>>> certainement rendre l'IHM de Doli plus jolie, le problème n'est pas là.
>>> Le point bloquant dans la commercialisation de Dolibarr est son
>>> ergonomie (ou son relatif manque d'ergonomie*).
>>>
>>> * :Attention je ne veux vexer personne, il s'agit une remarque que je
>>> souhaite constructive. Cela ne nous empêche pas de gérer au quotidien
>>> TECLIB' avec Dolibarr :)
>>>
>>> C'est lié au code moderne (Ajax, EXTJS ou autre) mais effectivement
>>> aussi à la séparation du code applicatif de celui de présentation et
>>> donc design CSS & Co.
>>>
>>> Je trouve cette conversation très intéressante et je pense qu'il faut
>>> continuer d'en parler ensemble et ne pas prendre de décision hâtive.
>>> Chaque partie a de vrais arguments dont certain sont basés sur
>>> l'expérience et il serait dommage de faire perdre des forces au
>>> projet par un "forck" ou même seulement une branche qui risque de
>>> finir par dire les 5 lettres à l'autre :)  
>>> Nous serions ravi chez TECLIB' de vous donner de manière plus
>>> complète notre point de vue sur ce sujet, par rapport à ce que nous
>>> avons déjà réalisé sur Dolibarr mais aussi par rapport à d'autres
>>> projets libres auxquels nous participons.
>>>
>>> pascal
>>>
>>>
>>> Pascal Aubry
>>> Directeur TECLIB'
>>> Technologies libres pour l'entreprise  mob. : 06 37 87 92 30
>>>
>>> Le 15 août 2011 à 18:35, Jean Heimburger
>>> <address@hidden> a écrit :
>>>
>>>    
>>>> Donc il reste du boulot pour rendre le code plus CSS et faciliter le
>>>> travail de ceux qui veulent proposer des design...
>>>>
>>>> @+
>>>>
>>>> Philippe GRAND a écrit :
>>>>      
>>>>> Bonjour à tous
>>>>>
>>>>> Pour aller dans le sens de Régis, un petit exemple d'un casse tête
>>>>> lorsque le code html et le design sont mélangés au code php :
>>>>> je voulais compléter mon travail sur un thème "full CSS3" en
>>>>> reprenant les petites images de tri asc ou des sur les listes pour
>>>>> les remplacer par uniquement du code css3, sans image... mais le
>>>>> code de ce design est intégré à la fonction print_liste_field_titre
>>>>> (lib/functions.lib ligne 2584 et suivantes) :
>>>>> print '<img width="2"
>>>>> src="'.DOL_URL_ROOT.'/theme/common/transparent.png" alt="">';
>>>>>        if (! $sortorder)
>>>>>        {
>>>>>            print '<a
>>>>> href="'.$file.'?sortfield='.$field.'&sortorder=asc&begin='.$begin.$options.'">'.img_down("A-Z",0).'</a>';
>>>>>
>>>>>            print '<a
>>>>> href="'.$file.'?sortfield='.$field.'&sortorder=desc&begin='.$begin.$options.'">'.img_up("Z-A",0).'</a>';
>>>>>
>>>>>        }
>>>>> ... donc coincé :-\
>>>>>
>>>>> @+
>>>>> Philippe
>>>>>
>>>>> Le 15/08/2011 12:50, Régis Houssin a écrit :
>>>>>        
>>>>>> je reste persuadé qu'il faut séparer le traitement des données de la
>>>>>> vue, encore une fois je me répète, ce n'est pas forcement pour le
>>>>>> design, mais pour une meilleur facilité de personnalisation.
>>>>>> Imposer un
>>>>>> affichage dans le code est bloquant.
>>>>>>
>>>>>>
>>>>>> Le 15/08/11 10:56, Jean Heimburger a écrit :
>>>>>>             
>>>>>>> Mes réponses dans le texte
>>>>>>>
>>>>>>> @+
>>>>>>>
>>>>>>> Jean
>>>>>>>
>>>>>>> Régis Houssin a écrit :
>>>>>>>                 
>>>>>>>> Je mets en copie ce message afin d'avoir leurs avis:
>>>>>>>>
>>>>>>>>
>>>>>>>> Régis:
>>>>>>>>                      
>>>>>>>>>> Il va falloir un jour ou l'autre qu'on prenne la décision de
>>>>>>>>>> séparer
>>>>>>>>>> le php du html afin d'inclure un système de template, déjà pour
>>>>>>>>>> faciliter la personnalisation
>>>>>>>>>>                                    
>>>>>>>> Laurent:
>>>>>>>>                      
>>>>>>>>> Par exeprience cela ne facilite pas mais complique.
>>>>>>>>> Cela facilite quand tu as une équipe de dev et une equide de
>>>>>>>>> graphiste
>>>>>>>>> different. Quand ce sont les meme, cela a malheureusement plus
>>>>>>>>> d'inconvenient que d'avantage. Ce n'est pas factuel, c'est juste
>>>>>>>>> l'experience qui me fait dire cela.
>>>>>>>>>                              
>>>>>>>> Régis:
>>>>>>>> ce n'est pas forcement pour la partie graphique, mais plus pour
>>>>>>>> le côté
>>>>>>>> optimisation, par exemple, en l'état actuelle il est impossible de
>>>>>>>> développer une interface spécifique pour smartphone sans être
>>>>>>>> obligé de
>>>>>>>> dupliquer le code, et là ça devient très lourd à maintenir.
>>>>>>>>
>>>>>>>>                        
>>>>>>> La séparation dans les pages de la partie BDD de la partie
>>>>>>> affichage me
>>>>>>> paraît suffisante. L'est-elle pour une interface smartphone ?
>>>>>>> Est-ce qu'un CSS spécifique ne suffirait pas ?
>>>>>>> Bien sûr il reste peut-être des anciennes pages à revoir
>>>>>>> La question que je me pose : vu les écrans avec beaucoup d'infos de
>>>>>>> Dolibarr, qui va faire sa gestion via smartphone ?
>>>>>>>
>>>>>>>                 
>>>>>>>> Régis:
>>>>>>>>                      
>>>>>>>>>> et pour améliorer le design, car bon nombres de personnes, que
>>>>>>>>>> ce soit
>>>>>>>>>> des clients, des utilisateurs, des développeurs ou des
>>>>>>>>>> partenaires se
>>>>>>>>>> plaignent du code ou du design.
>>>>>>>>>>                                    
>>>>>>>> Laurent:
>>>>>>>>                      
>>>>>>>>> Il y en aura toujours quoi que tu fasses. Il vaut mieux des
>>>>>>>>> plaintes et
>>>>>>>>> un code facilement maintenable plus des ihm evolués que du code
>>>>>>>>> "puristes" qui fait bon genre pour les moyennement initiés et
>>>>>>>>> un projet
>>>>>>>>> ralenti.
>>>>>>>>>
>>>>>>>>> Ce n'est pour moi pas un argument. Bien au contraire. Cela ils
>>>>>>>>> sont
>>>>>>>>> souvent contreproductif (certes en php un peu moins que les
>>>>>>>>> puristes
>>>>>>>>> java, mais la tendance est la meme, l'amplitude est juste plus
>>>>>>>>> limité).
>>>>>>>>>
>>>>>>>>> De nombreux projet ont cédés à ces erreurs pour les meme motif
>>>>>>>>> (à savoir
>>>>>>>>> parce que des puristes sortis d'ecole on convaincu de passer
>>>>>>>>> dans le
>>>>>>>>> coté obscur). Aujourd'hui ce sont devenu des projets impossible à
>>>>>>>>> maintenir ou difficile a faire evoluer (oscommerce, prestashop
>>>>>>>>> sont de
>>>>>>>>> vrais usines à gaz quand il faut trouver un bug) et tu as tout
>>>>>>>>> autant de
>>>>>>>>> mécontent, et meme plus d'ailleurs (C'est juste l'autre camp,
>>>>>>>>> celui des
>>>>>>>>> plus pragmatique et moin spuristes dans ce cas qui critique).
>>>>>>>>> Bref, il y
>>>>>>>>> aura toujours un camp pour critiquer en masse. Et plus le
>>>>>>>>> produit sera
>>>>>>>>> populaire, plus il y en aura. L'archi doit etre en phase avec son
>>>>>>>>> contexte de travail et un objectif de productivité et
>>>>>>>>> stabilité, pas
>>>>>>>>> avec un objectif de "état de l'art".
>>>>>>>>> Pour moi la décision est prise de longue date: Non Dolibarr ne
>>>>>>>>> sera pas
>>>>>>>>> une usine a gaz dans son code, car cela signifierait un projet
>>>>>>>>> 2 à 3
>>>>>>>>> fois moins actifs (la preuve c'est qu'en l'état, Dolibarr évolue
>>>>>>>>> beaucoup plus vite que tous les autres projets équivalent du
>>>>>>>>> meme genre,
>>>>>>>>> ce n'est pas un hazard).
>>>>>>>>> Des templates peuvent se faire mais avec parcimonie et
>>>>>>>>> uniquement pour
>>>>>>>>> des parties communes d'écrans (des boxes, des zones bien
>>>>>>>>> identifiés),
>>>>>>>>> etc. Cela doit servir a mutualisé le code, et pas à faire
>>>>>>>>> plaisir à ceux
>>>>>>>>> qui ne connaissent que le html.
>>>>>>>>>
>>>>>>>>> Pour un systeme de template, il vaut mieux crer un fork. Car
>>>>>>>>> j'en suis
>>>>>>>>> convaincu pour en avoir experimenté des tonnes de projets dans
>>>>>>>>> ce sens
>>>>>>>>> au niveau professionnel, c'est la mort d'interfaces évolués, et la
>>>>>>>>> galere pour les développeurs, l'acroissement de bugs aussi des
>>>>>>>>> qu'on
>>>>>>>>> insere de l'ajax ou du javascript. Je suis d'accord que pour les
>>>>>>>>> htmlistes c'est mieux, mais on fait une appli de gestion, par
>>>>>>>>> un outil
>>>>>>>>> pour ceux qui ont un CAP de photoshop donc la priorité doit
>>>>>>>>> etre mis
>>>>>>>>> pour faciliter l'analyse de code sans jeu de piste au devant de la
>>>>>>>>> partie IHM.
>>>>>>>>>
>>>>>>>>>                              
>>>>>>>> Régis:
>>>>>>>> le problème avec le fork c'est que si on revoit le code en
>>>>>>>> profondeur
>>>>>>>> pour intégrer un système de template il sera difficile de
>>>>>>>> maintenir une
>>>>>>>> synchronisation entre les deux projets. A moins d'en faire un
>>>>>>>> projet
>>>>>>>> destiné au entreprises désireuses d'avoir un suivi et un support
>>>>>>>> payant,
>>>>>>>> c'est justement la discussion qu'on va avoir pendant la réunion
>>>>>>>> skype
>>>>>>>> début septembre.
>>>>>>>>
>>>>>>>>                        
>>>>>>> Dolibarr est un outil de gestion qui fonctionne via une IHM web,
>>>>>>> pas un
>>>>>>> site qui doit obligatoirement incorporer les dernières
>>>>>>> innovations en
>>>>>>> matière web design. Rester le plus standard et clair possible. Le
>>>>>>> design
>>>>>>> devrait pouvoir être géré par des CSS, cela donnerait déjà assez
>>>>>>> d'occasion pour les amateurs  de design de s'occuper...
>>>>>>> C'est aussi aux prestataires de convaincre les clients sur
>>>>>>> l'utilité du
>>>>>>> produit pour la gestion, et que le design est clair, même s'il
>>>>>>> n'est pas
>>>>>>> selon les dernières modes imposées par de grands groupes.
>>>>>>> Ajax et javascript doivent être des outils au service des fonctions
>>>>>>> (alléger des requêtes HTML, éviter de recharger une page entière,
>>>>>>> valider les saisies coté navigateur au lieu d'attendre que le
>>>>>>> serveur
>>>>>>> renvoie une erreur ...) et non pas exclusivement du design.
>>>>>>>                 
>>>>>>>> Régis:
>>>>>>>>                      
>>>>>>>>>>  Autre point, supprimer le menu eldy, trop lourd a maintenir avec
>>>>>>>>>> auguria.
>>>>>>>>>>                                    
>>>>>>>> Laurent:
>>>>>>>>                      
>>>>>>>>> C'est le fait d'avoir 2 menus utilisant des archi differentes
>>>>>>>>> qui permet
>>>>>>>>> de valider que le mécanisme de menu est bien indépendant et
>>>>>>>>> "souple".
>>>>>>>>> C'est vrai que c'est du boulot en plus, mais je préfère le
>>>>>>>>> garder ici
>>>>>>>>> juste pour garantir que cette qualité reste conservée.
>>>>>>>>> Par contre, je vais sortir tous les autres qui eux ne servent à
>>>>>>>>> rien car
>>>>>>>>> sont justes des copies de eldy, sauf qu'ils ne sont pas
>>>>>>>>> maintenus et ont
>>>>>>>>> plein de petit défaut.
>>>>>>>>>
>>>>>>>>> Il faut inviter ceux qui veulent revoir les ihm a faire un
>>>>>>>>> fork. Cela
>>>>>>>>> evitera de perturber le projet et si vraiment cela marche on
>>>>>>>>> pourra
>>>>>>>>> recopier. Faire des ihm avec des templates c'est faciles, faire
>>>>>>>>> des ihm
>>>>>>>>> évolués comme on a déjà et tres dynamiques selon le contexte et
>>>>>>>>> les
>>>>>>>>> données, c'est une mission suicidaire en mode full templates.
>>>>>>>>>                              
>>>>>>>>                        
>>>>>>> Quelles sont les spécificités des deux systèmes de menu ?
>>>>>>>
>>>>>>>
>>>>>>>                 
>>>>>>>> Cordialement,
>>>>>>>>                        
>>>>>>> Personnellement, je trouve qu'on doit veiller à enrichir Dolibarr en
>>>>>>> fonctionnalités qui lui manquent pour qu'il soit encore mieux
>>>>>>> adoptés
>>>>>>> par des entreprises, plutôt que perdre du temps, des ressources,
>>>>>>> et de
>>>>>>> l'énergie pour colorer et faire clignoter une IHM, juste parce
>>>>>>> que tel
>>>>>>> gourou a fait quelque chose de sympa...
>>>>>>> (Quelques suggestions : inclure une notion de famille dans la
>>>>>>> gestion
>>>>>>> des produits, un système de déclinaisons de produits à partir d'un
>>>>>>> modèle, séparer dans la gestion des contacts un libellé du nom,
>>>>>>> ajouter
>>>>>>> une notion de type de client (ex client société CEE, client
>>>>>>> export... ),
>>>>>>> le remboursement des avoirs, une fonction de retour et d'échange de
>>>>>>> produits...)
>>>>>>> Dolibarr est avant tout un outil de travail, et pour
>>>>>>> l'utilisateur au
>>>>>>> quotidien, il faut des fonctions qui apportent les réponses à ses
>>>>>>> besoins, réponses clairement présentées, faciles à lire. Le reste
>>>>>>> ne me
>>>>>>> parait pas fondamental.
>>>>>>> Les IHM proposées sont pas mal du tout.
>>>>>>> Moi je travaille avec Eldy que je trouve claire et qui me
>>>>>>> convient, je
>>>>>>> vois des clients qui utilisent Auguria, la 3.1 amène Carméléo qui
>>>>>>> renouvelle bien, je crois que la plupart peut y trouver son compte.
>>>>>>> Il faut arrèter le dictat des IHM, tout en veillant à faire quelque
>>>>>>> chose de propre, clair, adapté aux fonctions dont les
>>>>>>> utilisateurs ont
>>>>>>> besoin.
>>>>>>>
>>>>>>>
>>>>>>>                  
>>>>>> Cordialement,
>>>>>>              
>>>>> -- 
>>>>> Atoo.Net <http://www.atoo-net.com>     Philippe GRAND
>>>>> 265 rue de la vallée
>>>>> 45160 Olivet
>>>>> 02 38 63 90 20
>>>>> address@hidden
>>>>>
>>>>>         
> 
> 


Cordialement,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
30, quai de Verdun
71700 Tournus
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/
---------------------------------------------------------

regis_houssin.vcf
Description: Vcard