Pour les appareils mobiles, la résolution est en fait grande, seule la taille de l'écran est petite. basé sur cela:
- Pour la conception de sites Web , visons-nous la résolution d'écran (par exemple 1920x1080)?
- Et pour les applications mobiles . visons-nous la taille de l'écran?
website-design
css
html
mobile
responsive-design
Engineeroholic
la source
la source
Réponses:
La conception réactive n'est basée ni sur la résolution ni sur la taille de l'écran. Au lieu de cela, la conception réactive est basée sur le contenu et la façon dont il est fabriqué, ce qui lui permet de s'adapter à toutes les tailles et résolutions.
La façon dont vous envisagez la conception réactive est incorrecte. Je suppose que vous venez d'un arrière-plan de conception d'impression plus conventionnel, oui? Concevoir pour le Web est beaucoup plus gratuit. Les sites Web réactifs n'ont souvent pas les mêmes points d'arrêt conventionnels ni les tailles / résolutions spécifiques pour lesquelles ils sont faits, car le Web permet plus que cela - il permet d'atteindre toutes les tailles d'écran. En tant que tel, vous pouvez concevoir en utilisant toutes les tailles qui conviennent à ce que vous concevez tant qu'elles sont raisonnables.
Cela étant dit, la meilleure pratique consiste à concevoir de manière mobile d'abord , ce qui devrait vraiment être nommé mobile-most-important . Cela vous oblige à vous concentrer sur le contenu le plus important et possible et vous permet ensuite d'en ajouter plus pour les écrans plus grands au lieu de vous forcer à commencer avec plus sur les grands écrans, puis à supprimer des éléments lors de la conception pour les plus petits. Vous pouvez en savoir plus à ce sujet dans mon amorce de conception réactive .
Mais nous devons également concevoir de manière à permettre la réactivité. La meilleure pratique est un exemple vivant, que ce soit sous forme de prototype ou dans un programme de wireframing, pas un document statique comme un PSD. En ce qui concerne le côté développeur, nous devrions utiliser des unités réactives et structurer notre code d'une manière logique.
Cela étant dit, vous devez mettre les choses en termes de pixels, c'est-à-dire de résolution, pas de taille d'écran.
la source
Grande question en effet!
Ma longue réponse déroutante: aucune et les deux
Juste quelques réflexions ici commentant un peu les contradictions auxquelles nous sommes confrontés aujourd'hui.
La technologie n'est plus ce qu'elle devrait être depuis des siècles.
Nous devrions tous concevoir sur la base d' unités réelles (ou de la taille percée) , avec un certain degré de flexibilité et de liberté pour laisser l'utilisateur faire des ajustements supplémentaires.
Mais pour connaître les mesures réelles, nous avons besoin des deux informations. Dimensions physiques et résolution de l'appareil = densité de pixels.
Mais il s'avère qu'il y a quelques années à peine, les appareils à écran commencent à déclarer la densité de pixels. Et certains ne le déclarent pas au serveur, faites juste beaucoup de publicité à ce sujet. (Aka Ipad, Iphone)
La résolution d'affichage peut être détectée par le système d'exploitation car il est impératif d'envoyer un signal en conséquence, mais pour la taille réelle de l'écran, nous avons besoin d'une énorme base de données de chaque modèle. Pas bon.
Cela nous laisse avec cette résolution d'écran que ce sont des informations que nous pouvons connaître.
Mais il est totalement différent de concevoir pour un grand moniteur FullHD que la même résolution sur un appareil mobile. Les deux 1920x1080. Aie.
Un cas particulier est que sur les projecteurs, car nous n'avons aucune idée de la distance de projection et de la distance des téléspectateurs.
Une solution partielle sont les requêtes multimédias et les éléments vectoriels, etc.
Une réponse courte
Pour le webdesign: au moins jusqu'à ce que nous trouvions quelque chose de mieux.
Conception fluide (pourcentages) et écoulement naturel, sections bien définies.
1920 de large
avec une requête des médias probablement à 1280
et / ou à 1024
probablement à 720
et 480.
avec détection d'appareil pour une prise en charge supplémentaire.
Pour les applications natives mobiles
Comme il est très spécifique, suivez simplement les lignes directrices de la marque en ce qui concerne l'interface utilisateur et les icônes.
Édité.
Pourquoi choisir une petite résolution d'écran sur un appareil mobile FullHD?
Un smartphone a une vraie résolution de FullHD mais normalement il déclare une petite résolution au serveur et au navigateur. Vous pouvez tester cette recherche sur Google https://www.google.com/search?q=what+is+my+screen+resolution pour que les requêtes multimédias fonctionnent.
la source
Tout d'abord, merci à tous pour les réponses et les précieuses lignes directrices, cela a certainement aidé!
Permettez-moi d'ajouter ma conclusion:
Pratiquement, le ciblage de la résolution d'écran mobile n'est pas un bon UX, la résolution est trop élevée pour le petit écran, les polices seront trop petites pour être lues, les icônes seront trop petites pour cliquer, etc.
Il est donc préférable de faire la conception en fonction de la taille réelle de la fenêtre! De cette façon, il est basé sur ce qu'un utilisateur peut voir et ressentir.
Pour y parvenir dans la vraie vie, nous devons ajouter une balise META de largeur de fenêtre d'affichage à l'intérieur
<head>des documents HTML:Cela indique au navigateur de rendre la page avec une largeur égale à la largeur de l'écran afin de s'assurer que la largeur de la page HTML est égale à la largeur de l'écran en termes de pixels. Le développement peut alors être facilement planifié avec des requêtes multimédias ciblant différentes tailles de fenêtres mobiles (qui sont un peu proches les unes des autres), et produira des éléments plus visuellement clairs.
S'il vous plait corrigez moi si je me trompe.
Mettre à jour:
Sur la base de mon humble expérience, je suggère les étapes ci-dessous pour un meilleur développement de site Web réactif:
1- Utilisez la méta du port de vue (voir en haut), cela augmentera également le classement de la page Web dans les résultats de recherche mobile selon Google. http://googlewebmastercentral.blogspot.com/2015/04/faqs-april-21st-mobile-friendly.html
Après les tests, il semble que l'ajout d'une méta de port de vue à lui seul donnera des notes à votre site Web dans les outils de test mobiles https://developers.google.com/speed/pagespeed/insights/
2- Vous voudrez peut-être envisager d'appliquer l'approche mobile d'abord, il est toujours plus facile d'aller plus grand que plus petit (dépend de la complexité de votre site Web)
3- Appliquer un système hybride réactif, un mélange entre adaptatif (fluide) et réactif (css media-queries), pour y parvenir:
Utilisez un pourcentage pour la largeur et les marges / rembourrages horizontaux. (les marges verticales peuvent avoir une taille de pixel fixe si vous le souhaitez. le défilement n'est plus un problème)
Utilisez em pour les polices, de cette façon lorsque vous modifiez la taille de la police pour le corps (ou html) dans les requêtes multimédias, tous les éléments CSS s'adapteront à cette taille, l'utilisation de px en fera un cauchemar car vous devez choisir chaque classe CSS et changer sa taille de police.
Faites flotter les div à gauche pour qu'elles s'alignent correctement sur l'espace disponible (ou à droite si votre conception l'exige).
4- Définissez les points d'arrêt , utilisez un outil de test réactif pour cela. J'utilise la vue de conception sensible à Firefox, réduisez simplement la largeur jusqu'à ce que vous atteigniez le point où le site Web devient défectueux (par exemple 500 px), c'est un point de rupture le marquez.
Appliquez les nouvelles règles CSS à l'intérieur de la requête média pour ce point d'arrêt (500 px),
5- N'oubliez pas de préserver la qualité et la clarté du site Web! si les éléments deviennent flous et trop proches les uns des autres, augmentez la largeur des éléments pour occuper la largeur du conteneur et faites-les empiler verticalement,
et n'oubliez pas de donner une nouvelle taille de police pour le corps afin que tous les sous-éléments héritent d'une police plus grande et deviennent plus lisibles.
6- Répétez le test réactif et définissez votre deuxième point de rupture, Très probablement, vous n'obtiendrez pas beaucoup de points de rupture car nous utilisons la conception fluide ici et c'est là que l'utilisation du pourcentage sera rentable!
J'ai travaillé sur un grand site Web avec des éléments de conception lourds auparavant et cela ne nécessitait que 2 requêtes multimédias :)
J'espère que cela vous aidera
la source
La manière dont une page réactive est redistribuée est basée sur les dimensions de la fenêtre d' affichage (et non de l'écran) en pixels virtuels (et non en pixels réels).
Sur un bureau traditionnel où 1 pixel virtuel = 1 pixel réel, si votre navigateur est défini sur une largeur de 1000 pixels, la page sera redistribuée pour s'adapter à cela.
Sur un iPhone 6, où 1 pixel virtuel (Apple appelle ces points ) = 3 pixels réels, la largeur du navigateur est la largeur de l'écran et le contenu refluerait pour s'adapter à la largeur de 417 pixels (même s'il s'agit en fait de 1242 pixels réels)
C'est donc un peu bizarre, car avec les exemples ci-dessus, l'appareil avec le moins de pixels réels est en fait considéré comme une fenêtre plus large dans une mise en page réactive.
la source