1. Mode Graphique
    1. 1- Principes fondamentaux
      1. Processus de conception
      2. Caractéristiques d'un grand logiciel
        1. Haute performance
        2. Facilité d'utilisation
        3. Aspect attractif
        4. Fiabilité
        5. Adaptabilité
        6. Interoperabilité
        7. Mobilité
      3. Principes de conception
        1. Principes (1)
        2. Principes (2)
        3. Principes (3)
      4. Pensez aux utilisateurs
        1. Compatibilité internationale
        2. Accessibilité aux handicapés
        3. Etendre l'interface
      5. Priorités
    2. 2- L'expérience du Mac
      1. L'environnement
        1. L'environnement (1)
        2. L'environnement (2)
      2. Les technologies
        1. Les technologies (1)
        2. Les technologies (2)
        3. Les technologies (3)
        4. Les technologies (4)
      3. Installation et mises à jour
        1. Packaging, installation
        2. Les assistants
    3. 3- L'interface Aqua
      1. Entrées utilisateur
        1. La souris
        2. le clavier
          1. Fonction des touches
          2. Raccourcis-clavier
          3. Navigation au clavier
        3. Sélection
        4. Edition de texte
      2. Glisser-déposer
        1. Glisser-Déposer (1)
        2. Glisser-Déposer (2)
      3. Le texte
        1. Les fontes
        2. Le style
      4. Les icônes
        1. Genres et familles d'icônes
        2. Création des icônes
        3. Icônes des barres d'outils
        4. Images propres au système
      5. Les pointeurs
      6. Les menus
        1. Comportement des menus
        2. Conception des menus
        3. La barre de menus
          1. Les menus (1)
          2. Les menus (2)
          3. Les menus (3)
        4. Menus contextuels et du Dock
      7. Les fenêtres
        1. Type et apparence
        2. Eléments
          1. Barre de titre
          2. Barre d'outils
          3. Barre de recherche
          4. Barre latérale
          5. Barre inférieure
          6. Les Tiroirs
        3. Comportement des fenêtres
          1. Comportement (1)
          2. Comportement (2)
          3. Superposition
          4. Défilement
        4. Les panneaux
          1. Les panneaux
          2. Panneaux transparents
          3. Autres panneaux
      8. Les dialogues
        1. Types de dialogues
        2. Aspect et comportement
      9. Fenêtres de dialogues
        1. Recherche, Préférences, Ouverture
        2. Enregistrement
        3. Choix, Impression
      10. Les contrôles
        1. Contrôles du cadre
          1. Contrôles en capsule
          2. Contrôles hérités
        2. Les boutons
          1. Boutons poussoirs
          2. Boutons en icônes
          3. Boutons de recherche
          4. Boutons de gradient, et d'aide
          5. Boutons à champfrein
          6. Boutons ronds
        3. Contrôles de sélection
          1. Boutons radio
          2. Cases à cocher
          3. Contrôles segmentés
          4. Boutons et menus pop-Up
          5. Menus Action
          6. Boîtes de combinaison
          7. Contrôles de chemin
          8. Puits, sélection de date
          9. Menus pop-down
          10. Glissières
          11. Contrôles pas-à-pas et placards
        4. Indicateurs
          1. Indicateurs de progression
          2. De niveau, de capacité
          3. D'estimation, de pertinence
        5. Contrôles de texte
          1. Champs d'entrée
          2. Champs à jeton
          3. Champs de recherche
          4. Listes de défilement
        6. Contrôles de visualisation
          1. Triangles d'affichage
          2. Boutons d'affichage
          3. Vues en liste
          4. Vues en colonnes
          5. Vues éclatées
          6. Vues à onglets
        7. Contrôles de groupage
          1. Séparateurs
          2. Boîtes de groupage
        8. Règles de disposition
          1. Dans le corps de la fenêtre
            1. Fenêtre de préférences
            2. Fenêtre à onglets
            3. Alerte, Dialogue
          2. Contrôles réduits et mini
            1. Contrôles réduits
            2. Mini contrôles
          3. Groupement des contrôles
          4. Positionnement dans la barre inférieure
      11. Glossaire
        1. Entrées en anglais
          1. 1- A à C
          2. 2- D à H
          3. 3- I à R
          4. 4- S à Z
        2. Entrées en français
          1. 1- A à C
          2. 2- C à G
          3. 3- I à P
          4. 4- P à Z
        3. `
    4. 4- Les leçons de Lion
      1. L'environnement de Mac OS X
      2. Principes fondamentaux
      3. L'expérience utilisateur
        1. Règles de conduite (1)
        2. Règles de conduite (2)
        3. Règles de conduite (3)
        4. Règles de conduite (4)
        5. Règles de conduite (5)
        6. Règles de conduite (6)
      4. Les technologies d'Apple
        1. Les technologies (1)
      5. -->
  2. Mode Commande

Le processus de conception




Le premier chapitre des AHIG (Apple Human Interface Guidelines) entend fournir des conseils de base au développeur qui envisage de créer un logiciel ; il s'agit d'abord d'identifier les besoins du futur utilisateur, et de faire en sorte d'y répondre. Je ne vais pas ici en faire une traduction littérale, mais seulement mettre à la disposition des lecteurs francophones l'essentiel des notions qui y sont exprimées. Pour plus de précision, vous pouvez vous reporter au texte en anglais.


1- Implication des utilisateurs dans le processus de décision

Apple recommande d'être en contact avec des utilisateurs pendant toutes les phases de la conception : cela permet de définir clairement leurs besoins pour répondre aux attentes ; le faire dès le début du processus de développement élimine des erreurs qui peuvent se révéler coûteuses.

Bien connaître le public visé
Analyser les produits similaires à celui envisagé, pour identifier le public qu'ils ciblent, et décider si on les concurrence de front ou si on les complète. Cette analyse permettra de mieux cerner les besoins à satisfaire.
Partir de scénarios typiques d'utilisation du logiciel envisagé, en précisant les environnements, les outils et les contraintes, définis si possible à partir d'environnements de travail concrets.
Pendant tout le processus de développement, tester les prototypes du logiciel, écouter les remarques des utilisateurs. S'attacher aux gens et à leurs capacités, pas aux ordinateurs et à leurs possibilités.
Ne pas concevoir pour soi, ou pour son usage, mais pour le public visé, même si en tant que concepteur on peut avoir des idées plus précises que ceux des utilisateurs.

Analyse des tâches
Rentrer dans le modèle mental et conceptuel des utilisateurs qui ont une tâche à accomplir. Décrire la tâche, définir les composants qui doivent la constituer, leur organisation, et le processus de travail.
Il est utile d'étudier comment les mêmes tâches s'accomplissent sans ordinateur : quelle est la terminologie utilisée, quels sont les concepts, les objets, les gestes de l'opérateur. A partir de là, reproduire ces conditions, mais tirer aussi parti des avantages inhérents à un ordinateur pour faciliter le travail.

Construire des prototypes
Des prototypes permettent de tester la conception du logiciel, et de vérifier comment il fonctionne. Le prototype peut être seulement une visualisation de l'apparence du produit, pour des tâches spécifiques ; il n'implique pas nécessairement l'écriture de code ; il a pour but de simuler certaines caractéristiques et de montrer comment elles fonctionnent.

Observer les utilisateurs
Tester les prototypes sur un panel d'utilisateurs, observer leurs réactions (au besoin en vidéo), et écouter leurs remarques. Rester neutre, pour ne pas influencer les utilisateurs pendant les tests.
Les tests doivent porter sur les tâches définies au cours de l'analyse initiale ; ne pas expliquer aux utilisateurs comment faire la tâche que vous chercher à tester.
Utiliser ces observations pour créer un second prototype si nécessaire, et le tester sur un autre panel d'utilisateurs. Répéter ce processus jusqu'à ce que les besoins des utilisateurs soient satisfaits.

Comment mener ces observations
Ces tests ne constituent pas une expérimentation (ils ne donnent pas de mesures chiffrées), mais permettent de voir où les utilisateurs achoppent, et d'y remédier. Ils complètent les approches cognitives, de groupe, ou heuristiques.
Si le budget ne permet pas d'utiliser des structures de test professionnelles, tester les prototypes avec des collègues ou des connaissances ; un peu de tests vaut mieux que pas de test du tout.

Quelques conseils pour mener ces tests auprès des utilisateurs :
• Se présenter, et préciser qu'il s'agit de tester le produit, pas de tester la personne. Observer, mais sans le faire remarquer.
• Annoncer la durée du test, et permettre d'en sortir à n'importe quel moment (un abandon indique que la tâche est trop difficile ou trop complexe).
• Utiliser le protocole "penser tout haut" : inviter l'utilisateur à dire ce qui lui vient à l'esprit pendant qu'il travaille. Cela facilite l'identification de ses attentes, de ses attentions, de ses stratégies de résolution des problèmes. Au départ, aider l'utilisateur à penser tout haut, en lui demandant de décrire une tâche simple et courante (comment préparer une tasse de café).
• Décrire ce que le participant est appelé à faire ; donner les explications utiles, mais si on doit faire une démonstration avant le test, ne pas montrer ce qu'on cherche à tester.
• Laisser l'utilisateur se débrouiller tout seul, sans aide extérieure. En cas de difficulté, ne pas intervenir immédiatement, laisser patauger un moment avant de donner la réponse ; cela permet de voir comment il réagit. L'assistance sera le plus souvent indispensable pendant le test, mais il vaut mieux imposer des limites à celle-ci (par exemple, attendre 3 minutes avant d'aider) ; rester souple cependant, et intervenir avant l'abandon.
• Conclure le test en expliquant ce qu'on cherchait à savoir, et répondre aux questions de la personne.

Exploiter les résultats de ces tests :
• L'observation vous montrera des utilisateurs faisant des choses que vous n'avez jamais imaginées. Si vous les voyez faire des fautes, ne blâmez pas leur inexpérience ou leur difficulté de compréhension ; votre objectif est de comprendre quelle partie de votre produit est difficile ou impossible à appréhender du fait d'une conception défectueuse.
• Identifier des répétitions ; si un utilisateur a une difficulté, chercher si elle se retrouve chez d'autres utilisateurs, et reconnaître alors que le logiciel est fautif.
• Examiner ces résultats au sein d'une équipe comprenant des représentants de la gestion du produit, du marketing, de l'engineering, de la conception de l'interface utilisateur, de la documentation, de l'assurance de qualité, chacun apportant son expertise.


2- Prendre les bonnes décisions de conception

Il faut comparer les coûts (pas toujours financiers) et les bénéfices de toute modification à l'application :
• Quand l'application devient plus grosse.
• Quand elle devient plus lente.
• Quand l'interface utilisateur devient plus complexe.
• Quand on passe son temps à développer de nouvelles caractéristiques au lieu d'améliorer celles qui existent.
• Quand la documentation devient trop étendue.
• Quand on prend le risque d'introduire des changements qui peuvent altérer des caractéristiques existantes.
• Quand il faut plus de temps pour valider le comportement de l'application.

Il faut faire les bons choix dans ces circonstances ; des mauvais choix entraînent des coûts élevés quand des bogues se révèlent ou que l'utilisateur ne sait pas utiliser le produit.

Eviter les cascades de caractéristiques
On peut être tenté de rajouter des caractéristiques qui ne sont pas fondamentales pour l'objet du logiciel. Cela peut entraîner une interface ampoulée et lente, plus difficile à utiliser du fait de sa complexité. Apple conseille de s'en tenir aux buts initiaux de l'application, et de n'inclure que des caractéristiques qui sont propres à l'objet du programme.
Les meilleurs produits ne sont pas les plus riches en caractéristiques, mais ceux qui sont les plus utilisables.

Appliquer la solution à 80 %
Elle consiste à couvrir les besoins d'au moins 80 % des utilisateurs. La conception en est plus simple, et les problèmes résolus plus élégamment.
Chercher à satisfaire les autres 20 % de la cible visée risque de rendre le logiciel inutilisable pour les autres 80 %. Même si ces 20 % plus exigeants ont de bonnes idées, elles peuvent n'être pas partagées par la majorité des utilisateurs. Pour identifier cette cible de 80 %, il est utile d'avoir une panel étendu de personnes testées.


3- Et que fait Apple ?

Puisque Apple donne elle-même des verges pour se faire battre, on ne m'en voudra pas, j'espère, de poser la question de la façon dont ses développeurs respectent les consignes de la maison. Et le bilan est plus que mitigé ! A voir les aberrations de l'interface utilisateur de Snow Léopard, on peut se demander où sont parties ces consignes, ou ces belles résolutions :

Etre en contact avec des utilisateurs pendant toutes les phases de la conception.
Les utilisateurs ont-ils réclamé le menu et les fenêtres semi-transparents, l'affichage de dossiers complets à partir du Dock, la présentation mortuaire de ce dernier, des icônes de résolution 512 X 512, des fenêtres plus grandes que leur contenu, un écartement démesuré des icônes ? Je ne suis pas dans le secret des dieux, mais toutes ces mesures me semblent devoir plus aux décisions arbitraires des développeurs Apple qu'aux besoins et aux désidérata exprimés par les utilisateurs. Quels utilisateurs peuvent se vanter d'avoir été (un tant soit peu) écoutés par Apple ?
Et puis, que fait Apple des réclamations d'utilisateurs confirmés qui souffrent des inconvénients majeurs d'une installation monolithique : confusion de l'espace du système et de celui des utilisateurs, difficultés rencontrées à chaque changement de version (Snow Léopard semble dans ce domaine avoir amélioré les choses sans les prendre par le bon bout), insécurité associée à cette situation. (Si vous lisez l'anglais, allez voir cet article important)...

S'attacher aux gens et à leurs capacités, pas aux ordinateurs et à leurs possibilités.
La finalité de ces dérives graphiques, c'est le plus souvent de mettre en évidence les prouesses techniques des APIs graphiques (Core Graphics, Core Animation) sans considération de leur utilité réelle. Les ingénieurs d'Apple s'amusent avec leur joujou, ils en rajoutent à qui mieux mieux. Certaines sont certes utiles et bien faites (le basculement d'utilisateur, Exposé, l'agrandissement des icônes du Dock sous le curseur de la souris, les multiples bureaux de Spaces), mais leur surexploitation va trop loin : combien d'utilisateurs normaux savent appeler Expose à partir du Dock (il faut cliquer sur une icône active du Dock, et maintenir la pression), et à quoi sert-il de ne voir alors que les fenêtres (s'il y en a) de l'application choisie, puisqu'on ne peut pas les exploiter dans Exposé (cliquer dans une fenêtre ramène sur le bureau) ?

Rentrer dans le modèle mental et conceptuel des utilisateurs qui ont une tâche à accomplir.
Les critiques qui ont été si souvent formulées à propos des dernières versions de iMovie, et notamment la difficulté rencontrée quand on essaie d'y insérer des photos à partir de iPhoto, montrent à l'évidence que le modèle mental des concepteurs de iMovie est très éloigné de celui des utilisateurs. Où est, encore une fois, l'écoute des utilisateurs ?

Introduire des changements qui peuvent altérer des caractéristiques existantes.
Snow Léopard en fournit plusieurs exemples, que j'ai déjà signalés : l'utilisation de Cmd pour vider la corbeille en mode sécurisé, la marge excessive imposée aux images affichées par Aperçu, le nom inutilement compliqué et trop long attribué aux images créées par une copie d'écran.

Les meilleurs produits ne sont pas les plus riches en caractéristiques, mais ceux qui sont les plus utilisables ; s'en tenir aux buts initiaux de l'application.
Le Dock est selon ces critères l'un des plus mauvais produits fournis par Apple : bien conçu à l'origine pour mettre à portée de main les applications et des documents, il s'est, à l'image de la grenouille de La Fontaine, transformé en bœuf prétendant tout faire : remplacer le Finder en affichant des dossiers complets (d'une façon maladroite -en éventail, ou en semi-transparence-, de surcroît), appel à Exposé (n'y a t-il pas une touche spéciale pour cela ?) caché, donc ignoré de la plupart des utilisateurs, raccourci mortuaire sur les vitres de Préférences Système qui ne sert à rien...

Ne pas concevoir pour soi, ou pour son usage, mais pour le public visé, même si en tant que concepteur on peut avoir des idées plus précises que ceux des utilisateurs.
C'est précisément ce qu'Apple ne fait pas... presque systématiquement.

Je ne doute pas qu'en y réfléchissant un peu, et avec votre expérience, vous pourrez trouver facilement d'autres illustrations des manquements d'Apple à ses propres principes... Bon amusement.