Categories
Non classé

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é.

Categories
Non classé

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:

@interface MonSingleton: NSObject { } 

+ (MonSingleton *) sharedSingleton; 

@end

Pour le .m:

@implementation
static MonSingleton *sharedSingletonInstance = nil; 

- (id) init 
{ 
 if(self = [super init]) 
 {
 // Initialisations classiques 
 } 
 return self; 
} 

+ (MonSingleton *) sharedSingleton
{ 
 if(sharedSingletonInstance == nil) // Pas encore instancié
 sharedSingletonInstance = [[MonSingleton alloc] init]; 

 return sharedSingleton; 
} 

@end

 

Le Singleton: Version Apple

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

static MyGizmoClass *sharedGizmoManager = nil;

+ (MyGizmoClass*)sharedManager
{ 
 if (sharedGizmoManager == nil)
 {
 sharedGizmoManager = [[super allocWithZone:NULL] init]; 
 }
 return sharedGizmoManager;
} 

+ (id)allocWithZone:(NSZone *)zone
{
 return [[self sharedManager] retain];
}

- (id)copyWithZone:(NSZone *)zone
{
 return self;
}

- (id)retain {
 return self;
}

- (NSUInteger)retainCount
{
 return NSUIntegerMax; //denotes an object that cannot be released
}

- (void)release
{
 //do nothing
}

- (id)autorelease
{
 return self;
}

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.

Categories
Non classé

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.

Categories
Non classé

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.