"Редактор свойств" c точки зрения удобства пользователя

Седельников Андрей

Программистам визуальных средств разработки (RAD) хорошо знаком такой обязательный элемент среды как "редактор свойств" (properties editor). Он представляет собой специальное окно, в котором отображаются и редактируются самые разные свойства объектов среды. Используется он очень часто, поэтому от того, насколько такой редактор свойств удобен в использовании зависит эффективность работы программиста.  В этой статье я проведу краткий анализ достоинств и недостатков редакторов свойств трех наиболее популярных сред разработки приложений - Visual FoxPro, VisualBasic и Delphi, а также покажу возможные пути его дальнейшего совершенствования.

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

Visual FoxPro 6

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

Второй недостаток проявляется уже при работе - это большое количество информации, которое обрушивается на пользователя. Например простейшая форма имеет 100 свойств и 61 метод. При таком количестве свойств найти одно нужное становится очень трудно. Откуда же их столько взялось? При внимательном рассмотрении выясняется, что среди них много попросту ненужных и неиспользуемых.  Например есть информационные свойства - только для чтения. Встречаются даже свойства только для Mac'а при том что мы работаем на PC. Затрудняет поиск нужного свойства еще и неудачная структура самих свойств. Например на рисунке вы видите 10 свойств, начинающихся со слова Font.

Разработчики Visual FoxPro все же поняли, что с таким количеством свойств работать сложно, поэтому они придумали понятие свойства по-умолчанию, то есть те свойства, которые изменены пользователем, помечаются жирным шрифтом. Это хорошее решение - если вы точно знаете, что вы меняли это свойство, найти его будет легче, потому что ваш мозг при таком поиске будет как-бы отфильтровывать свойства, отображенные обычным шрифтом. При всем этом подпись [Default] у свойств почему-то оставили, загрязняя экран лишним визуальным шумом.

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

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

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

В редакторе свойств Visual Basic уже заметно меньше свойств. Та же простая форма имеет их всего 50 штук (методы здесь не отображаются). По сравнению с Visual FoxPro видны несколько преимуществ:

• Редактирование свойства происходит непосредственно там, же где оно отображается
• Два вида представления списка - по-алфавиту и по-категориям, причем ненужные в данный категории можно "свернуть"
• Область подсказки можно расширить
• У свойств типа "цвет" отображается сам цвет, а не только его закодированное его значение

Но в очередной раз до конца все не доведено:

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

- Категории свойств и здесь продуманы плохо. Например почему Font не находится в Appearance (cм.рис)?

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

В фирме Borland видимо пострались учесть недостатки редактора свойств других программ, потому что их ObjectInspector обладает множеством полезных качеств, положительно влияющих на продуктивность и удобство работы:

• Редактируемое в данный момент свойство всегда четко отличается от других.
• Значения свойств визуально отделены от названий цветом, что облегчает визуальный поиск нужного названия.
• "Раскрывающиеся" свойства.
• Улучшена содержательная часть - свойства, которые подразумевают ввод свободного текста, например имя связанного объекта,  снабжены выпадающими списками, позволяющими выбрать значение из списка доступных. Такое решение уменьшает нагрузку на память пользователя.

Для сравнения - количество свойств у стандартного объекта "форма" - 52, методов -33, то есть в два раза меньше, чем в Visual FoxPro.

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

Как же можно сделать редактор свойств еще удобнее?

Я предлагаю три нововведения:

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

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

Во-вторых можно дополнительно запоминать для каждого объекта состояние всех иерархических свойств ("свернуто"/"развернуто").

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

Для этого можно делать следующее:

• Еще на этапе ввода выводить индикацию некорректности данного значения, например подсвечивая его красным цветом
• Предотвращать ввод некорректных значений (заменять символы локального алфавита латинскими там, где возможны только английские имена, заменять отрицательные числа на положительные там где возможны только такие и т.д.)

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

Вернуться в Колонку Автора