La soirée commence par un rapide tour de présentation où chacun expose en quelques mots qui il/elle est et le but de leur présence ce soir. En grande majorité, les gens sont des développeurs Android mais aussi quelques curieux. qui viennent pour découvrir Android. Quant à la principale motivation à assister à la soirée, elle est tout simplement de venir à la rencontre de la communauté.
1ère partie :
La première présentation commence avec Nicolas Chambrier, consultant/architecte chez Clever Age, qui vient nous parler de la mise en place de la Quick Action Popup.
Il y a quelques mois de cela, Google a réalisé pour Twitter un client Android. Cette application a marqué les esprits pour son aspect design et ergonomie. Alors qu’Android était critiqué pour ses interfaces “moches”, Twitter for Android arrive et se présente comme un modèle à suivre. Bien que Google ait annoncé qu’elle serait open-source, on attends toujours ….
Ce modèle suit 3 grands principes :
- Action bar : A la place de la barre fine de titre, une barre plus épaisse qui contient les actions auxquelles l’utilisateur aura souvent accès. Pour les actions secondaires, profitons du fait qu’un Android contrairement à un IPhone possède un bouton menu. Il y aussi la touche “search” qui est un peu particulière. Elle sert à indiquer à l’utilisateur qu’une recherche est disponible dans l’application. Il aussi recommandé de rendre cette recherche accessible depuis le bouton “Rechercher” du téléphone. A ce propos, attention car bien qu’il soit disponible sur beaucoup de modèle, ce bouton est facultatif. Le Samsung Galaxy S par exemple n’en possède pas.
- Quick Action Popup : C’est un menu contextuel. Pourquoi pas de menu classique ? Tout d’abord parce que c’est plus joli mais aussi par ce que c’est moins encombrant et qu’au niveau visuel c’est moins stressant. Par contre, inconvénant : c’est plus complexe à mettre en place car ce type de composant n’existe pas dans Android.
- Voir toutes les zones de l’application : l’écran d’accueil de l’application affiche les différentes Activity. La navigation se retrouve ainsi simplifiée.
Même si Google propose des idées sur la façon d’organiser, il ne donne pas vraiment de conseils sur la façon de faire.
Il faut aussi savoir prendre du recul, joli est différent d’ergonomique : une application joli peut ne pas être du tout ergonomique et inversement. De plus nos applications n’ont pas forcément les mêmes besoins. Avant de se lancer, il faut bien réfléchir à comment rendre facile l’accès au différentes Activity et ne pas hésiter à crayonner sur papier ses idées.
La théorie, c’est bien beau, mais qu’en est il en pratique ? Nicolas nous livre maintenant un retour d’expérience sur son application : Horaire TER SNCF.
Elle a eu une refonte graphique complète en adoptant certaines des propositions. Cette refonte a été faite avec l’aide d’un designer qui comme pour une maquette web a réalisé un psd. Il ne restait plus qu’à découper cette maquette pour intégrer les images. Cette refonte adopte aussi les Quick Action Popup.
L’idée de ces Quick Action Popup, c’est de pouvoir mettre en place derrière un système de plug-in, pour étendre l’application, au cas où l’application remporte un immense succès. Le plus simple et de commencer par implémenter un simple menu. Il faut aussi se demander si c’est applicable, c’est vrai que c’est joli, mais si le reste est moche ….
Le mieux est de commencer par implémenter par un contextuel, quand c'est ok on fait les QAP.
Il faut aussi se demande sir c'est applicable. C'est joli mais si le reste est moche ….
Reste à voir comment implémenter. Et là, Google n’aide pas . Il faut donc aller voir du coté des initiatives personnelles :
- WHSFinder
- Simple Quick Action : Plus détaille et bon choix pour s’inspirer
- Lorenz
- DevoTeam Quick Actions : inspiré par WHSFinder, mais avec une doc
- Horaire TER SNCF, l’initiative de Nicolas
Pourquoi donc a t-il ré-inventé la roue ?
En réalité, ce n’est pas si compliqué à développer, une cinquantaine de lignes de code suffisent. Une autre raison est le besoin spécifique par rapport au système de plug-in.
Il y tout de même des contraintes : il faut des compétences graphiques et le layout est limité à un background.
Pour intégrer, c’est très simple, il suffit d’incorporer le jar dans son projet. Un peu de code suffira pour faire le reste.
Il existe aussi d’autres ressource comme GreenDroid de Cyril Mottier.
Les slides :
http://www.slideshare.net/naholyr/paris-android-user-group
2ème partie :
Pour cette partie, c’est Ludovic Perrier, qui nous parle d’Ergonomie et Design sur Android.
Cette présentation se veut très générale, il n’y aura pas de code, juste quelques règles et du bon sens que l’on acquière en développant. Tout cela est extrait de son livre en cours de rédaction. Ce dernier est co-écrit avec Cyril Mottier et devrait être disponible en fin d’année chez DigitBook.
Pourquoi faut il s’attacher au design et à l'ergonomie ?
Tout simplement pour rendre l’application utilisable. Il ne faut pas perdre de vue qu’il faut garder le look&feel Android. On voit parfois des applications qui possèdent un bouton retour tout comme une application Iphone... Ce qui ne sert à rien, un téléphone Android possède un bouton retour. L’utilisateur peut être exigeant et vouloir la même application que sous IPhone, il n’est pas toujours évident de lui faire comprendre que ce n’est pas ce qu’il de mieux pour l’application.
Coté lanceur d’application, Google a très peu évolué ses roms depuis le début. Les roms constructeurs quant à elles proposent parfois un modèle assez différent. Samsung propose par exemple pour son Galaxy S un fonctionnement assez IPhoneLike avec son défilement horizontal.
Coté navigation matérielle, c’est assez hétérogène, on peut ainsi trouver : clavier physique, trackbal, trackpad, tactile, bouton physique optionnel, ….
Ce sont des facteurs auxquels il faut prêter attention : le trackpack ne possède pas de diagonale, sous certains modèle la pression sur 2 boutons en même temps ne fonctionne pas, bouton “rechercher” est facultatif, les boutons ne sont pas toujours placé au même endroit. D’où l’importance dans ce dernier cas de laisser la possibilité à l’utilisateur de paramétrer les boutons si l’on s’en sert (cas d’un jeu).
Il est important d’aller à l'essentiel, de fournir uniquement ce dont l’utilisateur a besoin. Pour les autres besoins, il est toujours possible d’utiliser des boutons d’actions. Les splash screens, c’est pour iOS, sous Android, il existe d’autre technique, comme un chargement en arrière plan.
Et pour finir quelques règles d’or :
- L’utilisateur doit pouvoir annuler une action, il faut donc faire des requêtes annulable. En effet, si l’on lance une action dont on ignore l’action, il est assez gênant ne peut pas pouvoir la stopper.
- Le mode plein écran est déconseillé : il ne faut pas oublier que notre application n’est pas seule. Il faut penser au notification que laisse les autres comme par exemple : réception d’un mail ou d’un sms.
- A partir d’environ 4 activités, un écran dashboard est conseillé, c’est moins fouillis.
- Il faut adapter l’interface à chaque état (selectionné, pressé, focus, ….). Ainsi, l'utilisateur se rends mieux compte de ce qu’il fait.
- Le scroll est une action assez lassante, il ne faut pas trop en abuser. Mieux vaut sectoriser si l’on a beaucoup de données.
- Une application intuitive n’a pas besoin d’aide. Qui n’a jamais été agacé par le trombone de Word ?
- Il faut penser à M Tout le monde, se mettre à sa place. Il est difficile de faire une application qui plaît à tout le monde.
Les slides :
https://docs.google.com/present/view?id=0AessGL44h9tEZGdzdzY3YmNfMjgwY2ozNDRtZms&hl=en&authkey=CP2draQK
Comme beaucoup d’évènements, c’est autour d’un pot que se termine la soirée. Il sera la scène de diverses discussions comme la possibilité de créer un évènement semblable sur Lyon, les widget; ou encore des démonstrations d’une application de réalité augmentée de chez DiotaSoft.
Pour ceux que ça intéresse, voici le google group :
http://groups.google.com/group/paris-android-ug
Articles
