Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Комментарии #1

Open
FMRobot opened this issue Mar 3, 2013 · 18 comments
Open

Комментарии #1

FMRobot opened this issue Mar 3, 2013 · 18 comments
Labels

Comments

@FMRobot
Copy link
Member

FMRobot commented Mar 3, 2013

No description provided.

@SilentImp
Copy link
Member

Фиксированная верстка является пережитком прошлого

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

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

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

p.s. Статья Бирмана неожиданно неприятно удивила.

@SilentImp
Copy link
Member

Кстати, очень большой вопрос насколько осмысленно разделять термины «адаптивный» и «отзывчивый» относительно макетов. Я не буду спорить с предложенной системой, но не проще ли их «смешать» а конкретное поведение описывать в Т.З.? Все равно ближайшее время вряд ли появится общепринятая и общеизвестная классификация, как бы нам этого не хотелось…

@gladkih
Copy link

gladkih commented May 20, 2013

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

@pukhalski
Copy link
Contributor

Думаю, что если бы не было смысла, то никто бы и не разделял.

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

@bezdna
Copy link

bezdna commented May 20, 2013

поправьте ссылку на статью Бирмана в последнем абзаце

@SilentImp
Copy link
Member

Cпасибо, поправил.

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

@d1ldo
Copy link

d1ldo commented May 20, 2013

Это все конечно хорошо и технологично, но у адаптивного дизайна есть одна существенная проблема. Человек зайдя сначала с настолького ПК, а затем с мобильного может потеряться в навигации. Привычные ему вещи могут либо исчезнуть либо находиться в непривычном месте. И это также очень актуально при ресайзе окна браузера. Допустим я хочу просто сделать окно уже, мне нравится читать короткие строки. И что же происходит? Зачастую на такого рода сайтах теряется контекст, причем иногда полностью пропадает с экрана то, что я видел до ресайза. Мне нужно заново разбираться что тут и где. Поэтому со всей этой адаптивностю стоит быть осторожным и использовать в меру. Еще один момент. Адаптивная верстка кушает существенно больше килобайт CSS-a, скриптов. И на мобилке будет грузиться сильно дольше, чем стандартная мобильная версия. Кроме того, в мобилку пойдут "взрослые" большие картинки, заресайзеные этой ваше йадаптивностью, но не потерявшие при этом в размере. В результате сайт может грузиться в 2 и более раза дольше, нежели мобильная версия. Так что я пока скептически отношусь к этому подходу и не считаю 960 устаревшим. С мобильника также не испытываю дискомфорта при посещении такого рода сайтов.

@d1ldo
Copy link

d1ldo commented May 20, 2013

Кстати, предпоследий абзац статьи Бирмана как раз то, о чем я говорю.

@SilentImp
Copy link
Member

Человек зайдя сначала с настолького ПК, а затем с мобильного может потеряться в навигации.

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

Адаптивная верстка кушает существенно больше килобайт CSS-a, скриптов.

Не правда.

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

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

Если сайт грузится в 2 раза дольше … то вас где то круто обманули :)

@d1ldo
Copy link

d1ldo commented May 21, 2013

Ну, во-первых, я сказал "может грузиться в 2 и больше", а не "будет точно грузиться в 2 раза дольше, инфа 100%". Все конечно зависит от ситуации. Но то что будет дольше — факт. В зависимости от сложности сайта (например, на фронте сайта присутствует много рюшечек — карусели, слайдеры и прочее.) Это далеко не 1 кб лишнего ненужного кода.

Во-вторых,

«Если навигация и лаяут продуманы, то смена одного представления на другое не вызовет сложностей в пользовании ресурсом.». В том то и дело, что задача эта архитрудная, требующая юзабилити-тестирований. Вот взять тот же фронтендер. При сужении сайта шапка переносится в подвал. Все, навигация потерялась, совсем другой сайт? Разумеется гики разберутся, но есть еще 99% не гиковых посетителей. У вас есть пример продуманного с вашей точки зрения сайта с адаптивной разметкой? Я вот лично еще ни одного не видел, везде какие то метамарфозы происходят, от которых хочется закрыть этот сайт нафиг.

@d1ldo
Copy link

d1ldo commented May 21, 2013

Мда, что-то я не понял, почему цитатой сделалась вся остальная часть текста.

@SilentImp
Copy link
Member

Мда, что-то я не понял, почему цитатой сделалась вся остальная часть текста.

Надо было оставить пустую строку после цитаты.

В зависимости от сложности сайта (например, на фронте сайта присутствует много рюшечек — карусели, слайдеры и прочее.) Это далеко не 1 кб лишнего ненужного кода.

Что карусель что слайдер будет работать как на десктопе так и на мобильном в общем случае. Там прежде всего метод ввода меняться будет. И это кстати не сложно и не требует больших объемов кода.

В том то и дело, что задача эта архитрудная, требующая юзабилити-тестирований.

Как связаны архитектурная задача и юзабилити тестирование?

Разумеется гики разберутся, но есть еще 99% не гиковых посетителей.

Все разберуться :)
Зачем приходят на этот сайт? Читать статьи. Что мы видим зайдя с мобильного устройства — статьи. Что именно должно вызвать проблемы?
И кстати ЦА этого ресураса именно гики. Кроме фронтендеров тут никого нет и быть не может в связи с характером ресурса.

@d1ldo
Copy link

d1ldo commented May 21, 2013

Архитрудная)

Что карусель что слайдер будет работать как на десктопе так и на мобильном в общем случае.

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

Зачем приходят на этот сайт?

Я не про фронтендер имел в виду. А про любой другой сайт, где посетители — обычные люди.

@SilentImp
Copy link
Member

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

Не хочешь, что бы грузилось — не грузи. Сделай асинхронную загрузку модулей, проверяй в js соответствие медазапросу или наличию фич вроде тача и не грузи первый модуль. Для этого можно например require.js попробовать использовать. Это решило бы проблему? Думаю да.
Ну и вынужден заметить что все карусели+салйдшеу+черти что еще которое я пишу в рамках одного проекта после минимизации обычно не занимает и 5 килобайт. А если вспомнить про gzip… C точки зрения «веса» и скорости загрузки намного актуальнее картинки и минимизация количества http запросов.

Я не про фронтендер имел в виду. А про любой другой сайт, где посетители — обычные люди.

Да бог с ним с фронтендером. Он далек от идеала и новый дизайн с учетом ошибок текущего на подходе. Главное что бы подход был юзер-ферст. И пользователь получал то, зачем он пришел. То что при этом меняется представление данных в зависимости от устройства не только не плохо, но напротив — отлично. Какое значение имеет то, что лаяут изменился, если ты и на десктопе и на мобильном сразу получишь доступ к нужной информации. Например в журнале это статьи. В магазине — товары. Если пользователь сразу сможет получить то за чем пришел и будет понимать что ему нужно делать что бы выполнить желаемое действие, то какая разница изменился лаяут или остался прежним? Привычный внешний вид или нет? Собственно вся суть изменений в том, что бы облегчить пользователю выполнение его задачи. Что бы ему было проще найти и купить товар, прочесть статью, оставить сообщение.

@beshur
Copy link

beshur commented May 26, 2013

Хорошее, мне понравилось!

@mishelen
Copy link

mishelen commented May 1, 2014

Баталище интересное было, сейчас дальше пошли разделяют между собой RWD и responsivness, ага, большое и малое "р".
А ведь по существу была огромная терка между Итаном и Густафсоном, за интегрирование друг другом понятий, даже больше: поглощение трейдмарков, и только Зельдман рассудил их)) естественно в сторону Итана.

Обе практики часто редуцировались: противник до механистическего концепта (CSS), второй якобы назначался проводником высших идеологий: PE, MF.

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

Главное поддерживать видимость слитности с дискурсом, пороть чушь на попсовом CMSMAGAZe))) и дезоринтировать менеджеров, что его почитывают, хоть так!)))

@ArsenArts
Copy link

Первая толковая статья, которая четко описывает отличия adaptive и responsive. Спасибо!

@igortatarenko
Copy link

Присоединяюсь к словам предыдущего оратора

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants