#систематика #инфоарх /// Архитектура
Архитектура описывает систему в части самых важных решений:
- Какие модули за какие функции будут отвечать.
- Какими интерфейсами будут связаны эти модули.
- Как и чем будут обмениваться эти модули через интерфесы — какие сервисы будут "течь" через порты, воплощенные интерфейсами.
Можно сказать, что модули есть существительные, а функции (выполняемые модулями) есть глаголы, так как функции есть действия, дающие на выходе результат и как следствие сервис.
Архитектура — это всегда прозрачный ящик!
Необходимо следить за связностью модулей — чем меньше связей, интерфейсов, тем меньше шансов на неотслежываемые соеднения (они — источник ошибок) и тем проще управлять модулями в составе системы.
Архитектура есть всё самое важное про функции, всё самое важное про модули и всё самое важное про размещение, а также всё самое важное в других рассмотрениях системы.
Архитектура может быть и у процесса, а следовательно — архитектура может быть у проекта.
____
#архитектура #интерфейс #модуль #прозрачный_ящик #проект
Архитектура описывает систему в части самых важных решений:
- Какие модули за какие функции будут отвечать.
- Какими интерфейсами будут связаны эти модули.
- Как и чем будут обмениваться эти модули через интерфесы — какие сервисы будут "течь" через порты, воплощенные интерфейсами.
Можно сказать, что модули есть существительные, а функции (выполняемые модулями) есть глаголы, так как функции есть действия, дающие на выходе результат и как следствие сервис.
Архитектура — это всегда прозрачный ящик!
Необходимо следить за связностью модулей — чем меньше связей, интерфейсов, тем меньше шансов на неотслежываемые соеднения (они — источник ошибок) и тем проще управлять модулями в составе системы.
Архитектура есть всё самое важное про функции, всё самое важное про модули и всё самое важное про размещение, а также всё самое важное в других рассмотрениях системы.
Архитектура может быть и у процесса, а следовательно — архитектура может быть у проекта.
____
#архитектура #интерфейс #модуль #прозрачный_ящик #проект
#систематика /// Порт, интерфейс, соединение
Порт — это канал обмена функциональностью между функциональными частями в системе. Также сама система имеет порт, через который она отдаёт свой сервис наружу в надсистему. Порты не имеют физического воплощения, физически порты воплощены модулями.
Интерфейс — это обмен между модулями. Сам по себе интерфейс не имеет физического воплощения, он воплощается через интерфейсные модули. При этом интерфейсный модуль имеет не один интерфейс: помимо целевого интерфейса для подключения надмодуля (частью которого является интерфейсный модуль) к другому надмодулю есть также интерфейс между интерфейсным модулем и смежным модулем в рамках системы.
Интерфейс и модули ничего не знают про то, что именно они будут передавать: потоки каких сервисов и данных они будут обеспечивать.
Соединения — это физические соединения между модулями при размещении. Например, винтовое крепление, или физическая сцепка USB-модулей.
Когда рассматриваются два (или более) модуля, которые взаимодействуют между собой, необходимо сразу же рассматривать их интерфейсы — то есть каким образом модули будут взаимодействовать между собой, как физически будут осуществлён обмен между портами.
Есть несколько вариантов связи модулей между собой:
- унификация — использование общих стандартов в индустрии/отрасли (220 вольт, USB, XML, 2НДФЛ) — просто и дешево, лучший вариант.
- интеграция — разработка этих модулей с учетом того как они будут связаны, то есть проектирование модулей и их интерфейсов для взаимодействия — редкий кейс, дорого, сложно, "закрытая" разработка.
- федерирование — применение "прослоек" и адаптеров в случае отсутствия стандартов, несовпадения интерфейсов — довольно частый случай
Когда реализуют стандарт интерфейса и портов, содержащих / предоставляющих / воплощающих этот интерфейс — этого стандарта стоит придерживаться маскимально строго и полно (в отличие от стандарта практики, при реализации которого стоит брать только самое необходимое).
____
#порт #интерфейс #соединение #унификаци #федерирование #интеграция #модуль
Порт — это канал обмена функциональностью между функциональными частями в системе. Также сама система имеет порт, через который она отдаёт свой сервис наружу в надсистему. Порты не имеют физического воплощения, физически порты воплощены модулями.
Интерфейс — это обмен между модулями. Сам по себе интерфейс не имеет физического воплощения, он воплощается через интерфейсные модули. При этом интерфейсный модуль имеет не один интерфейс: помимо целевого интерфейса для подключения надмодуля (частью которого является интерфейсный модуль) к другому надмодулю есть также интерфейс между интерфейсным модулем и смежным модулем в рамках системы.
Интерфейс и модули ничего не знают про то, что именно они будут передавать: потоки каких сервисов и данных они будут обеспечивать.
Соединения — это физические соединения между модулями при размещении. Например, винтовое крепление, или физическая сцепка USB-модулей.
Когда рассматриваются два (или более) модуля, которые взаимодействуют между собой, необходимо сразу же рассматривать их интерфейсы — то есть каким образом модули будут взаимодействовать между собой, как физически будут осуществлён обмен между портами.
Есть несколько вариантов связи модулей между собой:
- унификация — использование общих стандартов в индустрии/отрасли (220 вольт, USB, XML, 2НДФЛ) — просто и дешево, лучший вариант.
- интеграция — разработка этих модулей с учетом того как они будут связаны, то есть проектирование модулей и их интерфейсов для взаимодействия — редкий кейс, дорого, сложно, "закрытая" разработка.
- федерирование — применение "прослоек" и адаптеров в случае отсутствия стандартов, несовпадения интерфейсов — довольно частый случай
Когда реализуют стандарт интерфейса и портов, содержащих / предоставляющих / воплощающих этот интерфейс — этого стандарта стоит придерживаться маскимально строго и полно (в отличие от стандарта практики, при реализации которого стоит брать только самое необходимое).
____
#порт #интерфейс #соединение #унификаци #федерирование #интеграция #модуль
#инфоарх /// Информационная архитектура 2021
Устанавливаю в очередной раз собственное понимание информационной архитектуры (ИА).
Пререквизит:
1) Определение ИА от 22 марта 2021: "информационная архитектура — самое важное про интерпретацию системы агентом".
2) Критика ИА как дисциплины, серия 1 (2003), серия 2 (2004) — "ИА не есть дисциплина, а лишь новый должностной/профессиональный лэйбл"; ИА не формирует новых сущностей в проектировании, но является сборников таковых из других дисциплин.
3) Мысль о том, что ИА есть всегда, независимо от того, планировалось ли её разработать/создать/настроить. Она есть, хорошая или плохая.
Я готов согласиться, что ИА не является дисциплиной. Действительно, все практики, выполняемые для проработки успешной интерпретации (собственно, для проработки ИА) — практики проектирования архитектуры данных, интерфейса пользователя, семантических настроек системы. Если взять одну из "раскадровок" проработки ИА, то ровно это мы и получим:
- онтология и семантика — дисциплины логики, онтологии, лингвистики/стилистики, etc;
- структура, таксономия, классификация — дисциплины систематики;
- оркестровка, дирижирование, хореография — use-case-ориентированные дисциплины: проектирование ПО и системная инженерия.
Также стоит упомянуть про широчайший разброс определения ИА от тех, кто этой ИА занимается. Посмотрите любой WIAD — множество докладов начинаются с определения что есть информационная архитектура, и все эти определения разные, вольно трактуемые. Цельного определения нет, и об этом прямо пишут.
При этом я не готов отрицать наличие ИА в системах. И тем более не готов отрицать её важность. Повторю свою мысль снова: ИА есть всегда, хорошая или плохая. Важно то внимание, которое ей уделяется.
Вся эта ситуация похожа на свистопляску вокруг UX, который есть следствие, как и ИА. Он есть всегда, хороший или плохой, вопрос в том кто его прорабатывает и с помощью каких практик. Если ты работаешь над UI для улучшения UX, то ты UI-дизайнер. Если ты работаешь над сценариями взаимодействия с продуктом/сервисом, то ты product/service-дизайнер (хотя справедливости ради в любом случае, даже если у продукта/сервиса множество каналов, взаимодействие-то через интерфейс, то есть все эти приставки product/service — всё равно про UI).
Продавец на рынке, раскладывающий товар по группам, позволяющий выбирать самостоятельно экземпляры товара, предлагающий упаковку — тоже UX-дизайнер, влияет на опыт приобретения овощей-фруктов-etc. Результатом работы всякого дизайнера в любом случае будет опыт использования, хороший или плохой.
И в любом случае у продукта/сервиса/системы будет как-то организована информация, упакована в какую-то архитектуру — а значит и ИА в любом случае будет. И она влияет на UX, она его часть (здесь должны быть ссылка про affordance, но она у меня пока только в заготовке, будет нескоро).
Итого:
- Информационная архитектура есть часть UX, тот опыт "понятности"/"интерпретируемости" системы (тянет написать "квалиа интерпретации").
- Нет цельной практики информационной архитектуры, однако есть ряд практик, позволяющих качественно проработать ИА в создаваемом продукте; эти практики очень близки к практикам проектирования систем. Хорошая ИА есть результат выполнения практик проектирования.
ИА не есть дисциплина, но ИА зависит от выполнения практик по дисциплинам проектирования.
__
#инфоарх #информационная_архитектура #дисциплина #практика #интерфейс #ui #ux
Устанавливаю в очередной раз собственное понимание информационной архитектуры (ИА).
Пререквизит:
1) Определение ИА от 22 марта 2021: "информационная архитектура — самое важное про интерпретацию системы агентом".
2) Критика ИА как дисциплины, серия 1 (2003), серия 2 (2004) — "ИА не есть дисциплина, а лишь новый должностной/профессиональный лэйбл"; ИА не формирует новых сущностей в проектировании, но является сборников таковых из других дисциплин.
3) Мысль о том, что ИА есть всегда, независимо от того, планировалось ли её разработать/создать/настроить. Она есть, хорошая или плохая.
Я готов согласиться, что ИА не является дисциплиной. Действительно, все практики, выполняемые для проработки успешной интерпретации (собственно, для проработки ИА) — практики проектирования архитектуры данных, интерфейса пользователя, семантических настроек системы. Если взять одну из "раскадровок" проработки ИА, то ровно это мы и получим:
- онтология и семантика — дисциплины логики, онтологии, лингвистики/стилистики, etc;
- структура, таксономия, классификация — дисциплины систематики;
- оркестровка, дирижирование, хореография — use-case-ориентированные дисциплины: проектирование ПО и системная инженерия.
Также стоит упомянуть про широчайший разброс определения ИА от тех, кто этой ИА занимается. Посмотрите любой WIAD — множество докладов начинаются с определения что есть информационная архитектура, и все эти определения разные, вольно трактуемые. Цельного определения нет, и об этом прямо пишут.
При этом я не готов отрицать наличие ИА в системах. И тем более не готов отрицать её важность. Повторю свою мысль снова: ИА есть всегда, хорошая или плохая. Важно то внимание, которое ей уделяется.
Вся эта ситуация похожа на свистопляску вокруг UX, который есть следствие, как и ИА. Он есть всегда, хороший или плохой, вопрос в том кто его прорабатывает и с помощью каких практик. Если ты работаешь над UI для улучшения UX, то ты UI-дизайнер. Если ты работаешь над сценариями взаимодействия с продуктом/сервисом, то ты product/service-дизайнер (хотя справедливости ради в любом случае, даже если у продукта/сервиса множество каналов, взаимодействие-то через интерфейс, то есть все эти приставки product/service — всё равно про UI).
Продавец на рынке, раскладывающий товар по группам, позволяющий выбирать самостоятельно экземпляры товара, предлагающий упаковку — тоже UX-дизайнер, влияет на опыт приобретения овощей-фруктов-etc. Результатом работы всякого дизайнера в любом случае будет опыт использования, хороший или плохой.
И в любом случае у продукта/сервиса/системы будет как-то организована информация, упакована в какую-то архитектуру — а значит и ИА в любом случае будет. И она влияет на UX, она его часть (здесь должны быть ссылка про affordance, но она у меня пока только в заготовке, будет нескоро).
Итого:
- Информационная архитектура есть часть UX, тот опыт "понятности"/"интерпретируемости" системы (тянет написать "квалиа интерпретации").
- Нет цельной практики информационной архитектуры, однако есть ряд практик, позволяющих качественно проработать ИА в создаваемом продукте; эти практики очень близки к практикам проектирования систем. Хорошая ИА есть результат выполнения практик проектирования.
ИА не есть дисциплина, но ИА зависит от выполнения практик по дисциплинам проектирования.
__
#инфоарх #информационная_архитектура #дисциплина #практика #интерфейс #ui #ux
#инфоарх /// Интерпретируемость
Пользователь "общается" с системой для достижения цели, используя интерфейс. Интерфейсом является всё, с чем пользователь взаимодействует:
- адресный контент, который он ищет, с которым работает;
- навигация, по которой он добирается до этого адресного контента.
(а все остальное можно свести к этим двум)
Чтобы достигнуть цели, пользователь "читает" интерфейс, а в процессе чтения интерпретирует его в концепты, которыми мыслит.
Верно прочитанный интерфейс — понятый таким образом, чтобы достигнуть цели кратчайшим путем.
Та степень, в которой интерфейс верно понимается — его интерпретируемость.
Информационная архитетктура служит для увеличения интерпретируемости.
Интерпретируемость наряду с находимостью (findability) и доступностью (accessibility) является частью общего понятия эргономики (usability).
Интерпретируемость складывается не только из семантики (связь обозначения контента и самого контента, связь ярлыка и элемента за этим ярлыком), но также из считывания контекста, возможности для пользователя быстро прочитать конструкцию:
- я нахожусь в___,
- для того, чтобы___
- я попал сюда из___,
- и дальше я перейду к___.
Эта конструкция объединяет свойства находимости и назначения, включенные в "прочтение", и дающие в результате интерпретируемость.
__
#информационная_архитектура #интерфейс #навигация
Пользователь "общается" с системой для достижения цели, используя интерфейс. Интерфейсом является всё, с чем пользователь взаимодействует:
- адресный контент, который он ищет, с которым работает;
- навигация, по которой он добирается до этого адресного контента.
(а все остальное можно свести к этим двум)
Чтобы достигнуть цели, пользователь "читает" интерфейс, а в процессе чтения интерпретирует его в концепты, которыми мыслит.
Верно прочитанный интерфейс — понятый таким образом, чтобы достигнуть цели кратчайшим путем.
Та степень, в которой интерфейс верно понимается — его интерпретируемость.
Информационная архитетктура служит для увеличения интерпретируемости.
Интерпретируемость наряду с находимостью (findability) и доступностью (accessibility) является частью общего понятия эргономики (usability).
Интерпретируемость складывается не только из семантики (связь обозначения контента и самого контента, связь ярлыка и элемента за этим ярлыком), но также из считывания контекста, возможности для пользователя быстро прочитать конструкцию:
- я нахожусь в___,
- для того, чтобы___
- я попал сюда из___,
- и дальше я перейду к___.
Эта конструкция объединяет свойства находимости и назначения, включенные в "прочтение", и дающие в результате интерпретируемость.
__
#информационная_архитектура #интерфейс #навигация
#дизайн /// Требования в UI-задачах
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
#систематика /// Прогресс и инновации
Прогресс в технологиях случается непредсказуемо как следствие скрещения новых технологий (в составе результирующей), которые сами по себе начинают дешеветь, и становятся массово доступны.
Можно выделить 4 стадии:
- Стандартизация — технология описана для общего использования.
- Удобство использования / юзабилити — разработка доступного массам интерфейса, её могут использовать не только специалисты, а широкая аудитория.
- Распространение, переход в массовое потрбеление.
- Встраивание в инфраструктуру — когда новая технология уже везде, кажется и считается повсеместной, привычной, обыденной.
С появлением новых технологий меняются работы, которые выполняют по практикам/сервисам, и как результат появляются новые рынки.
Пример: сервис перевозки остался, но обеспечивающая система и связанные с ней работы поменялись; ранее это были диспетчеры и таксопарки, сейчас же это приложения и практика подбора машины с водителем (агрегатор такси).
Еще пример: сервис хранения и передачи данных остался, но ранее это были, например, CD-диски с обеспечивающей системой в виде компьютера и дисковода, теперь же это хранение на удаленном дата-центре с обеспечениев в виде сайта/приложения с доступом к этим данным в облаке.
___
#Технология #прогресс #интерфейс
[[Практика, дисциплина, технология]] — технология есть инструмент, позволяющая выполнять практику или оказывать сервис, при этом развитие технологий меняет работы в системах обеспечения, порождая новые рынки.
Прогресс в технологиях случается непредсказуемо как следствие скрещения новых технологий (в составе результирующей), которые сами по себе начинают дешеветь, и становятся массово доступны.
Можно выделить 4 стадии:
- Стандартизация — технология описана для общего использования.
- Удобство использования / юзабилити — разработка доступного массам интерфейса, её могут использовать не только специалисты, а широкая аудитория.
- Распространение, переход в массовое потрбеление.
- Встраивание в инфраструктуру — когда новая технология уже везде, кажется и считается повсеместной, привычной, обыденной.
С появлением новых технологий меняются работы, которые выполняют по практикам/сервисам, и как результат появляются новые рынки.
Пример: сервис перевозки остался, но обеспечивающая система и связанные с ней работы поменялись; ранее это были диспетчеры и таксопарки, сейчас же это приложения и практика подбора машины с водителем (агрегатор такси).
Еще пример: сервис хранения и передачи данных остался, но ранее это были, например, CD-диски с обеспечивающей системой в виде компьютера и дисковода, теперь же это хранение на удаленном дата-центре с обеспечениев в виде сайта/приложения с доступом к этим данным в облаке.
___
#Технология #прогресс #интерфейс
[[Практика, дисциплина, технология]] — технология есть инструмент, позволяющая выполнять практику или оказывать сервис, при этом развитие технологий меняет работы в системах обеспечения, порождая новые рынки.