L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Quelle est la prochaine étape pour les contrôles HTML?
Dans cet épisode, nous parlons de contrôles HTML. Pourquoi sont-ils si difficiles à coiffer et comment cela pourrait-il changer à l'avenir? Drew McLellan s'entretient avec Stephanie Stimac et Melanie Richards de Microsoft pour le savoir.
Afficher les notes
Mise à jour hebdomadaire
Transcription
Drew McLellan: Mon premier invité est un responsable de programme pour les expériences de développement Microsoft Edge, mais préfère se considérer comme un concepteur, un développeur front-end et un développeur défenseur de Microsoft Edge. Mon deuxième invité est également un gestionnaire de programme pour Microsoft Edge axé sur la plate-forme Web. Elle a également une formation en conception Web et en développement front-end. Elle adore concevoir et créer des objets amusants pour le Web et double actuellement l'art 3D.
Drew: Nous savons donc qu'ils sont tous deux des développeurs Web expérimentés qui travaillent dur pour faire avancer la plate-forme Web, mais le saviez-vous? ensemble, ils ont remporté le Kentucky Derby habillé en cheval de pantomime? Mes amis, veuillez souhaiter la bienvenue à Stéphanie Stimac et Melanie Richards. Salut Stéphanie. Salut Mélanie. Comment vas-tu?
Stephanie Stimac: Je suis en train de casser.
Melanie Richards: Je suis aussi simplement en train de casser.
Drew: Cela fait probablement environ un an Stéphanie, depuis nous vous avons eu la dernière fois sur le podcast, et vous avez l'honneur douteux d'être notre premier invité de retour. À ce moment-là, il y a un an, Edge était en train de passer à un moteur de rendu de chrome.
Drew: Melanie, je suppose que cette transition a également été un gros problème pour votre équipe sur la plate-forme Web. Comment ça s'est passé l'année dernière? La transition a-t-elle été harmonieuse et réussie?
Stephanie: Je pense que oui. Donc je pense que Gavin, nous avons parlé en dernier, nous étions juste en train de déployer notre version stable sur certaines plates-formes. Et maintenant, nous sommes également sous Linux, et il y a eu tellement de bonne réception de la part de la communauté des développeurs, les gens sont ravis d'utiliser Edge, donc la réception a été vraiment excellente et je connais les expériences des développeurs. Nous avons travaillé sur des trucs amusants qui arriveront bientôt, mais c’est vraiment bien.
Drew: C’est incroyable. Je ne savais pas que Edge était également disponible sous Linux maintenant, car il est également disponible sur Mac depuis un certain temps, ce qui est formidable de pouvoir exécuter une page sur un Mac. Je veux dire, Windows est évidemment le genre de système d'exploitation de bureau dominant. Le rôle du navigateur principal sur cette plate-forme est assez immense.
Drew: Et il y a eu un peu d'histoire irrégulière en ce qui concerne Microsoft et ses navigateurs, je pense que nous pouvons être honnêtes à ce sujet. Parfois ouvrir la voie, puis peut-être trébucher un peu et être laissé pour compte. Mais nous savons tous en tant que développeurs que la douleur qui vient d'une navigation aussi importante n'est pas à la hauteur. C'est donc formidable de voir que maintenant c'est une expérience vraiment de première classe pour les utilisateurs, mais aussi pour les développeurs aussi avec Edge, avec toutes sortes d'outils de développement et avec une expérience vraiment de première classe à cet égard également.
Melanie: Oui, cela a été formidable pour nous dans l'équipe, car nous avons eu en quelque sorte une véritable opportunité d'aider à faire avancer un peu plus le Web. Lorsque nous construisions en quelque sorte sur du HTML de pointe, il y avait des domaines dans lesquels nous devions rattraper certaines API.
Melanie: Et maintenant que nous collaborons et apportons de nouvelles idées dans le code chrome base et aux normes, il devient beaucoup plus facile de dire, d'accord, quelle est la prochaine étape? Comment résoudre les problèmes des développeurs et de nos utilisateurs? Donc, ce fut un peu une joie de collaborer avec des gens de différentes entreprises sur celui-ci.
Drew: Il semble très naturel que ce soit une expérience de collaboration et c'est un peu ce que le Web est conçu pour être,
Melanie: Absolument.
Drew: Donc, je voulais vous parler tous les deux aujourd'hui des contrôles HTML. Et ce terme lui-même, je suppose, est enveloppé dans une sorte de jargon de spécification de plate-forme. Que voulons-nous dire en termes pratiques lorsque nous parlons de contrôles HTML et quels sont les types de problèmes que les concepteurs et les développeurs pourraient résoudre avec eux sur un projet de tous les jours?
Melanie: Oui, donc nous sommes principalement penser aux contrôles de formulaire qui permettent l'entrée de l'utilisateur d'une manière ou d'une autre. Vous avez donc votre Slack, votre radio, la case à cocher, les boutons, cela s’étend également au lecteur vidéo et aux commandes.
Melanie: Donc, je pense que beaucoup d’entre nous ont vécu en ce qui concerne les participants. des contrôles personnalisables que nous avons personnellement expérimentés, c'est une sorte de lutte pour adapter ces commandes à la marque et à l'expérience utilisateur que nous recherchons pour notre base d'utilisateurs particulière.
Melanie: Donc, il y a des choses qui semblent ils devraient être assez triviaux, juste obtenir les bonnes couleurs dans certaines options. Et le fait que vous deviez simplement recréer complètement un contrôle pour ce faire, pour vous aligner sur votre image de marque, ce qui est quelque chose que beaucoup de projets exigent et qui est si difficile.
Melanie: J'ai vu un tweet il y a quelques mois, lorsque nous en parlions avec d'autres fournisseurs de navigateurs. Quelqu'un disait, Oh, vous voulez des icônes dans vos options de sélection, vous avez un problème. Donc, vous recréez le select et maintenant vous avez 37 problèmes.
Melanie: Il y a tellement de choses que vous devez gérer en tant que développeur concepteur, obtenir la bonne accessibilité, et il y a tellement de dimensions différentes de cela, la sémantique , les interactions du clavier, un contraste élevé, prenant en charge différents schémas de couleurs, ce genre de chose. Et nous constatons que les gens ne font que les recréer partout, plusieurs cadres différents même au sein de la même entreprise, beaucoup d'énergie de concepteur de développeur y est investie et c'est comme, d'accord, et si nous pouvions simplement faciliter l'utilisation du des choses hors de la boîte et de construire sur celles-ci et de ne pas avoir à recréer la roue ici?
Drew: Je pense qu'il y avait ce genre de concept avec l'implémentation précoce des contrôles de formulaire, qu'ils devraient ressembler à " est natif du système d'exploitation. Ce que vous pouvez comprendre du point de vue de la cohérence de l'expérience utilisateur pour l'ensemble du système d'exploitation.
Drew: Nous avons tous utilisé des applications de bureau, en particulier des applications multiplateformes qui implémentent leurs propres contrôles plutôt que d'utiliser les natifs et cette expérience peut être vraiment horrible. Vous pouvez donc voir d'où vient cette réflexion. Mais je pense que c'est presque une fausse promesse qu'il y a une expérience cohérente, car les contrôles d'une page Web ne se sont jamais vraiment comportés de la même manière que les contrôles des applications natives et du système d'exploitation, ils n'ont jamais vraiment fonctionné comme des contrôles natifs. C'était donc une sorte de couche de peinture, mais pas vraiment la même expérience utilisateur.
Stephanie: Exactement. Alors oui, j'ai plongé un peu dans l'histoire des contrôles, et je pense qu'au début ils se comportaient comme des contrôles de plate-forme natifs, car aux débuts du Web, c'était le système d'exploitation sous-jacent qui était en quelque sorte rendu
Stephanie: Et puis cette idée que les développeurs voulaient plus de contrôle sur la fonctionnalité et le style. Je lisais un article de blog de je pense, 2001, et donc comme CSS venait d'être normalisé et était en quelque sorte adopté comme le principal langage de style et les gens essayaient de styliser les contrôles et d'avoir plus de contrôle sur les contrôles.
Stephanie : Et cela a conduit, je pense, et même aujourd'hui, à une énorme sorte de divergence, je pense, dans la façon dont ils fonctionnent. Comme Melanie a dit que vous avez des gens qui recréent des contrôles de formulaire à partir de zéro, et ils peuvent ne pas imiter les contrôles de formulaire natifs de toutes leurs fonctionnalités. Vous aurez donc une sélection qui se comporte peut-être différemment sur un site Web et sur un autre.
Stephanie: L'expérience peut donc être assez choquante. Et je pense que même sur différentes plates-formes, nous avons des contrôles natifs qui ne se comportent pas de la même manière, ils se comportent différemment sur différentes plates-formes. Donc, cela crée une sorte de problème intéressant pour les développeurs lorsque vous pensez à l'expérience utilisateur.
Drew: Quand vous pensez à tout ce qui fonctionne sur la plate-forme Web, sorte de services bancaires et de soins de santé et les interventions d'urgence, les gouvernements, le commerce électronique, les économies mondiales fonctionnent essentiellement au-dessus de la plate-forme Web ces jours-ci, par divers moyens. Et tout cela est construit sur quelques contrôles HTML d'il y a 25 ans, à peu près, ils sont les mêmes depuis des décennies. Et ils sont vraiment terribles, n'est-ce pas? Ils sont basiques.
Drew: Mais comment en sommes-nous arrivés à ce point où ils ont été si laissés pour compte et que personne ne les a touchés pendant si longtemps? Comment en sommes-nous arrivés au point sur la plate-forme Web où le lien le plus faible est le contrôle d'entrée?
Melanie: Oui, je pense que c'est un très gros défi, quelque chose auquel nous pensons beaucoup en tant que fournisseurs de navigateurs et en tant que participants aux normes, la compatibilité Web. Cela revient tout le temps, vous pensez, Oh, devrions-nous apporter ce changement à CSS ou devrions-nous modifier un peu cela?
Melanie: Et peut-être que cela a beaucoup de sens logique pour le la façon dont les gens construisent aujourd'hui. Cela a beaucoup de sens pour l'ergonomie des développeurs, mais quelqu'un dit, Hé, attendez une seconde, si nous apportons ce changement, ces millions de sites vont exploser de manière inattendue. Il y a juste un exemple sur certains de ces contrôles où les gens appliquent des styles CSS qui n'ont aucun effet aujourd'hui.
Melanie: Donc, si nous disons, d'accord, en fait, nous allons autoriser telle ou telle propriété sur une certaine contrôle, maintenant, certains de ces sites vont faire des choses très funky. Donc, je pense que parce que les contrôles sont impliqués dans ces flux critiques pour la mission, comme vous l'avez en quelque sorte souligné, les gens sont un peu nerveux à l'idée de changer quelque chose d'aussi fondamental pour le Web d'une manière qui soit rétrocompatible et ne cassera rien.
Melanie: Nous devons donc en quelque sorte réfléchir au problème des contrôles de manière additive. Et certains des autres défis ici sont que chaque navigateur a en quelque sorte implémenté ses contrôles sous le capot d'une manière différente. Donc, certains font quelque chose qui est un peu orthogonal au système d'exploitation, certains s'appuient encore assez fortement sur le système d'exploitation, et cela peut changer pour le même navigateur sur différentes plates-formes. Il faut donc en quelque sorte tenir compte de toutes ces choses.
Melanie: Je pense que c'est un problème difficile, mais je ressens le vent du changement ici, tout le monde reconnaît, d'accord, nous devons aller et résoudre ce problème problème, ça va prendre beaucoup de temps, ça va être dur, mais essayons.
Stephanie: Pour ajouter en plus, donc j'ai participé à nos réunions avec Mélanie et le initiative d'interface utilisateur ouverte qui mène en quelque sorte la standardisation des contrôles. Et je ne pense pas que les gens réalisent non plus, comme Melanie l’a dit, que c’est une énorme entreprise. Et il y a des réunions que nous avons qui entrent dans des détails si granulaires sur la façon dont un sélect se comporte, juste à un niveau qui me souffle même un peu à quel point ces problèmes sont spécifiques auxquels nous devons réfléchir. C'est donc une entreprise énorme.
Drew: Il y a eu un effort, n'est-ce pas? Avec HTML5 pour améliorer un peu les choses, et il y avait de nouveaux types pour l'élément d'entrée et il y avait une capacité de validation de base et l'API de validation de contrainte, mais c'était une sorte d'évolution subtile, pas une révolution, était-ce réussi, faites vous pensez?
Melanie: Je pense que cet effort a ajouté des capacités nécessaires à la plate-forme Web, mais je pense qu'il y a un certain sentiment à propos de l'attribut type, peut-être que nous devrions aller d'une manière différente à l'avenir, mais ce type d'attribut fait beaucoup. Vous héritez en quelque sorte de nombreux comportements de la classe d'entrée de base qui ne sont peut-être pas applicables à cet élément particulier. Peut-être y a-t-il une manière différente de faire cela et d'avoir plus d'éléments spécifiques spécialement conçus, c'est un peu ce que nous recherchons.
Drew: Je pense à des choses comme la façon dont l'entrée de données fonctionne actuellement avec HTML5 ou Je dis ça marche, ça ne marche pas peut-être. Vous devez en quelque sorte regarder simplement le fait que chaque site crée des contrôles de calendrier personnalisés plutôt que d'utiliser ce sélecteur de date natif, car le sélecteur de date ne répond pas à ce besoin. Et vous devez en quelque sorte conclure que certaines de ces méthodes natives ont tout simplement échoué.
Melanie: Exact. Et le sélecteur de dates est tellement intéressant, car j'estime qu'il y a deux catégories de raisons pour lesquelles les gens les recréent. Dans certains cas, c'est comme si, oui, je veux qu'il fonctionne essentiellement comme un sélecteur de dates, mais j'ai vraiment besoin que ce soit un style qui corresponde à ma propre marque. Et ce contrôle du sélecteur de jour fait beaucoup de travail, il se passe beaucoup de choses dans ce tout petit monde pop-up.
Melanie: Et puis de l'autre côté de la maison, vous avez une compagnie aérienne sites Web, non? Là où ils essaient de faire quelque chose de différent, qui ne peut pas être pris en charge par ce contrôle de sélection de date où vous regardez vraiment la plage, je peux traverser différents mois et ce genre de choses. Alors oui, celui-là est délicat, il y a beaucoup de cas d'utilisation différents regroupés dans un contrôle.
Drew: Comment pouvons-nous éviter que de nouvelles sortes de retombent dans ce piège à l'avenir? C’est évidemment un exemple de quelque chose qui était trop complexe, évidemment très complexe à mettre en œuvre, car certains moteurs de rendu n’ont même pas essayé et d’autres qui ont essayé ont eu des niveaux de succès variables. Comment éviter de tomber dans ce piège à l'avenir? Pouvons-nous?
Melanie: Ouais. C'est une question intéressante, donc je pense que certaines des propositions que nous avons faites autour des commandes personnalisables visent à offrir aux gens un peu plus de flexibilité avec les commandes intégrées, plus de contrôle sur celles-ci, si vous voulez.
Melanie: Donc, décomposez simplement notre proposition de base ici, nous imaginons qu'il existe deux solutions différentes pour les contrôles personnalisables, et la bonne solution dépend du cas d'utilisation et du contrôle particulier et de sa complexité. Donc, les différents types de seaux sont, nous voulons avoir une sorte de structure interne normalisée pour les contrôles, ainsi nommés parties essentiellement. Et nous pouvons créer des pseudo éléments qui peuvent cibler des parties spécifiques.
Melanie: Donc, Greg Whitworth de Salesforce a en fait une proposition selon laquelle il se déplace autour d'un pseudo élément pour la case à cocher et les indicateurs radio. ce genre de mise en ligne dans ce seau. Ensuite, nous examinons également les emplacements de nom, alors disons que vous êtes un développeur Web, le contrôle de base fonctionne principalement pour vous, mais vous voulez juste remplacer un petit morceau du contrôle.
Melanie: Alors peut-être le bouton que vous faites partie d'une sélection, par exemple. Vous pouvez simplement remplacer ce nom par un emplacement. Et puis si vous voulez vraiment devenir vraiment personnalisé, vous pouvez en fait remplacer complètement le contrôle domino d'ombre par la méthode ajoutée ci-jointe.
Melanie: Et donc l'idée ici est que le développeur aurait le contrôle sur la vue de le contrôle, et ils s'appuieraient toujours sur le code du contrôleur provenant de la plate-forme Web pour connecter en quelque sorte les choses entre le modèle, donc certains points de données dans le contrôle et la vue, afin qu'ils n'aient pas à faire ce sous-jacent
Melanie: Donc, ce sont le genre de stratégies que nous avons dans la mesure où nous pouvons tirer parti de ce qui a déjà été fait mais vraiment le personnaliser à votre cas d'utilisation.
Drew: C'est donc en quelque sorte contourner ce problème, car de nombreux contrôles ne sont qu'une sorte de boîte noire insérée dans la page et vous ne pouvez rien faire grand-chose avec. Éléments remplacés, est-ce la bonne terminologie?
Melanie: Oui.
Drew: Oui. Donc, avec CSS ou avec JavaScript, il n'y a aucun moyen de cibler des bits à l'intérieur, ce n'est qu'une boîte et vous ne pouvez pas y entrer. Donc, l'idée que vous décrivez ici est de structurer les contrôles afin qu'ils ressemblent beaucoup plus à quelque chose que nous pourrions construire nous-mêmes, avec différents niveaux de conteneurs et d'éléments, de sorte que chacun de ces bits individuels puisse être ciblé.
Drew: Et puis certains d'entre eux pourraient être nommés, et ainsi vous pourriez garder le contrôle de base mais échanger les emplacements. Donc, si vous aviez un contrôle de téléchargement de fichiers, vous pourriez peut-être échanger le bouton avec un bouton de votre choix, mais gardez la fonctionnalité générale implémentée par la plate-forme Web, est-ce que je comprends bien?
Melanie: Ouais, c'est tout à fait correct, ouais. Nous voulons faciliter l'accès direct à ce contrôle et prendre en quelque sorte les morceaux dont vous avez besoin et mettre à jour les morceaux dont vous avez également besoin.
Drew: Oui, cela semble vraiment excitant. Mais pour jouer l'avocat du diable comme c'est parfois mon travail, avons-nous vraiment besoin de contrôles HTML? Et je pense qu'au nombre de formulaires soumis avec JavaScript à l'aide de l'API fetch, vous pouvez collecter des données et faire une demande de publication ou autre. Et vous pouvez prendre n'importe quel élément et activer le contenu modifiable et permettre à l'utilisateur de taper du texte ou quoi que ce soit. Avons-nous besoin de contrôles de formulaire natifs ou devrions-nous simplement devenir voyous et tout construire nous-mêmes?
Melanie: Pardonnez-moi, cela porte beaucoup sur l'accessibilité, c'est comme "ahhh!", Espérons que ce cri ne sonne pas trop horrible sur le micro ici, mais. Je pense que je suis un grand fan du web sémantique, non? Et avoir des choses qui sont vraiment conçues pour leur objectif. Encore une fois, il y a beaucoup de choses que vous devez faire pour que les personnes qui utilisent des technologies d'assistance, par exemple, sachent vraiment avec quoi elles interagissent et que leurs technologies d'assistantes sachent comment entrer leurs actions et leurs données dans ce contrôle comme
Melanie: Et donc, la clarté sur les éléments avec lesquels vous travaillez diminue vraiment si vous jetez simplement un contenu modifiable sur tout. Et puis, j'ai l'impression que JavaScript est en train de dévorer le monde et c'est ici que je commence à devenir nerveux à l'idée de me lancer dans un territoire controversé et de dire simplement le mot JavaScript et les gens sont, quoi? Sortez de la menuiserie.
Melanie: Mais les gens peuvent juste dire, eh bien, JavaScript dans leur navigateur ou contenu peut être en quelque sorte ingéré dans d'autres environnements. Et donc je pense toujours qu'il est très important de travailler avec HTML, de travailler de manière déclarative, de ne pas nécessairement dépendre de JavaScript pour tout, de fournir une expérience progressivement améliorée, donc.
Drew: Je pense que lorsque vous regardez la différence entre la façon dont les différents contrôles sont rendus sur une page Web de bureau, par rapport à l'expérience dans un navigateur mobile, pensez à quelque chose comme un contrôle de sélection, l'interface est complètement différente sur un appareil mobile, n'est-ce pas? Ce n’est pas seulement ce que les développeurs ont créé avec les divs et le CSS sur la page, le navigateur prend complètement le dessus et vous offre une expérience différente.
Drew: C'est plus approprié pour l'appareil en question. Je pense donc qu’il s’agit là d’un aperçu de la situation difficile à laquelle sont confrontés ceux qui utilisent des technologies d’assistance lorsqu'ils se heurtent à des éléments totalement personnalisés et non basés sur de véritables éléments HTML solides.
Melanie: Exact. Et c'est délicat si vous êtes une personne qui interagit avec le même contrôle de base d'un site à l'autre, mais vous devez aimer réapprendre à utiliser ce contrôle, car ce site Web a décidé d'utiliser les touches fléchées pour parcourir ces éléments. Et ce site a décidé d'utiliser les touches de tabulation ou la touche de tabulation. Et c'est comme, allez, c'est une telle surcharge cognitive pour les gens qui essaient juste de vivre leur journée.
Drew: Certainement, il y a énormément de choses à penser lorsque vous devenez voyou, n'est-ce pas ? En termes d'accessibilité, d'utilisation du clavier, de concentration, toutes ces sortes de choses qui ajoutent vraiment énormément de code à quelque chose qui pourrait être assez simple et vous pourriez simplement mettre les bons éléments et continuer votre journée.
Drew : C'est une véritable frustration pour nous, développeurs, d'essayer de styliser les éléments du formulaire pour les faire fonctionner comme nous le souhaitons. Et j'ai le sentiment que presque tous les concepteurs et développeurs voudraient avoir de meilleurs contrôles natifs. Est-ce quelque chose que vous avez vu dans votre propre recherche sur la communauté des développeurs Stephanie?
Stephanie: Donc, oui, nous l'avons vu dans la communauté des développeurs. Donc, il y a environ un an et demi, Greg Whitworth, qui travaille chez Salesforce et dirige l'initiative de l'interface utilisateur ouverte, a mené une enquête sur Twitter auprès d'environ 1400 personnes interrogées pour savoir si ce problème de contrôle était … Ou je suis désolé, Je suppose que c'était il y a deux ans et demi que 2020 était flou.
Melanie: À ce moment-là.
Stephanie: Ouais. Et il essayait d'approfondir pour voir si cette zone de contrôle était quelque chose dans lequel l'équipe de la plate-forme Web devrait investir. Et la principale raison pour laquelle les développeurs créent leurs propres contrôles ou les reconstruit à partir de zéro était qu'ils ne pouvaient pas changer suffisamment l'apparence. , Je pense que c'était à peu près comme un tiers des développeurs. Et puis, je pense à un autre tiers dit, à cause des incohérences du navigateur et je pense que vous pouvez supposer que cela a probablement à voir avec les parents aussi. Donc, c'est beaucoup d'heures de développement passées à reconstruire ces choses juste pour changer l'apparence.
Stephanie: Et donc Greg a en quelque sorte identifié que, oui, c'était un point douloureux et étant le PM que je suis, je voulait en quelque sorte découvrir à quel point c'était un problème pour les développeurs. J'ai donc fait mon propre type de recherche impromptue sur les gorilles sur Twitter et j'ai demandé aux gens, à quel point est-ce douloureux pour vous? Et j'ai eu environ 250 réponses à ce tweet.
Stephanie: Et j'avais demandé, que feriez-vous plutôt que de styliser un menu de sélection? Et les réponses allaient de je préfère mâcher du verre ou faire bouillir mes orteils dans la lave plutôt que de tenter de styliser un élément de sélection natif à… Je préfère avoir à créer le site et à le rendre compatible avec IE6. C'est donc un énorme problème pour les développeurs. C'est donc un thème assez cohérent que les développeurs ne sont pas satisfaits de ce qui est là. Donc,
Drew: Il y a eu un peu d'efforts de la part des différents navigateurs pour avoir un peu de rafraîchissement de la conception de certains contrôles de formulaire et essayer de retirer une partie de l'opinion de la conception. Nous avons beaucoup de sortes de dégradés et de choses en cours, n'est-ce pas, de toutes sortes, ce qui, je suppose, est la principale raison pour laquelle les gens veulent les styliser en premier lieu. Pour essayer d'obtenir un look un peu plus neutre qui ne soit pas en contradiction avec le design de leur site. Était-ce quelque chose dans lequel cet avantage était impliqué? Je sais que cela s'est produit dans Chrome, était-il alimenté par le chrome ou était-ce simplement Chrome, ou comment cela a-t-il fonctionné?
Melanie: Je pense que c'est en fait un excellent exemple d'une partie de la collaboration intersociétés nous avons pu le faire depuis le passage au chrome. Donc, en fait, du côté de Microsoft Edge, nous tous les PM sur la plate-forme examinons simplement, d'accord, voici toutes les fonctionnalités que nous avons dans notre navigateur actuel basé sur HTML de bord. Quelle est la situation actuelle dans le domaine du chrome?
Melanie: À l'époque, je travaillais sur l'accessibilité, donc cela ressemble à une collaboration avec chrome pour apporter un support pour l'automatisation de l'interface utilisateur, cette API d'accessibilité au chrome, forcer les couleurs, Windows support de contraste élevé, support pour d'autres paramètres du système, mais plus dans les champs de contrôle, l'équipe regardait en quelque sorte, à quoi ressemblent nos contrôles aujourd'hui, quelles sont nos exigences? Quelle est la situation dans le chrome?
Melanie: Donc, pour le navigateur Microsoft Edge, nous fonctionnons dans de nombreux contextes où il y a des capacités tactiles, donc il y a beaucoup de PC qui ont des écrans tactiles, par exemple. Et donc, la capacité tactile est vraiment importante pour nos contrôles de formulaire, ils doivent bien fonctionner pour un pointeur plus grand, qui est votre doigt.
Melanie: Et nous avons ce genre de système de conception fluide, donc nous étions juste le sentiment qu'il y avait des moyens de pousser un peu plus les commandes pour les aligner sur notre esthétique, nos exigences tactiles, nos exigences d'accessibilité, ce genre de choses. Et cela a finalement fonctionné parfaitement parce que nous avons parlé aux gens de Google et ils ont dit, oui, nous aimerions en quelque sorte mettre à jour, actualiser les commandes et les rendre plus modernes.
Melanie: C'était donc une collaboration très étroite entre les entreprises pour aboutir à quelque chose qui fonctionne pour notre esthétique, leur esthétique, l'esthétique d'autres navigateurs qui s'appuient également sur le chrome. Trouvez quelque chose qui constitue un bon compromis là-bas, puis il sera extensible. Donc oui, beaucoup de collaboration, elle est toujours en cours en fait, nous travaillons simplement sur l'actualisation des commandes pour Android, par exemple, donc, beaucoup de choses intéressantes à faire.
Drew: Donc, en quelque sorte regarder plus loin qu'un rafraîchissement de la conception. Y a-t-il des plans pour de nouveaux composants natifs à venir?
Melanie: Oh, ouais. C'est drôle que vous demandiez, car nous venons de publier un explicatif l'autre jour, pour un nouvel élément pop-up qui me passionne beaucoup. J'avais donc en quelque sorte mentionné que nous avions proposé quelques capacités différentes pour des contrôles personnalisables. Nous avons envoyé une intention de prototyper dans le projet chrome avec une sélection personnalisable, les ITP comme ils les appellent sont juste un peu comme, Hé, je vais jouer autour de la base de code, un peu comme pousser mes idées, voir si elles sont comme vraiment faisable dans la mise en œuvre. Et ce genre de situation se produit parallèlement à certains efforts de standardisation.
Melanie: Nous avons donc déposé un ITP pour la sélection personnalisable, mais une partie de ce dont nous avions besoin, nous parlons d'atteindre le dôme d'ombre, pour accéder au contrôle, nous avions besoin de quelque chose qui fonctionnait très bien pour la partie contextuelle de la zone de liste du contrôle de sélection. Et nous avons également en quelque sorte parlé à certains de nos partenaires dans différents cadres de conception et avons constaté qu'il y avait un besoin plus généralisé d'une fenêtre contextuelle pouvant être rendue sur la couche supérieure, de manière cohérente, elle peut se détacher de tout type de boîtes de délimitation.
Melanie: Nous constatons que la plupart du temps, les développeurs sont un peu comme du bourrage, ils sont comme des pop-ups divvy dans le bas du corps, parce qu'ils essaient de contourner ces problèmes de rendu , en particulier parce qu'ils ne peuvent pas contrôler directement tout le contexte dans lequel leurs composants apparaissent, car il existe une bibliothèque de composants. Donc, nous avons en quelque sorte examiné certains de ces problèmes et avons proposé une proposition contextuelle.
Melanie: Et c'est pour tout type d'interface utilisateur de couche supérieure qui apparaît et a des comportements de rejet légers . Ainsi, l'élément doit se fermer en cas de fuite ou de perte de concentration, des choses comme ça. Et il est vraiment conçu pour une interface utilisateur transitoire, non? Donc, vous ne pouvez avoir qu'un seul pop-up disponible à la fois, à moins qu'il y ait une chaîne d'ascendance, vous pouvez avoir des popups à l'intérieur des popups et il y a différents cas d'utilisation pour cela.
Melanie: Alors oui, c'est vraiment un début proposition, nous en sommes vraiment ravis. Mais nous aimerions recevoir les commentaires de la communauté, nous les avons publiés sur le repo Microsoft Edge Explications. Nous recevons tellement de bonnes questions, ce qui est vraiment excitant pour moi de voir des gens engagés avec l'idée et de vraiment pousser les détails et de nous regarder, fournisseurs de navigateurs, pour faire les choses correctement. Alors, super excité à ce sujet, s'il vous plaît vérifier et dites-nous ce que vous en pensez.
Drew: Et à l'étape actuelle, j'ai vu l'explication, qui est un document qui décrit tout. Est-ce là l’état de cela, il n’ya aucune sorte d’expériences et de codes avec lesquels jouer. C'est plus conceptuel, et si nous faisions ce genre d'étape, n'est-ce pas?
Melanie: C'est conceptuel, mais nous avons aussi un prototype d'intention déposé sur celui-là également. C'est donc quelque chose que deux de nos proches collaborateurs et Google nous aident, en quelque sorte à bricoler le code en ce moment, donc c'est assez excitant de simplement valider nos idées alors que nous faisons une proposition à la communauté au sens large.
Drew: C'est vraiment excitant, je viens littéralement de travailler sur un projet au travail qui est une fenêtre contextuelle vraiment clé dans notre interface produit. Et la quantité de travail nécessaire pour s'assurer que les pièges se concentrent correctement et, comme vous le disiez, permettons-nous à quelqu'un d'interagir avec un onglet ou avec des touches fléchées, ou tous les petits détails de l'interaction impliqués dans cela , en s'assurant qu'il apparaît aux écrivains qui indexent au-dessus de toutes les choses devant lesquelles il devrait se trouver, que se passe-t-il si quelqu'un fait défiler puis touche le bas du rouleau?
Drew: Toutes ces sortes de minuscules , de minuscules bits subtils d'interaction qui sont… ils ne sont pas individuellement, ils ne sont pas difficiles à coder, mais la somme d'entre eux représente beaucoup de travail et la possibilité que des bogues se faufilent et améliorent complètement le problème d'utilisation pour certains segments de votre public. Avoir cette chose aussi courante implémentée potentiellement dans le cadre de la plate-forme Web, ça va être un gain de temps énorme pour tout le monde, n'est-ce pas?
Melanie: Je suis tellement contente d'entendre ça, que serait un bon gain de temps pour vous, parce que oui, c'est exactement ce à quoi je pense, c'est comme, oh, d'accord, c'est 20 minutes ici, 30 minutes là-bas, mais multipliez cela par chaque développeur qui doit le faire , puis peut-être que vous manquez quelque chose et que vous obtenez un ticket très contrarié dans votre canal de commentaires. So.
Drew: So is the idea that then something like a popup would be a building block for then a customized select control where it would be the options sort of section?
Melanie: Yes, absolutely. That’s one of the cases where we kind of imagine this showing up and it’s worth mentioning that the pop-up control that we’re kind of putting forward is meant to be a base that you can build on top of, because there’s many different types of pop-up UI and your use case might differ a little bit from your neighbor next to you.
Melanie: But it’s worth mentioning we think that there are some classes of top layer UI that actually could warrant their own additional element to pop up, because the paradigms there are a little bit different from the popup that we’re proposing. And it’s a very well-trodden path, a lot of people are rebuilding this control.
Melanie: But we’re trying to find the right balance here between pushing the platform forward and not wanting to flood it with new elements either.
Drew: Yeah. I mean, that’s an important point, isn’t it? Because we sort of want to be confident that the things that are being added to the platform are an evergreen requirement and not just a current interaction fad. I mean, if you sort of think back to five years ago where every website had an enormous carousel on it, we could have at that point decided, oh right, the web platform needs an enormous carousel control built into it.
Drew: Could have built that, and then once something’s in the platform, it stays forever, right? Basically we don’t take things out, they’ve got to keep working forever. And if people then aren’t using them, then it just becomes technical debt. So is there a way we can safeguard against that to make sure that these things are evergreen and not just a fad?
Melanie: There’s a lot of different stakeholders in web standards and I think a lot of these things happen naturally, there do tend to be pretty strong headwinds against adding a new element, because there is this fear of making the wrong choices and having the big forever or capturing something that’s a fleeting sort of problem.
Melanie: So I think what’s key here is to look at the problems that have been around for the longest time, right? And just listen to the various different stakeholders and what they have to say about the proposal that you’ve made and make sure that we have the best insights from everybody in the industry, all working together towards the best solution.
Stephanie: So, thinking of new elements and sort of what would be put into the platform. So Chrome, I believe is working on a toggle switch element. I believe there’s a prototype up for that, but that’s an element that they have in the works, which is one of those elements that sort of makes sense, that is something that’s sort of fundamental that gets used across so many websites that just, again, that makes sense that there should be a native element for that.
Drew: That’s exciting to hear as well, because the work in sort of progressively enhancing a checkbox, for example, to become a toggle switch is… Yeah, yeah, it’s something that’s best avoided if you can. But a toggle switch as an interface device makes a lot of sense for a lot of cases of turning something on or off and being a yes, no choice. So having that sort of thing as a fundamental part of the web platform would be terrific.
Drew: When we think about all the existing controls that are out there that potentially have problems, can they be fixed? I mean, we can’t throw them away. Well, I guess we could come up with alternatives that new sites could start to use in their place, but can we rescue the current ones? Is there a way that we can keep backwards compatibility and still move them forward?
Melanie: Yeah. So I think that’s an interesting question that it encompasses a broad range, right? I depends on what the issue is, I think, look, browser vendors are not perfect either, we have bugs, we should fix the bugs. So there’s plenty of those items. But again there are some things that are very difficult for compat and just keeping the web working if we just change things underneath people.
Melanie: So for example when we were working through the controls refreshing chromium, some of the designers were like, Oh, what if we make these check boxes in these radius this size? And we’re like, yeah, that’s better for usability, but the problem is they’ve been a certain size on the web forever for everyone and bad things will happen if we change that.
Melanie: So, it’s frustrating a little bit sometimes, because you can imagine a better way of doing something, but you don’t want to break everyone. So I think it depends. That’s probably the eventual answer to every question in web development, isn’t it?
Drew: It depends. I think about things like the select element over the multiple attributes, so you can have not select multiple items in the list. I mean, putting to one side how it looks by default in most browsers, the interaction model for that control is from a different era of computing, isn’t it? So much so that it’s rarely used because a typical web user doesn’t know how to interact with it. Can we address things like that? Is that something that can be fixed?
Melanie: That’s a hard question. I believe there’s a lot of creative people in this space come up with some really interesting ideas. I have to think a little bit about that one, because I agree even as a user that I find that interaction pattern a little bit challenging. So yeah, back to the drawing board I guess.
Drew: So, it depends.
Melanie: Oh man. I’m just going to answer every question that you have from now on with that.
Drew: So, Stephanie mentioned open UI a little bit earlier. What is open UI?
Stephanie: So open UI is an initiative under the YCG, and it is focused on standardizing controls. And so I think not… So controls are standardized, but it’s only their function. So I think that’s where the root of a lot of this problem comes from is back 25 years ago when the initial controls were introduced into the first HTML 2.0 Specification. Their parts weren’t standardized, it was just this form is supposed to complete this function or serve this purpose and that’s sort of what was standardized.
Stephanie: And so that is sort of the problem, different browser engines choose to render their controls or build them differently under the hood. And so we can’t give developers access to the different parts, sort of in a compatible way at the moment. And so open UI at its core is sort of driving that initiative to define, so first select, what is a select comprised of? What are the different parts? And drive that work forward.
Stephanie: And so Greg Whitworth is again driving a lot of that work, but it’s an open initiative, so we’ve had quite a few people from the developer community join in on that and are sort of helping to drive that work with Greg and the rest of the team. And so, yeah, at it’s core it’s just trying to find the different parts of the controls and sort of pave the way to get those into an actual standard specification and eventually into browsers.
Drew: So, this was the internal structure that Melanie was talking about just before of being able to identify different slots and then putting names to the different parts that make up a control so they can be targeted and replaced or styled or whatever, but it’s just making sure that that is consistent across different browsers, standardizing it, working out where they are or should be, and then hopefully that gets implemented and we can start using controls with a lot more precision than we can currently.
Stephanie: Yeah, that’s exactly right.
Drew: And does open UI attempt to address how controls will look?
Melanie: No, that’s outside of the purview of the open UI efforts. So, we’re looking at, if we have an MVC model of controls looking at the M and the C I suppose you can say.
Stephanie: Just to add to that too, sort of standardizing the way they look, like Melanie said, yeah, that’s not really… When you have different companies like Microsoft or the different browsers, Firefox and Chrome and Microsoft, they are different companies with different design languages as well. So even our default styles I think are going to be reflective of the company or the browser. So.
Drew: I think that’s ideal from sort of a development point of view, because if the browser vendors have to implement this new spec, it’s been agreed on, they’re going to implement it. And the first thing they going want do is to use that to style the control themselves to match the language of the browser.
Drew: And any inflexibility or potential problems that might appear down the road for end users are going to appear for the browser developers as they’re implementing that themselves. So it’s a good initial stress test. Can this select box be made to look like it should in edge, made like it should in Chrome and so on.
Melanie: Yeah, I also feel like I’m trying to get all the different browser engines to agree on a style or even just standards group on what this thing should look like would be a… I think that conversation would go on forever, quite frankly.
Drew: And could potentially stifle innovation as well. I think it’s positive that different competing products can compete on the user experience level by bringing their own innovation and hopefully what the specifications will enable us to do is to do that in a way that isn’t going to impact an end user… end web developer who wants to then restyle those controls themselves. It gives everybody the flexibility that they need.
Melanie: Right. Yeah. It’s even just a challenge, even as we’re talking about standardizing the internals of a control, you have to do it in such a way that it could be implemented in a different fashion, or there’s a little bit of room for variety or as you said innovation. So, that is a challenging requirement of this work stream.
Drew: What’s the process of sort of between getting these early ideas? Things that the open UI project might write up. How do we get those to start to become part of a future web specification and then ultimately implemented in browsers. Are we looking at decades of work here? Or, I mean, it’s not going to be a month, is it?
Melanie: I wish. Just kidding, actually, it’s so funny, I was thinking about this the other day, it’s like, as a web developer, your timescale is so much shorter than web standards, it’s like, I would love to have this for this thing that I’m trying to push out next month or whatever, but you actually probably should want us to take a while, because that means that will be very considered in the decisions that the web standards industry makes.
Melanie: So, yeah, I think this is going to be… We’re looking at a couple of years at least to fully go through all the controls. As far as process goes, that’s sort of a little bit of a moving target, the folks who are involved in open UI, some of the chairs and a couple other folks are actually working on a process document for how this sort of works.
Melanie: But I think generally speaking, you can think as open UI as sort of the connective tissue that tells the full story between efforts that might land and what we do, so the living document for HTML or the CSS working group over at the W3C. The open UI group can tell the full story in between these desperate pieces. And then can also provide a maturation ground. So when you’re trying to get work into the HTML spec, that group goes off of PRs, rather than sitting in a room and chatting about it.
Melanie: And so the expectation is the PR should be fairly mature when you make it against that spec. So, perhaps open UI can be the place where you gain that maturity in the idea.
Drew: And the ideas can be thrashed out before they’re then taken onto the next level of being proposed to the actual specification.
Melanie: Yeah, absolutely.
Drew: So how can people get involved in this process to offer feedback? I mean, for example, I know personally I’ve done a lot of content management system development work and that they tend to be very form heavy. And so my individual perspective might be different from somebody who builds online games, and the web has to work for all those use cases. So I guess it’s really important to get lots of points of view into the process. How would people get involved with that?
Stephanie: There’s a couple of different ways that you can go, or you can either get involved in open UI, again, that group is… If you go to open-ui.org I believe, you can find out how to get involved in that and sort of actually be involved in the process of defining control structures and helping us do research, or you could provide feedback on the explainers, so there’s the customizing controls, CY explainer on GitHub under the Microsoft edge explainers repo.
Stephanie: And then also the pop-up explainer that Melanie mentioned. You can open issues or you can just tweet at me or Melanie and there’s some good… I’ve seen some good conversations with the pop-up explainer I think, Melanie’s Twitter feed, so.
Drew: So getting involved in the web platform could be as simple as sending a tweet?
Stephanie: Yes.
Drew: Amazing.
Melanie: We’re all human beings over here so.
Drew: What a time to be alive. So I’ve been learning about the future of HTML controls today. What have you both been learning about lately?
Stephanie: Well, so I’m writing a new talk for dual screen devices and talking about design considerations and I tend to go into the history of, like I’ve done with HTML controls. I like to dive into history and see where we’ve come from and so I’ve been looking at foldable devices and how… There were prototypes in 2008 of actual foldable devices, and so I’ve been diving into that and learning about that for my next talk.
Melanie: I feel like I have too many plates spinning at all times to start learning new things, but in addition to this controls work I’m also focused on the pricey space in the web platform, so very different space actually, which is very interesting. But learning a lot right now about identity and federated off use cases as that relates to privacy.
Melanie: So that’s been super interesting, collaborating with folks who have a lot of depth of expertise there. And outside of the web platform, I don’t know, always doing different stuff. You mentioned doing three arts, I’m taking, Devon Ko’s 3D for Designers course that’s been fun. Learning a little bit of Japanese. So working through my Kanji lessons. So doing fiber arts and then I was like, what if I learn Python? I’m like, no, no, no. I can’t add more things to this list.
Drew: Rein it in. That’s amazing. If you dear listener would like to hear more from our guests, you can find Stephanie on Twitter where she’s @seaotta with an A and her personal site is stephaniestimac.com.
Drew: Melanie can be found on Twitter where she’s @soMelanieSaid, and her website is Melanie-richards.com. And the open UI course is open-ui.org. Thank you both for joining me today. Do you have any parting words?
Stephanie: I have to say I’m excited about the controls work that Melanie is leading, and there’s just some good stuff coming in. So I hope developers get involved and are as excited as we are.
Melanie: Major plus one to that. Thanks so much for having us on today.
(il)Source link