26 августа 2010 г.



Интерфейс пользователя Eclipse: порция критики

Я долго работал (и продолжаю работать) с платформой Eclipse RCP. В целом - платформа безусловно хороша для java-разработчика. Без шума и пыли мы получаем готовый каркас приложения прямо «из коробки», а также развитый API для создания гибкого полноценного desktop-приложения. Конечно, есть в этой платформе свои недостатки. В том числе, обусловленные слишком модульной и гибкой архитектурой. 

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


Вспомним, что представляет собой типичный интерфейс приложения построенного на базе Eclipse RCP.

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

1. Пользователь вынужден знать что такое проекция и помнить какая из проекций отвечает за решение его текущей задачи. Другими словами - пользователь вынужден думать на языке приложения, а не на языке прикладной области

(Тут многие могут сказать, что я преувеличиваю. Но я считаю, что если критиковать - то делать это по максимуму)

Как говорится в известной книге признанного гуру юзабилити Стива Круга: «Не заставляйте ваших пользователей думать!». Конечно, это не значит, что надо разрабатывать интерфейс, которым сможет пользоваться даже умалишенный. Это значит, что у пользователя есть конкретная задача, для которой он открыл ваше приложение. И пускай лучше думает о ней, нежели о проекциях и о том, что же ему выбрать чтобы все-таки начать работать.

Более того, конкретная задача пользователя сформулирована на его языке. И, как правило, в этом языке нету места для «проекций», «перспектив», «плагинов» и прочего барахла.

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

----------------

Рисунок 1
Продолжим. Как видно на рисунке 1, главное окно приложения, как правило, разбито на несколько областей. В терминологии Eclipse эти области называются фолдерами (folders). Таким образом, при создании проекции мы задаем сколько у нее будет фолдеров, где они будут размещаться и какого они будут размера. Кроме этого, мы определяем на проекции места, где будут открываться наши редакторы и панели (view).

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

Вот тут и стоит проявить осторожность и вспомнить здравый смысл. Если приложение достаточно сложное, то панелей у пользователя может накопиться великое множество. Чтобы не быть голословным, приведу пример из реального ERP приложения. Проекция предназначена для работы с заказами кухонной мебели. Одновременно пользователь видит: 
  • панель со списком всех заказов
  • открытый заказ в редакторе
  • панель со свойствами выделенного в редакторе продукта
  • панель для показа схематических изображений
  • панель для быстрого перемещения по заказу (outline). 
Т.к. один заказ связан с одной кухней, то дополнительно имеем:
  • панель для задания параметров комнаты
  • панель для визуального добавления и размещения мебели по комнате
  • панель с трехмерной моделью получившейся кухни
И это еще не все, ведь заказ нужно направить в производство и после этого отгрузить клиентам. Поэтому еще пользователь видит:
  • панель со списком объектов для производства
  • панель со списком запланированных отгрузок
Думаю, не нужно доказывать что это - много. И ведь ничего не выкинешь, все это нужно иметь под рукой. Все эти бесчисленные панели располагаются в созданных фолдерах одна за другой. Т.е. в один момент будет открыто 3-5 панелей, а другие будут неактивны, скрыты. Таким образом, для решения задачи приходится между ними постоянно переключаться. Вот тут и натыкаемся на проблему:

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

Не очень хорошее положение дел, не так ли? Хорошо, если пользователь обладает хорошей концентрацией и не работает при этом на атомной станции :) Но, в подавляющем большинстве случаев дела обстоят совсем наоборот: пользователи невнимательны, их легко отвлечь на что-нибудь другое. А ведь еще есть аська, почтовый клиент, последние новости по RSS и прочее. Зачем же нам отвлекать пользователя еще больше внутри своего приложения? Попробуем найти выход.

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

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

Результат, к которому надо стремиться, это избавление пользователя от необходимости переключаться между панелями. Лучше всего заботиться об этом заранее, при проектировании. Как только у вас появилось желание создать очередную панель - задумайтесь, нужна ли она. Или ее можно совместить с уже существующей панелью.

--------------------

Далее. По ходу работы пользователю мало смотреть на данные, нужно совершать какие-то операции с ним. Логично, что операции будут представлены с помощью команд панели инструментов или меню (actions). 

У приложения есть главная панель инструментов с общими командами, есть главное и  контекстное меню. Конечно же, набор команд может зависеть от контекста текущей задачи: от открытой в данный момент проекции или редактора. Инфраструктура рабочей области приложения (workbench) дает возможность сделать появление контекстно-зависимых команд в главной панели инструментов динамическим. Т.е. они то появляются, то исчезают в зависимости от открытия и закрытия редактора.

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

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

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

Выход из такой ситуации есть и он уже применен в Eclipse. Это команды панелей (view actions). Они располагаются в специальной области самой панели, т.е. в поле зрения пользователя при работе с данной панелью. Также кнопки размещаются на одних и тех же местах в пределах панели, что тоже немаловажно.

--------------------

И последнее. Как возражение написанному выше можно сказать, что Eclipse RCP - это платформа для создания приложений уровня предприятия (enterprise). И, мол, корпоративные пользователи хорошо знают свою работу и быстро научатся работать со сколь угодно сложным интерфейсом. Это не так! И мы у себя в компании уже успели в этом убедиться.

4. Если пользователю неудобно/непонятно/неприятно работать с приложением - он сделает все чтобы с ним не работать и/или работать с другими, возможно морально устаревшими, инструментами.

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

Подводя итоги: будьте аккуратнее и не рубите с плеча. И, конечно же, не заставляйте ваших пользователей думать!


Полезные ссылки:






Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий