Схема цепи преобразования данных в системах с интерфейсами
⎯⎯⎯
Метод схематизации вариативности данных в точках их преобразований в информационной системе
Предисловие
Давно хотелось найти подход к схематизации протекание данных в информационной системе вдоль ствола потока пользовательского внимания. Случай на последнем проекте представился идеальный. В зависимости от ввода посетителя сайта требовалось выбирать одну из пяти моделей поиска. Данные вводились в два поля — технологически на тот момент сделать иначе не удавалось. Комбинаций вариантов ввода и реагирования было настолько много, что удерживать их в памяти или городить макеты на каждый случай казалось неподходящим решением. Так родилось представление, описанное в этой статье. А вот, кстати, и пример таблицы перебора в самом начале ситуации:
Варианты перебора в схеме и наборы, что их породили (левее). Не беда, если схема кажется сложной и непонятной, статья призвана снять все вопросы
В статье описан подход к схематизации движения данных в цифровом сервисе. Он основан на таблицах решений, понятиях преобразователя и предохранителя, категориях причина—следствие и смысл—форма.
Я считаю, что метод будет полезен дизайнерам интерфейса, аналитикам, разработчикам и инженерам качества и всем, кто детально проектирует работу цифрового сервиса. Подобные схемы выступают на проекте инструментом проектирования и коммуникации о вариантах решений на уровне процесса и данных. Вижу пользу в них во взаимодействии разработчиков, инженеров качества и дизайнеров.
Метод прекрасно дополняет и может применяться совместно с такими процессными нотациями как карта процесса-опыта, карта пользовательских историй и метод ключевых действий.
Модель «предохранитель-преобразователь»
Конвейер переработки данных
Будем представлять любую информационную систему как цепь последовательных шагов по преобразованию данных. Каждый отдельный шаг делает свой вклад в этом преобразовании и соединяется со следующим, собирая таким образом конвейер обработки данных.
Внутри такого конвейера данные обрабатываются, уточняются вычислениями или людьми, на их основе выполняются запросы в другие системы и принимаются важные решения. И результаты запросов, и принимаемые решения — всё это данные в общем потоке конвейера.
Преобразователь
Будем называть каждый шаг в таком конвейере преобразователем. Какие-то данные поступают на информационный вход преобразователя и после преобразования оказывается на его информационном выходе. Преобразователь является «черным ящиком»—решателем, выбирающим исход по набору входных значений.
Чему соответствуют преобразователи в реальных информационных системах? Ими могут быть:
вызовы внутренних или внешних сервисов, в этом случае преобразователями являются вызываемые сервисы;
отдельные процедуры функции, методы в потоке вычислений внутри одной программы;
работа человека с интерфейсом системы.
Да, человек, работающий с системой через её интерфейс в этой модели рассматривается как преобразователь. Он получает какие-то данные, интерпретирует и понимает, что предпринять, вводит новые данные в ответ на ситуацию и отправляет всё это дальше.
Предохранитель
Было бы здорово, если бы данные на входе в преобразователь подбирались идеальным образом. Реальность же устроена так, что на вход может попасть что угодно. Данные могут быть реалистичными, но экстремальными для нашего преобразователя — он может не уметь работать с ними. Или же данные на входе могут быть откровенной чушью и бессмыслицей. На этот случай любой преобразователь снабжается предохранителем.
Схема преобразователя с предохранителем
Задача предохранителя не допустить запуска преобразователя с «грязными данными». В автоматизированных сервисах этому служат коды результатов работы и сообщения об ошибках. В интерфейсах пользователя — искусственные ограничители и обратная связь (Норман, 2006; Купер, 2009).
Предохранитель обычно оставляет передаваемые на вход данные не тронутыми, снабжая их пояснением о том, что с ними не так.
В этой модели предохранитель является вспомогательной конструкцией внутри преобразователя. Поэтому при упоминании преобразователя далее будет имеется в виду, что внутри него может быть предохранитель.
Чувствительность к вариациям смысла и формы входных данных
Представим, что человек приходит на сайт за тем, чтобы найти и купить запчасть или автоаксессуар для своего автомобиля. Он встречает поле ввода с названием «Товар, товарная группа» и вводит туда свою потребность в том языке как он её понимает и может сформулировать.
Один раз он вводит артикул товара, в другой — комбинацию из бренда-производителя и одного из параметров товара, например, вязкости моторного масла. Однако, если наш преобразователь не готов обрабатывать данные в такой форме, нам следовало бы явно на это указать, настроив предохранитель на соответствующие случаи.
Входная таблица вариантов ввода в приёмный лоток и таблица вариантов в преобразователе
Чем выше чувствительность к различению вариантов ввода, тем выше интеллектуальность звена в конвейере преобразователей. Обеспечение требуемой чувствительности — одна из инженерных задач.
Ясно, что лучше, когда высокая чувствительность обеспечена на уровне преобразователя. Тогда большее число ситуаций будет обработано и передано далее по конвейеру. Менее превосходная ситуация, когда чувствительность перекладывается на предохранитель. При этом обработка состоит в пояснении о том, что неверно во вводе и рекомендациях как это исправить, изменив форму запроса. Наихудший вариант, когда звено ничего не знает о большинстве вариаций и ведёт себя непредсказуемым образом.
Нотация схемы цепи преобразований
Таблица преобразователя
Рассмотрим более пристально один преобразователь. Чтобы его описать полезно ответить на следующие вопросы.
Какова функция преобразования, в чем её смысл? Какой способ преобразования используется?
Какова чувствительность преобразователя и предохранителя: сколько вариантов ввода по разным формам обрабатывается, а сколько лишь распознаётся и возвращаются назад для коррекции?
Каковы функции вход и выход по задумке, что в них ожидается принимать и получать?
Каковы формы значений вход и выход: что реально вводят и что попадает на выход, учитывая все вариации?
На схеме метода, к которой мы постепенно переходим, преобразователь описывается таблицей с шапкой. В шапке фиксируются общие сведения, а внутри таблицы — все или только значимые вариации входа и выхода.
Пример таблицы преобразователя для простого случая. В этом примере варьированию придали лишь выход, оставив без внимания вариации входа
Вот что я обычно фиксирую в шапку таблицы преобразователя на сквозном примере.
Контекст — описание смыслового места в общей цепи преобразований. Пример: Интерактивный диалог выбора модификаций автомобиля из перечня всех модификаций, относящихся в одному номеру VIN, когда такая множественность присутствует.
Функция — назначение и способ преобразования. Пример: Выбор модификации из перечня.
Вход — смысл и структура данных на входе. Пример: Перечень модификаций, список объектов.
Выход — смысл и структуры данных на выходе. Пример: Одна выбранная модификация, один объект такой-то структуры.
Интерфейсная формула, если преобразователь интерфейсный — формула в нотации структурного языка интерфейсных ситуаций. Пример: ^{Модификации}[…] −> {Модификация}.
Преобразователь в общем случае является решателем, исполняющим некоторую бизнес-логику. Другими словами, он перебирает варианты условий и выдаёт решения на каждую из комбинаций. Такие решатели элегантнее всего записывать в форме таблиц решений. Такие таблицы примеряются, например в нотации в Decision Model and Notation (DMN), тесно дружащей с BPMN-нотацией.
Вот простой синтетический пример таблицы решений с двумя входными параметрами и одним выходным. Входных и выходных параметров может быть произвольное число и зависит от ситуации, где используется преобразователь. В таблице ниже два входных параметра имеют каждый словарь из двух вариантов значений, что рождает четыре комбинации на выходе.
Вход А | Вход Б | Выход 1 |
|---|---|---|
☼ | ☂︎ | Результат для комбинации ☼ + ☂︎ |
☼ | ✿ | Результат для ☼ + ✿ |
☁︎ | ☂︎ | Результат для ☁︎ + ☂︎ |
☁︎ | ✿ | Результат для ☁︎ + ✿ |
А вот пример реальный. Преобразователь ниже стоит в самом начале цепи и «слушает» варианты ввода в поле. Его задача распознать ввод и запустить либо необходимые подсказки, либо в случае, когда ничего не определится классифицировать ситуацию как «остальное».
Соединение таблиц в схему цепи преобразований
Схема цепи строится из сети таблиц отдельных преобразователей. Все или отдельные результаты с выхода одного преобразователей попадают на вход следующего. Так преобразователь соединяются друг с другом, создавая туннель для движения потока данных.
На этот момент у вас должно быть достаточно вводных для чтения таблиц преобзований и начала попыток составления собственных. Ниже я привожу фрагмент и целую карту с одного из реальных коммерческих проектов в сфере электронной коммерции с таким сложным товарным ассортиментом как автозапчасти. Я лишь немного изменил наименование методов и каталогов, в остальном схема осталось той, что дала нашей команде представление о том, что мы делаем.
Фрагмент
Первые рекомендации
Метод был применён пару раз в отдельных проектах. Опытное использование не накопило достаточной вариации для всестороннего описания. Однако первые сложности уже были встречены, и я дам рекомендации из того, что проявилось на текущий момент.
Одно поле — один преобразователь
Возникал соблазн делать схемы лаконичными и включать несколько полей ввода в один преобразователь. Опыт показал, что это плохая идея. Потому что в этом случае варианты перебора увеличиваются и при строгом следовании становится видно, что удобнее разделить ответственность на два преобразователя.
Я рекомендую использовать на каждый элемент интерфейса отдельный преобразователь. Некоторые элементы, такие как комбобокс, требуют несколько преобразователей на себя. Это происходит в случаях когда содержание справочника допустимых значений в предохранителе зависимо от входных данных. В этом случае полезно применить преобразователь на справочник значений, подставляющихся в подсказку комбобокса. Итак, первое правило, сколько интерфейсных элементов ввода, столько и преобразователей, не меньше.
Что варьировать
Всегда возникает вопрос, что именно варьировать. Вы заметили в примере выше, что иногда варьируется только выход, например. Это всецело зависит от вашей ситуации и интереса. Схемы всегда инструмент вспомогательный, а не основной. Если вам важно увидеть только вариации результата, вы вводите их, оставляя на входе чёрный ящик «значение». Если вам важно перебрать по смыслу и формам содержания все вариации ввода, вы делаете это. Аппетит здесь определяет необходимость. Мне было невозможно проектировать дальше без перебора двух переменных и вариантов результата, это и предопределило мой выбор.
Простой пример где варьируется только выход
«Нет» границам профессиональной специализации
Работая с цепью мы всегда дойдём до преобразований, творящихся на фронтенде и бэкенде. Дизайнеров интерфейса обычно пугает выход за пределы своей области профессиональной специализации. Но метод схемы цепи преобразований требует как минимум сходить и узнать, а то и договориться как в каждом месте будет вести себя цепь, что за преобразователь из имеющихся предстоит подставить или написать вновь.
Что дальше
У меня хорошие предчувствия по поводу применимости и ценности приведенного подхода. Он только начинает свой путь в жизнь, и мне, как автору, будет интересно как это приживается в вашей практике. Напишите, мне если вам кажется перспективным этот подход, но у вас остались вопросы по нюансам его применения. Или делитесь своими схемами и проблемными ситуациями, что вы встретили и на которые не нашли инструментов в этой статье.
Библиография
Алан Купер об интерфейсе. Основы проектирования взаимодействия, М. — 2009, Символ-Плюс
Дональд Норман, Дизайн привычных вещей, 2006
