This media is not supported in your browser
VIEW IN TELEGRAM
сегодня Серёжа Николаев опубликовал свой скрипт плавного скругления углов для иллюстратора, а с ним еще и научно-познавательную статью про плавное скругление и важность его в дизайне. горячо рекомендую
https://kefiijrw.medium.com/
https://kefiijrw.medium.com/
придумал самую честную схему продажи своих курсов: верну полную стоимость курса каждому, кто дойдёт до конца — выполнит цель (кейс на бехе в минимально приличном виде) и не нарушит дедлайнов. как вам?
висячие предлоги.
— Лебедев, на которого ссылаются, когда говорят, что переносить предлоги обязательно: «Строгих правил переноса нет, все они носят рекомендательный характер»
↗ ссылка
— Илья Бирман: «В самих языках, хоть русском, хоть английском, бывает слитное или раздельное написание, но не бывает неразрывных пробелов»
↗ ссылка
— чел из интернета, предлагающий, на мой взгляд, самое универсальное правило: «Уместно оставлять висячие предлоги на более коротких строчках и переносить с более длинных»
↗ ссылка
∮
еще пытался найти об этом что-то в «Справочнике издателя и автора» Мильчина, но не нашел.
∯
еще часто можно услышать, что висячие предлоги ломают ритм и усложняют чтение. хотя это почему-то распространяется на сайты и книги, но никаких проблем, те же люди, с чтением каналов и переписок в мессенджерах не испытывают.
∰
выходит, борьба с висячими предлогами — это просто защита традиций? стоит ли в таком случае делать выводы о компетентности дизайнера только потому, что он не переносит предлоги?
— Лебедев, на которого ссылаются, когда говорят, что переносить предлоги обязательно: «Строгих правил переноса нет, все они носят рекомендательный характер»
↗ ссылка
— Илья Бирман: «В самих языках, хоть русском, хоть английском, бывает слитное или раздельное написание, но не бывает неразрывных пробелов»
↗ ссылка
— чел из интернета, предлагающий, на мой взгляд, самое универсальное правило: «Уместно оставлять висячие предлоги на более коротких строчках и переносить с более длинных»
↗ ссылка
∮
еще пытался найти об этом что-то в «Справочнике издателя и автора» Мильчина, но не нашел.
∯
еще часто можно услышать, что висячие предлоги ломают ритм и усложняют чтение. хотя это почему-то распространяется на сайты и книги, но никаких проблем, те же люди, с чтением каналов и переписок в мессенджерах не испытывают.
∰
выходит, борьба с висячими предлогами — это просто защита традиций? стоит ли в таком случае делать выводы о компетентности дизайнера только потому, что он не переносит предлоги?
↑ обратите внимание на примеры выше. Дима использует висячие предлоги, как инструмент контроля выразительности.
там, где в заголовке пять строк — все предлоги перенесены для усиления контраста строк по длине. это делает блок более интересным, более острым.
а на другой странице, где к заголовку добавляются ещё две строчки сверху, такое чередование длин стало бы уже избыточным и назойливым. поэтому Дима, для успокоения, в конце, оставляет «для» на предыдущей строке. это позволяет сохранить баланс остроты и спокойствия.
там, где в заголовке пять строк — все предлоги перенесены для усиления контраста строк по длине. это делает блок более интересным, более острым.
а на другой странице, где к заголовку добавляются ещё две строчки сверху, такое чередование длин стало бы уже избыточным и назойливым. поэтому Дима, для успокоения, в конце, оставляет «для» на предыдущей строке. это позволяет сохранить баланс остроты и спокойствия.
Saucony Fresh Rags Grid Web Manatee (необычные, прикольно)
https://sneakerhead.ru/shoes/sneakers/grid-web-S705981/
https://sneakerhead.ru/shoes/sneakers/grid-web-S705981/
доступно о мегапикселях в камерах телефонов https://www.youtube.com/watch?v=M2l9W7P8-gk
YouTube
Мегапиксели: зачем смартфону 200?
Сперва мегапикселями хвастались мыльницы и иногда взрослые фотоаппараты, а теперь смартфоны всех перегнали и Samsung показывает сенсор на двести мегапикселей. Кто-то утверждает, что это улучшит качество фото, кто-то говорит, что это только добавит шумов.…
тестовые задания.
тестовые задания для дизайнеров условно можно разделить на два типа: «покажи, как ты делаешь» и «покажи, как ты думаешь».
текст задания первого типа «покажи, как ты делаешь» достаточно конкретный: есть такая-то проблема/задача и такой контекст; предложи несколько решений, расскажи как ты к ним пришел, чем они хороши и как ты будешь это проверять; на это у тебя должно уйти примерно столько-то времени; результат в фигме + ноушен.
еще круче, когда задание не завязано на какой-то конкретный продукт. например, однажды я делал тестовое в еду яндекса и оно звучало так: напиши лонгрид о своем лучшем продуктовом опыте, расскажи в деталях, как шла работа и к какому результату пришли.
такие тестовые, если сделать хорошо, то в дальнейшем можно переиспользовать — положить в портфолио, например. лонгрид для яндекса я до сих пор отправляю со своим портфолио, как пример моего продуктового опыта.
текст задания второго типа «покажи, как ты думаешь» обычно давольно размытый: есть такая-то проблема/задача — расскажи как ты будешь ее решать. объем работы и в каком виде будет решение ты определяешь сам. о чем важно не забыть и что важно проработать дополнительно, а что и так понятно — все сам. из опорных точек у тебя есть только твой предыдущий опыт.
плюс первого типа «покажи, как ты делаешь» в том, что он близок к реальным условиям дизайнерской работы: даже если ты берешься за что-то новое, у тебя есть понятный контекст и ты знаешь, какой результат и в каком виде от тебя ждут.
минус второго «покажи, как ты думаешь», что тебе нужно угадать, что от тебя ждут. у всех компаний, даже если в общих чертах кажется, что процессы выстроены похоже, если рассматривать в деталях — очень много нюансов. стандарта нет и у каждого работодателя есть какое-то собственное представление о приоритетах (ui, ux, консистентность, масштабируемость, оригинальность решения, аккуратность в макетах, ёмкость описания, степень проработки с точки зрения рынка конкурентов и позиционирования в нем и т. д.) и об идеальном процессе.
повезет, если в твоей предыдущей компании процессы и приоритеты были схожие. тогда ты, возможно, автоматически,
выполняя тестовое, пойдешь привычным путем и сделаешь так, как надо. а если нет — прости, не угадал, мы ждали вот так и так.
при этом развернутый фидбек по такой задаче, если его вообще дадут, на 90% будет применим к ожиданиям конкретно этой компании по этому тестовому. максимальная польза от которого будет только если ты придумаешь, как отправить его себе в прошлое.
∮
но, к сожалению, правда в том, что рынок перенасыщен дизайнерами и работодатель может себе позволить не заморачиваться о качестве своих тестовых и о времени людей, которые будут его делать. хочешь не хочешь, но с этим придется столкнуться. и единственное правильное решение здесь — не унывать и продолжать. ну и, при возможности, стараться уточнять, что конкретно от тебя ждут.
тестовые задания для дизайнеров условно можно разделить на два типа: «покажи, как ты делаешь» и «покажи, как ты думаешь».
текст задания первого типа «покажи, как ты делаешь» достаточно конкретный: есть такая-то проблема/задача и такой контекст; предложи несколько решений, расскажи как ты к ним пришел, чем они хороши и как ты будешь это проверять; на это у тебя должно уйти примерно столько-то времени; результат в фигме + ноушен.
еще круче, когда задание не завязано на какой-то конкретный продукт. например, однажды я делал тестовое в еду яндекса и оно звучало так: напиши лонгрид о своем лучшем продуктовом опыте, расскажи в деталях, как шла работа и к какому результату пришли.
такие тестовые, если сделать хорошо, то в дальнейшем можно переиспользовать — положить в портфолио, например. лонгрид для яндекса я до сих пор отправляю со своим портфолио, как пример моего продуктового опыта.
текст задания второго типа «покажи, как ты думаешь» обычно давольно размытый: есть такая-то проблема/задача — расскажи как ты будешь ее решать. объем работы и в каком виде будет решение ты определяешь сам. о чем важно не забыть и что важно проработать дополнительно, а что и так понятно — все сам. из опорных точек у тебя есть только твой предыдущий опыт.
плюс первого типа «покажи, как ты делаешь» в том, что он близок к реальным условиям дизайнерской работы: даже если ты берешься за что-то новое, у тебя есть понятный контекст и ты знаешь, какой результат и в каком виде от тебя ждут.
минус второго «покажи, как ты думаешь», что тебе нужно угадать, что от тебя ждут. у всех компаний, даже если в общих чертах кажется, что процессы выстроены похоже, если рассматривать в деталях — очень много нюансов. стандарта нет и у каждого работодателя есть какое-то собственное представление о приоритетах (ui, ux, консистентность, масштабируемость, оригинальность решения, аккуратность в макетах, ёмкость описания, степень проработки с точки зрения рынка конкурентов и позиционирования в нем и т. д.) и об идеальном процессе.
повезет, если в твоей предыдущей компании процессы и приоритеты были схожие. тогда ты, возможно, автоматически,
выполняя тестовое, пойдешь привычным путем и сделаешь так, как надо. а если нет — прости, не угадал, мы ждали вот так и так.
при этом развернутый фидбек по такой задаче, если его вообще дадут, на 90% будет применим к ожиданиям конкретно этой компании по этому тестовому. максимальная польза от которого будет только если ты придумаешь, как отправить его себе в прошлое.
∮
но, к сожалению, правда в том, что рынок перенасыщен дизайнерами и работодатель может себе позволить не заморачиваться о качестве своих тестовых и о времени людей, которые будут его делать. хочешь не хочешь, но с этим придется столкнуться. и единственное правильное решение здесь — не унывать и продолжать. ну и, при возможности, стараться уточнять, что конкретно от тебя ждут.