Comments 40
Неплохо!
В общем же, всем рекомундую прочитать книгу К. Вигерса "Разработка требований к программному обеспечению", там тема прототипирования также затронута.
В общем же, всем рекомундую прочитать книгу К. Вигерса "Разработка требований к программному обеспечению", там тема прототипирования также затронута.
Спасибо большое. В ближайшем будущем собираюсь вступить в роль как раз проектировщика/менеджера. Как раз ставил перед собой задачу выбора.
Когда будет сделан конкретный выбор постараюсь написать почему.
Когда будет сделан конкретный выбор постараюсь написать почему.
Отличный анализ и обзор.
В некоторых случаях бумажные прототипы - гораздо лучше индизайновых, а в некоторых наоборот.
Практически на всех сайтах, где нужно «промо», графика, навороты и т.д. - без бумаги не обойтись (я в хорошем смысле).
А большинство «сухих», информационных или корпоративных сайтов легче, конечно придумывать на экране.
Практически на всех сайтах, где нужно «промо», графика, навороты и т.д. - без бумаги не обойтись (я в хорошем смысле).
А большинство «сухих», информационных или корпоративных сайтов легче, конечно придумывать на экране.
Кстати, вместо корявого слова «юзабилити», есть очень хорошее, наше - «Эргономика!»
Не совсем согласен. Все определяет размер проекта.
Если проект маленький, статичный то хватит и бумаги.
А для более больших проектов процесс проектирования тоже начнеться с бумаги, однако потом перейдет на доску, а потом и в Axure Pro или Visio.
Если проект маленький, статичный то хватит и бумаги.
А для более больших проектов процесс проектирования тоже начнеться с бумаги, однако потом перейдет на доску, а потом и в Axure Pro или Visio.
Долгое время пользовался Visio для подготовки прототипов. По опыту могу сказать что это лишний этап, так как все равно перед этим все рисовалось на бумаге. На бумаге быстрее, а зачастую нужно получить первичный вид интерфейса быстро.
Вот как сейчас: бумажный прототип -> верстка -> утверждение верстки -> коддинг...
Вот как сейчас: бумажный прототип -> верстка -> утверждение верстки -> коддинг...
Спасибо за труд. Отдельное спасибо за PMBOK, в Америке, Англии, Японии уже давно существуют стандарты на создание ПО, и предотвращению наступания на одни и теже грабли.
Интересно у кого как обстоить дело со стандартами на фирмах.
PMBOK
SWEBOK
P2M
Список можно продолжать, опыт в мире уже есть, интересно как им пользуются.
Интересно у кого как обстоить дело со стандартами на фирмах.
PMBOK
SWEBOK
P2M
Список можно продолжать, опыт в мире уже есть, интересно как им пользуются.
я собираюсь в следующем году получать сертификат IPMI. Считаю, что должны все таки и наши специалисты приходить к единому стандарту.
Что характерно, PMBOK про создание ПО как раз ничего и не говорит.
The PMBOK Guide – Third Edition is an internationally recognized standard (IEEE Std 1490-2003) that provides the fundamentals of project management as they apply to a wide range of projects, including construction, ___software___, engineering, automotive, etc.
Если не говориться, что молотком можно колоть орехи, то это не значит что он для этого непригоден.
У меня в университете "Менеджмент IT проектов" преподавали отчасти по этой книге. Она, если честно, мозг хорошо вправляет. На западе хорошо то, что они к аккуратности и стандартам приучены. У нас же иногда так делают, потом самим переделывать не хочется, и начинают разработку сначала.
Если не говориться, что молотком можно колоть орехи, то это не значит что он для этого непригоден.
У меня в университете "Менеджмент IT проектов" преподавали отчасти по этой книге. Она, если честно, мозг хорошо вправляет. На западе хорошо то, что они к аккуратности и стандартам приучены. У нас же иногда так делают, потом самим переделывать не хочется, и начинают разработку сначала.
Ну у меня тоже преподавали и эту книгу, я ее честно всю прочитал, местами несколько раз.
ПМБОК, как следует из его концепции, отлично подходит для управления любым проектом. Подумать только, как это здорово, правда? Одну книгу прочитал - и управляй чем хочешь. Хочешь - дом строй, хочешь - канаву рой, хочешь - софт разрабатывай. Аккуратно и стандартно. Приученно.
Так что формально, я, разумеется, неправ - там и про ПО тоже. В том смысле, что именно про ПО там ничего не написано, но все, что написано, мол, годится и для ПО.
Не, а книжка, конечно, ценная, прочитать однозначно стоит, тут я согласен.
Но софт по ней - сами разрабатывайте, я свою команду не готов считать ресурсом.
ПМБОК, как следует из его концепции, отлично подходит для управления любым проектом. Подумать только, как это здорово, правда? Одну книгу прочитал - и управляй чем хочешь. Хочешь - дом строй, хочешь - канаву рой, хочешь - софт разрабатывай. Аккуратно и стандартно. Приученно.
Так что формально, я, разумеется, неправ - там и про ПО тоже. В том смысле, что именно про ПО там ничего не написано, но все, что написано, мол, годится и для ПО.
Не, а книжка, конечно, ценная, прочитать однозначно стоит, тут я согласен.
Но софт по ней - сами разрабатывайте, я свою команду не готов считать ресурсом.
>я свою команду не готов считать ресурсом.
В этом я абсолютно с вами согласен.
Дело в том, что пока команда разработчиков небольшая, стандарты будут только отягощать. Но как только их количество привысит определенный порог, отсутсвие стандартов даст о себе знать. И использование тогоже PMBOK (или другого стандарта, лучше даже ГОСТа, если он есть) будет очень полезно.
В этом я абсолютно с вами согласен.
Дело в том, что пока команда разработчиков небольшая, стандарты будут только отягощать. Но как только их количество привысит определенный порог, отсутсвие стандартов даст о себе знать. И использование тогоже PMBOK (или другого стандарта, лучше даже ГОСТа, если он есть) будет очень полезно.
Классическая Джоэловская диллема "Голый повар против Макдональдса". В этом смысле стандарты решают проблему масштабирования управления. Когда вы готовы работать силами многочисленной команды удовлетворительных разработчиков. То есть, ресурсами. ПМБОК как раз это поощряет - там утверждается, что если все делать по стандартам, то все будет хорошо.
Я к тому, что вместо стандартов лучше иметь идеи.
Я к тому, что вместо стандартов лучше иметь идеи.
Поправьте пожалуйста - не Usetics, а Usethics
Содержательная статья, большое спасибо. Хотелось бы добавить к теме следущее: несмотря на низкую интерактивность InDesign у него есть то преимущество, что файл InDesign можно использовать как основу для разработки дизайна в Illustrator, что сокращает время разработки дизайна.
совершенно прекрасный обзор
у нас в компании с этим все, конечно на нуле, и я пытаюсь сейчас внедрять это, так или иначе используя это во всех своих проектах
спасибо!
у нас в компании с этим все, конечно на нуле, и я пытаюсь сейчас внедрять это, так или иначе используя это во всех своих проектах
спасибо!
InDesign достаточно интерактивен
Благодарю за такой итоговый обзор. Как раз наткнулся на него, начиная рисовать прототипы для нового проекта. Как и большинство проголосовавших, чаще использую бумагу, по крайне мере на ранних этапах. Также имею опыт работы с Визио, он мне кажется довольно удобным для многих задач инструментом, в т.ч. и для прототипов. С удовольствием попробую и ваш инструмент.
господа, а что посоветуете для динамического прототипирования на Mac?
Спасибо.
p.s. OmniGraffle не предлагать :)
Спасибо.
p.s. OmniGraffle не предлагать :)
Interface Builder
en.wikipedia.org/wiki/Interface_Builder
habrahabr.ru/blogs/macosxdev/30553/
Сам не пользовался
en.wikipedia.org/wiki/Interface_Builder
habrahabr.ru/blogs/macosxdev/30553/
Сам не пользовался
Sign up to leave a comment.
Прототипирование web-сайтов. Собирая воедино.