Créer des maquettes basse fidélité en parlant à son ordinateur

Nous avions un rêve...#

TeleportHQ a été fondée en 2016 avec pour mission d’humaniser la technologie. Nous avons réuni une équipe internationale de designers, de développeurs et de spécialistes des données, animée par la volonté de créer des outils suffisamment puissants pour capitaliser sur les connaissances humaines accumulées et automatiser toujours davantage la création d’interfaces utilisateur.

L’une de nos premières idées de recherche était de générer des sites web simplement en parlant à un ordinateur. Les récentes avancées de l’IA ont rendu la génération d’interfaces utilisateur concrète pour la première fois.

Pour créer une solution d’apprentissage automatique performante, il nous fallait deux éléments essentiels : une grande quantité de données et un outil de « traduction entre l’humain et l’ordinateur », capable de reconnaître le langage naturel et de le convertir en langages de programmation. Trouver cet outil de traduction s’est avéré particulièrement difficile. Nous avons essayé des outils comme IBM Watson ou Google Dialogflow, mais ils ne convenaient pas à nos besoins.

Au même moment, notre équipe d’ingénierie développait la Playground, une nouvelle plateforme de développement visuel d’interfaces utilisateur. La technologie de Playground a ensuite permis aux développeurs, aux designers et aux créateurs de produits de collaborer sur un projet et de voir instantanément, en temps réel, le code généré par leur travail collectif.

Playground a rapidement pris son essor, gagnant en puissance et attirant une communauté d’utilisateurs toujours plus nombreuse. La plateforme repose sur le langage de développement d’interfaces utilisateur UIDL, le langage de représentation intermédiaire de TeleportHQ, ainsi que sur un ensemble de générateurs de code open source.

Vous pouvez voir comment ils fonctionnent ensemble dans notre REPL, où vous pouvez modifier l’UIDL et voir le code généré en temps réel dans différentes variantes de JavaScript.

La création de Playground a également présenté un avantage supplémentaire : son UIDL et ses générateurs de code open source ont fourni l’infrastructure essentielle qui a libéré notre première piste de recherche. Pour un scientifique des données, l’UIDL, en tant que langage spécifique à un domaine, était beaucoup plus facile à utiliser que du code pur, qui peut planter à la moindre erreur de syntaxe et nécessite une intervention humaine pour être réparé.

Grâce à cet avantage, TeleportHQ a réalisé des progrès considérables dans sa quête visant à générer des sites web en dialoguant avec un ordinateur. Voici une vidéo présentant nos dernières avancées :

https://www.youtube.com/embed/fq1RPJUI_GM

Nous sommes sur le point de réaliser notre rêve et aimerions partager quelques étapes clés de nos recherches dans l’article de blog suivant.

Définir l’objectif : déterminer la sortie du modèle#

Notre première étape a consisté à définir la sortie pour laquelle nous allions entraîner notre modèle. Afin de simplifier le problème, nous avons choisi une approche que nous appelons « sémantique », c’est-à-dire un ensemble de cadres de délimitation avec leur type et leur positionnement absolu. Nous avons nommé ce format « conception basse fidélité », car il s’agit d’un sous-ensemble de ce que l’on appelle généralement une conception haute fidélité (qui comprend également les couleurs, les formes, les polices et d’autres attributs visuels). On pourrait dire que notre conception basse fidélité est à la conception haute fidélité ce qu’une structure de simples balises HTML est à une page web contenant tous ses textes et propriétés CSS.

Constituer les données : créer le jeu de données d’entraînement#

Il convient de mentionner qu’en parallèle du développement de Playground, nous avons commencé à collecter et à organiser des millions de pages web afin de disposer d’un approvisionnement continu en données sélectionnées, que nous avons utilisées pour notre conversion de maquettes filaires en code .

Afin de manipuler et d’exploiter cette base de données en pleine expansion, nous avons créé un analyseur web personnalisé, capable de traiter jusqu’à 6 000 pages par minute. Vous trouverez davantage d’informations sur le sujet dans cet article de blog.

Nous avons décidé de générer les pages web de manière itérative, en commençant par la barre de navigation et en terminant par le pied de page. Pour ce faire, nous avons extrait de notre jeu de données principal de pages web un sous-ensemble de 850 000 sections représentant différentes parties sémantiques des pages. Voici un exemple :

Données et capture d’écran de la section héro en basse fidélité

Premières tentatives : autoencodeur séquence à séquence#

À la fin de 2019, nous avons commencé par une approche simple et non supervisée, fondée sur un autoencodeur séquence à séquence. Au cœur de cette architecture se trouve un goulot d’étranglement dans lequel les sections sont encodées sous la forme d’un tableau à une dimension. Ce goulot d’étranglement sert généralement à générer de nouvelles données ; nous avons donc pensé qu’il serait possible de générer de nouveaux designs en échantillonnant ses valeurs de façon aléatoire.

Malheureusement, cela n’a pas fonctionné comme prévu. Bien que le système ait réussi à apprendre à encoder et à décoder, il a complètement échoué sur de nouveaux exemples ou avec un encodage aléatoire.

Nous avons essayé plusieurs autres approches et architectures, notamment les autoencodeurs variationnels, les GAN et les réseaux de neurones à graphes, mais après neuf mois d’essais et d’erreurs, les résultats n’étaient pas exploitables.

Architecture de l’autoencodeur

Le tournant : l’arrivée de la technologie GPT-3#

Plus tôt cette année, OpenAI a publié une nouvelle version de Generative Pretrained Transformer (GPT-3). Son système établit une nouvelle référence en matière de résultats de pointe sur plusieurs bancs d’essai, notamment en réponse aux questions et en traduction automatique.

GPT-3 génère des séquences de valeurs discrètes à partir d’un contexte donné. À partir de ce contexte, le modèle génère la suite de la séquence en la complétant automatiquement, jeton après jeton.

Comme il a été entraîné sur l’ ensemble complet d’Internet, le modèle donne des résultats remarquables dans des domaines très variés, de la philosophie à la médecine. Mais un cas d’utilisation en particulier a retenu notre attention : la génération de code.

Deux exemples en particulier se sont démarqués. Dans le premier, GPT-3 a été utilisé pour générer des commandes bash. Dans le second, il a servi à générer du code JSX. Ces deux exemples ont suscité l’enthousiasme de notre équipe, car le modèle avait manifestement assimilé avec succès toutes les données de Stack Overflow. C’était la preuve irréfutable que la technologie GPT pouvait permettre de dialoguer avec une machine et de générer des interfaces utilisateur.

GPT-3 génère des commandes bash à partir du langage naturel

Le vent en poupe : exploiter la puissance de GPT#

Enthousiasmé par le potentiel de cette technologie, TeleportHQ a demandé un accès anticipé à GPT-3, mais sa demande n’a pas abouti. Nous sommes néanmoins restés convaincus que la réponse à notre problème d’apprentissage automatique résidait dans l’architecture GPT. Cela nous a incités à créer notre propre version. Après quelques recherches, nous avons choisi de travailler avec minGPT, une implémentation légère de GPT.

Une image vaut mille mots : GPT contre minGPT

Grâce aux données dont nous disposions et à la simplicité de minGPT, nous avons pu alimenter très rapidement le réseau avec nos données. À notre grande surprise, ça a tout simplement fonctionné.

Lors de cette première expérience, le modèle a appris à générer les sections de nos pages, caractère après caractère, en incluant la profondeur et les coordonnées de chaque élément.

Avec le contexte « DIV 0 0.5 0.5 1.0 1.0 », le modèle était capable de compléter automatiquement les données d’une section. Il était alors possible de reconstituer l’arborescence suivante :

Première section générée avec GPT-UI à partir du contexte « DIV 0 0.5 0.5 1.0 1.0 »

Bien que prometteur, le problème n’était pas encore résolu : le contexte ne pouvait pas encore être défini comme une intention de l’utilisateur. Nous avons donc affiné le modèle en insérant au début de la séquence le contenu à générer (par exemple, le nombre d’images, de paragraphes ou de divs).

Encore une fois : ça a simplement fonctionné.

Ci-dessous, on peut voir quelques sections (sélectionnées avec soin) générées par ce modèle amélioré. Dans tous les cas, non seulement les vues arborescentes et les cadres de délimitation étaient cohérents, mais les sections générées contenaient également les éléments demandés.

Un exemple de ce nouveau contexte : « IMG 2 P 2 H1 2 $ ». En l’insérant simplement avant la section elle-même, le modèle pouvait commencer après le premier « $ » et générer automatiquement toute la section.

Trois sections générées au début de nos expériences

Nous sommes ensuite allés encore plus loin en fournissant des informations supplémentaires au début de la séquence afin d’enrichir l’invite. Le système pouvait alors apprendre à générer des sections de hauteur, d’orientation et de fonction spécifiques.

Notre première architecture fonctionnelle

Il nous manquait encore un dernier élément : une interface utilisateur permettant à une personne de communiquer avec l’ordinateur en langage naturel. Nous avons créé la configuration suivante, dans laquelle l’intention de l’utilisateur est indiquée dans un formulaire.

Le premier formulaire utilisé pour interagir avec le modèle

Après avoir créé le formulaire, nous avons ajouté une couche de traitement programmatique qui transformait les commandes en langage naturel (par exemple : « Hé TeleportHQ, crée-moi une section de type barre de navigation avec 1 image et 4 liens, d’une hauteur de 65 pixels ») en contextes (par exemple : « NAVBAR $ h 65 $ IMAGE 1 LINK 4 $ »).

Ci-dessous, vous pouvez voir une démonstration de notre interface utilisateur actuelle. Elle permet à l’utilisateur d’interagir avec le modèle et de créer une page Web en quelques minutes.

Prototype GPT-UI

Nouveaux horizons : cap sur 2021…#

Il y a quatre ans, TeleportHQ faisait partie des rares équipes à croire qu’il était possible de créer des interfaces utilisateur à l’aide du langage naturel. Depuis, nous avons travaillé sans relâche pour poser les jalons de la maîtrise du langage entre l’humain et la machine. Nos résultats nous rapprochent toujours plus de notre mission initiale : automatiser entièrement la création d’interfaces utilisateur.

Aujourd’hui, nous disposons d’un prototype GPT-UI pleinement fonctionnel. Il compte 6 millions de paramètres, contre 175 milliards pour le gigantesque GPT-3.

GPT-3 est réputé pour sa puissance exceptionnelle, grâce à sa capacité à traiter potentiellement toutes les tâches en langue anglaise. Notre modèle, plus petit et plus agile, offre toutefois davantage de spécialisation et de réactivité.

Avec le temps, grâce aux bonnes données et à l’entraînement assuré par le reste de l’architecture Teleport, notre GPT-UI pourrait rivaliser avec GPT-3 pour créer des interfaces utilisateur à partir du langage naturel. Il aurait en outre l’avantage d’être entièrement personnalisable et de ne nécessiter qu’une fraction des ressources requises pour faire fonctionner le modèle.

TeleportHQ a déjà commencé à suivre la même approche pour créer d’autres modèles, spécialisés dans la création de composants spécifiques et de designs mobiles complets.

Nous sommes enthousiasmés par son potentiel et convaincus que, dans un avenir proche, nous pourrons générer des pages web complètes et très fidèles à l’original en une seule requête.

Si vous souhaitez demander une démonstration privée, proposer une collaboration ou nous faire part de vos commentaires, contactez-nous à hello@teleporthq.io .

💡

Si cet article vous a plu, vous pourriez également être intéressé par nos précédents résultats sur l’utilisation de l’apprentissage automatique pour générer automatiquement du code à partir de maquettes filaires.

https://www.youtube.com/embed/ZD8Cnzc6KlY