Month: June 2010

Categories
Non classé

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.

Categories
Non classé

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.

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.