В.Г.Бендаринов, г. Горький

О программировании интерфейсов

При чтении программы, опубликованной в № 2 за 1990 r. (c. 36), управляющей программатором ППЗУ, в глаза бросилась самая начальная её часть - выбор режима работы. Она, конечно, предельно проста и предусматривает все режимы работы, но неудобна. Возможно, пользователь БК этого сразу не поймёт, но пользователю компьютеров типа IBM с более совершенным программным обеспечением этого доказывать не нужно.

Следует сформулировать основные положения, которых надо придерживаться при программировании интерфейсов:

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

Теперь приведём структуру таких программ в PASCAL-TURBO.

Program MenuExample, Var
Koordinate: integer;
Key : Char ;
{$l Menu.HEL}
{$l OffOld.HEL} {в эти файлы надо записать процедуры, выполняющие}
{$l ChangeK.HEL} {соответствующие действия и использующие глобальные}
{$l OnNew.HEL} {переменные Key и Koordinate}
{$l Makes.HEL}
Begin
    Menu; {вывод текста меню }
    Repeat;
    If KeyPressed Then
    Begin
        Key: = ReadKey; {B более ранних версиях использовать Read(Kbd, Key)}
        OffOld; {убрать отметку предыдущего режима }
        ChangeKoordinates; {изменить координаты } OnNew; {отметить новый режим}
        If Key = #27 Then Exit; {выход по нажатию ESC} End;
        Until Key = #13; {до нажатия ENTER }
        Case Koordinate Of
            K1: Make1; {действие 1}
            K2: Make2; {действие 2}
            {включить все действия } 
        End;
    End;
End.

Заключение рецензента

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

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

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

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

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

Практические ограничения интерфейса часто связаны только с ограниченными фантазией и умением разработчиков программ.

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

Во-первых, из всех предложенных правил имеются исключения (особенно в игровых программах).

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

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

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

В-пятых, вопросы интерфейса с программами настолько важны, что разработчики систем программирования иногда включают средства создания и поддержки меню в состав системных библиотек. Например, система Турбо-Паскаль для персональных ЭВМ типа IBM PC имеет специальный пакет библиотечных файлов Turbo Professional, среди которых есть эти средства, поддержанные специальной диалоговой системой. Они достаточно просты в освоении и позволяют создавать удобный интерфейс действительно высокого уровня.

Скелет программы на Турбо-Паскале, представленный автором, пригоден для простого меню, в котором тема меню выбирается только один раз. Для многократного использования меню необходимо цикл REPEAT и оператор CASE охватить ещё одним циклом.

В головной программе не учтено, что управляющие символы, в частности символы, вырабатываемые клавишами перемещения курсора, требуют двух операторов ReadKey (или Read (Kbd, Key), поэтому во включаемых процедурах необходим свой анализ значения переменной Key и считывание второй половины кода для управляющей клавиши.

Кроме этого, в операторе CASE вместо K1 и K2 требуются некоторые целые значения, чтобы программа соответствовала синтаксису ПАСКАЛЯ.

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

Как и с помощью каких средств проектируют меню профессионалы, программирующие на БЕЙСИКЕе, можно узнать в выпуске журнала "Мир ПК", № 1, 1990 (Джим Вудграфф. Генератор меню). Статья Д. Вудграффа будет полезна не только профессионалам.