Ответ на »сообщение 2710« (Mak)
___________________________

В смысле, драйверы на Форте?  Форт-технологию с точки зрения ОС, прежде всего, я мыслю в использовании словаря по средствам которого пользователю доступны для вызова все
процедуры/функции ОС (не задумываясь, зачем они ему нужны).

Думаю, сейчас нет смысла конкретизировать задачу. Тем более, раз речь идет об исследованиях. Если не возражаете, то к моменту, когда здесь будет у нас больше ясности, я к Вам обращусь за советом.

Я пока не готом хранить ваши секреты. Вообще, я приверженец ОpenSource.

OpenSource бывает разный. Я не знаю ни одного OpenSource-проекта, в котором публике были бы доступны все материалы общения участников, включая личную переписку, трассировку ICQ, множество черновиков и т.п.

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

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

Ответ на »сообщение 2708« (Димыч)
___________________________

Подумал, подумал, и решил написать что:
фокус внимания, это то, на что вы сейчас смотрите или непосредственно контролируете.
локус внимания, это то, о чем вы сейчас думаете или над чем работаете.

Спасибо за детальное изложение. Это довольно полезная модель. Но я бы в нее добавил всего одно понятие (чтобы очень сильно не усложнять) -- контекст мышления. Это именно то, в рамках чего работают локус ("внимание" сознания) и фокус ("внимание" зрения, слуха, осязания, обоняния, вкуса). Контекст мышления -- это состояние сознания и подсознания, в котором и ведутся все остальные "вычисления" человеком.

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

Ответ на »сообщение 2636« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2632« (Mak)

5. С начала формирования команды, выведения ее на уровень кристаллизации и закладывания основ своей "корпоративной" культуры с соотв. требованиями к ведению и качеству работы. Первый год проекта направлен именно на решение этой задачи.


  Думаю, до альфа-версии я не доживу.


Речь идет, прежде всего, о проработке вопросов использования Форта в качестве языка, обеспечивающего слой между железом (процессором) и ОС.


  В смысле, драйверы на Форте?  Форт-технологию с точки зрения ОС, прежде всего, я мыслю в
использовании словаря по средствам которого пользователю доступны для вызова все
процедуры/функции ОС (не задумываясь, зачем они ему нужны).


Но есть и иные задумки. Однако не дело это обсуждать в публичном форуме. Есть готовность и желание -- я Вам пришлю приглашение вступить в нашу группу. Вы сможете войти в контекст работ и рассмотренных идей, после чего можно будет совместно выработать шаги движения в этом направлении.


Я пока не готом хранить ваши секреты. Вообще, я приверженец ОpenSource.

Ответ на »сообщение 2707« (Димыч)
___________________________
Можно свои три копейки в копилку графики?
Согласен по всем пунктам.
И книга Раскина - очень толковая книга, читал, многие вещи запомнились.

Ответ на »сообщение 2707« (Димыч)
___________________________

Подумал, подумал, и решил написать что:
фокус внимания, это то, на что вы сейчас смотрите или непосредственно контролируете.
локус внимания, это то, о чем вы сейчас думаете или над чем работаете.

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

Проблема в том, что на восстановление локуса внимания нужно от 2 до 15 мин в зависимости от кучи факторов.

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

Можно свои три копейки в копилку графики?

1. Хороший пользовательский интерфейс, это такой интерфейс, который не прерывает работу пользователя переключением локуса внимания. Достигается это путем сведения к минимуму модальности в системе. Пример хорошего интерфейса привести не смогу, поскольку хороший интерфейс обязательно должен быть связан с предметной областью. Что для предметника очевидно с первого взгляда, неспециалисту может быть непонятно совсем. Одно очевидно точно - хороший интерфейс содержит минимальное количество форм в программе. После применения этого принципа в одной из своих программ количество экранных форм было сокращено с примерно 20 до 6, причем заказчик сказал сразу "о, все понятно". Без изменения функциональности.

Понятие локус и модальность раскрываются в книге Д.Раскина. Найти можно на books.ru.

2. Программист (да и администратор тоже) работает с текстом потому, что текст дает большую гибкость по сравнению с графикой. Я был поражен, когда однажды в Линуксе увидел экранный интерфейс настройки сетевого подключения. Модальное окно свойств с 5 или более вкладок, где не видно (естественно), что находится на соседней вкладке и что ты только что настроил. При этом

man ifconfig

было куда понятнее.

Или еще один пример. На создание скрипта резервного копирования базы данных уходит по моим оценкам от дня до недели в зависимости от размера базы. При этом скрипт можно прочитать (две-пять страниц текста по 60 строк). То же самое в виде элементов в списке действий (MS SQL, Oracle 10g) совершенно не поддается анализу, пока не ткнешся мышкой и не посмотришь сложную экранную форму.

Конечно, с первого раза охватить весь синтаксис оператора BACKUP сложно. Но можно. И в дальнейшем им пользоваться тоже не сложно, поскольку для разбора деталей нужно лишь заглянуть в справку и написать что нужно, а не пробираться через экраны мастера (одно переключение модальности в справке против 6-7 в мастере с возможностью отката только на один экран [и то, если мастер хорошо написан и не сбрасывает состояние при возврате]).

3. Применение конструкторов и мастеров позволяет подтянуть новичков. В книге "Человеческий фактор в программировании" Л.Константайна есть график распределения пользователей систем. Большая часть - середнячки, которые знают свое дело и делают его хорошо. Для них мастера не нужны, поскольку список задач такого середнячка меняется редко. Для них нужно, чтобы программа не мешала работать.

Для новичка же важен т.н. "wow-фактор" или "впендюринг". "Ух ты, как тут удобно настраивается бэкап и запросы как просто делаются!..". Это понуждает покупать (или другим способом получать ПО), ну а потом в игру вступают другие механизмы (у всех так, слезть трудно, привыкли и пр.)

4. Применение в графическом интерфейсе мыши имеет ограниченное применение. Возможно предыдущая мысль покажется странной, но повсеместная ориентация на мышь пагубно сказывается на производительности работы пользователя. Соотношение скорости работы пользователя с мышью и с клавиатурой - примерно 16 к 1 (с мышью медленнее). Опять же см. Раскина.

Хорошим доказательством того, что клавиатура превосходит мышь по скорости работы является наблюдение за квалифицированным верстальщиком или дизайнером. В, казалось бы, чисто "мышинном" интерфейсе программы верстки хороший верстальщик практически не пользуется мышью, т.к. все позиционирование подчиняется сравнительно неплохо формализуемым правилам; мышь в этой ситуации даже мешает. Чем меньше в программе происходит переключений локуса внимания, тем больше вероятность того, что программой будет удобно пользоваться.

Выводы.
- Подход к противопоставлению "графика" - "текст" надо искать не в форме, а в применимости, основываясь на особенностях человеческой психики.
- Все средства хороши, но некоторые "хорошЕе". Применение средств должно ориентироваться прежде всего на "середнячков", на тех, кто будет применять инструменты повседневно, а не раз в год/месяц/квартал.
- Маркетинг в процессе разработки бывает очень вреден, поскольку заставляет встраивать в программу механизмы, вовсе не нужные пользователю.

Ответ на »сообщение 2703« (Сергей Прохоренко)
___________________________

Это творческий процесс, со всеми его недостатками. Должен быть проблемный подход (для каждой проблемы ищем решение), ясное ви'дение цели и поддержка ключевых лиц проекта.

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

Речь идет об одном универсальном инструменте? Или о наборе инструментов? Каковы границы его/их применимости?

Ответ на »сообщение 2702« (Сергей Прохоренко)
___________________________

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

и написанием ТЗ на разработку (другими средствами разработки) и бесконечно долгим ожиданием результата, а затем тестированием.
А вот это уже делает вас специалистом несколько другого профиля, чем разработчик.

Разве истина устанавливается голосованием?
При чем здесь голосование? Если Вы никак не можете убедить нескольких людей в своей позиции, то о чем это, по Вашему мнению, может говорить?

Разве что-то новое всегда сразу получало единогласное одобрение?
Вспомните год появления Access или год появления Delphi. О чем новом Вы говорите? Все это уже старые концепции, которым больше 10 лет.

Ответ на »сообщение 2692« (Eugene)
___________________________

Доброго времени суток!

Ответ на »сообщение 2688« (Сергей Прохоренко)
___________________________

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


А почему она Вас смущает? Кстати, документ с программным кодом должен представлять собой структурированный гипертекст (слово текст видите?), то есть симбиоз текста и графических объектов.

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


Что касается хранимых процедур и т.п., то Вы, наверное не в курсе, что в Access'е есть и очень удобный построитель макросов, и редактор кода на Вижуалбейсике, а набранный в построителе макрос можно автоматически преобразовать в модуль на Вижуалбейсике.
Да, Вы правы, с этим я не сталкивался. Но вот что гласит справка по Access 2002 ("Выбор между использованием макросов и программ Visual Basic"):
Макрос является удобным средством выполнения простых задач, таких как открытие и закрытие форм или запуск отчетов...
Программы Visual Basic используют вместо макросов в следующих случаях:
- Упрощение управления базой данных. Поскольку макросы являются объектами, существующими отдельно от использующих их форм и отчетов, поддержание базы данных, в которой реакция на события в формах и отчетах определяется многими макросами, становится достаточно затруднительным...
Таким образом, как я понимаю, макросы имеют вспомогательное значение, и для серьезной разработки все равно нужно писать модуль на VB.
С уважением,


Это и мои коллеги отмечали, что авторы справки и толстых руководств недооценивают макросы и незаслуженно отдают предпочтение Вижуалбейсику. Кстати, по Access'у нет ни толковой справки, ни хорошей литературы.

На моем веку был только один случай, когда макросов оказалось недостаточно, и понадобился модуль на Вижуалбейсике. Просто та задача полностью выходила за пределы естественной ниши СУБД.

Ответ на »сообщение 2690« (Beginner)
___________________________

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

Кроме сомнительного по качеству Access какие ещё примеры подобных систем?
На примерах понятнее.


А Вы не сомневайтесь. Access - очень качественная система. Excel - тоже. А еще Business Objects.

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