Стратегии обработки нескольких разрешений экранов и соотношений сторон в веб-разработке
Назад в день, 800 x 600 был разрешением экрана для разработки для - и возможно 640 x 480. Затем вперед прибыл 1024 x 768, и т.д., и т.д., и т.д.
Но затем это ухудшается: теперь у нас нет только различных разрешений, но также и отношений другого аспекта.
Какие стратегии люди используют для размещения сегодняшнего когда-либо расширяющегося диапазона размеров экрана и соотношений сторон?
(BTW - я только думал о ноутбуке / настольные аппаратные средства, но конечно существуют смартфоны и планшеты для рассмотрения также.)
5 ответов
Я знаю, что это может быть несколько спорным мнением, но я все равно скажу: Не делайте
Не проектируйте для разных размеров экрана или соотношений сторон. Конечно, есть несколько исключений: тяжелые веб-приложения, такие как клиенты веб-почты, определенно могут работать с большей площадью экрана и, вероятно, достаточно гибки, чтобы в любом случае работать с большим диапазоном размеров экрана. Мобильные версии указанного веб-сайта с более гибким дизайном, позволяющим приспособиться к невероятному спектру размеров мобильных экранов, также могут помочь сайтам с большим количеством мобильных устройств. Однако, если вы придерживаетесь так называемого «настольного веба», то, я думаю, мы можем сказать, что в 95% случаев есть более важные вещи, о которых нужно заботиться, чем размеры экрана, разрешение и соотношение сторон.
Давайте рассмотрим самое простое.Я действительно не понимаю, почему вас так заботит соотношение сторон — ведь нас уже не волнует так ерунда «ниже сгиба», не так ли? Сеть — это вертикальная среда — прокрутка всегда будет на веб-сайтах. Иметь все выше волшебной линии в 600 пикселей просто глупо.
Далее, разрешение/размер экрана. Опять же, мне трудно защищаться.
Пользователи с большими экранами обычно не увеличивают окна браузера до максимума, потому что считают, что большинство веб-сайтов не используют их преимущества. В то время как сеть приспосабливается к пользователю, пользователь также приспосабливается к сети. Хотя вы можете возразить, что это проблема курицы и яйца, факт остается фактом: веб-сайты обычно разрабатываются с учетом наименьшего общего знаменателя. Я не защищаю эту позицию, а скорее указываю на нее как на текущую преобладающую тенденцию в отрасли.
Некоторые вещи просто не будут работать при слишком высоком или слишком низком разрешении. Например, существует небольшой диапазон значений ширины, которые позволяют людям удобно читать с экрана. Еще немного, и количество движения глаз к следующей строке будет раздражать. Слишком низко, и текст будет казаться тесным. Тот факт, что веб был спроектирован так, чтобы быть нейтральным к разрешению, означает, что, как это ни парадоксально, было сделано не так много возможностей для тех, кто хочет создавать гибкие макеты. min-height и max-height помогут, конечно, но чем шире диапазон, тем больше трудностей вы столкнетесь. Такие вещи, как потерянные элементы, смещенные изображения, фоны, которые заканчиваются и т. д.неизбежны для действительно гибких сайтов, созданных с использованием современных технологий.
Поэтому я считаю, что самый простой способ справиться с несколькими разрешениями — это вообще игнорировать их — с сегодняшними технологиями в любом случае не так много вариантов — и проектировать с наименьшим общим знаменателем.
Это распространенный, но сложный вопрос, для которого, к сожалению, нет единственного оптимального решения. Все зависит от того, какой у вас контент. Вы можете использовать гибкий макет или разрабатывать свой сайт по-разному для разных разрешений (см. http://www.maxdesign.com.au/articles/resolution/ ). Чтобы увидеть пример гибкой конструкции, посмотрите это - http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign
Остерегайтесь настроек высокого разрешения.
Я думаю, что одна из самых не обсуждаемых проблем, с которыми сегодня сталкивается интерфейсная веб-разработка, - это тестирование в системах с высоким разрешением. Все научились тестировать, тестировать и тестировать в разных браузерах, но дизайнеры / разработчики не стали тестировать с разными настройками DPI.
Высокие (или даже низкие, если на то пошло) настройки DPI нарушают дизайн, когда шрифты масштабируются, а изображения - нет (что может случиться), могут привести к тому, что изображения будут выглядеть нечеткими / размытыми, а абсолютно позиционированные объекты могут не отображаться в желаемом местоположение (что было бы разрушительно для меню CSS.) Если ничего другого, протестируйте свои изображения с высоким разрешением DPI и при необходимости повторно визуализируйте их.
Это никогда не было проблемой до недавнего времени с выпуском Windows 7 и людьми, покупающими компьютеры с мониторами с высоким разрешением. Во-первых, в Windows 7 по умолчанию используется 96 точек на дюйм (что отличается от остального компьютерного мира, который использовал 72 точек на дюйм в качестве стандарта. Более того, Windows 7 автоматически настраивает параметры разрешения на дюйм, и я видел людей с разрешением 150% от нормального. (96 точек на дюйм в Windows).
Вот отличная ссылка, по которой этот вопрос обсуждается более подробно: http://webkit.org/blog/55/high-dpi-web-sites/
Отличный крест -браузерный веб-сайт, разработанный с учетом веб-стандартов, является целью, но не забывайте о тестировании DPI.
Ваш сайт не может идеально работать на всех дисплеях. Даже если бы у вас было достаточно часов в день (или, лучше сказать, года/десятилетия) для проектирования каждого возможного дисплея, вам приходилось бы делать это каждый раз, когда выходит новое устройство.
В процессе разработки я до сих пор неукоснительно стараюсь избегать горизонтальной прокрутки, и это не так уж сложно с плавающими элементами div/элементами div переменной ширины.Но помимо этого, мы действительно находимся на перекрестке «для этого есть приложение», где вам нужен специально разработанный дисплей для определенных устройств.
Одна из стратегий, которую я использую, заключается в том, чтобы уменьшить зависимость от одного дисплея — покупателю, вероятно, не нужно видеть всю вашу веб-страницу, чтобы сделать то, за чем он пришел. Вы можете разобрать функциональность на более мелкие/простые веб-страницы, которые лучше масштабируются на устройствах разного размера.
На работе у меня, так сказать, немного больше «мощности» — я могу разрабатывать внутренние веб-приложения, которые «предназначены для работы в… другие конфигурации на свой страх и риск». И это только после того, как менеджеры согласились с тем, что тратить дополнительную неделю на разработку (и даже больше на обновления / будущее обслуживание) только для того, чтобы успокоить одного вегетарианца на другом конце кампуса, который отказывается использовать IE, действительно не стоит затрат. . В таком случае нам нужен другой Тимми, а не более гибкое веб-приложение, которое может хорошо выглядеть в его любимом браузере, отличном от IE.
Ну, стараюсь не затягивать с ответом, вот что я делаю.
(A) Всегда начинайте с наиболее вероятного используемого соотношения/разрешения.
Если ваш среднестатистический Джо собирается работать на современном ноутбуке или настольном компьютере, у него, вероятно, ПО КРАЙНЕЙ МЕРЕ 1024x768 (ссылки: w3schools ]elykinnovation), что дает вам примерно полезную ширину 960 пикселей (вы можете проверить систему 960grid — с тех пор, как я впервые написал это, появилось чертовски много новых фреймворков). Если ваши пользователи с большей вероятностью начнут с мобильного устройства или планшета, подумайте о них в первую очередь. Если это 50%-50%, обычно лучше начать с малого, а затем расти, например. Rock Hammer или Foundation
(B) Макет: плавный или нет?
Если вашему веб-сайту нужна большая ширина, выберите плавный дизайн, начиная с этого разрешения.Будьте осторожны, человеческий глаз не любит читать текст поверх длинных строк, поэтому не злоупотребляйте плавным дизайном; часто допустимо использование 960 пикселей с большими полями. Возможно, вы захотите добавить (javascript) дополнительные боковые меню, если у вас действительно много места. Но спроектируйте свой веб-сайт так, чтобы он работал без JS, насколько это возможно.
(C) Другие разрешения
Наконец-то пришло время проверить, что с наименее используемыми разрешениями все еще приемлемо.
(D) Другие устройства, соотношения и прочее
Не так много вариантов для разных соотношений; это часто означает, что вы работаете на мобильном устройстве, iPad, AAA или аналогичном устройстве.
Мой совет: разрабатывайте специально для этих устройств.
При написании HTML помните о том, что вам понадобится, и помните, что HTML должен быть семантическим, а не дизайнерским. Используйте правильно семантические теги HTML5, если можете.
Избегайте
Используйте фреймворк!
Но вы все равно можете сделать несколько разных дизайнов для самых разных устройств. Вам не нужно делать все отзывчивым /в одном дизайне/.
В зависимости от клиента существует несколько способов обслуживания разных CSS; вы можете сделать это:
- на стороне сервера, проверяя браузер в HTTP-заголовке, исходящем от клиента, либо с вашим веб-сервером, либо с вашей динамической средой сценариев - будь то python/django, php или что-то еще
- javascript ( вы можете легко получить размер окна)
- html — в частности, с некоторыми специфическими устройствами, такими как iphone
Вы можете легко создать общий дизайн для небольших (например,мобильных) устройств, следуя простым правилам: 1. плавная компоновка, способная вписаться в очень маленькую ширину 2. компактные верхние/нижние колонтитулы не занимают слишком много места 3. несколько, четкое содержимое на «страницу» 4. Избегайте эффектов :over, так как они не будут работать на сенсорных устройствах!!!
Если вы хотите пойти дальше, вам нужно проверить настройки отдельных устройств; примером является окно просмотра iphone, см. библиотеку apple ref.
Это просто для начала. Опыт и конкретные потребности будут определять остальное!