Правильный или нет это подход зависит ещё от ценовой политики. Полностью поддерживаю, что правильнее — именно так, как вы описали, если конечно это возможно по совокупности причин.
Суть абзаца в том, что в любом случае придется утверждать ТЗ и в общих интересах, что бы все максимально точно понимали, что там написано – тут на помощь и приходят понятные всем mindmaps.
ps:
Вы наверняка сталкивались со случаем, когда заказчик не разбирается в тонкостях, но упорно этого не признает и гнет свою линию — наверное самый неприятный момент.
Ну в данном случае под пятью страничками, я подразумевал слово «простой», обычно состоящий из статики.
Но вот с точки зрения общения с заказчиком действительно приходится сталкиваться с удивлениями «почему столько стоит, это же всего одну страничку добавить» :)
Ну почему же не думает — это первая задача программиста после утверждения функционала, подписания тз и т.д.
Если конечно сайт того требует, а не создается с помощью кмс.
Хотя стоит признать, что внимания этому действительно уделяется недостаточно, особенно, когда возникает необходимость к готовой системе дописать новый кусок.
Да, всё это минусы в отрасли, а как с ними бороться каждый решает сам, но однозначного ответа нет(.
Действительно, порой это слишком накладно, тут либо отказываться от подобных задач, либо пытаться снизить расходы. Я лично вижу решение проблемы недорогих сайтов в унификации, подготавливаем стандартный набор документов, который корректируем в некоторых рамках. А вот эти рамки надо четко предоставлять заказчику, а выход за них должен и оплачиваться дополнительно.
Это ориентировано на небольшие студии с их не самыми серьезными проектами, без попытки замахнуться на самописные сообщества с кучей кода).
Естественно, намного правильнее, когда прототипирование делает человек, который понимает в юзабилити, а не в построение БД – статья о том что делать, а как уже на совести коллектива.
В торговле у продавцов такое правило почти обязательно, предложить выбор между двумя вещами, что бы покупатель ничего не придумывал и не ломался. Он после такого действия себя психологически ограничивает, но в тоже время ему кажется, что есть выбор — хороший прием, да.
Да, Дмитрий, поэтому я указал в статье, что это относится к средней по сложности сайтам.
Хотя сайт на подобии покерофа данным образом спроектировать можно, но естественно не только с одной ассоциативной картой и этапов будет больше, придется ограничивать вложенность пунктов и раскрывать что-то по-отдельности.
Некоторые вещи придется менять уже на живом сайте (юзайбилити на 100% обычно не предусмотреть и всё равно нужно будет корректировать по инфе от пользователей), что у Вас так же происходило и мне, как одному из Ваших пользователей, нравится, что получилось в итоге.
Да, мне тоже очень понравилось видео, ещё когда впервые промелькнуло на хабре. Правда в данный момент в роли ОС выступает linux, но это не такая проблема.
Не подскажите, есть ли там возможность создания например html версии, что бы представить заказчику, выложив на сервер?
Абсолютно верное замечание и полезный совет про «комбирование блоков», действительно бывает, что приходится готовые элементы пытаться адаптировать, но это не всегда так просто как звучит оказывается.
Да, естественно для сайтов из 5 страничек вырисовывать кучу картинок и проетировать интерфейс — это круто, но не очень разумно. А когда задача усложняется, полезно строить схемы даже для собственного понимания, да и приносит положительные эмоции, что всё делается четко.
Ну тут обычно важнее не спроектировать, а успеть записать пока мысли из головы не пропали :) А то действительно потом начинаешь вспоминать, что, где, как, а представления четкого уже нет.
Суть абзаца в том, что в любом случае придется утверждать ТЗ и в общих интересах, что бы все максимально точно понимали, что там написано – тут на помощь и приходят понятные всем mindmaps.
ps:
Вы наверняка сталкивались со случаем, когда заказчик не разбирается в тонкостях, но упорно этого не признает и гнет свою линию — наверное самый неприятный момент.
Но вот с точки зрения общения с заказчиком действительно приходится сталкиваться с удивлениями «почему столько стоит, это же всего одну страничку добавить» :)
Если конечно сайт того требует, а не создается с помощью кмс.
Хотя стоит признать, что внимания этому действительно уделяется недостаточно, особенно, когда возникает необходимость к готовой системе дописать новый кусок.
Действительно, порой это слишком накладно, тут либо отказываться от подобных задач, либо пытаться снизить расходы. Я лично вижу решение проблемы недорогих сайтов в унификации, подготавливаем стандартный набор документов, который корректируем в некоторых рамках. А вот эти рамки надо четко предоставлять заказчику, а выход за них должен и оплачиваться дополнительно.
Спасибо за такой развернутый комментарий :)
В таком случае mindmap можно применить для внесения ясности :)
Естественно, намного правильнее, когда прототипирование делает человек, который понимает в юзабилити, а не в построение БД – статья о том что делать, а как уже на совести коллектива.
Хотя сайт на подобии покерофа данным образом спроектировать можно, но естественно не только с одной ассоциативной картой и этапов будет больше, придется ограничивать вложенность пунктов и раскрывать что-то по-отдельности.
Некоторые вещи придется менять уже на живом сайте (юзайбилити на 100% обычно не предусмотреть и всё равно нужно будет корректировать по инфе от пользователей), что у Вас так же происходило и мне, как одному из Ваших пользователей, нравится, что получилось в итоге.
Не подскажите, есть ли там возможность создания например html версии, что бы представить заказчику, выложив на сервер?