Modèle de formulaires d’interface utilisateur dynamique, applications Web et mobiles

Ce blog est écrit pour les décideurs sur les projets d’interface utilisateur, généralement des architectes ou des responsables de logiciels ainsi que des développeurs de logiciels frontaux. Le sujet est largement applicable à différents paradigmes d’interaction utilisateur (Web, application mobile, chat, etc.).

La rédaction de formulaires est une activité très courante. Les formulaires simples sont faciles à gérer avec la plupart des frameworks ; cependant, les formes dynamiques sont difficiles à développer et à maintenir, et la difficulté augmente généralement de façon exponentielle.

Qu’entend-on par formes dynamiques ? Ce sont des formulaires dans lesquels :

1. L’ensemble total de questions potentielles est vaste, comme c’est souvent le cas avec de nombreux processus métier de nos jours. Bien sûr, pour une bonne convivialité, nous ne voulons poser que les questions pertinentes pour le cas de l’utilisateur actuel.
2. Et, plus intéressant, l’ensemble des questions à poser dépend des réponses des questions précédentes (étapes précédentes) et/ou des données externes. Cela conduit à des parcours de questionnaires indépendants pour différents utilisateurs.

Lorsque le nombre de questions est important, nous constatons généralement que le nombre total de chemins augmente (généralement de manière exponentielle) et submerge l’équipe de développement. La programmation de tout cela en code impose une charge énorme aux équipes de développement et de test front-end, et il est difficile à maintenir et à faire évoluer.

De plus, cela entraîne des difficultés à réutiliser le code dans différents cas d’utilisation et paradigmes d’interaction utilisateur.

Pour aggraver ces problèmes, l’entreprise souhaite que les questions soient modifiées relativement fréquemment. Nous aimerions pouvoir donner aux analystes commerciaux qui comprennent les cas d’utilisation des outils afin qu’ils puissent maintenir les questionnaires sans changements de code dans le front-end Web et l’application mobile. De plus, pour l’application mobile, nous voudrions une solution où nous n’avons même pas besoin de demander à l’utilisateur de mettre à jour l’application sur ses appareils pour toute modification des questionnaires.

Pour vous donner un exemple concret, il est typique pour une réclamation d’assurance voyage d’avoir des centaines de conditions différentes et de chemins différents dans le processus de collecte de toutes les données d’une réclamation. Dans de tels cas d’utilisation, de nombreuses questions doivent être posées :

• Il y a plusieurs raisons de soumettre une réclamation d’assurance, allant d’un voyage annulé à des bagages perdus, des blessures, une maladie, etc.
• Elle peut affecter une ou plusieurs personnes en voyage.
• Les questions peuvent être différentes en fonction de la politique à laquelle l’utilisateur a souscrit.
• Il y a différentes questions et flux si le voyage est annulé avant ou après le départ.
• Nous devons également collecter divers justificatifs et notes de frais.
• Les règles de validation sur ce qui peut être saisi sont très complexes et varient selon les entrées et les données précédentes (par exemple, le montant total réclamé dans cette réclamation et le montant déjà réclamé dans l’année).

La liste se rallonge de plus en plus. Vous trouverez ci-dessous une représentation visuelle de la façon dont le flux devient rapidement complexe. À partir de là, nous pouvons commencer à saisir la complexité que ces cas d’utilisation apportent (et ce diagramme ne fait qu’effleurer la surface) :

Une solution élégante à ces problèmes consiste à utiliser un système de règles pour définir le modèle du formulaire dynamique indépendamment de la façon dont il est rendu dans l’interface utilisateur frontale et l’appareil. Le modèle spécifie les questions à poser à chaque étape du processus et les chemins empruntés par le flux de questions. Il peut spécifier des règles de validation simples à arbitrairement complexes. C’est un besoin que nous constatons dans de nombreux secteurs qui ont des processus complexes, pour n’en citer que quelques-uns : la santé, la finance, l’éducation, les agences d’État et les assurances.

Ce n’est pas nouveau. Divers modèles de conception de modèles/vues ont été utilisés dans le développement frontal. Ainsi, le concept de conception de base est très familier aux équipes d’interface utilisateur.

Ce qui est nouveau, c’est l’utilisation d’un système de règles pour définir le modèle. Cela permet à un utilisateur d’appliquer une logique simple à complexe pour spécifier conditionnellement les contrôles à afficher, les validations à appliquer et le flux à suivre. Corticon.js en tant que système de règles low-code et facile à utiliser, permet aux analystes métier familiarisés avec le domaine du problème de créer et, surtout, de maintenir le modèle.

La séparation des préoccupations du code UI responsable du rendu du questionnaire présente de multiples avantages :

• Les organisations peuvent déployer de nouveaux questionnaires plus rapidement, car ce modèle permet de créer des composants côté client (ou moteurs de rendu) réutilisables dans différents questionnaires.
• Le modèle peut s’exécuter en cours avec l’interface utilisateur (généralement pratique avec les applications Web) ou peut être déployé aussi facilement qu’un service distant (sans serveur sur AWS, Azure ou GCP) ou en tant que serveur de nœud simple. Ceci est généralement plus pratique pour les applications mobiles (IOS, Android) car cela permet aux utilisateurs de mettre à jour fréquemment le modèle sans avoir à mettre à jour l’application mobile.
• Les organisations peuvent atteindre plus de constituants plus rapidement, car le même modèle peut être utilisé pour piloter des questionnaires dynamiques sur différentes plateformes. Le modèle est suffisamment abstrait et peut être réutilisé pour implémenter un composant de rendu d’interface utilisateur sur différentes plates-formes, par exemple, sur un appareil mobile et une application de navigateur de bureau.
• Réduisez la charge des organisations informatiques car les services de décision peuvent être créés par des analystes métier qui comprennent mieux le problème métier. C’est-à-dire que les spécialistes métier peuvent créer directement les règles pilotant les formulaires et sont ainsi capables, par exemple, d’ajouter ou de modifier facilement certaines questions sans modification du code frontal.
• Les développeurs front-end de l’interface utilisateur peuvent se concentrer sur la convivialité et ne pas avoir à se soucier des « règles commerciales » déterminant les questions à poser à chaque étape.
• L’actualisation de l’interface utilisateur devient beaucoup plus facile car le même modèle peut être réutilisé dans différentes interfaces utilisateur de rendu.
• Les tests sont grandement améliorés car :
  • Le modèle peut être testé unitaire et système avant intégration. Et l’ensemble du processus peut être automatisé et faire partie d’un pipeline CI/CD.
  • Toute modification apportée par les analystes métier peut être validée par le business group.

En conclusion, si vous avez affaire à des formulaires complexes ou dynamiques, envisagez d’utiliser Corticon.js pour modéliser les questions à poser, le flux à emmener l’utilisateur et les validations à définir. Vous économiserez beaucoup de temps de développement à l’avance et vous obtiendrez également plus d’agilité dans la maintenance de ces formulaires. Consultez notre solution open source sur Formulaires dynamiques Github.

En savoir plus sur Corticon.js ici.

Essayez Corticon.js