L’équipe interface utilisateur et design de Canonical compte quelques personnes dédiées à la technologie Web. À l’heure actuelle, un effort important est fait pour remodeler l’interface utilisateur de Launchpad maintenant que le noyau des fonctionnalités pour le suivi des bogues entre projets, la publication de code et la traduction est en place. Nous voulons clarifier la réalisation de tâches – en particulier pour les nouveaux utilisateurs – et nous voulons que lorsque vous apportez de petites modifications à votre projet, cela soit intuitif et réactif.

Au cours des discussions sur le design, nous avons passé beaucoup de temps à travailler sur une nouvelle approche des “boîtes de dialogues, assistants et flux de travaux”, en essayant de solutionner un problème épineux dans l’interaction avec l’utilisateur : comment simplifier quelque chose qui est complexe à réaliser ? Il y a de nombreuses situations dans Launchpad où vous devez être très bien organisé avant de pouvoir faire quelque chose. Par exemple, vous pourriez avoir besoin de vous assurer qu’il y a une équipe incluant des personnes spécifiques avant d’abonner cette équipe à une bogue. Vous pourriez aussi avoir besoin de créer une nouvelle version pendant que vous faites du triage et de la planification de travail à faire sur des bogues dans votre projet.

Actuellement, cela implique que vous alliez dans différents endroits de Launchpad avec une aisance qui suppose que vous savez exactement comment toutes les parties fonctionnent. Vous devez aller dans un endroit pour enregistrer une équipe et dans un endroit complètement différent pour créer une version. Cela fait que de nombreuses personnes n’utilisent pas certaines fonctionnalités de Launchpad, car elles doivent comprendre le système dans son ensemble avant de pouvoir faire la moindre chose. Chaque fois que quelqu’un se casse la tête là-dessus, nous échouons ! Et c’est le problème que nous avons cherché à résoudre.

Nous sommes arrivés à une solution astucieuse, que nous avons appelé formulaires dynamiques (« morphing dialogs »), qui assure que l’utilisateur a toujours un nombre minimum de choix à faire, et qui autorise néanmoins des variations complexes au cours d’un processus tout en restant assez naturelle aux utilisateurs.

Les idées clés sur lesquelles reposent les formulaires dynamiques sont :

• Ne requérir qu’une seule décision importante à la fois, et faire en sorte qu’elle soit explicite. Il y a parfois plusieurs façons de faire quelque chose, mais il y a en général un seul chemin normal que les utilisateurs peuvent suivre, et nous voulons toujours que les utilisateurs puissent faire facilement les choses simples.
• Donner aux utilisateurs une idée de l’avancement du processus, sans être trop dogmatique, car la réalisation d’une étape implique souvent qu’il faille faire d’autres choses en parallèle et que ces détours peuvent également nécessiter plusieurs étapes.

Voici une vidéo d’exemple, qui montre une personne liant un schéma directeur à une bogue. Il doit chercher le schéma directeur adapté, ce qu’il peut faire sur plusieurs projets simultanément. Dans le cas présent, il ajoute GNOME à la liste des projets dans lesquels il recherche un schéma directeur, et lorsqu’il ne peut pas le trouver, il va enregistrer un nouveau schéma directeur correspondant à ce qu’il veut. À la fin, il décide de revenir en arrière et d’en choisir un dans les résultats d’une recherche. Rien de tout cela n’a induit le chargement d’une page, et les allers-retours avec le serveur sont moins coûteux que le chargement de pages complètes, puisque nous pouvons obtenir ce dont nous avons besoin de manière très optimisée.

Vous pouvez voir quelques idées clés se dégager de la vidéo.

Notez que la “barre de progression” – la ligne verte – n’est pas particulièrement grande ou envahissante. Ce n’est pas non plus évident qu’il s’agit d’une barre de progression, jusqu’à ce qu’on ait terminé quelques processus multi-étapes. Notez également que vous pouvez faire des détours ; vous pouvez faire quelque chose en parallèle, comme enregistrer une équipe ou enregistrer un schéma directeur, et ces détours ont leur propre indicateur de progression qui est distinct du principal.

Nous avons récemment fait un « sprint » important qui a réunit toute l’équipe de Launchpad pendant deux semaines au cours desquelles nous nous sommes profondément immergés dans JavaScript et Ajax. Nous avons choisi YUI 3, la prochaine version de la librairie d’interface utilisateur pour le Web de Yahoo, comme fondation pour ce travail avec Ajax, et nous voulions que tout le monde soit opérationnel pour accélérer les processus de conception, de réalisation et de test d’applications clientes Web. Ce fut très plaisant.

Nous voulions, en particulier, unifier l’interface de programmation applicative pour services Web que nous avions déjà publié avec ce travail sur Ajax, pour qu’il soit facile d’écrire du code pour navigateur qui puisse communiquer avec l’interface de programmation applicative telle que nous l’avons mise à disposition des développeurs qui intègrent Launchpad. C’est maintenant possible, ce qui signifie que toute interface de programmation applicative que nous utilisons pour travailler avec Ajax pourra aussi être utilisée par les développeurs qui écrivent leurs propres outils pour accéder à Launchpad directement au travers de services Web.

Grâce aux atouts de YUI 3, l’équipe travaille maintenant d’arrache-pied pour faire passer ces idées du rêve à la réalité. Étant donné que YUI 3 est un projet d’avant-garde (certains diraient à l’avant garde !) nous nous concentrons sur les parties qui ne dépendent pas de widgets complexes – celles-ci commenceront à être en place l’année prochaine lorsque YUI 3 sortira de sa phase de développement.

Au cours des deux prochains mois vous verrez arriver des pièces de ce puzzle dans les versions mensuelles successives de Launchpad (ou quotidiennement, si vous êtes sur edge.launchpad.net et bêta testeur). Dans un premier temps, l’effet Ajax permettra juste l’édition en ligne. Dans six à neuf mois, les parties les plus complexes devraient être en place. Et d’ici là l’interface Web frontale de Launchpad sera aussi Open Source.

Origine : Morphing dialogs and the AJAX roadmap for Launchpad (http://www.markshuttleworth.com/archives/239)