Version imprimable
Bonjour.
Je vois souvent sur les logiciels des jeux vidéos les avertissements disant que leur usage peut provoquer les troubles de vue. J'imagine donc que les mêmes troubles peuvent être provoquées par des sites web ordinaires, utilisant les animations ou non.
Quelqu'un connait-il une ressource qui explique quels sont les troubles possibles et comment les éviter pour un designer ?
heu,Citation:
Envoyé par MainMa
les troubles indiqués sur les boîtes de jeux vidéo, sont là comme indication. Elles servent à prévenir d'un abus d'utilisation dans de mauvaise condition.
Donc, ta question à mon sens n'a pas lieu d'être posé puisque tu ne va pas rester 10h devant le même site web sur ton écran.
PS: La seule question à se poser est donc est ce que mon travail est regardable ou non?
Ah bon ? Ah, c'est pas ce que j'ai compris.Citation:
Envoyé par Vil'Coyote
Moi, je croyais que chez certaines personnes, c'est le fait de voir, même pendant un court laps de temps, une image ou une animation qui peut provoquer des troubles. Il s'agit par exemple des lignes de couleur opposée mises cote à cote, d'une spirale qui tourne sur elle-même, etc.
Ca dépend. Si c'est un site intranet, un salarié peut bien y passer 35 heures par semaine dessus. Si c'est un site web ordinaire, alors là, oui, forcement, y a peu de risque.Citation:
puisque tu ne va pas rester 10h devant le même site web sur ton écran
epilepsie?Citation:
Envoyé par MainMa
mon extranet est ouvert plus de 40 h par semaine mais n'est consulter réellement qu'une 1h par jour donc bon je pense toujours que ce genre de question n'est pas forcément pertinente .Citation:
Envoyé par MainMa
Je sais pas justement. C'est ça le problème. En regardant sur Wikipedia, j'ai pas vraiment vu ce qui peut provoquer une épilepsie dans ce contexte-là.Citation:
Envoyé par Vil'Coyote
Ce n'est qu'un cas particulier. Je n'ai pas dit que tout site extranet sera utilisé en permanence. Et c'est vrai que ce genre d'utilisation est rare, même aujourd'hui, lorsque certains font, à tort, un site intranet à la place d'un logiciel.Citation:
mon extranet est ouvert plus de 40 h par semaine mais n'est consulter réellement qu'une 1h par jour donc bon je pense toujours que ce genre de question n'est pas forcément pertinente .
En parlant de ça, deux cas me viennent à l'esprit :
- Le personnel des boutiques des opérateurs téléphoniques ou FAI, dont le travail consiste majoritairement à accueillir le public et faire les manipulations nécessaires sur un site intranet,
- Le personnel des SAV qui répond aux appels téléphoniques, et est amené à ce titre de travailler en permanence sur un site intranet.
Ah oui, le fameux "Avertissement sur l'épilepsie" des jeux vidéos. « élipepsie », comme je lisais ça il y a quelques années :aie:Citation:
Envoyé par Vil'Coyote
L'épilepsie est un problème neurologique, qui se manifeste surtout en cas de fatigue ou de nervosité.
Dans la mesure où la lecture sur écran fatigue fort les yeux, à cause notamment du rétro-éclairage et de la faible résolution par rapport à l'imprimé, oui, ça peut causer des crises d'épilepsie. Ce n'est pas lié au site web, mais aux écrans.
Cela dit, il y a des millions de gens qui travaillent 12h par jour sur pc (à commencer par les informaticiens) et qui n'ont aucun souci pour autant. D'ailleurs, plus les années passent, moins les écrans sont désagréables à lire : de CRT on est passé à LCD, puis on a inventé l'affichage sous-pixellaire, et les résolutions continuent à augmenter.
Si tu fais un intranet flashi et clignottant de partout, et que les gens doivent y bosser 35h par semaine, tu vas te faire des ennemis. C'est précisément le cas où il faut bien travailler le confort.Citation:
Envoyé par MainMa
Pourquoi « à tort » ? Il existe de vraies applications web, et c'est largement plus facile à déployer que des application desktop.Citation:
Envoyé par MainMa
Merci. Cela répond à ma question.
Justement, cette facilité de déploiement ou les raisons liées aux licences fait que souvent, quelque chose dont l'utilisation est limitée à l'entreprise est fait sous forme d'un site, au détriment de l'utilisateur final, celui-ci étant alors tenu d'utiliser une interface dont l'interactivité est beaucoup plus pauvre.Citation:
Envoyé par Antoine_935
Certes, lorsqu'un logiciel est fait par des personnes incompétentes sans intervention des spécialistes en interaction design, ce logiciel sera désagréable et peu pratique à utiliser, comme c'est très souvent le cas. Mais c'est d'autant plus vrai pour les sites web avec leurs contraintes propres.
Note : bien entendu, je parle uniquement des sites web, pas des RIA, qui sont un tout autre sujet.
Quelle interactivité manque-t-il aux applications web ? Après tout, les deux types d'applications sont très proches : une interface qui réagit aux clics sur des boutons et à ce qu'on tape dans des boites de texte.Citation:
Envoyé par MainMa
Après, que le bouton passe par 36 transitions qui font qu'il a l'air se s'enfoncer graduellement, ça n'apporte pas grand chose niveau fonctionnalités.
Je vois mal de quoi on manque, pour être honnete. C'est sans doute du à la fatigue de la journée, note. M'éclairerais-tu d'un exemple ?
Quelques exemples de tête, surement pas les meilleurs :Citation:
Envoyé par Antoine_935
1. Drag&drop : il est nettement plus difficile à implémenter dans un site web, donc est souvent mis à part (ou bien résulte dans le fait que seule la version JavaScript de l'application est développée, ce qui fait qu'elle a une accessibilité de zéro).
2. Cross-app drag&drop : peut-être l'exemple le plus flagrant, puisqu'il est impossible dans un site web de glisser les éléments entre plusieurs sites ou entre l'OS et le site ou l'application et le site (sauf à utiliser RIA avec Silverlight 4).
3. Sélection multiple : à savoir une sélection de plusieurs éléments de l'interface d'un clic de souris. Exemple : sélection des cellules dans Excel. Exemple 2 : sélection des fichiers dans explorer. Une sélection de plusieurs éléments via la souris peut souvent être très compliquées à faire, ce qui fait que le plus souvent, on se limite aux cases à cocher. Quitte à l'utilisateur de cliquer trente fois lorsqu'il a besoin de sélectionner trente éléments consécutifs. Les solutions intermédiaires, moins intuitives, existent (t.q. sélection des courriels multiples dans GMail), mais sont rarement faites dans des sites intranet.
4. Sélection rectangulaire : c'est-à-dire la sélection d'une zone rectangulaire de texte avec Alt appuyé. À ma connaissance, ce n'était jamais utilisé dans aucun site web. Si quelqu'un connait un exemple contraire, je suis curieux de savoir comment ceci avait été fait.
5. Filtrage des éléments : dû à la latence et au caractère compliqué (effacer les éléments qui ne correspondent pas au filtre → AJAXer les nouveaux → afficher les nouveaux), il n'y a souvent aucun filtrage fait ou il reste basique et lent. Highlight lui aussi est quasiment inexistant, dû encore une fois à la difficulté d'implémenter la chose.
6. Accès aux fichiers : un site web ne peut lister les fichiers ou les lire (encore heureux !). Dès lors les scenarii d'importation de plusieurs fichiers en indiquant juste le dossier sont impossibles.
7. Écrans : pas de plein écran pour les sites web (même si personne n'interdisait le F11). Pas de possibilité d'utiliser plusieurs écrans (et là, on y peut rien, sauf à passer par RIA).
8. Zoom. Un analogue de DeepZoom par exemple. Possible (Google Maps) mais pas simple de faire sans RIA. A fortiori lorsqu'il s'agit de zoomer non les images, mais aussi le texte. Ceci réduit considérablement les possibilités de voir et de rechercher les éléments dans un site web.
9. Copie complexe : exemple classique : copie d'un numéro de série à vingt-cinq caractères en un seul Ctrl+V dans cinq champs texte. L'implémentation des copies complexes est difficile à faire dans un site web, et est donc souvent omise. Ce qui en pratique résulte dans le fait que les employés perdent bêtement leur temps à entrer à la main les éléments dans des champs.
10. Latence : sans doute l'élément qui aurait dû être classé en premier et qui est clairement lié à l'interactivité-même. Dans un site web business ordinaire, il faut s'attendre à 200 ms. au minimum de latence AJAX, alors que ce temps peut être quasiment inexistant ou de l'ordre de quelques dizaines de millisecondes pour une application desktop. Si sur un site web grand public, ceci ne pose pas d'inconvénients majeurs, le cas est tout autre pour un outil qu'une personne utilise 35 heures par semaine, et où toute latence devient lourde à supporter.
Heureusement, les patterns action → réponse visuelle → AJAX → changement de réponse visuelle si besoin commencent à apparaitre même sur des sites grand public (t.q. StackOverflow par exemple), mais ceci reste hélas très limité.
11. Connexions : le fait de pouvoir tracer des connexions entre objets requiert quasiment toujours de recourir au dessin. Or le dessin est impossible dans un site web (même pour dessiner une simple ligne, il faut recourir aux procédés bien peu élégants). Dès lors, la manipulation des connexions entre éléments est impossible, et est contournée au mieux par drag&drop, au pire par les combo-boxes ou autres processus difficiles et/ou peu intuitifs.
D'une manière générale, suffit de prendre les exemples existants d'applications business et les imaginer en version web. Les différences seront plutôt minimes pour des applications business faites par des personnes qui ne s'y connaissent rien, mais il y a clairement des bons exemples à trouver en prenant des applications professionnelles.
À part : chose curieuse, je constate de plus en plus que même parmi des systèmes faites par des développeurs seulement (càd. sans intervention des spécialistes en interaction design), les logiciels d'entreprise sont souvent un peu moins horribles à utiliser que des sites intranet. Surement que l'aspect web rend plus compliqué même à ce niveau la création d'une interface.
Le Drag&Drop vient avec des risques de mauvaise utilisabilité: c'est une fonctionnalité « transparente », et donc difficile à découvrir. Et si vraiment tu en as besoin, jQuery existe.Citation:
Envoyé par MainMa
jQuery à la rescousse... http://jqueryui.com/demos/selectable/Citation:
3. Sélection multiple
Et même sans, il existe des centaines de manières de faire un système de sélection efficace.
J'ai déjà vu ça quelque part sur le web. jQuery toujours.Citation:
4. Sélection rectangulaire
Le problème est exactement le même sur des applications desktop :*transmettre les nouveaux critères au serveur, recevoir les données sérialisées, les désérialiser, les afficher. Même bataille.Citation:
5. Filtrage des éléments
Modèle cloud à la rescousse. C'est sur que mixer les apps web avec le desktop, c'est pas la meilleure chose à faire. Mais même encore, on peut s'en sortir.Citation:
6. Accès aux fichiers
Seules les applications très spécifiques ont besoin de plein écran.Citation:
pas de plein écran
Ah si, il suffit d'ouvrir deux fenêtres du navigateur. C'est d'ailleurs un des grands points fort du web.Citation:
Pas de possibilité d'utiliser plusieurs écrans (et là, on y peut rien, sauf à passer par RIA).
Encore une fois, les 9/10 des applications n'ont pas besoin de zoom. Et pour le reste, il y a jQuery. De plus, avec l'arrivée du HTML5 et des transitions CSS, on pourra même bientôt se passer de javascript.Citation:
8. Zoom
Sur l'application web de la banque dans laquelle j'ai fait un job d'étudiant (sous IE6), c'était possible. IE6, c'est vieux et naze. Mais c'était possible.Citation:
9. Copie complexe
Ça ne dépend absolument pas du principe d'application web. C'est le réseau qui est en cause. Web ou desktop, c'est la même bataille.Citation:
10. Latence
Google l'a fait pourtant. Comme un tas d'autres personnes. Avec le SVG, c'est possible. Avec Flash, c'est possible. Avec Java, c'est possible. Avec Silverlight c'est possible. Je continue la liste ?Citation:
11. Connexions
Concernant tes deux derniers points, je ne suis pas d'accord du tout avec, comme pour le reste d'ailleurs.
Je crois que je me suis pas exprimé assez clairement, et je n'en excuse.
Le problème ne vient pas forcement des limitations techniques à proprement parler, mais du caractère manifestement compliqué de la chose, et du fait que à chaque fois qu'on ajoute du JavaScript, on est obligé de faire tout en double : une version sans, une version avec.
Le caractère compliqué fait donc que pour les sites intranet, l'interactivité est souvent mise en dernier point sur la liste des priorités. Quant à celui d'être obligé de faire tout en double, cela résulte dans le fait qu'en pratique, on fait juste une version basique, et on s'arrête là.
Oui, si possible, vu que j'ai clairement précisé que je parlais de sites intranet sans RIA, et que dans la liste actuelle il n'y a que des RIA et applications desktop.Citation:
Avec Flash, c'est possible. Avec Java, c'est possible. Avec Silverlight c'est possible. Je continue la liste ?