Поиск подходящего инструмента прототипирования (об этом мы достаточно подробно написали в предыдущем посте) занял у нас довольно много времени и… окончился ничем. Нам так и не удалось найти инструмент, который в полной мере покрывал бы все наши потребности. Похоже, что программы для прототипирования, полностью отвечающей всем нашим представлениям и пожеланиям, в природе просто не существовало… Единичные кандидаты были близки к победе, но в любом из них был какой-нибудь неприятный и неприемлемый для нас «нюанс», который не позволял честно и без кривляния душой сказать: «Это именно то, что мы искали». Конечно, можно было закрыть глаза и пойти на компромисы, но это не наш путь. Недосказанность — это то, чего мы очень не любим.
На этой почве мы приняли не самое лёгкое решение попробовать собственноручно воплотить все наши идеи в жизнь и создать свой инструмент прототипирования. Подспорьем для разработки нашего собственного продукта стали также результаты анализа перспектив рынка инструментов прототипирования: существовало решений немного и покрывали они не все требования IT-компаний (по крайней мере — нашей компании, ну а мы, стоит ли сомневаться, далеко не единственные в своём роде). Ещё одним ощутимым толчком являлась перспектива выпустить первый российский полноценный инструмент прототипирования. Вобщем, плюсов мы насчитали больше, чем минусов.
Создание собственного инструмента прототипирования началось не с чистого листа, а на основе… впрочем, историю создания нашего инструмента опишу ниже.
История
2005 год
Основной продукт компании АЛЕЕ Софтвер представляет собой корпоративную систему класса ERM (система управления электронными записями). Система состоит из двух тонких клиентов, через которые работают пользователи: десктопное приложение и веб. Веб-представление системы нередко требует кастомизации ее графического интерфейса под стандарты заказчика, а также под другие используемые им корпоративные информационные системы. Для выполнения этой задачи у нас родилась идея создать специальный инструмент — конструктор, с помощью которого можно было бы легко перестраивать графический интерфейс веб-составляющей системы. Предполагалось сделать его простым в использовании настолько, чтобы Заказчик своими силами смог кастомизировать интерфейс системы без написания программного кода и без привлечения сторонних специалистов. Так, ведомые этой идеей, мы начали экспериментальную работу по созданию подобного инструмента.
Мы планировали сделать конструктор составной частью системы. Естественно, в таком случае его следовало бы и написать на языке основной системы, т.е. на Java. Впоследствии, однако, стало ясно, что существовавшие на тот момент технологии и возможности Java поставленную задачу решить не позволяют. Почему? Во-первых, на проектах большого размера скорость интерпретации Java-классов в нативный код Java-машиной была слишком низкой; значительно замедлялась и скорость работы приложения. Во-вторых, в стандартной сборке JDK отсутствовали нативные компоненты различных операционных систем. Эту проблему можно решить путем привлечения дополнительных библиотек, но это было бы связано и с дополнительными сложностями. К тому же качество и цены нас не устраивали. В-третьих, в самом языке Java не было многих необходимых для создания нового инструмента средств, на тот момент уже реализованных во многих других языках программирования. Список проблем и ограничений можно продолжать, вдаваясь в глубокие подробности и мелкие детали, но речь не о том. В конце концов мы решили отложить планируемую разработку, что называется, до лучших времен. В результате проведённых работ были созданы экспериментальные наработки, применение которым на тот момент мы не нашли. А проблема кастомизации интерфейсов системы была решена другим способом.
В процессе разработки нами было создано запускаемое приложение, включавшее: область редактирования графического интерфейса, минимальный набор компонентов для тестирования графического редактора, отдельный фрейм для управления слоями и отдельный фрейм для настройки компонентов.
2006-2008
Около трёх лет наши экспериментальные наработки, как говорится, «лежали на полке» и терпеливо ждали своего часа.
2009
В определённый момент перед нашей компанией остро встал вопрос выбора инструмента прототипирования. Мы активно занялись поиском такового, о чём в подробностях повествует первая часть цикла. Именно в это время у нас родилась идея создания своего собственного инструмента прототипирования. И тут мы вспомнили про наши экспериментальные наработки: они подходили в качестве основы будущего инструмента наилучшим образом.
Началась активная разработка инструмента прототипирования, который впоследствии получил название GUI Machine.
Постановка требований
Осмыслив специфику стоявших перед нами задач и проанализировав имеющиеся на рынке продукты, мы четко сформулировали требования относительно качеств, которыми должен обладать наш инструмент прототипирования:
- возможность прототипирования как десктоп-, так и веб-приложений; не обязательно, но желательно — возможность прототипирования приложений для мобильных устройств;
- более высокая (по сравнению с существующими аналогами) степень интерактивности создаваемых прототипов, большой набор обрабатываемых событий и выполняемых действий;
- наличие большого набора готовых графических элементов, как платформно-зависимых (т.е. «подстраивающихся» под вид операционной системы и ее оформление), так и платформно-независимых. В этот набор должны входить элементы для десктоп-, веб- и мобильных приложений. Они должны быть максимально кастомизируемыми;
- высокая реалистичность создаваемых прототипов;
- возможность просмотра прототипов собственными средствами, без привлечения сторонних программных продуктов;
- простота освоения: инструмент должен быть таким, чтобы с его помощью смог создавать прототипы человек, вообще не обладающий навыками программирования;
- высокая скорость создания прототипов;
- кросс-платформенность (инструмент должен работать по крайней мере в основных операционных системах — Windows, Mac OS, Linux).
Способ разработки
Для разработки инструмента прототипирования мы использовали методику экстремального программирования (ХР). Этот выбор был обусловлен целым рядом причин. Во-первых, необходимо было создать инструмент как можно быстрее. ХР является подходящей методикой для решения задач оперативной разработки. Во-вторых, у нас не было фиксированных требований к создаваемому инструменту, все изменялось и дополнялось в процессе разработки. В-третьих, применение методов ХР обеспечивает минимальный риск получения на выходе не соответствующего требованиям инструмента.
Мы попытались адаптировать требования ХР под специфику нашей работы: так, в нашей команде был всего один программист, поэтому мы не пользовались приемами парного программирования и взаимной проверки кода.
Разработка осуществлялась в тесном взаимодействии программиста, менеджера проекта и будущих пользователей системы. Работа над программой велась в быстром темпе: изменения в исходный вариант вносились ежедневно (а иногда — даже несколько раз в день). На начальных этапах работы мы намеренно не уделяли повышенного внимания вопросам дизайна, что позволило максимально сосредоточится на реализации функционала, а также избежать задержек.
2010
Работу по созданию собственного инструмента прототипирования мы начали 22 ноября 2009 года. Уже в мае 2010, задолго до выпуска релизной версии, надежность и функциональность продукта достигли такого уровня, что он был успешно опробован на реальном проекте компании. Этот факт, кстати, стал еще одним свидетельством того, что мы сделали правильный выбор, обратившись к экстремальному программированию.
Эксплуатация продукта
Замечу, что изначально мы не ставили перед собой цель выпустить собственный инструмент прототипирования на рынок, а планировали использовать его исключительно для проектов компании. Так, 2010 год ознаменовался рядом проектов, при реализации которых использовался наш инструмент. Ниже приведу пару примеров.
Разработка веб-интерфейса CRM системы
Впервые инструмент был использован для разработки прототипа веб-интерфейса CRM системы (Customer Relationship Management System — система управления взаимодействием с клиентами) — сложной системы корпоративного уровня. Основой для него была существовавшая десктопная CRM система (внутренняя разработка компании).
Для того, чтобы заказчик мог увидеть интерфейс будущей системы и высказать свои пожелания еще до фактического начала разработки, был создан его высокоточный и интерактивный прототип. Он адекватно и реалистично представлял как дизайн, так и функциональность системы:
Разработка внутрикорпоративного портала
Инструмент был использован для создания прототипа внутрикорпоративного портала нашей компании. В этом проекте не было строгих ограничений по срокам, дизайну и функциональности. Таким образом, специалист, разрабатывавший этот прототип, имел большую свободу действий. Созданный прототип был полностью интерактивным и обладал красивым дизайном:
Промышленная эксплуатация инструмента показала состоятельность инструмента, способность его успешно решать возложенные на него задачи. Получив такие результаты, было решено доработать и выпустить инструмент на рынок программного обеспечения.
1 декабря 2010 года была выпущена релизная версия продукта.
2011
24 января 2011 года мы провели семинар «Проблемы и решения проектирования и прототипирования графических пользовательских интерфейсов», на котором впервые был представлен разработанный нами инструмент под названием GUI Machine.
Что получилось?
Результатом нашей работы стал продукт, получивший название GUI Machine. К числу несомненных плюсов продукта мы относим:
- возможность прототипирования как веб, так и десктоп-приложений;
- высокую интерактивность создаваемых прототипов;
- высокую визуальную точность и эстетическую привлекательность создаваемых прототипов;
- простоту освоения и работы в инструменте: GUI Machine могут использовать в своей работе не только и не столько программисты, но и менеджеры, аналитики, осуществляющие взаимодействие с клиентом, и даже сами клиенты;
- высокую скорость создания прототипирования;
- кросс-платформенность: работает на Windows, MacOS и Linux;
- полную русскую локализацию продукта (интерфейс продукта, руководство пользователя на русском языке) и русскоязычную поддержку (обучение, консультации).
Было бы нечестно указывать лишь на плюсы. Конечно же, у нашего продукта тоже есть свои минусы и недостатки:
- пока нет возможности полноценной совместной работы над прототипом;
- пока нет возможности генерации спецификации на основе прототипа;
- пока отсутствуют компоненты для прототипирования приложений для мобильных ОС;
- пока нет инструментов рисования UML-диаграмм;
- инструмент достаточно требовательный.
Почему во многих пунктах фигурирует слово «пока»? Дело в том, что сейчас мы динамично развиваемся, расширяем функциональность инструмента и, конечно, планируем избавиться от перечисленных недостатков.
P.S.
Мы не питаем иллюзий и не считаем GUI Machine панацеей, позволяющей решать любые задачи лучше всех. Однако для тех, кто в поисках подходящего инструмента прототипирования столкнулся с проблемами, подобными описанным нами, наш инструмент, вероятно, окажется весьма и весьма полезным.
UPD: В следующей статье цикла будет представлен подробный обзор инструмента прототипирования GUI Machine
