Михаил Веткин

Почему происходит это горение?Пользователь при выборе из множества иконок сперва использует перефирическое зрение, которое хорошо развито у человека. Оно позволяет быстро реагировать на внешние сигналы. Проблема только в том, что для него это не иконки, а пятна иконок.Ему всё равно, что дизайнер нарисовал число в квадратике, что один квадратик это прямоугольник, а у третьего квадрата есть стрелочка справа. Ему даже все равно, что это никакой не квадрат, а круг со стрелкой внизу. Для такого зрения это разноцветное пятно с дыркой посередине. Но это ещё не всё.В психологии есть такое понятие как интерференция. Это когда несколько психологических процессов, как волны в физике, накладываются друг на друга и мешают быстро принять решение.Проактивная интерференция — это когда уже накопленные знания мешают обучению.Я пользуюсь gmail около 15 лет. За это время я и множество других пользователей привыкли к тому, как выглядит значок gmail, взять и просто поменять значок на совсем другой — просто воткнуть палки в колёса пользователям.

Хороший, плохой, злой: дизайн иконок внутренних сервисовЭта заметка появилась благодаря дизайнерам Google, которые в 2020 году анонсировали новую айдентику своих сервисов.С этого момента я каждый раз горю, когда пытаюсь тыкнуть на Google Meet, а попадаю в Gmail и наоборот#хороший_плохой, #design, #ux_ui

Запущенный примерИногда это вырастает в монструозные куски нетестируемого кода, который настолько сложно понять, что легче удалить и начать заново.Это только маленькие кусочки. Сами компоненты примерно по 1000 строк кода.

Да легко! Просто добавьте туда немного логики, потом придёт другой программист с микро-правкой и добавит ещё немного логики.Первый примерВ зависимости от того, есть ли у нас идентификатор магазина, мы либо ставим куки, либо очищаем.Логика проста. Но это всё ещё логика, которая может быть описана конкретным тест кейсом и вынесена в редьюсер.Второй примерКаждый раз при запуске этой функции ставится loading, пользователь видит загрузку. Потом если ответ сервера — OK, показываем предлагаемые компании.Это ещё один нетривиальный кусок бизнес логики, который оставлен без unit-тестов.

Хороший эффект должен быть скромным, максимально безынтересным местом в коде. В нём нет бизнес логики. Его смысл заключается в том, чтобы просто связывать различные части в вашем приложении, реагировать на простые сигналы.Например, для управления настройками мне нужно сначала эти настройки получить с сервера.В прошлой заметке я вернул из редьюсера объект с эффектом, который попадает в effector-функцию. Через конструкицю switch-case распределяются эффекты, которые надо выполнить.Единственное, что делает эффектор, это:1. Запрашивает данные из API2. Отправляет сигнал о том, что нужно обработать ответ в «чистой» части приложения.Тут почти невозможно ошибиться, нечего тестировать, не нужно долго рефакторить при изменении требований.Просто связываются разные куски кода.Но как можно написать плохой эффект?