В теме 11 ответов, и 7 участников, последнее обновление сделано пользователем 
Рустем Гайфутдинов 13 г, 9 мес. назад.
-
Сообщения
-
Всем привет
Дорогие аналитики, как вы ведете требования к GUI? В чем рисуете (axure хорошо, а что если проектируется не web site)?
Как проектируетеописываете usability? Как описываете работу приложения с устройствами ввода (что, если кроме клавиатуры есть другие)?История вопроса вот какая:
Проект — десктопное приложение, основной упор со стороны заказчика — на внешний вид. Сам заказчик невероятный визуал, текст воспринимает не больше трех предложений, дальше либо выключается, либо просит рисовать.
Я так вижу, что в данном случае собирать требования удобнее всего опираясь на то, как это будет выглядеть внешне — какие меню, куда можно из них перейти, что я в каждом меню увижу. Интереса добавляет то, что кроме клавиатуры будет еще пульт дистанционного управления, и каждую его кнопку тоже, само собой, нужно описать.Axure, на сколько я пока разобралась (раньше с ним не сталкивалась, миллион спасибо за статьи на сайте!), переходы может красиво нарисовать, но я так и не придумала, как бы отразить динамически работу элементов управления.
Гуру, какие есть идеи?
И с почином меня, что ли, первое сообщение на форуме, принимайте в свое аналитическое сообщество
Привет Мое мнение ниже.
Дорогие аналитики, как вы ведете требования к GUI?
Маша, исходя из текущих реалий твоего места работы у тебя есть как минимум 3 варианта:
Borland Caliber RM. При создании проекта в Caliber RM (да и после тоже
) можно указать/запросить, какие именно типы требований тебе нужно вести и среди них есть тип "GUI Requirements". Требования этого типа затем можно трейсить на страницы, функции, кнопки и пр.Atlassian Confluence. В проектном спейсе можно создать отдельную ветку для GUI требований и трейсить их на страницы, кнопки и пр. с помощью входящих/исходящих гиперссылок.
MS Word + SharePoint/SVN.Рекомендую для GUI сделать отдельный документ/раздел в общем документе и трейсить на другие требования кросс-линками и объектами.
Из моего опыта очень важно, чтобы разработчики знали GUI требования как Отче Наш, т.к. недостаток функциональности иногда можно скрыть/обыграть
, а кривой интерфейс очень сложно. Встречают по одежке Что касается структуризации GUI требований. Я обычно делаю общий раздел, куда выношу общие GUI требования (например, основной шрифт/цвет), требования к элементам интерфейса, которые есть на большинстве форм и т.д. Требования из этого раздела трейшу скопом на каждую страницу/форму. Если есть частные требования (специфичные какой-то одной странице/форме или кнопке, например), то описываю их отдельно, ну и трейшу на соответствующее требование.
Как вариант, если GUI требования достаточно статичны (не/мало изменяются во времени), то при описании каждой страницы/формы, кнопки можно отдельно описывать GUI требования к данному элементу. Разработчикам так удобнее читать, но если придется поддерживать требования — может отнять много времени на обновление требований.
В чем рисуете (axure хорошо, а что если проектируется не web site)?
В Axure можно проектировать не только веб сайты
Как варианты: Balsamiq Mocups, Visio.Как проектируетеописываете usability?
Уточни, пожалуйста вопрос. Т.к. Usability, ИМХО это интерфейс+функциональности+быстродейстие. Т.е. это GUI требования+пользовательские/функциональные требования+критерии качества.
Вот тутесть интересные мысли по поводу проектирования UX.Как описываете работу приложения с устройствами ввода (что, если кроме клавиатуры есть другие)?
Или разные сценарии использования (если они действительно отличаются). Или разные страницы/формы для одного и того же сценария использования. Например, в шаблоне SRS от IEEE есть раздел, в котором можно описать все возможные интерфейсы ввода.
Axure, на сколько я пока разобралась (раньше с ним не сталкивалась, миллион спасибо за статьи на сайте!), переходы может красиво нарисовать, но я так и не придумала, как бы отразить динамически работу элементов управления.
Для этого там есть динамические панели и возможность настраивать/писать "скрипты". На пальцах сложно объяснить
Попроси кого-нибудь из коллег показать (вроде есть группа рассылка на аналитиков в Itransition), думаю с радостью помогут. Добрый день, Мария, и добро пожаловать в наше аналитическое сообщество!
Хочу добавить немного к ответу 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). Но при любом раскладе до того, как будет нарисован первый юз кейс и спроектирован первый макет, необходимо сказать себе: «Я понял, в чем цель пользователей моего приложения и каким путем они будут ее достигать». Если понимания нет, надо вернуться на шаг назад и снова обратиться к пользователям, иначе все дальнейшие решения будут строиться на ложных предпосылках, а это чревато.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.rplibP.S.: совет данный здесь, не решит вашу задачу, особенно если вы ранее не работали с Axure. Если у вас есть конкретные вопросы касательно Axure, или можете более точно сформулировать задачу/подзадачи — спрашивайте, а мы постараемся помочь))
Вся динамика достаточно просто реализуется во FlairBuilder.
Используя инструмент Card Stack и большое количество обработчиков событий с поддержкой условий можно сделать достаточно полную имитацию поведения приложения.Для пульта — кладется картинка пульта, поверх кнопок — прозрачные элементы с обработчиками событий.
Вся динамика достаточно просто реализуется во FlairBuilder.
К сожалению кроме простого интерфейса и действительно простой анимации Flair Builder обладает огромным количеством недостатков и проектировать на нем нечто большее чем веб сайт в три странички представляется крайне сомнительным.
[quote]Вся динамика достаточно просто реализуется во FlairBuilder.
К сожалению кроме простого интерфейса и действительно простой анимации Flair Builder обладает огромным количеством недостатков и проектировать на нем нечто большее чем веб сайт в три странички представляется крайне сомнительным.[/quote]
Чек, а можно услышать более конструктивную критику? (: Я не подкалываю, я действительно хочу понять, может Flair Builder не совсем то, за что себя выдает (в хорошем смысле этого слова)..
Юра, если честно, то я удалил 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 это маленький ребенок, которому предстоит пройти долгий путь, чтобы стать полноценным помощником в работе. Как и многие дети он может показаться вам веселым и забавным — не думаю, что это то, что бы попросил от вас заказчик.Упс, уже три часа ночи
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 человек из разных стран и организаций, наш будущий заказчик остался очень доволен.
Ничего критически неработоспособного или неудобного нет.Если речь об анимации, то в новой версии 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
.В чем рисуете (axure хорошо, а что если проектируется не web site)?
История вопроса вот какая:
Проект — десктопное приложение, основной упор со стороны заказчика — на внешний вид. Сам заказчик невероятный визуал, текст воспринимает не больше трех предложений, дальше либо выключается, либо просит рисовать.
Я так вижу, что в данном случае собирать требования удобнее всего опираясь на то, как это будет выглядеть внешне — какие меню, куда можно из них перейти, что я в каждом меню увижу. Интереса добавляет то, что кроме клавиатуры будет еще пульт дистанционного управления, и каждую его кнопку тоже, само собой, нужно описать.Не только axure, большинство существующих инструментов прототипирования действительно ориентированы на Веб. Для прототипирования десктоп приложения вариант Visio, я думаю, Вам не подойдёт, судя по описанию заказчика: ему желательно представить полностью интерактивный прототип, где переходы от интерфейса к интерфейсу осуществляются в режиме симуляции. В визио же возможности интерактивности очень и очень ограничены. Посмотрите такие инструменты как GUI Machine или GUI Design Studio. Моё предпочтение на стороне GUI Machine: прототипы получаются намного более привлекательные, живые и интерактивные.
Описание GUI Machine представлено в топике:
viewtopic.php?f=7&t=181&p=15790#p15790
Вы должны авторизироваться для ответа в этой теме.
