Требования к GUI — собираем, проектируем, рисуем




Главная   Форумы   Методики визуализации и моделирования в бизнес-анализе   Требования к GUI — собираем, проектируем, рисуем

В теме 11 ответов, и 7 участников, последнее обновление сделано пользователем Аватар (Рустем Гайфутдинов) Рустем Гайфутдинов 5 г, 9 мес. назад.

Показано 11 ответов - от 1 до 11 (всего 11)
  • Автор
    Сообщения
  • 31.01.2011 в 17:47 # 5439
    Аватар (Maria)
    Maria
    Подписчик
    Всем привет

    Дорогие аналитики, как вы ведете требования к GUI? В чем рисуете (axure хорошо, а что если проектируется не web site)?
    Как проектируетеописываете usability? Как описываете работу приложения с устройствами ввода (что, если кроме клавиатуры есть другие)?

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

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

    Гуру, какие есть идеи?

    И с почином меня, что ли, первое сообщение на форуме, принимайте в свое аналитическое сообщество :)

    Поделиться:

    Цитировать

    31.01.2011 в 23:01 # 5440
    Аватар (Yuliya Shamrei)
    Юлия Шамрей
    Участник
    Привет :) Мое мнение ниже.

    Дорогие аналитики, как вы ведете требования к GUI?

    Маша, исходя из текущих реалий твоего места работы у тебя есть как минимум 3 варианта:

    Borland Caliber RM. При создании проекта в Caliber RM (да и после тоже :) ) можно указать/запросить, какие именно типы требований тебе нужно вести и среди них есть тип "GUI Requirements". Требования этого типа затем можно трейсить на страницы, функции, кнопки и пр.

    Atlassian Confluence. В проектном спейсе можно создать отдельную ветку для GUI требований и трейсить их на страницы, кнопки и пр. с помощью входящих/исходящих гиперссылок.

    MS Word + SharePoint/SVN.Рекомендую для GUI сделать отдельный документ/раздел в общем документе и трейсить на другие требования кросс-линками и объектами.

    Из моего опыта очень важно, чтобы разработчики знали GUI требования как Отче Наш, т.к. недостаток функциональности иногда можно скрыть/обыграть :oops: , а кривой интерфейс очень сложно. Встречают по одежке :)

    Что касается структуризации GUI требований. Я обычно делаю общий раздел, куда выношу общие GUI требования (например, основной шрифт/цвет), требования к элементам интерфейса, которые есть на большинстве форм и т.д. Требования из этого раздела трейшу скопом на каждую страницу/форму. Если есть частные требования (специфичные какой-то одной странице/форме или кнопке, например), то описываю их отдельно, ну и трейшу на соответствующее требование.

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

    В чем рисуете (axure хорошо, а что если проектируется не web site)?

    В Axure можно проектировать не только веб сайты :wink: Как варианты: Balsamiq Mocups, Visio.

    Как проектируетеописываете usability?

    Уточни, пожалуйста вопрос. Т.к. Usability, ИМХО это интерфейс+функциональности+быстродейстие. Т.е. это GUI требования+пользовательские/функциональные требования+критерии качества.
    Вот тутесть интересные мысли по поводу проектирования UX.

    Как описываете работу приложения с устройствами ввода (что, если кроме клавиатуры есть другие)?

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

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

    Для этого там есть динамические панели и возможность настраивать/писать "скрипты". На пальцах сложно объяснить :) Попроси кого-нибудь из коллег показать (вроде есть группа рассылка на аналитиков в Itransition), думаю с радостью помогут. :)

    Поделиться:

    Цитировать

    01.02.2011 в 11:19 # 5441
    Аватар (Belle Morte)
    Belle Morte
    Админ
    Добрый день, Мария, и добро пожаловать в наше аналитическое сообщество! :)

    Хочу добавить немного к ответу Essence. Во-первых, касательно инструментов: самый главный критерий при выборе — это чтобы с инструментом было удобно работать лично вам. Кому-то удобно рисовать в Photoshop, кто-то вообще использует PowerPoint или даже Excel. Я пробовала разные инструменты, но всегда возвращалась к Visio. Основная причина, пожалуй, в том, что там я могу нарисовать в общем-то любой, самый извращенный контрол, за считанные минуты, не задаваясь вопросом «а как я это сделаю». Как найти свой инструмент? Это наверное тот самый случай, когда ответ «путем проб и ошибок». Можно почитать обзоры на нашем сайте, можно пообщаться с теми, кто регулярно юзает определенный инструмент. Но главное самому попробовать разок и прочувствовать, что он может и чего не может.

    Во-вторых, меня очень заинтересовал ваш проект. Если не секрет, расскажите пожалуйста, а проектированием пульта тоже занимаетесь вы (размеры пульта и кнопок, цвет, материал, функции и т.д.)? Что касается описания требований, пожалуй, я бы вынесла их в отдельный раздел («Аппаратные интерфейсы» или что-то вроде этого).

    В-третьих, был у меня заказчик, который не любил читать. Он говорил открытым текстом, что длинные спецификации не осилит. В таком случае я вижу два варианта решения:
    1. Создается динамический прототип. Такие прототипы говорят сами за себя, вам не нужно описывать навигацию и поведение элементов управления: как правило, все довольно прозрачно. Минус: часто на его создание требуется сравнительно много времени.
    2. Создается документ, посвященный исключительно GUI. В случаях с заказчиками, которые любят смотреть и не любят читать, делаю так: рисую site map (или схему навигации, если речь о десктопном приложении), отдельно каждый скрин, и на каждой станице документа делаю пометки (на рисунке — цифра, на полях — короткий комментарий). На выходе имеем pdf-документ. покрывающий статическую составляющую. Для того, чтобы проработать динамику (этот аспект чертовски важен, ибо помогает проверить, что ничего не было упущено) рисуется Use Case-диаграмма и подробно описываются варианты использования (шаблон описания можно взять отсюда http://analyst.by/forum/dokumentaciya/shablon-use-casov).
    Правда, следует отметить, что для разработки может потребоваться (и часто требуется) более полноценная спецификация (см. дискуссию на эту тему http://analyst.by/forum/dokumentaciya/mozhno-li-oboitis-use-caseami). Для того, чтобы не пугать заказчика большой порцией информации, можно отправлять ему на аппрув отдельные куски (например, только бизнес-требования, или диаграмму активностей). В спецификацию же войдет все, что удалось собрать.

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

    Что касается проектирования юзабилити… В двух словах тут, пожалуй, трудновато все описать. Я стараюсь на всех этапах подготовки требований держать в голове правило «Keep it simple». Как только я вижу, что какой-то юз кейс разрастается на слишком много шагов, или на скрине оказывается так много кнопок, что не сразу можно понять, какую функцию выполняет каждая, я останавливаюсь и задаю себе вопрос: «что можно сделать, чтобы процесс стал проще/удобнее/понятнее?». При добавлении новой функции, нового юз кейса или роли я стараюсь «оглядываться» на оригинальные требования для того, чтобы спросить себя: «действительно ли пользователям нужна эта функция?».
    Ключ к тому, чтобы юзабилити было на высоте — понимание того, чего ожидают и чего хотят от вашего проекта пользователи (именно настоящие конечные пользователи, а не воображаемые пользователи в вашей голове или голове заказчика). Поэтому любое проектирование юзабилити должно начинаться с изучения пользователей. Замечательно, если есть возможность познакомиться с ними и посмотреть на то, как они работают, какая информация является для них важной, какая — второстепенной. Если такой возможности нет, придется собирать факты и фантазировать (см. презентацию о методе персон http://www.slideshare.net/ebacon/death- … esentation). Но при любом раскладе до того, как будет нарисован первый юз кейс и спроектирован первый макет, необходимо сказать себе: «Я понял, в чем цель пользователей моего приложения и каким путем они будут ее достигать». Если понимания нет, надо вернуться на шаг назад и снова обратиться к пользователям, иначе все дальнейшие решения будут строиться на ложных предпосылках, а это чревато.

    Поделиться:

    Цитировать

    15.02.2011 в 01:50 # 5442
    Аватар (check)
    check
    Участник

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

    У меня возникла вот такая идея если я правильно понял, какая перед вами стоит задача:
    1. Нарисовать пульт со всеми кнопками и повесить на них обработку событий.
    2. Сделать пульт мастером (master), тогда его можно будет использовать на каждой странице/разделе проектируемого прототипа.
    3. Определить и описать сами события, которые будут возникать при нажатии на ту или иную кнопку пульта.

    Заметьте, что анимация на данный момент реализована только в бета-версии Axure RP6, которая имеет ограниченный срок действия. Так же следует обратить внимание на то, что конечный прототип в Axure представляет собой HTML-страницы, поэтому необходимо решить подходит ли вам такой формат демонстрации прототипа заказчику. Если вы все таки решитесь использовать Axure, то рекомендую скачать библиотеки для проектирования десктопных приложений.
    Mac OS X: http://www.archive.org/details/AriFeldmanAxureOSXWidgetLibraryv1.01
    Windows: не нашел, возможно подойдет библиотека ниже
    OS elements: http://www.axure.com/widgetLibraries/OSElements_Y!DSK.rplib

    P.S.: совет данный здесь, не решит вашу задачу, особенно если вы ранее не работали с Axure. Если у вас есть конкретные вопросы касательно Axure, или можете более точно сформулировать задачу/подзадачи — спрашивайте, а мы постараемся помочь))

    Поделиться:

    Цитировать

    21.02.2011 в 10:52 # 5443
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Вся динамика достаточно просто реализуется во FlairBuilder.
    Используя инструмент Card Stack и большое количество обработчиков событий с поддержкой условий можно сделать достаточно полную имитацию поведения приложения.

    Для пульта — кладется картинка пульта, поверх кнопок — прозрачные элементы с обработчиками событий.

    Поделиться:

    Цитировать

    21.02.2011 в 12:11 # 5444
    Аватар (check)
    check
    Участник
    Вся динамика достаточно просто реализуется во FlairBuilder.

    К сожалению кроме простого интерфейса и действительно простой анимации Flair Builder обладает огромным количеством недостатков и проектировать на нем нечто большее чем веб сайт в три странички представляется крайне сомнительным.

    Поделиться:

    Цитировать

    21.02.2011 в 12:36 # 5445

    [quote]Вся динамика достаточно просто реализуется во FlairBuilder.

    К сожалению кроме простого интерфейса и действительно простой анимации Flair Builder обладает огромным количеством недостатков и проектировать на нем нечто большее чем веб сайт в три странички представляется крайне сомнительным.[/quote]

    Чек, а можно услышать более конструктивную критику? (: Я не подкалываю, я действительно хочу понять, может Flair Builder не совсем то, за что себя выдает (в хорошем смысле этого слова)..

    Поделиться:

    Цитировать

    23.02.2011 в 03:21 # 5446
    Аватар (check)
    check
    Участник
    Юра, если честно, то я удалил FlairBuilder со своего компа уже довольно давно, но постараюсь перечислить минусы, которые вспомню:

    1. Чтобы просмотреть прототип заказчику необходимо установить FlairBuilder viewer, который в свою очередь просит установки Adobe Air (к нему мы еще вернемся) — вроде ничего страшного, но та же Axure выдает HTML, который можно открыть в любом браузере.
    2. Мастера и страницы смешаны в одну кучу (мастера — обычные страницы, которые содержат в себе повторяющиеся элементы и могут использоваться в разных местах прототипа без необходимости рисовать их заново или копи-пастить)
    3. Мастера нельзя перемещать (переносить с места на место на той странице, где используется мастер) !!! (или я не нашел как это делать)
    4. FlairBuilder написан одним программистом (респект и уважуха), но подумайте сколько времени будет занимать фиксинг багов, у больших компаний тут явно преимущество.
    5. Прототип нельзя распечатать на бумаге из самой программы.
    6. Только одна библиотека элементов и не думаю, что будет много энтузиастов, делающих свои библиотеки.
    7. Сгенерированные прототипы временами просто глючат (точно не перечислю баги, но сталкивался с тем, что анимация слетает и один раз из 10 ведет себя непредсказуемо)
    8. Как и обещал — вернемся к Adobe Air. Мне исключительно нравится эта технология, которая предоставляет возможность создания кросс-платформенных приложений, только делается это ценой производительности, т.к. приложения AIR запускаются в собственной среде. При длительной работе и разрастающемся прототипе FlairBuilder просто начинает кушать ресурсы и откровенно тормозить. AIR изначально предназначен для запуска веб-приложений на десктопе при этом приложения полностью функционально а обмен данными происходит только в то время, когда есть подключение к интернету.
    FliarBuilder по определению не подходит для больших проектов.
    9. Аннотация пишется на отдельных элементах "callout", т.е. если вы хотите оставить заметку для какого-либо элемента вам надо перетянуть для него дополнительный элемент на прототип (и так проблемы с производительностью, так на каждый элемент нужно добавлять еще один).

    Кому подойдет:
    1. Дизайнерам, для быстрой демонстрации концепции взаимодействия с интерфейсом
    2. Для моделирование анимации, если на нее в приложении делается ставка и если проект небольшой
    3. Для тех, кто не может позволить программное обеспечение для прототипирования стоимостью выше $99 (FlairBuilder стоит $99)

    Кому не подойдет:
    1. Всем, кто работает с прототипом более 3-4 часов в день
    2. Специалистам, работающим на больших и длительных проектах

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

    Упс, уже три часа ночи :blink:

    Поделиться:

    Цитировать

    23.02.2011 в 10:02 # 5447
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик

    1. Чтобы просмотреть прототип заказчику необходимо установить FlairBuilder viewer, который в свою очередь просит установки Adobe Air (к нему мы еще вернемся) — вроде ничего страшного, но та же Axure выдает HTML, который можно открыть в любом браузере.

    Неверно.
    1. Есть онлайн-просмотрщик
    2. Если ваш закчик не умеет даже этим прользоваться, то ему можно отправить ссылку вида http://www.flairbuilder.com/viewer/?url … Google.fbp (ссылка рабочая).

    Касательно AIR vs HTML — в хтмл возможности AIR отсутствуют, поэтому не надо сравнивать тёплое с мягким.

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

    Используйте папки.

    3. Мастера нельзя перемещать (переносить с места на место на той странице, где используется мастер) !!! (или я не нашел как это делать)

    Не совсем понятно, что нужно делать. Перемещать элементы, принадлежащие мастеру, на странице которая использует мастер?

    4. FlairBuilder написан одним программистом (респект и уважуха), но подумайте сколько времени будет занимать фиксинг багов, у больших компаний тут явно преимущество.

    Разработчик охотно прислушивается к пожеланиям и оперативно отвечает на письма о дефектах. Но чем дальше будет расти продукт, тем тяжелее ему будет.

    5. Прототип нельзя распечатать на бумаге из самой программы.

    Да, только через эспорт в картинки и печать результата экспорта.

    6. Только одна библиотека элементов и не думаю, что будет много энтузиастов, делающих свои библиотеки.

    Можно создавать свои кастомные элементы и шарить их. Сейчас около 55 кастомных элементов, но комьюнити действительно слабое.

    Всё остальное без комментариев, потому что не указано, какой версией пользовались и впечатления на уровне "помню, что-то было не так".

    Я не агитирую срочно всем бежать смотреть FlairBuilder, у него своя аудитория и своя применимость. Есть ошибки, возможно отсутствуют "жизненно важные" функции. Для мега-систем из сотен страниц он действительно вряд ли подойдет.

    Сравнивать с Axure я тоже не буду, потому что пробовал его относительно недолго на ветках 4 и 5 и остался недоволен. Но это моё ЛИЧНОЕ мнение и моя ЛИЧНАЯ специфика работы. И хотелось бы, чтобы люди, которые пишут отзывы, делали это со знанием того, о чем они пишут.

    Я в FlairBuilder делал только один большой проект год назад, ещё до версии 2.х. Были свои недостатки, были проблемы производительностью, но прототип интерфейса показывался перед собранием в 20 человек из разных стран и организаций, наш будущий заказчик остался очень доволен.
    Ничего критически неработоспособного или неудобного нет.

    Поделиться:

    Цитировать

    23.02.2011 в 14:47 # 5448
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Если речь об анимации, то в новой версии Axure она есть.

    Не уверен, что мы под анимацией понимаем одно и то же:
    1. Почитал описания и хелп, в Axure есть аналог Card Stack — Dynamic Panels. Насколько они сравнимы, не могу сказать, надо пробовать. Не совсем понятно, насколько гибко в Axure реализованы состояния для табов и аналогичных компонентов, а также вещи типа "Если открыта вторая закладка (tab), то …"
    2. Насколько гибко настраиваемы элементы. Например я взял грид, но не совсем понял, можно ли туда накидать чекбоксов, иконок, форматированного текста и прочего. Вижу, что есть импорт из Excel, но я по опыту работы с Visio это не слишком люблю. И насколько я вижу, по умолчанию набор виджетов в Axure довольно скромный, надо бы посмотреть предлагаемые библиотеки.
    3. Ну и всякие рюшечки — например, когда закидываешь элемент Карта и в режиме просмотра там подгружается Google Maps. Аналогично с video players.

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

    Заглянул в Axure, насколько я понимаю, там другая концепция для мастера — мастер забрасывается на страницу и ему всё равно где лежать.
    В FlairBuilder аналогично Visio — мастер является подложкой страницы, на самой странице перемещать элементы принадлежащие мастеру нельзя.
    Собирать набор виджетов в единую группу и сохранять её для повторного использования в FlairBuilder можно. С какой точно версии — не вспомню.

    Есть ли возможность сделать заметку не добавляя на прототип нового элемента?

    Нет, только через Callout.

    При длительной работе и разрастающемся прототипе FlairBuilder просто начинает кушать ресурсы и откровенно тормозить.

    На версии 1.9х у меня были проблемы с производительностью. Версии старше полноценно не пробовал. Машина уровня Athlon 2400/VIA KT600, то есть далеко не новая.

    просто на данный момент у вас нет необходимости делать прототипы, но ка только она появится вы будете использовать именно FalirBuilder?

    Да, у меня сейчас другие задачи. До этого прототипировал в основном в Visio с автоматизацией выгрузки в images и обновлением в Word-based спецификациях. Если будет проект среднего или меньше среднего размера — с удовольствием попробую опять FlairBuilder. Или Axure *king* .

    Поделиться:

    Цитировать

    28.02.2011 в 18:11 # 5449

    В чем рисуете (axure хорошо, а что если проектируется не web site)?

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

    Не только axure, большинство существующих инструментов прототипирования действительно ориентированы на Веб. Для прототипирования десктоп приложения вариант Visio, я думаю, Вам не подойдёт, судя по описанию заказчика: ему желательно представить полностью интерактивный прототип, где переходы от интерфейса к интерфейсу осуществляются в режиме симуляции. В визио же возможности интерактивности очень и очень ограничены. Посмотрите такие инструменты как GUI Machine или GUI Design Studio. Моё предпочтение на стороне GUI Machine: прототипы получаются намного более привлекательные, живые и интерактивные.
    Описание GUI Machine представлено в топике:
    viewtopic.php?f=7&t=181&p=15790#p15790

    Поделиться:

    Цитировать

Показано 11 ответов - от 1 до 11 (всего 11)

Вы должны авторизироваться для ответа в этой теме.