Gérer un état Busy est souvent indispensable, chargement de données, interrogations d’un service Web, il y a des attentes qu’il faut matérialiser pour que l’utilisateur ne coupe pas l’App la croyant bloquée… Mais où mettre ce fichu indicateur ? Voyons ça…
Le design le plus simple est le meilleur
Qu’il s’agisse de performances pures, d’esthétique, d’UX, d’UI de tout ce que vous voulez, un design simple et épuré est toujours préférable à un sapin de noël même bourré d’options géniales.
C’était vrai sur Desktop avec WPF ou UWP, cela reste vrai et même plus encore sur les écrans des smartphones et des tablettes.
Il y a aussi des codes que les utilisateurs ont appris à reconnaître. N’essayer pas de donner dans la nouveauté débridée pour ces symboles universels, vous ne ferez que rendre confus ce qui aurait été simple à comprendre… Regarder l’icône de sauvegarde, presque partout c’est une disquette 3”5… Un format très temporaire, complètement dépassé, que les plus jeunes utilisateurs n’ont jamais connu. Et pourtant tout le monde comprend cette icône et tout le monde l’utilise…
Donc faire simple c’est aussi adopter des codes universellement compris pour rendre l’UX la plus intelligible possible.
Revenons à l’indicateur d’activité “Busy”
Dans une telle démarche épurée et efficace, l’indicateur d’activité “busy” doit trouver sa place. Or sur un petit écran hors de question de lui réserver un emplacement comme on peut le faire dans une barre de statut d’une application Desktop.
Ce fichu indicateur s’affiche par-dessus le reste le plus souvent car on ne sait pas où le mettre.
Pour faire simple et rester dans les codes, les gens se sont habitués à voir un “truc” tourner. Ce n’est pas récent, rappelez-vous les Macintosh d’antan qui affichaient déjà une montre dont l’aiguille tournait… Les Mac récents affichent une espèce de truc multicolore rond qui tourne aussi (et qui est affreux mais c’est une autre question). Google utilise cette approche aussi.
Il n’y a guère que sur les PC ou les applis de bureau pour Mac qu’on utilise encore une barre de progression. Généralement parce qu’on peut calculer cette dernière. Le “busy indicateur” est une barre de progression en mode indéfini et ronde. Rien de plus, rien de moins.
Donc optez pour un machin rond qui tourne dans le sens horaire. Vous pouvez être créatif ce n’est pas interdit tant que ça à l’air d’être un zinzin circulaire qui se mord la queue en tournant. Simple arc de cercle qui s’étend de 0 à 360 °, série de tirets hérissés qui se dévoilent, petits points qui semblent se courir après, tout est en envisageable tant que l’utilisateur comprend que c’est un indicateur 'd’activité au premier coup d’œil. Evitez les trucs top science-fiction où de multiple cercles et arc de cercles de couleurs tournent dans tous les sens. Parfois l’effet est très réussi, souvent c’est too much d’autant que le look du reste de l’App ne suit pas… Evitez de faire voir que le reste est moche….
La forme étant fixée reste à savoir où placer cette animation !
Les pratiques sont variables mais on retrouve souvent l’indicateur en haut de l’écran quand il s’agit de faire un pull down dans une liste par exemple. La liste s’abaisse visuellement et le truc qui tourne apparait dans l’espace libéré. Ce n’est pas moche, c’est compréhensible, mais cela complique les animations de l’UI pour pas grand-chose.
Le plus souvent ledit zinzin tournant se retrouve en plein milieu de l’écran en surimpression. Le reste étant blanc ou grisé généralement. Mais toutes les variantes ont pu être vues. Ce n’est pas un choix idiot, car il faudrait vraiment être neuneu pour le louper ! Donc c’est évident, et ça répond à l’un des critères essentiels de l’UX : la lisibilité. Mais c’est peut-être un peu trop lisible…
Soyons inventifs
On peut être inventif tout en restant dans “les clous”. Sans être délirant ou illisible.
En dehors des listes qui possède un geste vers le bas pour le rechargement ou la mise à jour du contenu et qui supporte un affichage en haut dans un espace fraichement libéré du fameux bidule tournant, le busy indicateur s’affiche surtout par suite d'une action précise, une commande, donc un bouton (que celui-ci soit de toute forme ou qu’il n’ait aucune forme et que seul le texte ne soit utilisé).
Ne serait-il pas logique de faire apparaitre le busy indicator à la place du texte du bouton ? L’utilisateur a les yeux juste à cet endroit en appuyant sur le bouton, il verra forcément l’animation. Il saura même avec assurance que c’est ce clic précis qui déclenche l’état d’attente.
L’idée ne casse pas non plus trois pattes à un pauvre canard mais elle des avantages : Elle est simple à réaliser, elle est évidente pour l’utilisateur et pour le développeur elle évite de faire des surimpressions, de déplacer des objets ou autres effets plus ou moins réussi pour que le busy indicator saute aux yeux…
Nous avons donc besoin d’un Busy Button. Appelons-le plus exactement un Activity Button, puisque son rôle est de montrer que l’App est occupée mais qu’elle est toujours en activité. Un Still Alive Button serait aussi une possibilité mais n’ergotons pas sur la terminologie de notre gadget c’est l’effet qui compte et l’utilisateur ne saura jamais quel nom porte la classe de notre objet !
L’effet visuel
Avant d’aller plus loin fixons nos idées en regardant l’effet que tout cela va rendre.
Sous Android cela donnera quelque chose de ce genre :
Sous iOS on aura plutôt ce qui suit mais la ressemblance est troublante 
Toute la feinte de cet ActivityButton se trouve dans sa construction. Au lieu d’un simple bouton qu’on irait bricoler dans les Renderers, on va utiliser une ContentView avec une Grid, et dedans, nous placerons un Button et un ActivityIndicator…
Tout le jeu sera de cacher le texte du bouton pendant qu’on affiche l’indicateur et réciproquement lorsque l’attente sera terminée.
Etude du code
Toutes les subtilités sont là, dans le code. Et l’étudier est bien le seul moyen de regarder et de comprendre comment ça marche vraiment. Dans les grandes lignes je suppose que vous compris mes explications, mais dans les détails seriez-vous capable d’écrire un tel contrôle à partir de zéro ? Si la réponse est non vous gagnerez beaucoup en étudiant le code.
Mais noircir cet article de pages de code ne le rendra pas plus attractif, bien au contraire. C’est pourquoi je vous propose de télécharger le code écrit par John Taubensee qu’il a mis à disposition sur son Git sous le nom explicite de Xamarin.ActivityButton. D’ici là un Nuget existera peut-être, sinon il n’est guère compliqué de repiquer le code du contrôle dans le source offert pour l’intégrer ailleurs.
Conclusion
Les bonnes idées partent souvent de constats simples et sont elles-mêmes simples. Il semblerait même que nous soyons très bons à trouver des choses complexes et totalement démunis lorsqu’il s’agit de trouver des choses simples. Même Léonard de Vinci, lorsqu’il pensait avion, objet volant il dessinait de délirantes machines avec voilure en spirale. Alors que s’il avait eu l’idée de simplement plier une feuille de papier comme tout gamin de nos jours sait le faire, il aurait tout de suite eu le profil d’un avion de chasse ou d’un planeur…
Même les meilleurs échouent à trouver la simplicité. C’est pourtant bien ce que nous propose ce simple Activity Button… Et c’est pour cela qu’il m’intéresse et que je vous en ai parlé. Bien au-delà du code (que je ne montre même pas), juste pour le plaisir d’un voyage entre un besoin et une solution simple…
Stay Tuned !