Yuliaproject

Вышел Adobe Xd под Windows10.
Если не убийца Скетч, то точно сильный конкурент.
Единственный минус - пока все еще в статусе Beta.

Если есть подписка на Creative Cloud - он бесплатен. В остальных случаях - вы знаете что делать )))

Короткий ответ:
не рисуйте в Фотошопе — рисуйте в Adobe XD. И все вопросы про dpi отпадут сами по себе.

Более развёрнутый ответ:
как правильно заметил GreatRash, dpi не имеет значения. Главное — кол-во пикселей. Да и то, с такими динамичными интерфейсами и адаптивными сайтами которые востребованы сегодня даже пиксели "сдают позиции" и делят место с %.

Если отвечать на вопрос, то верстать нужно в том разрешении (в пикселях), которое показывает браузер. Например, если с обычными компьютерами все ясно: ширина экрана 1280px, значит и рисовать нужно в 1280. То с телефонами уже все не так очевидно. Например, физический размер экрана iPhone 6: 750x1334px. Но браузер на телефоне показывает сайт так как будто бы там вдвое меньше пикселей: 375x667px. То есть, если вы в макете нарисуете блок шириной 187px, то он займёт половину экрана на iPhone 6.
Есть отличный сайт, который показывает размеры экранов самых популярных мобильных устройств:

• их фактические размеры (первые две колонки)
  
• и размеры, которые "понимает" браузер (3 и 4 колонки — это то, что вам надо).
  

Почему Adobe XD? Потому что, зуб даю, через пару лет Adobe скажет:
— Ребята, мы убираем из Фотошопа все фишки, которые раньше помогали вам делать дизайн сайтов. Верстайте их теперь в XD. А мы оставим фотошоп для фотографов и иллюстраторов.

Дело в том, что Adobe XD — это их новая разработка для прототипирования (дизайна) сайтов. И разработка этой программы идёт полным ходом. Пока-что доступна только под Мак (к концу года будет Windows версия). В программе есть очень "вкусные" фишки, которые ускоряют работу в десятки раз. Посмотрите хотя бы эту GIF-ку ниже. А ещё сама программа очень быстро работает.



Есть еще Sketch. Он тоже создан специально для дизайна сайтов и только под Мак.
Сначала может быть трудновато привыкнуть к дизайну без Фотошопа, но оно того стоит, поверьте.

Философия:
Что такое дизайн сайта? И зачем думать про разрешение? И зачем вообще мы их рисуем?
После того как сайт сделан и проект закрыт, все PSD макеты дизайнера отправляются в архив и лежат там мертвым грузом десятки лет пока вы их не удалите. Рисунки никому не нужны — нужен сам сайт. А рисуем мы их для того, чтобы легче представить себе и показать верстальщику как сайт должен смотреться. То есть, если бы мы могли телепатически обьяснить верстальщику что и как должно выглядеть, то никто бы не занимался этой "ерундой" в Фотошопе. И это основная задача дизайнера: придумать как сайт должен выглядеть, анимироваться и взаимодействовать с юзером и передать это дальше в производство.

И тут ваша идеальная работа, как дизайнера, должна выглядеть так:

1. Вы рисуете страницу так как она должна выглядеть и выносите в отдельный документ (или слой) все размеры всех блоков, отступов, хедеров, футеров и пр. У вас должно получиться что-то вроде "чертежа" сайта с вашими комментариями;
   
2. Затем, в отдельное место выносите дизайны всех кнопок, полей для ввода текста, стили заголовков, аккордеонов, вкладок и всего остального что есть на вашем сайте;
   
3. Отдельно подготавливаете контент: текст и картинки. При этом желательно, чтобы картинки были сразу продублированы в нескольких размерах (в случае с адаптивными сайтами).
   
4. Все иконки — тоже отдельно. Векторные, в формате SVG, плюс PNG — для подстраховки при вёрстке.
   

Затем собираете это все в один портфель и несёте верстальщику. Он скажет вам большое спасибо и назовёт лучшим дизайнером в мире.

Для примера, касательно пункта 1, посмотрите как я обычно оформляю ТЗ для верстальщика. Это только две страницы из 20-ти.



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

Если предъявляете такие требования к исполнителям, то соответствуйте подобным требованиям как заказчик.

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

2. Предоплата обычное дело и это гарантия того, что время не будет потрачено зря. Боитесь — разделите на этапы. Сроки увеличаться, но лично вам будет спокойнее.

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

4. Любой уважающий себя специалист имеет несколько способов оплаты. Считаете какие-то не подходящими — не используйте. У Вебмани есть аттестаты и бизнес-уровень, у Яндекса идентифицированный счет, у ПейПал арбитраный сервис и гарантии, у банков тоже гарантии — все они достаточно надёжны.

Я всегда говорю что портфолио говорит само за себя и бесплатно не работаю. Никаких проблем уже давно не было. А если же хотите строго с тестовым и без предоплаты, то это только к новичкам со слабым портфолио, либо по знакомству с рекомендациями ищите. Хотя, исключения есть везде)

Забыл кое что. Специалиста видно всегда и по обсуждению проекта легко понять мошенник перед тобой или нет. Специалист будет говорить о задаче, о способах её решения, уточнять, спрашивать и т.п. Мне очень часто говорили что выбрали меня из-за подхода к делу.
Если же предлагается бюджет заметно ниже, сроки фантастически быстрые, обещание все сделать очень классно и попытка всеми способами поскорее «уйти в скайп» и начать работу, при этом предоплата озвучивается очень часто и настойчиво — перед вами, скорее всего мошенник. =)

Не совсем верно. Все зависит от начального дизайна. Следует учитывать, что требуется. Сегментированная адаптация или респонсиваня. Если сегментированая, то градации бутстрапа вполне подойдут. Если респонсивный, то в идеале продумывать его изначально, т.е. строить карту сжатия на листе и задавать ключевые параметры в ui гайде. Например у вас три блока одинаковой ширины. Ширина задается в процентах на верстке и нужно определить, какова минимально допустимая ширина этого блока. По достижении этой ширины блоки можно расположить друг под другом или же опустить один блок ниже, при этом задав размер им не в ~33% от размера рабочей области, а в 50%. И далее в таком ключе. Почему это важно? Потому что если это не сделать, то верстальщик либо вас доконает вопросами, либо сделает на свое усмотрение, в большинстве случаев плохо.

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

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

Респонсивный дизайн. Когда при верстке большая часть контента легко "сжимается" по ширине\высоте, подстраиваясь под размеры рабочей области. Вызывает проблему с неровным разбиением, что вынуждает предугадывать поведение блоков при изменении размеров экрана.
Пример:

UP.
Касательно отступов, то все на усмотрение дизайнера. В том же бутстрапе не составит труда переменить размеры отступов, несмотря на предложенные им 15px, иногда требуется 60, 30, 15 и все в одном макете. Все зависит от вашего умения и виденья

1) Зависит от проекта. Есть 2 большие группы студий: первые делают "шаблонные" сайты и cms используют всегда.
Вторые делают более сложные/нагруженные вещи - и там как правило используется фреймворк, зачастую свой собственный.
Отдельной группой стоят битриксоиды - они вставляют свой битрикс всюду, и пофиг что он начинает падать уже на смешных нагрузках. Зато энтерпрайзненько, сертификаты есть, клиентам нравится пока падать не начнет)

2) Если клиент не собирается развивать бекенд самостоятельно - ему по большому счету все равно на стек технологий, хотелки как максимум идут на уровне "где то слышал", бороться с этим легко.
Если ситуация иная, у клиента есть команда которая после Вас подхватит проект и есть претензии к Вашему стеку - с вероятностью процентов 90 это просто не Ваш клиент.

3) Никакого rocket science тут нет.
Общая цепочка всего проекта:
сбор функциональных требований > проектирование ux > дизайн > верстка > проектирование db > программирование backend.
С последними двумя пунктами, при наличии утвержденного дизайна, справится (так или иначе) любой человек называющий себя backend программистом.

По мере роста сложности проектов и разрастанию команды, Вам понадобятся лиды что бы контролировать качество кода разработчиков и архитектуру, QA что бы тестировать то что получилось, менеджеры что бы управлять потоком задач, ну и тех директор что бы выстроил весь этот процесс ;-)

По факту же, многие студий выстраиванием такого процесса не заморачиваются(он дорогой реально), а просто отдают готовую верстку разработчикам со словами "собери что бы работало". Серьезные проекты так не соберешь, а стандартные корпоративные сайтики, магазины итд - легко

Адаптировать или нет - зависит от проекта и, к сожалению, желания и бюджета заказчика. Не адаптивные проекты встречаются все реже, но и в них используем как минимум модульную сетку.
Количество контрольных точек, в которых перестраивается макет, и их значения зависят от дизайна, также бывают дополнительные медиа-запросы для элементов, которые на какой-то ширине/высоте начинают плохо выглядеть.
Основной принцип - конкретный дизайн должен хорошо выглядеть всегда, без привязки к размерам конкретного устройства (но дизайнеры все равно рисуют 320, 768 и "большой" - какой? по настроению дизайнера), все, что не нарисовано, додумывает верстальщик на ходу.
Элементы форм, анимацию, кнопки, ссылки - все, с чем взаимодействует пользователь, также делим по принципу тач/не тач.

На абстрактный ответ мог бы ответить абстрактно, но отвечу с вариантами.
В зависимости от задачи, я опишу не для сервисов или больших сайтов\ресурсов.
Советую так же прочесть вот эту статью: frontender.info/building-a-better-responsive-website

Обычно использую bootstrap, который дополняю своими стилями, к примеру, сразу удаляю\перекрываю .row с его -15px margin'ом по сторонам, добавляю класс padding-0 для убирания в некоторых блоках padding'a у col- (который стандартно по 15px).

Стандартно учитываю разрешения - HD, ноутбучное 1366 и свое чуть меньше 1366 (у меня пуск справа:) ), 1024-960 - старые мониторы и нетбуки, смотрю в диапазоне 768px-960 для некоторых планшетов и телефонов, и меньше 768 для телефонов. Тут дизайн один, через media onlyscreen убираем с загрузки ненужные части.
Если все сверстано правильно и добавлены везде классы, то сайт будет полностью адаптивным.
Для тестов меньше 768px проверяю через iphone 5 и старенький android-телефон. (Через Toggle Device mode в Google Chrome получаешь очень сильно разительные результаты в сравнении с устройством - браузеры то другие, хотя большие косяки всплывают сразу.)
Тут кстати еще (мобильная) кросс-браузерность очень тонкий вопрос. Стиль у каждого браузера свой, особенно у всяких элементов типа input, так что тоже требует проверки и состояний тоже (placeholder, цвет текста в поле).

Нужно ли это? Безусловно - на любом сайте, в любой отрасли половина трафика с мобильных устройств, это уже стандарт качества, на мой взгляд:)