Bonjour,
mes réponses (qui n'engage que moi) dans le message vu le nombre de
questions.
Quelques remarques préliminaires :
- il faut bien penser que GLPI est un projet qui vie et évolue depuis 2003.
L'ensemble des évolutions ont été amenés par touches successives afin de
fournir aux utilisateurs des évolutions constantes.
Les modifications de fond se font donc en parallèle des avancées
fonctionnelles. C'est une volonté du projet, mais on pourrait dire
aujourd'hui on arrête tout, a dans 2 ans pour GLPI 2.0... Je ne pense
pas que ce soit ce que les utilisateurs de GLPI attendent.
- GLPI est perfectible sur beaucoup de points. Au niveau technique cela
s'explique par la volonté exposée plus haut.
De très nombreuses améliorations du framework ont été apportées ces
dernières années mais le chemin est encore long avant d'avoir vraiment
quelque chose de complètement satisfaisant. Le chemin est d'autant plus
long que le nombre de contributeurs est faible, que ce soit des
développeurs, des concepteurs (spécifications), des traducteurs, des
rédacteurs de documentation...
Plus on est de fous plus on rit dit l'adage mais c'est vrai. Nous avons
toujours été ouverts a toutes les remarques constructives et toutes les
contributions. Nous ne prenons donc pas mal un mail comme celui que vous
avez écrit, c'est ce genre de chose qui fait avancer le schmilblik.
Le 05/01/2012 20:09, Nicolas Monnet a écrit :
== A. Questions sur le style du code ==
1. Dans index.php par exemple:
// Start the page echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML
1.0 Strict//EN" '.
'"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>'."\n";
Pourquoi ne pas simplement fermer le tag php? Je croyais que PHP etait
fait pour ca.
C'est un choix de programmation. Personnellement je n'écris plus depuis
très longtemps du PHP sans ouvrir le tag au début du fichier et le
fermer à la fin. Ce que vous proposez peut être intéressant quand on
veut intégrer un peu de PHP dans du HTML.
Hors GLPI c'est plutôt l'inverse, beaucoup de PHP pour générer du HTML.
Cela permet aussi d'avoir un tout uniforme quand même très pratique
quand on veux relire du code.
2. Repetitions dans html.class.php:
Déjà discuté je passe.
3. Toujours dans html.class.php, ne serait-il pas possible de faire en
sorte que le code specifique a chaque module soit defini dans la classe
du module, plutot que d'avoir une classe "Header" de 2000 lignes?
Déjà discuté je passe.
== B. git ==
Déjà discuté je passe.
== C. Design UI ==
La j'ai un certain nombres de critiques, mais ne les prenez pas mal,
je trouve que QLPI ne se debrouille pas trop mal pour un logiciel de
ce type par rapport a la moyenne. Je me base sur la version 0.80.x,
il se peut que certaines choses aient change.
- Pagination des listes. Les choix 5. 10 et 20 servent-ils
a quelquechose? Imagine-t-on un use case ou un utilisateur
pourrait vouloir 5 elements par page, voire meme 10 plutot que
20? Pourquoi ne pas carrement prendre une valeur tres grande
par defaut, de facon a decharger la mise en page d'un element.
Je ne comprend pas trop votre propos.
Quel est le problème de proposer des valeurs même si elles ne sont pas
utilisées par la majorité des gens ?
Dans certains cas de listing très haut (ordi + logiciels) cela évite de
scroller pendant 10 heures.
C'est un paramètre que l'utilisateur peut configurer, c'est donc à lui
de définir la valeur qui lui convient le mieux.
- Les selections par liste deroulante (<FORM><SELECT...>) sont
problematiques d'un point de vue de l'experience utilisateur,
principalement parcequ'elles cachent initialement l'information
a l'utilisateur. Il doit cliquer pour savoir ce qu'il peut
choisir. C'est un peu frustrant, et c'est a eviter parcequ'il
y a souvent des alternatives possibles:
+ Quand il n'y a pas de choix possibles, il ne faudrait pas
laisser croire a l'utilisateur que c'est le cas (verifie
dans GLPI, il y a des cas avec des listes deroulantes avec
un seul element); soit transformer en texte, soit griser.
L'ensemble des affichages se fait de manière générique et permet un
affichage uniforme.
Je ne suis pas persuadé que d'avoir des affichages différents en
fonction des possibilités de sélection ne soit pas plus perturbant que
la situation actuelle. Mais c'est un point à discuter et à arbitrer.
Sachant en plus que on a déjà plusieurs mode d'affichage si vous activez
ou non l'affichage dynamique.
De nombreuses évolutions des dropdowns sont envisagés sur les dropdown
pour les rendres plus souple d'utilisation.
Par exemple : https://forge.indepnet.net/issues/973
+ Quand le choix est binaire, une case a cocher a la meme
fonctionnalite, et peut s'y substituer dans certains cas
(mais pas tous)
Même fonctionnalité pour l'utilisateur oui mais pas du tout pour le
développeur.
Une case à cocher non sélectionnée n'est pas postée par un formulaire.
Hors nous effectuons des modifications partielles ou complètes hors
saisie par un formulaire complet.
Dans ce cas comment savoir que la case est cochée ou que ce n'est pas un
paramètre géré par la mise à jour en cours ?
Une évolution du framework pourrait permettre de résoudre ce problème :
https://forge.indepnet.net/issues/2842
Même si je pense que ca ne résoudrait pas tout.
+ Quand il y a une poignee de choix (2 a 5), un bloc de
boutons radio est pratiquement toujours preferable.
Peut-être mais il prend de la place. Place, qui dans certains
formulaires, est plus que précieuse.
Il n'y a aussi que très peu de liste à taille fixe.
L'ensemble des dropdowns étant pour la grande majorité modifiable.
De mémoire on a le même problème avec les radio que les checkbox exposé
plus haut.
- La mise en page ne fait pas un tres bon usage de la typographie,
par ex. tous les textes sont pratiquement a la meme taille.
Que proposez vous pour cela ? je n'ai pas spécialement d'avis sur le sujet.
- Usage un peu trop intensif des filets, en particulier dans
les tables, meme si la plupart sont en reserve. Pour separer les
lignes dans une table, on peut par exemple simplement laisser 20%
d'espace entre deux lignes.
Je ne vois pas trop non plus le soucis et la proposition que vous
faites. Peut-être que des screens seraient plus compréhensible.
- Redondance de la navigation et pour beaucoup de widget
Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ?
- Elements graphiques de taille fixe, exemple champs de texte
dans les formulaires.
Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ?
- Les quelques icones sont franchement ambigus (cf "voir
le contenu de la corbeille"). C'est d'autant plus genant que
certains ont une fonction importante.
Cette partie est en cours de révision dans la 0.84. Toute proposition
est la bienvenue.
- Il faudrait differencier autant que possible ceux qui ont un
effet de bord de ceux qui ne sont que de la navigation (cf a
nouveau voir la corbeille, on pourrait penser a priori qu'il
signifie _mettre_ a la poubelle).
Comment les différentier ? Le titre des icônes me semble là pour ca.
- Menu deroulant "Page courante en PDF paysage" -> cf remarque
precedente sur les listbox deroulantes; mais en plus ici on a un
effet de bord alors que ca a le look d'un element de formulaire
(aspect identique a "Afficher xxx elements" a sa gauche). Pour une
fois, meme si je n'aime pas trop les barres d'icones, on gagnerait
a utiliser ce format, d'autant plus qu'une feuille orientee d'une
facon ou d'une autre est plus parlante que "paysage" ou portrait.
Effectivement, c'est un élément à revoir.
Quoi qu'il en soit, glpi est un projet tres utile, et j'espere avoir la
possibilite de contribuer a l'avenir.
Merci, dans l'attente d'une future contribution ;)
Cordialement,
Julien Dombre
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
