Адаптивный дизайн: теперь дело уже не в размере экрана

http://speckyboy.com/2013/09/11/responsive-design-is-not-about-screen-sizes-any-more/
  • Перевод
В марте 2012 года Гай Подъярны (Guy Podjarny) провел тест, в ходе которого сравнивалась продуктивность работы сотен новых адаптивных сайтов на устройствах с четырьмя различными разрешениями экранов. Получившиеся результаты были весьма разочаровывающими.

После двух лет подъема адаптивного дизайна, когда любой дизайнер и разработчик, которых только можно представить, запрыгнули в этот поезд, тест производительности на различных разрешениях потряс сами основы адаптивной теории.

Гай доказал, что практически все адаптивные сайты имеют избыточный вес.

«Мы сделали интернет по своему подобию … Тяжелым», – Джейсон Григсби.

Но, что еще важнее, мобильные пользователи точно так же, как и пользователи настольных ПК, подвергались килобайтной перегрузке.

Представители веб-сообщества по-разному отреагировали на эти данные. Некоторые заявляли, что адаптивный дизайн не является решением на все случаи жизни и, возможно, на данный момент недостаточно развит, чтобы справляться со всеми вызовами, с которыми сегодня сталкиваются дизайнеры.

К счастью, в веб-сообществе всегда найдутся люди, которые схватят быка за рога и перевернут ситуацию с ног на голову.

Современные веб-гуру вроде Брэда Фроста (Brad Frost), Люка Вроблевски (Luke Wroblewski) и Кристиана Хейльманна (Christian Heilmann) увидели возможности там, где другие ужасались кризису, и смогли обернуть проблему на пользу сообществу.

«Если ваш сайт весит 15MB, то это не HTML5. Это глупость», – Кристиан Хейльманн.

Без обид, но производительность в вебе традиционно достигалась за счет вещей, которые лучше всего описываются жаргонизмами разработчиков. Термины вроде GZIP-инг, уродование (uglifying), минификация, DNS Lookup, файл-конкатенация… Все эти непонятные слова выносят дизайнеров за скобки.

Умные люди в сообществе, однако, все же поняли, что корни проблемы лежат глубже. На самом деле абсолютно не важно, оптимизируете вы или сжимаете изображение в ультра высоком разрешении, если при этом вы просто скрываете его от мобильного пользователя, который все равно должен скачать это изображение, чтобы его посмотреть.

«Хорошая производительность – это хороший дизайн», – Брэд Фрост.

Чтобы создавать по-настоящему легкие сайты, не стоит заморачиваться на производительности, вместо этого, производительность должна рассматриваться как один из элементов дизайна.

Производительность так же важна, как и любая другая вещь. Сайты, которые добиваются хороших результатов производительности, с самого начала придерживаются такого подхода. А те, кто упускает это из виду, в конечном итоге страдают от низкой скорости загрузки.

«Производительность – это уважение. Уважайте своих пользователей и они вернутся снова», – Брэд Фрост.

Почему так происходит


Показатель отказов

Существует исследование, согласно которому, 57% пользователей уйдут с вашего сайта, если он загружается дольше трех секунд.

image

Google, Page Speed & SEO

Весной 2010 года Google начал учитывать скорость при ранжировании сайтов. Она не оказывает большое влияние на позицию сайтов со средней скоростью загрузки, но если страница не загружается за определенное время, то поисковый алгоритм применяет к такому сайту штрафные санкции.

Это еще раз доказывает, что когда речь идет о пользовательском опыте, необходимо уделять внимание скорости.

Соображения скорости

Люди часто говорят о довольно абстрактной концепции «Мобильного контекста». Согласно знаменитой теории Google мобильные пользователи делятся на три типа:

  • Повторяющие (Repetitive Now): люди, которые используют свои телефоны, чтобы быть в курсе непрерывных, повторяющихся изменений (спортивные результаты, обновления ленты в Facebook, динамика акций на фондовом рынке).
  • Скучающие (Bored Now): Пользователи, которые обращаются к телефону во время ожидания какого-то события.
  • Срочные (Urgent Now)

Похоже на правду, не так ли?

На самом деле это не имеет ничего общего с действительностью. Нет никакого «мобильного контекста». Люди будут использовать свои телефоны во время прогулки по улице, домашнего отдыха или в путешествии на поезде. Они делают все одновременно!

Телефоны следуют за людьми, куда бы те ни отправились. Поэтому люди их используют абсолютно везде.

«Мобильный контекст – важная штука, но сначала нужно понять, что же это вообще, черт возьми, такое», – Тим Кадлец.

Люк Вроблевски приводит действительно интересную статистику:

Где люди используют мобильные устройства?

  • 84% дома
  • 80% в свободное время в течение дня
  • 76% в очередях и в процессе ожидания
  • 69% в процессе шоппинга
  • 64% на работе
  • 62% во время просмотра ТВ-программ (альтернативные исследования дают цифру в 84%)
  • 47% во время подготовки к работе

С возникновением новых возможных ситуаций, развитием новых рынков и появлением новых привычек у людей, мобильный контекст неизбежно изменится. Можно с уверенностью предположить, что концепция мобильного контекста сохранит свою актуальность до тех пор, пока люди будут пользоваться мобильными устройствами.

И это заставляет нас внимательнее взглянуть на скорость интернета. Есть только одна возможность давать пользователям тяжелый сайт и не получить при этом проблем: если пользователь будет открывать его на Macbook Pro находясь дома с быстрым интернетом.

Однако же необходимо предусмотреть и прочие ситуации, которых существует великое множество. Люди используют для просмотра сайтов бесконечное количество устройств, появляющихся на рынке каждый день.

«Вы не можете знать, с каких устройств будут просматривать ваш сайт. Это решают пользователи», – Карен МакГрейн.

Даже в тех странах, где пару лет назад было не так много смартфонов, сейчас их число растет бешеными темпами.

«Если ваши материалы, контент, информация, продукты, услуги недоступны в мобильной среде, то для этих людей они не существуют вовсе», – Карен МакГрейн.

Еще более важный момент – места, из которых люди будут приходить на ваш сайт. Так что вы должны будете учитывать любую скорость интернета. Дело даже не в том, что некоторые пользователи живут в удаленных регионах, где качество покрытия оставляет желать лучшего. Люди будут заходить на сайт с работы, где есть канал на 100 мб/с, из дома, где доступна скорость от 2 до 30 мб/с, через 3G и 4G и так далее.

Говоря напрямую, адаптивный дизайн больше не история про размеры экранов, но различные сценарии, решения для которых должны быть гибкими и продуманными «от и до».

И как?


Хорошо, что вы спросили.

Выше мы говорили, что производительность не стоит рассматривать, как набор автоматизированных заданий, запускаемых на стороне сервера для спасения обреченного сайта. Существуют способы преодолеть подобные проблемы и даже обратить их в конкурентные преимущества.

Чего стоит избегать

Гай Подъярны выделяет три главные причины существования большого количества тяжелых адаптивных сайтов:

  • Загрузка и сокрытие: большое количество элементов загружается, но не показывается пользователю
  • Загрузка и урезание: изображения в высоком разрешении загружаются, а затем урезаются для соответствия пользовательскому экрану
  • Избыточный DOM: не существует способа избежать парсинга и обработки браузером всех зон DOM, включая скрытые

Упреждающий подход

Существует большое количество информации на тему того, почему сайтам не всегда удается соответствовать ожиданиям в плане производительности. Большинство специалистов говорят что-то вроде «нужно быть адаптивным с самого начала».

Все техники, которые мы обсудим далее, не являются чем-то новым. Интересный момент здесь в том, как они совмещаются и переплетаются, сглаживая недостатки и подчеркивая достоинства друг друга.

Прогрессивное улучшение

Смысл этой техники заключается в обеспечении опыта использования сайта в вебе, который ограничен только самым главным.

Пару лет назад эта теория воспринималась главным образом с «браузерной» точки зрения. С развитием таких технологий как HTML5, CSS3, jQuery и т.п. разработчики, кажется, забыли о своих пользователях. Многие из них создавали несовершенные сайты, слишком полагаясь на эти новые технологии.

Теперь, когда браузеры на основе Webkit, Firefox и другие отвоевали большую долю рынка, появилась другая проблема – огромное количество мобильных устройств с браузерами, которые не обладают возможностями iPhone или Samsung. Прогрессивное улучшение – это единственный подход, который предполагает, прежде всего, учет способностей всех этих забытых игроков, а уже затем движение в сторону более навороченных устройств.

Разработка Mobile First

В 2009 году Люк Вроблевски предложил подход к разработке, получивший название Mobile First, по трем причинам:

  • Мобильный рынок продолжает развиваться бешеными темпами.
  • Мобильная среда заставляет вас фокусироваться (позволяя избавиться от беспорядка, причиной которому является слишком большее количество места на экране).
  • Мобильная среда расширяет ваши возможности (благодаря технологиям вроде GPS, геолокации, мультитач-жестам, акселерометру, камерам).

С тех пор веб-дизайн постоянно смещается в сторону этого подхода. Многие дизайнеры и разработчики отмечают, что построение сначала мобильной версии сайта, дает преимущественно над десктопной разработкой (что очень неплохо иллюстрирует второй пункт выше). Прогрессивное улучшение и подход Mobile First также неплохо сочетаются друг с другом. Разработчики начинают создавать сайт для мобильных устройств, постепенно улучшая его, добавляя большие разрешения к первоначально небольшому размеру экрана.

Джордан Мур (Jordan Moore) собрал отличный список причин использования Mobile First. Он утверждает, что из-за того, что полностью положиться на скорость соединения нельзя, «адаптивный веб-дизайнер» должен начинать работы с самой низкой входной точки – мобильной версии сайта, предполагая низкую скорость соединения, и двигаясь в разработке поэтапно, к более крупным точкам прерывания для более быстрого соединения. В будущем мы сможем полагаться на высокую скорость соединения, но пока стоит принять как должное низкое качество связи и не предпринимать опрометчивых шагов.

Вывод

Разрабатывайте сайт с расчетом на небольшие разрешения и возможности. Используйте технику прогрессивного улучшения с самого начала. Добавляйте дополнительную функциональность, улучшенные визуальные эффекты и способы взаимодействия там, где это имеет смысл.

RESS: Responsive Web design + Server Side components

По мнению многих людей у адаптивного дизайна есть один большой недостаток – он целиком и полностью зависит от определения ширины экрана.

С появлением все большего количества типов устройств, включая гибриды вроде ноутбуков с тачскринами, определение разрешения экрана стало крайне важной вещью в адаптивном дизайне. Библиотеки, которые обеспечивают эту функциональность (главным образом, Modernizr), буквально расцвели и сейчас используются в большинстве проектов. Они помогают разработчикам понимать, поддерживает ли браузер пользователя ту или иную функциональность и, соответственно, предоставлять ее. Но во многих случаях полагаться на браузеры – не лучшая идея, поскольку, зачастую, они могут поддерживать те или иные функции лишь частично, при этом «заявляя» о полной поддержке.

Для решения этой проблемы и был создан RESS. Как и Mobile First термин RESS был образован Люком Вроблевски в 2011 году. Он основывается на определении типа устройства, его оценке и обеспечении связанного пользовательского опыта. Для выполнения этой задачи существуют тяжелые средства вроде WURFL, DeviceAtlas и более легкие, такие как Browser Gem, которые считывают строку User Agent и действуют на основе этой информации.

Оценка типа устройства имеет и другие преимущества. Она позволяет разработчикам использовать различные шаблоны сайта в зависимости от устройства пользователя. Скажем, вы создаете очень большой сайт и хотите упростить мобильную навигацию. Вы можете «поиграть с контентом», показывая или скрывая что-либо, подвигать дивы по JavaScript коду или использовать разные шаблоны для мобильной и десктопной версии сайта, необходимость показа которых определяется сервером.

Представители BBC говорят о том, как RESS и прогрессивное улучшение могли бы работать отдельно. Подход называется Cut the Mustard! Он состоит в создании основной версии сайта, которая будет работать на любом устройстве. Затем устройство оценивается сервером для того, чтобы определить, «срезает ли оно горчицу». Если ответ да, то используется улучшенная версия сайта. Если же устройство не обладает нужными параметрами, пользователь все равно видит основной контент.

Условная загрузка

«Мобильные пользователи хотят видеть наше меню, часы работы и телефон доставки. Пользователи десктопа само собой хотят видеть картинку в 1 мб, на которой кто-то смеется в салат», – Мэт «Wilto» Маркиз.

Рассмотрим пару точек зрения:

1) Мобильные пользователи хотят получить контент, также сильно, как пользователи десктопов.

«Если ваш контент доступен по URL, то его обязательно будут просматривать с мобильных устройств», – Брэд Фрост.

2)Мобильная среда заставляет фокусироваться. Существуют определенные ограничения (вроде скорости соединения или размера экрана), которые дизайнерам необходимо принять, чтобы одинаково хорошо предоставить тот же самый контент.

Эта техника, также называемая «Агрессивным улучшением», позволяет дизайнерам фокусироваться на ключевом контенте и прогрессивно улучшать его для бОльших экранов. Она подразумевает базовый доступ к определенному контенту, который затем может быть дополнен на странице, при появлении места.

«Возможно, более точным определением условной загрузки будет назвать ее подходом content-first. В этом случае сайдбары или многочисленные столбцы с красивым, но нефункциональным контентом – роскошь, вам недоступная», – Джереми Кейт.

Вы можете использовать отличное средство MatchMedia, которое подражает поведению CSS и оценивает размер экрана в JavaScript.

Ленивая загрузка

Сайты, тяжелые на вид и в использовании (Facebook, Twitter, Pinterest), когда им необходима оптимизация для мобильной среды, прибегают к использованию техники ленивой загрузки (lazy loading) для обеспечения лучшего пользовательского опыта. Когда вы загружаете страницу впервые, загружается определенное число постов. Когда вы прокручиваете страницу вниз, дизайнер предполагает, что вы хотите увидеть больше контента, поэтому тот вставляется на страницу с помощью Ajax. Это позволяет значительно ускорить загрузку страницы и избежать избыточности DOM.

Установка бюджета производительности

Тим Кадлец утверждает, что установка максимального веса страницы и контроль этого показателя, является главным способом сокращения времени загрузки страницы. «Задавайте цели и стремитесь к ним». Стив Соудерс (Steve Souders) предлагает на выбор три опции, если вы уже превысили свой бюджет:

  • Оптимизация существующей функции или элемента
  • Удаление существующей функции или элемента
  • Избегание добавления новой функции или элемента

Звучит довольно радикально, но такой подход позволяет сфокусироваться на том, как на общую производительность сайта влияет каждая новая функция.

Кроме того, существует определенное количество методов, работающих на более техническом и менее концептуальном уровне.

Техники работы с изображениями

Веб-сайты примерно на 60% состоят из изображений. И если вы показываете мобильным пользователям с неизвестной скоростью соединения картинки десктопного размера, то обрекаете свой сайт на проблемы со скоростью загрузки.

Способ решения этой проблемы заключается в показе различных версий изображений в зависимости от размера экрана или типа устройства. Таким образом, вы будете показывать маленькое изображение при заходе на сайт с мобильного телефона, картинку в высоком разрешении пользователю десктопа и еще в два раза большее изображение в случае HiDPI устройства.

Адаптивные изображения

Дизайнеры и разработчики во всем мире вели борьбу за включение адаптивных изображений в спецификацию HTML. Мэт ‘Wilto’ Маркиз один из наиболее ярких сторонников этой идеи. Битва еще не выиграна, но появились решения на базе JavaScript, которые помогают добиться желаемого результата.

Скот Йель (Scott Jehl), из Filament Group написал плагин, который имитирует разметку, предложенную сообществом, и прекрасно работает: это PictureFill.

Сжатие изображений

Голландский дизайнер Даан Джобсис (Daan Jobsis) обнаружил очень странный феномен при сжатии изображений в Photoshop. Ему удалось осуществить следующую последовательность действий: он взял изображение, удвоил его размер (200%), сжал его до 25% или менее от его первоначального качества, затем восстановил размер изображения в браузере до изначальной величины (100%). В результате изображение не только стало легче, но и изначально было оптимизировано для HiDPI экранов, благодаря дублированию плотности пикселей.

Единственная обнаруженная проблема здесь заключается в том, что браузеру может быть тяжело отрисовывать увеличенное вдвое изображение в его изначальном размере (особенно если это необходимо делать сотни раз, в случае сайтов с большим числом медиа контента). Чтобы убедиться в оптимальности данного решения необходимо уделить время тестированию.

Векторные vs растровые изображения

Отличным выбором можно назвать SVG изображения. Они полностью масштабируемы, благодаря чему хорошо работают на любом экране. Реализовать fallback в этом случае будет очень просто с помощью Modernizr.

Иконочные шрифты

Технически они на самом деле являются векторными изображениями, только представленными в виде шрифта. Как говорит Крис Койер (Chris Coyier), «иконочные шрифты изумительны» потому что:

  • Легко изменять их размер
  • Легко менять их цвет
  • Легко оттенять форму шрифта
  • Они работают в IE6, в отличие от прозрачных PNG.
  • С ними можно делать все то же, что и с изображениями
  • Они предоставляют неограниченный простор для типографики

Изображения HiDPI

Дэйв Бушелл (Dave Bushell) не так давно написал очень интересную статью с размышлениями о HiDPI-изображениях. Он утверждает, что, даже несмотря на то, что сегодня мы можем показывать пользователям iPhone, iPad или других современных устройств изображения, которые соответствуют возможностям этих девайсов, все еще слишком рано предполагать, что это не навредит сайту.

«Означает ли высокая скорость и высокая плотность пикселей, что пользователи хотят видеть изображения лучшего качества? В случае пакетного тарифа с ограничением по количеству гигабайт, вряд ли», – Дэйв Бушелл.

Что дальше?

Недавно Google разработал новый формат изображений – WebP. Он предоставляет возможность сжатия изображений без потерь, что позволяет получать в три раза меньшие файлы, в сравнении с PNG.

Сегодня существуют простые и легкие JavaScript-библиотеки, с помощью которых можно конвертировать изображения в и из WebP формата. Учитывая влияние последних новинок Google, вполне возможно, что начать эксперименты с WebP для улучшения работы сайтов с большим числом изображений уже сейчас может быть хорошей идеей.

Загрузка элементов

Загружайте элементы аккуратно и по порядку. Контроль этого аспекта несет в себе большие преимущества, позволяя странице сначала отображать базовый контент, а затем улучшать его.

CSS, изображения

Контролируйте загрузку с помощью media query, условной или ленивой загрузки и применяйте техники адаптивных/сжатых изображений.

JavaScript

Используйте такие функции HTML5, как async или defer. Кроме того существуют такие «помощники при загрузке», как RequireJS, который может контролировать загрузку и зависимости.

Реклама, социальные виджеты и сторонние элементы

Просто вставляйте их на страницу после загрузки.

Олдскульные техники улучшения производительности

Они известны довольно давно, но все еще неплохо работают.

Снижайте число HTTP-запросов

Чтобы это добиться, разработчикам необходимо приложить усилия, однако есть ряд способов, позволяющих достичь этого:

  • Применяйте конкатенацию для всех CSS-файлов или используйте CSS Preprocessors, чтобы скомпилировать их в один файл.
  • Объединяйте JS плагины в том же файле и всегда загружайте их в футере, за исключением случаев, когда им действительно необходимо блокировать рендеринг страницы (если вы загружаете шрифты Typekit в футере, вы получите знаменитый эффект FOUT или «Взрыв нестилизованного текста»).
  • При необходимости работы с PNG-изображениями, используйте спрайты. Они объединяют все изображения в одно и используют CSS для «нарезки» его на нужные кусочки.
  • По возможности используйте схему данных URL (рус, англ), которая позволит включать изображения в качестве строчных данных и еще сократить число HTTP-заголовков.

Снижайте число байтов

Минифицируйте каждый скрипт или CSS-файл, который вызывается со страницы. Настройте на сервере GZIP-компрессию/расширение и применяйте их для всех элементов.

Заключение


Со времен рождения адаптивного дизайна важность производительности в вебе была сильно преувеличена.

Дизайнеры и разработчики фокусируются на сборке адаптивного паззла, в качестве элементов которого стали выступать различные скорости доступа в сеть, множество различных устройств, разные места нахождения пользователей.

Чтобы подготовиться к проблемам завтрашнего дня нам необходимо обращать большое внимание на производительность, ведь декстоп-ориентированный веб исчезает прямо на наших глазах. Мобильный пользователь быстр, легок и не будет преодолевать препятствия для доступа к контенту, и, учитывая, что сайтов с каждым днем становится все больше, быть быстрым означает быть впереди.

Вам также может понравиться [en]…


P. S. Замечания по переводу принимаются в личку.

P. P. S. Еще мы начали размещать дайджесты интересных публикаций мира юзабилити и UX в своем блоге. Вдруг кому интересно.
UIDG
70,00
Компания
Поделиться публикацией

Комментарии 44

    +8
    Не люблю адаптивные версии сайтов. Пользуешься все время одним и тем же интерфейсом, а потом заходишь на этот же сайт с телефона и становится непонятно где что искать. Хорошо, если кнопка «обычный режим» есть.
      +9
      Вы что-то путаете. Адаптивный != мобильная версия
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Верно. Настоящая адаптивность — это когда за меня решают, что мне нужно на каком устройстве и в какой ситуации, а что нет. С одной стороны — круто, а с другой — сами знаете.

          Это первый шаг. Шагов всегда несколько: предположение, опыт, анализ, результаты, следующий шаг.
          –12
          Адаптивный веб-дизайн (англ. Responsive web design) — дизайн веб-страниц, обеспечивающий отличное отображение сайта на различных устройствах. (wiki)
          Мобильная версия сайта является адаптивной версией сайта для мобильного устройства. Или я не правильно понимаю?
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              Мобильная версия сайта является адаптированой версией сайта для мобильного устройства.
            +21
            Напрасно минусуете человека — это совершенно нормальное поведение пользователя, привыкшего к определенному интерфейсу.

            Например поменялось меню и теперь вкладка «форум» не вторая справа, а третья снизу. Нужно снова перечитать все пункты меню и найти ее. И так с каждым элементом. Представьте себе, если бы в вашей квартире мебель менялась местами днем и ночью — вроде должно стать удобнее, но только если ты на 100% знаешь что и куда переехало.

            Конечно есть удачные примеры адаптации, но рекомендую несколько раз подумать, прежде чем глобально перекроить страницу проекта.

            Естественно речь идет о крупных площадках с большим количеством постоянных пользователей.
              +3
              Есть ещё одна вещь, которая отталкивает меня от адаптивного дизайна.
              Это упрощение интерфейса. Так как разработчик делает одну страницу для разных устройств, то на ПК мы получаем почти ту же функциональность, что и на мобильном гаджете. А это невероятная деградация. Добавьте к этому то, что элементы интерфейса не могут нормально иметь два радикально разных вида (под палец и под курсор), и получаем, что страдает в основном курсор, т.к. «пальцев», то есть тачевых устройств, уже больше, чем ПК.

              Из чего делаю вывод: если вы хотите сделать действительно качественный сайт, и вы не скупитесь на дополнительное время разработки, то сделайте три совершенно разные версии — для мобильников, для планшетов и для ПК. С разной функциональностью, и соответственно, различающимся весом.

              Из минусов для разработчика я тут вижу только один — ему придется больше работать. С другой стороны, он сам ответственен за качество кода, который пишет.
                –1
                Пользователям мобильников и планшетов лучше дать возможность скачать приложение для работы с вашим сайтом, и уведомлять об этом при попытки просмотра сайта. А адаптировать сайт есть смысл для популярных экранов desktop & ipad и то без фанатизма.

                Мобильные приложения меньшее из всех зол, так как можно использовать все возможности гаджета и интегрироваться в экосистему. Пользователи сколны пользоваться приложениями ( это удобно), больше чем кастрированными версиями сайта.

                От разработчика потребуется знание не только web, но еще и мобильных технологий. Для ускорения разработки можно пользоваться например phonejs.devexpress.com/

                Наверное такой подход подойдет не для всех ресурсов, но для большинства точно.
                  +6
                  Меня лично такой подход бесит. Особенно, когда с мобильного нет даже возможности посмотреть полную версию сайта (а только ссылка на установку приложения).

                  Кому-то, может, будет удобно поставить приложения для пары-тройки сайтов. Но ставить его для сайта на который ты заходишь в первый и последний раз… Тем более такие приложения часто хотят столько прав, что ужас берет.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Я хотел сказать, что если выбирать между мобильной версией сайта и приложением для работы с сайтом — обычно выбирают приложение.

                      Лично я еще не видел удачных мобильных версий сайтов.
                        +1
                        >Я хотел сказать, что если выбирать между мобильной версией сайта и приложением для работы с сайтом — обычно выбирают приложение.
                        В приложениях, обычно, не пошлёшь ссылку на конкретную страницу, не скопируешь текст, не сохранишь понравившуюся картинку и вообще можно сделать только то, что разработчик вспомнил/решил/согласился и реализовал. И не забыл про твою платформу, кстати (привет от владельцев телефонов на Symbian/WP/FirefoxOS/UbuntuTouch и прочих Palm'ов)
                        >Лично я еще не видел удачных мобильных версий сайтов.
                        Ну, например, мобильные версии сайтов VK и Emirates меня вполне устраивают.
                +10
                Я в итоге так и не понял о чем речь. Сначала говорят что адаптивный дизайн тяжелее. Что, в общем-то, очевидно: тянем к клиенту верстку на все случаи жизни, а показываем только то, что нужно. Потом говориться о том, что это в общем-то проблема но, вроде как, и не совсем проблема: можно тут подкрутить, там подлечить, потом предлагается сервером отдавать разный контент(!) для разных устройств и все будет красиво. Так если сервером отдавать разный контент, нафига вообще адаптивный дизайн нужен?
                  0
                  Смотреть обычную версию на мелком экране не удобно. Не весь функционал нужен.
                    +3
                    Перечитайте вопрос еще раз.
                      0
                      А вот это не факт. Вы точно так же можете зайти на телефоне на сайт из дома или офиса как и с компьютера. Сидя в туалете, например. И точно так же пользоваться. Единственная разница: меньше экран, память и процессор.
                      0
                      мне кажется, вопросы дизайна и профильных технологий, лучше рассматривать в отдельности, иначе холивару не будет конца). ну т.е. да, адаптивный дизайн нужен, чтобы адаптировать интерфейс к физиологическим особенностям юзверей и техническим возможностям клиентских девайсов. как это все реализовать на клиенте и сервере уже чисто инженерная задача. а где-то на стыке живут попытки сэкономить ресурсы, чтобы не верстать под каждый девайс в отдельности.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Так если сервером отдавать разный контент, нафига вообще адаптивный дизайн нужен?

                          Основной смысл это экономия при разработке. Если просто: 200 $ — адаптивный против 100 $ — мобильный 100 $ — планшетный 100 $ — полноценный 100 $ — ТВ. Итого профит, но у любого профита есть цена и суть поста(как я ее понял) выбирать надо золотую середину в зависимости от проекта.
                          +2
                          Изначально не очень хорошо относился к адаптивному дизайну, как раз из-за размеров страницы и что все это ложится на клиента. А у мобильных телефонов не только экран меньше, но и возможностей по обработке информации тоже меньше(процессор, память и т.д.). Поэтому решили у себя делать отдельную версию — для мобильных устройств. Сейчас конечно есть проблемы, но по крайне мере пользователи не ждут пока загрузятся куча ненужных картинок и информации, которую они по сути не увидят.
                          А вообще за статью большое спасибо. Интересно было почитать.
                            0
                            А на хабре не будете публиковать этот «Usability и UX дайджест»?
                              +1
                              Пока экспериментируем с форматом, все устаканим и, скорее всего, будем публиковать и на хабре тоже.
                              +3
                              Применяйте конкатенацию для всех CSS-файлов или используйте CSS Preprocessors, чтобы скомпилировать их в один файл.

                              Неужели действительно нужно собирать всё в ОДИН файл? Я всегда думал, что нужно искать компромисс между количеством загружаемых файлов и количеством «лишней» на данный момент загружаемой информации.
                                0
                                Нужно грузить один файл, но без лишней информации. Собирать под разные экраны разное. Сервером.
                                0
                                Все должно быть в меру. Если основной сайт тяжелый то ему точно нужна отдельная версия под мобильные устройства, в других случаях применятся адаптивка, правда подходить к ней нужно очень осторожно и не перелопачивать интерфейс так что потом при заходе с мобильного устройства этот сайт совершенно не узнать. А вообще я за отдельную кнопку (поддомен) для перехода на мобильную версию сайта, захотел и перешел и получил мобильный интерфейс вместе с меньшим кол-вом трафика заточенный под твое разрешение и тип девайса. Не нужно решать за меня что я хочу, я сам выберу оставаться мне на исходном сайте или перейти на мобильную версию.
                                  +1
                                  ссылки от 2011-2012 годов настолько же устарели, как и ваша информация.

                                  надеялся узнать что-нибудь новое, но, наверное, не судьба…
                                    +1
                                    Вот эти ссылки на подборки разного добра 3-х летней давности не очень актуальны мягкагаваря.
                                    p.s. опоздал с коментом, сорри )
                                      +8
                                      Сайты, тяжелые на вид и в использовании (Facebook, Twitter, Pinterest), когда им необходима оптимизация для мобильной среды, прибегают к использованию техники ленивой загрузки (lazy loading) для обеспечения лучшего пользовательского опыта. Когда вы загружаете страницу впервые, загружается определенное число постов. Когда вы прокручиваете страницу вниз, дизайнер предполагает, что вы хотите увидеть больше контента, поэтому тот вставляется на страницу с помощью Ajax.

                                      Для тех, кто делает твиттер-подобную подгрузку контента, в аду должен существовать специальный котел — с лестницей наверх, которая будет съезжать обратно в кипящее масло, как только грешник подбирается поближе к бортику. Вы поломали мой скроллбар, ироды!
                                      Браузеры же умеют рендерить недогруженные страницы больше десятилетия. И никакого тормозящего js не нужно.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          +1
                                          Больше всего в этом преуспели разработчики Flickr. После внедрения нового «justified view» вес страницы, которая отмотана вниз до предела (он там все же есть) вместе с огромными фото, которые средствами css уменьшаются и подгоняются по ширине окна и высоте строки, может достигать 40 Мб. Это ворочается с существенным трудом на atom-ных нетбуках. Все эти подгрузки по scroll без освобождения страницы от того, что ушло далеко вверх — форменное вредительство.
                                            +1
                                            А еще веселее, когда в самом низу страницы есть ссылка, на которую тебе надо нажать, скажем, ссылка «Для разработчиков». И вот ты ее уже вроде как видишь, но тут чертов контент подгружается и надо листать дальше, пока все новости за 3 года не увидишь.

                                            Особенно доставляет в гугле, в режиме поиска картинок, кнопка «Упрощенная версия» внизу результатов. Пока до нее дойдешь, ощутишь все прелести утяжеленной версии.

                                            А также youtube очень меня разочаровал, когда стал использовать эту чертову ленивую загрузку для комментов у видео. Теперь после загрузки страницы еще надо ждать какое-то время, чтобы прочитать комменты. Неужели нельзя было хотя бы сделать чтобы они погружались в фоне, пока я смотрю видео?
                                              0
                                              Или placeholder флэша — у фэйсбука всегда внизу страницы. При этом FlashBlock почему-то не хочет добавлять FB в белый список раз и навсегда — возможно, из-за https, а может, у меня хром кривой. Но включить флэш на фэйсбуке для меня всегда задачка не из легких.
                                                +1
                                                >А еще веселее, когда в самом низу страницы есть ссылка, на которую тебе надо нажать, скажем, ссылка «Для разработчиков». И вот ты ее уже вроде как видишь, но тут чертов контент подгружается и надо листать дальше, пока все новости за 3 года не увидишь.
                                                В Опере (12) это решается совершенно элементарно, кстати: F12→[ ] Enable Javascript → End → Click → F12 → [x] Enable Javascript.
                                                >А также youtube очень меня разочаровал, когда стал использовать эту чертову ленивую загрузку для комментов у видео. Теперь после загрузки страницы еще надо ждать какое-то время, чтобы прочитать комменты. Неужели нельзя было хотя бы сделать чтобы они погружались в фоне, пока я смотрю видео?
                                                Особенно неудобно это потому, что комментарии, обычно, видны на том же экране безо всякого скролла, зачем откладывать их загрузку на неопределённое время — непонятно. Особенно если топовый комментарий а-ля «видео — фуфло, заголовок левый, можно не смотреть»
                                              0
                                              У меня как раз выбор недавно стоял между bootstrap 3, foindation 4. Решил остановиться на 2м. Она тоже не легкая, но можно обойтись без jquerly в пользу более легкой библиотеки. В холиварах как раз критиковали foindation 4 за то, что он ориентирован на мобилки. А я предпочитаю более быстрые технологии.
                                                +3
                                                Мобильный рынок продолжает развиваться бешеными темпами.

                                                А с ним и мобильные сети, и тарифы на мобильный Интернет, и мощности мобильных устройств.

                                                Может быть, описанной проблемы вообще не существует?
                                                  +2
                                                  Я вот раньше думал, как же не веб-программистам трудно с интерфейсом приходится, чтобы тянулся как угодно по размеру… Настал и наш черед :)
                                                    0
                                                    Есть ещё проблема размеров шрифтов. До сих пор в ходу 19'' мониторы с разрешением как на 4-5'' смартфонах. И здесь дело не только в размере, но и в ширине строки: слишком узко или слишком широко — и уже неудобно читать. Это до сих пор проблема большинства сайтов.
                                                      0
                                                      И ещё: у тачскринов нельзя навести курсор куда-то, можно только кликнуть. Из-за этого я не могу с планшета посмотреть схему зала местного кинотеатра, потому что меню на их дурацком сайте появляется при наведении, а клик перенаправляет на другую страницу (где ссылки куда надо нет).
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          0
                                                          Адаптивный дизайн хорош для блогов или лент новостей. ПРОСТЫХ вещей.

                                                          Для всего остального лучше бы купили технологию подгонки сайта по ширину у Оперы (как же мне не хватает этой технологии в Хроме :(

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое