Paresseux, impatients et trop fiers : créer des expériences exceptionnelles pour des développeurs exceptionnels

De « Comment faire ça ? » à « Bonjour tout le monde » en un clin d'œil.

Il y a quelques semaines, nous avons évoqué l'importance (et les difficultés) liées à la conception de kits de développement logiciel (SDK) avec lesquels nos utilisateurs finaux peuvent interagir en toute fluidité.

Mais un sujet qui est rarement abordé dans ce domaine est celui de l'expérience développeur (DX). On semble oublier que les développeurs apprécient tout autant les expériences simples et captivantes que n'importe quel autre utilisateur devant son écran. 

La différence, c'est que si un développeur se retrouve bloqué ou perdu en essayant d'intégrer un SDK dans son application, même le composant le plus fonctionnel et le plus agréable à utiliser ne verra jamais le jour.

Chez Microblink, nous mettons tout en œuvre pour éviter que cela ne se produise. 

Nous savons que les développeurs qui s'intéressent à nos solutions de numérisation souhaitent pouvoir se lancer rapidement avec l'un de nos SDK sans avoir à réinventer la roue et qu'une fois celui-ci intégré, ils s'attendent à ce qu'il fonctionne sans faille au sein de leur propre application. 

Alors, comment s'y prendre pour créer une telle expérience ?

En assumant leur paresse 

Larry Wall, le créateur de Perl, a été le premier à définir, sur le ton de l’ironie, les trois vertus qui distinguent les bons développeurs : la paresse, l’impatience et l’orgueil. Il a décrit la paresse comme « une qualité qui vous pousse à tout mettre en œuvre pour réduire votre dépense énergétique globale ». (1)

Nous sommes d'accord avec cela. Les développeurs ont beaucoup de travail à accomplir et s'il existe une solution simple qui leur permet de le faire plus rapidement, ils la trouveront. 

C'est pourquoi nous ne les obligeons pas à passer des heures sur une tâche qui ne prend que quelques minutes. Certes, la technologie qui sous-tend nos SDK peut s'avérer assez complexe, mais l'intégration ne nécessite généralement que quelques lignes de code. 

Par ailleurs, nous restons à l'écoute pour identifier la prochaine fonctionnalité indispensable à nos développeurs. Lorsque nous publions une nouvelle version de notre SDK, cette fonctionnalité y figure généralement déjà.

Une autre chose que nous évitons de faire lorsque nous développons nos SDK, c'est de submerger les développeurs de fonctionnalités, de méthodes ou de noms de variables qui ne leur sont pas familiers. 

Cela devrait leur sembler être un prolongement naturel de leurs applications ; c'est pourquoi nous nous en tenons aux conventions de nommage et à la syntaxe auxquelles ils sont habitués. 

Par exemple, sous Android, c’est la méthode `onActivityResult` qui renvoie les résultats de la numérisation, tandis que sous iOS, cette même méthode est appelée via un contrôleur de vue et un délégué. Pour les développeurs travaillant sur une base de code unique, nous avons intégré une grande partie de nos SDK dans des plugins destinés aux frameworks multiplateformes les plus courants du marché. 

Tout ce que nous faisons, nous le faisons dans le but d’alléger autant que possible la charge de travail des développeurs. Lorsqu’ils ont moins de code à gérer et moins de soucis à se faire, nos SDK ont plus de chances de trouver leur « fin heureuse » dans une application réelle.

En leur faisant gagner du temps

De la même manière que la patience peut être une faiblesse, l'impatience peut être une vertu. Si les développeurs n'étaient pas impatients par nature, vous verriez beaucoup plus souvent la « balle de plage tournoyante de la mort » d'Apple.

Les développeurs qui découvrent nos produits sont séduits par l'idée que leur application puisse numériser des pièces d'identité, des cartes bancaires, des cartes d'embarquement et bien d'autres documents en une fraction de seconde. Souvent, ils ont hâte de mettre rapidement en place une solution fonctionnelle, sans avoir à souscrire immédiatement à une licence pour le SDK.

Nous en sommes conscients. Pour apaiser leur impatience, nous leur permettons de cloner et d'exécuter des exemples d'applications adaptés à leur cas d'utilisation, afin qu'ils n'aient pas à fouiller trop profondément dans notre documentation. 

Et si même cela leur semble trop compliqué, ils peuvent simplement télécharger l'application Microblink Vision pour iOS ou Android afin de découvrir nos SDK en action.

En leur laissant le dernier mot 

Comme dans tout autre métier, le développement d’applications s’accompagne d’une certaine dose d’orgueil — ou de fierté excessive. Et ce n’est pas grave. Pour un développeur, le sentiment que l’on éprouve en lançant une application n’est sans doute pas très différent de celui qu’éprouve un sculpteur lorsqu’il inaugure une exposition. 

C'est pourquoi nous laissons aux développeurs le dernier mot sur le fonctionnement ou l'apparence de nos SDK au sein de leur application. Si la paresse cède le pas à l'orgueil et qu'ils estiment pouvoir mettre en œuvre la fonction de numérisation mieux que nous, personne ne les en empêchera. 

Un développeur peut utiliser notre flux de numérisation intégré tel quel, le personnaliser ou créer une nouvelle interface utilisateur à partir de zéro, et même prendre en charge la gestion de l'appareil photo au sein de l'application.

Nous leur permettons de mettre la main à la pâte et de se lancer dans la personnalisation totale, sachant que nous serions condamnés à travailler éternellement avec des langages et des frameworks obsolètes s’il n’y avait pas ces développeurs trop sûrs d’eux qui disent : « Bah, je pourrais faire en sorte que ça fonctionne mieux ou que ça ait un meilleur rendu. »

N'oubliez pas : les développeurs sont aussi des utilisateurs

Même si la paresse, l'impatience et l'orgueil ne sont sans doute pas des qualités très utiles quand on a une pile de vaisselle qui trempe dans l'évier, elles peuvent constituer un puissant moteur d'efficacité et d'innovation lors du développement d'applications. 

Car, au fond, ce n’est rien d’autre qu’un désir déguisé d’efficacité. Les développeurs veulent simplement faire leur travail plus vite et mieux. Et cela implique moins de code inutile, moins de terminologie obscure et plus de temps consacré à la création plutôt qu’à la prise en main.

Lors du développement de nos SDK, nous devons garder ces éléments à l’esprit et nous efforcer d’offrir une expérience développeur si intuitive qu’elle passe presque inaperçue. Le genre d’expérience que nous nous empressons d’offrir à nos utilisateurs finaux, mais que nous oublions souvent de reproduire pour nos développeurs.

Nos solutions de numérisation intelligentes sont conçues pour faciliter la vie des développeurs. Testez-les gratuitement au sein de votre application.