Conception d'une interface logicielle pour différentes tailles d'écran

Question

De nos jours, nous avons des écrans comme 1920x1200 et 1680x1050 en utilisation courante et certains utilisent même une résolution de 2560x1600 alors que certains anciens systèmes reposent encore sur une résolution de 800x600. J'écris un logiciel qui a l'air bien sur un 1680x1050, mais trop petit sur un 1920x1200 et trop grand sur un 1024x768. Avez-vous des suggestions sur la façon de concevoir une application pour différentes tailles d'écran? Les choses étaient beaucoup plus simples auparavant quand nous avions peu de différences dans les résolutions, mais maintenant il semble qu'il n'y a pas de bonne façon de gérer cela.

Je sais que cette question concerne plus la conception/mise en page que la programmation, mais je parie que cela fait plus ou moins partie de la vie des programmeurs, j'ai donc fait ce post ici.

Answer 1

Les applications doivent s'ajuster automatiquement à une variété de tailles de fenêtre et de tailles d'écran. Vous ne devez pas supposer que les utilisateurs voudront toujours exécuter votre application en plein écran. Même si tous vos utilisateurs ont des écrans époustouflants, ils peuvent vouloir montrer plusieurs fenêtres côte à côte dans certains cas. La conception (si ce n'est pas le développement) de plusieurs tailles de fenêtres est assez facile lorsque les données sont présentées dans un format liste/tableau ou graphique (ce dernier incluant des cartes, des diagrammes et la plupart des applications WYSIWYG). Le volet qui affiche la table ou le graphique doit être redimensionné lorsque la fenêtre est redimensionnée. Généralement, vous incluez des barres de défilement horizontales et verticales si nécessaire pour permettre à l'utilisateur de parcourir les données dans la taille de panneau qui existe actuellement. Le redimensionnement du panneau avec des redimensionnements de fenêtre implique généralement que toutes les données sont accessibles par les barres de défilement. Cela ne fonctionne pas bien pour diviser les données en pages (par exemple, comme la manière dont les résultats de recherche Google sont divisés).

Il est parfaitement acceptable d'avoir un défilement horizontal pour une table (contrairement à une page Web dominée par la prose) tant que la première colonne identifiant les lignes reste visible lorsque l'utilisateur fait défiler horizontalement. De même, les en-têtes de colonne doivent rester visibles lorsque l'utilisateur fait défiler verticalement. Pour les graphiques, changer la taille de la fenêtre ne devrait généralement pas changer le niveau de zoom. Au lieu de cela, affichez plus de données lorsque vous effectuez un zoom arrière et moins lorsque vous effectuez un zoom avant, tout en offrant une fonction de zoom distincte. Pour les données présentées sous forme de formulaire, avec des champs et des étiquettes pour un seul enregistrement exécuté dans le volet, il est impossible de gérer plusieurs tailles de fenêtre, et vous devez choisir une taille de fenêtre à concevoir pour . Pour la facilité d'utilisation, vous devez concevoir de sorte qu'à la taille de texte standard, tous les champs soient visibles sans défilement lorsque la taille de la fenêtre correspond à la résolution d'écran la plus basse que vous êtes susceptible de rencontrer. Utilisez des onglets ou d'autres contrôles similaires pour adapter tous les champs requis dans cet espace. En règle générale, cela implique une taille de 1024x768, en supposant que vos utilisateurs peuvent utiliser votre application sur un ordinateur portable. Il peut être acceptable d'avoir une disposition de formulaire qui nécessite un défilement vertical à des résolutions plus petites (comme c'est commun sur les applications Web), mais les utilisateurs ne devraient jamais avoir à faire défiler horizontalement pour les cas typiques. Ainsi, dans votre cas, vous pouvez concevoir pour 1024x1050 si la plupart de vos utilisateurs utilisent des ordinateurs de bureau et n'utilisent qu'occasionnellement des ordinateurs portables. Testez que les utilisateurs se rendent compte qu'ils doivent faire défiler lorsqu'ils utilisent une basse résolution avant de procéder. Si vous vous attendez à ce que les utilisateurs utilisent la fenêtre régulièrement lors de l'affichage d'autres fenêtres (par exemple, cela ressemble plus à une boîte de dialogue de propriétés), cela peut imposer des limites supplémentaires à la taille de la fenêtre.Avec une disposition de formulaire, la taille du texte ou les espaces entre les champs ne doivent pas changer lorsque la fenêtre est redimensionnée (bien que permettre à l'utilisateur d'augmenter explicitement la taille du texte soit une bonne idée). Redimensionner plus grand que la taille conçue pour devrait simplement ajouter des marges vierges à droite et en bas. En d'autres termes, il n'y a vraiment pas beaucoup de point à redimensionner pour la mise en forme de formulaire. C'est bon. Au moins certains de vos utilisateurs feront bon usage de l'espace d'écran inutilisé pour autre chose (par exemple, une autre fenêtre ou application). Les utilisateurs disposant d'un grand écran avec de grands écrans peuvent ouvrir deux instances de la même fenêtre côte à côte et chaque instance affiche un onglet différent afin qu'ils puissent surveiller autant que possible en même temps.

Si vous redimensionnez plus petit que la taille prévue pour une mise en forme de formulaire, les barres de défilement doivent apparaître et donner accès aux champs qui ne sont plus visibles. Cette dernière situation devrait être un cas limite si vous avez choisi la résolution d'écran la plus basse que vous êtes susceptible de rencontrer.

Answer 2

En général, vous concevez pour la résolution d'écran la plus basse que vous vous attendez à rencontrer.

Vous avez raison car il existe une multitude de résolutions d'écran raisonnables.

Vous avez la possibilité de concevoir votre interface utilisateur pour des résolutions d'écran multiples, et de faire en sorte que votre application choisisse la disposition appropriée en fonction de la résolution d'écran réelle.