Applications Web progressives (PWA) est un moyen fantastique de transformer les applications Web en expériences natives et autonomes. Ils comblent l’écart entre les sites Web et les applications natives, mais cette transformation peut être susceptible d’introduire des défis de conception qui nécessitent une considération réfléchie.
Nous définissons nos PWA avec un fichier manifeste. Dans notre manifeste de PWA, nous pouvons sélectionner parmi une collection de modes d’affichage, chacun offrant différents niveaux de visibilité de l’interface du navigateur:
fullscreen: Cache toute l’interface utilisateur du navigateur, en utilisant tout l’affichage.standalone: Ressemble à une application native, masquant les contrôles du navigateur mais en conservant l’interface utilisateur du système.minimal-ui: Montre un minimum d’éléments d’interface utilisateur du navigateur.browser: Expérience de navigateur Web standard avec l’interface du navigateur complet.
Souvent, nous voulons que nos PWA se sentent comme des applications plutôt qu’un site Web dans un navigateur, nous avons donc défini le membre de l’affichage Manifest à l’une des options qui masque l’interface du navigateur, telles que fullscreen ou standalone. C’est fantastique pour aider à faire en sorte que nos applications se sentent plus à l’aise, mais cela peut introduire certains problèmes que nous ne considérerions généralement pas lors de la création du Web.
Il est facile d’oublier la quantité de fonctionnalités que le navigateur nous offre. Des choses comme les boutons avant / arrière, la possibilité de rafraîchir une page, de rechercher dans les pages ou même de manipuler, de partager ou de copier une URL d’une page sont toutes les fonctionnalités fournies par le navigateur auxquelles les utilisateurs peuvent perdre l’accès lorsque l’interface utilisateur du navigateur est masquée. Il y a aussi le cas des choses que nous affichons sur des sites Web qui ne se traduisent pas nécessairement par des expériences d’applications.
Imaginez un utilisateur profondément dans un formulaire sans bouton de retour, essayant de partager une page de produit sans la possibilité de copier une URL, ou de frapper un bug sans bouton de rafraîchissement pour les renflouer!
Heureusement, nous avons de nombreuses façons de personnaliser le Web.
Nous utilisons les requêtes multimédias tout le temps lors de l’écriture de CSS. Qu’il s’agisse de changer de styles pour imprimer ou de définir des points d’arrêt pour une conception réactive, ils sont monnaie courante dans la boîte à outils du développeur Web. Chacun des modes d’affichage discutés précédemment peut être utilisé comme requête multimédia pour modifier l’apparence des documents en fonction.
Requêtes médiatiques telles que @media (min-width: 1000px) ont tendance à tirer le meilleur parti pour définir des points d’arrêt en fonction de la taille de la fenêtre, mais ils sont capables de bien plus. Ils peuvent gérer styles d’impressionorientation de l’appareil, préférences de contraste et une tonne entière de plus. Dans notre cas, nous sommes intéressés par le display-mode Fonction médiatique.
Les requêtes de support en mode d’affichage correspondent au mode d’affichage actuel.
Note: Bien que nous puissions définir des modes d’affichage dans notre manifeste, le mode d’affichage réel peut différer en fonction de la prise en charge du navigateur.
Ces requêtes multimédias font directement référence au mode actuel:
@media (display-mode: standalone)ne s’appliquera qu’aux pages définies en mode autonome.@media (display-mode: fullscreen)s’applique au mode plein écran. Il convient de noter que cela s’applique également lors de l’utilisation de l’API plein écran.@media (display-mode: minimal-ui)s’applique au mode d’interface utilisateur minimal.@media (display-mode: browser)s’applique au mode de navigateur standard.
Il vaut également la peine de garder un œil sur le window-controls-overlay et tabbed Modes d’affichage. Au moment de la rédaction du moment de la rédaction, ces deux modes d’affichage sont expérimentaux et peuvent être utilisés avec display_override. display-override est un membre du manifeste de notre PWA, comme displaymais offre quelques options et puissance supplémentaires.
display a une chaîne de secours prédéterminée (fullscreen -> standalone -> minimal-ui -> browser) que nous ne pouvons pas changer, mais display-override Permet de définir un ordre de secours de notre choix, comme les suivants:
"display_override": ["fullscreen", "minimal-ui"]
window-controls-overlay ne peut s’appliquer qu’aux PWA fonctionnant sur un système d’exploitation de bureau. Il fait prendre la fenêtre entière, avec les boutons de commande de fenêtre apparaissant comme une superposition. Entre-temps, tabbed est pertinent lorsqu’il existe plusieurs applications dans une seule fenêtre.
En plus de cela, il y a aussi le picture-in-picture Mode d’affichage qui s’applique aux modes d’image (vous l’avez deviné).
Nous utilisons ces requêtes multimédias exactement comme nous le ferions toute autre requête multimédia. Pour montrer un élément avec la classe .pwa-only Lorsque le mode d’affichage est autonome, nous pourrions le faire:
.pwa-only {
display: none;
}
@media (display-mode: standalone) {
.pwa-only {
display: block;
}
}
Si nous voulions afficher l’élément lorsque le mode d’affichage est autonome ou minimal-uinous pourrions faire ceci:
@media (display-mode: standalone), (display-mode: minimal-ui) {
.pwa-only {
display: block;
}
}
Aussi génial que cela soit, parfois CSS ne suffit pas. Dans ces cas, nous pouvons également référencer le mode d’affichage et effectuer les ajustements nécessaires avec JavaScript:
const isStandalone = window.matchMedia("(display-mode: standalone)").matches;
// Listen for display mode changes
window.matchMedia("(display-mode: standalone)").addEventListener("change", (e) => {
if (e.matches) {
// App is now in standalone mode
console.log("Running as PWA");
}
});
Applications pratiques
Maintenant que nous savons comment apporter des modifications à l’affichage selon que les utilisateurs utilisent notre application Web en tant que PWA ou dans un navigateur, nous pouvons voir comment nous pourrions utiliser ces compétences nouvellement apprises.
Adaptation du contenu pour les utilisateurs de PWA
Les utilisateurs qui ont une application installée en tant que PWA sont déjà convertis, vous pouvez donc modifier votre application pour atténuer le discours marketing et se concentrer sur l’expérience utilisateur. Étant donné que ces utilisateurs ont démontré l’engagement en installant votre application, ils n’ont probablement pas besoin de contenu promotionnel ou d’invites d’installation.
Afficher plus d’options et de fonctionnalités
Vous devrez peut-être exposer directement plus de choses en mode PWA, car les gens ne pourront pas accéder aux paramètres du navigateur aussi facilement lorsque l’interface utilisateur du navigateur est cachée. Des fonctionnalités telles que le changement de dimensionnement des polices, la commutation entre le mode clair et l’obscurité, les signets, le partage, les onglets, etc., peuvent avoir besoin d’une alternative intégrée.
Fonctionnalités adaptées à la plate-forme
Il y a des fonctionnalités que vous ne voudrez peut-être pas sur votre application Web car elles se sentent déplacées, mais que vous voudrez peut-être sur votre PWA. Un bon exemple est la barre de navigation inférieure, qui est courante dans les applications mobiles natives grâce à la plus facile à accoucher qu’il fournit, mais rare sur les sites Web.
Les gens impriment parfois des sites Web, mais ils impriment très rarement des applications. Déterminez si des fonctionnalités comme les boutons d’impression doivent être masqués en mode PWA.
Installer des invites
Une gêne commune est une invite pour installer un site en tant que PWA apparaissant lorsque l’utilisateur a déjà installé le site. Idéalement, le navigateur fournira une invite d’installation à part si notre PWA est configurée correctement, mais pas tous les navigateurs, et il peut être capricieux. MDN a un guide fantastique sur Création d’un bouton personnalisé pour déclencher l’installation d’un PWAmais cela pourrait ne pas répondre à nos besoins.
Nous pouvons améliorer les choses en cachant des invites d’installation avec notre requête multimédia ou en détectant le mode d’affichage actuel avec JavaScript et en renonçant à la déclenchement des fenêtres contextuelles en premier lieu.
Nous pourrions même configurer cela en tant que classe d’utilité réutilisable afin que tout ce que nous ne voulons pas être affiché lorsque l’application est installée en PWA peut être cachée avec facilité.
/* Utility class to hide elements in PWA mode */
.hide-in-pwa {
display: block;
}
@media (display-mode: standalone), (display-mode: minimal-ui) {
.hide-in-pwa {
display: none !important;
}
}
Puis dans votre HTML:
<div class="install-prompt hide-in-pwa">
<button>Install Our App</button>
</div>
<div class="browser-notice hide-in-pwa">
<p>For the best experience, install this as an app!</p>
</div>
Nous pourrions également faire le contraire et créer une classe de services publics pour que les éléments ne montrent que dans un PWA, comme nous l’avons discuté plus tôt.
Utilisation stratégique de la portée et du démarrage de l’URL
Une autre façon de masquer le contenu de votre site est de définir le scope et start_url propriétés. Ceux-ci n’utilisent pas les requêtes multimédias comme nous l’avons discuté, mais doivent être considérées comme des moyens de présenter différents contenus selon que le site est installé en tant que PWA.
Voici un exemple de manifeste en utilisant ces propriétés:
{ "name": "Example PWA","scope": "/dashboard/","start_url": "/dashboard/index.html","display": "standalone", "icons": [ { "src": "icon.png", "sizes": "192x192", "type": "image/png" } ] }
scope Ici définit le niveau supérieur de la PWA. Lorsque les utilisateurs quittent la portée de votre PWA, ils auront toujours une interface de type application mais auront accès aux éléments de l’interface utilisateur du navigateur. Cela peut être utile si vous avez certaines parties de votre application que vous souhaitez toujours faire partie de la PWA mais qui ne sont pas nécessairement optimisées ou qui font les considérations nécessaires.
start_url Définit l’URL qu’un utilisateur sera présenté lorsqu’il ouvrira l’application. Ceci est utile si, par exemple, votre application dispose de contenu marketing à example.com et un tableau de bord à example.com/dashboard/index.html. Il est probable que les personnes qui ont installé l’application en tant que PWA n’ont pas besoin du contenu marketing, vous pouvez donc définir le start_url à /dashboard/index.html L’application commence donc sur cette page lorsqu’ils ouvrent le PWA.
Transitions améliorées
Voir les transitions Peut se sentir inconnu, hors de propos et un peu voyant sur le Web, mais sont une caractéristique commune des applications natives. Nous pouvons configurer les transitions de vue PWA uniquement en enveloppe le CSS pertinent de manière appropriée:
@media (display-mode: standalone) {
@view-transition {
navigation: auto;
}
}
Si vous vraiment Ambitieux, vous pouvez également modifier la conception d’un site entièrement pour s’adapter plus étroitement aux systèmes de conception natifs lors de l’exécution en tant que PWA en jumelant une vérification du mode d’affichage avec une vérification de l’appareil et / ou du navigateur utilisé selon les besoins.
Prise en charge et tests du navigateur
La prise en charge du navigateur pour les requêtes de média en mode d’affichage est bon et étendu. Cependant, il convient de noter que Firefox n’a pas de support PWAet Firefox pour Android affiche uniquement les PWA browser Mode, vous devez donc faire les considérations nécessaires. Heureusement, amélioration progressive est de notre côté. Si nous avons affaire à un navigateur manquant de soutien aux PWA ou à ces requêtes médiatiques, nous serons traités dégradation gracieuse.
Le test des PWA peut être difficile car chaque appareil et navigateur les gère différemment. Chaque mode d’affichage se comporte légèrement différemment dans chaque combinaison de navigateur et de système d’exploitation.
Malheureusement, je n’ai pas de solution miracle à vous offrir à ce sujet. Les navigateurs n’ont pas un moyen pratique de simuler les modes d’affichage pour les tests, vous devrez donc tester votre PWA sur différents appareils, navigateurs et systèmes d’exploitation pour vous assurer que tout fonctionne partout, comme il le devrait.
Résumer
L’utilisation d’un PWA est une expérience fondamentalement différente de l’utilisation d’une application Web dans le navigateur, donc des considérations doivent être faites. display-mode Les requêtes multimédias fournissent un moyen puissant de créer des applications Web progressives vraiment adaptatives qui répondent intelligemment à leur contexte d’installation et d’affichage. En tirant parti de ces requêtes, nous pouvons faire ce qui suit:
- Masquer les invites d’installation redondantes Pour les utilisateurs qui ont déjà installé l’application,
- Fournir des aides à la navigation appropriées Lorsque vous rendez les contrôles du navigateur indisponibles,
- Contenu et fonctionnalité d’adaptation Pour faire correspondre les attentes des utilisateurs dans différents contextes,
- Créer des expériences plus-natives qui respectent les conventions de plate-forme, et
- Améliorer progressivement l’expérience pour les utilisateurs engagés.
Alors que les PWA continuent de mûrir, les implémentations réfléchies et la couture deviendront de plus en plus importants pour créer des expériences d’applications vraiment convaincantes sur le Web. Si vous avez des démangeaisons pour encore plus d’informations et des conseils et astuces PWA, consultez Ankita Masand «Guide étendu des applications Web progressives».
Lire plus approfondie sur SmashingMag
(GG, YK)
Source link