Parlons des notications ! Comme l’a mentionné Ryan Lortie, il a eu beaucoup de discussions entre les communautés Ubuntu, Kubuntu, GNOME, KDE et Mozilla qui étaient représentées à l’UDS au sujet des propositions faites pour Ubuntu 9.04 par les équipes de Canonical en charge de la conception de l’interface utilisateur de l’ingénierie du poste de travail.

Voir la vidéo de présentation au format Flash.

Il y a quelques idées assez audacieuses (lire : controversées) que nous avions envie d’explorer, c’était fantastique d’avoir la possibilité d’en discuter avec un large échantillon de la communauté. Il y avait plusieurs points délicats et des pièges qu’à mon avis nous avons réussi à éviter dans un premier temps, grâce à tous ceux qui ont participé. Certaines des choses sur lesquelles nous travaillons dans ces équipes sont faites en direct avec des partenaires pour leurs appareils, ce qui fait qu’ils ne voient pas ce niveau de discussion avant de livrer, mais c’est formidable quand nous avons l’opportunité de le faire.

Certaines de ces idées ne sont pas prouvées, elles se résument à des questions de point de vue, mais puisque notre engagement à leur égard se fonde sur le désir d’en savoir plus je les vois comme des expériences constructives. Les expériences ne sont que ça – des expériences. Elles peuvent être des succès ou des échecs. Nous devrions les juger avec précaution, une fois que nous avons les informations en main. Nous apportons de nouvelles idées pour le poste de travail Libre, sans égo. Nous savons que ces idées pourraient être meilleures ou pires que des travaux similaires faits dans d’autres communautés, et nous voulons recueillir les impressions de vrais utilisateurs pour tenter de trouver le meilleur compromis pour tout le monde. Les meilleures idées, et le meilleur code, formeront au final une partie des communs numériques du Logiciel Libre et seront partagés par GNOME, KDE et chaque distribution. Donc, à ceux qui sont ennuyés par le fait que nous puissions livrer autre chose que GNOME ou KDE par défaut, je voudrais leur demander d’être patient et de nous soutenir – nous voulons contribuer par de nouvelles idées et du code neuf, et cela implique quelques différences qui pourront servir de base à des discussions au sujet des orientations futures des projets en amont. Par le passé, nous avions peu de différences de ce type dans Ubuntu. Certaines, comme la disposition actuelle du poste de travail, ont été largement adoptées. D’autres, comme l’infâme « mode spatial Ubuntu », ne l’ont pas été. C’est la vie, et nous bénéficions tous de l’évolution.

Les expériences sont aussi des choses que nous ne devrons pas faire à la légère. Le poste de travail sous Ubuntu est une chose qui me tient à cœur ; je me sens personnellement responsable de la productivité et de la satisfaction de chaque utilisateur de Ubuntu, donc lorsque nous proposons de nouvelles idées et du code pour le poste de travail je pense que nous devons faire tout ce que nous pouvons pour être sûr de réussir du premier coup. Nous ne devons pas infliger de mauvaises idées à nos utilisateurs juste parce que nous sommes curieux, arrogants, butés ou fiers. En dépit du fait que nous puissions occasionnellement être curieux, arrogants, butés et fiers :-)

Alors, que proposons-nous ?

Tout d’abord, nous portons de l’attention aux notifications sur le poste de travail dans le cadre d’une étude plus large sur « l’espace entre les applications ».

Je pense que la meilleure aide que Canonical et Ubuntu puissent apporter à la cause du Logiciel Libre sera de s’investir sur les points de frictions qui existent entre les principaux composants du poste de travail. En d’autres termes, bien qu’il y ait déjà de grandes communautés en amont sur des applications individuelles pour le poste de travail du Logiciel Libre (Novell pour Evolution, Sun pour OpenOffice, Mozilla pour Firefox, Red Hat pourNetworkManager), nous pensons qu’il a beaucoup de travail productif et utile à faire sur ce qu’il manque entre elles. Les notifications sont des choses que font de nombreuses applications, et si nous apportons de nouvelles idées dans ce domaine alors nous aiderons à améliorer l’interface utilisateur de toutes ces applications. C’est un beau démultiplicateur de force – nous espérons faire un travail qui rende celui des autres communautés encore plus précieux.

Quoi qu’il en soit, attendez-vous à des heurts. Les idées que nous explorons peuvent entrer, pourront entrer et entrent déjà en conflit avec des concepts présents dans différentes applications. Nous pouvons nous occuper du code correspondant dans les paquets de « main », mais je suis plus préoccupé par la gestion d’une perturbation sociale potentielle que le conflit pourrait créer, et c’est plus une question de dialogue que de programmation.

Les notifications sont intéressantes, subtiles et complexes. Il y a beaucoup d’approches différentes sur de nombreuses plateformes différentes. Il y a beaucoup de scénarios d’utilisation. Nous essayons de réduire et d’éliminer la complexité, tout en permettant de traiter les scénarios d’utilisation que nous connaissons.

Il y a eu du bon travail de fait sur les notifications dans la communauté freedesktop.org, et même une spécification qui est *presque* en 1.0 dans cette communauté, avec des implémentations Open Source. Nos suggestions sont basées sur cette spécification, mais elles déprécient certaines de ses fonctions. Nous serons probablement compatibles avec l’interface de programmation applicative actuelle pour l’envoi des notifications, mais nous n’afficherons probablement pas toutes les notifications qui pourront être envoyées, si elles requièrent l’emploi de fonctions que nous déprécions. Si cette expérience se passe bien, nous espérons aider cette spécification de FD.o à passer en 1.0, avec ou sans nos modifications.

Les principales suggestions que nous faisons sont les suivantes :

• Il ne devrait y avoir aucune action sur les notifications.
• Les notifications ne devraient pas être affichées de manière synchrone, mais devraient pouvoir être placées en file d’attente. Notre implémentation de l’agent d’affichage des notifications n’affichera qu’une notification à un moment donné, d’autres pourrons procéder différemment.

C’est à peu près tout. Il y a des subtilités et des variations, mais ce sont les suggestions fondamentales que nous faisons, et que nous explorerons dans un netbook avec un partenaire, de même que dans la version générique de Ubuntu 9.04, à la grâce de Dieu.

Ce travail débouchera sur un nouvel agent d’affichage des notifications, et non sur une branche ou une modification de l’agent de notification actuel de GNOME. Nous ne pensons pas que l’interface de programmation applicative cliente – libnotify – ait besoin d’être modifiée pour cette expérience, bien que nous puissions ne pas afficher des notifications envoyées via cette interface de programmation applicative qui utilise des fonctions que nous suggérons de déprécier. Nous essaierons de faire en sorte que les paquets dans « main » soient modifiés de manière appropriée, et nous espérons que le MOTU aidera à l’identification et à la mise à jour des paquets requis dans « universe ».

Pourquoi un nouvel agent d’affichage des notifications ? Nous le concevons pour être développé avec Qt sur KDE et Gtk sur GNOME. L’idée est d’avoir le plus de code possible en commun, mais de pouvoir néanmoins tirer parti de l’environnement d’affichage de texte approprié sur Ubuntu et Kunbuntu. Nous espérons livrer les deux simultanément, et nous en avons parlé avec des membres des deux communautés Ubuntu et Kubuntu. Pour l’instant, il y a quelques désaccords entre GNOME et KDE à propos du statut de la spécification de FD.o, et nous espérons que nos efforts aiderons à établir un pont entre les deux communautés. Dans Ubuntu 9.04, nous souhaitons continuer à maintenir et à publier les paquets de l’agent de notification existant en complément, pour offrir les deux options aux utilisateurs qui ont une préférence particulière. En général, là où nous investissons dans des travaux expérimentaux, nous prévoyons de continuer à offrir un composant ou un paquet standard de GNOME ou de KDE dans l’archive de sorte que chacun puisse en profiter à sa guise.

Le point le plus controversé de cette proposition est l’idée que les notifications ne doivent pas être associées à des actions. Autrement dit, pas de boutons, d’ascenseurs, de liens ou même d’annulation [x]. Lorsqu’une notification arrivera, vous ne pourrez pas cliquer dessus, vous ne pourrez pas la faire disparaître, vous ne pourrez pas continuer vers une autre fenêtre ou une page Web. Vous aimez cette liberté ? Hmmm ? Aliénation, à première vue, mais il y a de la méthode dans cette aliénation.

Notre hypothèse est que l’existence de N’IMPORTE QUELLE action crée une obligation pressante d’agir, ou de PENSER À AGIR. Cela fait passer les notifications du statut de jeu à celui de travail. Cela leur donne de lourdes responsabilités. Cela en fait des interruptions, non des notifications. Et les interruptions sont ennuyeuses lorsque vous avez des choses à faire.

Nous avons donc à nous battre sur trois fronts.

1. Nous voulons rendre les notifications vraiment éphémères. Elles sont ici, et puis elles sont parties, et c’est la vie. Si vous êtes devant votre poste de travail lorsqu’une notification arrive, vous la percevrez, et si vous voulez vous pourrez la REGARDER, et elle sera belle, claire et simple à comprendre. Si vous voulez l’ignorer, vous pourrez le faire sans crainte et elle partira chaque fois sans que n’ayez à l’annuler, c’est OK. Les notifications concernent uniquement des choses que vous pouvez ignorer ou manquer. Si vous êtes sorti prendre un café et qu’une notification arrive, vous ne vous en porterez pas plus mal. Elles ne s’empilent pas comme le courriel, il n’y a pas de journal de celles que vous avez raté, vous ne pouvez pas faire défiler l’écran en arrière et les voir à nouveau, et d’ailleurs vous n’avez pas d’obligation de le faire – elles ne peuvent pas devenir un travail alors que vous êtes déjà occupé à quelque chose d’autre. Elles sont parties comme une fille mystérieuse dans le bus que vous n’avez pas pris, et elles enrichissent votre vie exactement de la même manière !
2. Nous pensons qu’il devrait y avoir des indicateurs persistants pour les choses que vous devez réellement savoir, même si vous avez raté la notification parce que vous avez eu un besoin urgent d’un café. Nous sommes donc en train de faire une liste de ces choses, et nous prévoyons de les implémenter.
3. Tout le reste devrait être traité via une fenêtre qui attire l’attention, située en arrière-plan, à moins que ce soit vraiment important auquel cas la fenêtre pourrait passer en avant-plan.

Comme il s’agit clairement d’un travail sur plusieurs versions, nous pourrons identifier des problèmes et des inconsistances en chemin notamment à l’occasion des points de contrôles. J’espère que non, mais ce n’est pas improbable, en particulier lors de la première itération. Ces idées pourraient également se révéler sans intérêt, et nous devrions être prêts à changer de direction en fonction des retours une fois que nous aurons une implémentation dans la nature.

Nous avons eu un superbe « sprint » UXD et DEE (équipe conception de l’interface utilisateur et équipe ingénierie du poste de travail) à San Francisco la semaine précédent l’UDS. Merci à tous ceux qui y ont participé, en particulier ceux qui venaient d’autres équipes. Ce travail sur les notifications pourrait bien n’être que la partie visible de l’iceberg, mais c’est un joli petit morceau :-)

Un ou plusieurs de nos partenaires OEM proches (sociétés avec lesquelles nous travaillons sur les nouvelles fonctions du poste de travail) proposeront probablement ces fonctionnalités via un netbook au cours du cycle 9.04. À ce stade, nous déposerons également le code dans un PPA pour effectuer des tests avec un plus grand nombre d’applications. Il y a des discussions actives concernant la révision de la spécification de freedesktop.org en se basant sur ce travail. Je pense que nous devrons être prudents, et que nous devrons collecter les impressions de vrais testeurs ainsi que des données solides, mais si tout ce passe bien nous pourrons proposer une simplification de la spécification, et nous soumettrons notre agent d’affichage de notifications à FreeDesktop.org. Une collaboration à long terme autour du code aura lieu sur Launchpad.

Origine : Notifications, indicators and alerts