Эрик Реймонд - Искусство программирования для Unix

Проблема управления сеансами может быть переадресована серверам приложений, таким как Zope или Enhydra, которые обеспечивают отделение сеансов и предоставляют службы аутентификации для программ внутри них. Недостаток данных программ равноценен их достоинству: они облегчают сохранение на сервере информации о состоянии по каждому пользовательскому сеансу. Хранение данных сведений может оказаться проблемой. Оно занимает ресурсы, и данную информацию необходимо удалять по истечении определенного времени, поскольку между транзакциями не существует способа точно определить, остается ли пользователь на связи.

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

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

Способ, с помощью которого браузеры отделяют клиентов от серверов, имеет более серьезные последствия. В Web-среде стало сложнее и не так привлекательно привязывать потребителей к закрытым, частным протоколам и API-интерфейсам. Экономика разработки программ, таким образом, склоняется к HTML, XML и другим открытым, текстовым Internet-стандартам. Данная тенденция успешно и интересно объединяется с развитием модели разработки открытого исходного кода, которая рассматривается в главе 19. В мире, где Web является созидательной средой, Unix-традиции проектирования, включая рассмотренные в настоящей главе методики проектирования интерфейсов, выглядит гораздо более естественно, чем когда-либо прежде.

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

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

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

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

Необходимо двигаться дальше и снабжать длительные операции индикаторами выполнения. Это хороший стиль, позволяющий пользователю, распределять свое внимание на чтение почты или другие задачи, ожидая подтверждения. Однако не следует загромождать GUI-интерфейсы всплывающими окнами подтверждения, кроме случаев, когда необходимо обезопасить операции, в результате которых данные могут быть утеряны или повреждены, и даже тогда необходимо скрывать их, если родительское окно свернуто, и не показывать до тех пор, пока родительское окно не получит фокус [107] Если в системе поддерживаются подсвечиваемые всплывающие окна, которые "мало вторгаются" между пользователем и приложением, используйте их . . Задача дизайнера интерфейса заключается в том, чтобы помогать пользователю, а не беспричинно вмешиваться в его работу.

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