А самое интересное – что этот дизайн-паттерн поощряется самим софтом для разработки интерфейсов. И фотошоп, и иллюстратор, и фигма, и скетч – все предлагают не браузерные, а «экранные» разрешения, никто даже не напоминает о том, что «эй, ребят, не забудьте, что там ещё браузер и ОС отожрут 200 пикселей, не надо дизайнить десктоп в 16:9».
Не поддавайтесь: дизайн под FullHD – это где-то 1900×800, а под ноутбук – 1340×600.
Не поддавайтесь: дизайн под FullHD – это где-то 1900×800, а под ноутбук – 1340×600.
Не шуметь
Начитавшись Дорофеева и других сенсеев эффективности, я выпилил себе все звуковые уведомления на телефоне и постоянно отстреливаю все источники всплывающих карточек и непрошенных свистопердений.
И мне кажется, что это нормально и так делают все.
Но выходя на улицу и общаясь с другими людьми, я вижу, что очень и очень многие не понимают, что внимание – такой же ценный ресурс, как, например, время или деньги.
Они получают по 180 уведомлений в час и в потоковом режиме их обрабатывают – а потом жалуются, что у них нет ни сил, ни возможности сосредоточиться на чём-то сложнее одноклеточных трудовых операций и одноклеточных же развлечений.
Шаг первый: надо отнять у приложений и сайтов возможность инициировать взаимодействие с ними. Кто-то поставил лайк твоему посту в инстаграме, кто-то подписался на тебя вконтакте, кто-то написал в канальчик в тележке – не повод для сервиса начать разговор со мной. Не заблуждайтесь: это не человек с вами пытается заговорить, это приложение тянет вас в пучину бесконечного скролла.
Цените своё внимание и концентрацию.
Шаг второй: надо делать меньше шума. Не выходите из старых чатов, не создавайте новых без нужды, не подходите к коллеге, не договорившись предварительно о разговоре. И отключите звуки на телефоне – если не для себя, то хотя бы для других.
Цените внимание и концентрацию окружающих.
Давайте, пожалуйста, не шуметь.
Начитавшись Дорофеева и других сенсеев эффективности, я выпилил себе все звуковые уведомления на телефоне и постоянно отстреливаю все источники всплывающих карточек и непрошенных свистопердений.
И мне кажется, что это нормально и так делают все.
Но выходя на улицу и общаясь с другими людьми, я вижу, что очень и очень многие не понимают, что внимание – такой же ценный ресурс, как, например, время или деньги.
Они получают по 180 уведомлений в час и в потоковом режиме их обрабатывают – а потом жалуются, что у них нет ни сил, ни возможности сосредоточиться на чём-то сложнее одноклеточных трудовых операций и одноклеточных же развлечений.
Шаг первый: надо отнять у приложений и сайтов возможность инициировать взаимодействие с ними. Кто-то поставил лайк твоему посту в инстаграме, кто-то подписался на тебя вконтакте, кто-то написал в канальчик в тележке – не повод для сервиса начать разговор со мной. Не заблуждайтесь: это не человек с вами пытается заговорить, это приложение тянет вас в пучину бесконечного скролла.
Цените своё внимание и концентрацию.
Шаг второй: надо делать меньше шума. Не выходите из старых чатов, не создавайте новых без нужды, не подходите к коллеге, не договорившись предварительно о разговоре. И отключите звуки на телефоне – если не для себя, то хотя бы для других.
Цените внимание и концентрацию окружающих.
Давайте, пожалуйста, не шуметь.
Увеличить в два раза
Дизайнер сверстал буклет с текстом размером восемь пунктов. Заказчик сказал: мелко, увеличьте текст в два раза. Дизайнер переверстал всё шрифтом в 16 пунктов. Буклет как был нечитаемым, так и остался: теперь чтобы что-то прочесть, надо отойти на полтора метра.
Почему так вышло?
Заказчик говорит про количественные характеристики: увеличить в два раза, – хотя имеет в виду качественные: сделайте, чтобы не надо было блин глаза ломать! Но неправильная формулировка требований не делает заказчика виноватым: он и не обязан представлять себе, чем восьмой кегль отличается от шестнадцатого. Заказчик подал дизайнеру на вход ошибку, а тот не отфильтровал её.
Джуниор и не обязан: до него не должно доходить коммуникационных ошибок, у него для этого есть старшие и менеджеры.
Мид чувствует, что тут что-то не так, делает одну страницу 16 кеглем и отправляет её обратно для согласования: вы точно вот этого хотите?
Старший диз ничего не переспрашивает, печатает себе на пробу макет с 8 кеглем, с 10 и 11, смотрит на них и переверстывает макет одиннадцатым, потому что он читается в два раза лучше.
Заказчик не враг: он просто не дизайнер, и выражает свои мысли как может. Понять, что он имеет в виду – часть работы дизайнера.
Дизайнер сверстал буклет с текстом размером восемь пунктов. Заказчик сказал: мелко, увеличьте текст в два раза. Дизайнер переверстал всё шрифтом в 16 пунктов. Буклет как был нечитаемым, так и остался: теперь чтобы что-то прочесть, надо отойти на полтора метра.
Почему так вышло?
Заказчик говорит про количественные характеристики: увеличить в два раза, – хотя имеет в виду качественные: сделайте, чтобы не надо было блин глаза ломать! Но неправильная формулировка требований не делает заказчика виноватым: он и не обязан представлять себе, чем восьмой кегль отличается от шестнадцатого. Заказчик подал дизайнеру на вход ошибку, а тот не отфильтровал её.
Джуниор и не обязан: до него не должно доходить коммуникационных ошибок, у него для этого есть старшие и менеджеры.
Мид чувствует, что тут что-то не так, делает одну страницу 16 кеглем и отправляет её обратно для согласования: вы точно вот этого хотите?
Старший диз ничего не переспрашивает, печатает себе на пробу макет с 8 кеглем, с 10 и 11, смотрит на них и переверстывает макет одиннадцатым, потому что он читается в два раза лучше.
Заказчик не враг: он просто не дизайнер, и выражает свои мысли как может. Понять, что он имеет в виду – часть работы дизайнера.
Отдельный человек
Только начав принимать и комментировать чужие макеты, я понял, насколько важно самому не трогать исходники. Оценивать результат должен отдельный, отвлечённый от непосредственного производства человек.
Когда не закапываешься в инструмент и не думаешь о технической реализации, видишь общую картину и можешь её корректировать, не задумываясь о том, как эти изменения будут реализованы технически.
Как только открываешь исходник и начинаешь самостоятельно в нем копаться – сразу же рискуешь стать заложником принятых технических решений. При этом чем дольше работаешь с макетом, тем сильнее симпатия к нему, каким бы ужасным он на самом деле ни был – прямо как при стокгольмском синдроме.
Если вы дизайнер и у вас есть падаваны – не доделывайте макеты за них. Во-первых, так они будут становиться самостоятельнее, а во-вторых, вы не разменяете общее видение на структуру стилей абзацев в индизайне. Но обращайте внимание, если ваши комментарии встречают большое сопротивление – возможно, со структурой макета что-то неладно, и простые правки займут неоправданно много времени. В этом случае надо смотреть, что экономически выгоднее: а) забить на правки и сдать макет как есть, б) внести правки «грязно» или в) сесть рядом и помочь навести порядок в структуре макета. Но только при третьем варианте технический долг не создаётся, а сокращается.
Если вы дизайнер и вам приходят правки – пересиливайте себя и вносите (я не говорю здесь про объективно неадекватные правки, это отдельная тема). Знакомая ситуация: смотришь макет, который сделал месяц назад, и всё там не так? Вот: со стороны реально виднее. Но если при обработке комментов чувствуется, как что-то идёт не так, что начинается перерасход рабочего времени или для внесения правок придется сильно менять макет или вообще переделывать его – сообщайте об этом наверх и решайте проблему.
Для принятия макетов нужен отдельный человек, потому что в клинче с макетом общая картина выходит из поля зрения.
Только начав принимать и комментировать чужие макеты, я понял, насколько важно самому не трогать исходники. Оценивать результат должен отдельный, отвлечённый от непосредственного производства человек.
Когда не закапываешься в инструмент и не думаешь о технической реализации, видишь общую картину и можешь её корректировать, не задумываясь о том, как эти изменения будут реализованы технически.
Как только открываешь исходник и начинаешь самостоятельно в нем копаться – сразу же рискуешь стать заложником принятых технических решений. При этом чем дольше работаешь с макетом, тем сильнее симпатия к нему, каким бы ужасным он на самом деле ни был – прямо как при стокгольмском синдроме.
Если вы дизайнер и у вас есть падаваны – не доделывайте макеты за них. Во-первых, так они будут становиться самостоятельнее, а во-вторых, вы не разменяете общее видение на структуру стилей абзацев в индизайне. Но обращайте внимание, если ваши комментарии встречают большое сопротивление – возможно, со структурой макета что-то неладно, и простые правки займут неоправданно много времени. В этом случае надо смотреть, что экономически выгоднее: а) забить на правки и сдать макет как есть, б) внести правки «грязно» или в) сесть рядом и помочь навести порядок в структуре макета. Но только при третьем варианте технический долг не создаётся, а сокращается.
Если вы дизайнер и вам приходят правки – пересиливайте себя и вносите (я не говорю здесь про объективно неадекватные правки, это отдельная тема). Знакомая ситуация: смотришь макет, который сделал месяц назад, и всё там не так? Вот: со стороны реально виднее. Но если при обработке комментов чувствуется, как что-то идёт не так, что начинается перерасход рабочего времени или для внесения правок придется сильно менять макет или вообще переделывать его – сообщайте об этом наверх и решайте проблему.
Для принятия макетов нужен отдельный человек, потому что в клинче с макетом общая картина выходит из поля зрения.
Перечитал предыдущий пост и обратил внимание, что у меня смешались обращения на «ты» и на «вы». Начал править – но всё не так становится сразу. Начал разбираться, выяснил: обращаюсь к читателю я на «вы», а всякие там «видишь, открываешь» – это повествование во втором лице, как будто я встаю на место читателя. И тут уже уместно обращение на «ты»: к себе же никто на «вы» не обращается.
Во как.
Во как.
Файловый хостинг на Dropbox
В небольших проектах на Тильде или Редимаге, когда нет возможности залить файлы на сервер и получить прямую ссылку, можно использовать в качестве хостинга дропбокс. Для того, чтобы он отправил по запросу чистый файл, а не пользовательский html-интерфейс, в конце ссылки надо дописать
UPD
В чате Ne_znal_talk подсказали, что для достижения такого же результата можно ещё заменить в адресе ссылки домен с
В небольших проектах на Тильде или Редимаге, когда нет возможности залить файлы на сервер и получить прямую ссылку, можно использовать в качестве хостинга дропбокс. Для того, чтобы он отправил по запросу чистый файл, а не пользовательский html-интерфейс, в конце ссылки надо дописать
?raw=1. Например:https://www.dropbox.com/s/sltez4uqjv1bdqx/TicksAndTrips-03.jpg?raw=1
Так можно обойти ограничения по размеру изображений (Тильда, например, режет всё до 1680px) или вставить видео безо всяких ютьюбовских/вимеовских обёрток/сжатий.UPD
В чате Ne_znal_talk подсказали, что для достижения такого же результата можно ещё заменить в адресе ссылки домен с
www.dropbox.com на dl.dropboxusercontent.com – и ничего в конце не дописывать:https://dl.dropboxusercontent.com/s/sltez4uqjv1bdqx/TicksAndTrips-03.jpgBetter web typography
Перевёл замечательную памятку Матежа Латина (Matej Latin), создателя сайта betterwebtype.com и автора книги Better Web Typography For Better Web.
В ней собраны все основы работы со шрифтами, базовые понятия типографики и правила набора, описаны самые часто используемые фичи OpenType.
При переводе расширены некоторые пункты, добавлены иллюстрации к классификации шрифтов и локализованы региональные особенности набора. Все изменения и публикация одобрены автором.
Качайте, печатайте, держите под рукой :)
UPD
Памятка обновлена и теперь содержит актуальный набор настроек типографики из фигмы.
Перевёл замечательную памятку Матежа Латина (Matej Latin), создателя сайта betterwebtype.com и автора книги Better Web Typography For Better Web.
В ней собраны все основы работы со шрифтами, базовые понятия типографики и правила набора, описаны самые часто используемые фичи OpenType.
При переводе расширены некоторые пункты, добавлены иллюстрации к классификации шрифтов и локализованы региональные особенности набора. Все изменения и публикация одобрены автором.
Качайте, печатайте, держите под рукой :)
UPD
Памятка обновлена и теперь содержит актуальный набор настроек типографики из фигмы.
Dropbox
[RU] BetterWebTypeCheatsheet.pdf
Shared with Dropbox
Фигма переработала и расширила инструментарий работы с типографикой! Поиграть с новыми опциями можно по ссылке: https://www.figma.com/file/I7aquUJskPWwudWatNjfkC/Figma-OpenType-playground/duplicate
UPD
Памятка обновлена. Теперь она рассказывет об актуальных настройках шрифтов в фигме.
UPD
Памятка обновлена. Теперь она рассказывет об актуальных настройках шрифтов в фигме.
Вычисление оптимального DPI
Когда-то давно наткнулся на такую формулу для определения разрешения растровых макетов:
Несколько дней назад задался вопросом, откуда взялось 180 – и решил посчитать. Что там сложного – базовая тригонометрия, да пропорцию решить. Остроту зрения я помнил из «Занимательной Геометрии» Перельмана, тангенс одной угловой минуты я посчитал... а дальше аж теорема про дискретизацию аналоговых сигналов вылезла. В общем, если кому-то интересно, почему там именно 180 – читайте на Оди :)
Когда-то давно наткнулся на такую формулу для определения разрешения растровых макетов:
dpi = 180/D
где D – минимальное расстояние в метрах, на котором будет рассматриваться готовый материал.Несколько дней назад задался вопросом, откуда взялось 180 – и решил посчитать. Что там сложного – базовая тригонометрия, да пропорцию решить. Остроту зрения я помнил из «Занимательной Геометрии» Перельмана, тангенс одной угловой минуты я посчитал... а дальше аж теорема про дискретизацию аналоговых сигналов вылезла. В общем, если кому-то интересно, почему там именно 180 – читайте на Оди :)
Сглаживание углов в Web
Уже много написано про неприятные скругления углов (первое, что приходит на ум – вот эта статья Бирмана), но в вебе решения «из коробки» ещё нет.
В одном из проектов мне очень хочется использовать плавные скругления (без них вообще не то), и я решил погуглить, что вообще придумали. Нашёл вот такую статью на медиуме. Да, работает, но кривит-то прям от середины сторон! А мне надо, чтобы только уголки.
В общем, сел, разобрался, как работает noscript, модифицировал код и получил что-то похожее на правду. Понятно, что это не production-ready решение, но по крайней мере есть что показать разработчикам.
Уже много написано про неприятные скругления углов (первое, что приходит на ум – вот эта статья Бирмана), но в вебе решения «из коробки» ещё нет.
В одном из проектов мне очень хочется использовать плавные скругления (без них вообще не то), и я решил погуглить, что вообще придумали. Нашёл вот такую статью на медиуме. Да, работает, но кривит-то прям от середины сторон! А мне надо, чтобы только уголки.
В общем, сел, разобрался, как работает noscript, модифицировал код и получил что-то похожее на правду. Понятно, что это не production-ready решение, но по крайней мере есть что показать разработчикам.
Каким устройством ввода вы преимущественно пользуетесь для работы?
Anonymous Poll
67%
Мышь
12%
Планшет
21%
Тачпад
0%
Другое
Абсолютное позиционирование
Я очень долго работал мышью и только какие-то рисунки делал на планшете. Потом решился-таки полностью перейти на планшет – и не пожалел.
Планшету иногда не хватает скролла, но в целом это компенсируется удобством абсолютного позиционирования – каждая точка экрана соответствует определённой точке поверхности планшета – при перетягиваниях и протяжках на планшете никогда не нужно «перехватывать» курсор.
Да, попасть в отдельный пиксель может быть трудно из-за смещения курсора при касании пером, но во-первых, это нужно гораздо реже, чем кажется на первый взгляд, а во-вторых, это дело привычки. Мне потребовалось две недели, чтобы я привык настолько, чтобы работа с мышью стала по ощущениям как будто в варежках.
По моему опыту для не-иллюстраторской работы на стандартном мониторе 16:9 достаточно размера S (примерно А5). Для мониторов пошире (типа 21:9) лучше брать M – но обязательно в настройках включить сохранение пропорций.
Если вы сомневаетесь – то обязательно попробуйте, никто вам не скажет, понравится ли вам работать с планшетом. Но если уж понравится, то понравится прям изо всех сил :)
Я очень долго работал мышью и только какие-то рисунки делал на планшете. Потом решился-таки полностью перейти на планшет – и не пожалел.
Планшету иногда не хватает скролла, но в целом это компенсируется удобством абсолютного позиционирования – каждая точка экрана соответствует определённой точке поверхности планшета – при перетягиваниях и протяжках на планшете никогда не нужно «перехватывать» курсор.
Да, попасть в отдельный пиксель может быть трудно из-за смещения курсора при касании пером, но во-первых, это нужно гораздо реже, чем кажется на первый взгляд, а во-вторых, это дело привычки. Мне потребовалось две недели, чтобы я привык настолько, чтобы работа с мышью стала по ощущениям как будто в варежках.
По моему опыту для не-иллюстраторской работы на стандартном мониторе 16:9 достаточно размера S (примерно А5). Для мониторов пошире (типа 21:9) лучше брать M – но обязательно в настройках включить сохранение пропорций.
Если вы сомневаетесь – то обязательно попробуйте, никто вам не скажет, понравится ли вам работать с планшетом. Но если уж понравится, то понравится прям изо всех сил :)
Про сделывание
Одна дизайн-студия в рассылке поделилась историей: заказчик решил отдать реализацию их дизайна другим разработчикам, и все их тщательно проработанные микровзаимодействия и анимации пошли лесом. Вот, мол, сравните наш классный проектик на бихенсе с тем, что вышло в итоге: разработчики не сумели.
Я вижу в этой ситуации во-превых, громадную проблему в коммуникации между дизайнером, заказчиком и разработчиком, а во-вторых, разницу между «делать» и «сделать».
Если у дизайнера заказывают сайт, то он должен сделать красивое и удобное решение задачи заказчика. Сделать значит 1) придумать и 2) реализовать. Если дизайнеру не дают права на выбор разработчиков, он должен отказаться от проекта. Если он не может себе этого позволить, то должен топить за возможность общаться с разработкой. Если и ему не дают и этого (а отказаться от проекта он всё-таки не в силах), дизайнер должен задокументировать каждый ховер, каждый фрейм, каждый изинг, каждую анимацию, каждую свистелку и каждую перделку. Потому что непосредственного контроля над разработкой у него нет, а ответственность за результат он несёт. Если в итоге получится не то, что задумано – значит, дизайнер не справился. Делал, но не сделал.
Да, ситуации бывают разные, переговоры не всегда складываются удачно, но мне кажется неэтичным выкладывать себе в портфолио рисунки решения задачи, которого в итоге у заказчика нет.
Одна дизайн-студия в рассылке поделилась историей: заказчик решил отдать реализацию их дизайна другим разработчикам, и все их тщательно проработанные микровзаимодействия и анимации пошли лесом. Вот, мол, сравните наш классный проектик на бихенсе с тем, что вышло в итоге: разработчики не сумели.
Я вижу в этой ситуации во-превых, громадную проблему в коммуникации между дизайнером, заказчиком и разработчиком, а во-вторых, разницу между «делать» и «сделать».
Если у дизайнера заказывают сайт, то он должен сделать красивое и удобное решение задачи заказчика. Сделать значит 1) придумать и 2) реализовать. Если дизайнеру не дают права на выбор разработчиков, он должен отказаться от проекта. Если он не может себе этого позволить, то должен топить за возможность общаться с разработкой. Если и ему не дают и этого (а отказаться от проекта он всё-таки не в силах), дизайнер должен задокументировать каждый ховер, каждый фрейм, каждый изинг, каждую анимацию, каждую свистелку и каждую перделку. Потому что непосредственного контроля над разработкой у него нет, а ответственность за результат он несёт. Если в итоге получится не то, что задумано – значит, дизайнер не справился. Делал, но не сделал.
Да, ситуации бывают разные, переговоры не всегда складываются удачно, но мне кажется неэтичным выкладывать себе в портфолио рисунки решения задачи, которого в итоге у заказчика нет.
Анонс
Обновили свой сайт и выложили несколько новых проектов – а значит, есть о чём рассказать: и про анимацию на главной нашего сайта, и про разработку сайта Gratar, и про пару логотипов, о которых ещё не рассказывал.
Stay tuned!
Обновили свой сайт и выложили несколько новых проектов – а значит, есть о чём рассказать: и про анимацию на главной нашего сайта, и про разработку сайта Gratar, и про пару логотипов, о которых ещё не рассказывал.
Stay tuned!
owlagency.ru
Главная | OWL agency - разработка сайтов, дизайн, маркетинг, коммуникации
Студия дизайна и разработки. Коммуникации, брендинг, дизайн и разработка сайтов.
Привязка к сетке
Иногда случается, что дизайн выглядит хорошо и структурированно, но как только выключаешь сетку, всё начинает разваливаться. Чтобы так не было, чаще задавайте себе вопрос: к чему привязано положение объекта? Ответ «к сетке» – неправильный. Правильные ответы: к заголовку, к углу, к кнопке, к картинке, к тексту. По сетке можно только выравнивать. Если что-то к сетке привязано, то при её скрытии всё рассыпется.
(Картинки взяты из статьи Игоря Штанга – ссылка ниже, – в которой он формулирует один из основных принципов вёрстки: «сначала конструкция, потом сетка». Этот принцип работает не только для печатных макетов, но и для интерфейсов)
Иногда случается, что дизайн выглядит хорошо и структурированно, но как только выключаешь сетку, всё начинает разваливаться. Чтобы так не было, чаще задавайте себе вопрос: к чему привязано положение объекта? Ответ «к сетке» – неправильный. Правильные ответы: к заголовку, к углу, к кнопке, к картинке, к тексту. По сетке можно только выравнивать. Если что-то к сетке привязано, то при её скрытии всё рассыпется.
(Картинки взяты из статьи Игоря Штанга – ссылка ниже, – в которой он формулирует один из основных принципов вёрстки: «сначала конструкция, потом сетка». Этот принцип работает не только для печатных макетов, но и для интерфейсов)