История создания инструмента прототипирования. Часть II


    Поиск подходящего инструмента прототипирования (об этом мы достаточно подробно написали в предыдущем посте) занял у нас довольно много времени и… окончился ничем. Нам так и не удалось найти инструмент, который в полной мере покрывал бы все наши потребности. Похоже, что программы для прототипирования, полностью отвечающей всем нашим представлениям и пожеланиям, в природе просто не существовало… Единичные кандидаты были близки к победе, но в любом из них был какой-нибудь неприятный и неприемлемый для нас «нюанс», который не позволял честно и без кривляния душой сказать: «Это именно то, что мы искали». Конечно, можно было закрыть глаза и пойти на компромисы, но это не наш путь. Недосказанность — это то, чего мы очень не любим.

    На этой почве мы приняли не самое лёгкое решение попробовать собственноручно воплотить все наши идеи в жизнь и создать свой инструмент прототипирования. Подспорьем для разработки нашего собственного продукта стали также результаты анализа перспектив рынка инструментов прототипирования: существовало решений немного и покрывали они не все требования 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
    ALEE Software
    38,60
    ПО стандартизации и управления качеством
    Поделиться публикацией

    Комментарии 38

      0
      Зачем менеджерам, аналитикам и, прости господи, клиентам интерфейсы прототипировать? Вряд ли у них без специфических знаний что-то хорошее получится, даже если их научат использовать конкретный инструмент. Ведь если у человека есть зеркалка и он умеет на ней кнопочки нажимать, то это совсем не значит, что он — фотограф.
        +1
        Юля, вопрос правильный и мы его себе, конечно же, не один раз задавали. Ответ нашли, как всегда на рынке, анализируя опыт зарубежных конкурентов, которые и начали раньше и клиенты у которых более продвинуты. Вот видео доклада Синтия Бакани — менеджера по дизайну и юзабилити, Citi Cards (Сити Груп) www.youtube.com/watch?v=5A3wtNxbw2Y Она рассказывает с какими трудностями они как заказчики сталкивались в процессе разработки своих продуктов силами внешних разработчиков, в том числе и удаленных.

        Есть еще один факт, добытый в общении с крупными российскими аутсорсерами, у них в обойме инструментов не один, а несколько разных сред протитипирования: и iRise, и Axure и GUI Design Studio, т.к. каждый крупный заказчик приходит со своими требованиями к инструментарию и если ты хочешь на него работать, то придется прикупить соответствующую лицензию.

        С менеджерами и аналитиками вопрос отдельный. Сравним два форума аналитиков: российский www.uml2.ru/forum/ и беларусский analyst.by/forum/ В обоих присутствуют разделы по проектированию интерфейсов, правда белорусские коллеги продвинулись дальше, видать экспорториентированность (ИТ, а не энергоресурсы) их экономики, заставляет их шевелиться активнее.
          0
          Вы так и не ответили: зачем поручать дизайн (в оригинальном смысле этого слова) людям, которые на нём не специализируются?

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

            p.s. а в чём проблема сделать «эту кнопочку снизу, а фон зелёным», если бухгалтеру так удобнее? Прототип как раз призван выявить эти нюансы ещё до начала разработки, на стадии проектирования, чтобы не пришлось переделывать программу уже после реализации
          +3
          А вот вопрос: какие «специфические знания» с вашей точки зрения необходимы? Насколько я помню, был у нас как-бы веб-дизайнер. С кнопочками как раз у нее все было хорошо, и с CSS тоже неплохо, а вот с дизайном интерфейса никак. А именно был проект, по которому надо было старую CRM систему перевести на новые технологии и с расширением функционала, интерфейс планировался — веб вместо java-приложения (десктоп). Максимум, что сделал веб-дизайнер, так это задал цветовую гамму и стиль шрифта. Вся компоновка (по-моему, порядка 29 составных экранов, каждый из которых делится еще на несколько более простых, и таким образом более сотни кранов) была произведена менеджером, а не веб-дизайнером, который показал полную несостоятельность в данном вопросе. Оно и понятно, если мы говорим об интерфейсах сложных приложений (простенькие или представительские веб-сайты я не беру в рассмотрение и надеюсь автор комментария не их имел в виду), так как дело не в эстетике, не в цветовой палитре, а в компоновке элементов интерфейса, в удобстве расположения функциональных элементов, которые пляшут от требуемой функциональности, от специфики и стиля работы пользователя, от его требований и т.д. А с этим как раз работает менеджер (или аналитик, или… не важно как этот человек в каждой компании называется), тот, кто бок о бок работает с клиентом, практически живет в его компании, ощущает эту компанию. Передать это невозможно, а таскать дизайнера — глупо, так так тогда надо таскать пол команды.

          Поэтому на практике мы выработали следующий подход: структуру интерфейса, элементы, отклики и пр. создает менеджер плотно работающий с клиентом на проекте. Эти интерфейсы отдаются дизайнеру (в компании есть дизайнер и есть верстальщик, это разные люди), который достаточно быстро стилизует интерфейсы, можно в той же программе. Если интерфейсы приняты и уже не требуют изменений, переходим к реализации — подключению к системе, здесь работает верстальщик и отчасти программист. Что мы выигрываем: время и терпение клиента (а это не мало, особенно на больших проектах), качество интерфейса, собственно время менеджера (как ни странно — объяснять по несколько раз дизайнеру, потом показывать клиенту, потом опят объяснять дизайнеру, потом опять клиент, снова дизайнер, клиент… и т.д. — это значительно больше, чем по указанной выше схеме), общее время, скорость разработки. Кстати про CRM: клиент был очень доволен интерфейсами, и все они были приняты с минимальными корректировками.
            0
            Такой человек обычно называется UI/UX designer он и занимается проектированием интерфейса, часто в паре с аналитиком.
              0
              По идее это так, но что на практике?
                0
                В моей практике обычно так и происходит. Разве что аналитика часто нет — выполняю и его функции. Если совсем всё плохо/небольшой проект/бюджет/самому интересно, то и дизайном элементов сам занимаюсь (стили, оформление).
                  0
                  Думаю, аналогично тому как Вы занимаетесь работой дизайнера/аналитика на некоторых проектах — в небольших фирмах достаточно квалифицированные и неглупые менеджеры/аналитики могут заниматься созданием прототипов. Тем более, что в фирме может быть дизайнер/менеджер, но не быть UI/UX специалиста.
                  Ну это лично мое имхо
                    0
                    В компаниях (даже довольно крупных, ~200 сотрудников) которые ещё не осознали необходимость специалистов-проектировщиков, разработкой прототипов занимаются аналитики. Крайне редко менеджеры (судя по моему опыту).

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

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

          Зачем реально ресайзить колонку, если без комментария заказчик даже не подумает её таскать.
          то же с сортировкой, зачем реальная сортировка без описания по какому принципу она строится и без явного обозначения что такой функционал есть.
          опять же сворачивание-разворачивание блоков, действия абсолютно неявные, особенно для неопытных пользователей.
          Я бы добрую часть функционала не заметил и засыпал бы вас вопсросами, а в ответ вы бы писали — а кликни правой кнопкой мыши туда (+скриншот).
          Обязательно добавьте комментирование всех возможных действий и их описание. А вообще, конечно здорово смотрится, хоть используй для сайтов визиток как CMS.

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

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

            Это лишь один частный пример — у обоих вариантов есть и плюсы и минусы, о которых неоднократно писалось в различных источниках, поэтому, мне кажется, здесь все совсем неоднозначно.
              +1
              согласен на 100%, возможны разные взгляды и подходы, они как правило зависят от способа взаимодействия с заказчиком и процесса разработки.
                0
                А способ взаимодействия с заказчиком и процесса разработки может быть абсолютно разным у разных фирм. Так как мы исходно ориентировались на свою и знакомые нам фирмы — возможно их специфика сыграла свою роль и видоизменила некоторый функционал и исходную идею.

                Впрочем, раз мы рассчитываем продвигать продукт в «широкие массы» — непременно исправимся и подкорректируем все возникшие несоответствия.
              +2
              Не согласен с тем, что прототип должен быть схематичным всегда. На мой взгляд, требуемая степень детализации (достоверности, точности) прототипа всегда зависит от конкретного проекта, конкретного заказчика, его пожеланий и требований.
              В первом примере мы имели дело с заказчиком, очень требовательным к интерфейсу. Схематичное расположение элементов и функциональных блоков мы зарисовывали на бумаги, после чего на их основе делали точный детализированный прототип именно по требованию заказчика. Что и как должно работать детально обсуждалось (совместно с заказчиком) и опять же записывалось на бумаге. Так что ситуаций, в которых заказчик не знает, куда нажать, у нас не было. Да и прототип мы показывали ему своими руками.
              Хотя, конечно, в большинстве случаев работа с заказчиком идёт удалённо, поэтому полностью согласен с Вашим замечанием относительно необходимости заметок. Вообще говоря, эта функциональность уже есть в планах развития инструмента
              +3
              Что-то мне ваш логотип напоминает:

              habreffect.ru/files/f95/399a20d0b/gui.jpg
                +2
                Вы не первый, кто нам об этом говорит :)
                Однако, наш дизайнер, создавший логотип, не знал про эту игру и никогда её ранее не видел.
                У дизайнеров мысли сходятся
                  0
                  Вы же понимаете, насколько это невозможно? — кругляшки туловища и хвостика абсолютно идентичны: палитра, градиент, диаметры; и даже ножка хвостика с едва заметным трапециевидным сужением.
                    0
                    Предлагаете прилюдно казнить нашего дизайнера?)
                    Мы уже пытали её на тему заигрывалась ли она в WorldOfGoo, но расколоть так и не удалось.

                    На самом деле, похожа только идея головы, как мне кажется…
                    Впрочем это всё слишком высокие материи, так что я не буду спорить на эту тему.
                      0
                      Ну что вы! Не нужно никого казнить. Мало ли, как бывает. Наверное, это не главное в инструменте — сейчас потестим и будет что обсудить.
                      +1
                      «Кругляшки туловища и хвостика абсолютно идентичны» — это потому что я наложил мордашку из ВорлдОфГуу на логотип Гуи Машин.
                        0
                        Ну вот! А я-то сразу плохое подумал! )
                          0
                          Хех, а я то еще подумал, не имели ли Вы ввиду ту самую картинку… Ну не может же быть… ;)
                        0
                        Совершенно невозможно, чтобы моя коллега, глядя мне в глаза, врала о том, что не видела ранее эту игру…

                        я верю в людей и их честность :)
                      +1
                      Игрулину мы, конечно, заметили, но уже после того, как порешили с лого… В любом случае, связи тут особо никакой нет. Может в будущем найдем что поуникальнее ;)
                        0
                        Однозначно прослеживается характерный глазной гипертелоризм, округлость и идентичная радиальная градиента брюшного и хвостового отделов. С моей точки зрения обе особи — ближайшие родственники, но Гуй Машин выглядит умнее, причем значительно.
                        +1
                        А рассказать про то как проектировали интерфейс своего инструмента прототипирования можете?

                        Учитывали ли вы опыт конкурентов? Какие вы выделяете в интерфейсе своей программы преимущества, какие недостатки?
                          0
                          Можем и расскажем, но уже в детальном обзоре самого продукта, который мы вскоре разместим.
                          0
                          Посмотрел на сайте стоимость и немного удивился: 599 евро за лицензию на одного юзера — не дороговато ли?
                          Вообще-то Expression Studio 4 Ultimate стоит 599 долларов.
                            0
                            Станислав, не могли бы вы перечислить ограничения демо-версии?
                              0
                              Основным ограничением демо-версии является отсутствие возможности сохранения проектов.

                              В скором времени с обзором продукта мы выложим здесь уникальные двухмесячные тестовые тестовые лицензии, дающие доступ ко всей функциональности продукта.
                                0
                                P.S. Я, конечно, не Станислав но лучше осведомлен в данном вопросе ;)
                                  0
                                  Это не очень хорошо. Чтобы попробовать инструмент в работе нужно поработать в нем несколько дней хотя бы, сделать что-то функциональное.
                                    0
                                    Именно поэтому сы сейчас немного изменяем и вскоре представим на всеобщий суд демо-лицензии.
                                      0
                                      Вариантов много, например, не закрывать приложение. Если серьезно, мы предоставляем несколько способов вполне легального использования полноценных лицензий, с ними можно ознакомиться на сайте, кроме того, готовы совешенно бесплатно оживить присланный вами интерфейс в целях демонстрации возможностей продукта.

                                      Ценовая же политика — это вообще предмет отдельного разговора. На предложения о высокой стомости, я спрашиваю, а за сколько бы вы купили этот продукт прямо сейчас?
                                  0
                                  Поясню, что под «готовы совешенно бесплатно оживить присланный вами интерфейс» имеется в виду то, что мы можем отрисовать Ваш проект по предоставленным Вами данным в GUI Machine и предоставить готовый проект Вам :)

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

                                    Самое читаемое