Ergonomie des systèmes mobiles

1. Les actions de l'utilisateur

1.1 Action Recherche

La recherche est un élément important pour les applications et les OS mobiles. Elle peut être limitée à l'application ou s'étendre à l'ensemble du téléphone.

La recherche peut être localisée à une application ou globale au téléphone. Cette recherche globale permet de retrouver tous les éléments associés à un mot (contacts, réseaux sociaux, notes, documents, web, etc.). Les applications peuvent s’intégrer dans ce mécanisme pour exposer leurs données dans un résultat de recherche, et ainsi inciter l’utilisateur à revenir dans l’application.

iOS propose de remplacer la barre d'actions par le champ de saisie de la recherche.

Ce champ est souvent caché au-delà du haut d'une liste. Il n’apparaît que si l’utilisateur déplace la liste vers le bas.

Une icône normalisée peut également être proposée dans une barre d'onglets.

Les recherches peuvent être intégrées à la recherche globale du système. Cela est accessible à gauche de la page principale de l'iPhone. Ou bien, deux ou trois clics sur le home permettent de déclencher une recherche globale.

Android propose d’ajouter une icône dans la barre d'actions.

Le champ de saisie superpose la barre d'actions, tout en maintenant le menu. Des icônes peuvent alors disparaître pour être remplacées par des items du menu.

Les applications peuvent s'intégrer dans la recherche globale du smartphone.

Les anciens téléphones Android proposent parfois un bouton physique pour démarrer une recherche. Ce dernier disparaît, car les boutons système ne proposent pas d'équivalent. Les applications ne doivent pas exploiter ce bouton pour une recherche dans l'application.

Windows Phone propose un bouton physique de recherche globale qui n'est pas spécifique à l'application en cours. Ce bouton déclenche une recherche via Bing et non sur tout le périphérique. Il est nécessaire de proposer un bouton dans la barre d'actions.

La recherche globale n'est pas disponible au moment de la rédaction de ce document. Il semble qu’une prochaine version l'intégrera.

1.2 Ouvrir avec…

Des objets ou des documents peuvent être édités ou consultés par d’autres applications présentes sur le smartphone ou la tablette.

Les contraintes techniques des OS limitent parfois les possibilités offertes aux applications.

iOS permet l’ouverture d’un document par une autre application. Mais pour cela, ce dernier doit être recopié dans l’espace mémoire de l’application cible. Le document peut être présenté à l’utilisateur, mais il ne peut être modifié par une autre application. Cela limite les possibilités des conteneurs de fichiers dans le Cloud comme Dropbox.

Android permet un partage complet des fichiers entre les applications. L’utilisateur peut alors choisir l’application la plus à même d’effectuer des modifications. Par exemple, il existe de nombreuses applications capables d’améliorer une photographie. Il est possible d’éditer directement un fichier Dropbox.

Windows Phone ne permet pas l’édition de documents entre les applications, en dehors du Cloud. Un fichier peut être dupliqué dans le contexte d’une autre application pour être consulté.

Lors de la consultation d’un document sur SkyDrive (la solution Cloud de MS), la référence du document est utilisée par l’application d’édition pour lui permettre de modifier le fichier présent dans les nuages. Cette modification est alors visible par les autres applications utilisant SkyDrive. En cas de perte de réseau, impossible de modifier un fichier d’une autre application.

1.3 Partage avec...

Les applications veulent permettre le partage d'informations vers les réseaux sociaux ou autres applications. Chaque OS intègre des approches différentes pour permettre cela.

iOS propose un bouton spécifique pour permettre le partage d'un document. Par défaut, une liste finie d'applications natives est intégrée dans l'application. Cependant, il est possible de concevoir son application de façon à ce qu’elle puisse partager des fichiers avec certaines applications tierces.

Android propose une icône spécifique à ajouter dans la barre d'actions pour le partage. La liste des applications prêtes à recevoir un partage est variable. En effet, une application peut s'enregistrer comme cible d'un partage. Le dernier partage effectué est mémorisé, permettant à l'utilisateur de partager à nouveau plus rapidement. Dans l'exemple suivant, le Bluetooth est le dernier partage utilisé.

Windows Phone propose également un partage avec les différentes applications présentes dans le smartphone. La barre d'actions doit proposer un menu pour cela. Cela ouvre une nouvelle fenêtre pour sélectionner l'application cible. Elle est automatiquement générée par le système.

1.4.Sélection multiple

Les utilisateurs désirent parfois effectuer une même action sur différents objets. Par exemple, ils désirent sélectionner certaines photographies pour les partager, les envoyer par mail ou les effacer.

iOS propose de passer par le bouton modifier. Le mode de sélection multiple est alors indiqué dans la barre de titre. Des cases à cocher sont superposées sur les photos.

Android propose d'entrer dans le mode de sélection par un appui long sur un des éléments (grammaire invisible). La barre d'actions est alors modifiée pour proposer différentes actions à l'utilisateur. Il peut valider ou abandonner la sélection. Les éléments de l’écran peuvent également s’enrichir d’une coche ou d’un autre signal visuel de sélection. Le menu correspondant s'adapte à la sélection courante.

Les versions précédentes d’Android proposaient une action dans le menu pour entrer dans ce mode.

Windows Phone propose d'entrer dans le mode de sélection multiple à partir d'une action de la barre de menu.

2. Paramétrage

Les OS utilisent des approches différentes pour la gestion des paramètres des applications.

iOS propose de centraliser toutes les options de paramétrage à un même et unique endroit. Ce qui a pour avantage de limiter le nombre d’éléments et d'options au sein d'une application. Par contre, cela oblige l'utilisateur à sortir de son application pour changer un paramètre (grammaire invisible). Il est probable qu'un utilisateur ignore la présence de paramètres pour son application.

L'utilisateur n'a pas à valider ses modifications pour qu’elles soient prises en compte. Elles sont effectives immédiatement.

Android propose d'utiliser un bouton d'action pour entrer dans le paramétrage. Une feuille de styles normalisée doit être utilisée pour valoriser les différents paramètres. Le modèle consiste à permettre la modification des paramètres sans demander de validation à l'utilisateur.

Windows Phone propose également d'ajouter un bouton d'action ou un menu pour le paramétrage. L'utilisateur ne doit généralement pas valider ses modifications, même s'il existe des applications qui proposent le contraire (Mail).

3. Panorama

Les écrans des smartphones sont de petite taille. Il est souvent nécessaire d'exploiter plusieurs vues mises les unes à côté des autres. Cela permet de proposer un écran système plus grand que l'écran physique et de présenter un extrait du panorama. L'utilisateur doit glisser l'écran à droite ou à gauche pour révéler la suite du panorama.

L'utilisateur n'a pas forcément conscience de la présence des autres vues du panorama. Plusieurs approches ont été imaginées.

iOS propose de signaler cela à l'utilisateur en présentant un indicateur de page (page control). Ce composant indique le nombre de pages disponibles et la page en cours de visualisation (grammaire visible). Le point plus clair indique la position relative de la page dans le panorama. Une icône spécifique peut remplacer le point.

Android propose le concept de page à glisser, mais n'offre pas de composant graphique équivalent au « page control ». Chaque application décide alors de le proposer ou non (avec des points, des barres, etc.). Par exemple, la page du bureau colorie pendant un instant un segment de la barre séparant les icônes du menu. Il existe des librairies pour proposer différents indicateurs de page.

Un débordement peut être volontairement utilisé pour signaler à l'utilisateur qu'il ne voit pas l'intégralité des informations. C'est le cas de la galerie par exemple.

Dans l’exemple suivant, la taille des images est adaptée dès qu’une image ne tient plus à l’écran, pour être certain de générer un débordement.

Windows Phone considère comme important que l'utilisateur ait conscience qu'il est possible de consulter les écrans complémentaires (les vues du panneau). Pour l'informer, plusieurs stratégies sont utilisées.

La première approche consiste à réserver une bande d'un demi centimètre à droite pour y présenter le bord gauche de l'écran suivant.

La deuxième approche consiste à utiliser un titre avec une police de grande taille dont le texte déborde en largeur de l'écran. Ainsi, l'utilisateur devine qu'il est possible d'aller voir à droite. Il est à noter que ce mode n'est pas disponible pour une présentation en mode paysage.

Certaines langues ne permettent pas de présenter l'intégralité du titre sur l'ensemble des volets, d'autres utilisent des mots trop courts pour que ceux-ci débordent.

Dans l'exemple suivant en français, impossible de connaître l'intégralité du titre, même si on le devine, car il n'y a pas de vue à droite.

4. La connexion avec le réseau

Les applications exploitent fortement le réseau afin d’étendre les capacités du terminal. Les données peuvent arriver à la demande ou en tâche de fond. Cela peut déclencher des alertes ou des notifications à l’utilisateur.

4.1 Rafraîchissement à la demande

Les informations récupérées sur Internet sont une image à un instant donné, présente sur le serveur. Entre-temps, de nouvelles données peuvent arriver, sans que l'application en soit prévenue. Par exemple, de nouveaux messages peuvent être publiés sur les réseaux sociaux.

Pour rafraîchir l'application, il est possible que le serveur informe directement l'application, mais plus souvent, l'utilisateur doit effectuer une action pour demander le rafraîchissement. Les OS proposent des approches différentes pour répondre à ce besoin.

iOS propose le pattern « Tirer pour rafraîchir » (pull-to-refresh – brevet de Twitter). L'utilisateur doit tirer au-delà d'une liste vers le bas, pour la faire déborder et déclencher une requête réseau pour obtenir les nouveaux éléments. Mais on peut aussi trouver un bouton permettant de demander un rafraîchissement. Il est à noter que le fait de tirer vers le bas est également utilisé pour faire apparaître une boîte de recherche (gesture).

Android propose quant à lui d’ajouter un bouton comme dernier élément d'une liste ou de présenter un sablier dès que l'utilisateur dépasse le dernier élément. Un bouton de rafraîchissement est également proposé. On ne retrouve jamais d'élément caché au-dessus de la liste. Le design et les animations des listes ne s’y prêtent pas.

Windows Phone propose des listes infinies avec chargement des données au fur et à mesure. En cas d’attente, un loader indique que les données arrivent. Un bouton standard permet plus généralement de rafraîchir les données.

4.2 Signaler un événement

Les applications effectuent des traitements en tâche de fond. Elles peuvent parfois avoir des difficultés à fonctionner (perte de réseau, SMS qui ne part pas, mot de passe devenu invalide, etc.) Il est nécessaire de prévoir un mécanisme ergonomique pour signaler ces situations à l'utilisateur.

Plusieurs approches sont disponibles. Partant de l'idée que l'utilisateur est devant son écran lors de la diffusion de l'information, il est possible d'afficher une alerte par-dessus l'écran actif. Suivant les OS, ce message peut venir de l'application active ou d'une autre application exécutée en tâche de fond.

Cette approche présente plusieurs inconvénients : l’utilisateur risque d’être gêné par l’apparition de ce message, car il cache une partie de l’application. D'autre part, l'utilisateur peut manquer le message. Il n'est alors pas prévenu que ses mails ne sont plus téléchargés ou qu'un SMS n'est pas parti. Bien entendu, il ne faut informer l'utilisateur que si cela est vraiment important.

Pour simplement confirmer une action, il est préférable d'avoir un retour visuel sur l'écran, comme le changement de couleur d'un bouton.

iOS propose des notifications servant à alerter l'utilisateur qu'un événement s'est produit. À tout moment, il est possible de consulter un écran, appelé « centre de notifications ». On y accède en glissant le doigt du haut vers le bas à partir de la barre de statut. Les alertes sont classées par applications.

Il est possible d'être notifié de deux manières différentes : par une pop-up et une bannière. Un badge sur l’icône de l'application peut également signaler l’arrivée d’un événement.

Les notifications sur iOS sont standardisées et ne peuvent être personnalisées.

Elles indiquent le nom de l'application ainsi qu'un message. Il est possible de faire les actions suivantes : fermer la notification, ouvrir l'application concernée ou demander un rappel.

Un appui sur une alerte lance l’application correspondante.

Les notifications ne peuvent s’agréger en une seule dans la barre de notification.

L’application n’est pas prévenue de l’arrivée d’un événement. Une fois lancée, elle peut consulter ces événements pour réagir en conséquence et par exemple mettre à zéro le badge de l’icône.

Android propose quatre approches pour informer l'utilisateur : un texte défilant sur la barre de statut, des alertes par-dessus l'application, des notifications et des boîtes de dialogue pop-up.

Le développeur peut modifier les styles des alertes. Ces messages peuvent être placés n'importe où sur l'écran, mais ne sont pas actifs. Ils peuvent apparaître à l'initiative d'une autre application que celle actuellement présente à l'écran. L’utilisateur ne peut faire disparaître cette fenêtre manuellement, mais elle disparaît après quelques secondes.

Il est également possible d'afficher une boîte de dialogue à l'utilisateur pour lui demander de prendre une décision. C'est le cas, par exemple, lors d'une association Bluetooth. Ces dialogues peuvent être à l'initiative d'autres applications et surgir à tout moment. La transparence autour du dialogue n'est pas complète. Il n’y a aucune limitation sur le contenu du dialogue.

Android propose également une liste de notifications. Un glissé du doigt depuis le haut de l'écran permet à l'utilisateur de les consulter.

L'utilisateur peut glisser chaque événement à l’extérieur de l'écran, sur la droite ou la gauche, pour le supprimer.

Pour signaler la présence de notifications, des icônes spécifiques peuvent être ajoutées dans la barre de statut, présente sur tous les écrans. Ainsi, l'utilisateur est invité à consulter les notifications si une icône spécifique l’intéresse. Il n'a pas besoin de consulter régulièrement la liste pour savoir s'il s'y passe quelque chose d'important.

Un texte peut s’afficher sur la barre de statut lors de l’événement.

Les notifications peuvent être plus ou moins riches suivant les versions de l'OS.

Si elles ont besoin de plus de place, elles peuvent s'étendre directement depuis la liste des notifications.

Elles peuvent proposer des actions simples, portées par des boutons.

Pour éviter de polluer cette liste, les applications doivent les agréger au maximum. Si le même message arrive plusieurs fois, un compteur doit être incrémenté sur le premier message.

Android propose sur certains périphériques une LED, avec différentes couleurs, qui permet d'informer l'utilisateur sans que ce dernier ait besoin d'allumer son smartphone. La présence de cette lumière et les couleurs disponibles sont variables suivant les périphériques.

Les anciennes versions ne proposent que l’affichage d’éléments simples dans le centre de notifications. Il est possible d’avoir deux lignes de texte et une icône.

Windows Phone ne propose pas de conteneur centralisé de notifications. Le système propose quatre approches pour notifier l'utilisateur :

- Utiliser un label à la place de la barre de statut tout en haut lorsque l'utilisateur démarre l'application. Lors du lancement de l'application, cette dernière affiche furtivement une synthèse des actions passées ;

- Ajouter un compteur sur la tuile de l’application ; l'application doit proposer un paramètre pour ne plus mettre à jour la tuile en tâche de fond ;

- Afficher une alerte par-dessus l'application active. Un clic sur l’alerte lance l'application correspondante. Les applications peuvent refuser d'être ainsi perturbées ;

- Utiliser une boîte de dialogue qui surgit sur l'application, si elle est active. Le reste de l'espace est estompé.

Les applications ne peuvent pas signaler un problème à l'utilisateur s'il n'est pas présent devant l'écran. Tant que l'utilisateur ne relance pas l'application, il ne sait pas s'il y a eu un problème. Il est alors possible que ce dernier pense que ses mails sont récupérés et qu'il n'y en a pas de nouveau, alors qu'en réalité, son mot de passe a expiré et qu'il ne l'a pas mis à jour dans son téléphone.

Les applications doivent demander à l’utilisateur l’autorisation de lui envoyer des notifications.

Il n'existe pas de lumière pour signaler un événement sans allumer le téléphone.

4.3 Widget actif

Les notifications permettent d'informer l'utilisateur, mais imposent que ce dernier utilise la liste pour les consulter. Il est également possible d'informer l'utilisateur d'informations concernant ses applications, en enrichissant dynamiquement un widget spécifique. Il s’agit d’une sorte de mini-application disponible sur le bureau.

Si l'utilisateur estime qu'une application est particulièrement digne d’intérêt, il peut décider d'installer le widget sur son bureau afin d'avoir une vue rapide de l'évolution de ses réseaux sociaux, de la météo, des informations, du trafic routier, etc.

Les approches sont assez différentes suivant les OS.

Pour iOS, la notion de widget n'existe pas. Il est simplement possible d'ajouter un indicateur numérique sur l’icône de l'application. Ce dernier permet d'informer de la présence d'un nouveau mail par exemple. Ce « badge » est valorisé par l’application ou par un événement venant du net.

Il existe une exception : l'application calendrier. L’icône de cette application a un affichage dynamique puisqu'elle présente une partie de la date du jour (nom du jour de la semaine + N°).

Android permet aux applications d'exposer des widgets de différentes formes et différentes tailles, plus ou moins actifs. Cela permet d'organiser les différents écrans composant le bureau, afin d'avoir soit des accès directs à certaines fonctionnalités des applications, soit des informations fraîches. Il est possible d’interagir directement depuis le bureau. Les widgets peuvent être simplement informatifs (la météo, un dossier de mail, l'agenda), avoir quelques boutons (activer le Wifi, le Bluetooth, itinéraire vers le domicile) ou une combinaison de boutons (contrôle de la playlist). L'utilisateur peut modifier la taille des widgets.

L'espace disponible sur un écran du bureau étant limité, il est souvent nécessaire de les organiser sur les différents écrans disponibles. Les widgets peuvent être présents sur l'écran de déverrouillage.

Windows Phone utilise des tuiles (widget applicatif) pour permettre à l'utilisateur d'avoir un résumé rapide de l'état de plusieurs applications. Elles sont capables de se rafraîchir automatiquement et de lancer l'application. Comme sur Android, c'est à l'utilisateur de sélectionner et d'organiser les widgets présents sur son bureau. Cet écran ne peut être qu’en portrait.

Contrairement à Android ou iOS, l'utilisateur dispose d'un espace infini vers le bas pour agréger tous les widgets. Un rapide glissement du doigt permet alors d'avoir une vue synthétique des informations. Par contre, les widgets ne peuvent que présenter de l'information. Aucune action n’est possible. Ils sont mis à jour via des notifications du réseau.

Les tuiles peuvent exister en trois tailles et différents modes d’animation : Flip (la face se retourne sur place), Icône (la tuile est fixe), Cycle (une succession d’images) ou Dynamique. Elles doivent avoir un fond coloré uni.

Un appui sur une tuile lance l'application correspondante. Il est impossible d’interagir plus finement. Par exemple, impossible de contrôler la diffusion musicale depuis le bureau. C'est le bouton « volume » qui fait apparaître un menu par-dessus l'application.

Il est également possible d'ajouter des informations sur l'écran de verrouillage, au choix de l'utilisateur. L’application peut livrer le texte sous la date et une icône parmi cinq avec un chiffre.

4.4 Tâche de fond

Il arrive fréquemment qu'un utilisateur de mobile n'ait pas accès au réseau. Cela n’implique pas pour autant qu'il ne puisse pas réaliser d'action sur son téléphone. Il peut parfaitement rédiger un mail, réagir au flux d’un réseau social, publier une nouvelle photo, etc. Les données ne sont pas diffusées immédiatement, mais le seront dès que le réseau sera disponible, ou lors de la prochaine connexion Wifi.

De même, il est intéressant de récupérer des données dès que possible, afin d’alimenter les applications. Ainsi, même en l’absence de réseau, l’utilisateur peut consulter les derniers mails récupérés.

iOS ne permet pas de publier des modifications si l’application n’est pas active. Les données ne peuvent être diffusées sur le réseau. Tant que l’utilisateur ne relance pas l’application, les données restent en attente. Il n’est pas possible de récupérer des données en tâche de fond, sauf pour l’application mail native. Il n’est donc pas possible de consulter les derniers mails en cas de perte de connexion.

Les applications Apple ne subissent pas cette contrainte. Il y a donc une différence entre rédiger un mail sans réseau avec l’application d’Apple et la même action avec une solution alternative. C’est uniquement lors du réveil de l’application alternative que les messages pourront partir.

Quelques actions en tâche de fond sont possibles, comme la navigation GPS, l’écoute d’un flux audio ou la téléphonie IP.

Android permet la publication de services. Ce sont des traitements exécutés en tâche de fond ou sur événement. Ainsi, il est possible de publier les messages en attente, dès la reprise du réseau. L’utilisateur peut être en train d’utiliser une autre application ou avoir le téléphone éteint, les messages seront envoyés dès que possible. Il est possible de récupérer les nouveaux mails, au fur et à mesure qu’ils arrivent. Ainsi, même en absence de réseau, il est possible de les consulter, alors que l’application n’a jamais été lancée par l’utilisateur.

Window Phone propose une approche de multitâche sous le contrôle de l’OS. Périodiquement, à l’initiative du système, des traitements peuvent être déclenchés. Ces derniers peuvent envoyer ou recevoir des données. Si une application n’est pas lancée pendant un certain temps, les tâches de fond associées sont considérées comme inutiles. Les traitements ne sont alors plus déclenchés.

Il existe également des traitements déclarés comme gros consommateurs de ressources. Ils ne sont déclenchés par le système qu’avec une connexion Wifi et un branchement au secteur.

5. Présentation à l’écran

L’écran d’un smartphone présente un espace réduit qu’il faut exploiter au maximum. Il doit également permettre de présenter un retour immédiat à l’utilisateur (affichage de la lettre du clavier, modification de la couleur d’un élément, etc.). De plus, le terminal peut basculer en mode portrait ou paysage et propose un clavier virtuel.

5.1 Portrait/paysage

Les applications peuvent être utilisées sur téléphone ou sur tablette. L'usage principal sur un smartphone et le mode portrait. Pour une tablette, c'est le mode paysage qui est privilégié. Les applications devraient être compatibles avec ces deux modes.

iOS ne permet pas à toutes les applications de fonctionner dans les deux modes. Généralement, les applications spécifiques au téléphone n'acceptent que le mode portrait. Les versions pour iPad sont alors très différentes. Par exemple, la gestion des contacts entre iPhone et iPad est très différente.

Android ne propose que des applications qui fonctionnent dans les deux modes, même si les applications typiques téléphone sont présentées en mode portrait (appel téléphonique, SMS). En effet, certains téléphones possèdent un clavier physique qui force le mode paysage lors de son utilisation. Chaque saisie peut passer l'application en mode paysage.

Windows Phone ne propose pas le mode panorama avec une utilisation en paysage. Donc beaucoup d'applications ne fonctionnent pas dans cette orientation.

5.2 Dialogue

Lors du besoin d'une intervention de l'utilisateur, une boîte de dialogue est proposée à l'utilisateur. Cette dernière propose généralement quelques boutons, une liste réduite de choix ou de cases à cocher. Plusieurs approches coexistent pour l'ordre des boutons.

iOS met l'action principale à droite.

Android propose que le bouton de validation soit le dernier.

Les anciennes versions d’Android utilisaient un ordre inversé, avec la validation à gauche.

Windows Phone propose le bouton de validation à gauche.

Il est important de respecter ces conventions, car l'utilisateur a tendance à cliquer sans vraiment faire attention aux libellés des boutons.

6. Sécurité

Chaque OS mobile propose son approche de la sécurité. Certains préfèrent exposer tous les privilèges avant l’installation de l’application, d’autres préfèrent demander l’accord de l’utilisateur au premier usage.

iOS propose un modèle de sécurité simplifié, où l’utilisateur doit accepter chaque privilège avant la première utilisation. Les privilèges sont à ce jour : GPS, Photo, Contacts, Calendrier, Rappels, Partage Bluetooth, Compte Twitter et Compte Facebook.

Android propose un modèle basé sur une exposition des privilèges à l’utilisateur avant l’installation de l’application. Comme le modèle de sécurité est complexe et évolutif, les nombreuses informations présentées ne permettent pas toujours aux utilisateurs d’avoir conscience des impacts. Ils ont tendance à accepter tous les privilèges.

Il n’est pas possible de sélectionner les privilèges à accorder. Cela simplifie la conception des applications, car il n’est pas nécessaire de prévoir les cas où un privilège n’est pas disponible.

Des techniques avancées permettent d’ajouter dynamiquement de nouveaux privilèges. Cela est une sorte d’accord de l’utilisateur. Mais pour cela, l’utilisateur devra quitter l’application pour installer une extension via la place de marché.

Windows Phone propose d’indiquer l’ensemble des privilèges d’une application avant son installation. De même, il n’est pas possible de sélectionner certains privilèges ou d’en ajouter en cours de route.

Conclusion

Nous avons identifié de nombreuses différences entre les OS et de nombreux composants à exploiter lors de la conception d’une application mobile. Nous n’avons pas la prétention d’être exhaustifs. Le tableau suivant synthétise en une vingtaine de points les différentes informations.