Bonjour,
Nous utilisons GLPI en interne chez mon nouvel employeur, et je suis en
train de regarder le code pour voir si je pourrais contribuer certaines
ameliorations. Notez que je ne connais pas grand chose a PHP (plus a
l'aise en Perl/Javascript/Haskell).
== 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.
2. Repetitions dans html.class.php:
$menu['admin']['content']['rule']['options']['transfer']['title']=
__('Transfer');
$menu['admin']['content']['rule']['options']['transfer']['page'] =
"/front/transfer.php";
$menu['admin']['content']['rule']['options']['transfer']['links']['search']
=
"/front/transfer.php";
N'est-il pas possible en PHP de faire quelquechose comme:
$transfer = $menu['admin']['content']['rule']['options']['transfer'];
$transfer['title'] = __('Transfer');
$transfer['page'] = "/front/transfer.php";
$transfer['links']['search'] = "/front/transfer.php";
Ca limite les repetitions, et evite de depasser systematiquement 80
colonnes.
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?
== B. git ==
Avez-vous envisage de passer a git? Ca rendrait les contributions
nettement plus faciles. En l'occurence pour mon projet j'ai fait un
checkout avec git-svn, mais ca serait quand meme plus pratique si tout
etait deja sur github.com
== 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.
- 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.
+ Quand le choix est binaire, une case a cocher a la meme
fonctionnalite, et peut s'y substituer dans certains cas
(mais pas tous)
+ Quand il y a une poignee de choix (2 a 5), un bloc de
boutons radio est pratiquement toujours preferable.
- 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.
- 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.
- Redondance de la navigation et pour beaucoup de widget
- Elements graphiques de taille fixe, exemple champs de texte
dans les formulaires.
- 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.
- 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).
- 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.
Quoi qu'il en soit, glpi est un projet tres utile, et j'espere avoir la
possibilite de contribuer a l'avenir.
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
