L’indépendance de la résolution

Lancez votre traitement de texte habituel, et ouvrez un document vierge au format A4. Maintenant, prenez une feuille au format A4 et superposez-la à la page affichée à l’écran: cela ne vous surprend peut-être plus, mais la feuille est plus grande que sa représentation à l’écran. Ne trouvez-vous pas troublant qu’en 2010, les ordinateurs ne sachent pas afficher les documents en taille réelle à l’écran ?

Une histoire de résolution

Revenons d’abord sur cette histoire de résolution. La résolution est une mesure du nombre de points (en l’occurrence pour un écran, des pixels) alignés sur une longueur d’un pouce (2,54 cm). On utilise souvent l’abréviation anglaise dpi («Dots Per Inch»), même si l’abréviation française ppp («Points Par Pouce») est courante.

Faisons un rapide calcul: l’écran de mon iMac G5 présente des dimensions physiques de 14,4 x 9 pouces (soit 36,58 x 22,86 cm). Il affiche 1440 x 900 pixels. Sa résolution horizontale est donc de 1440 / 14,4 = 100 ppp. Et sa résolution verticale est de 900 / 9 = 100 ppp.
 Le fait que la résolution soit la même horizontalement et verticalement indique que les pixels de l’écran sont carrés (il existe des écrans avec des pixels rectangulaires).

Les logiciels ne dessinent pas à l’échelle

Nous en verrons la raison plus loin, mais sur recommandation d’Apple, les logiciels considèrent que l’écran présente une résolution de 72 ppp. Ce choix de 72 ppp s’explique pour des raisons historiques; cela permet une correspondance exacte entre une mesure en pixels et une mesure en points d’imprimerie (il y a 72 points d’imprimerie par pouce). Il me semble que sous Windows, on considère que la résolution est de 96 ppp, ce qui est plus proche de la réalité actuelle.

En pratique cela signifie que pour représenter une page A4 verticale, le logiciel dessine un rectangle de 21 cm/2,54 x 72 ppp = 595 pixels par 29,7 cm/2,54 x 72 ppp = 841 pixels. Aussi, quand le zoom de la page est réglé à 100 %, le logiciel dessine à 72 ppp. Pour le faire dessiner à 100 ppp, il faut donc mettre le zoom à 100/72 = 139 %. Je peux alors superposer la feuille sur mon écran avec une correspondance parfaite.

Pourquoi ce problème n’est-il toujours pas résolu en 2010 ?

Apple propose des API pour connaître la définition (en pixels) de l’écran. On peut sans doute également demander au système d’exploitation les dimensions physiques de l’écran et calculer sa résolution comme ci-dessus, et enfin dessiner à l’échelle. Cependant, un problème va apparaître dès lors que vous brancherez un deuxième écran sur votre Mac qui présente une résolution différente du premier: une fenêtre à cheval sur les deux écrans n’aura son contenu à l’échelle que sur l’un des écrans. En y réfléchissant, la seule manière simple de résoudre le problème est que ce soit le Window Server qui fassent l’adaptation.

Les réflexions d’Apple sur le sujet

L’indépendance de la résolution était annoncée pour Mac OS 10.5 et ne fut finalement pas présente. Il existe pourtant déjà quelques API: Resolution Independence Guidelines.

Je vous fait un petit résumé:

  • Les ingés d’Apple ont l’air de s’embrouiller avec tout ça.
  • Il faudra dessiner à 72 ppp. Quartz effectuera ensuite les conversions pour avoir les coordonnées en pixels.
  • Il est pour l’instant possible de changer le facteur d’agrandissement à l’aide de l’application Quartz Debug, dans le menu Tools > Show User Interface Resolution. Essayez, c’est marrant. Ce petit essai devrait vous faire comprendre la complexité de la chose: c’est moche, on voit plein de gros pixels.

Il va donc falloir rendre l’interface utilisateur entièrement vectorielle. C’est un énorme travail, et il est donc compréhensible qu’Apple ne l’ait pas encore complètement implémenté.

Dialogue d’impression

Voilà un bogue marrant que j’ai trouvé en travaillant sur PortraiMatic 2.0:

PrintDialoguePortrait

Une image appelée Portrait.png se trouve dans les ressources de l’application: on constate qu’elle a remplacé l’image qui désigne l’orientation ”portrait” dans la boîte de dialogue ”Format d’impression”. Au moins, résoudre le problème est simple, il suffit de renommer le fichier.

Note pour plus tard: essayer d’utiliser une image Landscape.png.

La télé 3D et l’impression de relief

Dans le cadre de son excellent podcast consacré à la photographie, Benoît Marchal a interviewé Michel-Patrick Lauret, spécialiste de la stéréophotographie. Je ne vais pas revenir sur le principe, vous conseillant plutôt l’écoute de l’émission.Ce qui m’a particulièrement intéressé est le point de vue du photographe sur la télévision 3D.

Comme il l’explique fort justement, la distinction des reliefs étant donnée par l’écart des yeux, elle ne fonctionne bien que lorsque le sujet observé est proche. D’où l’utilisation de focales standard pour révéler la profondeur. Dans son exemple d’un mannequin marchant sur un podium, alors que les autres photographes utiliseront des télé-objectifs pour photographier le mannequin de loin, lui attendra qu’il arrive au bout du podium pour être le plus près possible et donner la meilleure sensation de relief.

Or, les conventions du cinéma sont plutôt d’utiliser des plans serrés, qui nécessitent l’utilisation de longue focales. Pareil pour filmer un match de foot: les caméramen se trouvent sur le bord du terrain et utilisent de longs télé-objectifs. L’impression de relief est donc minimale.

Tout le propos est que pour généraliser la stéréovision, il faudra aussi repenser la manière de filmer.

BeMyApp juin 2010

Voilà une semaine qu’avait commencé la première rencontre ByMyApp, et je n’ai pas encore pris le temps de vous raconter son déroulement et vous donner mes impressions. Commençons par rappeler les principes: les organisateurs avaient réuni des développeurs logiciel, des concepteurs web et des graphistes pour qu’une trentaine de personnes viennent leur exposer leurs idées d’applications pour iPhone ou iPad. À l’issue du week-end, un jury récompensait l’équipe gagnante par un prix de 5000 €.

John Karp et Cyril Attia nous donnaient rendez-vous au Dune, un bar situé aux alentours de l’hôpital Saint Louis. J’arrivai en ce vendredi soir, chargé de quinze kilos de bagages entre mes vêtements, mon MacBook et les quelques livres que j’avais emporté: l’un portant sur le développement iPhone, un autre sur la gestion de version avec Git, et le dernier pavé sur OpenGL (on ne sait jamais). Ayant marché depuis la gare du Nord, j’étais en sueur ! John emportait mes bagages dans le fond du Dune et m’invita à coller sur la poitrine une étiquette à mon nom, qu’il avait dotée d’une pastille verte indiquant mon rôle de développeur logiciel.

Je profitai de l’heure qui restait avant la présentation des projets pour lier connaissance avec les gens présents. D’emblée, l’ambiance me parut très sympathique. Si certains étaient réservés, tout le monde était de bonne humeur et impatient d’exposer ses idées ou de commencer à travailler. Lorsqu’arrivèrent les vingt heures, chaque porteur de projet disposa d’une minute pour exposer son idée. J’essayai de rester attentif, tâtant dans ma poche les trois jetons que je placerai sur mes projets favoris. Parmi la trentaine de projets présentés, la moitié était des projets qui auraient plus intérêt à naître sous la forme d’un site web que d’une appli iPhone; je vais y revenir. Parmi les projets restants, certains me parurent peu novateurs.

À la suite de ces présentations, les porteurs disposaient de trois-quart d’heure pour venir «draguer» ceux qui allaient réaliser les applications. J’étais là, posté comme une jolie fille, à attendre que chaque prétendant me fasse la cour en me soufflant à l’oreille ses arguments les plus persuasifs (voilà un renversement de situation bien agréable, d’autant plus lorsque ce furent de jolies demoiselles qui vinrent m’accoster). Voici une leçon à retenir pour les porteurs de projets des prochaines éditions: venez à deux. Certains n’ont pas eu le temps de venir me causer, alors que par moment, personne ne me faisait la conversation. Si vous êtes seuls, faites court lorsque vous comprenez que vous n’avez pas convaincu; il est inutile d’insister, il vaut mieux apporter vos arguments à quelqu’un d’autre.

Une minute pour présenter un projet peut sembler court, mais c’est suffisant. Très honnêtement, j’avais déjà choisi mes trois projets à l’issue des présentations, et les arguments apportés par la suite ne m’ont pas fait changer d’avis… Mais notez bien que j’aurais éventuellement pu pour le dernier projet de mon tiercé. Si je peux encore donner un conseil, c’est d’éviter d’être trop technique dans votre présentation. Essayez plutôt de raconter une histoire pour que votre auditoire puisse se projeter. Soyez concrets, même si vous n’êtes pas sûr que la solution technique à laquelle vous pensez est réalisable: ceci est du ressort des développeurs, qui s’attendent à ce que vos propos soient naïfs.

Après que les votes furent dépouillés, le verdict tomba: sept projets étaient retenus. Parmi mes poulains, un seul était retenu, aussi je me dépêchai de me rapprocher de Brigitte, la porteuse, pour travailler sur son projet, qui consiste en une application d’apprentissage des caractères Hiragana (l’un des trois alphabets du Japonais). Je finis par convaincre un autre développeur, Mathieu, de se joindre à nous. Nous nous étions déjà rencontré lors d’une réunion CocoaHeads, mais il fut hésitant, à raison: le projet exigeait la mise au point d’algorithmes complexes, un risque important étant donné le peu de temps pour la réalisation. Finalement, nous somme rejoints par un graphiste, Roger.

Je ne vous raconterai pas ici le déroulement du développement, qui n’est guère intéressant: Mathieu et moi travaillions dans notre coin sur l’algorithme et l’interface utilisateur et Brigitte s’occupai d’envoyer nos demandes à Roger et de rendre son concept un peu plus ludique, en travaillant ses listes de vocabulaire.

Dimanche, l’heure du verdict approchait, et l’algorithme n’était toujours pas au point. Je su pertinemment que nous n’arriverions pas à le faire fonctionner, aussi je décidai d’aller voir Brigitte et de nous préparer à la présentation du prototype final. Aussi parce que je regrettai de ne pas avoir travaillé davantage en groupe, et que je voulais donc profiter des derniers instants. À ce moment, beaucoup avaient déjà une idée des vainqueurs, parce que leur projet était déjà bien avancé la veille; le doute portait sur l’avancement des autres projets.

Et il n’y eu pas de surprise: le projet choisi fut iDact, une appli sur iPad qui affiche des plans sonorisés pour guider des mal-voyants dans les lieux publics tels que gares, aéroport, musées et dont le porteur de projet avait les plans. Ce verdict est juste: l’application était sans doute l’une des plus facile à réaliser, mais la réalisation était impeccable. Aucun concurrent n’a présenté un logiciel aussi proche d’un projet fini. Bravo aux gagnants !

Et merci aux organisateurs Cyril et John. J’essayerai d’être présent à la BeMyApp du 15 octobre.

Conception itérative d’une IHM

Lors de la session de CocoaHeads de jeudi soir, nous avons eu droit à une présentation de Jonathan Perret, qui en bon adepte de la méthodologie XP, crée ses applications de façon itérative. C’est à dire, qu’il fait en sorte qu’elle reste fonctionnelle tout le temps, mais ajoute les nouvelles fonctionnalités, et améliore l’existant au fur et à mesure.

L’un des auditeurs, lui alors demandé s’il faisait de même pour l’IHM (Interface Homme-Machine), ce à quoi Jonathan a répondu par l’affirmative, ce qui ne manqua pas d’étonner l’auditeur qui fit remarquer, à raison, que de nombreuses sociétés ne travaillent pas ainsi. Beaucoup conçoivent les IHM à l’avance sur papier, ou sous Photoshop, et en discutent en comité, avant de demander aux programmeurs d’implémenter le produit de leurs réflexions.

Preuve en est l’existence de nombreux outils pour créer des maquettes graphiques, ou les différents articles d’équipes expliquant comment elles ont conçu leur IHM sur papier avec des gabarits d’écran. Ces maquettes sont bien jolies, mais ce ne sont que des maquettes; non-seulement, les réaliser prend du temps, mais souvent la mise en œuvre réelle révèle que les concepts qui paraissaient si séduisants dans l’imaginaire fonctionnent mal en réalité.

Leur démarche me semble être le produit de dérives visant à occuper les graphistes et créer des plans et autres réunion; bref, des occupations habituelles des grosses boites. Pour ma part, j’utilise donc une approche itérative qui, à mon sens, se justifie par le fait qu’il est relativement peu coûteux (en termes de temps et de ressources) de se tromper. Quel que soit le programme que l’on conçoit, on commet des erreurs de conceptions: ces erreurs font partie intégrante du travail de design. Souvent, il est nécessaire de se tromper pour comprendre quelle est la bonne solution.

Interfaces gestuelles et découvrabilité

Un article intéressant sur Ignore the code. Les interfaces gestuelles posent, entre autres, des questions quant à la ”découvrabilité” des actions possibles. Par exemple, secouer l’iPad pour annuler la dernière commande n’est pas évident, il faut le savoir, car il est peu probable de le découvrir par accident.

Les adaptations d’iWork à l’iPad font également usage de nouveaux gestes pour contraindre les dimensions des objets: de fait, ceux-ci sont documentés dans le logiciel. Ces actions sont moins naturelles que faire défiler la page en glissant le doigt, ou agrandir une image en écartant deux doigts.

Comprenons que ces interfaces sont encore immatures, et que beaucoup de concepts sont encore à inventer ou parfaire. Ma réflexion personnelle est que sur nos Mac, nous sommes aussi habitués à certaines conventions: par exemple maintenir la touche ”Majuscule” appuyée pour contraindre les dimensions, ou la touche ”Contrôle” pour dupliquer la sélection. Ces actions-ci non plus ne sont pas évidentes: nous l’avons découvert au détour d’une page de manuel, ou parce que quelqu’un nous l’a expliqué.

Singleton

Le Singleton est sans doute la Design Pattern la plus connue, ne serait-ce parce qu’elle est simple à comprendre. L’idée est que certains objets n’existent qu’à un seul exemplaire dans une application. Considérez par exemple ces méthodes de classes Cocoa:

  • +[NSFileManager defaultManager]
  • +[NSFontPanel sharedFontPanel]
  • +[NSApplication sharedApplication]

Chacune renvoie un objet partagé — une instance unique pour toute l’application. Il faut appeler cette méthode de classe pour accéder à cet objet, et ne pas instancier un objet comme on le fait d’habitude, avec le couple [[alloc] init].

Le Singleton: Version simple

Créer un objet singleton en Objective-C n’est pas compliqué:

Pour le .h:

Pour le .m:

 

Le Singleton: Version Apple

Voici l’implémentation proposée par Apple :

La différence est que les méthodes en rapport avec la création, la copie et la destructions des instances sont supplantées pour vous empêcher de créer une instance supplémentaire , ou de détruire l’instance partagée. Il s’agit d’une approche plus paranoïaque que celle que je vous proposais plus haut. Je dirais qu’elle convient mieux si vous travaillez en équipe ou que vous rendez publique votre bibliothèque de classes. La première version possède l’avantage de la simplicité, et convient pour un petit projet, par exemple sur iPhone.

Critique de Rework

Rework

Nombreux sont les livres dédiés à la gestion des affaires qui paraissent chaque année. Il ya quelques semaines, paraissait Rework, un ouvrage un peu différent des autres, écrit par deux membres de 37signals, une société qui développe des applications web, et qui s’est fait connaître pour être à l’origine de Ruby on Rails. J’ai acheté ce livre peu après sa sortie, mais pas essentiellement pour son contenu… En effet, je lis régulièrement le blog de la société, et j’étais déjà très au fait de leurs idées par un livre, Getting Real, qu’ils ont mis gratuitement à disposition des lecteurs, il y a déjà quelques années.

Getting Real fut pour moi une révélation. Et dans un sens, j’ai acheté Rework pour rétribuer les précieux conseils que les auteurs m’ont dispensé jusqu’ici. Il m’est donc inévitable de comparer Getting Real et Rework. Sur le fond, les idées ne sont pas très différentes et toujours aussi subversives («ne pas planifier», «pas de réunion», «faire le minimum», etc.), bien qu’elles se soient nourries de quelques années supplémentaires de réflexion. Ainsi, on trouve des ajouts sur l’embauche ou la promotion.

Sur la forme, Rework a été réécrit entièrement pour ne plus être concentré sur la manière de faire tourner une affaire d’agence web, mais faire tourner une affaire tout-court. Ainsi, les nombreux exemples qui étayent le livre ne sont plus puisés dans le monde de l’informatique, mais dans le monde des affaires. Cette différence rend le livre plus généraliste mais constitue également sa faiblesse: les exemples paraissent moins concrets, en tout cas pour quelqu’un versé dans l’informatique.

En résumé, je dirais que si vous êtes un dirigeant ou un cadre et que vous n’êtes pas au fait des idées de 37signals, la lecture de ce livre vous apportera une nouvelle vision du (dys-)fonctionnement de l’entreprise. J’espère que vous y trouverez des idées dérangeantes. Par contre, si comme moi, vous êtes un fidèle du blog de la société, la lecture de Rework est dispensable.

La durée de vie des appareils électroniques

Voilà un sujet qui revient régulièrement dans les émissions de reportages, pour dénoncer “les pratiques honteuses de ces multi-nationales qui nous poussent à acheter toujours du neuf”. La plupart du temps, et comme la majorité des gens, je ne connais rien aux sujets abordés par ces émissions; mais quand arrive un tel sujet, que j’ai étudié à l’école et vu dans ma vie professionnelle, cela rend flagrant à quel point ces journalistes ne cherchent que le sensationnalisme.

Scoop: les industriels limitent la durée de vie des appareils

Ma séquence préférée est celle du journaliste qui obtient la confidence d’un ingénieur flouté que “la durée de vie d’un appareil est prédéterminée lors de sa conception”. La voix off, chargée de trémolo sans perdre ses accents de Vincent Marronnier, nous laisse imaginer que le reporter a bataillé dur pour obtenir l’information, à coup de chantage, de corruption et de poules de luxe.

Pourtant, en ouvrant n’importe quel livre sur la fiabilité des composants, on peut voir ce diagramme, dit «en baignoire»:

Diagramme_en_baignoire

Ce diagramme est un modèle qui s’applique aux composants électroniques ou mécaniques, et par voie de conséquence, à tout système entier. Comme c’est un modèle statistique, il faut bien évidemment disposer d’un échantillon assez grand pour qu’il soit représentatif.

La phase (1) correspond à la jeunesse.
Quand on monte 10 000 téléviseurs, on sait qu’un certain nombre, disons cinq, va tomber en panne dans les premières heures de fonctionnement. Le constructeur veut éviter que l’appareil tombe en panne chez le client car rapatrier l’appareil lui coûte cher, et cela donne une mauvaise image de sa compagnie. On laisse donc souvent les appareils vieillir à l’usine (il existe des moyens d’accélérer le vieillissement).

La phase (2) est la durée de vie nominale de l’appareil.
Dans cette phase, les pannes existent, mais leur probabilité reste contenue. C’est la durée de cette phase qui est prédéterminée à la conception.

La phase (3) correspond à la fin de vie de l’appareil.
Il devient de plus en plus probable que surgisse une panne. Cependant, notez bien que certains appareils produits dépasseront de longtemps la durée de vie nominale.

Décider de la durée de vie nominale

Il est certes dérangeant de découvrir que la durée de vie d’un appareil est choisie dès sa conception, mais extrapoler en prétendant que les constructeurs limitent volontairement l’espérance de vie de leurs appareils est malhonnête ! La volonté des ingénieurs est plutôt de garantir que l’appareil atteindra un âge minimum, en balance avec des problématiques de coût. La durée de vie nominale est effectivement décidée par les services marketing, qui prennent en compte:

  • Le prix que le client est prêt à payer.
    Ce prix est déterminé par rapport à la concurrence et au positionnement de la marque.
  • La durée de vie exigée par le client.
    Par exemple, qu’une télé tombe en panne au bout de cinq ans ou qu’un lave-linge au bout de sept, paraît raisonnable à beaucoup de clients.
  • La vitesse des évolutions technologiques
.
    Un téléphone portable qui a trois ans est dépassé ! Beaucoup de clients l’auront déjà renouvelé de toute façon: ils n’auront pas attendu la panne.

Ce ne sont pas les constructeurs, mais les clients qui déterminent l’âge que doit atteindre un appareil électronique. N’en déplaise aux journalistes d’Envoyé spécial ou Capital. Si un constructeur vous garantissait une durée de vie deux fois plus longue, seriez-vous prêt à payer deux fois plus cher ? Cinquante pour cent plus cher ? Trente pour cent plus cher ? Les constructeurs se sont seulement adaptés à notre mode de consommation.