# Retour d'informations

## Caractéristiques des applications réactives

Bien que les applications hautement réactives puissent différer énormément entre elles, ces application ont en commun les caractéristiques suivantes :

- elles donnent immédiatement un retour d'information aux utilisateurs même si elles ne peuvent pas satisfaire leurs requêtes immédiatement,

- elles gèrent les requêtes en file d'attente selon les perspectives des utilisateurs, éliminant les requêtes qui ne sont plus pertinentes et les réarrangeant selon les priorités probables des utilisateurs,

- elles permettent aux utilisateurs de faire d'autres tâches en attendant que les opérations de durée importante soient achevées — surtout celles ne résultant pas d'une demande de l'utilisateur — telles que la récupération de la mémoire non utilisée et autres opérations habituelles de « ménage »,

- elles donnent des retours d'informations suffisants pour permettre aux utilisateurs de comprendre ce qu'ils font et les organisent selon leurs capacités à les appréhender et à y réagir,

- elles font savoir aux utilisateurs que le traitement est en cours,

- elles permettent aux utilisateurs de savoir ou d'estimer le temps que les opérations vont prendre,

- elles permettent aux utilisateurs, d'une part de définir, lorsque c'est possible, le rythme du travail, d'autre part d'arrêter les tâches initiées mais non achevées.

Les applications hautement réactives donnent le contrôle aux utilisateurs en accusant réception de chacune de leurs demandes, en les informant continument sur la progression de la réalisation de chaque requête et en leur permettant d'effectuer les tâches dans un délai acceptable.

Même les applications avec des interfaces attractives et intuitives peuvent manquer de réactivité. Typiquement, les applications non réceptives possèdent au moins l'un des défauts suivants :

- elles fournissent un retour d'informations tardif — voire aucun — aux requêtes des utilisateurs, en les laissant se demander ce que l'application a fait ou est en train de faire,

- lorsqu'elles effectuent des opérations de longue durée, elles empêchent les utilisateurs de faire d'autres tâches ou d'annuler l'opération en cours,

- elles ne savent pas afficher une estimation de la durée des opérations de longue haleine et forcent les utilisateurs à attendre pour des durées imprévisibles,

- elles ignorent les demandes utilisateur quand elles font le « ménage courant » sans autorisation et forcent les utilisateurs à attendre un délai imprévu — souvent sans aucun retour.

Il est parfois possible d'améliorer la réactivité d'une application sans accélérer le code de l'application. Pour des astuces sur la façon de faire de telles améliorations, consultez la .

## Temps de réponse acceptables

Certains évènements de l'interface utilisateur nécessitent des délais de réponse plus courts que d'autres. Par exemple, la réponse d'une application à un clic de souris de l'utilisateur ou un appui sur une touche doit être beaucoup plus rapide que la réponse à une requête d'enregistrement de fichier. Le tableau ci-dessous affiche le délai de réponse maximum acceptable pour les évènements courants d'interface.

Temps de réponse acceptable maximum pour les évènements courants

Évènement UI | Temps de réponse maximal acceptable
--- | ---
Clic avec la souris, mouvement du pointeur, déplacement ou redimensionnement de fenêtre, appui sur une touche, mouvement de dessin, autre évènement d'entrée UI impliquant une coordination main-œil | 0,1 seconde
Affichage d'indicateurs de progression, accomplissement des commandes utilisateur ordinaires (par ex. fermeture de fenêtre), accomplissement des tâches d'arrière-plan (par ex. reformatage d'un tableau) | 1,0 seconde
Affichage d'un graphe ou de n'importe quoi d'autre pour lequel l'utilisateur s'attend à ce que ce soit long (par ex. affichage d'une nouvelle liste de toutes les transactions financières d'une entreprise pour une période comptable) | 10,0 secondes
Acceptation et traitement de toutes les entrées utilisateur pour une tâche | 10,0 secondes

Rendez chaque délai de réponse de votre application aussi court que possible, à moins que les utilisateurs n'aient besoin de temps pour consulter les informations affichées avant qu'elles ne soient effacées. Le délai de réponse acceptable pour chaque évènement se fonde sur l'intensité avec laquelle l'utilisateur moyen ressent le fait que tel ou tel évènement est un point logique sur lequel s'arrêter ou faire une pause. Plus ce sentiment est fort, plus l'utilisateur acceptera volontiers d'attendre une réponse. Vérifiez que votre application répond aux demandes des utilisateurs dans les limites énumérées dans le tableau ci-dessus. Si votre application ne peut pas répondre dans ces délais, elle présente probablement un ou plusieurs défauts d'ordre général dans un module ou un algorithme particulier.

Conseils

- Vérifiez que votre application fournit un retour d'information dans les 100 millisecondes (0,1 seconde) après chaque appui sur une touche, mouvement de souris ou autres entrées physiques de l'utilisateur.

- Vérifiez que votre application fournit un retour d'information dans les 100 millisecondes (0,1 seconde) après chaque modification d'état d'un contrôle qui réagit aux entrées de l'utilisateur — par exemple l'affichage des menus ou l'indication de cibles de dépôt.

- Vérifiez que votre application prend moins de 1 seconde pour afficher chaque indicateur de progression, réaliser chaque commande utilisateur ordinaire ou réaliser chaque tâche en arrière-plan.

- Vérifiez que votre application prend moins de 10 secondes pour accepter et traiter toutes les entrées utilisateur pour n'importe quelle tâche — dont les entrées utilisateur de chaque étape d'une tâche en plusieurs étapes, comme celles d'un assistant.

## Réponse aux requêtes utilisateur

Si votre application met trop de temps à répondre, les utilisateurs seront frustrés. Utilisez les techniques suivantes pour améliorer la réactivité de votre application.

Conseils

- Affichez le retour d'information dès que possible.

- Si vous ne pouvez pas afficher toutes les informations que l'utilisateur demande, affichez les informations les plus importantes d'abord.

- Gagnez du temps en affichant des résultats approximatifs pendant le calcul des résultats finals.

- Si les utilisateurs risquent de répéter une commande consommatrice en temps plusieurs fois de suite, gagnez du temps en maquillant les effets de la commande plutôt qu'en relançant de manière répétée le traitement de la commande. Par exemple, si l'utilisateur ajoute plusieurs lignes dans un tableau d'une base de données, vous pouvez afficher chaque nouvelle ligne immédiatement, tout en retardant leur création effective dans la base de données jusqu'à ce que l'utilisateur ait terminé l'ajout de toutes les lignes.

- Anticipez le travail. Préparez la réalisation de commandes qui, selon toute vraisemblance, succéderont à la commande actuelle. C'est-à-dire, utilisez les temps morts pour anticiper les requêtes que l'utilisateur lancera probablement à la suite. Par exemple, pendant que l'utilisateur d'une application de messagerie est en train de lire le nouveau message affiché, l'application peut préparer l'affichage du nouveau message suivant.

- Utilisez des traitements en arrière-plan. Réalisez les tâches moins importantes — telles que le ménage courant — en arrière-plan en permettant aux utilisateurs de poursuivre leur travail.

- Reportez le travail non urgent. Faites-le plus tard, lorsque il y a plus de temps disponible.

- Ne faites pas d'opérations superflues. Par exemple, pour se déplacer de plusieurs pages en arrière dans un navigateur Web, un utilisateur peut faire une succession rapide de clics sur le bouton Précédent du navigateur. Pour afficher plus rapidement la page effectivement demandée, le navigateur peut ne pas afficher les pages intercalées entre la page actuelle et la page finale.

- Utilisez la gestion dynamique du temps. Au cours de l'exécution, modifiez la façon dont votre application donne la priorité aux entrées utilisateur et aux autres traitements, en se fondant sur l'état actuel de l'application. Par exemple, si un utilisateur est en train d'effectuer de la saisie dans un traitement de texte pendant qu'un document autre est en cours d'impression, l'application de traitement de texte peut retarder la tâche d'impression si l'utilisateur engage une opération de modification (telle que couper et coller du texte) qui nécessite plus de ressources.

- Dans votre application, affichez une estimation du temps que va nécessiter chaque opération longue.

  - Si une commande demande une durée supérieure à 5 secondes avant de terminer son travail sur un objet, autorisez les utilisateurs à interagir avec les parties de l'objet ou les parties de l'application qui ne sont pas directement affectées par la commande.

  - Si la sortie d'une commande est de grande taille, affichez des résultats partiels dès leur disponibilité. Faites dérouler les résultats (si nécessaire) jusqu'à ce que l'utilisateur place le focus d'entrée sur un composant (par ex. une barre de défilement ou une zone de texte) impliqué dans le défilement.

## Types de retour d'information visuel

Vous pouvez utiliser deux types de retour visuel d'informations pour les opérations de votre application — un retour d'information à l'aide du pointeur et d'animations de progression.

### Retour d'information avec le pointeur

Le retour d'information à l'aide du pointeur de souris consiste à modifier sa forme. Par exemple, un pointeur « occupé » indique une opération en cours ; l'utilisateur ne peut pas faire d'autres tâches. Un pointeur « occupé interactif » indique qu'une opération est en progression, mais que la fenêtre reste toujours interactive.

Pointeur occupé (à gauche) et pointeur occupé interactif (à droite)

Busy pointer (left) and busy-interactive pointer (right)

### Animations de progression

Les animations de progression affichent, soit la proportion d'opération réalisée, soit seulement le fait que l'opération est en cours. Habituellement, ces animations prennent la forme, soit d'une barre de progression, soit d'une liste de contrôle de progression.

Conseils

- Lors de l'affichage d'une animation de progression, ouvrez-là dès le début de l'opération et fermez-la automatiquement dès que l'opération est terminée.

- Utilisez une barre de progression à mesure si votre application peut estimer, soit la durée de l'opération, soit sa proportion de réalisation.

- Si votre application ne peut pas faire d'estimation et que l'opération n'a qu'une étape, utilisez un indicateur de progression indéterminée. Pour les opérations à deux ou plusieurs étapes, utilisez une liste de contrôles de progression qui affiche dynamiquement une coche pour chaque étape réalisée.

#### Barres de progression

Pour des informations sur les différents types de barres de progression et quand les utiliser, consultez la .

##### Fenêtres de progression versus barre d'état

Dans une application dont les fenêtres principales contiennent une barre d'état (qui elle-même contient une barre de progression), se pose souvent le cas de présenter le retour d'informations d'une opération, soit dans la barre d'état, soit dans une fenêtre de progression. Une règle d'usage consiste à utiliser la barre d'état lorsqu'une opération doit durer moins de cinq secondes, sinon la fenêtre de progression. Cependant réfléchissez à ce qui suit au moment de faire un choix entre les deux :

- L'ouverture d'une nouvelle fenêtre, particulièrement lors d'une opération courte, peut, sans nécessité, interrompre le déroulement du travail de l'utilisateur.

- Les fenêtres de progression peuvent fournir plus d'informations.

- Plusieurs fenêtres de progression peuvent être ouvertes en même temps alors qu'une barre d'état ne peut afficher qu'une seule et unique opération.

- Les fenêtres de progression disposent d'un bouton Annuler.

#### Fenêtres à liste de contrôle

A checklist window shows the sequence of stages in an operation. See .

A Checklist Window

A checklist window showing a sequence of steps

## Choix d'un retour d'information approprié

Pour déterminer le type de retour d'information à fournir pour une opération particulière, prenez en considération ces facteurs :

- L'application peut-elle fournir une estimation de la progression de l'opération ou pas.

- L'opération bloque-t-elle l'utilisateur dans l'exécution d'autres commandes de l'application ou pas.

- L'application possède-t-elle un espace dédié, tel qu'une barre d'état, pour indiquer l'état des opérations ou pas.

Le tableau ci-dessous affiche le type de retour d'information à utiliser pour les opérations nécessitant plus d'une 1 seconde pour se terminer. Dans la colonne « Retour approprié », le terme « Animations de progression interne » signifie animations de progression affichées dans une zone d'état dédiée d'une application et « Animations de progression externe » signifie animations de progression affichées ailleurs que dans une zone d'état dédiée — typiquement dans une boîte de dialogue d'alerte.

Types de retour d'information pour les opérations qui durent plus d'une seconde

Durée-type > 5 s. ? | Blocage pour exécuter d'autres commandes ? | L'application a-t'elle une zone d'état dédiée ? | Retour d'information approprié
--- | --- | --- | ---
Oui | Oui | Oui | Animation interne plus retour d'information au pointeur
Oui | Oui | Non | Retour d'information au pointeur
Oui | Non | Oui | Animation interne
Non | Oui | Oui | Animation interne plus retour d'information au pointeur
Non | Oui | Non | Animation externe plus retour d'information au pointeur
Non | Non | Oui | Animation interne
Non | Non | Non | Animation externe

Conseils

- Utilisez un pointeur occupé lorsque l'interaction de l'utilisateur est bloquée par votre application pendant plus d'une seconde. Affichez le pointeur occupé moins d'une seconde après le début de l'opération.

- Si une commande doit prendre 10 secondes ou plus pour se terminer, mettez un bouton Arrêter ou Annuler également activable en appuyant sur la touche Échap ; les utilisateurs peuvent ainsi interrompre le traitement de la commande même si l'application ne peut pas en annuler les effets. Consultez la .

- Lorsque vous utilisez une animation externe, laissez la fenêtre contenant l'animation à l'écran pendant au moins une seconde après que l'opération soit achevée avec un message de terminaison avec succès. Modifiez les boutons Arrêter ou Annuler en bouton Valider pendant ce temps — un appui sur ce bouton doit fermer la fenêtre immédiatement.

## Autoriser l'arrêt d'une commande

Les utilisateurs ont parfois besoin d'interrompre une commande — par exemple, parce qu'elle prend trop de temps. L'application doit permettre aux utilisateurs d'arrêter les commandes en cours, même si l'arrêt d'une commande peut ne pas annuler ou « revenir en arrière » sur tous les effets de la commande.

Conseils

- Placez un bouton Arrêter ou Annuler également activable en appuyant sur Échap à côté de l'animation de progression pour une commande qu'il est possible d'interrompre.

- Nommez le bouton Annuler si l'opération complète peut être abandonnée proprement sans effet collatéral, en laissant le système dans l'état où il était avant le lancement de l'opération. Terminez la commande immédiatement lorsque l'utilisateur appuie sur le bouton.

- Nommez le bouton Arrêter si la commande peut être interrompue mais que ses effets jusqu'au moment de l'arrêt ne peuvent pas (ou ne doivent pas) être annulés. Lorsque l'utilisateur appuie sur ce bouton, ouvrez une boîte de dialogue d'alerte prévenant des effets potentiellement risqués d'un arrêt de la commande. La boîte de dialogue d'alerte ne doit comporter que deux boutons : l'un pour continuer le traitement de la commande, l'autre pour la terminer immédiatement.

Vous disposez également de l'alternative de placer le bouton Arrêter ou Annuler près du contrôle avec lequel l'utilisateur a lancé la commande à arrêter. Ne placez le bouton ici que si :

- il n'y a aucune animation de progression pour la commande ou

- l'animation de progression est dans la zone d'état d'une fenêtre ou à un autre endroit qui manque de place pour mettre un bouton Arrêter ou Annuler.

Dans la boîte d'alerte qui apparaît après l'appui sur le bouton Arrêter, assurez-vous que le message et les étiquettes des boutons de la boîte d'alerte sont précis et explicites. Des étiquettes de bouton ambiguës peuvent faire que les utilisateurs mettent fin ou continuent une commande contrairement à leur intention. Par exemple, utilisez :

    Continue deleting files? [Continue Deleting]
        [Stop Deleting]

plutôt que

    Operation interrupted, continue? [Yes]
        [No]

car dans ce dernier exemple, il n'est pas clair qu'un clic sur Oui continue l'opération ou continue la suppression (c'est-à-dire, arrête l'opération).