Comment bien réaliser son projet WeWeb de A à Z ? Après des dizaines de projets réalisés, on vous conseille ce à quoi il faut penser avant, pendant et après le développement de votre application web !
Avant de lancer votre app : Préparez les fondations
Ne négligez pas le design UI (user interface)
Pour maximiser les chances de réussite de votre projet lowcode, commencez par ouvrir Figma pour créer les maquettes de votre futur application. Cela vous permet de deisgner votre application avant de la dévlopper. En plus, vous pouvez avancer très vite avec des milliers de templates et UI Kits déjà existants.
Une fois votre design prêt : activez le plugin Figma to WeWeb : cela permet d’importer les styles et typographies. Et aussi, si vous avez bien réalisé votre maquette, vous pouvez importer boutons, inputs, images et icônes. (Ainsi que tout le reste, mais le contenu importé ne sera peut-être pas adapté !)
Le back-end : Faites appel à un pro
Dans un premier temps, il faut choisir son back-end. Faites votre marché en fonction de vos besoins : facilité d'utilisation, coûts, flexibilité… n’hésitez pas à comparer l’existant en terme de back-end low-code. Xano, Supabase, AirTable… plusieurs options s’offrent à vous. Mais le plus important restera de bien créer sa structure de base de données, sans quoi l’API que vous utiliserez vous causera beaucoup de problèmes.
Pensez donc à bien nommer vos tables, vos API RESTful, et à bien optimiser la structure de vos données.
Sur weweb, utilisez les classes, composants et sections
Une fois votre back-end et votre design prêt à être développer, il ne reste plus qu’une seule chose à penser : l’utilisation de classes, composants et sections pour découper et factoriser votre développement.
Essayez de repérer en amont un maximum tout ce qui sera répété, que ce soit au niveau du style ou contenu. En général, on retrouve:
- Pour les classes : les boutons, inputs, cards, container… ainsi que leurs states respectifs (hover, focus…)
- Pour les composants : Inputs (couplé avec les classes), menus déroulant, cards, badges, file uploader…
- Pour les sections : principalement navbar/sidebar et footer, ainsi que les modales si vous en avez.
Les bonnes pratiques pendant le développement
Optimiser les tailles, images, nombre d’éléments
Au maximum, essayez de favoriser les éléments qui ont des tailles définies : en pixel, em, rem… et évitez les tailles relatives : en %, vh, vw… souvent, vous serez obligé d’avoir des longueurs relatives afin que vos éléments prennent toute la place disponible, mais cependant pour les hauteurs, celles-ci sont en générales connues à l’avance : c’est le cas des inputs, boutons, etc.
Pensez à bien importer vos images dans un format léger ainsi qu’avec une taille adaptée:
inutile d’avoir une image de 1000*1000 en .gif si c’est pour afficher une photo de profil par exemple. De manière générale, privilégiez des images en .webp ou mieux : en .svg si le format vous le permet.
💡 Utilisez Squoosh pour facilement réduire la taille de vos images, et ce en illimité sans inscription ! En plus, vous avez un grand nombre de paramètres accessible pour convertir comme bon vous semble.
Enfin, réduisez au maximum le nombre d’éléments HTML affichés sur votre page, par exemple évitez l’encapsulation excessive avec des divs.
Prioriser les appels au back-end
Lorsque vous chargez votre page, le plus important pour l’utilisateur est d’avoir le Largest Contentful Paint (LCP) (ou le Rendu de Contenu Important en français) qui soit disponible le plus vite possible. Ainsi, il vous faut prioriser ce que vous voulez afficher à l’utilisateur, et cela passe notamment par vos appels au back-end et ce que celui-ci vous renvoie.
Par exemple, on ne voudra appeler que les collections qui sont affichées à l’écran directement, ainsi que le strict minimum au niveau du contenu demandé.
💡 Pagespeed vous permet d’avoir un aperçu et un score de vitesse de votre site : n’hésitez pas à y jeter un oeil régulièrement pendant le développement !
Dès que le FCP est disponible, le plus important est que l’utilisateur puisse naviguer et interagir avec le site : c’est ce qu’on appelle le Temps d’interactivité (TTI). Ainsi, éviter de bloquer le bon fonctionnement de la page avec du Javascript ou tout workflow rendant impossible l’utilisation du site pendant le chargement.
Utiliser les workflows globaux et formulas
Afin d’être le plus flexible possible, vous devez utiliser au maximum les workflows globaux et les formulas. Au début, l’implémentation peut paraître fastidieuse, et en fin de projet il est même possible que certains workflows fassent appel à 3, 4 voire même 5 workflows enchaînés !
Un workflow ne devrait faire qu'une seule et unique chose à la fois, et ne devrait pas avoir trop de paramètres.
Par exemple :
- togglePopup (popup, boolean)
- sendMessage (message, user)
- launchToast (title, description, type)
Et bien évidemment, le même procédé s’applique aussi aux formulas.
Maintenance et conseils
Enregistrer et suivre les erreurs
Afin d’avoir un bon suivi et de comprendre ce que font les utilisateurs, il faut bien penser à voir et logger les erreurs quand celles-ci arrivent. C’est possible d’implémenter cela aussi bien en front qu’en back, donc si possible faites sur les 2.
Côté WeWeb, on peut retrouver:
- On collection fetch error, qui est un workflow de page. Dès qu’une collection a eu un problème de fetch, alors ce workflow est exécuté.
- On error, qui est le tab adjacent au workflow par défaut. Cette partie s’active lorsque le workflow n’a pas fonctionné jusqu’au bout, et vous pouvez retrouver dans les variables de contexte la raison.
Bien nommer ses variables, workflows et collections
Il faut toujours renommer ce que l’on fait dans WeWeb, car ça n’a pas d’incidence sur le SEO ou la performance, donc on peut en profiter. En effet, WeWeb utilise des UUID pour les variables/workflows/collections, donc que vous nommiez votre variable: ppShowOT ou Popup - Show only one time n’aura pas de différence, si ce n’est que pour vous !
Donc n’hésitez pas à être le + clair possible, en vous adaptant avec votre équipe. En effet, le mieux est de se coordonner avant le début de projet, et de savoir par avance comment vous nommez vos éléments : plutôt avec une approche de développeur ? (snakeCase, ou camel_case) ou alors une approche marketing ? (en décrivant le plus possible, parfois même avec des émojis 👌)
Utiliser des loaders et templates de chargement
Si malgré tous ces conseils, le chargement de votre application devient conséquent (ce qui est tout à fait envisageable, pas d’inquiétudes !), alors il vous faudra mettre en place des loaders ainsi que des templates de chargement, ou des squelettes de chargement.
En effet, au lieu d’attendre à regarder une page blanche chargée, c’est préférable pour l’utilisateur de voir qu’il se passe bien quelque chose !
Ainsi, 3 solutions s’offrent à vous :
- Utiliser le loader de haut de page, aux couleurs de votre entreprise
- Utiliser un Loader basique, directement depuis: Add → Loader
- Utiliser un squelette de chargement
💡 Pour le squelette de chargement, n’hésitez pas à regarder de tutoriel de JP Trinh.
Conclusion
Et si malgré tous ces conseils, vous n’arrivez pas à un résultat satisfaisant… nous nous ferons un plaisir de vous aider dans la réalisation de votre projet. N’hésitez pas à nous contacter !