Цифровой журнал «Компьютерра» № 29 - Коллектив Авторов

- Критерии важности, основаны на способе абстрагирования и фильтрации информации (что в современном интерфейсе выражается сортировкой и фильтрацией).

* Смысл

- Семантика должна быть явной и совместимой в приложениях (для чего и нужны идентификаторы). Информация должна быть упорядочена в виде структур, таких как списки, таблицы, графы, иерархии, использование отношений 1:1, 1:N, M:1, N:M (которые соответствуют разным структурам) и использовать объекты, действия, и отношения различного рода (пространственных, временных, возможность, планирование, цель, и т.п.), которые используются в естественном языке, но не всегда явно в мире компьютеров.

- Ассоциация информации с аттрибутами, категориями и т.п. (например, как это сейчас делается при помощи тегов и ключевых слов) заменяется на связность с идентификаторами, которые, за кулисами, могут быть связаны с другими идентификаторами (т.е. если вы связываете фотографию с идентификатором «отпуск», то не нужно ее связывать с идентификатором «отдых», т.к. эта трансляция уже будет сделана неявно). Причем, эта связь должна подразумевать только саму себя (т.е. «фотографии из отпуска» означает, что фотографии относятся только к отпуску, а не документы, которые упоминают фотографии и/или отпуск).

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

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

- Любой предмет является статическим и динамическим одновременно и только абстракция может склонить чашу весов в ту или иную сторону. Этот аспект может быть явно обозначен для любого идентификатора (например, «цены на модель А» — это может быть запросом к сайту дилера, возвращающий текущие цены, но также и зафиксированными данными, полученными в определенный момент времени, который тоже должен быть зафиксирован; при этом обе формы могут быть связаны между собой, чтобы было возможно их обновить, а также при желании получать нотификации об обновлении; для документа подобный дуализм может быть выражен в его композитной форме, которая развивается во времени, и версиях, которые фиксируют определенную конфигурацию документа; сама версионность должна быть одним из базовых свойств информационной «оболочки», описанной выше, т.к. версии предоставляют срезы информации во времени).

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

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

* Интерфейс

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

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

- Информация должна быть доступна при помощи смысловых идентификаторов (например, вместо файла 1234.sub, информация будет видна как «субтитры фильма А»; причем, «субтитры» и «фильм А» — это два связанных идентификатора, которые возможно будет переиспользовать для дальнейшего поиска/фильтрации).

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

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

- Опции/параметры должны быть связаны с функциональностью (например, если опции оказывают влияние на поведение функции, то при запуске этой функции мы должны видеть какие именно опции оказывают влияние).

- Любой элемент интерфейса должен быть представлен в следующих аспектах: (1) декларативном (объявление и/или идентификатор), (2) императивном (связанный с действием или же с изменениями, например, для текстового поля), (3) ссылочном, (4) вопросительном. Данные аспекты помогают понять, как данный элемент можно (1) использовать и переиспользовать, (2) менять и изменять при его помощи другие элементы, (3) связан с другими элементами, (4) может быть связан с другими элементами, вследствие недостаточных сведениях о связях или необходимости уточнения.

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

- Безопасность, может быть дополнена (не считая уже существующих средств) контекстовой фильтрацией: т.е. приложение должно декларировать в каком контексте оно собирается работать.

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