Vous tournez votre téléphone pour tester une écran, et l'agencement s'adapte soit de manière propre, soit il se décompose. Le texte se reflowe, les boutons sautent, une fenêtre modale couvre soudainement la mauvaise zone, ou votre lecteur vidéo se comporte exactement comme prévu. Ce petit moment est où orientation paysage cesse d'être un terme de design et devient une décision de produit.
Si vous concevez pour les appareils mobiles, vous avez besoin d'une réponse claire à qu'est-ce qu'une orientation paysage. Pas seulement la définition de classe, mais la version du développeur. Comment cela affecte la disposition, quand supporter la rotation, quand le bloquer et comment le gérer dans les applications web, les applications natives et les Capacitor projets sans créer une expérience utilisateur fragile.
Table des matières
- Comprendre l'orientation paysage
- Portrait vs Paysage : Une Comparaison Fondamentale
- Utilisations courantes dans différents médias
- Gestion de l'orientation sur le Web
- Gestion de l'orientation dans les applications mobiles
- Pratiques de l'expérience utilisateur pour l'orientation de l'écran
Comprendre l'orientation portrait
Les utilisateurs remarquent l'orientation pour la première fois lorsqu'un écran tourne. Les développeurs la remarquent lorsqu'elle brise leur interface.
L'orientation portrait signifie que le cadre est plus haut qu'il est large. C'est l'idée de base. Elle provient de l'art visuel, où les portraits de la tête et du haut du corps d'une personne étaient généralement encadrés verticalement. Cette même idée s'est étendue à la conception de pages, à la photographie et aux interfaces numériques. Une référence utile pour cette histoire plus large est la page d'orientation de Wikipedia.
Pour les constructeurs, la partie importante est que l'orientation portrait n'est pas liée à une taille d'écran, un appareil ou un format de fichier. C'est une règle sur la forme. Si la hauteur est supérieure à la largeur, vous êtes en orientation portrait.
Pourquoi cela compte dans le travail de produit
L'orientation portrait est devenue un choix pratique par défaut pour les appareils mobiles car l'utilisation debout correspond à la façon dont les gens tiennent naturellement les téléphones. Cela affecte la navigation, la portée du pouce, la lecture, la conception de formulaire et la disposition de la navigation.
A un feed, une vue d'article, un écran de paramètres ou un fil de discussion, il est généralement plus naturel de lire dans un cadre vertical. C'est une raison pour laquelle les choix d'orientation sont directement liés aux décisions concernant l'expérience utilisateur des applications mobiles, et pas seulement à la mise en forme visuelle. La règle pratique est de considérer le paysage comme un contexte de mise en page, et pas seulement la position du dispositif.Les débutants dans le développement ont souvent de la difficulté à faire la distinction entre
l'orientation et
la résolution
ou le rapport d'aspect L'orientation est un concept qui concerne la disposition des éléments sur l'écran, tandis que la résolution et le rapport d'aspect se rapportent à la définition de l'écran et à ses dimensions. L'orientation est un élément clé de l'expérience utilisateur des applications mobiles, car elle affecte la façon dont les utilisateurs interagissent avec l'application et la manière dont ils perçoivent l'information. La résolution et le rapport d'aspect sont des concepts liés à la définition de l'écran et à ses dimensions, et ils ne sont pas directement liés à l'orientation. En résumé, l'orientation est un concept qui concerne la disposition des éléments sur l'écran, tandis que la résolution et le rapport d'aspect se rapportent à la définition de l'écran et à ses dimensions.. Ils sont liés, mais ce n'est pas la même chose.
- Orientation signifie laquelle des deux côtés est plus longue.
- Résolution signifie combien de pixels existent dans chaque dimension.
- Rapport d'aspect décrit la relation entre la largeur et la hauteur.
Un tablette en portrait et un téléphone en portrait peuvent avoir des dimensions très différentes, mais ils partagent toujours le même état d'orientation. C'est pourquoi la logique de l'interface utilisateur réactive devrait demander : « Est-ce que la hauteur est supérieure à la largeur ? » avant de demander quoi que ce soit de plus spécifique.
Portrait vs Paysage : Une Comparaison Fondamentale
Une façon simple de penser à cela est à travers la composition. Un portrait peint met l'accent sur une personne ou un autre sujet de grande taille. Un tableau horizontal capture la largeur, le contexte et l'espace environnant. L'UI fonctionne de la même manière.
Dans l'imagerie et la conception d'interface utilisateur, l'orientation portrait est le rectangle où La hauteur dépasse la largeurPar conséquent, les longues arêtes sont verticales. C'est l'inverse de l'orientation horizontale. SLR Lounge’s glossaire La définition technique décrite et pourquoi la forme convient aux sujets hauts et à la structure verticale.
La différence dans une table
| Orientation | Forme | Meilleur ajustement | Effet typique |
|---|---|---|---|
| Portrait | Plus haut que large | Alimentation, formulaires, lecture, sujets hauts | Concentre l'attention verticalement |
| Paysage | Plus large que haut | Vidéos, cartes, tableaux de bord, scènes larges | Montre plus de contexte horizontal |
Cela ressemble à des choses basiques, mais c'est utile lorsque vous faites des compromis dans une revue de produit.
Quels changements pour l'utilisateur
Le paysage réduit généralement l'attention. Il réduit le contenu latéral et encourage un flux de haut en bas. C'est pourquoi les flux de médias sociaux, les pages d'articles, les étapes d'inscription et les interfaces de chat ressentent souvent une sensation plus propre en paysage.
L'orientation horizontale fait le contraire. Elle expose plus de largeur, ce qui aide avec les vues en deux colonnes, les calendriers, les galeries, la lecture de médias, les surfaces chargées en données et les vues immersives. Si votre disposition nécessite une comparaison latérale, ce format horizontal vous donne souvent plus d'espace pour respirer.
Le paysage est généralement sur le contexte. L'horizontale est généralement sur l'attention.
Quels changements pour le développeur
L'erreur la plus grande est de traiter le format plus large comme une version étirée du paysage. Ce n'est pas le cas. L'héritage de l'information doit souvent changer.
Par exemple :
- En mode paysage : une table de bord peut empiler des cartes en une colonne unique.
- En mode paysage : le même tableau de bord peut passer à plusieurs colonnes et révéler des filtres ou des panneaux latéraux.
- En mode paysage : une formulaire de paiement peut donner la priorité à de grands cibles de clic et à un flux clair.
- En mode paysage : ce même écran peut se sentir mal à l'aise si les champs deviennent trop comprimés verticalement.
Les développeurs travaillant sur des layouts mobiles immersifs doivent également réfléchir à la gestion des bords, aux zones de sécurité et au comportement plein écran. Si vous ajustez ces détails, Capacitor configuration d'affichage sans bords fait partie de la même conversation car les changements d'orientation affectent la perception des utilisateurs de l'espace disponible.
Utilisations courantes dans différents médias
La disposition verticale se retrouve dans plus de lieux que les écrans mobiles. Cela compte car le concept n'a pas commencé dans le logiciel, et il ne s'appartient pas uniquement au logiciel.
Photographie et impression
Un portrait professionnel est l'exemple évident. La mise en page verticale convient mieux à la face et au corps d'une personne qu'une large mise en page ne le ferait pas. La même logique s'applique aux photos de mode, aux couvertures de livres, aux affiches et aux couvertures de magazines.
La conception d'impression repose également sur le portrait lorsque l'expérience de lecture doit se dérouler de haut en bas dans une colonne étroite. Cette forme aide l'œil à voyager naturellement vers le bas de la page.
Documents et communication quotidienne
La plupart des rapports, des CV, des lettres et des documents internes sont conçus en portrait. C'est pas parce que le portrait est toujours meilleur. C'est parce que la page verticale fonctionne bien pour la lecture de séquences de paragraphes, de titres, de listes et de signatures.
Si vous avez jamais exporté un PDF et remarqué que une table large devient soudainement illisible, vous avez vu la limite du portrait aussi. Certains contenus sont mieux présentés sous une forme horizontale. La clé est de correspondre la mise en page au structure du contenu.
Produits mobiles et flux d'applications
Dans ces circonstances, le portrait devient le modèle mental par défaut pour beaucoup d'équipes.
Réfléchissez aux écrans que les utilisateurs ouvrent régulièrement :
- Chat apps : les messages s'empilent verticalement.
- Applications sociales : les publications, commentaires et vidéos sont consommés dans un flux en position verticale.
- Applications de commerce : les résultats de recherche et les listes de produits glissent vers le bas.
- Applications bancaires : les soldes, transactions et flux de confirmation sont généralement organisés en sections verticales.
Ces modèles ne sont pas des hasards. Portrait prend en charge l'utilisation d'une main, la navigation par doigt et la réalisation de tâches linéaires.
Une grande partie de l'interface utilisateur mobile ressent intuitivement parce que l'interface suppose un appareil en position verticale avant de supposer quoi que ce soit d'autre.
Cela ne signifie pas que chaque écran doit rester en position portrait. Les lecteurs multimédia, les cartes, les grands graphiques et les workflows basés sur la caméra bénéficient souvent d'une mise en page plus large. Mais pour les flux de tâches quotidiens, le portrait est généralement où les utilisateurs commencent.
Gérer l'orientation sur le Web
Un bug web commun semble petit au début. Votre application s'affiche proprement dans un viewport orienté vers le haut, puis l'utilisateur tourne le dispositif et le graphique déborde, le sidebar apparaît au mauvais breakpoint, ou la touche clavier recouvre le bouton de soumission. L'orientation sur le web est vraiment liée à l'état. La forme du viewport a changé, et votre interface doit répondre de manière prévisible.
Pour les développeurs, cela signifie séparer deux tâches. Le CSS gère les changements de mise en page. Le JavaScript gère les changements de comportement. Si vous emballez le même projet pour mobile plus tard, ce niveau web compte toujours. En utilisant Capacitor pour convertir une application web en application mobile ce n'empêche pas la nécessité d'une bonne gestion de l'orientation web. Cela rend cette base encore plus importante.
La plateforme vous donne deux outils principaux. L'orientation d'écran API expose le type et les événements de changement d'orientation, et le Manifeste de l'application web permet à une application installée de déclarer un mode préféré orienté vers le haut tel que portrait, portrait-primary, ou portrait-secondary. MDN documente ces valeurs de manifeste dans sa Référence de l'orientation du manifeste de l'application web.
Utilisez CSS lorsque la mise en page doit s'adapter
Commencez par CSS. C'est la méthode la moins chère et la plus fiable pour répondre lorsque la largeur et la hauteur échangent de rôle.
/* Default portrait-friendly layout */
.page {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.sidebar {
display: none;
}
@media (orientation: landscape) {
.page {
grid-template-columns: 280px 1fr;
}
.sidebar {
display: block;
}
}Cela fonctionne comme une amélioration progressive de la forme de l'écran. Commencez par la mise en page étroite et orientée vers le haut par défaut. Ajoutez ensuite de l'espace pour l'interface secondaire uniquement lorsque le viewport devient plus large.
Un certain nombre de pratiques économisent du temps plus tard :
- Commencez par votre mode principal : Si les gens utilisent principalement l'application en position verticale, faites que cela soit la disposition de base.
- Évitez les hauteurs fixes : La rotation d'un appareil peut réduire rapidement l'espace vertical utilisable, surtout lorsque l'interface de navigateur ou un clavier virtuel est visible.
- Testez les états d'interaction réels : Les formulaires, les en-têtes collés et les feuilles de bas de page échouent souvent lors de la rotation, pas dans les captures d'écran statiques.
Utilisez JavaScript lorsque le comportement doit réagir
Le CSS peut réorganiser les boîtes. Il ne peut pas décider quand reconstruire un graphique ou réinitialiser un gestionnaire de gestes.
Utilisez JavaScript lorsque les changements d'orientation affectent l'interface utilisateur étatuelle.
function logOrientation() {
const type = screen.orientation?.type;
console.log('Current orientation:', type);
}
logOrientation();
screen.orientation?.addEventListener('change', () => {
logOrientation();
const isPortrait = window.innerHeight > window.innerWidth;
if (isPortrait) {
document.body.classList.remove('wide-mode');
} else {
document.body.classList.add('wide-mode');
}
});Ce modèle mental est simple. Si la rotation change la présentation des données ou la logique d'interaction, JavaScript doit répondre. Si la rotation ne change que l'espacement ou la disposition, CSS doit s'en charger.
Une règle pratique aide les équipes junior à éviter une grande complexité. N'utilisez pas JavaScript pour imposer des décisions de disposition que CSS gère bien déjà.
Définissez une orientation préférée pour les PWAs
Si votre PWA est conçue principalement pour une utilisation debout, déclarez-le dans le manifeste.
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}C'est une préférence, et non une substitution pour un design réactif. Cela aide le navigateur à comprendre comment l'application installée devrait s'ouvrir et se comporter dans les contextes pris en charge.
Vous pouvez également demander un verrouillage d'orientation en temps de exécution lorsque le navigateur le permet :
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}Utilisez cela avec prudence. Une bonne règle est de verrouiller uniquement lorsque la rotation briserait la tâche elle-même, comme un flux de capture guidée ou une écran avec des exigences d'alignement physique strictes. Dans la plupart des autres cas, adapter l'interface est le choix de conception mieux, car cela respecte à la fois l'appareil et l'utilisateur.
Gestion de l'orientation dans les applications mobiles
Les applications mobiles peuvent faire plus qu'une fenêtre de navigateur. Elles peuvent déclarer une orientation d'écran par défaut au niveau de l'application, puis changer le comportement pour une seule écran lorsque la tâche le demande. Cette contrôle supplémentaire est utile, mais cela crée également une erreur courante. Les équipes restreignent la rotation trop largement, et une application simple commence à se sentir rigide.
A good mental model helps here. App-wide settings are your default policy. Screen-level code is the exception layer. Use the policy for broad intent, and use the exception only where a rotating device would interfere with the job the user is trying to finish.
Contrôle de la plateforme native
Sur Android, l'orientation est souvent définie dans AndroidManifest.xml pour une activité :
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />Cette fonctionnalité fonctionne comme un drapeau de configuration au niveau supérieur. Elle est simple, prévisible et facile à appliquer sur toute l'activité. Le compromis est la portée. Si seule une écran nécessite le mode portrait, appliquer cette règle globalement est généralement trop brutal.
Sur iOS, les orientations prises en charge sont définies dans Xcode à travers les paramètres de cible et les métadonnées de l'application. Vous pouvez définir ce que l'application permet généralement, puis affiner le comportement dans les contrôleurs de vue spécifiques lorsque l'écran a des exigences plus strictes.
Cette distinction est importante pour les équipes cross-plateformes. La configuration native répond à la question « Qu'est-ce que cette application devrait permettre généralement ? » La runtime code répond à la question « Qu'est-ce que cette écran devrait faire en ce moment ? »
Le contrôle programmé dans les applications Capacitor
Si vous construisez avec Capacitor, le contrôle dynamique est généralement réservé à code, près de la route ou de la vue qui en a besoin. Un écran de connexion peut être plus facile à utiliser en portrait. Un écran de médias ou une flux de caméra peut nécessiter de permettre la rotation en fonction de la façon dont l'appareil est tenu.
Un plugin garde cette logique lisible et évite les tuyauteries natives personnalisées. Le Capacitor plugin d'orientation d'écran pour les applications Capacitor vous permet de lire l'orientation actuelle, d'appliquer une restriction pour un mode spécifique comme le portrait, et de supprimer cette restriction lorsque l'utilisateur revient à un écran flexible.
import { ScreenOrientation } from '@capgo/capacitor-screen-orientation';
async function lockLoginScreen() {
await ScreenOrientation.lock({ orientation: 'portrait' });
}
async function unlockForMedia() {
await ScreenOrientation.unlock();
}
async function checkCurrentOrientation() {
const result = await ScreenOrientation.orientation();
console.log(result);
}Le modèle est simple. Appliquez la restriction lorsque l'écran devient actif. Supprimez-la lorsque l'écran n'est plus actif. Dans une application basée sur un routeur, cela signifie souvent lier les changements d'orientation aux appels de cycle de vie de page plutôt que de disperser les appels dans des composants aléatoires.
Choisissez les restrictions spécifiques à l'écran avec soin
Utilisez un mode droit fixe lorsque la rotation perturberait l'entrée, l'alignement ou l'attention de l'utilisateur.
Exemples courants incluent :
- Écrans d'authentification : les entrées restent stables pendant que l'utilisateur tape.
- Étapes de paiement et de confirmation : moins de changements de disposition pendant les tâches à haute attention.
- Flux de travail en kiosque ou guidé : l'interface nécessite une présentation cohérente.
Laissez le dispositif tourner librement lorsque la largeur supplémentaire ou une prise de main différente aide clairement à la tâche.
Les exemples typiques incluent la lecture multimédia, les cartes, les jeux, les vues de la caméra et les écrans de données dense.
Une règle utile pour les équipes juniors est simple. Si le changement de direction du dispositif n'aurait que pour effet de modifier les espacements, laissez le système de disposition s'en charger. Si le changement de direction du dispositif changerait la façon dont la tâche fonctionne, alors l'orientation à l'écran code peut être justifiée.
Capgo est mentionné ici pour une raison pratique. Dans les projets Capacitor , le contrôle de l'orientation est l'une de ces fonctionnalités de plateforme qui commence comme un détail UI mineur et devient rapidement un comportement de l'application. Traitez-le comme un comportement. Gardez la disposition flexible par défaut, appliquez des restrictions avec parcimonie et supprimez-les dès que l'écran n'en a plus besoin.
Meilleures pratiques UX pour l'orientation de l'écran
La gestion de l'orientation est une décision UX en premier lieu et une décision technique en second lieu. Le code est généralement simple. La partie difficile est de choisir un comportement qui sent naturel.
Un petit checklist aide :
- Concevez pour le contexte dominant : si la plupart des utilisateurs commencent debout, faites du portrait la version la plus forte de l'interface.
- Supportez un mode de visualisation plus large où cela ajoute de la valeur : ne bloquez pas la rotation sur les écrans qui bénéficient d'une largeur supplémentaire.
- Verrouillez uniquement avec une raison claire : un formulaire, un achat, ou un flux sécurisé peut justifier cela. Une page de contenu ne le fera généralement pas.
- Préservez l'état pendant la rotation : les utilisateurs ne devraient pas perdre leur saisie, leur position de roulage ou leurs onglets sélectionnés.
- Testez les deux orientations sur des appareils réels : les simulateurs manquent de transitions maladroites, de chevauchement de clavier et de problèmes de zone de sécurité.
Pour des décisions de mise en page plus larges, la guidance de l'UI et de l'UX cross-plateforme pour les applications Capacitor s'adapte bien à la test de l'orientation car la même écran doit souvent ressentir comme natif sur différentes tailles d'appareil et des conventions de plateforme.
La principale prise de conscience est simple. Si vous demandez ce qu'est une orientation portrait, la réponse n'est pas juste « vertical ». C'est une règle de cadre, un état de mise en page et une attente de l'utilisateur. Les bonnes applications traitent ainsi.
Si vous expédiez des applications Capacitor et avez besoin d'un comportement d'orientation contrôlé aux côtés de fixes rapides après la mise en production, Capgo est une option à considérer. Elle fournit des mises à jour en temps réel pour les applications CapacitorJS et Electron, et elle maintient également des plugins pour les capacités d'appareil telles que l'orientation de l'écran, ce qui peut aider lorsque vous avez besoin de bloquer ou d'activer des vues spécifiques sans revoir tout votre processus de mise en production.
