Ларри Константин - Человеческий фактор в программировании

Приведем еще один пример эффективной перегрузки. В интерфейсах многих приложений есть визуальные компоненты, к которым можно перетаскивать данные для запуска процесса их обработки. Известными примерами таких «зон сброса» являются пиктограммы принтеров и корзин для мусора, расположенные на экране. В некоторых случаях весьма разумно иметь как зону, в которую можно перетаскивать документы, так и специальную управляющую кнопку для применения операции к уже выбранным данным. Одни пользователи предпочитают идиому drag-and-drop, другим этот механизм кажется утомительным и трудным, поэтому они предпочитают выбирать данные, а потом щелкать мышью по элементу управления. Иногда в приложениях можно увидеть условность, согласно которой «зоне втаскивания» придается соответствующая «подсказка» в виде углубления или «колодца». В соответствии с принятой практикой «подсказка нажатия» передается при помощи создания выступающей, выпуклой внешней формы. Объединенный элемент управления состоит из выступа в виде кнопки, помещенного в центр неглубокого «колодца». Он говорит пользователю: «Или тащи сюда, или нажимай — как хочешь».

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

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

По материалу из журнала Object Magazine, март 1997 г.

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

Ряд ведущих специалистов-практиков также пришли к заключению, что пользовательские ситуации полезны при разработке пользовательских интерфейсов (см. главу 22). Если пользовательские ситуации можно применять для управления разработкой объектного взаимодействия и разбиения методов по классам, значит, их можно применять для проектирования взаимодействия между человеком и компьютером и для распределения элементов интерфейса между интерфейсными контекстами. Логика может показаться неубедительной, однако эта идея обладает привлекательностью, являясь своего рода технологическим вариантом волшебства, основанного на внушении. В конце концов, оба термина имеют общий ко-рень и могут даже рифмоваться. «Идя в рейсы по пользовательскому интерфейсу, не забывайте пользовательские кейсы» [41] Going places with use cases for user interfaces — это вполне может быть девизом часа.