Low-Code est une approche du développement de logiciels qui permet à chacun, même sans expérience de la programmation, de concevoir rapidement et facilement ses propres applications informatiques et des processus efficaces. La plupart des gens réagissent d'abord avec réticence lorsqu'ils entendent cela, car le développement de logiciels implique normalement aussi la programmation de logiciels.
Dans un précédent article de blog sur le thème No-Code / Low-Code, j'ai déjà écrit sur les détails de cette nouvelle approche de développement avec tous ses avantages et inconvénients, mais ce n'est pas le sujet de cet article de blog.
Dans cet article, je vous prends par la main et je construis avec vous votre première application Low-Code. C'est en effet la manière la plus rapide de comprendre ce que signifie réellement le Low-Code et de savoir si ce dernier peut éventuellement vous aider, vous ou votre équipe, à travailler plus efficacement à l'avenir.
Aurons-nous encore besoin de développeurs à l'avenir ?
Honnêtement, cela ne risque pas d'arriver. Même si le Low-Code est une tendance très en vogue en ce moment, cette nouvelle approche de développement ne pourra pas rendre la programmation logicielle classique superflue ou la remplacer. Permettez-moi d'expliquer brièvement comment j'en suis arrivé à cette conclusion.
Je suis fermement convaincu que le Low-Code n'est pas adapté à tous les développements. Le principal avantage du Low-Code réside dans sa simplicité. Mais cette simplicité signifie aussi que le développement est limité par la force des choses. De mon point de vue, le Low-Code doit être considéré comme un terrain de jeu pour tester de nouveaux processus ou solutions. Comme vous allez le voir, SeaTable vous permet de développer un premier prototype en très peu de temps et de l'utiliser ensuite pour tester votre processus. Après quelques jours, vous et votre équipe en tirerez rapidement les premières conclusions : avez-vous vraiment besoin de ce processus ? Faut-il adapter le processus, le modifier ou l'aborder différemment ?
De mon point de vue, le Low-Code doit être considéré comme un terrain de jeu pour tester de nouveaux processus ou solutions.
Bien entendu, il est également possible qu'avec ces nouvelles connaissances, vous optiez délibérément pour une solution spéciale prête à l'emploi ou que vous fassiez appel à un développeur pour la programmation.
L'important est que Low-Code vous ait aidé à mettre en œuvre votre processus et à acquérir de l'expérience.
Vous n'êtes d'ailleurs pas obligé de lire ce texte pour développer votre première application Low-Code. Si vous préférez regarder une vidéo plutôt que de lire un texte, vous pouvez également regarder la vidéo suivante sur YouTube.
N'existe-t-il pas déjà des applications "Customer Feedback / Feature Request" ?
Bien sûr que si. Les applications de feed-back client existent déjà comme des grains de sable. Voici une petite sélection des services en ligne les plus connus :
canny.io
canny.io est l'une des solutions de feed-back client les plus connues du marché. La plateforme SaaS attire par son prix d'entrée gratuit, qui comprend pratiquement toutes les fonctions importantes, y compris la planification de la feuille de route. Ce qui est un peu dissuasif, c'est le prix élevé de 400 $ par mois si l'on a besoin de plus de fonctions.
fider.io
Il faut bien regarder pour trouver des différences dans la surface de fider.io par rapport à canny.io. fider.io marque des points grâce à son approche open source et à la possibilité d'héberger soi-même le logiciel. En termes de prix également, fider.io est nettement moins cher que canny.io, même s'il faut pour cela renoncer à certaines fonctions, comme par exemple une feuille de route et un changelog.
nolt.io
Nolt est un autre fournisseur d'un Customer Feedback Board hébergé en ligne. Un Conseil Nolt est mis en place en quelques minutes et convainc par son design simple qui fonctionne également bien sur les petites résolutions. En ce qui concerne le prix, Nolt rend également les choses extrêmement simples, puisque chaque board coûte simplement 25$ par mois. Ni plus ni moins.
Maintenant, vous vous posez peut-être la question suivante : pourquoi reproduire ces solutions avec du code Low ? La réponse à cette question est très simple. Pourquoi se donner la peine de faire quelque chose soi-même alors qu'il existe déjà depuis longtemps une solution pour le faire ?
Parce qu'en développant vous-même le processus, vous le contrôlez entièrement et pouvez ensuite l'adapter à votre guise. En même temps, il n'y a pas de meilleure façon d'apprendre quelque chose que de le faire soi-même. Alors, allons-y.
Qu'est-ce qui fait une bonne application de feedback client ?
Que vous programmiez de manière classique ou que vous travailliez avec une plateforme Low-Code comme SeaTable. Au début, vous devriez prendre du recul et réfléchir à ce que vous voulez atteindre exactement.
L'application Customer Feedback que nous avons développée doit permettre de répondre aux quatre exigences suivantes :
- Collecte de tous les types de feedbacks des clients en un seul endroit
- Tirer des enseignements de ce feedback
- Identifier et mettre en œuvre des améliorations pour votre produit
- Faire participer les clients à la discussion à tout moment.
Nous allons maintenant mettre en œuvre ces exigences petit à petit dans SeaTable. Alors retroussons nos manches et mettons-nous au travail.
Étape 1 : Tableau de synthèse Feature Requests / Customer Feedback
Tableau des "Feature Requests
Créez un tableau de quatre colonnes dans une base SeaTable. La première colonne contient le TitreLa première colonne est une brève description de l'exigence. La deuxième colonne est destinée à une description plus détaillée. La troisième colonne est destinée à la StatutC'est pourquoi vous devriez utiliser une sélection simple. Pour la dernière colonne, choisissez le type de colonne "Créateur", qui sera remplie automatiquement. Vous pouvez bien sûr choisir librement le nom des colonnes ou les compléter par vos propres données. N'oubliez pas qu'à l'avenir, toutes les demandes de fonctionnalités seront saisies et listées dans ce tableau.
Nouvelles inscriptions par formulaire web
Ensuite, nous avons besoin d'un moyen pour que vos clients vous transmettent de nouvelles demandes de fonctionnalités. Pour cela, un formulaire web peut être créé en quelques clics par SeaTable. Lors de la création du formulaire Web, vous pouvez décider de le rendre accessible à tous ou seulement aux personnes disposant d'un compte SeaTable valide. Vous pouvez ainsi contrôler exactement qui seront les utilisateurs de votre nouveau formulaire web. Vous pouvez maintenant soit publier le lien vers votre nouveau formulaire web sur votre site web, soit l'envoyer à vos clients.
Vous avez déjà développé une première petite application low-code qui vous permet de collecter les commentaires des clients et les demandes de fonctionnalités. Vous pourriez maintenant publier une vue en lecture seule de votre tableau sur votre site web et votre projet serait déjà terminé. Mais cela ne nous suffit pas, car nous voulons encore autoriser les commentaires et les votes pour les différentes feature requests.
Étape 2 : Commentaires sur les feature requests
Tableau pour les commentaires
Maintenant que les feature requests sont clairement présentées dans un tableau, nous allons passer aux commentaires. L'idée est que tous les clients aient la possibilité de mener une discussion sur la base des feature requests souhaitées. Nous créons donc un tableau pour ces commentaires. Ce tableau nécessite en tout cinq colonnes. Nous utilisons la première colonne pour attribuer automatiquement un numéro aux commentaires. Dans la deuxième colonne, nous saisissons le commentaire. Dans la troisième colonne, l'auteur est à nouveau saisi automatiquement. La quatrième colonne est la date de création et la cinquième colonne est une colonne de lien vers les Feature Requests. Il est important que la colonne de lien n'autorise que le lien avec une Feature Request. Cela n'aurait en effet aucun sens d'associer un commentaire à plusieurs feature requests.
Formulaire web pour la saisie de nouveaux commentaires
Nous avons maintenant le tableau nécessaire pour ajouter des commentaires aux différentes Feature Requests. Si vous le souhaitez, vous pouvez créer vos premiers commentaires directement dans le tableau et les attribuer à l'une des Feature Requests. Ici aussi, il est bien sûr judicieux de créer un formulaire web permettant de sélectionner d'abord la Feature Request et de saisir ensuite un commentaire.
Étape 3 : Tableau des votes
Annexe du tableau
Passons maintenant au dernier tableau de notre application Low-Code. La structure du tableau Votes est super simple. Nous utilisons à nouveau une numérotation automatique dans la première colonne, l'auteur rempli automatiquement dans la deuxième colonne et une colonne de lien vers les feature requests. C'est tout ce dont nous avons besoin dans ce tableau, car nous voulons seulement savoir quelle personne a donné son vote pour quelle Feature Request. Faites une première entrée dans ce tableau et liez une Feature Request de votre choix.
Si vous retournez maintenant au premier tableau, vous verrez que deux nouvelles colonnes ont été ajoutées dans ce tableau. Les liens entre les tableaux fonctionnent dans les deux sens, c'est pourquoi vous pouvez maintenant voir dans le tableau Demandes de fonctionnalités voir les liens vers les autres tableaux. Pour avoir une vue d'ensemble encore plus claire, vous devriez ajouter deux autres colonnes de formules et utiliser la formule countlinks(Spaltenname) faire compter la somme des commentaires et des votes. Ainsi, vous pouvez également trier votre tableau à l'aide de ces deux colonnes afin de voir en haut les feature requests les plus populaires ou les plus vivement discutées.
Vote par bouton et liaison par automation
Il nous manque encore la possibilité de voter. On pourrait à nouveau utiliser un formulaire web, mais il est un peu compliqué d'ouvrir un formulaire web juste pour sélectionner une valeur et l'envoyer. L'utilisation d'un bouton est nettement plus rapide et plus simple. Nous attribuons à ce bouton la fonction Copier la ligne dans un autre tableau. Avec cette fonction, toutes les colonnes avec des noms identiques sont copiées. Créez encore une autre colonne dans la table Votes qui correspond au nom de la première colonne de la table Feature Requests.
Cliquez ensuite sur le bouton et observez ce qui se passe. Une nouvelle ligne est créée dans le tableau Votes, mais il manque encore le lien automatique vers la bonne Feature Request. Nous y parvenons à l'aide d'une règle d'automatisation qui crée automatiquement un "lien" vers le premier tableau à chaque nouvelle ligne. Testez tout de suite votre application en distribuant quelques votes.
Script Python pour la suppression des doublons
Vous remarquez immédiatement que nous avons certes créé une possibilité de vote très simple, mais que cela n'empêche pas qu'une personne puisse voter plusieurs fois pour la même Feature Request. Nous voulons bien sûr éviter cela et utilisons pour cela le script Python suivant.
table_name = 'Votes'
view_name = 'Default View'
column_to_compare_a = 'Title'
column_to_compare_b = 'Voter'
## don't change anything below this line ...
from seatable_api import Base, context
server_url = context.server_url
api_token = context.api_token
def remove_duplicates():
# Authentication
base = Base(api_token, server_url)
base.auth()
# variable to save row values for comparison
column_a = ""
column_b = ""
rows = base.query('select * from '+ table_name +' order by '+ column_to_compare_a +','+ column_to_compare_b)
for row in rows:
if row.get(column_to_compare_a) == column_a and row.get(column_to_compare_b) == column_b:
print("Duplicate found at row with the id: " + row.get('_id') + ". Delete this row ...")
base.delete_row(table_name, row.get('_id'))
# store this values for comparison
column_a = row.get(column_to_compare_a)
column_b = row.get(column_to_compare_b)
remove_duplicates()
Nous ajoutons ce script comme action supplémentaire à la règle d'automatisation que nous venons de créer et nous nous assurons ainsi que les entrées en double sont immédiatement supprimées. Essayez-le tout de suite. Vous verrez qu'une nouvelle entrée est créée dans le tableau des votes, mais qu'elle est immédiatement supprimée.
Optimisation et visualisation par tableau Kanban
Dans la dernière étape de votre développement, vous devriez encore optimiser vos tableaux et ajouter par exemple des regroupements par statut ou par Feature Requests. Vous devriez masquer les colonnes inutiles et créer d'autres vues, comme par exemple une feuille de route qui ne contient que les feature requests ayant le statut "en cours de planification". En outre, vous pouvez limiter quel utilisateur peut effectuer quelle modification dans vos tableaux. Vous devez par exemple vous assurer, à l'aide des autorisations de colonnes, que vous seul ou des personnes sélectionnées pouvez modifier le statut de certaines Feature Requests.
Comme dernière étape, je vous recommande encore d'activer le plug-in Kanban, car il offre une belle représentation visuelle de vos Feature Requests dans leur statut respectif. Ainsi, en tant que créateur et administrateur de ce tableau, vous pouvez également modifier rapidement et facilement le statut par glisser-déposer.
Publication de votre application Low-Code
Nous voici arrivés à la fin du développement de votre application low-code. Votre nouvelle Feature Request App offre deux formulaires web pour la création de nouvelles Feature Requests et de commentaires, ainsi qu'un simple bouton pour mettre à jour les différentes Feature Requests. D'un autre côté, votre première application offre encore un grand potentiel d'amélioration. Soyez créatif et essayez-le tout simplement. Bien entendu, vous trouverez également cette application dans notre section Modèles.