In reply to: "MoYo" <m...@indepnet.net>
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.
C'est le cas pour index.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.
Dans les editeurs que j'utilise (en l'occurence Eclipse principalement)
la coloration syntaxique rend la chose plus lisible que la floppee
d'apostrophes et de guillemets.
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 ?
Les choix disponibles sont caches, l'utilisateur doit cliquer pour les
voir. Or le sens d'un widget n'est souvent evident que quand on connait les
choix possibles. Ca ne change pas grand chose quand on parle d'un seul
formulaire,
mais pour une application web ou il y a des douzaines de formulaires
avec des centaines de widgets, ca se traduit par beaucoup de confusion.
Dans certains cas de listing très haut (ordi + logiciels) cela évite de
scroller pendant 10 heures.
Scroller est 100x plus rapide que de cliquer "next" 20 fois. Qui plus
est tout afficher permet d'utiliser ^F. La seule raison pour limiter
cette taille est pour les utilisateurs sur des ordis tres tres faibles
(vintage 1999), mais honnetement, meme sur un smartphone, je n'ai jamais
constate de probleme avec des listes de plusieurs milliers de ligne, en
tous cas avec un navigateur suffisament recent.
C'est un paramètre que l'utilisateur peut configurer, c'est donc à lui
de définir la valeur qui lui convient le mieux.
Ca encombre l'interface a chaque page avec un reglage qui n'est change
qu'une fois. Ce n'est pas un probleme technique, c'est une question
d'ergonomie.
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.
Je suis d'accord que ca peut poser des problemes d'alignement et de mise en
page.
Cela dit il faut voir ce que ca donne pour comprendre a quel point c'est
exactement le contraire de perturbant pour l'utilisateur. Face a des boutons
radio, l'utilisateur sait immediatement les choix disponibles et l'information
qu'on attend de lui. J'avais ainsi implemente un script greasemonkey pour Jira
qui faisait la transformation automatique, je ne retrouve malheureusement pas
mes screenshots mais j'essayerai de trouver quelquechose pour illustrer le
propos.
Sachant en plus que on a déjà plusieurs mode d'affichage si vous
activez
ou non l'affichage dynamique.
Je ne sais pas ce que c'est.
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 ?
Dans ce cas une paire de boutons radio ferait l'affaire.
> + 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.
J'avais reussi a regler le probleme de la taille dynamique dans le script GM
mentionne plus haut, ca n'est pas un si gros probleme honnetement; la mise en
page en est un en effet.
Que proposez vous pour cela ? je n'ai pas spécialement d'avis sur le
sujet.
Je ferai un mockup pour donner un exemple.
Je ne vois pas trop non plus le soucis et la proposition que vous
faites. Peut-être que des screens seraient plus compréhensible.
C'est un point de vue de graphiste. Les filets alourdissent la vision globale et
nuisent a la lecture rapide. Regardez un ecran avec un peu de recul, vous ne
voyez que les filets. Remplacez les filets par un peu plus d'espacement, et
le contenu prend le dessus.
Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ?
Il y a plusieurs facons d'arriver au meme endroit. Si je veux aller a l'
inventaire des cartouches, je peux:
1. Cliquer sur inventaire, puis cliquer sur cartouches
2. Mouse over sur inventaire, puis cliquer sur catouches dans le menu deroulant
3. Cliquer sur l'icone "menu_all.png" puis cliquer sur cartouches
Or ces 3 possibilites sont situees pratiquement au meme endroit, fonctionnant
sur des modes pratiquement identiques; a differencier des raccourcis claviers
ou gestes souris par exemple.
Ca n'est pas un enorme probleme mais ca complexifie l'interface pour un
benefice quasi-nul.
Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ?
Par exemple, si je veux ajouter un ordinateur dans l'inventaire, le textarea
"commentaires" fait la meme taille que ma fenetre soit 640x480 ou que je sois
en fullscreen sur un 24"
Comment les différentier ? Le titre des icônes me semble là pour ca.
Vous voulez parler du text en hover? Ca demande de poser le pointeur sur l'
icone et d'attendre, et donc ca n'est pas evident a premiere vue, et qui plus
est est incompatible avec les touchscreens (ipad, smartphone ...)
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
