Comments 6
Классная статья!
Спасибо за подробное описание версионирования.
Обязательно попробую бранчинг в фигме)
Я думал об инструменте автоматического тестирования, который позволит не ломать UX пользователя, и предотвращать дизайнерские катастрофы, вроде той, что произошла в Firefox при переходе с Photon на Proton (ff 89+). Semver на это очень хорошо ложится.
Идея в том, что ты описываешь UX (ожидания пользователя от компонента) в тесте.
Например, пользователь ожидает что активный таб легко отличить от неактивного.
примеры на псевдоязыке
TestActiveTabIsDistinguishableFromInactive
distinguishableContrast = 4.5; // WCAG AA
tabsContrastValue = getContrast(components.tab_inactive.background-color, components.tab_active.background-color)
assert(distinguishableContrast, tabsContrastValue)
Другой пример: пользователь ожидает, что если во вкладке N воспроизводится звук, то на ней отображается кнопка (т.е. интерактивный элемент с toggle поведением) Mute
TestPlayingTabHasMuteButton
muteControlSelector = '.control-mute'
hasMuteControl = components.tab_playing.getControlEmelents().contains(muteControlSelector)
assertTrue(hasMuteControl)
TestPlayingTabMuteButtonIsIvisible
<...>
assertVisible(muteControlEl)
TestPlayingTabMuteButtonIsInteractive
<...>
assertClickable(muteControlEl)
TestPlayingTabMuteButtonHasToggleBehavior
<...>
assertEquals('toggle', muteControlEl.behavior)
Теоретически и технически это, кажется, реализуемо.
По мере накопления тестов, можно будет обобщить термины distinguishable, interactive, итп на уровне проекта, что позволит выстроить более умную дизайн систему.
Плюс в том, что в проекте зафиксированы ожидания пользователя (UX), и новый дизайнер, придя в проект, не нарушит их (твой новый clean modern fresh new look не принимается, пока не проходит тесты соответствия текущим пользовательским ожиданиям).
Проблема в том, что если переусердствовать с детальностью описания, то к интерфейсу в принципе невозможно будет прикоснуться: любое изменение что-нибудь да поломает. Начнут фиксировать размеры в пикселях/цвета итп — тесты перестанут приносить пользу, так как будут просто фиксировать текущую версию дизайна.
То есть должна быть какая-то грань на уровне принципа/методологии.
Мы не фиксируем, например, координаты кнопки "закрыть", но фиксируем, что кнопка должна быть в правом верхнем углу для Windows юзеров, и в левом верхнем для Mac.
Мы не фиксируем, что активный таб становится distinguishable только через контраст фона (как в моём примере), а на уровне проекта описываем разные трактовки distinguishable (контраст фона, подчеркивание/обводка, итд итп) и сверяемся по ней.
Общая проблема дизайнеров и UX специалистов (такой профессии не должно существовать, имхо) в том, что они говорят на языке чувств и ощущений, их требования субъективны, и ввиду этой субъективности, могут не совпадать с пользовательскими. Они нигде не описываются, поэтому меняется человек -> меняются субъективные требования -> выкатывается новый дизайн, который ломает ожидания пользователей -> пользователям стало неудобно.
Подобная штука (если к ней додумать внятную методологию, сформулировать принцип консервативности интерфейса) позволит говорить на одном формальном языке.
Да, и увы у Version history есть такой большой минус. Поэтому пользоваться им нужно аккуратно. Мне нравится в нем только то, что можно копипастить проект в нужном временном отрезке, в новый файл, и от туда уже брать нужные макеты. Но и тут есть загвоздка, если мы до этого меняли что-то в ветке, прошлые макеты могут быть недоступны для копирования(
Как UX/UI-дизайнеру не потеряться в тысяче макетов в Figma: новый инструмент контроля версий