Un détail agaçant...

[esox_13]

On peut aussi créer son propre onglet personnalisé où on met tous ses outils habituels.

Je trouve qu'il y a s'autres problèmes plus embêtants sur C1 que ça ! Comme par exemple la lenteur à reprendre la main quand on sélectionne un tiff multi-calques, ou bien des bizarreries qui se produisent un jour et pas le lendemain... Principalement, sur Mac, parfois on se tape la roue multicolore pendant 1 ou deux minutes lors de la sélection d'images pourtant non modifiées. On relance C1 et parfois ça rentre dans l'ordre, ou pas, ou parfois il faut relancer l'ordi... Ou encore le catalogue. Mais ceci étant dit, quand je dois développer un raw je préfère C1 à LR, surtout pour des travaux où le travail doit être très précis au niveau colorimétrie, bruit ou gestion luminosité/contraste. Ayant le pack Adobe pour les photographes, je n'ai pas la version débridée de C1, je n'utilise que la version DB pour dos P1.

[Bélisaire]

Une discussion de plusieurs pages sur un détail aussi infime illustre combien on peut perdre de temps sur les forums !!

Indépendamment du sujet de ce fil, ce genre de "vérité" générale ne dit rien: quel que soit le sujet de la discussion, on peut toujours trouver quelqu'un pour déclarer "combien on peut perdre de temps sur les forums".

[Samoreen]

...qu'un utilisateur demande que l'on réponde à un souci minime (un détail agaçant...) qui ne serait pas la priorité de la majorité de la communauté et qui ne répondrait en outre à aucune logique bien claire.

En fait, Bélisaire n'a rien demandé. Il l'a précisé plusieurs fois. Il a juste posé une question.

Les concepteurs ne prennent jamais assez en compte les besoins des usagers, et c'est à se demander si des études préliminaires sont faites à ce sujet.

Je crois qu'elles se limitent à la portion congrue (de même que les tests qualité). En la matière, la gestion de projet la plus intelligente que j'ai pu observer a concerné une application de guichet pour un de mes clients (La Poste), il y a déjà longtemps. L'équipe de développement a été divisée en 2 parties : une équipe IHM et une équipe traitement. L'équipe IHM a réalisé une maquette avec une proposition d'interface qui a été présentée dans différents bureaux de poste sur le terrain. Les responsables de la partie IHM n'étaient pas des développeurs à proprement parler mais des ergonomes. La maquette a été développée avec un langage de haut niveai particulièrement adapté à cette tâche. Aucun traitement n'était réellement implémenté, c'était juste de la simulation.

Les utilisateurs (les employés derrière les guichets) ont donné leur avis en fonction de leur contexte d'utilisation. Pendant ce temps, l'autre équipe développait les traitements, sans présumer de l'interface. Ils n'étaient d'ailleurs pas installés au même endroit. Au final, les 2 morceaux ont été connectés après réécriture complète de la partie IHM dans un langage plus performant mais avec des spécifications validées sur le terrain. Exemplaire.

Bien sûr, on ne peut pas faire ça avec une application grand public mais on doit pouvoir trouver autre chose que la détestable méthode aujourd'hui généralisée dite de "la version bêta payante", économiquement intéressante mais génératrice de frustration chez l'utilisateur. À ce moment-là, il est déjà trop tard. On ne peut plus faire autre chose que signaler les bugs.

[tenmangu81]

En fait, Bélisaire n'a rien demandé. Il l'a précisé plusieurs fois. Il a juste posé une question.

Exact  Je dirais même qu'il a juste fait une remarque.

[Bélisaire]

Je trouve qu'il y a s'autres problèmes plus embêtants sur C1 que ça ! (...) Principalement, sur Mac, parfois on se tape la roue multicolore pendant 1 ou deux minutes lors de la sélection d'images pourtant non modifiées.

Libre à toi d'ouvrir un fil sur un sujet que tu crois bon d'être traité, ou encore juste pour en faire le constat. Mais comment réagirais-tu si, en regard du problème soulevé, je te répondais que le souci de la roue du paon ne m'est jamais arrivé (il est vrai que je suis sur PC, pas sur MAC  ); si j'ajoutais qu'il y a d'autres problèmes plus... agaçants  ?

[esox_13]

?

[Benaparis]

Je trouve qu'il y a s'autres problèmes plus embêtants sur C1 que ça ! Comme par exemple la lenteur à reprendre la main quand on sélectionne un tiff multi-calques, ou bien des bizarreries qui se produisent un jour et pas le lendemain... Principalement, sur Mac, parfois on se tape la roue multicolore pendant 1 ou deux minutes lors de la sélection d'images pourtant non modifiées. On relance C1 et parfois ça rentre dans l'ordre, ou pas, ou parfois il faut relancer l'ordi... Ou encore le catalogue. Mais ceci étant dit, quand je dois développer un raw je préfère C1 à LR, surtout pour des travaux où le travail doit être très précis au niveau colorimétrie, bruit ou gestion luminosité/contraste. Ayant le pack Adobe pour les photographes, je n'ai pas la version débridée de C1, je n'utilise que la version DB pour dos P1.

Cela étant j'ai deux Mac (MacPro 2009 et MacBook Pro fin 2013) et je ne rencontre pas les problèmes que tu évoques, ce qui ne veut pas dire que je n'ai pas rencontré quelques bug, mais plutôt de manière anecdotique avec les versions Pro classiques...En revanche selon la carte graphique utilisée dans ta machine désactiver l'accélération graphique peut solutionner ton soucis. As tu essayé cette solution?

PS : tu utilises un vrai Mac ou un Hackintosh? Si c'est un Hackintosh c'est forcément aux risques et périls de l'utilisateur 😉

[coval95]

Il est normal que quelqu'un qui est déjà habitué à un fonctionnement donné ne soit pas convaincu par un fonctionnement alternatif. Gageons que si C1 avait été conçu différemment et fonctionnait par défaut de la manière que je propose, c'est le contraire qui ne serait pas convaincant pour ceux habitués à ce fonctionnement . La force de l'habitude n'est pas nécessairement une force de conviction. La preuve. Sinon, personne n'aurait posé la question du fonctionnement de C1 sur ce point particulier.

Juste une remarque : l'argument que tu développes ici est valable pour moi (qui suis habituée au fonctionnement de C1) mais il l'est tout autant pour Bélisaire (qui est habitué au fonctionnement de LR).  

Bref, l'objectif de l'exercice, pour futile qu'il soit, était de proposer une solution à une question posée dans le post initial. Vous m'avez demandé comment j'aurais résolu le problème tout en permettant de conserver le fonctionnement actuel, je crois que c'est fait. Il est (il aurait été) facile de concevoir un fonctionnement qui donne le choix à l'utilisateur et qui satisfasse tout le monde. Et c'est souvent le cas.

Oui, si c'est une option, pas de souci, ça satisfait un plus grand nombre d'utilisateurs. Par contre tu ne peux pas nier que ça complexifie le logiciel et le rend plus lourd à tester dans les versions ultérieures. Plus tu as d'options, plus tu as de cas de fonctionnement. Je ne t'apprends rien, n'est-ce pas ?  

Mets-toi à la place de Phase One : quel intérêt auraient-ils à ajouter cette option ?
Je participe de manière occasionnelle au forum de Phase One (sous un autre pseudo), je ne prétends avoir tout lu mais quand même, je n'ai pas le souvenir d'avoir jamais lu le moindre post à ce sujet ! Peux-tu me citer un (et si possible plusieurs) exemple(s) ?
Idem sur le forum Chassimages, d'ailleurs...

Je suis la première à dire que les développeurs doivent consulter les utilisateurs, je me suis souciée d'ergonomie des IHM pendant une bonne partie de ma carrière et, même si ce n'était pas ma spécialité, on venait me demander mon avis parce que les informaticiens "purs" ne se rendent pas forcément compte des besoins utilisateurs et ont tendance à faire des choix dans le sens qui leur simplifie la vie (normal quand on leur met la pression sur les coûts et les délais).

Mais l'ergonomie a forcément une part de subjectivité (tout simplement parce que nous sommes des êtres différents les uns des autres). Il faut donc évaluer l'intérêt d'une évolution en fonction du nombre d'utilisateurs concernés.

[at] Robert
La question initiale relève certes de la broutille, de l'aveu même de son auteur, mais je ne trouve pas que la discussion soit une perte de temps. Il y a longtemps que je m'intéresse à la question de la relation concepteur <=> utilisateur et je trouve qu'elle évolue mal (comme la relation fournisseur <=> client en général, d'ailleurs). Je trouve que l'utilisateur final n'est pas assez impliqué dans la phase de conception et que les concepteurs ne sont plus guidés que par leur propre vision des besoins de l'utilisateur et leurs propres contraintes. Il y a dans cette approche "top-down" une forme de domination qui ne devrait pas être acceptée aussi facilement.

Après tout, nous sommes les clients qui faisons vivre ces sociétés. Nous avons notre mot à dire. Nous finançons ces projets. À chaque fois que je le peux, j'essaie d'expliquer que souvent, quand le fournisseur dit "c'est comme ça et ça ne peut pas être autrement", il raconte des histoires et masque soit une certaine paresse, soit une conception défaillante. Ce que, mon passé et mon expérience aidant, j'ai beaucoup de mal à accepter. Et j'ai également de plus en plus de mal à accepter que toute critique, tout signalement d'un problème soient trop souvent contrés par d'autres utilisateurs. Je pense que tu as dû observer ça également. Ici comme ailleurs, on entre trop facilement dans la logique idiote du pour ou contre : je rejette en bloc ou j'accepte tout sans broncher. Il faut choisir son camp. Phénomène qui explique l'apparition des imprécateurs bien connus ici et sur d'autres forums. Je ne crois pas que je m'y ferai un jour.

Bien d'accord avec ça, mais à moduler par le nombre d'utilisateurs concernés (cf ce que j'ai écrit ci-dessus).

Et je trouve dommage de considérer que c'est une perte de temps de discuter d'ergonomie, surtout concernant un logiciel que nous utilisons pendant de nombreuses heures.

[coval95]

En fait, Bélisaire n'a rien demandé. Il l'a précisé plusieurs fois. Il a juste posé une question.

Oui, et si tu as bien voulu voir, j'ai répondu à sa question. Mais apparemment ma réponse ne l'a pas convaincu...

Je crois qu'elles se limitent à la portion congrue (de même que les tests qualité). En la matière, la gestion de projet la plus intelligente que j'ai pu observer a concerné une application de guichet pour un de mes clients (La Poste), il y a déjà longtemps. L'équipe de développement a été divisée en 2 parties : une équipe IHM et une équipe traitement. L'équipe IHM a réalisé une maquette avec une proposition d'interface qui a été présentée dans différents bureaux de poste sur le terrain. Les responsables de la partie IHM n'étaient pas des développeurs à proprement parler mais des ergonomes. La maquette a été développée avec un langage de haut niveai particulièrement adapté à cette tâche. Aucun traitement n'était réellement implémenté, c'était juste de la simulation.

Les utilisateurs (les employés derrière les guichets) ont donné leur avis en fonction de leur contexte d'utilisation. Pendant ce temps, l'autre équipe développait les traitements, sans présumer de l'interface. Ils n'étaient d'ailleurs pas installés au même endroit. Au final, les 2 morceaux ont été connectés après réécriture complète de la partie IHM dans un langage plus performant mais avec des spécifications validées sur le terrain. Exemplaire.

Bien sûr, on ne peut pas faire ça avec une application grand public mais on doit pouvoir trouver autre chose que la détestable méthode aujourd'hui généralisée dite de "la version bêta payante", économiquement intéressante mais génératrice de frustration chez l'utilisateur. À ce moment-là, il est déjà trop tard. On ne peut plus faire autre chose que signaler les bugs.

Cette méthode, basée sur une maquette, est LA bonne méthode et elle a été appliquée dans mon entreprise mais trop peu souvent hélas. Il faut avoir prévu dès le départ le temps nécessaire pour la réalisation de la maquette (en principe relativement rapide si on a les bons outils) et son évaluation par des utilisateurs puis le développement final de l'IHM.

[Franciscus Corvinus]

J'ai été absent pendant quelques jours et meme si la conversation a évoluée, il y a quelques réponses que je souhaite apporter a ceux qui ont pris la peine de me répondre.

Mais il n'y a PAS d'onglet idoine ! Les onglets sont des structures totalement personnalisables, aucun outil n'est lié de manière fixe à un onglet et réciproquement.
Le même outil peut se trouver dans TOUS les onglets ou dans aucun. Lequel actives-tu ?
Autant je peux comprendre qu'un nouvel utilisateur n'ait pas capté ça, autant je suis étonnée que des utilisateurs de longue date commettent cette erreur ! 

Bonnes questions sur lesquelles j'ai glissé pour ne pas rendre mon post trop long, mais pas d'erreur. L'onglet idoine, c'est bien sur celui qui, dans l'arrangement actuel, contient l'outil en question. Si l'outil est dans plusieurs onglet, le raccourci peut faire un cycle entre chaque tant que la touche est enfoncée. Une alternative est de réaffecter temporairement l'outil zoom de la souris a ce cycle tant que la touche de l'outil reste enfoncée, comme ca on n'est pas tributaire d'un rythme de défilement qui peut etre trop lent/rapide.

Sans revenir sur ce qu'a dit Coval, vous ne vous êtes jamais imaginé que l'idée d'utiliser ces outils permettaient justement d'éviter d'aller les chercher dans l'onglet dans lesquels ils sont rangés?
Quand je recadre, fait un horizon, un perspective avec ces outils la plupart du temps je n'ai pas besoin de les affiner au curseur dans les onglets...bref c'est l'intérêt ergonomique de ces outils. Bref pas convaincu par votre argument.

Il y a des outils qui ne s'utilisent qu'a la souris, tres bien. Dans ce cas on ne perd rien a *afficher* l'onglet et l'outil utilisé, non? Mais tu connais suffisamment C1 pour savoir qu'il y en a d'autres qui ne s'utilisent qu'avec des curseurs (la plupart des outil de gestion des couleurs par exemple) et que l'on est *obligé* "d'aller les chercher". Ca serait plus simple et plus rapide s'ils s'ouvraient sur simple pression d'une touche plutot que de forcer plusieurs clicks de souris.