Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Жаль нельзя несколько вариантов выбрать. Мы, например, сначала обсуждаем на словах, рисуем на бумажках, а потом пишем спек с использованием схем, сделанных в Visio.
Сколько в процентах весь этот этап занимает от общего времени проекта(т.е. обсуждение+на бумажках+пишется спека+рисуется в Visio)? Считаете ли вы ваш подход наилучшим в вашей ситуации?
Насчет времени. Если проект имеет более мение не стандартную функциональность. То очень важно проработать интерфейс в деталях. Иначепотом потратится уйма времени на правку уже готовой функциональности.
Если проект стандартный, все элементы тысячу раз опробованы можно просто обсудить и программить.
Если проект стандартный, все элементы тысячу раз опробованы можно просто обсудить и программить.
Как вы считаете, как можно замерить численно эту "уйму"? Фиксировать время затраченное на переделку уже после того как работы по прототипированию закончены?
Естественно опытным путем.
Берем проект, оговариваем его в общих чертах. Например, есть виш лист заказчика, мы задаем по нему вопросы, так чтобы в голове сложился более менее четкий образ. И программируем все это. Первый звоночек, что что-то не так - это возникающие в процессе разработки вопросы, на которые сам придумываешь ответы. Считай уже, что все это прийдется переделать. Ну и все время потраченое на переделку аккуратно фиксируем (и как часто бывает вычитаем из своей прибыли).
А вообще тотальное прототипирование не обязательная вещь. Есть стандартные вещи, на которые есть заготовленые куски спецификации. Например аутентификация, восстановление пароля, частенько в регистрации только данные поменять нужно. В админке куча стандартных элементов. Все это здорово сокращает время создания спецификации.
Берем проект, оговариваем его в общих чертах. Например, есть виш лист заказчика, мы задаем по нему вопросы, так чтобы в голове сложился более менее четкий образ. И программируем все это. Первый звоночек, что что-то не так - это возникающие в процессе разработки вопросы, на которые сам придумываешь ответы. Считай уже, что все это прийдется переделать. Ну и все время потраченое на переделку аккуратно фиксируем (и как часто бывает вычитаем из своей прибыли).
А вообще тотальное прототипирование не обязательная вещь. Есть стандартные вещи, на которые есть заготовленые куски спецификации. Например аутентификация, восстановление пароля, частенько в регистрации только данные поменять нужно. В админке куча стандартных элементов. Все это здорово сокращает время создания спецификации.
Невозможно определить длительность этого этапа (назовём его "проектирование").
Она зависит от конкретного проекта. Существует два основных влияющих фактора:
- размер проекта
- заказчик (время получения обратной связи от заказчика).
Размер проекта влияет на длину этапа проектирования прямо пропорционально. Причём, соглашусь с koscoder-ом, момент "стандартности" элементов тоже играет роль.
Ну и т.к. на этой стадии идёт максимальное взаимодействие с заказчиком, очень многое зависит от него - насколько он динамично обеспечивает обратную связь.
Из практики, были случаи, когда проектирование занимало месяц, реализация 3 месяца, а был и такой, когда проектирование заняло 4 месяца, а реализация месяц.
Свой подход считаю наилучшим, т.к. пришёл к нему эволюционно в течении более чем 10-ти лет работы и успешно его использую (ессно, что он тоже эволюционирует и становится лучше :). В двух словах, гораздо легче всё сначала закрепить на бумажке/в документе, чем потом переделывать. Я для этого использую переговоры с заказчиком с бумагой под рукой и дальнейшее развитие этого дела в документах-спецификациях, с конкретными схемами страниц сайта.
Она зависит от конкретного проекта. Существует два основных влияющих фактора:
- размер проекта
- заказчик (время получения обратной связи от заказчика).
Размер проекта влияет на длину этапа проектирования прямо пропорционально. Причём, соглашусь с koscoder-ом, момент "стандартности" элементов тоже играет роль.
Ну и т.к. на этой стадии идёт максимальное взаимодействие с заказчиком, очень многое зависит от него - насколько он динамично обеспечивает обратную связь.
Из практики, были случаи, когда проектирование занимало месяц, реализация 3 месяца, а был и такой, когда проектирование заняло 4 месяца, а реализация месяц.
Свой подход считаю наилучшим, т.к. пришёл к нему эволюционно в течении более чем 10-ти лет работы и успешно его использую (ессно, что он тоже эволюционирует и становится лучше :). В двух словах, гораздо легче всё сначала закрепить на бумажке/в документе, чем потом переделывать. Я для этого использую переговоры с заказчиком с бумагой под рукой и дальнейшее развитие этого дела в документах-спецификациях, с конкретными схемами страниц сайта.
Возможно, кто-то расскажет о собственных разработках? Или о возможно забытом в вариантах способе?
Поправьте заголовок: «участвовать».
Спасибо за наводку на "Axure"
Пожалуйста, но учтите,что есть и свои минусы. Обзор средств прототипирования с их плюсами и минусами тема моей ближайшей статьи на http://www.amazedev.com
В общем-то для статьи статистику и собираю
В общем-то для статьи статистику и собираю
В рассылке IxDA недавно в очередной раз была очень интенсивная (100 сообщений!) перекличка по средствам протопирования.
А, вот она:
http://ixda.org/discuss.php?post=22050&s…
А, вот она:
http://ixda.org/discuss.php?post=22050&s…
Спасибо. Не знал о существовании этого опроса.
Среди западных списков рассылки IXDA самый ценный. Если опубликуете свою статью, то дайте здесь, пожалуйста, анонс - самому интересно, что у Вас получиться.
Получилась такая статья:
http://www.amazedev.com/prototipirovanie…
Комментарии и критика принимаются.
http://www.amazedev.com/prototipirovanie…
Комментарии и критика принимаются.
Не очень гибкий опрос, так что никак не проголосовал в результате.
Для крупного проекта я, например, сначала обсуждаю на словах (1), потом зарисовываю на бумаге (2), делаю в Visio схемы (3), делаю динамически HTML-прототип в Dreamweawer.
За наводку на Axure спасибо, кстати. Попробую.
Для крупного проекта я, например, сначала обсуждаю на словах (1), потом зарисовываю на бумаге (2), делаю в Visio схемы (3), делаю динамически HTML-прототип в Dreamweawer.
За наводку на Axure спасибо, кстати. Попробую.
Я, например, делаю большинство на бумаге, а некоторые вещи — в Axure, но больше статические. Динамические прототипы — реже.
ребятки, сори за возможный оффтоп, но у меня тут возникла идея для редактора кода:
http://neelts.ya.ru/replies.xml?item_no=13
пожалуйста, те кто может постить в UI Design and Usability, напишите статейку со ссылкой, думаю многим будет интересно!
http://neelts.ya.ru/replies.xml?item_no=13
пожалуйста, те кто может постить в UI Design and Usability, напишите статейку со ссылкой, думаю многим будет интересно!
Кто нибудь знает кроме Axure ПО для прототипирования?
Могу сказать, что собираюсь представить некоторую альтернативу Axure по создания динмаических прототипов. На этом пока всё. Могу лишь пока предложить следить за блогом http://www.amazedev.com. На хабре будет представлено тоже.
нипонятнаа...
обсуждения, потом документы со screens (возможно Visio), а потом собственно протопит, используя реальные технологии.. заодно сверяем свои ожидания от них.
сейчас посмотрю Axure, но непонятно, зачем строить прототипы на технологиях, которые потом всё равон выкидывать...
обсуждения, потом документы со screens (возможно Visio), а потом собственно протопит, используя реальные технологии.. заодно сверяем свои ожидания от них.
сейчас посмотрю Axure, но непонятно, зачем строить прототипы на технологиях, которые потом всё равон выкидывать...
В моей компании для прототипирования Веб-приложений (как впрочем и десктопных) активно используется собственная разработка — GUI Machine. На выходе получаем полностью интерактивный и детализированный прототип. Нужно это, естественно, не всем или не всегда, но мы разрабатываем веб-приложения со сложной логикой и кастомизируем веб-интерфейсы сложных КИС — поэтому для нас важно, чтобы прототип был максимально интерактивным и описывал сложный функционал, чтобы между участниками проекта (заказчиком, программистом, дизайнером, менеджером) не осталось не решённых вопросов и не обговоренных моментов. Иначе придётся переделывать — а это дорого, долго, нудно и не очень приятно.
С недавних пор инструмент выпущен «на свободу», если заинтересовало — познакомиться поближе и опробовать демку можно здесь: www.guimachine.ru
С недавних пор инструмент выпущен «на свободу», если заинтересовало — познакомиться поближе и опробовать демку можно здесь: www.guimachine.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Участвуешь в разработке web-проектов? А как выглядит процесс прототипирования в твоей компании?