:: urbansheep (urbansheep) wrote,
:: urbansheep
urbansheep

Что (и зачем) нужно для поддержки множественных персон в инфосистемах

Краткое содержание

[0.1]

Нужно ли вам завести себе виртуала? Как удобнее работать с несколькими личностями одновременно? Чего не хватает для этого в технологии? Примерно на такие вопросы я и пытаюсь здесь ответить. То, что вначале развивается как чересчур „техническое“ обсуждение, дальше (примерно с третьего пункта) превращается в обсуждение простых вопросов:

[0.2]

  • Как сделать организацию и обработку информации проще?
  • Какие средства для этого лучше подойдут?
  • Чего требовать от будущего?

[0.3]

Виртуалы здесь называются персонами, их владелец — пользователь, или автор. Разные роли виртуалов, как ни странно, называются ролями. Во всём остальном можно разобраться по ходу разговора. Вы всё ещё здесь? Тогда начнём.


Фото: Miss Aniela

Сколько нужно попугаев на одного удава? Пользователи и персоны

[1.1]

Погружённый в проектирование некой системы управления данными, moedusa спрашивает (перефразирую):

[1.2]

  • Может ли один и тот же пользователь обладать и представлять несколько персон в рамках одной и той же системы?
  • А что делать с ролями персон?

[1.3]

Короткий ответ: в современной системе пользователю достаточно одной персоны, которой может быть назначено несколько ролей см.[1]. Рассуждение о том, почему в будущем современной системе этого станет недостаточно (и чем, после превращения иамс в многофункционального бегемота, нам придётся её дополнять) — ниже.

Лестница описаний

[2.1]

Если упрощённо представить существующую в компьютерных инфосистемах иерархию, то она будет выглядеть примерно так:

  • Пользователь — верхний уровень. Индивидуальный субъект, который садится за терминал и выполняет определённые действия, решает свои задачи.

    • Персона (identity) — аватара пользователя, от имени которой он работает в настоящий момент.

      • Роль — унифицированный набор характеристик (права доступа, принадлежность к сообществу, исполняемые функции) аватары в системе

[2.2]

Почти в любой современной информационной системе иерархия строится, начиная со второго пункта — подразумевая, что у пользователя только одна „личность“, и больше ему не нужно. Это похоже на фортепьяно — тот же единый голос, один терминал, один исполнитель. Для абсолютного большинства задач этого достаточно, но по мере развития „ареал обитания“ инфосистем неизбежно будет расширяться, включая в себя не только то, что пользователь делает в самой системе, но и то, что происходит за её пределами — семантическая сеть как раз для этого и задумывалась.

[2.3]

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

Достоинства одновременного использования нескольких персон

[a.1]

Каждая персона — это совершенно иной человек, который имеет свою, пусть и искусственно созданную, историю, прошлое, настоящее, а часто — и будущее, в котором реальный мир играет лишь роль „голосующего“ за какие-то варианты дальнейшего развития истории.

[a.2]

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

[a.3]

К другим достоинствам персон можно отнести:

  • возможность использования в качестве прототипа существующего человека — с действиями и реакциями реплики на основе опыта прототипа
  • большую эффективность диалогов за счёт добавления в него персон-„прирождённых фасилитаторов“

Насущная потребность и её удовлетворение

[3.1]

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

[3.2]

В нашем же случае вместо актёра сам автор как бы разделяется на отдельные части, независимые друг от друга, подобно волшебнику-магрибинцу из „Волшебной лампы Аладдина“, при этом оставаясь единым в физическом смысле. Эти независимые части могут работать друг с другом, а могут исследовать разные сферы и никогда не пересекаться, но сам автор всегда является ими всеми или каждой из них в отдельности. И, в отличие от одного актёра, персоны могут действовать почти одновременно.

[3.4]

Лирическое о.: В настоящее время, и в течение большей части нашего прошлого, разделить персону и автора не было никакой возможности и они являлись единым целым в физическом мире. Поэтому увеличение количества персон и появление новых аватар на органическом и неосознанном уровне рассматривается современной психиатрией (в общем) как серьёзная девиация, с единственным исключением в виде игр и театра.

[3.5]

Что же делать с сознательно созданными и тщательно смоделированными альтернативными автарами, современная психиатрия пока (в общем) не определилась, и до тех пор, пока явного вреда рассудку эта практика не наносит, её предпочитают считать также „игрой“ — как способ удовлетворения своего любопытства или решения технических или психологических проблем (здесь в игру вступает психологическое многоголосие, где каждый голос предлагает своё толкование).

Колосс на глиняных ногах

[4.1]

Итак, инфосистема. У одного автора может быть несколько персон. Они независимы и не связаны друг с другом. Работа идёт, количество персон (как отработанных, так и просто вовлечённых в игру) растёт, . и в какой-то момент техническая сложность управления многочисленными персонами переходит все разумные границы. Работа останавливается, либо прерывается ровно до того момента, пока автор не уравновесит количество персон и свои возможности. Но действительно ли это автор не рассчитал? Если посмотреть то чаще всего сложные и долгие проекты, которые в основе своей имеют „цифровые“ средства разработки и производства, останавливаются по следующим тривиальным причинам:

  • Однозадачность (single-tasking)

    [4.2]

    Почти все системы сейчас предназначены только для одного пользователя, который работает в данный момент, они не позволяют работать с одного рабочего места нескольким персонам сразу. Первые шаги для этого делаются в операционных системах, где смена текущего пользователя может происходить быстро и с сохранением текущих настроек (в разной форме это есть в *nix или в WinXP). Для другого пользователя просто выделяется отдельное рабочее пространство с его собственным контекстом, где он может отработать и после этого „вернуть“ контроль предшественнику.

    [4.3]

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

    [4.4]

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

    [4.5]

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

  • Изолированные контексты (non-shared contexts)

    [4.6]

    Изоляция контекстов, которая обязательна для разных людей (именно такая изоляция обеспечивает ощущение „своего пространства“ и того, что называется „privacy“), очень мешает при одновременной работе нескольких персон (а также коллектива людей, как в случае с парным программированием или проектированием, но это тема другого разговора) — переплетать разные знания и контексты этих персон приходится очень аккуратно, практически всегда вручную, особенно когда идёт параллельная работа, а не просто создаётся групповое произведение.

    [4.7]

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

    [4.8]

    Лирическое о.: технологии пакетной обработки известны очень давно, и практика эта уходит корнями в тайм-менеджмент и распределение машинного времени, так что успешные решения разработаны и применяются, хотя на перестройку работы и уходят некоторые ресурсы. Зато после первичной реорганизации и вынужденного упорядочивания процесса работа идёт гораздо легче.

    [4.9]

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

    [4.10]

    В плане обозримости и удобства манипулирования идеально подходят большие стены, полы и столы, где можно раскладывать целые линии, кучки и группы объектов, которые могут взаимодействовать друг с другом. Если в эту же пространственную систему включить ambient-эффект (пример — интерактивные карты театра военных действий, где сразу отражается текущее состояние в целом и в то же время легко можно изучить детали и сведения с любого меньшего участка), то управление и осмысление данных упрощается многократно, а освободившиеся ресурсы можно пустить на более творческую, нежели вынужденная организация элементов, деятельность.

    [4.11]

    Ещё одним достоинством больших пространств является возможность окинуть взглядом все активные контексты и лёгкость ориентации в пространстве. В сочетании с „зонированием“ (раскладывание по кучкам) это и помогает разделять наши контексты, не давая им превратиться в хаос.

  • Восстановление контекстов (context overhead)

    [4.12]

    После переключения или при переходе от одной персоны к другой неизбежно требуется восстанавливать то состояние, которое было на момент выхода. Иногда требуется и изменять это состояние „с течением времени“ — так как у нас многозадачная вселенная. Пока что восстановление контекстов (особенно после сбоев) встречается лишь в отдельных приложениях, медленно распространяясь — начиная с „резервных копий“, журналирующих файловых систем и журналирующих операционных систем см.[2]. В современных системах примером такого поведения можно считать режим „усыпления“ и последующего продолжения работы с того же места в Win2K/WinXP и уже упоминавшуюся схему работы нескольких пользователей, когда одновременно может быть активно несколько сессий, но на время активной работы с одной из них остальные приостанавливаются.

    [4.13]

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

    [4.14]

    Пока всего этого нет, сохранение и восстановление контекстов (вплоть до наборов ссылок, настроений, диалогов) производится либо вручную, либо примитивными (психо-)техническими средствами (см.[3]) — они служат хорошей тренировкой для памяти и для сознания, но в моменты, когда нужно обрабатывать постоянно значительные массивы данных, информационная перегрузка начинает отключать целые сегменты контекстов, и те просто выпадают из фокуса.

Лучше запоминается то, что больнее ударило

[5.1]

Как ни очевидны эти сложности, в ближайшее время быстрое решение (на нашем уровне „простых решений с открытым кодом“) им не светит в силу специфичности самой темы множественных персон — слишком мало распространён сам метод и слишком много белых пятен во всём, что связано с проектированием не на уровне функций или задач, а на уровне целых контекстов. Но решения будут.

[5.2]

Векторов здесь два — практика параллельной работа нескольких людей, где требуется совмещение контекстов без их перемешивания, уже набирает силу (тот же редактор „Гидра“ (см.[5]) является хорошим примером), а значит, через три-четыре редакции средства для „контекстного сопровождения“ появятся в интегрированных средах для разработки (IDE) вроде MS Visual Studio. „Большие“ компании будут только рады, если найдётся новое средство для резкого увеличения эффективности их разработчиков, кто-то даже сейчас пытается разрабатывать подобные решения для эффективной работы с контекстами в рамках управления знаниями, не понимая, впрочем, до конца, в какую сторону нужно двигаться (например, см.[8]).

[5.3]

С противоположного конца двигается open-source-сообщество. Если идея будет достаточно популяризована, то мелкие группы свободных разработчиков с успехом повторят и разовьют успех Гидры в других приложениях, всячески дополняя идею параллельной работы поддержкой контекстов (см.[6]), а уж мы сумеем поддержку контекстов превратить в поддержку контекстов для множественных персон.

[5.4]

Пока же мне остаётся использовать все свои скромные возможности для того, чтобы понять, что нужно от идеально-практической системы, собрать очередные пол-дюжины прототипов, и дальше оттачивать навыки работы с бумагой в трёхмерном пространстве, без которых создание длинных „многоличностных“ текстов становится похожим на поиски Святого Грааля. В конце концов, это то, что поколения писателей хорошо отработали за последние несколько веков.

[5.5]

К счастью, несмотря на всю кажущуюся сложность вопроса поддержки множественных персон, значительного упрощения работы можно добиться буквально „наколенными“ решениями (см.[9]), а так как мейнстрим меня интересует только в плане экономии моих же сил, чтобы не изобретать велосипед по второму разу, то актуальным остаётся жизненный принцип „если вам это не нужно — это ваши проблемы“. А я пока продолжаю делать то, что мне поможет — и к третьей версии, я думаю, IAMS обзаведётся системой отслеживания параллельных контекстов для каждой из множества персон, принадлежащих каждому из авторов.

Ссылки по теме

  1. [6.1]

    Привилегированные группы пользователей - терминология и базовые понятия: Обсуждение вопроса назначения ролей, организации доступа и разграничения прав для пользователей на сервере xpoint выводит хорошую последовательность „группирования“ объектов, где на каждом из концов единичный объект, а на пересечении — группа этих объектов: пользователь — роли пользователей — группы документов — документ.

  2. [6.2]

    „В идеале механизм undo должен быть частью системы и привязан к "сеансу", то есть к контексту, в котором протекает всё взаимодействие пользователя со средой. Если механизм сеансов реализует восстановление сеанса после отключения питания или разрыва сетевого соединения, то сеансное undo оборачивается ничем иным, как тотальным версионным контролем -- штукой, о которой большевики пиздят уже двадцать лет!“ — в рассуждении о настраиваемых интерфейсах @ behrk

  3. [6.3]

    Свёртывание данных для хранения в памяти // человеческий подход @ urbansheep

  4. [6.4]

    Неуёмная страсть ИАрхитекторов к виртуализации самоЁ себя @ moedusa

  5. [6.5]

    Hydra — Realtime Multi-threaded Conversations @ urbansheep

  6. [6.6]

    Как вы организуете свои данные? @ behrk

  7. [6.7]

    The Remembrance Agent @ urbansheep

  8. [6.8]

    LightOntos

  9. [6.9]

    Решения для небольших солнечных систем @ urbansheep




Subscribe
  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 16 comments