Oui, les objets intermédiaires sont une bonne chose.
Par contre, la conception de ce type d'objet doit permettre des
interactions.
Cordialement
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 16/08/2011 09:23, Jean Heimburger a écrit :
Oui
c'est vrai, on peut certainement plus mutualiser et créer plus
d'objets réutilisables. Encore faut-il les réutiliser... On en
a déjà quelques outils pour afficher un formulaire, un dropdown,
une date... des objets de relativement bas niveau, et des
squelettes de page, de classe, de script... Pourquoi pas créer
des objets intermédiaires qui permettent de créer une liste (les
pages liste.php), une fiche (les pages fiches.php), sous forme de
boites qui se positionneraient comme des blocs (ou des onglets
d'ailleurs) ensuite dans le template de page.
Le tout c'est de faire l'objet et qu'il réponde à la plupart
des cas pour qu'il soit utilisable, simple pour qu'il soit
facilement compréhensible et enfin le documenter pour le faire
utiliser aux développeurs. Un élémént clé est la documentation,
encore plus que le code.
@+
Jean
Régis Houssin a écrit :
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=""
alt="">';
if (! $sortorder)
{
print '<a
href="">'.img_down("A-Z",0).'</a>';
print '<a
href="">'.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,
|