WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 21 | 22 || 24 | 25 |   ...   | 27 |

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

Всегда может оказаться, что желание клиента получить новую функцию обусловлено не реальной потребностью в ней, но собственно концепту альными проблемами системы. Системы же конкурентов страдают как от ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ такого же непонимания проблемы, так и от множества других причин. Это значит, что прислушиваться к сторонним требованиям к системе, безус ловно, следует, но рассматривать эти требования нужно не как директивы, но как признаки общего неблагополучия.

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

Не копируйте слепо интерфейс конкурентов. Зачем плодить убожество Так как всё таки определить нужную функциональность Современная наука выдвинула два основных способа, а именно анализ целей и анализ действий пользователей. Эти способы фактически не конфликтуют друг с другом, более того, в процессе определения функциональности желательно использовать оба.

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

Это значит, что сами по себе функции никому не нужны и не важны.

Людям нужно средство вообще, делающее возможным выполнять какую либо работу. Разницу подходов к выбору функциональности в такой системе удобно проиллюстрировать на примере тостера. Стандартный подход, при котором функции выбираются фактически произвольно, в лучшем случае приведет к такому заданию:

«Нужен ящик с узкой прямоугольной дыркой и нагревателем внутри» Анализ целей пользователя приведет к другой формулировке:

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

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

Результатом этого процесса должен являться список целей, например, для тостера финальный список целей должен выглядеть очень просто:

«Должен поджаривать мелкие предметы, преимущественно хлеб» И только.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ После того, как истинные цели пользователей установлены (и доказано, что таких пользователей достаточно много, чтобы оправдать создание системы), приходит время выбирать конкретный способ реализации функции, для чего используется второй метод.

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

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

Рис. 61. Пример явной пользы анализа действий пользователей. На рисунке изобра жены три способа индикации выделенного объекта в векторных иллюстративных программах. Помимо собственно индикации, те же самые элементы управления должны использоваться для изменения формы и размера объектов. Слева элемент управления, введенный в программах фирмы Corel. В программах Corel большие черные прямоугольники позволяют изменять размер выделенного элемента, малень кие же квадратики в углах треугольника (узловые точки), описывающие форму объекта, заблокированы. При выборе инструмента редактирования они разбло кируются и появляется возможность изменять форму объекта. В центре и справа – такой же элемент управления программы Macromedia Freehand. По умолчанию изменять размер невозможно, передвигая же узловые точки можно изменять форму объекта. Проблема в том, что изменять размеры объектов нужно гораздо чаще, нежели изменять их форму. Поэтому программы Corel в этом аспекте более произво дительны. Обнаружить же это можно только путем анализа действий пользователей.

Достоинства подхода Corel прекрасно понимают в Macromedia, но поскольку Freehand программа уже устоявшаяся, они не могут просто так скопировать стиль конкурента.

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

В сколько нибудь сложных интерактивных системах сами по себе выб ранные стратегии действий влияют на требования к функциональности.

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

Единственным выходом является банальное наблюдение за людьми, выполняющими свою задачу, пользуясь уже имеющимися инструментами, а именно системами конкурентов (если они есть) и предметами реального мира (поскольку очень немного новых действий появилось только после появления компьютеров). Неплохим источником материала для анализа часто служит даже не наблюдение за людьми, но анализ результатов их работы – если оказывается, что результат работы практически не зависит ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ от используемого инструмента, это значит, что нужна только та функцио нальность, которая оказала воздействие на результат (т.е. функции, которыми никто не воспользовался, не нужны).

Тут очень важно избежать эгоцентризма. Очень трудно отказаться от мысли «если это нужно мне, это нужно и многим». Возможно, что и нужно.

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

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

Поскольку на этом этапе мы узнаём, какая именно функциональность нужна для каждого варианта, можно избрать верный путь по правилу «чем меньше действий требуется от пользователя, тем лучше» (благо компьютер есть, прежде всего, великое средство автоматизации). Не стоит забывать и про другое правило: чем меньше функций, тем легче их сделать.

Существует два принципиально разных подхода к определению Низкоуровневые и высокоуровневые функциональности системы. При первом подходе система снабжается функции максимальным количеством функций, при этом результаты многих из них являются суммой результатов других функций. При другом подходе все составные функции (метафункции) из системы изымаются. Ярким представителем первого подхода является Corel PhotoPaint, не менее ярким представителем другого – Adobe PhotoShop.

Рис. 62. Окно программы PhotoPaint 9 со всеми интерфейсными элементами, которые можно вывести одновременно (многое не влезло). © Corel.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ Рис. 63. Окно программы PhotoShop 4, со всеми интерфейсными элементами (влезло всё). В последней версии PhotoShop появилось несколько новых элементов, так что сравнение не вполне корректно. Тем не менее, в последней версии PhotoShop «интерфейса» всё равно гораздо меньше. © Adobe.

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

Судя по всему, людям больше нравится пользоваться низкоуровневыми функциями, поскольку это позволяет добиваться более тонких и предсказуемых результатов. С другой стороны, доказательств этого не так уж много (сам факт того, что PhotoShop продается лучше, чем PhotoPaint, говорит не так уж о многом). Таким образом, выбор подхода не слишком прост. С другой стороны, остается возможность компромисса: всегда можно включить в систему средства автоматизации, чтобы пользователи получали возможность создавать (и распространять) свои метафункции, каковой подход как раз и применен в PhotoShop. Я полагаю, что это оптимальный подход.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ Этот этап либо происходит сам, либо не происходит вовсе. Предыдущие Прилив этапы дают достаточное представление о сущности создаваемой системы.

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

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

Возвратимся к многострадальному тостеру. Это очень простая система, поэтому для нее достаточно одного сценария.

«Виктор Х. отрезает кусок хлеба и кладет его в тостер. Он включает тостер и ждет, пока хлеб не поджарится» Но это просто, ради такого результата не стоит огород городить.

Обычно всё несколько сложнее. Предположим, что необходимо разработать сценарии для будущей почтовой программы. Судя по всему (я не анализировал действия пользователей, так что не уверен), для этой задачи необходимо три сценария:

А) Елизавета Бонифациевна запускает почтовую программу.

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

Б) Еремей Карапетович делает активным окно уже открытой почтовой программы и включает процесс скачивания новой почты. Получив почту, он ее читает. Одно сообщение он пересылает другому адресату, после чего удаляет его, а еще одно печатает. После чего переключается на другую задачу.

С) Пришло новое сообщение, и Джамиля Валериевна восприняла соответствующий индикатор. Она делает активным окно почтовой программы и открывает полученное сообщение. Она читает его, после чего перемещает его в другую папку. После чего переключается на другую задачу.

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ Итак, информация о будущей системе собрана. Теперь, пользуясь этой Проектирование информацией, необходимо создать общую структуру системы («вид с высо общей структуры ты птичьего полета»), т.е. выделить отдельные функциональные блоки и определить, как именно эти блоки связываются между собой. Под отдель ным функциональным блоком я понимаю функцию/группу функций, свя занных по назначению или области применения в случае программы и груп пу функций/фрагментов информационного наполнения в случае сайта1.

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

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

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

Перегружать же интерфейс опасно.

Pages:     | 1 |   ...   | 21 | 22 || 24 | 25 |   ...   | 27 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.