Le menu permettant d'afficher les icones à l'opposé du bouton applications est quelque peu dommage,
C'est dommage pour ceux qui veulent utiliser un paradigme qui n'est pas celui utilisé par le reste de l'environnement. Pour l'utilisateur, cela n'a aucun impact sur son utilisation.
d'ailleurs une extension permet déjà de changer cette position
C'est le rôle des extensions de rajouter tout et n'importe quoi selon les souhaits des utilisateurs, même quand ces souhaits s'opposent au paradigme de départ.
Ce qui est relativement amusant, c'est que la critique d'un choix faire par les développeurs est automatiquement rejetée en expliquant que la solution retenue est meilleure pour diverses raisons clairement établies et logiques.
Ce qui est relativement amusant, c'est que quand qlq'un dit: "ce serait bien que les tags fonctionnent mieux, que les versions ne brisent pas la compatibilité des extensions (ou au moins le notifie) et que le menu permettant d'afficher les icones soit à l'opposé du bouton applications" et qu'on répond: "d'accord pour les deux premiers, pour le troisième, je trouve que ça apporte plus d'avantage que d'inconvénient", la personne conclut que la critique est automatiquement rejetée.
Tu as 2 critiques sur 3 qui sont considérées comme valides. Mais non, c'est pas assez pour toi: si tu n'as pas 100% raison, c'est forcément que les autres sont bornés.
(sinon, oui, j'ai un biais: à force d'entendre les critiques basées sur une utilisation particulière sans tenir compte du paradigme général de l'environnement et proposant des solutions défavorisant ce paradigme, j'ai tendance à avoir un apriori négatif par rapport à ce genre de critique. je suis utilisateur de kde, mais c'est juste triste de voir une idée nouvelle (qui ne convient pas à mon usage, mais pourquoi interdire tout les usages différents du mien) partir en vrille parce que tout le monde veut lui rajouter sa feature au détriment d'une vision globale)
pour diverses raisons clairement établies et logiques.
En quoi le fait que le déplacement de la souris soit plus long dans des cas où le flux d'action est forcément ralenti par autre chose est une bonne raison.
Je trouve que la raison "défavorisé une utilisation qui va au final mettre l'utilisateur en porta-faux" est une raison clairement établie et logique.
nous verrons si mon argumentation est absurde d'ici quelques temps.
Étant donné la pression de la communauté dès qu'un développeur adopte un paradigme qui ne correspond pas à un groupe d'utilisateur particulier, cela ne m'étonnerait pas que ça soit changé. Cela ne veut pas dire que ce sera mieux.
Ploum a écrit un article sur l'"usabilité" aujourd'hui. Je suis d'accord avec un des commentaires qui parle de la loi de futilité de Parkinson (qui correspond très bien: ici, on se plaint d'un déplacement de souris plus long lors de cas où le flux d'action est de toutes façons ralenti par d'autres obstacles). C'est à mon avis le principal frein à la réalisation d'outil libre pratique pour l'utilisateur: lorsqu'un développeur dit "on va aller à gauche", il faut toujours que certains dans la communauté réagissent: "houlà, il est très important que ce détail là aille à droite".
[^] # Re: Comparaison de menus Unity/GnomeShell/elementary
Posté par j-c_32 . En réponse au journal GNOME, c'est Apple et Ubuntu c'est Android (Vendredi inside). Évalué à -1.
C'est dommage pour ceux qui veulent utiliser un paradigme qui n'est pas celui utilisé par le reste de l'environnement. Pour l'utilisateur, cela n'a aucun impact sur son utilisation.
C'est le rôle des extensions de rajouter tout et n'importe quoi selon les souhaits des utilisateurs, même quand ces souhaits s'opposent au paradigme de départ.
Ce qui est relativement amusant, c'est que quand qlq'un dit: "ce serait bien que les tags fonctionnent mieux, que les versions ne brisent pas la compatibilité des extensions (ou au moins le notifie) et que le menu permettant d'afficher les icones soit à l'opposé du bouton applications" et qu'on répond: "d'accord pour les deux premiers, pour le troisième, je trouve que ça apporte plus d'avantage que d'inconvénient", la personne conclut que la critique est automatiquement rejetée.
Tu as 2 critiques sur 3 qui sont considérées comme valides. Mais non, c'est pas assez pour toi: si tu n'as pas 100% raison, c'est forcément que les autres sont bornés.
(sinon, oui, j'ai un biais: à force d'entendre les critiques basées sur une utilisation particulière sans tenir compte du paradigme général de l'environnement et proposant des solutions défavorisant ce paradigme, j'ai tendance à avoir un apriori négatif par rapport à ce genre de critique. je suis utilisateur de kde, mais c'est juste triste de voir une idée nouvelle (qui ne convient pas à mon usage, mais pourquoi interdire tout les usages différents du mien) partir en vrille parce que tout le monde veut lui rajouter sa feature au détriment d'une vision globale)
En quoi le fait que le déplacement de la souris soit plus long dans des cas où le flux d'action est forcément ralenti par autre chose est une bonne raison.
Je trouve que la raison "défavorisé une utilisation qui va au final mettre l'utilisateur en porta-faux" est une raison clairement établie et logique.
Étant donné la pression de la communauté dès qu'un développeur adopte un paradigme qui ne correspond pas à un groupe d'utilisateur particulier, cela ne m'étonnerait pas que ça soit changé. Cela ne veut pas dire que ce sera mieux.
Ploum a écrit un article sur l'"usabilité" aujourd'hui. Je suis d'accord avec un des commentaires qui parle de la loi de futilité de Parkinson (qui correspond très bien: ici, on se plaint d'un déplacement de souris plus long lors de cas où le flux d'action est de toutes façons ralenti par d'autres obstacles). C'est à mon avis le principal frein à la réalisation d'outil libre pratique pour l'utilisateur: lorsqu'un développeur dit "on va aller à gauche", il faut toujours que certains dans la communauté réagissent: "houlà, il est très important que ce détail là aille à droite".