Блог NunDesign

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

1. Правильный интерфейс - это функциональный интерфейс. В таких командах главный упор делается на продуманный механизм разрабатываемого проекта, на идеальный движок, все силы уходят на то, чтобы ядро было безупречным, чтобы (web или windows) приложение работало без сбоев при любой нагрузке, чтобы максимально полно и качественно реализовать затребованные заказчиком функции и сделать доступными управление этими функциями из интерфейса приложения. И складывается так, что для разработки этого приложения (или ряда приложений) привлекаются лучшие, высокооплачиваемые специалисты-разработчики, аналитики и программисты. Такие факторы, как удобство пользования этим приложением или уж тем более красота интерфейса, считаются вторичными, это приводит к тому, что и специалисты подбираются уже менее тщательно, команда специалистов незначительна по сравнению с командой программистов (обычно вообще один-два человека, иногда даже удалённых). Функциональность реализована, но пользоваться ею неудобно, а о визуальной привлекательности лучше не вспоминать.
2. Правильный интерфейс - это удобный интерфейс. Забота о пользователе ставится во главу угла (я не говорю о том, что это не правильно). Для разработки привлекаются талантливые информационные архитекторы, проектировщики взаимодействия, специалисты по юзабилити-тестированию, удивительно, но факт: в команде на пять программистов - семь ответственных талантливейших человек, отвечающих за создание правильного интерфейса + привлечённые для тестирования (эмуляция целевой аудитории) люди. Работу свою они выполняют качественно, приложение получается на самом деле с интуитивно понятным интерфейсом, удобное в использовании, только вот группа разработчиков подводит - то у них база падает при увеличении нагрузки, то кнопка нажимается через раз, да и сама функциональность не достаточно продумана и реализована поверхностно, хотя другие разработчики из этой же темы давно уже ушли на порядок вперёд. Удобно, но не функционально и не привлекательно.
3. Правильный интерфейс - это красивый интерфейс. В последнее время приходилось анализировать большое количество как виндовых программ, так и веб сервисов, встречались среди них примеры с на самом деле привлекательным, талантливо исполненным интерфейсом - очень эффектные веб сайты, необычайно и привлекательно отрисованные формы программ, с гармонично подобранными цветовыми гаммами и потрясающей графикой. Честно говоря, ни одно из них не осталось под руками в работе, отношение к ним осталось, как к миленьким игрушкам, которые стоило запустить, чтобы посмотреть, что там у нас рисуют западные прогрессивные разработчики, полюбоваться и забыть навсегда ввиду абсолютной непрактичности приложения. Не говорила бы об этом примере, если бы не сталкивалась. В такой ситуации разработка приложения в целом - это постоянное дорисовывание и перерисовывание интерфейса, его элементов, в процессе разработки делается 50 вариантов эскизов и на ежедневных митингах с руководством 90% времени - это обсуждение того, почему у этой иконочки “вот видите? зубчик на скруглении неаккуратный”, а “вот эта панелечка на один пиксель левее остальных”, и такое прочее. Команда же программеров чувствует себя изгоями - они не получают чёткую постановку задачи, им не дают технических возможностей реализовать всё достаточно правильно, им не дают человеко-ресурсов (когда в команде пару человек более-менее грамотные, остальные 10-15 - новички типа студенты), и даже времени на правильную реализацию.Типичный пример: так, ребятки, нам для послезавтрашней презентации сделайте быстро и красиво первую, пилотную версию (делают, что успевают, но к презентации версию предоставляют). А потом после презентации попытки объяснить руководству, что этот прототип был сделан в спешке на скорую руку, и для правильной реализации дайте же нам две недели! Две недели не дают, говорят, что функциональность устраивает, но через месяц разработки, когда костыли под костылями уже не удерживают конструкцию, удивляются и оскорбляются - что вы, мол, возитесь, и почему у вас всё время ничего не работает! Работает, но кое-как. В подобных ситуациях зачастую: красиво, но неудобно и не функционально.

Недооценка важности какого-то этапа, или низкие критерии качества любой части процесса разработки встречаются часто и в большинстве случаев снижают качество работы в целом, иногда - обесценивают (и я была свидетелем того, как закрывались практически готовые, разработанные проекты ввиду их полной коммерческой нецелесообразности при данной реализации, а бюджета на полную переделку уже не было). Часто это приводит к безграмотному использованию человеческих ресурсов. Я встречала, к примеру, в целом неплохую команду разработчиков (что-то около 40 программеров, большей частью веб-сервисы) - и на всю команду ВООБЩЕ ни одного дизайнера, ВООБЩЕ ни одного грамотного верстальщика. Помню, сколько времени талантливый дотнетчик тратил на то, чтобы хоть как-то причесать интерфейс, по ходу разбираясь с тонкостями вёрстки, с html и css и консультируясь по поводу подбора цветов для оформления интерфейса и элементов интерфейса. И это в то время, когда гораздо рациональнее и для конторы в целом выгоднее, если бы он писал только свой движок - но у конторы некому поручить эту работу, а тот удалённо сотрудничающий с ними индус, который рисует им эскизы для интерфейсов (дико уродские, честно-честно) и потом их “режет” в базовую html вёрстку (адаптацией вёрстки в движок он никогда не занимался и поэтому понятия не имеет, отчего матерятся программеры и после его трудов полностью перевёрстывают полученный макет).

Многие этапы разработки производятся в результате спонтанно, случайным образом, как получится. И программисты могут привести множество примеров такой разработки, когда на поставленную задачу один говорит “я слышал, это можно сделать так-то”, второй - “этот механизм я когда-то [в другой ситуации] делал так-то”, но в целом не хватает ни опыта, ни знаний для того, чтобы выбрать на самом деле правильное решение. И по отношению к правильным интерфейсам - в большинстве компаний интерфейсы разрабатываются на основе интуиции, существующего опыта (как опыта разработчика интерфейсов, так и опыта пользования различными интерфейсами) и на основе здравого смысла (а, правильнее сказать, того видения “здравости”, которое наличествует у разработчиков на данный момент времени). И хорошо, если в компании осознают целесообразность привлечения профессионалов для тех или иных этапов разработки, и могут обосновать эту целесообразность, но уж больно часто на предложение, мол пусть эту работу выполняет специалист в соответствующей отрасли, руководство смотрит удивлённо и неодобрительно: А ЗАЧЕМ?

Приведу цитату (скопировано из раздела “советы” на сайте Артёма Горбунова):

Все физические проявления хорошего интерфейса эстетичны — экраны, текстовый набор, иллюстрации и визуализации. Плохой интерфейс уродлив.
[Тафти, Рудер, Херлберт, Мюллер-Брокман, Брингхерст и другие...]

Что представляет проектная матрица

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

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

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

Деятельность при анализе

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

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

• исследование;
• разработка модели;
• интеграция;
• просмотр.

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

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

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

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

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

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

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

Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, - это разработка модели, вериикация взаимных действий, интеграция и просмотр.

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

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

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

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

Интеграция. Как только модели состояний и модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.

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

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

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

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

—
* ДПДД - Action data flow diagram - диаграмма потоков данных действий.

—
Источник: Объектно-ориентированный анализ: моделирование мира в состояниях.
Авторы: Салли Шлеер, Стефан Меллор
Книга издана в 1993-м году, на счёт переизданий - не в курсе; посвяцена изложению самых первых этапов процесса разработки сложных (программных, технических и других) систем.