Paresseux, impatient et trop fier : Construire de grandes expériences pour de grands développeurs

De “comment faire” à “bonjour le monde” en un clin d’œil.

Il y a quelques semaines, nous avons écrit sur l’importance (et les difficultés) de la conception de kits de développement logiciel (SDK). concevoir des kits de développement logiciel (SDK) avec lesquels les utilisateurs finaux peuvent interagir de manière transparente.

Mais un sujet qui est rarement abordé dans cet espace est celui de l’expérience du développeur (DX). Les gens semblent oublier que les développeurs apprécient les expériences simples et attrayantes autant que la dernière personne devant l’écran.

La différence est que si un développeur est bloqué ou confus 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 faisons tout ce qui est en notre pouvoir pour éviter que cela ne se produise.

Nous savons que les développeurs qui parcourent nos solutions de numérisation veulent pouvoir utiliser l’un de nos SDK sans avoir à réinventer la roue et qu’une fois intégré, ils s’attendent à ce qu’il fonctionne parfaitement dans leur propre application.

Comment créer une telle expérience ?

En acceptant leur paresse

Larry Wall, le créateur de Perl, a été le premier à inventer trois vertus qui distinguent les bons développeurs : la paresse, l’impatience et l’orgueil démesuré. Il a décrit la paresse comme “une qualité qui vous pousse à faire de gros efforts pour réduire la 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 peu contraignante qui les aide à le faire plus rapidement, ils la proposeront.

C’est pourquoi nous ne les obligeons pas à passer des heures à faire un travail qui ne peut prendre que quelques minutes. Certes, la technologie qui sous-tend nos SDK peut s’avérer assez complexe, mais l’intégration implique rarement plus de quelques lignes de code.

Par ailleurs, nous restons à l’affût de la prochaine fonctionnalité dont nos développeurs auront besoin. Lorsque nous publions une nouvelle version de notre SDK, cette fonctionnalité est généralement déjà présente.

Une autre chose que nous évitons de faire lorsque nous écrivons nos SDK est de bombarder les développeurs avec des fonctionnalités, des méthodes ou des noms de variables qu’ils ne connaissent pas.

Il doit s’agir d’une extension naturelle de leurs applications, c’est pourquoi nous nous en tenons aux conventions de dénomination et à la syntaxe auxquelles ils sont habitués.

Par exemple, sur Android, c’est onActivityResult qui renvoie les résultats scannés alors que sur iOS, la même méthode est appelée via un contrôleur de vue et un délégué. Pour les développeurs qui travaillent avec une base de code unique, nous avons intégré une bonne partie de nos SDK dans des plugins pour les frameworks multiplateformes les plus populaires. pour les frameworks multiplateformes les plus populaires..

Tout ce que nous faisons, nous le faisons dans le but d’alléger au maximum le 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 bonheur dans une application réelle.

En leur faisant gagner du temps

De même 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 le ballon de plage d’Apple en train de tourner.

Les développeurs qui explorent nos produits sont intrigués par l’idée que leur application puisse scanner des documents d’identité, des cartes de crédit, des cartes d’embarquement et tout autre objet en une fraction de seconde. Souvent, ils ont envie de faire fonctionner quelque chose rapidement, sans avoir à acquérir immédiatement une licence pour le SDK.

Nous comprenons cela. Pour atténuer leur impatience, nous les laissons cloner et exécuter des exemples d’applications correspondant à leur cas d’utilisation, afin qu’ils n’aient pas à se plonger trop profondément dans notre documentation.

Et si c’est trop de travail, ils peuvent simplement télécharger l’application Microblink Vision pour iOS ou Android pour voir nos SDK en action.

En leur laissant le dernier mot

Comme c’est le cas pour tout autre métier, le développement d’applications s’accompagne d’une dose d’orgueil – ou de fierté excessive -. Et ce n’est pas grave. Pour un développeur, le sentiment que procure la livraison d’une application n’est pas très différent de celui qu’éprouve un sculpteur à l’occasion d’une exposition.

C’est pourquoi nous laissons aux développeurs le dernier mot sur la manière dont nos SDK fonctionneront ou se présenteront dans leur application. Si la paresse l’emporte sur l’orgueil et qu’ils pensent pouvoir mettre en œuvre la numérisation mieux que nous, personne ne les en empêchera.

Un développeur peut utiliser notre flux de numérisation intégré dès le départ, personnaliser ou créer une nouvelle interface utilisateur à partir de zéro et même prendre le contrôle de la gestion de l’appareil photo dans l’application.

Nous leur permettons de se salir les mains et de faire du sur-mesure, sachant que nous serions coincés à jamais avec des langages et des frameworks dépassés s’il n’y avait pas eu des développeurs trop confiants pour dire : “Je pourrais faire en sorte que ça marche ou que ça ait l’air mieux”.

N’oubliez pas que les développeurs sont aussi des utilisateurs

Si la paresse, l’impatience et l’orgueil ne sont pas forcément utiles lorsque vous avez une pile de vaisselle qui trempe dans l’évier, ils peuvent être un puissant moteur d’efficacité et d’innovation lors du développement d’applications.

Car, au fond, il s’agit d’un désir déguisé d’efficacité. Les développeurs veulent simplement faire leur travail plus vite et mieux. Cela signifie moins de code inutile, moins de terminologie inconnue et plus de temps consacré à la création plutôt qu’à l’intégration.

Lors de l’élaboration de nos SDK, nous devons tenir compte de ces éléments et nous efforcer d’offrir aux développeurs une expérience si intuitive qu’elle passe à peine inaperçue. C’est le genre d’expérience que nous nous empressons d’offrir à nos utilisateurs finaux, mais que nous oublions souvent de recréer pour nos développeurs.

Nos solutions de numérisation intelligentes sont conçues pour répondre aux besoins des développeurs. Essayez-les gratuitement dans votre application.