Je n'ai pas fermé mon compte Google par anti-Googlisme primaire : je l'ai fait par opposition aux nouvelles règles de gestion des données privées de la firme de Mountain View, et à sa politique générale. Je continue donc à utiliser certains services Google lorsqu'ils sont tout simplement irremplaçables, comme les Webmaster Tools, tout en cherchant à minimiser leur impact. J'ai ainsi quasiment réussi à me passer de Google Maps.
Sur le web
Avant même de m'éloigner des produits de Google, je n'étais pas un grand utilisateur de la version web de Google Maps, lui préférant Bing Maps. Alors que Google utilise beaucoup les données de Tele Atlas (TomTom), Microsoft préfère celles de Navteq (Nokia) : je n'ai jamais perçu de réelles différences dans le cadre de mon utilisation. J'ai néanmoins toujours préféré les tuiles et la sémantique visuelle de Microsoft, tout comme le zoom progressif de Bing Maps.
Une ancienne adresse.
Lorsqu'il s'agit de faire des captures d'écran pour situer un lieu pour information, j'apprécie énormément le mode « Vue d'ensemble » de Bing : au lieu d'utiliser des vues satellite, il utilise des photographies aériennes prises à 45°. La sensation de profondeur est impressionante et ne se fait pas au détriment de la densité d'informations.
La grande force de Google reste néanmoins le mode Street View : son équivalent chez Microsoft, Streetside, en est encore à ses balbutiements. Mais là où on peut l'activer, Bing Maps met une raclée à Google Maps : il y a beaucoup moins d'artefacts et autres bizarreries, la navigation est beaucoup fluide, et le degré de précision beaucoup plus grand. C'est tout simplement superbe.
J'utilise aussi assez régulièrement OpenStreetMap, un système de cartographie libre et coopératif. J'apprécie notamment le mode « Carte de transport », qui projette les lignes de transport en commun sur la carte, ainsi que le mode « Carte cyclable », qui projette quant à lui les pistes cyclables, les stations de vélos, etc.
Pistes cyclables et services aux cyclistes dans mon quartier.
Sur iPhone et iPad
C'est sur iPhone et iPad qu'il est le plus difficile de se passer de Google Maps, puisque Google est le fournisseur de données cartographiques d'Apple. En attendant iOS 6 et un possible nouveau fournisseur, il est quasiment impossible d'éviter Google Maps dans les applications tierces, puisque c'est une brique de base du système. Ce n'est pas particulièrement grave, puisque les données fournies ne sont pas liées à un compte — j'aurais plutôt à me plaindre d'Apple qui utilise mon iPhone comme un appareil de relevé de données en temps réel (au moins le fait elle anonymement et sans le lier à mes autres données). Reste que l'on peut d'ores et déjà remplacer l'application Plans par d'autres qui utilisent d'autres sources que Google Maps.
Je n'ai pas trouvé d'applications convaincantes utilisant Bing Maps, mais je suis tombé sur deux pépites se fournissant chez OpenStreetMap. La première est OpenMaps, un simple remplaçant de Plans utilisant OpenStreetMap qui a la bonne idée d'afficher la carte… sur l'intégralité de l'écran, sans la lourde interface de l'application par défaut. On peut ajouter des boutons vers des fonctions précises : je me suis contenté d'un bouton « Localiser », qui permet de centrer le plan sur ma position, soit 90 % de mon usage de l'application Plans.
Les 10 % restants couvrent l'utilisation de la fonction Itinéraire, quand je suis pressé et que je n'ai pas envie de faire confiance à mon sens de l'orientation dans un endroit inconnu. OpenMaps peut utiliser le service d'itinéraire gratuit de YourNavigation, qui est plutôt fiable (son itinéraire de chez moi au travail est le même que le mien, à la fois le plus rapide et le plus court). Bonus : OpenMaps gère différents types de tuiles, dont les excellentes de Stamen Design (j'adore les tuiles Toner, à fort contraste), ainsi que les modes transport et cycles.
POI+ est un bon complément : il permet d'ajouter facilement des points d'intérêts non-référencés par OpenStreetMap et ainsi de devenir acteur de l'entreprise de cartographie, et non plus simple consommateur. Cela peut paraître un détail, mais j'ai par exemple ajouté un passage piéton près du bureau qui n'était pas référencé — cela peut par exemple être utile aux déficients visuels.
Waze, que je n'utilise pas mais qui peut être utile aux conducteurs, est un système de navigation turn-by-turn qui utilise lui aussi OpenStreetMap, et est disponible sur iPhone comme sur iPad.
Les jeux d'APIs
Puisqu'il m'arrive encore de temps en temps de développer des applications web et que la localisation est une donnée importante, il me faut noter que Google Maps domine dans ce domaine de la tête et des épaules tous ses concurrents. L'API mise à disposition par Google est tout à la fois facile à mettre en place, rapide à charger, puissante et flexible. Même mes projets censés me permettre de reprendre le contrôle de l'intégralité de ma vie numérique utilisent Google Maps, c'est dire.
Et c'est donc la première capture publique du « projet Hugo ».
Il me semble néanmoins qu'OpenStreetMap pourrait rapidement rattraper son retard : les données de ce projet sont tout simplement excellentes, parfaitement mises à jour, et la communauté les entourant très dynamique. De quoi réellement parachever mon indépendance de Google Maps.
J'utilise moins iCloud pour stocker mes brouillons que comme une autre façon d'y accéder. Ce n'est pas donc une boîte noire ou ce que j'appelle un entonnoir, un cul-de-sac duquel il est difficile de sortir mes fichiers et qui créé donc des frictions — ce serait un comble pour quelqu'un qui prétend à la zénitude dans son travail ! C'est tout au plus un sablier, un passage un peu plus étroit pour être plus concentré, mais totalement intégré au reste de mon flux de travail.
Je m'explique.
Tous mes brouillons sont stockés dans un sous-dossier Brouillons du dossier Vault de ma Dropbox, qui contient tous mes fichiers. Cette proximité « géographique » avec les milliers de fichiers générés par mon activité chez MacG à acquis un petit côté angoissant, l'impression de toujours écrire la même chose avec le même outil et de jamais prendre de pause. J'ai donc décidé de déporter ce dossier Brouillons dans iCloud — déporter, et pas déplacer.
Un problème d'iCloud est qu'il gère les fichiers par application : les notes textuelles ne sont pas regroupées par type, mais réparties dans divers dossiers selon qu'elles aient été créées avec iA Writer, Byword, TextEdit ou une autre outil. Ce système multiplie ainsi les entonnoirs, les mécanismes où il est plus facile de faire entrer des fichiers que de le faire sortir. Mais ce n'est pas une fatalité ! Le principal avantage d'iCloud est de stocker les fichiers non dans une base ou dans un paquet, mais dans un simple dossier accessible dans le Finder — pour Byword, il s'agit d'un dossier du genre ~/Bibliothèque/MobileDocuments/#####~byword/Documents/, utilisé à la fois par Byword pour Mac et Byword pour iOS, sachant que j'utilise les deux applications. L'effet « boîte noire » d'iCloud est donc bien plus limité que ses détracteurs ne veulent le faire croire : les fichiers sont certes mis à disposition par le nuage, mais ils sont stockés en local dans le format natif de l'application qui les a créé1.
L'accessibilité des fichiers d'iCloud et leur intégration transparente dans mon flux de travail tient à un simple lien symbolique (ln -s) : je fais croire à iCloud que le dossier ~/Bibliothèque/MobileDocuments/#####~byword/Documents/ est plein de documents, mais il pointe en fait vers le dossier Brouillons de ma Dropbox. Ainsi, mes fichiers restent gentiment dans la Dropbox, où ils sont sauvegardés à l'infini et surtout à disposition directe de toutes mes applications : mon flux de travail normal n'a pas bougé d'un iota. Mais à travers le lien symbolique, ils sont aussi accessibles via iCloud, et d'ailleurs sauvegardés à l'infini une nouvelle fois : iCloud est donc une autre porte d'entrée, complètement indolore. Pas de format(age) de fichier exotique (comme celui de Day One qui utilise des fichiers PLIST), pas de modification du nom de mes fichiers et de leur extension et donc de rupture de mon workflow, etc.
J'abandonne demain Byword au profit d'une autre interface ? Il me suffit de casser le lien symbolique, et de mettre en relation mon dossier Brouillons avec le dossier iCloud de ma nouvelle application de choix. J'abandonne iCloud ? La belle affaire, c'est un simple moyen d'accès à mes fichiers, et pas le seul endroit où ils sont stockés. En attendant, j'ai l'impression que mes fichiers personnels sont séparés de mes fichiers professionnels, parce que j'y accède par un chemin différent. C'est reposant parce que cela me donne l'impression d'une franche coupure, alors que rien n'a réellement changé dans la gestion basique de ces fichiers.
Tout bénéfice donc, et voilà pourquoi iCloud est un sablier, et non un entonnoir.
C'est la même chose pour le Flux de photos, exploitable même sans iPhoto ou Aperture, comme l'a expliqué par exemple mon collègue Nicolas sur MacGeneration.
Une boîte ou un navigateur ne devraient jamais être utilisés comme gestionnaires de tâches. Alors qu'il existe de petits logiciels spécialisés que l'on appelle… gestionnaires de tâches.
J'ai toujours eu tendance à considérer ma boîte mail comme un gestionnaire de tâches. Il faut dire que le Mail d'OS X, conçu pour répondre aux besoins de Steve Jobs, y invite : en plus de l'état lu / non-lu qui est comme un état fait / à faire, des drapeaux pour mettre des éléments de côté, et d'un excellent champ de recherche, il dispose d'un module de notes.
Ces derniers temps, j'ai aussi la fâcheuse habitude d'ouvrir des centaines d'onglet dans mon navigateur, chose que je cantonnais autrefois à Omniweb et son système de sessions pour mes recherches. J'ai toujours eu à gérer plusieurs sujets de front, mais je n'ai désormais plus peur de perdre ma session avec la fonction de Reprise d'OS X, et ait donc perdu l'habitude de créer des dossiers de signets. Des dizaines de mails qui s'empilent, des centaines d'onglets qui ralentissent mon navigateur, c'est se construire une pression : la boîte mail est pleine le matin en se levant, l'est toujours le soir en allant se coucher, et on atteint jamais le moment où l'on ferme le dernier onglet du navigateur avec le sentiment du travail accompli. Ça n'a pas l'air comme ça, mais ça a son petit effet psychologique, comme les textes en cours jamais fermés dans Byword.
Ces mails et ces onglets ne sont pourtant pas un fardeau : correctement gérés, ce sont des informations cruciales pour être productif, et non un frein. Si un mail n'appelle qu'à une réponse et que je peux y répondre imédiatement, autant le faire, au plus tard à la prochaine pause café1 — cela me prendra plus de temps de le faire quand 100 courriels se seront entassés. Si un mail appelle à une action plus complexe, là encore, je la prévois immédiatement : les articles à écrire et les projets en plusieurs parties qui nécessitent un travail collaboratif sont envoyés dans Daylite, le reste est tout simplement mis dans mon calendrier. Même chose avec les onglets : puisqu'ils sont en général des liens vers du matériel brut pour un futur article, pourquoi donc ne pas noter l'échéance de l'article quelque part, et indexer les onglets soit un dossier de signets, soit dans une application de lecture différée ?
Inbox zero quasi-permanente = bonheur.
Au delà de ces outils, je n'ai pas de recommandation particulière à faire : il y a au moins 15 000 applications différentes qui peuvent être reliées à la gestion de tâches, et chacun trouvera chaussure à son pied. Si j'ai donc un conseil, c'est d'évaluer la situation et d'agir en conséquence, en essayant divers outils jusqu'à que ça aille. Ou en développant le sien si rien ne fonctionne, paraît que les meilleurs logiciels sont nés comme ça. Mon système de gestion informationelle n'est pas le meilleur logiciel de sa catégorie, mais je l'ai précisément codé parce que je n'arrivais pas à trouver de solution satisfaisante pour les archives à long terme sur des sujets vagues sans impératif de publication. Pour des besoins plus urgents, j'utilise beaucoup Readability, qui est plus facile à nettoyer que les dossiers de signets. Enfin, le fait de tester OS X Mountain Lion m'avantage, puisque je peux utiliser le Calendrier et l'application Rappels en conjonction avec mon iPhone, ce qui me suffit largement.
Je n'associe pas forcément mes rappels à des alarmes. Le simple fait d'ouvrir le Centre de notifications le matin me permet de savoir précisément ce que je vais faire dans la journée, et donc de commencer à brancher les bonnes prises dans ma tête.
Au final, toute cette masse d'informations qui si elle n'est pas traitée fait du bruit est ainsi filtrée, domptée, pour devenir du signal. C'est un changement qui au quotidien requiert une certaine discipline pour être mis en place — j'avoue parfois laisser le mail dériver, mais c'est aussi parce que je travaille en ce moment sur des sujets plus longs — mais qui fait gagner un temps fou à la fin de la journée. Et qui permet surtout de fermer Firefox à 19h00 sans rien avoir laissé dedans, et de rentrer à la maison sans avoir l'impression de ramener du boulot sous la forme de 25 mails à lire : j'ai fini ma journée, je n'ai plus rien à faire, je vais aller faire la sieste. Ou faire un tour. Ou boire un coup. Prendre l'air, m'oxygéner les poumons, et, surtout, le cerveau.
C'est ma version très personnelle de la « two-minute rule » de David Allen. Je crois que Merlin Mann a un truc similaire dans sa série Inbox Zero, mais je ne l'ai pas lu depuis longtemps et ait toujours eu du mal à accrocher.
Mes participations récentes à La Minute Apple et au Clubcast d'Edencast m'ont rappelé à quel point j'aimais le podcasting : MacStyle fut précédé par un podcast audio dont le nom doit rester enfoui dans les décombres de l'internet, et l'Apple News MQCD reste un excellent souvenir. L'idée de réaliser un nouveau podcast me trottait donc dans la tête depuis plusieurs mois : après un faux départ, le métro [podcast] dodo est donc lancé.
Faux départ, car ce podcast aurait dû s'appeler le [zen]cast… une marque déposée par Creative qui désigne, ironie du sort, un ancien concurrent de l'agrégateur de podcasts d'iTunes. Vu le souvenir inexistant que j'en avais, il a dû connaître un formidable succès. Je tiens à remercier les nombreux lecteurs qui ont participé au sondage qui a fait de métro [podcast] dodo le nom du podcast de métro [zen] dodo.
Le métro [podcast] dodo adopte un format d'une demi-heure : c'est plus long que les capsules de quelques minutes, ce qui permet de véritablement poser la discussion, mais aussi beaucoup plus court que la plupart des podcasts, qui dépassent 1h30 et sont souvent assez décousus. Chaque épisode abordera un sujet unique, souvent en rapport avec les problématiques de métro [zen] dodo, mais pas forcément. Pour commencer, un épisode du métro [podcast] dodo sera publié tous les quinze jours le dimanche matin, avec un invité à chaque fois.
Le métro [podcast] dodo dispose de son propre site, où chaque épisode sera annoncé et accompagné de liens sur les sujets abordés. Vous pouvez vous abonner au métro [podcast] dodo dans iTunes : ce n'est pas quelque chose que j'ai l'habitude de demander, mais n'hésitez pas à laisser un commentaire ou donner une note, vos avis garantissant la visibilité du podcast dans l'iTunes Store. Enfin, si vous voulez participer, n'hésitez pas une seconde à me contacter, ce sera un plaisir.
Rendez-vous donc dans quinze jours pour le premier « vrai » épisode de métro [podcast] dodo.
On dira que je chipote, mais j'ai la sensation que l'équipe d'Ars Technica a loupé une occasion en lançant sa septième version. L'arrangement par défaut, de type magazine, fonctionne mieux que la moyenne : il répartit les différents types de contenu le long d'une grille — les contenus d'actualité à gauche, les articles de fond à droite, et les éléments interactifs (revue du web et classement par popularité) entre les deux.
Mais regardez, là, en haut à droite : il y a un bouton qui permet de changer l'apparence du site. Mais si, je vous dit, le tout petit bouton « Layout » entre l'énorme emplacement de pub et l'énorme bannière de promotion du dernier article de fond.
Il permet d'activer un mode « archive », tout simplement une vue antéchronologique type blog. Mais une vue, là encore, qui fonctionne mieux que la moyenne : le dernier article de fond fait office de une, et la liste déroule le contenu, les articles de fond étant plus particulièrement soulignés. C'est clair, c'est net, ça a un excellent rapport signal / encombrement, et ça donne envie de lire. Et c'est surtout organisé de la même manière que la page de lecture d'un article, elle aussi un modèle de clarté.
D'où la question : mais pourquoi, Ars, pourquoi ? Pourquoi ce bouton ? Est-ce que tu hésitais entre les deux designs, ou est-ce que tu avais peur que tes lecteurs n'apprécient pas le mode « magazine » ? Pourquoi, par défaut, présenter une interface incohérente, portant à droite sur la page d'accueil et à gauche sur la page d'un article ? Pourquoi ? Dans un cas comme dans l'autre, pourquoi ne pas avoir fait un choix clair, assumé ? Ce bouton est tout petit, mais il pose de grandes questions. D'autant plus grandes que l'ensemble est tout simplement impressionnant de clarté, ce qui prouve que la publicité peut ne pas dévisager un site — je vais sans doute m'abonner de nouveau à Ars, pour le coup.
![métro [zen] dodo](./templates/assets/images/logo.png){kind=logo}
