Re: [Dolibarr-foundation-board] Installation wizard

[Jean Heimburger]

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.