Комментарии 37
>> Этот метод создания мобильных сайтов использует программирования на стороне сервера, чтобы создать CSS и HTML для различных устройств
А остальные методы как? Готовые .html страницы сразу складывают в папке?
А остальные методы как? Готовые .html страницы сразу складывают в папке?
Остальные могут адаптироваться посредствам вёрстки, при одинаково отдаваемом контенте. Отдельный мобильный сайт сам по себе отдаёт готовое решение для мобильных устройств.
CSS сейчас полностью позволяет адаптировать содержание к экрану. Остается только загрузка лишнего JS-кода (что можно на уровне JS определять), лишней HTML-разметки (но эти 3-5 Кб мало кого волнуют) и неоптимизированные изображения (вот их на уровне сервера, видимо, только вставлять). Хотя если через JS подгружать изображения, то с сервера и эту нагрузку снять можно.
Если я ничего не путаю, то сейчас nginx умеет на лету оптимизировать изображения (ресайзить точно умеет).
php тоже умеет ресайзить на лету изображения. Уже лет 10 точно :) А через cgi-bin и Apache уже лет 15 такое возможно.
Может молодой и зеленый, но совсем не понимаю зачем это нужно делать?
Почему нельзя при заливку создавать несколько копий разного разрешения? Дисковое пространство — самое дешевое из остальных параметров сервера
Почему нельзя при заливку создавать несколько копий разного разрешения? Дисковое пространство — самое дешевое из остальных параметров сервера
Это у кого как) вообще это просто как вариант, всё зависит от случая. Например если у вас крупный, совсем картиночный сайт или вроде того, то дисковое пространство вам будет нужно, а заодно вам нужно будет разработать систему, которая будет конвертировать, отдавать для разных параметров разные картинки, и т.д. Иногда проще один раз настроить веб-вервер, который будет ресайзить и кэшировать. Я не говорю, что так нужно делать всегда)
Я считаю что лучше всего писать универсальный API на бэкенде, а на фронтенде адаптивная верстка с каким-нить js mvc фреймворком(Backbone, Ember, Spine, Angular итд) который и работает с этим API и по сути является HTML5 приложением. Ну и js-шаблоны можно делать разные для десктопного и мобильного и использовать HTML5 app cache. Ну например с помощью AMD можно какие-то скрипты грузить или нет итд. Не так уж критично что первая загрузка сайта будет долгой, ведь потом все скрипты и стили будут лежать в app cache и с сервера будут поступать только json данные которые не много весят.
А уже потом, при необходимости, создать нативные приложения для мобильных платформ которые с этим-же API и будут взаимодействовать.
А уже потом, при необходимости, создать нативные приложения для мобильных платформ которые с этим-же API и будут взаимодействовать.
Как бы оно так да не так…
Увы много у этого подхода недостатков. Индексация поисковиками — никакая (делать hashbang копии страниц — дополнительные затраты времени и далеко не все поисковики поддерживают). Шаринг в социальных сети мягко говоря непрост — одни сети вообще убирают location hash, другие ищут open graph, который закономерно един для SPA. Но куда хуже проблема с кэшированием — размер кэша у большинства браузеров (особенно мобильных) ограничен, и складывая туда мегабайты яваскрипта мы ускоряем лишь загрузку последующих страниц. А завтра пользователь будет качать javascript по новой.
Кроме этого AMD порождает очень много http запросов. (решается через rjs для requirejs, но использует его нечасто). Если целится на нативные приложения — о сессиях необходимо забыть сразу, а это ещё пачка проблем. SPA на MVC-фреймворке с REST-API на сервере — это классная штука, но окружение пока ещё не очень к ним дружелюбно.
Увы много у этого подхода недостатков. Индексация поисковиками — никакая (делать hashbang копии страниц — дополнительные затраты времени и далеко не все поисковики поддерживают). Шаринг в социальных сети мягко говоря непрост — одни сети вообще убирают location hash, другие ищут open graph, который закономерно един для SPA. Но куда хуже проблема с кэшированием — размер кэша у большинства браузеров (особенно мобильных) ограничен, и складывая туда мегабайты яваскрипта мы ускоряем лишь загрузку последующих страниц. А завтра пользователь будет качать javascript по новой.
Кроме этого AMD порождает очень много http запросов. (решается через rjs для requirejs, но использует его нечасто). Если целится на нативные приложения — о сессиях необходимо забыть сразу, а это ещё пачка проблем. SPA на MVC-фреймворке с REST-API на сервере — это классная штука, но окружение пока ещё не очень к ним дружелюбно.
HTML5 History API убирает проблему hashbang. GitHub один из самых показательных примеров. Есть множество плагинов которые решают проблемы с кросс-браузерностью.
Ээээ а можно подробнее? Как мне пошарить страницу вконтактик через html5 history?
Изначально у SPA (single page application) возникала проблема, что контент меняется, а URL остается. Чтобы это исправить, использовались хеш-теги, например myapp.com/#!/about или myapp.com/#!/news/17. Тут возникает куча проблем, которые описал xel — то что после # не отсылается на сервер.
С появлением History pushState можно менять URL, который показывается в адресной строке, не перегружая при этом страницу. Таким образом пользователь, перейдя с главной страницы на новость будет видеть myapp.com/news/17 и этот же URL будет шарить в контактик.
С появлением History pushState можно менять URL, который показывается в адресной строке, не перегружая при этом страницу. Таким образом пользователь, перейдя с главной страницы на новость будет видеть myapp.com/news/17 и этот же URL будет шарить в контактик.
… и как быть с тем, что порядка 40% или сколько там пользователей сидят на ИЕ? Какие такие чудо-плагины порешают проблему с кросс-браузерностью в случае соц. сетей, отрезающих хэш?
Ну значит 60% смогут копировать URL из адресной и шарить его в соц. сетях. Остальные пусть нажимают кнопку Like/Share, в которой адрес будет указан явно. Плагины просто делают fall-back в URL с хешами.
Понятно что способ не идеальный, требует каких-то дополнительных затрат. Но зато более гибкий по сравнению с адаптивной версткой
Понятно что способ не идеальный, требует каких-то дополнительных затрат. Но зато более гибкий по сравнению с адаптивной версткой
Может быть, ссылки на сайты-примеры добавите? Чтобы народу не гуглить.
Меня всегда полностью устраивает обычная немобильная версия, что на смартфоне, что на планшете. Если открывается урезанная мобильная, то насильно переключаюсь в полную версию. Неудобства никакого нет. Неудобство скорее от пользования «специальными» мобильными версиями с урезанным функционалом, отключенными комментариями и т.д.
Я за адаптивный дизайн (в целом) (сам недавно пробовал верстать).
Время загрузки отличается полагаю из-за насыщенности страницы графикой. И если фоновое изображение можно легко переназначить на более «легкое» или вообще не использовать картинку, то с тегом img могут быть проблемы. И опять же, с помощью того-же css можно скрывать то, что по мнению разработчиков не должно быть видимым в мобильной версии сайта, впрочем, насколько я понимаю, это перечит концепции адаптивного дизайна.
Время загрузки отличается полагаю из-за насыщенности страницы графикой. И если фоновое изображение можно легко переназначить на более «легкое» или вообще не использовать картинку, то с тегом img могут быть проблемы. И опять же, с помощью того-же css можно скрывать то, что по мнению разработчиков не должно быть видимым в мобильной версии сайта, впрочем, насколько я понимаю, это перечит концепции адаптивного дизайна.
Для начала хочу бросить камень в огород любителей отдельных мобильных версий сайтов: когда я поочередно посещаю один и тот же сайт, пользуясь десктопом / мобилой / планшетом, я меньше всего на свете хочу лицезреть координально разную логику взаимодействия с интерфейсом. Я хочу, чтобы все возможные версии были максимально приближены друг к другу и пускай на телефоне громоздкое меню будет спрятано под заметной кнопкой «меню». И вообще, на телефоне с горизонтальным разрешением >1000px я не желаю лицезреть убогую мобильную версию, хочу оригинал.
Потом, «Мобильные пользователи должны быть как-то вычислены, а технология определения устройств пока недостаточно надежна». Неужели?
Замеры скорости загрузки сайтов-примеров меня умиляют. Starbucks, например, грузился добрые несколько секунд на десктопе с 50 мегабинтым интернетом. И вообще, хватит уже считать килобайты. Смотрите за производительностью сервака, за тем, сколько статики он отдает и сколько динамического содержимого при загрузке страницы. Пусть мгновенно загружаются тексты, и скелет страницы (базовый шаблон), а потом плавно подгружается все остальное.
Лично я обоими руками голосую за адаптивный дизайн. Более того, сегодня считаю это направление веб-разработки одним из самых интересных.
Потом, «Мобильные пользователи должны быть как-то вычислены, а технология определения устройств пока недостаточно надежна». Неужели?
Замеры скорости загрузки сайтов-примеров меня умиляют. Starbucks, например, грузился добрые несколько секунд на десктопе с 50 мегабинтым интернетом. И вообще, хватит уже считать килобайты. Смотрите за производительностью сервака, за тем, сколько статики он отдает и сколько динамического содержимого при загрузке страницы. Пусть мгновенно загружаются тексты, и скелет страницы (базовый шаблон), а потом плавно подгружается все остальное.
Лично я обоими руками голосую за адаптивный дизайн. Более того, сегодня считаю это направление веб-разработки одним из самых интересных.
del
Немного подумав, я также пришел к выводу, что автор путает цель и средства.
Мобильную версию можно сделать легкой как и отдельной страницей, так и использовав @media правила, просто скрыв «лишние» блоки, порезав графику.
Мобильную версию можно сделать тяжелой, насыщенной как и делая ее отдельной, мобильной страницей, так и используя @media правила и не скрывая «лишние» блоки.
Весь вопрос в концепции и предполагаемых сценариях использования.
С моей точки зрения с технической стороны использование @media правил намного элегантнее и правильнее.
Мобильную версию можно сделать легкой как и отдельной страницей, так и использовав @media правила, просто скрыв «лишние» блоки, порезав графику.
Мобильную версию можно сделать тяжелой, насыщенной как и делая ее отдельной, мобильной страницей, так и используя @media правила и не скрывая «лишние» блоки.
Весь вопрос в концепции и предполагаемых сценариях использования.
С моей точки зрения с технической стороны использование @media правил намного элегантнее и правильнее.
время загрузки на 3G-смартфоне оставляет желать лучшего (это занимает около 7 секунд)
Мне бы такие проблемы со скоростью загрузки) Это при том количестве не адаптивных сайтов, которые грузятся от минуты до пока не надоест ждать.
как-то писал свои мысли про тот момент когда еще можно использовать media queries, а когда уже нужен отдельный мобильный сайт и как все это реализуется, не буду пересказывать, может будет интересно:
nazz.me/few-words-about-responsive-design/
nazz.me/few-words-about-responsive-design/
Переключение в режим просмотра полной версии сайта с мобильного устройства должно осуществлять нативно само это устройство. В качестве примера могу привести Internet Explorer на Windows Phone, там в настройках указывается, какой версией надо представляться: обычной или мобильной. К сожалению, пока не дошли руки протестировать, как это будет работать с адаптивной вёрсткой, отталкивающейся от ширины экрана.
В родном браузере Андроида (4 и выше) тоже есть возможность переключаться между мобильной и обычной версиями, но это задается для конкретной открытой страницы. Если галочка на отображение большой версии стоит по умолчанию для всех сайтов, которые будут открываться на устройстве, это тоже не есть хорошо, потому что многие из них все равно еще сложно просматривать с маленьких экранов
Мой комментарий был к этому:
Я считаю, что сайт должен «решать за пользователя», в каком виде показывать контент на уровне определения по заголовкам и пр. Пользователь же, если хочет видеть не мобильную, а обычную версию сайта должен иметь возможность указать это нативными способами на самом устройстве. В таком случае и волки сыты и овцы целы: большинство пользователей, просматривая сайт с мобильных устройств будут видеть мобильную версию и всё ок; те же, кому надо полную версию на смартфоне поставят соответствующий чек-бокс в настройке и тоже будут рады.
Например, я с телефона часто захожу на Афишу. Если я хочу выбрать фильм или кафе, я захожу на обычную версию сайта, если посмотреть, где идет нужный мне фильм или узнать какой-то адрес — на мобильную. И я доволен тем, что сайт не решает за меня, в каком виде смотреть контент, а дает выбор.
Я считаю, что сайт должен «решать за пользователя», в каком виде показывать контент на уровне определения по заголовкам и пр. Пользователь же, если хочет видеть не мобильную, а обычную версию сайта должен иметь возможность указать это нативными способами на самом устройстве. В таком случае и волки сыты и овцы целы: большинство пользователей, просматривая сайт с мобильных устройств будут видеть мобильную версию и всё ок; те же, кому надо полную версию на смартфоне поставят соответствующий чек-бокс в настройке и тоже будут рады.
Сколько не сталкивался, мобильные версии сайтов вызывают обычно раздражение и воспринимаются обрезанными. То, что красиво смотрится на сайтах дизайнеров или на каталогах шаблонов, в жизни часто неудобно для использования. Меню становятся на всю ширину телефона, красоты пропадают, появляются какие-то автоматические перенаправления на мобильную (либо нет) версию сайта — сплошные условности, за которыми страницу воспринимать только сложнее…
По мне, так проще ориентироваться на дексктопный режим браузера, при возможности. Мобильник — это не платформа для серфига, это инструмент быстро что-то посмотреть. Чем быстрее будет выдан контент, и чем меньше придется разбираться, где в мобильной версии те же кнопки/ссылки, что в десктопной версии, тем быстрее я найду нужную информацию.
С планшетом, конечно, более спорно. Главное же — не скрывать информацию, чем бы пользователь не зашел на сайт, это будет самое честное.
По мне, так проще ориентироваться на дексктопный режим браузера, при возможности. Мобильник — это не платформа для серфига, это инструмент быстро что-то посмотреть. Чем быстрее будет выдан контент, и чем меньше придется разбираться, где в мобильной версии те же кнопки/ссылки, что в десктопной версии, тем быстрее я найду нужную информацию.
С планшетом, конечно, более спорно. Главное же — не скрывать информацию, чем бы пользователь не зашел на сайт, это будет самое честное.
Перед разработкой решения для мобильных устройств главное определить, для чего пользователи заходят с мобильных телефонов. Не столько важна подгонка под ширину экрана (тексты, естественно, должны быть масштабируемы при приближении, а то бывает...), сколько возможность быстро получить от сайта желаемое (телефон, карту проезда, свежие цитаты с башорга, ближайший сеанс электричек и т. д.). Да и по диагонали можно быстрее промотать до нужного места страницы, чем только вертикальной прокруткой, если знаком с сайтом и знаешь куда мотать.
У новомодоного RESS имеются определенные проблемы угадайте с каким браузером: в версиях меньше 9 внутреннее кэширование при использовании Vary просто отключается. По-хорошему этот самый Vary должен быть у всего — HTML, CSS, JS, картинок — поэтому у типичных бухгалтерш сайт будет еле-еле ползать. А у большинства коммерческих сайтов именно бухгалтерши являются целевой аудиторией, а отнюдь не хипстеры с гаджетами.
Отличная статья! :)
Хочется верить, что адаптивный дизайн вскоре избавится от своих недостатков!
Хочется верить, что адаптивный дизайн вскоре избавится от своих недостатков!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение методов создания мобильных версий сайтов