{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Блог Ильи Бирмана: заметки с тегом метод", "_rss_description": "Блог Ильи Бирмана о дизайне, городах, музыке и жизни.", "_rss_language": "ru", "_itunes_email": "ilyabirman@ilyabirman.ru", "_itunes_categories_xml": "<\/itunes:category>\r\n<\/itunes:category>\r\n\r\n", "_itunes_image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic-square@2x.jpg?1573933764", "_itunes_explicit": "no", "home_page_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/method\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/method\/json\/", "icon": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764", "authors": [ { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" } ], "items": [ { "id": "6094", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/ui-and-data-flow\/", "title": "Интерфейс и поток данных", "content_html": "

Это черновик, который я решил опубликовать.<\/p>\n

Поток данных — один из моих методов проектирования интерфейса. Он помогает избавиться от ненужных экранов и шагов.<\/p>\n

С точки зрения ТРИЗа, идеальный интерфейс — это интерфейс, которого нет, но его функция выполняется. И об этой функции можно думать как о функции посредника на пути потока данных: данные текут между людьми и машинами, а интерфейс как-то в этом участвует.<\/p>\n

Простой пример<\/h2>\n

Человек собирается в поездку и хочет узнать погоду в городе назначения. В идеале должно быть так: человек только подумал об этом, и хоп — уже знает погоду. Но пока что это недостижимо, нужен интерфейс.<\/p>\n

Интерфейс помогает данным о запросе человека попасть в машину; данным ответа попасть к человеку. Не прозевайте: предыдущее предложение — ключевое, ведь в нём написано, зачем нам вообще этот интерфейс! Так данные на входе — это город, а на выходе — погода. Отсюда получаем интерфейс: поле ввода города, и рядом — погода в нём.<\/p>\n

Дальше уже его улучшаем автодополнением, обновлением по мере ввода, историей; помним город или даже несколько с прошлого раза, чтобы даже не вводить. Это просто применение базовых принципов.<\/p>\n

А как было бы неправильно? Ну, например, начать анализировать предметную область, из каких параметров складывается погода и как их сгруппировать, или там как города объединяются в страны, а страны в континенты, проектировать навигацию по этой базе. Это всё «логично», но не должно быть основой интерфейса, так как не помогает потоку данных.<\/p>\n

Сложный пример<\/h2>\n

Я делал интерфейс «Секьюриджа<\/u>»<\/a>, программы для мониторинга объектов пультовой охраны. В магазинах, банках, квартирах установлены сенсоры и передатчики. По городу дежурят группы быстрого реагирования — «бойцы». Оператор следит за событиями и руководит перемещением бойцов с помощью программы.<\/p>\n

В версии, которая была до меня, да и у конкурентов, были «модули»: в одном отображались сигналы, в другом — карта города с расположением бойцов, в третьем — картотека самих охраняемых объектов с поиском, в четвёртом — какой-то журнал, куда оператор должен записывать свои действия. Снова, всё «логично», но не помогает потоку данных.<\/p>\n

Здесь в идеале не нужен не только интерфейс, но и пользователь! Если где-то сработала сигнализация и это не ложная тревога, то ближайшие бойцы должны поехать туда безо всякого оператора, а если ложная, то хозяева должны договориться об удобном времени прихода техника, который будет знать все подробности сбоя и придёт чинить. Но пока что это недостижимо, нужен оператор, и только поэтому и нужен интерфейс.<\/p>\n

Интерфейс должен помочь данным о сигналах с объектов пройти через оператора и дойти до бойцов в виде инструкции или хозяев и техников в виде информации. Получается, оператор должен получить какие-то данные, что-то сделать с ними, что машина сделать не может, принять решения, и отправить данные обратно в систему. Данные системы для оператора: что за сигнал, где это, как там дела с электричеством и связью, какая там ближайшая группа быстрого реагирования, кто хозяин объекта и какой его телефон, какие датчики есть на объекте и как он выглядит на плане. Оператор вникает, что произошло, инструктирует бойцов или связывается с хозяевами и техником. Данные от оператора для системы: ложная ли была тревога, были ли выявлены неполадки, требуется ли работа техников, что сделано, устранена ли проблема.<\/p>\n

Ну и всё, исходя из этого и строим интерфейс:<\/p>\n

\n\"\"\n<\/div>\n

Нет никакой причины оператору по крупицам собирать информацию по разным модулям и потом заносить результат в ещё один модуль «журнал». Вся информация должна сразу быть перед глазами, как и кнопки записи итогов в журнал. Оператор видит всю картину и как с кем связаться; разбирается в ситуации; здесь же жмёт на итоговую кнопку.<\/p>\n

Применимость<\/h2>\n

Такой способ думать об интерфейсе подойдёт, когда речь о конвейерном, транзакционном взаимодействии. На этом сложно построить интерфейс Гугль-дока или программы 3д-моделирования, ведь там процесс работы слишком творческий, нелинейный. Но всё же всегда полезно думать не модулями и не «бизнес-сущностями», а сценарием и ролью интерфейса в нём.<\/p>\n

Ещё эти идеи где-то рядом с технозависимостью. В лекции о технозависимости мы говорим о том, что технические условия не должны влиять на интерфейс, ну а тут — что и логическое устройство чего бы то ни было, организация данных, отделов в компании в общем-то тоже не должны влиять на интерфейс.<\/p>\n", "summary": "Это черновик, который я решил опубликовать", "date_published": "2023-09-20T23:42:42+05:00", "date_modified": "2026-01-11T03:00:56+05:00", "tags": [ "метод", "пользовательский интерфейс", "сценарный подход" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/securige-ui.jpg", "_date_published_rfc2822": "Wed, 20 Sep 2023 23:42:42 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6094", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/securige-ui.jpg" ] } }, { "id": "5924", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/scenario-spacial-solution\/", "title": "Сценарное и пространственное решения в интерфейсе", "content_html": "

На интерфейсную задачу есть смысл смотреть с двух сторон. С одной стороны, нужно найти решение на уровне сценария. Как пользователь будет делать то, для чего он пришёл в интерфейс: какую последовательность шагов проходить, какие данные вводить, какие получать. С другой стороны, для любого шага нужно найти пространственное решение: как будут организованы на экране данные и элементы управления, как экран будет свёрстан.<\/p>\n

Эти вещи взаимосвязаны, но иногда стоит искусственно в своей голове их разделить. Прям представить для начала, что любая пространственная задача нипочём, и нужно понять только сам сценарий. А потом представить, что сценарий зафиксирован, и нужно сверстать шаги именно такими, какими требует сценарий.<\/p>\n

Почему это полезно: потому что иначе дизайнер может не заметить, что ухудшил сценарий только из-за того, что не смог сверстать экран. Например, не хватило места на экране — разделили процесс на два шага, хотя по смыслу это ни для чего не нужно. Неопытный дизайнер может просто даже неотрефлексировать, что он ввёл лишний шаг только из-за того, что не справился с вёрсткой. Точнее, вообще не осознать, что шаг лишний, ведь сложность вёрстки сама по себе выглядела естественным основанием для введения ещё одного шага.<\/p>\n

При этом я не говорю, что так делать никогда нельзя. Просто важно хотя бы отдавать себе отчёт в том, что ты решил пространственную задачу сценарно (то есть как бы не решил, а просто ушёл от неё). Тогда, например, если ты сделал такое для тесного телефона, то, возможно, в полноэкранной версии ты не будешь это повторять, а вернёшь вариант в один шаг.<\/p>\n", "summary": "На интерфейсную задачу есть смысл смотреть с двух сторон. С одной стороны, нужно найти решение на уровне сценария", "date_published": "2022-12-12T23:47:41+05:00", "date_modified": "2023-09-18T15:39:22+05:00", "tags": [ "метод", "пользовательский интерфейс" ], "_date_published_rfc2822": "Mon, 12 Dec 2022 23:47:41 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "5924", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "5677", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/ui-course-frag-40\/", "title": "На интерфейсном курсе: сценка со звонком в пиццерию", "content_html": "

Чтобы довести интерфейс до ума и понять, чего в нём не хватает, разыгрываем сценку со звонком в пиццерию. Разговор с «менеджером пиццерии» (на самом деле участницей курса) помогает понять, чего не хватает на экране. 4 минутки:<\/p>\n

\n