Тупые и умные компоненты

    Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хобби в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.


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

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

    Что вообще такое компоненты

    Графический интерфейс (GUI), как правило, состоит из кнопок, полей, чекбоксов, текстовых блоков и пр. Именно это мы называем «компоненты» — эдакая интерактивная (или нет) «обёртка» контента: кнопка «Оформить заказ»; чекбокс «Я принимаю условия соглашения» и т.д.

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

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

    Посмотрим на простом примере

    Дизайним карточку товара в интернет-магазине: картинка, информация, цена и кнопка «Купить».

    А ещё требуется карточка товара для корзины. Там нет кнопки «Купить», зато есть кнопка «Удалить» и селектор количества товара. Звучит как новый компонент. Делаем!

    Спустя какое-то время дизайним новую фичу — личный кабинет. Карточка требуется уже не для товара, а для пользователя. Совсем другой компонент. Делаем!

    И вот у нас уже 3 компонента «Карточка».

    Карточки во всем своем многообразии
    Карточки во всем своем многообразии

    Теперь мы хотим показать информацию о заказе в личном кабинете. Неплохо смотрелась бы… Карточка!
    Какую же из трёх использовать? Ни одна толком не подходит. Проще уже сделать новую.


    Проходит время, карточки разработаны и живут в разных местах системы.

    Однажды мы решаем разом модернизировать все карточки — сделать изображения круглыми. Модно!
    Изменения во всех карточках становятся испытанием для дизайнера и болью для разработчиков, потому что карточек много и они разные.

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

    Изменений бы потребовалось в три раза меньше, если бы карточку переиспользовали.

    Зачем и как переиспользовать компоненты

    Переиспользование компонентов помогает:

    1. облегчить жизнь себе и разработчикам;

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

    Во имя переиспользования, по примеру разработчиков React.js, делим компоненты на два типа: «тупые» и «умные».

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

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

    Шаблон карточки и примеры его применения
    Шаблон карточки и примеры его применения

    Пример с карточками сделан в Figma. «Тупая» карточка — Figma-component с применением Auto Layout. Благодаря этому элементы карточки можно удалять и менять, а её размер подстроится под изменения. Умная карточка — Figma-instance.

    Достаточно внести изменения в «тупом» компоненте, и они автоматически окажутся в «умных». Также происходит и в разработке, если код компонента переиспользуется.

    Скругление всех картинок одним движением
    Скругление всех картинок одним движением

    Тупой UI kit

    Простая и понятная библиотека компонентов (UI kit), элементы которой легко переиспользовать и обновлять — турбо-ускоритель дизайна и разработки. И состоит такая библиотека из тупых компонентов. Я называю её «Тупой UI kit».
    Если на вашем проекте уже есть UI kit, попробуйте сделать все компоненты в нём тупыми. Скорее всего, вы с удивлением обнаружите, что многие компоненты можно унифицировать: объединить похожие или удалить повторяющиеся. «Отупить» UI kit может быть непросто, понадобится время на ревизию системы и сильный дизайн-инструмент. Figma отлично справляется, но и Sketch не отстает.

    «Тупой UI kit» облегчит работу над дизайном, избавив от необходимости плодить компоненты и изобретать велосипед. Разработчики тоже скажут вам спасибо за то, что они могут переиспользовать код компонента.
    «Тупой UI kit» также может стать основой для создания Storybook проекта.

    Выводы

    Разделяя компоненты на «умные» и не очень, вы:

    1. создаете унифицированный интерфейс;

    2. оптимизируете дизайн и разработку, не выдумывая новые компоненты без необходимости;

    3. оставляете возможность легко вносить изменения в дизайн и код;

    4. делаете поведение компонентов предсказуемым для пользователей.


    Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале «Поясни за UX».

    EPAM
    Компания для карьерного и профессионального роста

    Комментарии 20

      0
      Изменений бы потребовалось в три раза меньше, если бы карточку переиспользовали.

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

        0

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


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

        0
        А можно «тупой» заменить на что-то более благозвучное? Ну, к примеру, «простой»?
          +2

          Feel free Можете использовать любое удобное название))

            0
            Это скорее вопрос, сам немного затупил, как адекватно перевести dummy на русский в данном контексте.
              +2

              Мне лично слова "глупый" и "тупой" кажутся наиболее подходящими, потому что отражают отсутствие привязки к контексту. Всё-таки "простой" это немного о другом. Но тут как вам удобнее))

                –1
                В среде React «тупые» компоненты обычно называют «глупыми». Например, тут.

                Ещё есть такая статья по теме различий этих двух типов компонентов, там терминология немного другая.
                0
                Со словом dummy ничего особо сложного нет: вполне можно использовать его прямое значение — «модель, макет». И «тупые компоненты» можно назвать, например, «компонентами-макетами».
                Только вот обычно для такого противопоставление компонентов программы, как в статье, в англоязычных технических текстах чаще, по моему наблюдению, используется альтернатива dumb-smart. И вот подобрать другое слово для перевода dumb я лично затрудняюсь: в частности, прямое значение — «немой» — тут явно не годится.
                  –1
                  в фигме нормальные названия component — instance.
                  по русски можно называть общий/абстрактный и частный случай
            0
            Выглядит как изобретение шаблона…
              0

              Да, буквально там так и написано)) дизайнеры редко используют этот подход, к сожалению

                0
                Лично мне странно, что у вас разработкой переиспользуемых компонентов занимаются дизайнеры. По опыту работы в другой, сходной области — разработка UI программ для Windows на Delphi — я склонен считать, что разработка повторно используемых компонентов — это задача программистов. Потому как имеющиеся в языках с классическим ООП (инкапсуляция-наследование-полиморфизм), типа Delphi инструменты для этого — это программистские инструменты. Про используемые у вас инструменты я несколько не в курсе, но полагаю, что ситуция сходная.
                  0

                  Дело не в инструментах, а в подходах и командной работе.
                  Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
                  Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
                  Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
                  Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.

                0
                Вероятно, как выглядит, так оно и есть.
                0
                Однажды мы решаем разом модернизировать все карточки — сделать изображения круглыми. Модно!

                Плохой пример. Часто встречал требование вида,
                — вот тут, тут и тут круглое. А вот тут оставить как было. Это же не долго, час не больше.
                — Но… Это же один и тот же компонент!
                По этому разбиение на компоненты как предлагаете вы это палка о двух концах. Для себя я лично решил что stateless это всякие примитивы. А умные компоненты можно делать вообще без рендерера, чисто базовый с abstract методами. Если это прям так необходимо.
                Хотя тут скорее всего от проекта зависит.

                  0

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

                  0
                  Я, наверное, не до конца понял, но для меня карточка состоит из:
                  MainView — главная «рамочка» карточки
                  ImageView — картинка
                  HeaderView — заголовок
                  DescritionView — описание
                  PriceView — цена
                  ControlView — кнопочки
                  и т.д.

                  Хотим картинку в круге? Меняем ImageView.
                  Нужно в карточку добавить сводную информацию о заказах? Создаём SummaryView.
                  Зачем делать тупую рыбу-заглушку?
                    0

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

                      0
                      А если все эти кнопочки не нужны, то куда они деваются? Остаются в коде как мусор?
                        0
                        Они остаются в коде (и в дизайне) как элементы компонента, готового к изменениям при необходимости. Если вас беспокоит проблема неиспользуемого кода, то, насколько мне известно, Storybook позволяет снизить его количество засчет хранения компонентов отдельно от кода продукта. Но тут меня разработчики могут поправить

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое