Fermer

avril 27, 2020

Construire en interne ou acheter une bibliothèque de composants d'interface utilisateur: 8 facteurs clés


Que votre objectif soit de respecter la date limite d'un projet Web ou de normaliser votre développement sur une seule bibliothèque d'interface utilisateur, vous devrez probablement prendre la décision de créer votre interface utilisateur en interne ou d'acheter une bibliothèque prête à l'emploi de composants d'interface utilisateur. Beaucoup de choses peuvent dépendre de cette décision, alors assurez-vous de considérer ces huit facteurs clés.

Quand devriez-vous investir dans l'achat d'une bibliothèque d'interface utilisateur tierce? Il n'y a pas de réponse universelle à cette question, mais il y a certainement des situations dans lesquelles vous obtiendriez une énorme valeur en retour, probablement un multiple du coût de la licence. Cet article passera en revue certaines des principales considérations à garder à l'esprit lors de l'évaluation des alternatives pour la création d'interfaces utilisateur – la construction en interne, le choix d'une solution open source ou le choix d'une bibliothèque d'interface utilisateur commerciale.

Nous considérerons huit facteurs, mais d'abord, je vais vous donner un peu de contexte afin que vous ayez un peu de contexte.

Bien que cet article utilise KendoReact une bibliothèque d'interface utilisateur React commerciale, pour illustrer certains points, les critères discutés ici peuvent être appliqués pour évaluer n'importe quelle bibliothèque d'interface utilisateur JavaScript.

Petite note avant de plonger – aux fins du présent article, ce que nous appelons «bibliothèque d'interface utilisateur» ou «bibliothèque tierce» est une boîte à outils de composants d'interface utilisateur prédéfinis, personnalisables et extensibles que les développeurs peuvent implémenter dans leurs applications. Les bibliothèques d'interface utilisateur peuvent également inclure des outils supplémentaires tels que des générateurs de thèmes, des directives de conception et des exemples d'applications.

Comment en sommes-nous arrivés là?

Commençons par expliquer pourquoi: quelle est la raison pour laquelle vous recherchez des solutions d'interface utilisateur? En règle générale, les développeurs atteignent ce stade lorsqu'ils sont pressés par le temps pour terminer une application ou, dans un scénario moins stressant, sont conscients qu'ils peuvent gagner du temps en ne construisant pas tout à partir de zéro et explorent des options pour augmenter leur productivité

Un scénario populaire est la nécessité de standardiser une bibliothèque d'interface utilisateur par exemple lorsqu'une équipe commence à travailler sur une application complexe et sait qu'elle aura besoin de plusieurs composants d'interface utilisateur. L'adoption d'une bibliothèque complète dans cette situation réduit le temps de prise de décision d'avoir à découvrir, apprendre à utiliser et personnaliser plusieurs solutions différentes.

D'autres fois, vous pouvez rechercher une solution pour un problème difficile : ajout d'une grille de données, application d'un style à plusieurs composants ou respect de l'accessibilité.

Lorsqu'il s'agit de répondre à l'un de ces besoins, que vous ayez un délai à respecter ou que votre principale préoccupation soit de rationaliser le développement de votre interface utilisateur, vos options sont les suivantes:

  • Créez votre interface utilisateur en interne
  • Trouvez un logiciel open source ( Solution OSS)
  • Acheter une bibliothèque commerciale

Souvent, vous adopteriez une approche mixte car chacune de ces options a ses avantages et ses inconvénients. Pour prendre une décision éclairée, alors, assurez-vous de considérer ce que chacune des options individuelles implique et comment cela affecterait votre équipe et vous à court et à long terme.

En tant que directeur marketing de KendoReact, j'ai dépensé d'innombrables heures pour répondre à cette question précise – quand un développeur ou une entreprise a-t-il besoin d'une bibliothèque d'interface utilisateur professionnelle? Quand y a-t-il une meilleure alternative pour eux? Vous pourriez vous attendre à ce que je dise que tout le monde a besoin d'une bibliothèque d'interface utilisateur professionnelle, mais ce serait naïf – et ce n'est tout simplement pas vrai. Accompagnez-moi dans un voyage explorant ces questions sur la base des recherches que mon équipe et moi avons faites!

J'ai résumé les principaux critères qui influencent la question à laquelle chaque développeur est confronté à un moment donné, même dans le monde JavaScript. Cette question, en termes plus simples, est la suivante: Dois-je construire quelque chose moi-même ou dois-je acheter une solution standard?

Votre application dans son contexte

Il peut être utile de regarder la situation dans son ensemble début. Votre projet JavaScript est construit au sein de votre organisation, qui peut être petite ou grande, au sein de votre équipe, qui se compose probablement d'ingénieurs à différents niveaux d'expérience, et pour un certain client, interne ou externe. Il peut y avoir d'autres éléments importants à considérer concernant le contexte de votre application, par exemple, si l'industrie que vous desservez est hautement réglementée. Tous ces facteurs ont une incidence sur la solution que vous choisirez.

 Votre application React dans le contexte de votre entreprise

Voici quelques contextes qui peuvent jouer un rôle important dans la détermination de la solution d'interface utilisateur que vous choisir:

Taille de l'entreprise

Dans les grandes entreprises, il existe souvent d'autres équipes qui créent l'interface utilisateur pour d'autres applications. Ces équipes utilisent-elles déjà une bibliothèque d'interface utilisateur? En recherchent-ils un sur lequel normaliser? L'adoption du même outil au sein des équipes présente de multiples avantages, du partage des connaissances à une interface utilisateur et une expérience utilisateur (UX) cohérentes «automatiquement» au sein de votre organisation. Il peut être difficile d'obtenir un aspect et une convivialité différents en utilisant différents outils.

Expérience en équipe

Les différentes personnes de votre équipe ont-elles la même expérience? Ont-ils de l'expérience dans la construction de leurs propres composants d'interface utilisateur? Combien de temps leur faudrait-il pour créer un sélecteur de date, un graphique ou un formulaire? Si l'équipe commence tout juste à utiliser un cadre ou un langage, il peut être utile de normaliser les outils de productivité courants pour agir comme des «égaliseurs» et réduire la quantité de code non documenté que les membres de votre équipe plus expérimentés devront examiner. D'autres facteurs peuvent également jouer – par exemple, quels outils avez-vous utilisés auparavant? Si vous pouvez trouver une solution qui répond à vos besoins et est familier à la plupart de votre équipe, vous raccourcirez le temps de mise en œuvre.

De plus, avec tout travail spécialisé, il existe un talent pour la construction de composants d'interface utilisateur réutilisables – eh bien, il y a un talent pour construire des composants d'interface utilisateur utilisables en premier lieu. L'expérience précédente dans la création de composants d'interface utilisateur crée une base de connaissances et une expertise qui aident à éviter les barrages routiers et à résoudre rapidement les problèmes courants. Rien n'empêche votre équipe d'acquérir ce savoir-faire, mais demandez-vous si vous bénéficierez d'investir du temps et des efforts ou si vous réinventerez la roue.

Qui est le client

Votre client est-il une équipe interne qui a peu ou pas d'exigences d'interface utilisateur et recherche simplement des fonctionnalités brutes et simples? Ou les spécifications techniques de votre application ont-elles la taille d'un roman? Le premier scénario nécessite une solution beaucoup plus simple, où dans le second, vous pouvez également anticiper plusieurs demandes de modification qui impliqueront une solution modulaire par conception. De plus, l'accessibilité est-elle indispensable pour votre utilisateur final? Cela nécessiterait de se familiariser avec les directives d'accessibilité respectives et de décider comment les appliquer dans la pratique – ce n'est pas un processus simple dans la plupart des cas.

Durée de vie du projet

Votre projet a-t-il une date de début et de fin claire ou s'agit-il d'un initiative à long terme? Devrez-vous le maintenir ou une fois que vous avez terminé, vous avez terminé? S'il s'agit d'un projet ponctuel, il peut être utile d'implémenter des composants d'interface utilisateur prêts à l'emploi au lieu de prendre le temps de coder quelque chose qui a déjà été construit par quelqu'un d'autre – et quelque chose que vous n'aurez plus jamais besoin d'utiliser à nouveau.

en même temps pour des projets à long terme, ou si vous commencez régulièrement de nouvelles applications React, et que vous n'avez pas une visibilité complète sur tous les composants et fonctionnalités de l'interface utilisateur que vous devrez implémenter à l'avenir, vous pourriez être bien servi par une solution complète qui peut être appliqué à plusieurs scénarios.

Le maintien de plusieurs dépendances et de code non documenté est une phrase qui, en soi, fait frémir la colonne vertébrale de la plupart des développeurs. Cela s'applique à n'importe quelle partie de votre projet, y compris la création de l'interface utilisateur. Outre le simple désagrément de la tâche, la maintenance du code peut occuper des pans de temps imprévus. De plus, nous avons tous rencontré des projets qui ne peuvent pas être mis à jour vers la dernière version du framework en raison d'une dépendance obsolète mais cruciale.

Les risques associés à la maintenance à long terme peuvent être plus petits si vous augmentez la taille – c'est-à-dire , si vous optez pour une entreprise établie qui a une feuille de route pour un avenir prévisible et publie régulièrement des mises à jour.

Mais attendez, il y a plus

Prenez le temps de réfléchir aux autres facteurs entourant votre application qui peuvent vous concerner. Peut-être que les préférences de votre gestionnaire, les perspectives économiques ou une future fusion ou acquisition joueront un rôle important dans votre choix de solution. Quoi qu'il en soit, il vaut la peine d'envisager avant de s'engager sur une voie à suivre plutôt que d'être surpris après.

8 facteurs à prendre en compte lors de la décision

En tenant compte du contexte de votre application, vous avez compilé une liste de solutions possibles pour votre application. UI / UX. Si la décision était simple ou directe, vous ne liriez pas ce blog, il est donc probable que dans votre liste restreinte, il existe un mélange d'alternatives – certaines commerciales, d'autres open-source ou basées sur des logiciels open-source (OSS). Tous répondent à vos exigences, dès aujourd'hui.

 Liste restreinte de bibliothèques et de solutions d'interface utilisateur

Une note avant de continuer: je suppose que vous connaissez très bien les avantages de la création de votre solution en interne, donc je vais me concentrer moins

1. Documentation et ressources d'apprentissage

Commençons simplement. Même un bouton peut être difficile à mettre en œuvre si vous n'avez pas de documentation technique. La documentation vous aidera non seulement à mettre en œuvre votre solution, mais si elle est bien rédigée et régulièrement mise à jour, elle contribuera à raccourcir le temps de développement et de maintenance. Pour des solutions plus complexes, avoir des ressources d'apprentissage supplémentaires telles que des articles, des vidéos ou même un forum Q&R actif (que ce soit Stack Overflow ou un forum spécifique au produit) peut être d'une aide et d'une utilité immenses. C'est pourquoi lors du calcul du coût interne / heure de développement de votre application, il peut être judicieux d'inclure des heures de développement supplémentaires dans votre estimation pour documenter le code – sauf si vous êtes certain que le ou les développeurs qui écrivent ce code resteront dans votre

D'un autre côté, avec les bibliothèques tierces, qu'elles soient payantes ou OSS, vous pouvez vous attendre à un certain niveau de documentation et de ressources d'apprentissage dans le cadre du package. Cependant, les solutions payantes sont plus en jeu si les développeurs ne peuvent pas rapidement apprendre à les utiliser, de sorte que l'engagement de documentation des entreprises offrant des solutions commerciales est généralement assez élevé.

2. Support

Parfois, les documents et les blogs ne suffisent pas et vous devez aller directement à la source avec votre question. Quelles options avez-vous pour obtenir une assistance technique concernant les solutions de votre choix? Si c'est votre équipe interne qui construit la majeure partie de la solution, vous êtes principalement seul avec le dépannage et le débogage. Le plus ici est que vous avez une équipe dédiée à faire avancer votre projet et à répondre à toutes les questions.

Avec une solution payante, la situation est similaire, sauf que vous «embauchez» une équipe externe pour gérer les tickets de support afin que votre sa propre équipe peut se concentrer sur le respect de ce délai. Les solutions payantes sont assez rentables de cette manière – par exemple, les licences KendoReact incluent un support technique, et les personnes qui répondent à vos tickets sont les développeurs de l'équipe d'ingénierie KendoReact elles-mêmes, de sorte que vous êtes sûr d'obtenir une réponse rapide, garantie et très qualifiée . Nous avons tous notre part d'histoires terriblement comiques de contact avec le service client, et il est vrai que différentes entreprises le gèrent avec un degré de réussite différent. Je ne peux parler que pour mon équipe, et notre tableau de bord montre que le taux de satisfaction avec le support technique de KendoReact est constamment à 93% ou plus. Si le support est important pour vous, assurez-vous de le tester avant de faire votre choix.

La situation du support technique lors de l'utilisation de solutions open source est hétérogène. Si la bibliothèque que vous consultez a une grande communauté qui l'utilise, vous bénéficiez de nombreux autres développeurs qui contribuent et collaborent. Cela peut conduire à répondre très rapidement à vos questions – ou pas du tout, si personne d'autre n'est intéressé par la solution que vous recherchez. Cela vaut toujours la peine de regarder les principaux contributeurs de la bibliothèque que vous évaluez. C'est une façon de savoir si cela est vraiment pris en charge par un grand effort communautaire ou si cela dépend du travail d'une poignée de développeurs.

3. Dépendances

Il est important de considérer les dépendances que vous ajoutez à votre projet avec la solution que vous choisissez. Si vous optez pour la méthode OSS, en fonction du nombre de composants et de fonctionnalités que vous devez implémenter, ce nombre peut devenir assez élevé. Cela augmente la complexité de votre solution et vous devrez peut-être gérer des conflits entre bibliothèques ou gérer des situations telles que des bibliothèques qui cessent d'être gérées. Un moment délicat ici est que vous ne savez peut-être même pas qu'une bibliothèque est une dépendance pour vous, car il peut s'agir d'une dépendance de deuxième ou troisième niveau de l'un des outils de votre pile.

Le compromis avec un payant La bibliothèque d'interface utilisateur consiste à ajouter une seule dépendance (ou en tout cas moins), de sorte que le niveau de complexité dans lequel vous achetez est beaucoup plus petit. Cependant, vous avez un seul point de défaillance. Cela semble plus effrayant qu'il ne l'est souvent, étant donné que de nombreuses solutions payantes sont fournies par de grandes entreprises ayant une longue expérience en affaires, et avec succès. Par exemple, KendoReact fait partie du portefeuille Progress d'outils de développement, dont certains ont été lancés il y a près de 20 ans.

4. Mises à jour

Sur une note connexe, si votre application sera utilisée pendant plus d'une saison, réfléchissez à ce que vous devrez faire lorsque la prochaine version du framework ou du navigateur arrivera – et si ce n'est pas la suivante, celle qui suit . Que devrez-vous faire pour rendre votre code compatible dans chacune des options présélectionnées que vous évaluez? L'externalisation de la prise en charge des nouvelles versions à une «équipe externe» – que ce soit en utilisant une solution open source ou payante bien entretenue – peut vous permettre d'utiliser les dernières technologies dès leur sortie, sans avoir à réaffecter constamment des personnes à cette tâche

5. Réutilisation

Si ce ne sera pas la dernière application React que vous construisez, quelle quantité de code pourrez-vous réutiliser dans de futurs projets? Construire en interne avec la réutilisation à l'esprit augmente les enjeux sur la qualité de la documentation de votre bibliothèque. La plupart des bibliothèques UI open source et payantes obtiennent des scores élevés sur ce critère car elles sont conçues pour servir le plus grand nombre.

6. Caractéristiques spéciales: A11y, I18n, L10n

Votre application peut avoir besoin d'une ou plusieurs de ces fonctionnalités maintenant, ou elle peut être ajoutée en tant qu'exigence plus tard: accessibilité, internationalisation, localisation. Bien qu'ils soient différents, ce qui est courant, c'est qu'ils devraient être pris en charge par tous les composants applicables de votre application. Ces fonctionnalités seraient-elles prêtes à l'emploi (ou dès le début, en cas de construction en interne) ou une telle exigence signifierait-elle devoir aller sur une autre chasse aux solutions?

Je voudrais accorder une attention particulière à l'accessibilité . L'importance de rendre le Web accessible à tous ne peut être surestimée, et les gouvernements prennent de plus en plus de mesures pour y parvenir. Pour aider les développeurs à comprendre les principes fondamentaux de l'accessibilité, nous avons écrit plusieurs blogs sur le sujet. Je vous recommande de commencer avec le Guide d'accessibilité pour le développement Web .

7. Coût, licence et retour sur investissement (ROI)

Le résultat net. Le ROI. L'étiquette de prix. Que l'argent vienne de votre poche ou de votre budget ou non, vous êtes probablement au moins curieux, sinon très intéressé, ce que chaque solution vous coûtera.

Lorsque vous construisez en interne

Peut-être le plus difficile à mesure est le coût de la décision de se développer en interne. Cela commence tout simplement avec votre coût développeur / heure multiplié par l'estimation du temps du projet. Nous avons mentionné plus haut dans cet article quelques tâches supplémentaires que vous devrez peut-être inclure dans votre estimation. Cela comprend, mais sans s'y limiter, la rédaction de documentation, la prise en charge de nouveaux cadres et navigateurs, la correction de bogues et la maintenance.

Un scénario intéressant que nous avons vu se produire plus d'une fois est lorsque d'autres équipes de votre organisation aiment ce que vous avez terminé et souhaitez adopter votre bibliothèque d'interface utilisateur construite en interne. Cela vient avec ses propres avantages et inconvénients. Du côté positif, l'utilité de votre travail augmente et les coûts sont répartis sur plusieurs projets, ce qui augmente efficacement votre retour sur investissement. De plus, c'est une grande sensation de voir votre travail utile, je peux en témoigner. Le revers est que votre équipe et vous pouvez devenir par inadvertance (ou non) l'équipe d'interface utilisateur interne, devant répondre aux demandes de tout le monde.

Lorsque vous choisissez OSS

L'open source est souvent gratuit et vous pouvez trouver d'excellents outils Là. Réunir les compétences et l'enthousiasme de toute une communauté peut conduire à la création de logiciels puissants et riches qui résolvent les problèmes de manière créative. Cela vaut vraiment la peine de chercher des logiciels libres qui correspondent à vos besoins – ou d'inspirer votre propre résolution de problèmes. Gratuit – sans étiquette de prix – ne signifie toutefois pas qu'il n'y a pas de coût associé à l'utilisation d'une option gratuite. Vous pouvez le rechercher dans le temps croissant consacré à la maintenance, au débogage et à la création de fonctionnalités manquantes.

Lors du choix d'une bibliothèque de composants d'interface utilisateur commerciale

Les bibliothèques d'interface utilisateur commerciales fonctionnent généralement sur une base de licence par développeur et potentiellement une forme d'abonnement qui donne accès au support technique et aux dernières fonctionnalités. Si votre équipe implémente la bibliothèque, vous pouvez augmenter le coût du temps d'implémentation pour votre équipe ou pour vous. Il convient de noter ici que la différence de temps de mise en œuvre entre la création d'un composant en interne et l'achat d'un composant tiers augmente considérablement pour les composants plus complexes, en faveur des outils prêts à l'emploi.

Pour mettre cette déclaration en contexte, envisagez qu'une licence unique, perpétuelle et sans redevance pour KendoReact avec prise en charge prioritaire s'élève à 999 $, pour tous les 70+ composants. Pour ce prix, vous pouvez utiliser cette version de KendoReact indéfiniment et dans des projets illimités. Vous avez la possibilité de renouveler votre abonnement dans un an pour obtenir la dernière version et continuer vos privilèges de support, avec une grande remise pour un renouvellement anticipé. Considérez maintenant: Quelle partie de l'interface utilisateur de votre application vous ou votre équipe créeriez si vous leur payiez 999 $… pour toute l'année .

Pour une discussion intéressante sur l'économie des logiciels open source et les moyens de indemniser quotidiennement les développeurs derrière les outils que nous utilisons gratuitement, et en tirer le meilleur parti, consultez l'article de TJ VanToll, Pouvons-nous rendre l'open source plus durable?

8. The Pleasure Factor

Enfin, un sujet qui est légèrement plus flou que ceux ci-dessus – mais un peu flou: surtout si vous choisissez une bibliothèque sur laquelle normaliser, la solution que vous choisirez sera là pour vous permettre de vivre au quotidien, pour la durée de votre projet, et au-delà. Allez-vous apprécier de travailler avec cette solution? Est-ce que l'entreprise / les personnes derrière elle rendront votre travail plus facile ou plus difficile? Quelle est la chance de surprises agréables et pas si agréables? En bref, ce sera un plaisir de travailler avec ce vendeur ou créateur? C'est difficile à mesurer, mais vous pouvez revoir vos points de contact avec cette entreprise et réfléchir à ce que votre expérience avec eux a été jusqu'à présent.

Conclusion

Décider de construire votre interface utilisateur en interne ou de mettre en œuvre une solution externe peut être un processus long et compliqué. Plus encore si vous cherchez une boîte à outils pour standardiser votre développement et l'utiliser tout au long de votre projet actuel et même dans les futurs. Compte tenu de l'impact que cette décision aura sur la qualité de votre candidature et éventuellement sur la motivation de votre équipe, cela vaut la peine de prendre le temps de passer en revue les avantages et les inconvénients de chaque option de votre liste restreinte.

Il est intéressant de noter certains des thèmes qui a continué à émerger dans les critères que nous avons énumérés ci-dessus:

  •     Avec quels risques êtes-vous à l'aise? Chaque solution comporte ses propres types d'incertitude. Réfléchissez également aux moyens d'atténuer ces risques offerts ou disponibles avec chaque option.
  • Sur quel type de travail souhaitez-vous que votre équipe se concentre? Est-ce que l'implémentation, la maintenance et la correction des bogues sont importantes pour vous ou votre équipe?
  • Combien de temps le résultat de ma décision restera-t-il avec moi? En d'autres termes, devrai-je maintenir cette application / développer ce projet pendant longtemps?
  • Pour quoi dois-je optimiser? C'est une question quelque peu réfléchie, car les développeurs optimisent parfois pour protéger le travail qui les intéresse le plus en recherchant la solution la plus efficace ou ce qui est le mieux pour l'entreprise. Si vous décidez de garder le travail «doux» pour vous, c'est bien sûr – mais il est utile d'en faire un choix conscient.

My Take, ou "The Pitch"

Je sais que vous attendiez que j'aille ici. Je détesterais décevoir.

Dites-moi ceci: la création d’interface utilisateur fait-elle partie des activités principales ou des compétences essentielles de votre entreprise? Sinon, et vous créez des applications professionnelles avec une interface utilisateur complexe, je dirais que le choix d'une bibliothèque payante est l'un des investissements les plus rentables que vous puissiez faire. Cela peut non seulement vous faire économiser de l'argent, mais aussi beaucoup de temps d'ingénierie précieux. Et le stress. Et un travail désagréable.

Nous avons littéralement eu un client qui nous a dit dans son ticket d'assistance qu'il ne pouvait pas dormir à cause d'un problème qu'il avait avec son interface utilisateur. Une fois qu'il a reçu la solution de mon coéquipier Stefan, il a répondu que son sommeil était revenu à la normale. Donc, si l'application que vous créez est basée sur React, utilisez l'essai gratuit de KendoReact de 30 jours (vous donnant accès à notre support technique) et vérifiez s'il peut résoudre votre problème et répondre à vos Critères. C'est peut-être la solution qui vous aidera à mieux dormir.





Source link