Здравствуйте, Real 3L0, Вы писали:

R3>Т.е. под эксплорером подразумеваем комбинацию коммандной строки + то, что он предлагает?
Ну да. Даже если спрятать cmd.exe, у нас по-прежнему остаётся Win+R.

S>>Тогда вам надо сначала почитать книги, к примеру, Тео Манделла (критически) и Якоба Нильсена (с уважением).
R3>Ок, попробую почитать. Хотя Тео Манделла не нашёл.
http://www.proklondike.com/books/usability/mandel_gui_development.html
Тео — собственно, основной пропонент "объектно-ориентированного UI", отвечавший за разработку UX в OS/2.
Значительная часть того, что вы видите в Windows 95 — Windows 7 основана на его идеях.
Важно читать его критически — проблемы интерфейса, которые он решал, сейчас в значительной мере устарели. И появились новые проблемы, про которые Тео ничего не знал, поэтому его решения во многом неадекватны.

R3>Действие — это, по сути, аналог нажатия на кнопку "ОК" в форме десктоп интерфейса. В зависимости от существующих на форме контролов (параметров), это нажатие выполнит некоторую функцию.
В таком случае, дДействие — это кортеж из значений параметров и идентификатора кнопки.

R3>Вот этого я и не могу понять. (Гы! Я всё забыл — определение изоморфизма смотрел в вики.)
R3>Если объект — это число, а действие — операция сложения, то где тут изоморфизм? (Я правильно прочитал изоморфизм?)
Число — это объект {2}. Точка на плоскости — это объект {1, 2}. Действие "сложить 2 и 2" — это объект {+, 2, 2}.

Можно наоборот — представить все объекты в виде композиции действий.

Здравствуйте, Real 3L0, Вы писали:
R3>В названии темы — любые. А другой стороны я не понял, какие ещё бывают запросы, кроме как получить данные, изменить и удалить?
Ок, характерные примеры запросов в реальных информационных системах:
1. Вывести список вариантов авиаперелёта из Новосибирска в Мехико и обратно, прилёт не позже 10:00 утра понедельника по местному, отлёт не раньше 20:00 пятницы по местному, отсортированных по возрастанию стоимости.
2. Перевести 600 рублей со счёта 4010.............22 на оплату мобильного номера +7 9........5
3. Показать 10 топиков форума с максимальной активностью за последние 48 часов

Несмотря на то, что каждый из них можно выразить в терминах запросов "получить список ID всех объектов типа А" + "получить детали объекта по его ID" + "сохранить изменения в объект по его ID", эффективность такой реализации будет сосать.

Здравствуйте, Real 3L0, Вы писали:

R3>Пришёл к следующим мыслям...
Давно пора было прийти к мыслям, что хранение зависит от тех запросов, которые ты собрался делать.
Перед тем, как описывать хранение — опиши какие запросы будут поступать к твоей системе.

Здравствуйте, Real 3L0, Вы писали:

R3>Дело в том, что у меня проблема не в реализации, а в постановке задачи, в аналитике.
Ну так это оттого, что у вас постановки нет. Задача "вычислять неизвестно что неизвестно как" имеет много классических решений. Например — машина Тьюринга.
Если вы хотите построить более удобное решение, то придётся сузить задачу.
R3>И в добавок хотелось бы понять, как это может выглядеть интерфейсно.
Сначала надо понять, что такое "это". Вы сейчас пытаетесь уловить сходство, а уж потом рисовать портрет (с).

Здравствуйте, Sinclair, Вы писали:

S>На всякий случай поясню, что "всякие Siri" начинались не с "давайте прикрутим голосовое управление к чему угодно", а со списка сценариев типа "узнать текущую погоду", "добавить событие в календарь", "ответить на сообщение" и прочих.
Ну вообще-то, голосовое управление в своё время очень неплохо прикручивали к Emacs'у. Там можно было чем угодно управлять, и оно работало — с помощью марковских моделей строилась наиболее подходящая цепочка действий.

S>Если хочется полезть на рынок Siri, то нужно иметь как минимум полсотни, а лучше сто, очень конкретных сценариев с внятными критериями успеха и удобства.
S>Иначе — не взлетит.
У Сири их порядка 500. Но они все очень простые, в принципе, это вообще не очень сложный проект по нынешним меркам. Я про конкретно распознавание голоса, в Сири есть ещё много интересных технических решений для улучшения experience'а (типа Multipath TCP сразу через оба радиоканала).

Здравствуйте, Cyberax, Вы писали:
C>Для эксперимента это сообщение я пишу с помощью распознания голоса. Как не странно но для русского языка это работает очень даже неплохо, даже запятые ставятся в нужных местах. А вот с английским всё плохо, видимо для английского языка простые технологии распознавания уже достигли своего теоретического придела. Хотя и для русского языка есть ещё куда совершенствуется.
Круто. Но "диктовка текста" — это всего один сценарий, хоть и сложный.
Если речь об управлении, то банальное "найди мне заправку по пути" или "скажи эльзе, что я опоздаю на митинг на двадцать минут" требует ещё больших усилий, чем функция стенографиста.

Здравствуйте, Cyberax, Вы писали:
C>Современные лингвистические модели (гуглить по "frame-semantic parsing") уже умеют извлекать смысл из текста. В смысле, пытаться заматчить текст на некоторый набор стандартных предложений.
Важное выделено.
Мы опять уходим от "всё понимать и всё делать", и приходим к оптимизации под конкретные сценарии.

Приветствую.
Может не в тот форум — разберёмся.

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

• тип — "сообщение"
  
• текст — string
  
• автор — string

и после создаём само сообщение, где "текст" — "привет", "автор" — "кто-то", а тип берётся из описания как есть. Получается что-то типа следующего:

сообщение: "привет", "кто-то"

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

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

А теперь к проблемам.
Я хочу добавить более сложные действия над сущностями, когда вместе с действием указываются дополнительные параметры или ссылки на другие сущности.
Например:

документ: "ДокументТакойТо" распечатать принтер "ПринтерТакойТо"

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

рабочая область: "РабочаяОбластьТакаяТо", пользователь: "ИвановИван", доступ: "ТолькоЧтение"

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

А теперь, для тех кто дочитал до сюда, правильно ли я думаю: если у нас есть две сущности, хранящиеся в разных местах, то сохранять действие, которое использовало эти сущности, нужно:
1. там, где действие выполнено;
2. там, где хранятся сущности (это актуально для примера с правами доступа — надо обязательно сохранить в рабочей области);
3. предоставлять автору действия выбирать, где сохранять действие.

В общем, любые комментарии приветствуются.

P.S. Походу, я потихоньку возвращаюсь сюда.

Привет, Real 3L0, давненько не встречались:


R3>1. ...там, где действие выполнено;
R3>2. там, где хранятся сущности (это актуально для примера с правами доступа — надо обязательно сохранить в рабочей области);
R3>3. предоставлять автору действия выбирать, где сохранять действие...

Аналогично, разбирая бизнес-процессы, я пришел к выводу, что неудобно выстраивать все сущности в один длинный список и затем строить между ними связи — процессы. Действительно, не всегда понятно к какой сущности больше привязан тот или иной процесс.

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

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

Здравствуйте, sereginseregin, Вы писали:

S>Аналогично, разбирая бизнес-процессы, я пришел к выводу, что неудобно выстраивать все сущности в один длинный список и затем строить между ними связи — процессы. Действительно, не всегда понятно к какой сущности больше привязан тот или иной процесс.

Ну, такого вопроса у меня не стоит: сущность либо используется в действие (в твоём случае — в БП), либо нет.

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

А вот эти абзацы не понял. Можешь дать пример?

Я думаю, что действия над сущностями, нужно хранить в том месте где хранится описание сущностей. Можно использовать для группировки что то типа пространства имен. Вообще нужно исходить от необходимого api к хранилищу.

Здравствуйте, Rinbe, Вы писали:

R>Я думаю, что действия над сущностями, нужно хранить в том месте где хранится описание сущностей. ...

Не обязательно. Например, чтобы дать человеку ключ от квартиры, тебе не обязательно быть рядом с входной дверью.

P.S. Извините за аналогию.

Можно я в этой теме буду свои мысли писать... Мне так лучше думается.

R3>

R3>рабочая область: "РабочаяОбластьТакаяТо", пользователь: "ИвановИван", доступ: "ТолькоЧтение"

R3>Сохраняя это действие в хранилище — мы также сохраняем права доступа к хранилищу, а это нужная информация.
R3>Почему это именно действие, а не сущность — не уверен, что могу объяснить. Может потому, что нет возможности точно определиться, какую сущность в какой хранить: пользователя в рабочей области или рабочую область в пользователе.
R3>Отдельное от объектов хранение действий позволяет, во-первых, вводить команды в любой последовательности операндов, а во-вторых, что очень важно, можно к любому хранящемуся объекту применить действие, которое использует в качестве операнда тип данного объекта.

Пришёл к следующим мыслям.
Если у нас есть такое действие, как в примере, то из него следует, что спрашивая у системы "какие пользователи имеют доступ к 'ТакойТо' рабочей области" и "в какие рабочие области имеет доступ 'ТакойТо' пользователь", получаем, что действие надо хранить так, чтобы оно было доступно как совместно с каждой рабочей областью, так и с каждым пользователем. Причём при изменении действия в одном месте, оно должно сразу измениться в другом.
Следовательно, действие должно быть одно и при этом быть чем-то типа связи двух сущностей.
Сейчас думаю, сохранять действия в хранилище, но не в явном виде, как сущности, а отображать их по конкретному запросу пользователя.

Здравствуйте, gandjustas, Вы писали:

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

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

Здравствуйте, Sinclair, Вы писали:

S>Несмотря на то, что каждый из них можно выразить в терминах запросов "получить список ID всех объектов типа А" + "получить детали объекта по его ID" + "сохранить изменения в объект по его ID", эффективность такой реализации будет сосать.

Дело в том, что у меня проблема не в реализации, а в постановке задачи, в аналитике. И в добавок хотелось бы понять, как это может выглядеть интерфейсно.
А реализация — дело наживное.
За примеры спасибо.

Здравствуйте, Sinclair, Вы писали:

S>Ну так это оттого, что у вас постановки нет. Задача "вычислять неизвестно что неизвестно как" имеет много классических решений. Например — машина Тьюринга.
S>Если вы хотите построить более удобное решение, то придётся сузить задачу.

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

Если допустить, что эта система уже создана, то пример использования: создал контакт (человека), написал ему письмо, поставил ему задачу, импортировал картинку, уменьшил размеры картинки, ну и два первых твоих примера (про самолёт и перевод денег; необходимость в третьем пока не вижу). И т.п. — как минимум, все "тупые" операции, выполняемые на компьютере.

Здравствуйте, Real 3L0, Вы писали:

R3>Задача проста: хочу некую систему, куда я
R3>1. могу заносить информацию (в идеале — любую)
R3>2. управлять этой информацией (в иделе — любое управление)
Вашим требованиям с избытком удовлетворяет файловая система FAT-12.

R3>Если допустить, что эта система уже создана, то пример использования: создал контакт (человека), написал ему письмо, поставил ему задачу, импортировал картинку, уменьшил размеры картинки, ну и два первых твоих примера (про самолёт и перевод денег; необходимость в третьем пока не вижу). И т.п. — как минимум, все "тупые" операции, выполняемые на компьютере.
Все тупые операции и так выполняются на компьютере.

Задачи по-прежнему нет.

Здравствуйте, Sinclair, Вы писали:

S>Вашим требованиям с избытком удовлетворяет файловая система FAT-12.

Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли".

S>Все тупые операции и так выполняются на компьютере.

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

S>Задачи по-прежнему нет.

А сейчас?

...
P.S. Голосовое управление не предлагать в связи с отсутствием 100% распознавания.

Здравствуйте, Real 3L0, Вы писали:

R3>Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли".
Критериев юзерфрендливости не озвучено.

S>>Все тупые операции и так выполняются на компьютере.
R3>И во-вторых, ещё хочется с помощью единого интерфейса (в какой-то степени это следует из "юзерфрендли", т.к. отсутствует необходимость изучения новых интерфейсов).
command.com даёт вполне себе единый интерфейс.

S>>Задачи по-прежнему нет.
R3>А сейчас?
И сейчас нет.

R3>P.S. Голосовое управление не предлагать в связи с отсутствием 100% распознавания.
Даже если бы было 100% распознавание с детектом подтекстов и сарказмов, это бы не помогло. Проблема не в распознавании, а в отсутствии постановки задачи.

R3>

R3>документ: "ДокументТакойТо" распечатать принтер "ПринтерТакойТо"

Sinclair, упомянул про коммандную строку. Как-то я забыл про неё, хотя когда-то думал о ней.
Т.е. получается, что действие — это множество пар [<параметр> <значение>] + [название действия]
Таким образом, действие можно записать как сущность:

• распечатать
  
• документ: "ДокументТакойТо"
  
• принтер "ПринтерТакойТо"

Здравствуйте, Sinclair, Вы писали:

R3>>Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли".
S>Критериев юзерфрендливости не озвучено.

Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи).

S>command.com даёт вполне себе единый интерфейс.

+1.

S>>>Задачи по-прежнему нет.

Упростить/облегчить взаимодействие с компьютером.

Здравствуйте, Real 3L0, Вы писали:

R3>Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи).
Ну, тогда попробуйте Windows Explorer — он же дефолтный шелл пользовательских версий винды.

R3>Упростить/облегчить взаимодействие с компьютером.
Это не задача. Как только у вас в требованиях появляются сравнительные степени (легче, проще, быстрее), надо сразу задавать
а) по сравнению с чем и
б) на каких сценариях

Потому что, скажем, заменить во всех файлах в определённом пути символ "," на ", ёпть," из командной строки линукса значительно быстрее/легче/проще, чем в GUI Windows Explorer.

При этом напомню, что пользователь "систему хранения данных" не видит вообще. Он видит исключительно UI — и можно сделать офигенно удобный UI на чистой файлухе (т.е. древовидное хранение именованных блобов), а можно сделать полное угробище поверх пост-реляционной ОО СУБД с транзакциями и шлюхами.

Вы в какой области хотите задачу решить — User Experience или Back-end?

Здравствуйте, Real 3L0, Вы писали:
R3>Т.е. получается, что действие — это множество пар [<параметр> <значение>] + [название действия]
R3>Таким образом, действие можно записать как сущность:
(headbang).
Записываемость действия как сущности вообще никак не зависит от UI — будь там командная строка или веб-интерфейс.
Вот у вас есть "объект" контакт, который состоит из нескольких скалярных атрибутов и ссылок типа "начальник/подчинённый".
Чем этот объект отличается от объекта "изменить контакт", с атрибутами типа "дата изменения", "инициатор", "список троек "имя свойства, значение до, значение после""?

Здравствуйте, Sinclair, Вы писали:

R3>>Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи).
S>Ну, тогда попробуйте Windows Explorer — он же дефолтный шелл пользовательских версий винды.

У него (в отличии от command.com) нет возможности выполнить любое действие.

R3>>Упростить/облегчить взаимодействие с компьютером.
S>Это не задача. Как только у вас в требованиях появляются сравнительные степени (легче, проще, быстрее), надо сразу задавать
S>а) по сравнению с чем и
S>б) на каких сценариях

+1.
а) по сравнению с текущим программным обеспечением (например, с тем же command.com)
б) на максимально возможных (согласен, расплывчато, но это моя цель)

S>Потому что, скажем, заменить во всех файлах в определённом пути символ "," на ", ёпть," из командной строки линукса значительно быстрее/легче/проще, чем в GUI Windows Explorer.

Это если файлов много, а если один — эксплорер рулит. Более того, эксплорер рулит при количестве не больше N замен, где N — индивидуально. Например, я не помню какая команда отвечает за переименование, но помню стандартную клавишу F2 (переименование) + знаю о copy-paste, поэтому при некотором N мне проще сделать ручками, чем вспоминать (искать) название команды и какие у неё операнды.
И эта ситуация актуальна для всех редких действий.
Это, кстати, хороший пример юзерфрендли.

S>При этом напомню, что пользователь "систему хранения данных" не видит вообще. Он видит исключительно UI — и можно сделать офигенно удобный UI на чистой файлухе (т.е. древовидное хранение именованных блобов), а можно сделать полное угробище поверх пост-реляционной ОО СУБД с транзакциями и шлюхами.

+1.

S>Вы в какой области хотите задачу решить — User Experience или Back-end?

Думаю, в первой, т.к. проблемы пока только в ней, а вторая у меня всегда зависила от первой.

Здравствуйте, Sinclair, Вы писали:

R3>>Таким образом, действие можно записать как сущность:

Под словом "как" я подразумевал только визуальную похожесть. (Извини, если неясно выразился.) Поэтому...

S>Записываемость действия как сущности вообще никак не зависит от UI — будь там командная строка или веб-интерфейс.
S>Вот у вас есть "объект" контакт, который состоит из нескольких скалярных атрибутов и ссылок типа "начальник/подчинённый".
S>Чем этот объект отличается от объекта "изменить контакт", с атрибутами типа "дата изменения", "инициатор", "список троек "имя свойства, значение до, значение после""?

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

Здравствуйте, Real 3L0, Вы писали:

R3>У него (в отличии от command.com) нет возможности выполнить любое действие.
Ну конечно же есть.

R3>Думаю, в первой, т.к. проблемы пока только в ней, а вторая у меня всегда зависила от первой.
Тогда вам надо сначала почитать книги, к примеру, Тео Манделла (критически) и Якоба Нильсена (с уважением).

Здравствуйте, Real 3L0, Вы писали:
R3>Под словом "как" я подразумевал только визуальную похожесть. (Извини, если неясно выразился.) Поэтому...
Откуда взялась визуальная похожесть?

S>>Записываемость действия как сущности вообще никак не зависит от UI — будь там командная строка или веб-интерфейс.
S>>Вот у вас есть "объект" контакт, который состоит из нескольких скалярных атрибутов и ссылок типа "начальник/подчинённый".
S>>Чем этот объект отличается от объекта "изменить контакт", с атрибутами типа "дата изменения", "инициатор", "список троек "имя свойства, значение до, значение после""?

R3>... я не понимаю, что за объект "изменить контакт". В моём понятии — это "действие + объект" или "действие над объектом".
Вы уже определили "объект" как ID и набор типизированных атрибутов. "изменить контакт" — это такой же объект, с id и атрибутами.

R3>Т.е. если мы опишем, что объект контакт имеет все перечисленные тобой атрибуты, то они и будут. Если мы создадим действие "изменить", то это будет просто редактирование любого контакта.
Да.
R3>А вот если мы создадим действие "отправить файл", то тут уже будут использоваться другие объекты (например, "электронный адрес" и "файл"), которые не существуют в описании объекта контакт.
Правильно, потому что "отправить файл" — это объект другого типа, чем "изменить контакт".

Скажите честно, вы математику в каком объёме изучали?

Здравствуйте, Sinclair, Вы писали:

R3>>У него (в отличии от command.com) нет возможности выполнить любое действие.
S>Ну конечно же есть.

Т.е. под эксплорером подразумеваем комбинацию коммандной строки + то, что он предлагает?

R3>>Думаю, в первой, т.к. проблемы пока только в ней, а вторая у меня всегда зависила от первой.
S>Тогда вам надо сначала почитать книги, к примеру, Тео Манделла (критически) и Якоба Нильсена (с уважением).

Ок, попробую почитать. Хотя Тео Манделла не нашёл.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Real 3L0, Вы писали:
R3>>Под словом "как" я подразумевал только визуальную похожесть. (Извини, если неясно выразился.) Поэтому...
S>Откуда взялась визуальная похожесть?

Как я писал в самом первом сообщении, сущность "привет" имеет вид:

сообщение
текст "привет"
автор "кто-то"

Следовательно, действие похоже:

распечатать
документ: "ДокументТакойТо"
принтер "ПринтерТакойТо"

R3>>... я не понимаю, что за объект "изменить контакт". В моём понятии — это "действие + объект" или "действие над объектом".
S>Вы уже определили "объект" как ID и набор типизированных атрибутов. "изменить контакт" — это такой же объект, с id и атрибутами.

Т.е. мне надо отказаться от понятия "действия"?

S>Скажите честно, вы математику в каком объёме изучали?

В университетском, но, видать, я действительно плохо учился, потому что не понимаю, при чём тут она.

Здравствуйте, Sinclair, Вы писали:

R3>>Т.е. под эксплорером подразумеваем комбинацию коммандной строки + то, что он предлагает?
S>Ну да. Даже если спрятать cmd.exe, у нас по-прежнему остаётся Win+R.

Ну так это опять даёт нам отсутствие дружелюбности для любого действия.

S>Важно читать его критически — проблемы интерфейса, которые он решал, сейчас в значительной мере устарели. И появились новые проблемы, про которые Тео ничего не знал, поэтому его решения во многом неадекватны.

После Раскина мне всё кажется устаревшим (хотя я с ним и не во всём согласен).

Здравствуйте, Real 3L0, Вы писали:

R3>Ну так это опять даёт нам отсутствие дружелюбности для любого действия.
Критерий дружелюбности?
Поймите, пока вы не возмёте конкретный сценарий с конкретными параметрами, вы никогда не сможете спроектировать UX.
Простейший пример: безналичный перевод денег со счёта пользователя в адрес некоего бенефициара.
Формально в общем случае у нас есть пачка реквизитов, которые могут потребоваться для идентификации бенефициара.
Можно бесконечно долго совещаться в замкнутой комнате и бесконечно передвигать по макетному столу все эти БИК, ОКАТО, двадцатизначные счета и прочее.
Но результат один хрен будет как в сбербанке 90х.
А когда мы выходим из коробки и смотрим в реальные сценарии, выясняется, что можно сэкономить 410 нажатий кнопок из 415 благодаря тому, что люди чаще всего переводят деньги своим родственникам/знакомым, у которых мало того, что счета в том же банке, но они ещё и включены в адресную книгу смартфонов друг друга.

Понимаете? Невозможно это угадать, не глядя в реальный сценарий. И это — для изолированной задачи!
А если поставить задачу не просто "переводить деньги куда угодно", а "делать что угодно с чем угодно", то спроектировать "удобный UI" практически невозможно.
Можно сделать что-то типа 1С — где есть понятия типов данных, поэтому разработчику не нужно заморачиваться с банальными вещами вроде прикручивания справочника счетов к полю ввода "номер счёта" для отчётов.


R3>После Раскина мне всё кажется устаревшим (хотя я с ним и не во всём согласен).
Вот как раз до него у меня руки не дошли. Надо бы заняться.

Здравствуйте, Sinclair, Вы писали:

S>А если поставить задачу не просто "переводить деньги куда угодно", а "делать что угодно с чем угодно", то спроектировать "удобный UI" практически невозможно.

Пример понятен. Соглашусь с невозможностью спроектировать удобный UI (только потому, что не встречал), но не соглашусь с невозможностью спроектировать такой UI. Доказательство — существование таких проектов, как всякие Siri или Mozilla Ubiquity.
Это может быть задачей?

Здравствуйте, Real 3L0, Вы писали:
R3>Пример понятен. Соглашусь с невозможностью спроектировать удобный UI (только потому, что не встречал), но не соглашусь с невозможностью спроектировать такой UI. Доказательство — существование таких проектов, как всякие Siri или Mozilla Ubiquity.
R3>Это может быть задачей?
На всякий случай поясню, что "всякие Siri" начинались не с "давайте прикрутим голосовое управление к чему угодно", а со списка сценариев типа "узнать текущую погоду", "добавить событие в календарь", "ответить на сообщение" и прочих.
Если хочется полезть на рынок Siri, то нужно иметь как минимум полсотни, а лучше сто, очень конкретных сценариев с внятными критериями успеха и удобства.

Иначе — не взлетит.

Здравствуйте, Sinclair, Вы писали:

S>На всякий случай поясню, что "всякие Siri" начинались не с "давайте прикрутим голосовое управление к чему угодно", а со списка сценариев типа "узнать текущую погоду", "добавить событие в календарь", "ответить на сообщение" и прочих.
S>Если хочется полезть на рынок Siri, то нужно иметь как минимум полсотни, а лучше сто, очень конкретных сценариев с внятными критериями успеха и удобства.
S>Иначе — не взлетит.

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

Здравствуйте, Sinclair, Вы писали:

S>Если хочется полезть на рынок Siri, то нужно иметь как минимум полсотни, а лучше сто, очень конкретных сценариев с внятными критериями успеха и удобства.
S>Иначе — не взлетит.
Для эксперимента это сообщение я пишу с помощью распознания голоса. Как не странно но для русского языка это работает очень даже неплохо, даже запятые ставятся в нужных местах. А вот с английским всё плохо, видимо для английского языка простые технологии распознавания уже достигли своего теоретического придела. Хотя и для русского языка есть ещё куда совершенствуется.

Здравствуйте, Sinclair, Вы писали:

S>Тео — собственно, основной пропонент "объектно-ориентированного UI", отвечавший за разработку UX в OS/2.

Прочитал Тео.
Похоже на то, что я пытаюсь сделать другой (может быть — более лучший) "объекто-ориентированный UI".

Здравствуйте, Real 3L0, Вы писали:

R3>Приветствую.
R3>А теперь, для тех кто дочитал до сюда, правильно ли я думаю: если у нас есть две сущности, хранящиеся в разных местах, то сохранять действие, которое использовало эти сущности, нужно:
R3>1. там, где действие выполнено;
R3>2. там, где хранятся сущности (это актуально для примера с правами доступа — надо обязательно сохранить в рабочей области);
R3>3. предоставлять автору действия выбирать, где сохранять действие.

Зачем плодить новые понятия. Хранить надо объект и методы. Где хранить объекты вопрос пользователя, а методы храняться в классе. Кроме того есть еще необходимость хранить связи. Не адреса, а то, что я называю событиями. Нечто которое фиксирует факт актуальности применения какого то метода. Т.е. процедуры обработки события. И есть еще одна проблема. Сам метод тоже надо хранить. А он состоит из операторов или инструкций. Это не объекты, а субъекты. Они должны тоже иметь какой-то формат. И очень подходит вариант типа класс-субъект. Я назвал такой подход концептным.

Здравствуйте, Real 3L0, Вы писали:

R3>Т.е. мне надо отказаться от понятия "действия"?
Надо понять, для чего оно нужно.
R3>В университетском, но, видать, я действительно плохо учился, потому что не понимаю, при чём тут она.
Математика обучает обходиться минимумом абстракций, и сводить задачи к уже известным.
Например не придумывать какие-то "действия", которые изоморфны "объектам". Или при придумывании сразу идентифицировать различия.
Вот, скажем, в COM есть интерфейс IUnknown, которого вполне достаточно в качестве основы.
Но спецификация обязана описывать не только вопрос взаимодействия между объектами, но и вопросы порождения объектов, обмена данными, и прочие.
Отсюда IClassFactory, IContext, IMalloc, и прочие неотъемлемые части спецификации COM.

Здравствуйте, Sinclair, Вы писали:

S>Если речь об управлении, то банальное "найди мне заправку по пути" или "скажи эльзе, что я опоздаю на митинг на двадцать минут" требует ещё больших усилий, чем функция стенографиста.
Современные лингвистические модели (гуглить по "frame-semantic parsing") уже умеют извлекать смысл из текста. В смысле, пытаться заматчить текст на некоторый набор стандартных предложений.

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

Здравствуйте, Sinclair, Вы писали:

C>>Современные лингвистические модели (гуглить по "frame-semantic parsing") уже умеют извлекать смысл из текста. В смысле, пытаться заматчить текст на некоторый набор стандартных предложений.
S>Важное выделено.
S>Мы опять уходим от "всё понимать и всё делать", и приходим к оптимизации под конкретные сценарии.
Насколько я помню, в самом большом корпусе "semantic frame"'ов сейчас более 20 тысяч шаблонов. Причём есть и правила их каноникализации.

Конечно, это не настоящий AI, но запросы типа "где ближайшее место, чтобы заправить топливо" поймёт.

Здравствуйте, Cyberax, Вы писали:
C>Конечно, это не настоящий AI, но запросы типа "где ближайшее место, чтобы заправить топливо" поймёт.
Для этого нужно не просто "понять", но и что-то сделать. Например, передать запрос программе навигации (какой именно?), озвучить варианты маршрута, принять команду к перепрокладке и т.п.
То есть помимо абстрактного "корпуса семантики" нужна привязка этой семантики к функциональности конкретного окружения.

Здравствуйте, batu, Вы писали:

B>Зачем плодить новые понятия. Хранить надо объект и методы. Где хранить объекты вопрос пользователя, а методы храняться в классе.

Сейчас я храню методы не в классе, потому что начитался про OWL. Поэтому и параметры объекта — тоже хранятся не в классе. Собственно, на текущем этапе никаких проблем не заметил.

B> Кроме того есть еще необходимость хранить связи. Не адреса, а то, что я называю событиями. Нечто которое фиксирует факт актуальности применения какого то метода. Т.е. процедуры обработки события.

Вот этого вообще не понял.

B> И есть еще одна проблема. Сам метод тоже надо хранить. А он состоит из операторов или инструкций. Это не объекты, а субъекты. Они должны тоже иметь какой-то формат. И очень подходит вариант типа класс-субъект. Я назвал такой подход концептным.

Метод конечно надо хранить. Сейчас методы самого низкого уровня, поэтому это просто бинарный код. Потом (когда-нибудь) можно будет создавать методы из методов, но это всё равно останется методом.

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, batu, Вы писали:

B>>Зачем плодить новые понятия. Хранить надо объект и методы. Где хранить объекты вопрос пользователя, а методы храняться в классе.

R3>Сейчас я храню методы не в классе, потому что начитался про OWL. Поэтому и параметры объекта — тоже хранятся не в классе. Собственно, на текущем этапе никаких проблем не заметил.
А проблем по хранению и не будет. Проблемы с дублированием. Ну, глупо хранить методы с объектом, если это метод класса.

B>> Кроме того есть еще необходимость хранить связи. Не адреса, а то, что я называю событиями. Нечто которое фиксирует факт актуальности применения какого то метода. Т.е. процедуры обработки события.

R3>Вот этого вообще не понял.
Я б удивился если б ты понял. Намекаю. Объекты как-то взаимодействуют друг с другом.. Вот это взаимодействие и надо определять.. Может у тебя таких проблем еще нет.. Но будут..

B>> И есть еще одна проблема. Сам метод тоже надо хранить. А он состоит из операторов или инструкций. Это не объекты, а субъекты. Они должны тоже иметь какой-то формат. И очень подходит вариант типа класс-субъект. Я назвал такой подход концептным.

R3>Метод конечно надо хранить. Сейчас методы самого низкого уровня, поэтому это просто бинарный код. Потом (когда-нибудь) можно будет создавать методы из методов, но это всё равно останется методом.
Можно и в бинарном методы хранить.. И объект можно в бинарном.. Но, как-то систематизировать оно лучше.. Вот и придумали классы.. И еще одно напряжение мозга...И методы так же..

Здравствуйте, Sinclair, Вы писали:

R3>>Т.е. мне надо отказаться от понятия "действия"?
S>Надо понять, для чего оно нужно.

Действие — это, по сути, аналог нажатия на кнопку "ОК" в форме десктоп интерфейса. В зависимости от существующих на форме контролов (параметров), это нажатие выполнит некоторую функцию.

R3>>В университетском, но, видать, я действительно плохо учился, потому что не понимаю, при чём тут она.
S>Математика обучает обходиться минимумом абстракций, и сводить задачи к уже известным.
S>Например не придумывать какие-то "действия", которые изоморфны "объектам". Или при придумывании сразу идентифицировать различия.

Вот этого я и не могу понять. (Гы! Я всё забыл — определение изоморфизма смотрел в вики.)
Если объект — это число, а действие — операция сложения, то где тут изоморфизм? (Я правильно прочитал изоморфизм?)

Здравствуйте, batu, Вы писали:

B>>>Зачем плодить новые понятия. Хранить надо объект и методы. Где хранить объекты вопрос пользователя, а методы храняться в классе.
R3>>Сейчас я храню методы не в классе, потому что начитался про OWL. Поэтому и параметры объекта — тоже хранятся не в классе. Собственно, на текущем этапе никаких проблем не заметил.
B>А проблем по хранению и не будет. Проблемы с дублированием. Ну, глупо хранить методы с объектом, если это метод класса.

Необходимо пояснение. Метод, он хотя и хранится отдельно, но относится только к определённому классу. Можно наделать много методов, никак не изменяя класс. (В программировании, вроде, есть такой паттерн.)
Аналогично — с полями класса.
Дублирования нет.

B>>> Кроме того есть еще необходимость хранить связи. Не адреса, а то, что я называю событиями. Нечто которое фиксирует факт актуальности применения какого то метода. Т.е. процедуры обработки события.
R3>>Вот этого вообще не понял.
B>Я б удивился если б ты понял. Намекаю. Объекты как-то взаимодействуют друг с другом.. Вот это взаимодействие и надо определять.. Может у тебя таких проблем еще нет.. Но будут..

Взаимодействие есть. Пример:

сообщение
текст — "привет"
автор — "кто-то"

Данный объект-сообщение (условно назовём его "привет") связан с объектом-контактом (условно назовём его "кто-то").

Здравствуйте, Sinclair, Вы писали:

S>Число — это объект {2}. Точка на плоскости — это объект {1, 2}. Действие "сложить 2 и 2" — это объект {+, 2, 2}.

Ну если так, то да, согласен.
Подумаю.

Здравствуйте, Sinclair, Вы писали:

S>То есть помимо абстрактного "корпуса семантики" нужна привязка этой семантики к функциональности конкретного окружения.
А это уже проще — количество возможных действий даже в самых продвинутых программах весьма невелико.

Таким образом, пока остановлюсь на том, что хранить буду сущности следующего вида:

<объект>
[
  действие
    [объект]
    ...
]

Пример:

документ "DocumentName"
распечатать
принтер "PrinterName"

Здравствуйте, Sinclair, Вы писали:

S>... Якоба Нильсена (с уважением).

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