Комментарии 24
Сейчас разрешения экранов трудно делить на десктопы-не десктопы. У кого-то экран древнего монитора 1024 (небось, сидит на IE 5.5), а у меня планшетник в альбомной ориентации шире этого значения. Если дизайнер нарисует, что на планшетниках какой-то набор элементов должен становиться сладйером, то он имеет в виду именно ширину экрана или все устройства с сенсорным управлением? А бывают ноутбуки и моноблоки (вроде бы), у которых сенсорный экран. Как тут себя вести дизайнерам, вообще не понятно.
А вообще, у меня есть вопрос. Если есть макет с размерами 360, 1024 и 1440, то на каких размерах принято переходить на мобилку, на каких на десктоп? То есть, условно планшетный вид — это 1025-1439, а 1024 — это уже мобилка? Или 361-1023 — это планшет, а мобилка — это 360 и ниже? Правда, есть телефоны с 375 (iphone X что ли, не помню точных моделей).
Я всё время путаюсь в этом. То есть, верстаю контентную область для десктопа не шире 1440, добавляя отступы. Потом на каком-то разрешении нужно перейти на планшетный вид (у меня обычно desktop first). И вот на каком разрешении переходить на планшет: на 1480 и вниз (1440 + padding по 20) до 1024+40 включительно?
Тогда как быть с тем, что на телефоне интерфейс ориентирован вдоль вертикали, а на 1024 он нарисован больше по горизонтали? Как это принято верстать на 1023, как жутко растянутую мобилку или как мобилку 320, расположенную по центру экрана?
Не стоит ли дизайнерам добавлять ещё одну точку, на которой вертикальный интерфейс переходит в сжатый горизонтальный интерфейс? Скажем, 768.
дада… поддерживаю вопрос )
на книжном-планшете чаще всего вообще беда - всё дико огромное, т.к. дизайнер/верстальщик решил, что это уже мобила )
Очень важно, что бы на поддерживаемых продуктом разрешениях контент отображался корректно. Если продукту не интересно поддерживать старые смартфоны или компьютеры – он может этого не делать, но в моей публикации указаны размеры вполне актуальные. Не все пользователи просматривают десктопные макеты на весь экран, например. Не все планшеты имеют высокое разрешение, равно как и смартфоны, некоторые планшеты поддерживают режим раздельного экрана и.т.д.
«Если дизайнер нарисует, что на планшетниках какой-то набор элементов должен становиться сладйером, то он имеет в виду именно ширину экрана или все устройства с сенсорным управлением?» – для этого существуют комментарии дизайнера и он может описать в каких случаях должен показываться этот элемент и как он должен работать.)
При проектировании экранов важно учитывать с каких девайсов его просматривают пользователи. Это с лёгкостью можно проверить через сервисы метрик.
При разработке адаптивной верстки могут учитываться не только размеры экранов, а и платформы с которых пользователи просматривают верстку.
В пограничных случаях, когда экран не относится ни к планшету ни к десктопу, могут подготавливаться отдельные макеты, все напрямую зависит от продукта, а они бывают разными.
То как выглядят макеты напрямую зависит от обозначенных разработчиками или дизайнерами брекпоинтов. Можно нарисовать только три ширины экрана, а можно больше: под маленькие смартфоны, под обычные, под разные размеры планшетов и десктопов. Все зависит от бюджетов компании, сроков и сложности задачи.
...но текст не раскрывает ни один из этих тезисов. И не отвечает на вопрос, сформулированный в заголовке. Хотя я, кажется, догадался - разработку осуществляет движок Figma на основании интерактивно введённых в него параметров макета. Так?
Для передачи макетов в разработку нужно подготовить макеты в необходимых разрешениях. В сформулированном тезисе речь идет о «...как минимум три типа устройств десктоп, планшет и мобилка.»
На практике бывают различные агрегатные состояния даже десктопной верстки: отображение в окне, отображение при открытом боковом сайдбаре, без него, с разными размерами перемещаемых виджетов, отображение на небольшом дисплее в режиме разделенного экрана и т.д.
В идеале стоит просить дизайнера подготовить макет для каждой подобной непонятной или сложной ситуации, это его работа.))
Проекты бывают разными, соответсвенно количество макетов может быть разным. В статье написано что стоит учитывать наиболее маленькие разрешения ибо порой дизайнеры этого не учитывают. В итоге макет попросту не помещается в экран.
Касаемо пограничных состояний можно готовить отдельные версии макетов, что сделает и дизайн верстку более качественными.
У меня нет рецепта для всех сайтов, ведь они бывают разными. Где-то достаточно трех состояний, где-то нужно более глубокая проработка. Если есть вопросы по конкретным ситуациям – можете написать мне в Директ, обсудим что можно придумать.))
Начет движка Фигмы не совсем понял. В Фигме можно использовать различные инструменты для подготовки адаптивных макетов. Если компоненты завернуть в автолейауты, правильно выставить параметры позиционирования элементов и отступов внутри фреймов – можно с легкостью подготовить адаптивные макеты под любое разрешение.
Прежде всего, не ясно, в каком формате предполагается передавать макеты. И, если я правильно понял, под термином "разработка" Вы подразумеваете HTML-вёрстку. Например, когда компания, взявшаяся продвигать мой сайт, готовила ТЗ по редизайну, то там были текстовые описания объектов с их параметрами и примеры, как это должно выглядеть (набросанные в графическом редакторе). Без текстовых приложений верстальщик бы это не осилил. Но у нас относительно простой сайт, возможно, для более сложных требуются другие подходы (но Вы таки не объясняете механизм взаимодействия дизайна и вёрстки)
Вы заблуждаетесь о передачи файлов в статье написано:
«Редактор дает возможность получать доступ к макету всем участникам команды в режиме онлайн, все изменения в проекте происходят в реальном времени, их сразу же видят все члены команды. Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.»
«Таким образом, я рекомендую использовать для работы приложения хранящие макеты в облаке и поддерживающие возможность кооперативного редактирования макетов в реальном времени. Figma будет отличным выбором.»
Касаемо комментариев для разработчиков также написано в пункте №5 и №8, а также в пункте №11.
Статья о том, как должен выглядеть макет, а не о том как составить ТЗ на сайт.
Вы подняли интересную тему взаимодействия дизайнеров и разработчиков. На эту тему можно написать отдельную статью. Возможно, этим займусь чуть позже. 😊
Но Вы-то озаглавили статью не "Как должен выглядеть...", а "Как передавать"!
Большая часть статьи отвечает на вопрос как должен выглядеть макет, как к нему оставлять комментарии и согласовывать его с разработчиками. Вступительная часть статьи «Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.» отвечает на вопрос «Как передать макет?», – это самая простая часть не требующая развернутых комментарии.
Для вас прокомментирую.) Макет передается разработчиками в виде ссылки. Если передавать макеты не в Фигме, он может пересылаться в виде файла.
Ссылке или файлы вы можете передать внутри CRM системы, с помощью мессенджеров или других способов передачи информации, коих сейчас довольно много, в каждой команде они свои.))
Макет стоит сопроводить комментариями, китом и презентацией. Все это написано в статье. Мне больше нечего вам добавить. Статья подписана так как нужно.
Думаю, пользователи которым адресована эта статья разберутся с тем в каком виде и как передавать файлы. Спасибо за ваши замечания.)
Возможно, в будущем я напишу статью о том как построить комфортную коммуникацию между разработчиками и дизайнерами. Этот вопрос не относится к теме статьи.
Помимо рекомендаций касаемо размеров экрана, в статье идет речь и о других важных моментах. Поэтому статья отвечает на вопрос из заголовка.
Касаемо размеров макетов я дал комментарий. Если вам не ясны другие тезисы – пишите, постараюсь вам помочь разобраться.)
на каких размерах принято переходить на мобилку, на каких на десктоп?
использовать для этих целей разрешения кмк антипатерн ибо есть десктопы с 800*600(нетбуки) и есть мобилки с 2к+(на почти любой флагман гляньте)
для начала стоит матчасть \@media запросов изучить.
\@media screen{desctop only}
\@media handheld{mobiles} или \@media not(screen) and not(print){для новых браузеров}
если нужно больше гибкости, всегда есть возможность сочетать в запросе тип, разрешение, DPI и ориентацию одновременно( landscape || portrait)
https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries
Пишут, что handheld уже deprecated. Я почему-то всегда думал, что screen — это любые экраны. А всякие носимые устройства определял по тому, что pointer у них coarse, хотя такой может быть не только на носимых устройствах.
Пишут, что handheld уже deprecated
вторую часть строки кому писал?
думал, что screen — это любые экраны
если тут формулировка еще довольно размытая, хотя и уже намекает @media - CSS | MDN
screen - Предназначен в первую очередь для цветных компьютерных экранов.
то тут уже прям кричит https://webref.ru/css/media
screen Экран монитора. что вполне конкретный класс устройств
p.s. дисплей - встроенное устройство, монитор - внешнее https://ru.wikipedia.org/wiki/Дисплей
У моноблоков дисплей или уже монитор? Чем современный коммуникатор не компьютер? У него есть всё необходимое. Вебреф — это наследник htmlbook, его же вёл один человек (10 лет назад так было). А MDN — это всё же документация от разработчиков браузера. Хотя, если этот один человек опробовал screen на разных устройствах и понял, как оно реализовано браузерами, тогда там может быть более аргументированное мнение.
Вебреф — это наследник htmlbook
А MDN — это всё же документация...
...тогда там может быть более аргументированное мнение
его инфа не противоречит МДН"у, если вы об этом. просто у МДН она кмк слишком размытая в данном вопросе.
ну и не стоит забывать, htmlbook.ru webref.ru их владелец явно русскоязычный нэйтив, а MDN заполнялась скорее english natives, и не исключено что с помощью гугл транслэйта. ну т.е. тут скорее вопрос не аргументации а корректности перевода...
Чем современный коммуникатор не компьютер?
кейсами применения и происходящими из этого стандартными для них габаритами, разъемами, HID`ами(тачскрин, стилус-тачскрин, клаво-мышь, клаво-тачпад).
У моноблоков дисплей или уже монитор?
встроенный в устройство - дисплей(*фоны, планшеты, *буки, моноблоки).
внешний цельный - монитор(десктопы).
внешний раздельный - экран и проектор(роль экрана может выполняться чем угодно, даже кирпичной стеной. учитывая это, формулировка "для компьютерных экранов" с MDN, выглядит как минимум странно, не находите?)
но одно дело, что есть у устройства и совсем другое, чем его считают имеющиеся дрова/ОС/DE/браузер/CSS стиль...
ну а учитывая что у моноблоков десктопные кейсы, грубо говоря у них дисплеи "притворяющиеся" мониторами.
ну как то так...
Но я читаю MDN на английском. В русском переводе этого сайта я давно разочаровался, когда увидел, как там выкинули пару абзацев. Переводят там, возможно, волонтёры, поэтому нет ничего странного в "компьютерных экранах". Только в моноблоке не понятно, это экран встроен в компьютер, или компьютер встроен в монитор.
2к разрешение мобильных девайсов не то же самое, что ширина в CSS. Моё устройство, с которого я пишу комментарий, имеет разрешение 1080×2310, но в рамках @media его размер 360×770.
Что касается handheld и тд - эти значения из старой спеки Media Queries Level 3. В Level 4 они deprecated и ничему не сопоставляются.
Все верно. Под мобильные устройства макеты разрабатываются в логических пикселях, а при выводе отображаются физический размер.
Макет нарисованный под 375px будет иметь размер на выходе в разы больше, в зависимости от коэффициента масштабирования экрана.
Например, для десятого айфона макет рисуется под 375рх, а на выходе рендерится картинка с разрешением 1125px по ширине. 😊
не то же самое, что ширина в CSS
я в курсе, потому и назвал ~их использование в медиа антипатерном
Что касается
handheld
вторую часть строки кому писал? *2
фраза "для новых браузеров" как бы на что-то намекает, не?
Есть media queries - -webkit-device-pixel-ratio который позволяет отслеживать устройства с различным количеством точек на пиксель
https://developer.mozilla.org/en-US/docs/Web/CSS@mediaa/-webkit-device-pixel-ratio
Давай обнимемся, бро!
Если есть макет с размерами 360, 1024 и 1440, то на каких размерах принято переходить на мобилку, на каких на десктоп?
Это, вообще, бич времён. По своему опыту могу сказать, что может быть как угодно! Есть дизайнеры, которые отрисовывая три брейкпоинта, совершенно не обращают внимание на пограничные состояния.
Я в таких случаях пытаюсь объяснять, что макет под 360px в разрешении 1023px будет выглядеть, мягко говоря, не очень.
Встречались какие-то варианты с ограничением по ширине блоков или с ограничением сетки на 640px в промежутке между 360-1023.
Но, как правило, такие макеты делаются в дикой спешке и приходится допиливать на лету исходя из предыдущих макетов того же автора, это если они есть. А если подсказок нет, то тупо собираю макет на 360 под 1023 и тыкаю пальцем. Ибо потом можно воткнуть ограничитель куда-нибудь и все. Чаще всего народ кивает и машет рукой.
В любом случае спорные моменты стоит обсуждать с дизайнером/заказчиком, чтобы потом не было претензий.
В промежутке между 360рх и 1024рх, стоит добавить размер 768рх, например. Могут быть любые приемлимые значения.
Касаемо десктопных макетов также могут быть разные макеты для небольшого экрана и для крупных экранов. Все зависит от сложности проекта.
Кроме того, бывают разные подходы к подготовке адаптивных макетов, может быть респонсив, может быть адаптивный дизайн, может быть вообще отдельная версия сайта для мобилки и планшета.
Вижу, что тема с подготовкой размеров экранов довольно интересна и работа с адаптивным в целом. Думаю, есть смысл подготовить отдельные публикации на эти темы. 😊
Я как-то задавался подобными вопросами. Выкрутился, задав в медиазапросах размеры в сантиметрах. Но это для случая, когда не используется Bootstrap — с бутстрапом использую встроенные в него значения.
Как передавать макеты в разработку?