• Собеседование в луже крови
    +1
    «Уважаемые господа, семечки в офисе есть запрещено!»
    (2013, офис клиента, объявление в приёмной. И рядом станина под штангу, поверх ковра :).
    Но самое смешное, что люди оказались хорошие.
  • Как оценить уровень владения английским языком
    +1
    Вообще, базовый словарный запас и грамматика — не совсем то же, что «уровень владения языком». Всё-таки реальное владение подразумевает понимание всяких речевых фишек: интонаций, метафор, фразеологизмов, сарказма и иронии, юмора, ситуативных реплик и т.п. И возможность использовать всё это самому.

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

    К слову, один знакомый Сергей рассказывал, как сдуру представился партнёрам Сержем (Serge) и потом вздрагивал в конфе каждый раз, когда кто-то упоминал поисковые системы (search). :) То есть оба слова вроде как прекрасно знакомы, но…

    Лично меня часто ставят в тупик реплики с идиомами или отсылками к зарубежным книгам/фильмам/поговоркам и т.п. Если их не знаешь, некоторые фразы выглядят ну прям очень странно :) Типа, когда тебе внезапно желают сломать ногу «Break a leg!», имея в виду «Удачи!».

    А самое смешное, что чем лучше владеешь родным языком, тем сложнее нормально общаться на другом. Потому что если привык думать точными формулировками и использовать образную речь, то при переходе на иностранный каждую фразу приходится сначала искусственно упрощать до уровня «моя-твоя-понимать». Очень неприятное ощущение, на грани беспомощности — как будто кусок личности ампутировали) Флирт, юмор, эрудиция — до свидания) Если привык ощущать себя хорошим собеседником, то довольно тяжко внезапно оказаться этаким говорящим поленом, которое в любой момент может ляпнуть что-то в духе «я есть Грут».

    Так что вокабуляр и грамматика — это прекрасно, но и питать иллюзии на этот счет не стоит) Полноценное владение языком для иностранца практически недостижимо, если сопоставлять с его же уровнем владения родным. Всегда будет существенно ниже, всегда secondary. Понятно, что русскоязычный профессор-гуманитарий наверняка сможет посостязаться в грамматике с англоговорящим гопарем, но вот при общении с нативом-профессором разница все равно останется заметной.
  • Как оценить уровень владения английским языком
    +6

    Тут нюанс есть: более-менее доброжелательные к вам нативы в любом случае ответят, что вы говорите, как минимум, хорошо. Независимо от того, как обстоят дела. Прямой ответ типа "всё плохо" считается невежливым и токсичным. Людей принято хвалить с сильным перекосом в позитив. Грубо говоря, их perfect и excellent — это примерно в диапазоне от "нормально" до "хорошо" (читайте, "нас устраивает"). "Отлично" выражают обычно дифирамбами, типа fantastic, amazing и т.п. Good — это примерно уровень "так себе". Ну а всякие там nice try и it's ok — это типовая реакция на провальные проекты, ошибки и т.п. В этом смысле спрашивать бесполезно, вам никогда не скажут прямо. Не принято. Культурные различия)

  • Базовые UI/UX паттерны
    +1
    Это позволит снизить порог входа, но не позволит сделать интерфейс удобнее, чем у конкурентов.

    Тут нет противоречия, если смотреть в корень. За любой удачной «новой» фишкой стоит заимствование из смежных отраслей или глобальных человеческих привычек. Это тоже использование поведенческих паттернов)

    По моим личным ощущениям, львиная доля косяков и проблем UX возникает именно там, где дизайнеры пытаются внедрять необкатанные теоретические удобства, не имеющие в основе устоявшихся паттернов. Фишки основанные на «здравом смысле», голой логике и т.п. постоянно вступают в противоречие с реалиями эксплуатации.

    Образно говоря, дизайнер-новатор старательно проектирует в столе «удобные» пазы под планшеты и чашки, а потом выясняется, что они мешают людям заниматься сексом) Все способы использования интерфейса вряд ли возможно предсказать на этапе проектирования. Невозможно теоретически вычислить идеальное расположение кнопки, потому что на практике люди могут держать телефон в двух руках, или в одной, или в зубах, или нажимать на нее ухом случайно, или коннектиться с утюга...) Все это вылезает только на практике и на больших выборках. Поэтому с точки зрения бизнеса выгодно использовать решения, которые опираются на обкатанные паттерны. В этом смысле всё сказанное выше верно.

    Это никак не ограничивает попытки сделать интерфейс удобнее, чем у конкурентов. Выбор тех или иных паттернов и определяет UX. Кто точнее попадет в привычки своих [потенциальных] пользователей, у того и получается удобнее. Собственно, это и есть суть UX в чистом виде. Мостить дорожки там, где люди уже ходят.
  • Ускоряемся в Figma. Нужно больше плагинов
    0
    Хм. Работает, проверил специально только что:

    (Слои внутри компонента Item, вложенного в компонент Items).

    Не работать может, например, если тестировать на мастер-компоненте. Мастер-компонент по умолчанию исключается из синхронизации, данные вставляются только в копии. (Можно изменить, добавив «+» перед названием).

    Еще там бывают заморочки с именованием родительских объектов и листов таблицы. Недавно схему чуток изменили, похоже. Теперь имя листа в родительских контейнерах указывается через двойной слеш, а не решётку: «Container \\my-sheet-name».

    Горячо рекомендую документацию вот эту, а не ту, которая в описании плагина. Сам не сразу ее обнаружил — много времени зря потратил)

    P.S. Ivan_Fil, спасибо за пост) Немного опередили, тоже думал на эту тему написать.

    Из крупных и интересных есть ещё:
    • Themer — сохраняет наборы стилей «Фигмы» через jsonbin. Это позволяет создавать светлые/темные темы в одном макете и переключаться между ними. Плагин сыроватый и немного замороченный, т.к. хранит данные на стороннем сервисе. Живых проектов на нём я ещё не пилил, но на своих тестовых пробовал — работает.
    • MapMaker — вставка карт на основе GoogleMaps или Mapbox. Использовал уже неоднократно, довольно полезный.
    • FontReplacer и FontFascia — для поиска из замены шрифтов в проекте. Удобно при копировании компонентов из одного проекта в другой, где отличается типографика. Плюс помогает находить слои и компоненты, в которых остался старый шрифт после каких-нибудь экспериментов и замен.
    • Similayer — позволяет выбирать на странице слои с одинаковыми свойствами (цвет, обводка, текстовые и т.п.). Помогает разгребать плохо структурированные макеты, где автор поленился или забыл объединить часть элементов в компоненты.


    Успехов!
  • Быстрое, удобное, адаптивное меню для 1075 категорий (36000 товаров)
    +3
    1. Меню такого объема лучше делать вертикальным: нет лимита по длине, избавляет от «Ещё...», можно интуитивно сортировать и фильтровать (расположив инпут/панель фильтров над меню). Плюс это позволит выполнить пункт 2.

    2. Минимальные габариты кликабельной плашки желательно делать такими, чтобы туда влезал палец (48x48 px и более). Это очень сильно снижает количество мискликов и, след-но, отказов. На десктопе тоже! Не забывайте, что не все люди обладают точной моторикой и зрением, а с возрастом всё это проседает. Чем старше аудитория, тем критичнее размеры областей клика.

    3. В идеале меню должно управляться и табуляцией. Включая перемещение по подпунктам с клавиатуры. У нас все забивают, но в зарубежных проектах это бывает базовым требованием. Там больше доля ридеров и всяких гаджетов, поэтому все помешаны на accessibility. В разметке желательно следить за семантикой (nav), в некоторых случаях внедрятьARIA-roles и т.д.

    4. Нежелательно делать «выворотку» (светлый текст на темном фоне) для светлых тем. Контраст цветов фона и текста лучше держать повыше (примерно как у вас в выделенных пунктах).

    5. Минимальный размер шрифта сейчас желательно делать минимум 16px для десктопа, причем брать гротески а не антиквы. Для сжатых и мелких гарнитур (Pt Sans и др) размер шрифта надо брать даже чуть больше — ~18 или выше.

    6. В меню такой вложенности желательно показывать кол-во дочерних элементов и товаров, особенно если вы требуете полный клик, чтобы показать подуровень. Иначе у вас будут ситуации, когда человек делает 3-6 кликов, а в итоге оказывается в пустой или почти пустой подподкатегории, где нечего выбирать.

    7. Желательно обрабатывать не только состояние hover, но и active и pressed/selected. Т.е. меню должно чем-то реагировать на нажатие и различать текущую цепочку навигации (на какой странице находимся) от простой подсветки пунктов при их просмотре (какой пункт меню под мышкой).

    8. Не очень удачно делать два ряда горизонтальных меню друг под другом. См п.1.

    9. Про скрытие меню по клику на оверлей (вне меню) уже написали выше. В идеале ещё по клавише Esc (и «назад» на телефонах)

    10. В идеале (без прямолинейного сео) вложенность основного меню надо уменьшать до 1-2 уровней. А более глубокую рубиркацию показывать после перехода внутрь. Точкой входа в магазин почти всегда становится не главная, а внутренняя страница. Т.е. человеку, который пришел по запросу «Сантехника», выгоднее на первом же уровне (без кликов) показать Унитазы и Раковины, а не Инструмент и Краску. Верхний уровень на внутряках как раз лучше показывать по прямому запросу, то есть по клику на общую кнопку типа «Все рубрики», «Полный каталог» и т.п.

    P.S. 36k — это не настолько много) Норма для большого тематического магазина. А ведь есть ещё гипермаркеты)

    Успехов!
  • Волновой метод построения цветовой гаммы
    +3
    Это очень прикольно в качестве гимнастики ума. Но палитры на выходе сами всё демонстрируют) Потому что в цветовосприятии важна не столько физика, сколько физиология.

    1. Восприятие цвета в спектре (в отличие от звука) дискретно или, точнее, неравномерно на разных участках в силу того, что число светочувствительных клеток-колб отличается. Поэтому, например, гармоничные сочетания из трех оттенков зелёной части спектра составить проще, чем миз жёлтой. А удачные сочетания чистых цветов не всегда остаются удачными при равномерном изменении их яркости или насыщенности. Плюс есть ещё культурные/эволюционные особенности, которые позволяют жителям джунглей различать больше оттенков зелёного, а жителям побережья — синего и т.д. Это мелочи но этот факт сам по себе ломает аналогию с музыкальными интервалами и четко показывает, что понятие гармонии опирается не на объективные метрические параметры, а на их восприятие и интерпретацию.

    2. На сайте результирующие цвета сплошь тёмные, даже для светлых образцов (в терминах HSB — brightness не бывает высокой, болтается внизу). Получается, что в этой системе не существует светлых чистых гамм.

    3. Аналогично с насыщенностью: saturation всегда выше среднего, даже если образец откровенно десатурированный, пастельный. Такая гамма разваливается, насыщенные цвета забивают пастельный. Примерно как при плохом сведении звука одни инструменты забивают другие.

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

    Словом, все это интересно, но немножко конь в вакууме. Пока что довольно далеко от прикладного дизайна.
  • Лети-лети лепесток… или сказ про то, как UX проектировщик свой продукт в Instagram продвигал
    +2
    Я не эксперт по Инсте, но в своё время был кое-какой опыт работы с продвижением разных штук в разных рынках. Заметки на полях:

    1. Строить гипотезы на малых выборках — вредно

    Когда вы оперируете единичными продажами, любое наблюдение будет в пределах случайности или погрешности. Ну то есть, если у вас 2 продажи и одну из них сделал, допустим, хромой пенсионер-кошатник — это вовсе не значит, что хромые пенсионеры-кошатники составляют 50% вашей ЦА :) Кроме того, перелить ~50 подписчиков из аккаунта с 400 — это само собой должно получаться, без всякого маркетинга и сложных теорий, поэтому никаких глобальных выводов из этого делать не нужно.

    2. Мудрить — не значит продавать. Инструменты большого маркетинга не предназначены для микробизнеса

    Портреты покупателей выделять нет смысла (см. п.1). У вас по определению будут довольно разношерстные клиенты. Нет смысла группировать их и сегментировать ЦА. Тут либо каждый клиент образует отдельную группу, либо получатся слишком общие признаки. Заметьте, под ваши два портрета (женщины + мужики творческих профессий) попадает практически вся инста :) Такое сегментирование не даёт никакого профита, потому что у всех этих людей разные вкусы, разный образ жизни, разные интересы. Эта сегментация не влияет на тактику продаж.

    Вообще, если вам кто-то в контексте Инсты и SMM (на курсах и т.п.) начинает затирать что-то из «взрослого» маркетинга (ёмкость и объем рынка, потенциальный спрос и т.п.), гоните в шею. Для всех этих понятий существуют точные определения и формулы расчёта, математический аппарат. В смм они сродни карго-культу)

    3. Мышление с позиции ценника даст больше толку

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

    Если у вас продукт со «средней» ценой под «средние» доходы — это не только хорошо (потенциальных покупателей много), но и плохо (максимум конкурентов, расходы на рекламу распыляются, низкая конверсия).

    Подход «от ценника» гораздо конструктивнее. Возникает понимание, что товар — это (условно) не «картина», а «хендмейдовый подарок за 100 баксов». Как только вы начинаете думать в этих категориях, представление об аудитории, конкуренции и самом продукте меняется. Вы быстро перестанете ориентироваться на всякую стереотипную ерунду, типа «мужчин творческих профессий»* и начнёте искать тех, кто реально готов дарить кому-то хендмейд за стольник. Угол зрения совершенно иной. Иногда в результате и сам ценник тоже двигается, причем не обязательно вниз.

    * Знакомые мне UI/UX дизайнеры через одного технари, практичные, семейные, себе дарят скорее гаджеты, да и жёнам-любовницам тоже. Ваще на ваша ЦА. Совершенно.

    4. Нельзя игнорировать личный фактор

    Когда строите маркетинговые теории, не забывайте, что соцсети (в отличие от поточных производств) едут на личном общении. Это значит, что решающим фактором продажи может быть тупо знакомство с автором) И следовательно, если ваш знакомый дизайнер купил у вас картину, это отнюдь не значит что дизайнеры ваша ЦА — возможно, ему просто нравятся ваши сиськи, например) Ну или прекрасный внутренний мир. (Хотя, зная мужской стиль мышления, я бы всё-таки поставил на сиськи :) Я к тому, что нельзя экстраполировать опыт личных продаж на работу с холодной аудиторией. Это две разные вещи. Учитывайте статистику именно по тому каналу, который используете. Опыт с других каналов/площадок может существенно отличаться.

    5. Не надо ориентироваться на клиентов других художников

    Если человеку нравится творчество Вани Иванова — это вообще никак не значит, что он заинтересуется творчеством Пети Петрова.

    Я не знаю, почему все сммщики так любят таргетиться на конкурентов — это прямо паталогия какая-то. Такой подход отбивается по продажам ровно в одном случае: когда ты толкаешь абсолютно идентичный продукт, но ниже по цене. (И еще в массированных РК, когда бюджет конский и задача мельтешить по максимуму, но это другая история).

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

    Типичный автор типичных SMM курсов обычно думает с точностью до наоборот. Возможно, поэтому он и занимается подобной ерундой)

    P.S. Хорошая самопроверка: допустим, в расчете на «ЦА № 2» вы опубликовали пост в нескольких нерелевантных хабах и собрали 3k просмотров. Если ваши гипотезы верны, то на такой выборке за ближайшие сутки чисто статистически должно получиться где-то с полсотни новых подписчиков и, минимум, 1-2 продажи (именно с хабра). Если этого нет, значит гипотезы не работают и надо что-то переосмысливать.

    В любом случае, успехов!
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    В принципе, что пнём о сову, что совой об пень :) Большая часть вопросов, упомянутых тут, не очень зависит от инструментария фронтендера и остается актуальной хоть с «Зеплином» хоть без него. Всё равно ведь компоненты надо как-то именовать, стандарты отступов и сеток согласовывать и т.д. «Зеплин» с «Фигмой» неплохо интегрированы. Глобальные стили из Ф уже импортируются, импорт компонентов тоже на подходе, вроде как. Но «Зеплин» не отменяет необходимость договариваться об именовании и приводить базу компонентов в какой-то единообразный вид.

    Плюс, по чисто личному ощущению, темп развития «Фигмы» выше, и есть ненулевая вероятность, что она со временем перекроет функционал Зеплина собственным, развив свой read-only режим в полноценный интерфейс для разработчиков.
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    Не :) В стандартном синтаксисе всё наоборот: двойное нижнее подчеркивание отделяет элемент, а одинарное — модификатор.

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

    В принципе, если ваши коллеги не возражают, то можно и так, наверное. Но при смене коллектива та же путаница будет постоянно возникать. Возможно, есть смысл вернуться к классике :)
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    А вот это вопрос интересный и годный. Чисто теоретически, на уровне архитектуры, я согласен, что в идеале не-компонентных частей в компонентном дизайне быть не должно. И наверное, если речь идёт о каком-то отдельно взятом проекте, то этого можно добиться. Здесь дизайн-система по сути просто обеспечивает консистентность интерфейса, который сравнительно легко можно унифицировать.

    Но если мы всё-таки говорим о какой-то универсальной дизайн-системе, цель которой организовать рабочий процесс между дизайнером, верстаком и т.д. в общем потоке разных проектов, то тут речь будет скорее о рамочном соглашении , а не жестком стандарте не все случаи жизни. Иначе система начнет мешать в работе, потому что сами задачи могут быть разнородными.

    Грубо говоря, например. Делаем на потоке промо-сайты, у каждого первый экран главной страницы представляет собой обложку с ярким коллажем с анимированными элементами. Логически такая обложка — компонент. Она есть на каждом сайте, имеет стандартное место в лейауте, стандартный размер, поведение брейкпоинтов и т.п. Но поскольку начинка обложки всегда разная (и в этом, собственно, её функция) унифицировать её толком мы не можем, да и выносить в библиотеку нет практического смысла, т.к. переиспользуется только голый фрейм.

    Или другого плана пример. Рисуем контентную страницу, типа лонгрида. Логически в тексте много разных переиспользуемых компонентов: абзацы, врезки, цитаты, списки, мелкий текст и т.п. Но если делать их именно компонентами (отдельными блоками-экземплярами), то при любом изменении объема текста вся колбаса поедет и нужно будет руками переставлять все блоки. Если же считать компонентом родительский фрейм (весь контейнер с текстом статьи), то его не получится переиспользовать, потому что структура врезок, цитат и т.п. не совпадёт. Переиспользуемым в данном случае является оформление элементов, а не сам текст. Поэтому в «Фигме» такие вещи выносятся в стили, а не компоненты. И соответственно, на уровне «Фигмы» такие текстовые слои лучше оставлять как есть, вне компонентов. Предполагая, что на уровне верстке они имеют произвольную разметку, которая может содержать в себе компоненты, примеси и т.д.

    Словом, дизайн-система и её техническая реализация дадут некоторую разбежку по-любому. Поэтому я сторонник того, чтобы стандарт вычленялся из кейсов. То есть стандартизировалось только то, что на практике повторяется и переиспользуется.
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    Люди не уловили юмор, видимо)
    К слову, если брать именно UI, то при жестком выборе из набора «дизайнер, верстальщик, „Фигма“» я бы оставил все-таки верстальщика :)
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    Вроде всё так. Может, я опечатался где-то в тексте?

    Классический синтаксис БЭМ:

    // Модифицированный элемент блока:
    .block__element_modifier
    
    // Модифицированный блок:
    .block_modifier
    


    Если где-то текст не соответствует, тыкайте меня носом, подправлю :)
    Спасибо за комментарий!
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    +1
    Система вводится не ради «пиксель пёрфекта» (визуального), а ради стандартизации рабочего процесса. Со всеми её плюсами и минусами.

    Представьте себе open source проект, в который могут коммитить совершенно посторонние люди. Там максимальный профит от стандартизации, потому что без неё каждый лепит по-своему. Кому-то нравится паддинг 5 пикселей, кому-то 3; кто-то считает с учетом border-box, кто-то нет и т.п. Никаких ресурсов не хватит делать ревью визуально для каждого такого коммита. А при наличии системы можно и людей обучить, и ревью частично автоматизировать.

    В студии профит не так очевиден, но принцип тот же.
  • Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™
    0
    Думаю, четвёрку выбрали потому, что из всех клавиш-цифр она ближе всего к указательному пальцу при зажатых «Ctrl+Shift». Фотошоповский «Ctrl+;» плох тем, что правую руку нужно отрывать от мыши. Субъективно, подход «Фигмы» всё-таки удобнее после адаптации, хотя в первые недели я тоже вешался)

    Про «дачную скатерть» сказано метко, но особой проблемы нет. Во-первых, сетка многослойная. Лишнюю разлиновку можно держать по умолчанию скрытой, если мешает. Во-вторых, «магнитная» привязка работает даже если сетка едва видимая или прозрачная. На скринах она ярче раз в 5, чем нужно — для иллюстрации.
  • Правила подготовки макетов в Figma
    0
    Ответил тут.
  • Правила подготовки макетов в Figma
    +1
    Вы хорошо реагируете. По 2 и 3 давайте так сделаем: я черкну себе в туду и по возможности в течение 3-4 недель попробую оформить комментом или постом. Нужны иллюстрации, т.к. всё пляшет от сеток. Не гарантирую, но постараюсь.
  • Figma — простое решение для дизайнера, сложное решение для верстальщика
    +1
    Вы теоретически рассуждаете или пробовали сравнивать оба подхода (Фигма/Adoby) на объемных проектах? В моем случае эти аргументы отпали уже после 3-4 проектов в Фигме.

    Делать компоненты смарт-объектами/файлами по сравнению с Ф крайне неудобно: можно утонуть в состояниях и модификаторах. Банально, у вас есть компонент header, в нём зашит компонент nav-menu со ссылками. И есть макеты страниц (много), где в шапке выделены соответствующие родительские пункты меню (разные). Попробуйте собрать всё это на смарт-объектах так, чтобы получить полноценный экспорт в результирующих файлах. Я имею в виду, свободно менять типографику элементов меню из любого места, переключать в 1 клик состояния :hover и :active и т.п. для отдельно взятого пункта в отдельном макете. В таком духе:



    В Фигме, к слову, вы можете всё это ещё и показать интерактивно: потестить «живьём» нажатие кнопок, показать всплывание окон и оверлеев, поведение фиксированных элементов при скроллинге и др. — без необходимости экспортировать статику и собирать из неё потом что-то сторонними примочками).

    При атомарном подходе в PS у вас на нормальном проекте постоянно будут получаться смарт-объекты с 5-10 уровнями вложенности. Управлять ими адски геморройно. В сравнении:



    Опять же, с респонсивностью холста что? Ничего. Портировать какой-нибудь баннер под 20 размеров (привет, Яндекс.Директ и т.п.) придётся чуть ли не руками. А в Фигме вы делаете 1 компонент, потом тянете его как угодно — содержимое само «едет» куда нужно или выравнивается. Причем правки вносятся во все артборды сразу и экспорт всей пачки jpeg происходит в 1 клик. Вот вам такой «смарт-объект» (накинул в один компонент от балды случайных элементов из либы для демонстрации выравнивания):



    А теперь вносим туда 3 правки, примерно за 5 секунд:



    Сколько возни было бы со смартами, чтобы раскидать 3 правки на на 4 разноформатных артборда (не пропорционально, а респонсивно)?

    И это всё очень лишь мелкие частности. Их таких миллион.

    В общем, собирать все эти вещи из смарт-объектов кажется удобным только до тех пор, пока не поработаешь плотно с компонентами. Я ещё не встречал людей, которые освоив Фигму (до стадии преодоления начальных привычек), вернулись бы потом на смарт-объекты. Это просто бессмысленно.

    Да, при освоении первую неделю тяжко, хочется ругаться матом (то горячие клавиши не совпадают, то выделение слоев непривычное, то что-то ведёт себя «нелогично» и т.п.). Но это обычная история при миграции на новый софт после многолетней привычки.

    Повторюсь, обратно в ФШ/Люстру возвращаться не тянет ни на йоту. Хотя я тоже консерватор и тоже относительно долго от неё отбрыкивался :) Почти год присматривался, ковырял по вершкам. Но по факту Фигма действительно экономит уйму времени и энергии. Навскидку, процентов на 20 производительнее стал.
  • Figma — простое решение для дизайнера, сложное решение для верстальщика
    +2
    А вы не пробовали спросить почему ?)

    Figma не является аналогом PS/AI, это продукты совершенно разного назначения. PS не умеет ничего из того, ради чего создавалась Фигма.

    1. Там нет компонентной системы и нормальной возможности повторно использовать компоненты между макетами (статичные Смарт-объекты это совсем не то).
    2. Там нет возможности наследовать стили от родительских проектов.
    3. Там нет совместного доступа.
    4. Там нет режима прототипирования.

    Там нет ничего для работы с проектами на 50-100 артбордов. И не должно быть, потому что PS — это редактор растровых изображений, а не сервис для разработки и прототипирования интерфейсов. Когда вы просите дизайнера сделать интерфейс в PS, это всё равно что попросить его рисовать макеты от руки в тетрадке или, скажем, вырезать из цветной бумаги: технически возможно, но бестолково, бессмысленно и абсолютно не технологично.

    В Фигме сейчас с плагинами можно создавать даже пакеты стилей (темы). То есть в 1 клик переключать темы по всему проекту (тёмная/светлая и др.) А в PS чтобы поменять цвет 1 базовой кнопки для 100 артбордов, нужно открыть все 100 макетов и руками перекрасить каждый экземпляр, да ещё потом экспортнуть всё заново. (Да, можно частично автоматизирвоать это экшнами/скриптами, но по сравнению с Фигмой это костыли).

    Я пользовался PS как основным граф. редактором лет 10, да и до сих пор пользуюсь для работы с растром. Могу даже изредка какой-нибудь сайтец набросать, если там много растровой графики (промо и т.п.). Но рисовать в PS интерфейсы после выхода Фигмы — не дай боже. Зачем?

    Возможно, вы не сталкиваетесь в своей работе с этими проблемами PS и, соответственно, просто недооцениваете сильные стороны Фигмы. Но тогда и глобальных выводов делать не стоит.

    Я не идеализирую Фигму, в ней полно всяких заморочек (как и в любом другом редакторе). Но по темпу развития и специализации уже сейчас видно, что она становится стандартом индустрии. Люди слезают даже со Скетча, что уж про PS говорить. Adoby свой XD бесплатно раздавала и всё равно толком не забрала свою прежнюю дольку. Если кто-то и будет конкурировать с Фигмой в ближайшем будущем в области интерфейсов, то аналоги из того же поколения «CSS-based» редакторов. Типа Webflow или каких-нибудь гибридных решений с участием avocode, invisionapp и т.п. Но даже у них на данном этапе перспективы похуже, на мой взгляд. Фигма быстро движется и явно монополизирует нишу.
  • Правила подготовки макетов в Figma
    0
    1. Если ваш дизайнер не умеет в сетки, пинать надо не дизайнера, а того, кто его нанял.

    2. При наличии внятной дизайн-системы нет никакой практической необходимости выдерживать точные пиксельные значения отступов (кроме чистого перфекционизма и эстетики). Потому что когда у верстака есть базовые значения (например: 4px grid, базовый интерлиньяж 16 (32) px, gutter 16x20px, ширина колонки адаптивна), ему вообще не нужно изучать размеры каждого компонента в отдельности, потому что они всегда очевидны даже на глаз, т.к. кратны базовым. Принять для себя систему и следовать ей в 20 раз проще и умнее, чем сидеть и выцеливать каждый пиксель в проекте с сотней-другой экранов. Я сам жуткий педант, но даже у меня в макетах полно подобных огрех, чисто статистически. Ни у кого это не вызывает вопросов, благо мои верстаки люди опытные и не склонные к истерикам. И если кто-то видит в макете с 4-пиксельной базой паддинг в 17px, то не истекает ядом, а спокойно пишет в стилях «16px». Потому что понимает суть происходящего и общую логику лэйаута.

    3. «Мы, дизайнеры» именуем слои как надо. Вплоть до имитации структуры компонентов a ля Stylus/SCSS в БЭМ-нотации, если это зачем-то требуется. И не надо чесать всех под одну гребенку. Если ваш дизайнер чего-то не умеет — это ваши локальные проблемы, а не норма для всех представителей профессии или индустрии.

    Отсюда встречное предложение:

    • либо нанимайте более опытных дизайнеров, для которых всё это даже не азбучные истины — будет вам счастье;
    • либо уж будьте терпеливы и обучайте свои молодые кадры корректно — без истерик и демонстрации мнимого превосходства.

    На мой взгляд, подобное притягивает подобное. Ни один квалифицированный дизайнер (верстальщик/программист/грузчик) не будет работать с виталиями, которые доносят свою мысль исключительно в императивах и нагнетают драму на пустом месте. Эти простейшие рабочие вопросы решаются в ходе 10-минутного митинга.

    P.S. Не драматизируйте тяготы верстачьих будней) Там минимум нервотрепки по сравнению с практически любой другой профессией. (Да, я верстал под IE6). Если вас «аж трясёт» от пары лишних пикселей, дело не в пикселях и не в дизайнерах.
  • Проектирование интернет-магазина для SEO: (теория + чеклист)
    +1
    Субъективно, ценность таких статей не в том, чтобы раскрыть какие-то великие тайны или научить кого-то чему-то, а в простом обмене опытом из личной практики. Не знаю как вам, а мне это всегда очень интересно, даже если в статье нет ничего из ряда вон. И чем типичнее описанный проект, тем больше шанс почерпнуть прикладной опыт для себя.

    Так что я не жду от авторов каких-то бесспорных истин или открытия Америки. Полезно бывает найти подтверждение отдельным собственным эмпирическим выводам или лишний раз убедиться, что люди сталкиваются со схожими проблемами. Любая фактическая инфа со стороны полезна. Мы все так или иначе работаем с изрядной долей неопределенности, бывает трудно отличить случайные корреляции от закономерностей. Так что чужой опыт это всегда хорошо (независимо от того, насколько он «правильный»).

    Знаю, что многие предпочитают публикации передовых компаний об инновациях, с кучей технических подробностей и всяких крутых решений. Но, на мой взгляд, их опыт как раз трудно масштабировать вниз до уровня локальной студии. Ну то есть оно вдохновляет, конечно, но в 99% случаев проблемы и решения гигантов возникают в абсолютно параллельной вселенной. Грубо говоря, ну читаю я статью ребят из условного Яндекса, которые отлично решили проблему X с помощью 20 программистов и навороченной нейросети. Вау, очень интересно и любопытно. Но при этом у меня тупо нет в работе ни одного проекта, который требовал бы такого уровня автоматизации и где бы внедрение окупилось для клиента :) Так что лично для меня статьи типа этой имеют бОльшую субъективную ценность, даже когда я совершенно ничего нового не узнаю.

    К слову, во многом согласен с вашим замечанием о ЧПУ выше (в плане чистой логики). Но спорная информация — это всё-таки сырьё для анализа. Её можно отфильтровать, осмыслить, погонять на тестах и т.п. Хуже, когда анализировать вообще нечего. В этом смысле, доклады волне хороши.

    P.S. iarga, спасибо, прочёл с интересом.
  • Как UX-писатель помогает улучшить продукт
    0
    Вы защищаетесь (зачем-то?), но не вникаете. Я всего лишь ответил на конкретный вопрос: почему язык «роботов» воспринимается легче «очеловеченного».

    Тексты интерфейса это именно пятна. Биомеханика глаз так работает. Я пытаюсь вам сказать, что процесс чтения происходит не последовательно, а на основе саккад. Читая, мы «скачем» от точки к точке с интервалами в 20-200 миллисекунд. Чем меньше саккад потребуется, чтобы выявить суть написанного, тем выше шанс, что будет прочитано всё пятно целиком.

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

    Считается, что для английского языка средняя длина саккады для текста составляет 7-9 знаков (на деле зависит от форматирования, гарнитуры, интерлиньяжа, условий наблюдения и др). Но общий смысл один: одновременно мы можем удерживать взглядом лишь несколько символов, а всё что вокруг размывается по мере их удалённости от точки фиксации взгляда. Детали в этой статье (english), например.

    Всё это напрямую влияет на то, как нужно структурировать текстовки и располагать ключевые слова (я не про SEO сейчас) внутри них.


    Поэтому существуют определенные приёмы для управления вниманием. Один из них заключается в том, чтобы дробить тексты на коротенькие номинативные предложения и т.п. Это именно то, что вы называете «притвориться роботом». Якорные формулировки. И это помогает.

    И это не «второстепенный вопрос», а краеугольный камень, который отличает UX-райтинг от обычного сопроводительного «простынного» копирайтинга или, тем более, устного общения между собеседниками.

    В силу саккадной специфики восприятия, люди не замечают многие тексты. Я имею в виду буквально: не видят. Текст есть, а человек смотрит прямо на него, но не замечает. Для него это просто сложное пятно, которое почему-то никак не хочет осмысливаться.

    Знаете, бывает такое, когда внимание рассеяно и одну строку в книге по 5 раз начинаешь читать заново, а суть всё не воспринимается? Схожий принцип. Дело тут не самом по себе количестве знаков, а в отсутствии сильных «зацепок» в выхваченном фрагменте. Мозг не хочет вникать в то, что не имеет сильных якорных точек (такой точкой может стать, например, имя главного героя, какое-то отдельное эмоционально-ассоциированное слово или даже просто ВНЕЗАПНОЕ НЕСТАНДАРТНОЕ ФОРМАТИРОВАНИЕ как в книжках Кинга). Иногда достаточно в тексте выделить всего 1 слово, чтобы внезапно «увиделся» целый блок или абзац. Это и есть якорь. В интерфейсе якорем может послужить любое слово, связанное с текущим активным элементом/процессом или его состоянием.

    Проблема в том, что попытки сделать формулировки более литературными приводят к обратному эффекту. Люди перестают замечать весь блок, если он излишне обстоятельный и выполнен в стиле правильной устной речи. Если первые несколько саккад не оправдывают ожидания (не находят никаких нужных якорей), то человек просто «не видит» весь блок целиком. Причем саккады вообще не соответствуют последовательностям слов или букв. Примерно вот так это выглядит на eye-tracker'ах:

    image
    (картинка из той же статьи по ссылке выше)

    В литературных формулировках якори сильно разбавлены, поэтому шанс зацепиться за них взглядом намного снижается. В результате львиную долю текстов человек просто не замечает. Совсем. Как будто там просто какое-то серое пятно, которое вообще не нужно читать и осмысливать.

    Именно поэтому тексты «роботов» имеют больший шанс быть прочитанными и понятыми. Это никак не связано с их литературным качеством.

    Повторюсь, человеческое восприятие текста работает не так, как кажется на первый взгляд. В это стоит вникнуть — там много интересного.
  • Как UX-писатель помогает улучшить продукт
    0
    И соответсвенно, ожидаете, что UX-писатель должен притворяться роботом… Просто интересно, почему так.

    Это очень просто. Вы как и многие райтеры (если не большинство) исходите из предположения, что люди читают тексты интерфейса и, в более общем виде, что человек думает словесными формулировками. А это не так.

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

    Во-вторых, мы не думаем словами на уровне рефлексов. Чтение текста — это надстройка, промежуточный уровень интерфейса, которым приходится пользоваться людям для трансляции сложных понятий и образов. Распознавание текста и конвертация его в «мысли» — очень ресурсоёмкая операция. Она происходит на уровне высшей нервной деятельности, которая ворочается намнооооого медленнее и тяжелее, чем рефлексы, жесты и др.

    Наш естественный «поток сознания» крайне далёк от литературного вида. Он гораздо больше похож на то, что вы считаете речью роботов. Мы вовсе не случайно ищем в гугле что-то вроде «окна пвх купить рехау цены», а не «Я хочу узнать цену на оконные конструкции Rehau, чтобы их купить». Это не ради удобства поисковых систем или набора текста. Просто такие вот «вспышки» гораздо ближе по структуре к тем цепочками ассоциаций, которые складываются у нас в головах.

    По той же причине критически важные сообщения иллюстрируют, а не описывают словами. Дорожные знаки, иконки, картинки в детских книжках — всё призвано сократить затраты на осмысливание текста.

    Поэтому пытаясь «очеловечить» текст за счет литературных формулировок, райтер в 99% случаев усложняет восприятие написанного. Заставляет читателя проделывать лишние ресурсоёмкие операции, декодировать информацию, которую перед этим сам же и закодировал, тоже потратив уйму времени.

    Вспомните как меняются формулировки в стрессовых ситуациях. Там всё само собой постепенно «деградирует» до однословных конструкций с предельно однозначными формулировками. Команд. Императивов. Условных сигналов. То есть до той самой речи «роботов». И это не случайно.

    Сравните:

    1. «Мы увидели гранату, летящую в вашу сторону, и подумали, что будет правильно сообщить вам об этом, чтобы вы могли заранее лечь на землю и тем самым сохранили себе жизнь».
    2. «ЛОЖИСЬ, б***ь!!!!»

    У этого принципа множество самых разных практических следствий. Все «деловые» и «технические» версии языков имеют тенденцию к упрощению. Любые текстовки повсеместно сокращаются пропорционально частоте их использования. Мои комменты на Хабре адски длинные (ради экономии времени на формулирование :). Тексты для массовых сервисов нужно искусственно «отуплять» в плане лексики и красноречия. Итэдэ итэпэ.

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

    Вообще, «парадоксальных» моментов в UX полно, и никто абсолютно от них не застрахован, пока по граблям не напрыгается. Потому что мы все интуитивно хотим делать продукты логичными и упорядоченными, но человеческое поведение строится вовсе не на формальной логике. Отсюда постоянное непонимание: почему голая попа птушницы популярнее умного и полезного контента в инсте, почему какие-то убогие стикеры «стреляют» лучше запланированной убер-киллер-фичи, почему люди не хотят кликать на CTA-кнопку и т.п. Впору отдельную большую статью на эту тему писать)
  • Э — Эксперимент. Или как наука помогает проектировать интерфейсы
    +1
    Есть такая штука, как список когнитивных искажений. Выглядит заумно, но там есть ссылки на подробные статьи, где собраны примеры, описания экспериментов и др. В том числе и перечисленные. Дюже рекомендую всем, кто изучает UX, особенности человеческого мышления и восприятия. [Ну или жаждет манипулировать людьми — МУАХ-ХА-ХА-ХА… Кхм :].
  • Разделение профилей заказчика и фрилансера
    0
    Кажется, у нас с вами получился диалог про Фому и Ерёму :)

    У меня за плечами лет ~12 фриланса в той или иной форме. Биржами пользуюсь в качестве заказчика и посредника. В вашем восприятии заказчик и исполнитель заключают сделки только штучно, и в своей системе координат вы правы. Но я утверждаю, что времена меняются, и что существуют иные сценарии работы. Например, когда пул задач исчисляется десятками или сотнями. При таком раскладе все процессы строятся совершенно иначе.

    Никаких «проверенных» лансеров на дистанции даже в 1 год не существует. Просто в силу того, что за такой период многое меняется: кто-то «пропадает», у кого-то вырастает ценник, у кого-то меняется график работы, кто-то нишуется, кто-то постоянно перегружен, кто-то сам начинает отдавать на субподряд, кто-то выгорает. Это подтвердит практически любой заказчик-оптовик, который плотно работает с лансерами хотя бы пару лет. Отдельно взятый исполнитель нестабилен чисто статистически. Стабильность появляется лишь в том случае, если вы дробите все проекты на типовые задачи без привязки к конкретным личностям и у вас всегда на низком старте 3-5 исполнителей по каждому профилю.

    Биржи часто используются для того, чтобы масштабировать мощности. Грубо говоря, появляется задача забить 100k товаров в интернет магазин — вы пишете детальное ТЗ с чеклистами, идёте на биржу и прогоняете 10% объема через 100 исполнителей. После этого этапа у вас остается 20 толковых исполнителей, которым передаются 90% объема, а 5 наиболее внимательных вы делаете «контролёрами». Это совершенно иной подход, причем если раньше он применялся только для неквалифицированной работы, то сейчас по схожему принципу решаются и более сложные задачи, особенно если они типовые или основаны на мейнстримных технологиях.

    Я прекрасно понимаю, что часть проектов работает по вашей схеме. Что есть узкопрофильные и хорошо отнишеванные специалисты. Что часть заказчиков — «рознечники» (собственники мелких фирм, у которых задачи штучные и разноплановые). Но, как ни крути, основные объемы заказов попадают на рынок через субподряды — от агентств, студий и прочих посредников. А при описанном подходе важны не столько личности, сколько оптимизация процедур. Поэтому я и считаю, что в перспективе развиваться быстрее будут именно те биржи, которые сделают ставку на соотвествующие инструменты для работы с потоками проектов, а не отдельными лансерами.

    P.S. Я ничего не осуждаю и не критикую :) Просто бла-бла на интересную тему.
  • Разделение профилей заказчика и фрилансера
    0
    Спасибо за пост, тема интересная.

    Суну 5 копеек. У всех известных мне бирж проблема именно в том, что в качестве ключевой сущности принят пользователь. Хотя в жизни такой сущностью служит не человек, а проект (или «сделка» — далее по тексту это синонимы). В этом радикальное отличие от оффлайнового найма или хедхантинга. Основной биржевой поток составляют разовые сделки, а личности исполнителей и заказчиков второстепенны, это побочная инфа для оценки рисков.

    Если абстрагироваться от пиления макетов и непредвзято пересмотреть рабочий процесс типичного пользователя, всё встанет на свои места. Когда фрилансер «ищет заказчиков» на бирже, чаще всего он на самом деле ищет не пользователя, а сделку (или поток сделок для регулярной загрузки). Когда заказчик «ищет исполнителя», он тоже обычно ищет не пользователя, а сделку. Типовые взаимоотношения завязываются опять же через сущность сделки. Транзакции и арбитраж тоже привязаны к ней. Даже конкуренция создается опять-таки на уровне сделок (а не исполнителей, как кажется на поверхностный взгляд).

    Поэтому, вопреки стереотипу, и «профиль заказчика», и «профиль исполнителя» это одно и то же: архив сделок. Никакого разделения на уровне «профилей» в жизни нет. Роль пользователя в каждом конкретном случае определяется конкретным проектом, сделкой. Это своего рода scope, за пределами которого роль может меняться на любую другую.

    Такой подход был бы намного более гибким и жизненным. Один и тот же человек в разных проектах мог бы играть роль казначея, контролера, ЛПР, куратора, исполнителя, субподрядчика и др. Это точка роста, потенциал для более полноценной проектной работы и, соответственно, повышения среднего уровня проектов по сложности и бюджету.

    И смежный момент. Мне кажется, биржи слишком прямолинейно подходят к выбору значимой/не значимой информации. Мол, заказчику интересны только услуги, исполнителю только заказы. Это не так. По опыту, повторюсь, профайл нужен в первую очередь для оценки рисков и общей адекватности потенциального партнера по сделке. А эти выводы делаются за счет косвенной информации. Архив сделок всегда интересен и информативен, вне зависимости от того, какую роль человек играл в тот или иной момент. Собственно, даже сам факт наличия нескольких ролей уже дает море информации при сопоставлении с текущим проектом)

    В целом, это системная проблема бирж как явления в их нынешнем виде. Все в той или иной форме навязывают роли и сильно ограничивают взаимодействие людей. Думаю, со временем кто-то это прочувствует и совместит биржу с более развитым инструментом управления проектами (ролями, тасками, процессингом и т.д.). Получится этакая биржа 2.0, а остальным станет трудно. Хорошая идея для стартапа, кстати.
  • Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты
    0
    Принимается, спасибо) Зарапортовался. К сожалению, это не спасает итоговый результат — он всё равно далёк от приемлемого. Нельзя так с айдентикой обращаться, на мой взгляд.

    Кстати, тут напрашивается ещё один интересный аспект: юридический. Во-первых, игры с яркостью — это редактирование изображения, и я не уверен, насколько это вообще легально без согласия правообладателя. Во-вторых, если речь идёт о зарегистрированных торговых марках, то изменение цветовой схемы тоже вызывает вопросы, т.к. цвет может быть значимым с точки зрения охраны прав.

    Утрированно говоря, если у одной фирмы логотип — черный круг, а у другой — белый круг, то при инверсии происходит подмена торговой марки)
  • Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты
    +1
    Когда вы механически понижаете brightness в HSB/HSV, возникают оптические искажения, т.к. цветовосприятие не полностью соответствует «математике». Например, для глаз не существует тёмно-жёлтого цвета — он воспринимается как грязно-коричневый (хорошо заметно на третьем скриншоте). Чистый синий #0000ff изначально выглядит фиолетовым, но при понижении яркости синеет. И т.д. Плюс при естественном затенении тон обычно слегка смещается в холодную сторону.

    С адаптацией картинок возникает ещё больше проблем, потому что вся гистограмма меняется. Затемненная фотка выглядят неестественно, как при плохой экспозиции, выбиваются детали в тенях. Обратите внимание, как у вас пропали складки шарфа на фото.

    Ещё одно искажение появится за счет того, что светлые объекты выглядят больше тёмных при одинаковом размере. Заметно меняется ощущение контраста, когда выворачиваются тонкие штрихи, шрифты, обводки. Например, в подвале на третьем скриншоте текст копирайтов на тёмном фоне выглядит ярче, чем на светлом.

    Об очевидных проблемах с тенями элементов вы уже упомянули — объемы теряются.

    Этот путь, скорее всего, приведёт к возникновению дополнительной мета-разметки или ограничений CSS-свойств для отправителей. Понадобится возможность защищать брендовые цвета, переопределять вручную какие-то нюансы и т.п.

    Пользовательский контент по мере развития CSS тоже усложняется: в самом письме могут задействоваться альфа-каналы и цветовые трансформации. Как такой каскад будет выглядеть после дополнительных преобразований — фиг знает. Предположим, фон плашки задан через rgba(255,255,255,0.7) поверх синего контейнера. Совокупно каждый пиксель светлый. И что с этим делать? :)

    В общем, дизайн нельзя адекватно затемнить простым смещением всего вдоль оси Brightness/Value. Результат всегда будет отличаться от оригинала, причем разницу трудно предсказать. Вы можете отправить человеку фото своей черной кошки на фоне серой шторы, а прислать в итоге картину Малевича «Черный квадрат» :)

    Мне кажется, принципиально более правильный подход — дать возможность отправителям самостоятельно предусматривать ночную версию своих писем. Понятно, что это вводит толику хаоса и не все будут заморачиваться. Но это логичнее. Если уж дневной дизайн создаётся на внешней стороне и находится вне вашего контроля, то на той же стороне должен создаваться и ночной. Нет смысла надстраивать структуру, которая от вас не зависит — результат будет очень шатким.

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



    При всём при этом тема крайне интересная. Спасибо за пост и вообще за то, что делитесь с опытом — здесь есть о чём подумать)
  • Мой способ создания мастер-компонентов в Фигме
    +2
    Аналогично делал универсальный компонент одно время, только иконки две: слева и справа — так более гибко. Позволяет реализовывать выпадающие списки с иконическими элементами, аккордеоны, инпуты с иконками поля и иконкой состояния («глаз» для паролей) и т.п.

    Вот тут везде по сути один такой компонент в основе) Он реально удобный.





    Но со временем наоборот стал сознательно избегать излишней унификации.

    Дело в том, что при всей внешней схожести компонентов, у них разная семантика. Поэтому они по-разному ведут себя внутри других компонентов, реагируют на ввод и т.п. Например, у инпута добавляются результаты валидации, подсказки по ошибкам и т.п. А у выпадающего списка — нет. При наведении на простую кнопку меняется цвет, а при наведении на кнопку-иконку внутри крошек к ней просто добавляется бордюр. И так далее.

    Когда элементов и проектов накапливается много, «универсальный» компонент превращается в обузу, потому что от него наследуется целое дерево модификаций и при малейшем обновлении «корня» часть веток запросто может посыпаться. Так что в итоге теряется сам смысл универсальности. В итоге я решил особо не умничать и делать компоненты полностью независимыми друг от друга :) Тут примерно та же попа, как при высокой связности кода в программировании. Тем более, что во некоторых проектах компоненты имеют другую структуру, состав или кол-во состояний.




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


    Если не используются глобальные компоненты, всё вообще становится просто. На странице компонентов они группируются по фреймам. Тогда локальная библиотека становится компактной и ворочается быстро. То есть вместо того, чтобы скроллить сто иконок, я бросаю из библиотеки на макет экземпляр дефолтной иконки (первый в списке) или копирую любую иконку из макета. А потом через меню instanсe (см. выше) быстро выбираю нужные модификаторы во вложенных списках. Если в проекте много всего, то компоненты можно ещё и по страницам разложить, тогда вообще удобно:



    P.S. Важное замечание: эта система хороша для случая когда дизайнеров мало (один-два), а проектов много и они разноплановые, автономные. В больших командах с сингл-проджектом и глобальной библиотекой всё может быть иначе.
  • Всё, что нужно знать об автоматических переносах в CSS
    +2
    Вряд ли существует фундаментальное исследование, не тот масштаб проблемы. Есть много мнений на этот счёт, есть рекомендация избегать переносов в самых разных Style Guides.

    Гайд «Википедии»:
    Use of soft hyphens should be limited to special cases, usually involving very long words or narrow spaces (such as captions in infoboxes or other tight page layouts, or column labels in narrow tables). Widespread use of soft hyphens is strongly discouraged, because it makes the wikitext very difficult to read and to edit.

    Чикагский гайд (платный, но есть trial), на который ссылается гайд MS:
    The hyphenation function on your word processor should be turned off. The only hyphens that should appear in the manuscript are hyphens that would appear regardless of where they appeared on the page (e.g., in compound forms). Do not worry if such a hyphen happens to fall at the end of a line or if the right-hand margin is extremely ragged. By the same token, do not attempt to manually break excessively long words (e.g., long URLs) with a hyphen. See also 2.96.

    Это не исследования, конечно. Но рекомендации. Каждый руководствуется субъективным опытом. Я описываю свои наблюдения, которые основаны на довольно плотной работе с текстом в течение нескольких лет (копирайтинг, редактура и т.п.). Их не обязательно принимать на веру, но можно принять как пищу для размышлений.

    Так вот, личное мнение:

    1. Техника чтения такова, что мы идентифицируем слова отнюдь не последовательно. Наиболее значимы для распознавания первые и последние символы. (Здесь чуть глубже, с отсылками и примерами). Когда слово дробится, мы сразу теряем часть опорных символов, число вариантов вырастает, распознание затрудняется.

    2. Чтение со второго слова равносильно центральной или правосторонней выключке, потому что глаз вынужден нащупывать начало каждой новой строки. (Опять же, не могу сослаться на классическое исследование, но это входит в любой сборник «плохих практик» по типографике и полностью подтверждается моим личным опытом).

    3. При послоговом переносе возникает многовариантность из-за общих приставок и корней. «Мама, я принёс тебе теле-...» — телефон? телевизор? телескоп? телеграмму? Это постоянный микроподбор вариантов на основе контекста.

    Предугадывание (нечеткий поиск) кажется мне по определению более ресурсоёмкой операцией, чем прямое и однозначное считывание. Косвенно это подтверждается тем, насколько сложнее на глаз найти все вхождения определенного слова в длинном тексте, если оно местами дробится переносами.

    Учитывать моё мнение или нет — тут уж целиком на ваше усмотрение :)

    P.S. Прошу прощения, дальше углубляться не готов, итак слишком увлёкся)
  • Всё, что нужно знать об автоматических переносах в CSS
    0
    Возможно, есть смысл использовать сжатые гарнитуры (condensed) и кегль чуть скромнее. Что немцы частенько и делают, собственно.



    К сожалению, я не знаю немецкого (переносы тоже от балды расставлены), поэтому адекватно протестить не могу. Чисто визуально, несмотря на сжатие, глазу проще выхватить из контекста слово, когда оно не дробится:



    А вообще, надо брать да проверять. Практика — критерий истины) Дизайнеры часто судят о мнимой читабельности визуально, по размеру букв и т.п. Но на практике не раз убеждался, что больше зависит именно от компоновки текста в колонке: длина строки, выключка, интерлиньяж и др. Поэтому в сложных случаях надо брать и тестить.

    Ну и держим в голове, что ваш пример довольно специфичен: википодобный немецкий текст в ширине 304px, без редактуры. Мы всё-таки по большей части работаем с русскоязычными или на крайняк англоязычными текстами. В быту всё проще. Рядовой текст без переносов выглядит вполне нормально даже без изменения кегля и гарнитуры. Читается легче, чем с переносами.

    Вообще, если слова длиной под 30 знаков — исключения, то в идеале хотелось бы лечить их индивидуально. Мягкими переносами (­) или принудительно дробить. Тривиальная задача для типографа, в общем-то. Если такой возможности нет, лучше уж просто оставлять свободно висеть в отдельной строчке, нет в этом ничего особо страшного. Одна визуально некрасивая строчка вряд ли стоит сотни переносов по всей простыне.

  • Всё, что нужно знать об автоматических переносах в CSS
    +5
    Есть мнение, что сами переносы — атавизм, который стоит оставить позади.

    Аргументы вкратце следующие:
    1. В вебе нет ограничения на число строк, поэтому нет острой потребности заполнять площадь по максимуму.
    2. Раздробленные слова затрудняют чтение сильнее, чем «рваный край».

    Изначально потребность в переносах возникла как попытка сэкономить площадь носителя. Количество строк в бумажном издании ограничено, влияет на стоимость тиража. В вебе этой проблемы нет, поэтому нет и функциональной причины для переносов.

    Рваный край становится проблемой только в том  случае, если неудачно подобрана ширина колонки. Для сплошного текста оптимальна длина строки в ~6—9 слов (и слегка варьируется для разных языков). В такой колонке колебания рваного края составляют от силы процентов пять-десять ширины, это смотрится вполне нормально и живо. Если же колонка выглядит рваной, это как раз сигнал о том, что есть проблема с пропорциями шрифта и строки — тогда лучше по возможности подрихтовать дизайн, а не лечить симптомы.

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

    У меня есть примерно 10
    причин не делать пере-
    носы при сплошном набо-
    ре текста в вебе.
    У меня есть
    примерно 10 причин
    не делать переносы
    при сплошном наборе
    текста в вебе.

    С точки зрения функциональности, скорочтения и восприятия смысла, рваный край лучше, чем дробные слова. В этом плане переносы — ненужный костыль, который мы тянем в веб из книжной типографики по привычке.

    Что касается эстетики, тут тоже не всё однозначно. Избыточно ровные текстовые блоки сродни симметричной композиции и т.п. Обычно человеку изначально нравятся симметрия, яркие цвета и простые геометрические формы. Но по мере развития вкуса, предпочтение отдается асимметрии, полутонам и сложным пятным. (Не в смысле ханжества; просто естественная закономерность из культурологии, основывается на изучении народных искусств на разных стадиях развития).

    Так что, на мой взгляд, переносы в вебе не нужны. Как не нужен, например, text-indent для отбивки абзацев или    п р о б е л ь н а я     р а з р я д к а   для выделения текста. Это пережитки бумажных изданий, вынужденные костыли, обусловленные несовершенством технологий верстки. По мере развития технологии их желательно изживать из массового оборота.

    P.S. Кстати, есть вероятность, что сами принципы чтения постепенно изменятся. Вот интересный эксперимент (англ.), например. Вместо вывода целого текста выводится одно поле, которое показывает текст пословно — скорость чтения получается выше обычной. Это не полноценная замена тексту, конечно, их сложно всерьез сравнивать, но сама попытка переосмыслить процесс чтения о многом говорит.

    Тем не менее, статью прочел с интересом, спасибо!
  • File management done wrong — Часть 2: Masterpiece of Shit
    0
    Зря мне шпильку воткнули, незаслуженно :) Есть приципиальная разница между подходом MS к Win8 и редизайном в стиле «я хочу, чтобы было как в баттлфилде».

    Интерфейс Metro (aka «плитки») обкатывался на побочных продуктах несколько лет до включения в Win8. Zune (2006), Windows Phone (2010) и Windows Media Center (где-то там же). Сама Win8 ведь тоже не в один день возникла: полгода в dev preview, потом полгода в бете и только в 2012 релиз. Причем это самостоятельный продукт, а не обновление семерки. То есть клиент имел возможность пощупать новую ось перед покупкой, не слезая со старой, и принять осознанное решение. Примерно это я и имел под эволюцией инфраструктуры.

    Насколько понимаю, для перехода на Metro существовали объективные причины. Предыдущая 7-ка вообще не была рассчитана на сенсорные экраны и никак не коррелировала с Windows Phone. То есть им нужно было уже не просто что-то там улучшить, а заточить ось под новый класс железа с новой эргономикой. Я не держал свечку, но мне кажется, что поддерживать одновременно старый UX (десктоп в стиле «пуск») и новый UX (сенсорный ввод а ля Windows Phone) — очень проблемно со всех сторон и экономически сложно. Возможно, поэтому им и пришлось вырабатывать новую экосистему. Это не редизайн в косметическом смысле. И внедряли его далеко не идиоты, на мой взгляд.

    Хорош ли Metro в вакууме или нет — отдельная тема. Не хочу развивать, чтобы не лезть во вкусовщину. Скажем так, мне понятно, какую глобальную проблему они пытались решить с его помощью. Поэтому в контексте темы критиковать частности смысла не вижу.

    Никто не утверждал, что MS выпускает идеальные продукты. Речь шла лишь о том, что проблема редизайна таких проектов сложнее и глубже, чем кажется автору поста. Ну и, косвенно, о том, что не стоит записывать в идиоты сотни людей только потому, что они делают свой продукт не совсем так, как хочется лично тебе.
  • File management done wrong — Часть 2: Masterpiece of Shit
    +16
    Консервативность таких интерфейсов связана с двумя большими проблемами:

    • у них огромный пласт легаси (и в плане кода, и в плане сервиса, и в плане бюрократии);
    • их использует широкая аудитория (дифференцированный UX очень ограничивает).


    «Скорость эскадры равна скорости самого медленного корабля» ©

    Когда вы заявляете «я уверен, что...», «я считаю, что», вы опираетесь только на один стиль использования интерфейса — собственный. Но файловым менеджером пользуются и ваша бабушка, и лысый дядя из 90-х, и еще много кто. И у каждого из этих людей есть свой пользовательский опыт, который нарабатывался десятилетиями и слабо пересекается с вашим. И все эти люди составляют значительную часть клиентской базы. Поэтому и меняется такой проект очень медленно и неповоротливо.

    Понимание связи между дизайном и ресурсами

    Глобальные «намоленные» продукты, типа MS — это не столько про картинки на экране, сколько про саппорт, стоимость обслуживания клиента, затраты на внедрение и т.д.

    Представьте: есть среди ваших клиентов миллион клерков в возрасте хорошо за сорок, которые вот уже лет 20 сохраняют файлы, нажимая на иконку «Дискета». И вот одним прекрасным утром они открывают свой софт, а иконки на месте нету. Вам кажется, что это ерунда — разберутся, переучатся. Но для людей это проблема. У них есть сотни других дел, которые требуют внимания. А клик на «дискету» доведен до бессознательного автоматизма. В итоге одна чертова иконка временно парализует работу миллиона людей, часть из них начинает дрючить саппорт, предприятия вынуждены выделять ресурсы на дообучение персонала, всех успокаивать, а сами люди по интерции еще месяц тупят, рефлекторно ища отсутствующую «дискету».

    И всё это деньги: расходы, расходы, расходы — каждый чих автоматом умножается на число пользователей. Причем мы ведь даже логику интерфейса не трогали, всего лишь одну иконку актуализировали. Пример утрированный, для понимания принципа: глобальный редизайн это риски и стресс, которые в лучшем случае временно усложняют всем жизнь, а в худшем приводит к потере части клиентской базы или доли рынка. Нельзя его от фонаря с наскока делать, только потому что вы придумали придумку, пусть даже правильную.

    Редизайн больших проектов проводится за счет эволюции инфраструктуры, а не революции в конкретном интерфейсе

    Чтобы снизить риски, такие интерфейсы редизайнят годами, в час по чайной ложке и заранее подготавливая людей к каждой перемене. Сначала новый UI внедряют в побочные и новые продукты, ждут пару лет, пока у основной массы выработается UX, поменяется картина мира.

    Грубо говоря, есксплореры меняются не изнутри, а под воздействием внешней среды. Когда более молодые и шустрые проекты подготовят людей к определенной опции, только тогда она и появится в динозавре. Трендсеттеры почти всегда работают с более молодой и подвижной аудиторией. Именно поэтому условный Apple может внедрить новую фишку быстрее условного Гугла, а условный MS всегда апдейтнется последним. А какой-нибудь РосГосХренПромСтрой будет по прежнему использовать IE8, потому что средний возраст сотрудников там 50+ и им какбэ даром не надо прогрессивное меню в стиле баттлфилда :)

    Тестировать надо на плохом раскладе и под максимальной нагрузкой

    Попробуйте затестить концепты на возрастной аудитории. Например, слепить прототип на коленке и дать его тупой толстой тётке из бухгалтерии. В идеале, заставить ее отработать в вашем интерфейсе полную 8-часовую смену, стоя у нее за спиной и всё записывая, но не вмешиваясь. Тогда из концептуального счастья начнет вылезать реальность: и проблемы с «понятными» иконками, и постпринт кислотных кнопок в глазах, и тотальное не соответствие прогнозируемого поведения пользователя фактическому и др-др-др.

    И тогда, если сможете абстрагироваться от позиции: «просто та тупая тётка ничего не понимает», ваша картина мира сильно повзрослеет. Крайне наивно думать, что среди тысяч людей, работающих над коммерчески успешным продуктом, нет ни одного умного и компетентного.


    (Картинка не моя, из интернетов)
  • Карьерные стероиды. Путь Самурая
    +8
    всего восемь месяцев, но я тоже был самураем

    1. Нельзя быть немножко беременным :) Либо вы [«вы» риторическое, не берусь судить о вас лично] — описанный типаж по жизни, и тогда все ваше мировоззрение вертится вокруг понятия «долг», со всеми вытекающими отсюда тараканами, системой ценностей, мышлением и проблемами. Либо вы просто временно его имитируете: используете демонстративную абсолютную лояльность в качестве стратегии карьерного роста. Тогда это чистейший стероид с романтическим сахаром.

    2. У самурайства есть очень неприятная обратная сторона. Гипертрофированная «ответственность» порождает синдром вахтёра. В какой-то момент такой человек с изрядной долей вероятности решает, что он лучше всех знает, что хорошо для даймё. И тогда служение превращается в избыточную опеку, лезут наружу ревность, фанатизм, бескомпромиссность и прочее. «Ради дела» такие перцы разваливают родимую структуру почище любого внешнего врага.

    В целом, образ самурая очень уж карамельный. Романтики там не больше, чем в роли собаки при хозяине. И место в иерархии примерно такое же. Абсолютно преданная собака никогда хозяином не станет, она подчиненная, не ее уровень. Ну а если собака матёрая, шибко независимая и потенциально способная претендовать на роль вожака, то рядом ее держать опасно — тут уж либо на цепь и строгий ошейник, либо по-тихому пристрелить за сараем. Преданности в ней примерно ноль.

    Самураи, кстати, как и любая личная гвардия (гвардейцы, преторианцы, опричники, янычары и др.), слабых хозяев время от времени резали без особых комплексов. Все эти красивые бусиды прекрасно трактуются по ситуации — как и рыцарские кодексы, и блатные понятия, и монастырские уставы и прочее. Всегда можно заявить, что даймё нарушил священные традиции и не оправдал высокое звание. В конце концов, ритуализированные своды правил для того и пишутся, чтобы наиболее беспринципные и хитрые люди могли легитимно навязывать свои цели романтикам и конформистам. Нет в этом ничего особо поэтичного.

    А люди из ваших примеров, насколько могу судить, на самураев совсем не похожи. Больше напоминают истории «self-made» лидеров на стадии созревания. Даймё им постольку-поскольку, они двигают подконтрольную тему просто потому что органически не могут не двигать и, тем более, халатно делать что-то на отъявись. Привычка у них такая: раз есть тема, надо двигать. Ну типа как если ваш ребенок голоден, вы берете и кормите — никакой дополнительной мотивации не требуется. Это не служение чему-то, это норма. Типовая модель поведения собственников, предпринимателей и полноценных управленцев. Прослеживается у всех, при любом масштабе деятельности: что на фрилансе в одно лицо, что у «владельцев заводов, газет, пароходов». Собственно, тем они и отличаются от своих стероидных топов. Так что эти люди не исключение, а норма для своего уровня.
  • Удобный БЭМ
    +4
    На мой взгляд, попытка создать «мегауниверсальную» кнопку с тысячей возможных вариаций — это и есть фундаментальная ошибка. Фактически, мы пробуем затолкать в один блок несколько десятков кнопок совершенно разного вида. Здесь автоматом должны возникнуть два вопроса:

    1. А нужны ли реально в проекте десять вариаций кнопки, не затрагивающих ее функциональные возможности? Нельзя ли как-то унифицировать?

    2. Действительно ли всё это именно кнопки? Возможно, танцы с иконками и метками намекают, что больше подошли бы другие контролы: свитчеры, селекты и т.п. Возможно, метке вообще не место на кнопке? Возможно, ее нужно вынести в лейбл?… (Просто общую логику дизайнера иллюстрирую).

    В рамках компонентной дизайн-системы нельзя из прихоти взять и переместить иконку одной из кнопок с левой стороны на правую, а у остальных оставить слева. Для этого должны быть какие-то рациональные причины. И когда эти причины начинаешь анализировать, зачастую оказывается, что нужно не иконку двигать, а менять компоновку интерфейса или использовать какие-то другие элементы управления.

    По крайней мере, мне пока не доводилось сталкиваться с реальной потребностью в таких мегауниверсальных кнопках. Если это существующий проект, с интересом взглянул бы на макеты.

    К слову, на хабре попадались хорошие статьи, раскрывающие суть проблемы. Например.

  • Удобный БЭМ
    +7
    1. «Одноразовый блок» вообще не стоит считать блоком. Это элемент вышестоящего блока. Если у вас форма действительно намертво связана со страницей и вы понимаете, что она не повторится нигде, то перед вами не столько .form, сколько .mypage__form. А вот блоки, ее составляющие (кнопки, инпуты, лейблы) свободно переиспользуются. Да, там может появиться каскад, но если ваш псевдоблок действительно одноразовый, то каскад в нем не может создать проблем.

    .input {}
    .my-page__form .input { /* margin, position, width, ... */ }
    .my-another-page__form .input { /* margin, position, width, ... */ }


    2. Само возникновение «одноразовых блоков» может быть следствием сырого дизайна, как выше справедливо заметили. То же самое, если часто возникает потребность в чисто декоративных модификаторах. На практике они по большей части функциональные, связанные с состояниями (_disabled, _collapsed, _invalid — такого плана). И как следствие, по большей части булевы. Если у вас много модификаторов вида «_ключ_значение», то есть смысл еще раз подумать над всей дизайн-системой, почти наверняка там не всё хорошо.

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

    /* ../base/button.css */
    .button {display: block; cursor: pointer; ...}
    /* ../project-red/button.css */
    .button {background: red; ...}
    /* ../project-blue/button.css */
    .button {background: blue; ...}
    


    Никаких модификаторов тут не требуется. Индивидуальные стили проектов не надо хранить в общих компонентах. Иначе вам при 100 проектах пришлось бы в каждом блоке таскать с собой 100 модификаторов, из которых 99 не используются в текущем дизайне. Дело тут не БЭМ, а в архитектуре проектов и сборке.

    Модификаторы хороши в том случае, если у вас внутри текущего проекта есть одновременно, например, несколько разновидностей кнопок. Скажем, иконические и без иконок. Или синие для безопасных действий и красные для опасных. Вот тогда у вас могут появляться модификаторы: button_iconic, button_safe,… и т.д. Это имеет смысл, потому что они нужны все сразу в текущем проекте.

    P.S. Не то чтобы я был адвокатом или ярым фанатом БЭМ, но по факту 99% постов о «проблемах БЭМ» (в контексте именования и CSS) в итоге сводятся к тому, что автор упускает какой-то нюанс или не в полной мере понимает какую-то часть методологии. Поэтому, если возникает желание сделать свой особый БЭМ с преферансом и одалисками, то с очень большой долей вероятности что-то делаете не так.
  • Особенности подходов к дизайну в реальном производственном секторе
    0

    Всё это заимствования, сделанные N лет назад.

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

    Слово «дизайнер», кстати, тоже было в свое время предметом подобных споров. Мол, нечего выпендриваться, вы же просто художники-конструкторы (так официально называлась позиция, которая соответствовала вашему представлению о дизайне). Но мир немножко изменился, и сейчас понятия вроде «design engineer» уже никого особо не смущают. Я понимаю, что кому-то может быть трудно существовать в мире нечетко детерменированных систем. Хочется чтобы всё было по полкам, с четкими рамками. Но это жизнь. Дизайнер не обязательно художник конструктор, точно так же как врач не обязательно терапевт.

    Повторюсь, слово design повсеместно применяется в том числе и для описания инженерных, архитектурных и других решений. Нет жесткой границы между этими дисциплинами именно потому, что в сложных областях (бац, аэродинамика!) пересечение в теоретической базе приближает их друг к другу. Между промдизайнером и инженером гораздо больше общего, например, чем между ним же и графдизайнером. Но это не делает промдизайнера ни инженером, ни «рисователем картинок».

    P.S. Аудиодизайнер гуглится по запросу sound designer. В принципе, как человек посторонний, я бы согласился на термин «звукорежиссер». Но вилка уже наметилась, т.к. звукорежиссеры это всё-таки про драматургию, а не про ускорение трафика в ТЦ за счет подбора ритма или про «мелочи» вроде голосовых интерфейсов или сигнальных систем для слепых и т.п. Чем дальше, тем больше будет таких приземленных чисто логических задач, не связанных со сценой, эстрадой и творчеством. Так что рано или поздно они открестятся друг от друга точно так же, как дизайнеры и художники.

    ***
    Извините, не готов дальше дискутировать. Похоже, мы с вами живем в параллельных вселенных, которые толком не пересекаются :) А времени постинг съедает много. Но в любом случае успехов и спасибо за мнение.
  • Особенности подходов к дизайну в реальном производственном секторе
    0
    А дизайн в первую очередь это как раз картинки в вакууме, визуальные свойства… разработка взаимодействия это уже проектно-инженерные решения.

    Такое представление — фундаментальная проблема дизайна на постсоветском пространстве. Во многом благодаря ему и возникает разница в качестве продукции.

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

    Об эту проблему разбиваются попытки импортозамещения в тех отраслях, где спрос хоть как-то зависит от конечного потребителя. Не хочу тыкать пальцем в конкретные торговые марки, чтобы не обижать людей, которые вкладывают в них силы и время. Но примеров много.

    Дизайн в «западном» [тоже плохой ярлык, но для простоты] понимании намного шире, чем принято было считать у нас. Он давно вышел за пределы оформительства и понимается скорее как междисциплинарная область знаний, которая обеспечивает взаимодействие человека со средой. Причем не только визуальной, любой.

    Дизайн есть везде, где есть восприятие органами чувств. Аудиодизайн, кинэстетический дизайн, да хоть обонятельный. Зацикленность на «картинке» объяснятся тем, что зрение поставляет человеку наибольший объем ключевой информации для принятия решений. И работать с ним проще и привычнее. Но все уже давно поняли, что картинкой дело не ограничивается. Шершавое сигнальное покрытие на дорогах и азбука Брайля — это тоже дизайн. Интерфейсы можно строить на любых сигналах, была бы целесообразность.

    Понимание этого факта размывает границы между инженерными дисциплинами и дизайном. Нет однозначной черты, которая отделяет аэродинамику от дизайна автомобиля. Нельзя сделать удобную мебель без понимания анатомических особенностей человека. И т.д. Поэтому понятие дизайна постепенно подминает под себя эргономику, техническую эстетику и многие другие вещи. И чем сложнее продукт, тем шире теоретическая база, необходимая его дизайнерам (совокупно, специализации никто не отменял). Так что современное понимание дизайна подразумевает междисциплинарность понятия.

    Поймите правильно, я не имею в виду, что земля вертится вокруг дизайнеров. Профессия как профессия. Речь о том, что постсоветское восприятие дизайна как этакого «финишного покрытия» инженерии приводит к серьезным провалам. Дизайн — неотъемлемая часть любого продукта с самого начала его создания и на каждом этапе, который хоть как-то касается восприятия продукта человеком.

    Насколько я понимаю, пост в том числе как раз об этом. И пост хороший.

    P.S. «Замерять метрики» — это тавтология :) Но дело не в этом. Их можно снимать, получать, фиксировать, документировать, отслеживать, контролировать, учитывать и т.д. И трекать тоже можно. Способность поглощать и растворять в себе неологизмы — самая сильная сторона русского языка. Люди, которые стремятся избавляться от кальки и заимствований, лишают его главного преимущества и сырья для развития. Такой «чистый» русский язык уже изобретен, называется basic english — там хватает десяти слов на все случаи жизни. Если же вы действительно хотите сохранить полноценный русский язык во всем его великолепии, то не мешайте ему поглощать все остальные. Такой вот парадокс.
  • Столетний холивар: креативность против юзабилити
    +11
    Вот вроде простые вещи же. Искусственная проблема на пустом месте.

    1. Юзабилити — это креативность, обкатанная практикой

    Никакого противопоставления креативности и юзабилити не существует. Это разные механизмы эволюции, как генерация поколений и естественный отбор. Их приоритет зависит от стадии задачи и накопленного опыта.

    Креативность важна на этапе превопроходцев, когда нет обкатанных решений. Мы генерируем варианты без каких-либо ограничений. И запускаем их в жизнь. А дальше всё лишнее постепенно начинает отсекаться бритвами опыта и обратной связи. И если условия задачи относительно четкие и постоянные, то рано или поздно творческий хаос стабилизируется и остается пара наиболее удачных решений из числа предложенных. Для конечной задачи не нужна бесконечная креативность.

    Это универсально и естественно:

    • идейные революционеры сменяются практичными администраторами,
    • на смену разным зарядкам от самсунгов и моторолл приходят USB,
    • гаражные кулибины на массовом рынке вытесняются жестко регламентированой промышленностью,
    • алмазы разнообразных форм оформляются лишь десятком стандартных огранок,
    • ...

    Юзабилити — это фильтр для креативности, а не ее альтернатива.

    Юзабилити отсеивает результаты креативности, не прошедшие естественный отбор. Их нельзя противопоставлять в лоб. Такой же абсурд, как противопоставить работу программиста и тестировщика ПО, например.

    Если следовать логике статьи, то бриллиант — это такой очень скучный и банальный природный алмаз. Ведь природа создает миллиарды камней уникальной формы. А мы, по скудоумию, граним их все одинаково) Но де факто, эта «логика» просто игнорирует факты: у огранки есть прикладные цели, завязанные на преломление света, поэтому она определяется геометрией и оптикой, а вовсе не художественными идеями. Подмена понятий.

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

    Например, до веба в бумажной типографике десятки лет не пересматривались базовые пропорции (кегль/интерлиньяж, например). Но пришел веб и мы быстренько закреативили, поставив все истины под сомнение. И разродились увеличением интерлиньяжа. А потом, когда экраны выросли, мы и кегль увеличили в полтора раза. А с приходом мобильников юзабилити сайтов вообще радикально изменилось. В эру бумаги такая же креативность просто не имела бы смысла. Ну увеличили бы мы кегль, ну выросла бы стоимость издания в полтора раза за счет бумаги, ну сгнил бы тираж на складе — это и есть фильтр юзабилити в действии :)

    2. Дизайн — это самоограничение, а не свобода творчества

    Вечная проблема «художников»: путают дизайн и искусство. Да, есть сходство в процессах и пересечения в теоретической базе, но цели-то фундаментально разные)

    Цель дизайна — решение коммерческих и производственных задач. Это измеримые, приземленные, практичные вещи. Поэтому вся визуальщина обязана плясать ровно в тех рамках, которые позволяют добиваться целей. Это не значит, что всё всегда сводится к деньгам. Цели могут быть и не финансовыми, особенно промежуточные. Но держать их в голове — обязательно. Они выше по приоритету и креативности, и трендов, и личных вкусов дизайнера. И, кстати, выше юзабилити (!), если возникают противоречия.

    Недаром в студенческие годы, когда ничего толком не знаешь и не понимаешь, креативность прёт изо всех отверстий :) Любой выпускник на новом месте рвётся с нуля переделывать буквально всё: от логотипа с 70-летней историей, до производственной линии. Но уже через год-другой появляется опыт, который позволяет прикидывать и стоимость реализации идеи, и последствия, и риски. И тогда, внезапно, креативность уступает место анализу.

    Вообще, чисто субъективно: веб-дизайнером человек становится в тот момент, когда получает возможность напрямую работать с обратной связью: цифрами, статистикой, вебвизорами, а главное — динамикой прибыли. Кто сталкивался, тот начинает совершенно другими глазами смотреть на концепты с бихансов и дрибблов.

    3. Пилюля от холиваров

    Резюмируя, если вас (читателя) смущает или удивляет однообразность дизайна сайтов, которые решают одинаковые задачи, то:

    • либо вы не до конца понимаете принципы их дизайна (и тогда это решается наработкой опыта),
    • либо вам не дают покоя творческие амбиции (и тогда стоит поискать себя в искусстве),
    • либо вы увидели какую-то конкретную дырку в бизнес-логике этих сайтов или потенциал для ее развития за счет конкретных новых методик дизайна (и тогда вы либо будущий трендсеттер и потенциальный миллиардер, либо см. первый пункт),
    • [либо вы просто решили хайпануть и тогда тема не имеет значения :].


    Всё очень, очень просто.