-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
Я не могу с этим согласится как минимум по той причине, что любой дизайн построенный вокруг графического артефакта обязательно будет фиксированного размера. Такое можно часто увидеть на промосайтах. Всему свое место.
Всегда, когда приходилось работать с «резиной» учитывал максимальную и минимальную ширину. Причем начиная с ie6, где поведение задавалось экспрешенами. p.s. Статья Бирмана неожиданно неприятно удивила. |
Кстати, очень большой вопрос насколько осмысленно разделять термины «адаптивный» и «отзывчивый» относительно макетов. Я не буду спорить с предложенной системой, но не проще ли их «смешать» а конкретное поведение описывать в Т.З.? Все равно ближайшее время вряд ли появится общепринятая и общеизвестная классификация, как бы нам этого не хотелось… |
Думаю, что нет особого смысла разделять отзывчивый от адативного — по большей части это одно и тоже. Как часто люди меняют размер браузера во время просмотра страницы? Так что не так сильно заметна разница этих двух понятий. |
Думаю, что если бы не было смысла, то никто бы и не разделял. Люди не изменяют часто размер браузера во время просмотра, но у каждого под рукой по парочке устройств, которые уже сами об этом заботятся. Но я не вижу аналогии между разделением адаптивного и отзывчивого с тем, меняют ли люди размер браузера во время серфинга? |
поправьте ссылку на статью Бирмана в последнем абзаце |
Cпасибо, поправил. Кстати, касательно браузеров/устройств … суть адаптивного дизайна в том, что бы позволить вообще исключить категорию браузер/устройства, а формировать представление за счет определения свойств носителя и доступных на нем фич. |
Это все конечно хорошо и технологично, но у адаптивного дизайна есть одна существенная проблема. Человек зайдя сначала с настолького ПК, а затем с мобильного может потеряться в навигации. Привычные ему вещи могут либо исчезнуть либо находиться в непривычном месте. И это также очень актуально при ресайзе окна браузера. Допустим я хочу просто сделать окно уже, мне нравится читать короткие строки. И что же происходит? Зачастую на такого рода сайтах теряется контекст, причем иногда полностью пропадает с экрана то, что я видел до ресайза. Мне нужно заново разбираться что тут и где. Поэтому со всей этой адаптивностю стоит быть осторожным и использовать в меру. Еще один момент. Адаптивная верстка кушает существенно больше килобайт CSS-a, скриптов. И на мобилке будет грузиться сильно дольше, чем стандартная мобильная версия. Кроме того, в мобилку пойдут "взрослые" большие картинки, заресайзеные этой ваше йадаптивностью, но не потерявшие при этом в размере. В результате сайт может грузиться в 2 и более раза дольше, нежели мобильная версия. Так что я пока скептически отношусь к этому подходу и не считаю 960 устаревшим. С мобильника также не испытываю дискомфорта при посещении такого рода сайтов. |
Кстати, предпоследий абзац статьи Бирмана как раз то, о чем я говорю. |
Если навигация и лаяут продуманы, то смена одного представления на другое не вызовет сложностей в пользовании ресурсом.
Не правда. Практика показывает что если код продуман, то он увеличивается не на много. И тем более не на столько, что бы возникли проблемы со скоростью загрузки. У меня обычно и килобайта то не набирается. При этом появляется адекватная поддержка мобильных устройств и вывода на печать. А об отзывчивых изображениях и способах «не грузить больше чем надо» говорили уже неоднократно. Если есть необходимость, то эта проблема решаема. Если сайт грузится в 2 раза дольше … то вас где то круто обманули :) |
Ну, во-первых, я сказал "может грузиться в 2 и больше", а не "будет точно грузиться в 2 раза дольше, инфа 100%". Все конечно зависит от ситуации. Но то что будет дольше — факт. В зависимости от сложности сайта (например, на фронте сайта присутствует много рюшечек — карусели, слайдеры и прочее.) Это далеко не 1 кб лишнего ненужного кода. Во-вторых,
|
Мда, что-то я не понял, почему цитатой сделалась вся остальная часть текста. |
Надо было оставить пустую строку после цитаты.
Что карусель что слайдер будет работать как на десктопе так и на мобильном в общем случае. Там прежде всего метод ввода меняться будет. И это кстати не сложно и не требует больших объемов кода.
Как связаны архитектурная задача и юзабилити тестирование?
Все разберуться :) |
Архитрудная)
Не, подразумевается, что они могут быть не нужны на мобилке по задумке дизайнера, но в адаптивном подходе будут грузиться все равно.
Я не про фронтендер имел в виду. А про любой другой сайт, где посетители — обычные люди. |
Не хочешь, что бы грузилось — не грузи. Сделай асинхронную загрузку модулей, проверяй в js соответствие медазапросу или наличию фич вроде тача и не грузи первый модуль. Для этого можно например require.js попробовать использовать. Это решило бы проблему? Думаю да.
Да бог с ним с фронтендером. Он далек от идеала и новый дизайн с учетом ошибок текущего на подходе. Главное что бы подход был юзер-ферст. И пользователь получал то, зачем он пришел. То что при этом меняется представление данных в зависимости от устройства не только не плохо, но напротив — отлично. Какое значение имеет то, что лаяут изменился, если ты и на десктопе и на мобильном сразу получишь доступ к нужной информации. Например в журнале это статьи. В магазине — товары. Если пользователь сразу сможет получить то за чем пришел и будет понимать что ему нужно делать что бы выполнить желаемое действие, то какая разница изменился лаяут или остался прежним? Привычный внешний вид или нет? Собственно вся суть изменений в том, что бы облегчить пользователю выполнение его задачи. Что бы ему было проще найти и купить товар, прочесть статью, оставить сообщение. |
Хорошее, мне понравилось! |
Баталище интересное было, сейчас дальше пошли разделяют между собой RWD и responsivness, ага, большое и малое "р". Обе практики часто редуцировались: противник до механистическего концепта (CSS), второй якобы назначался проводником высших идеологий: PE, MF. В этой истории меня прикалывает, что в русскоязычном сегменте отзывчивый не прижилось и в ходу адаптивный. Как всегда -- все как не у людей. Главное поддерживать видимость слитности с дискурсом, пороть чушь на попсовом CMSMAGAZe))) и дезоринтировать менеджеров, что его почитывают, хоть так!))) |
Первая толковая статья, которая четко описывает отличия adaptive и responsive. Спасибо! |
Присоединяюсь к словам предыдущего оратора |
No description provided.
The text was updated successfully, but these errors were encountered: