Комментарии 68
Надеюсь, я тоже когда-то научусь проектировать
А то все как-то в голове, да в голове, да «примерно как-то вот так», а потом вспоминай сиди что ты там как-то раз, сидя на кухне, придумал
А то все как-то в голове, да в голове, да «примерно как-то вот так», а потом вспоминай сиди что ты там как-то раз, сидя на кухне, придумал
Для небольших сайтов достаточно тз/брифа, а вот для крупных проектов без проектирования и т.д.
Сам стараюсь с сайтами сложнее визиток/банальных ИМ расписывать все на бумаге и рисовать эскизы интерфейсов.
Сам стараюсь с сайтами сложнее визиток/банальных ИМ расписывать все на бумаге и рисовать эскизы интерфейсов.
Да, естественно для сайтов из 5 страничек вырисовывать кучу картинок и проетировать интерфейс — это круто, но не очень разумно. А когда задача усложняется, полезно строить схемы даже для собственного понимания, да и приносит положительные эмоции, что всё делается четко.
Разумно-разумно. Если проект маленький, значит технологическая цепочка просто будет быстрее прогоняться.
Для небольших сайтов можно прорисовать все что угодно с самого начала и это будет 90% работы.
Для крупных проектов делать все вышеуказанное одному человеку невозможно. И это учитывая, что куча этапов тут не расписаны как суть.
Для крупных проектов делать все вышеуказанное одному человеку невозможно. И это учитывая, что куча этапов тут не расписаны как суть.
Да, Дмитрий, поэтому я указал в статье, что это относится к средней по сложности сайтам.
Хотя сайт на подобии покерофа данным образом спроектировать можно, но естественно не только с одной ассоциативной картой и этапов будет больше, придется ограничивать вложенность пунктов и раскрывать что-то по-отдельности.
Некоторые вещи придется менять уже на живом сайте (юзайбилити на 100% обычно не предусмотреть и всё равно нужно будет корректировать по инфе от пользователей), что у Вас так же происходило и мне, как одному из Ваших пользователей, нравится, что получилось в итоге.
Хотя сайт на подобии покерофа данным образом спроектировать можно, но естественно не только с одной ассоциативной картой и этапов будет больше, придется ограничивать вложенность пунктов и раскрывать что-то по-отдельности.
Некоторые вещи придется менять уже на живом сайте (юзайбилити на 100% обычно не предусмотреть и всё равно нужно будет корректировать по инфе от пользователей), что у Вас так же происходило и мне, как одному из Ваших пользователей, нравится, что получилось в итоге.
Как же хорошо, когда структура подобным образом утверждается до дизайнерской работы. На практике чаще приходится сталкиваться с готовым дизайном, напрочь оторванным от реальности. В этом случае подход немного иной, можно составить карту блоков и элементов по существующему дизайну и утвердить с заказчиком связи между всем этим
«что главной частью в работе над программным продуктом, будь то сайт...» — я бы сказал, что логичнее называть сайт не «программным продуктом», а инструментом продаж.
Уже с самого начала статьи чувствуется, что над проблемой работал программист, а должен проектированием сайта заниматься менеджер проекта. Увы, это и приводит часто к тому что сайт «на аяксе» и всё в нем летает, а продают больше конкуренты.
Уже с самого начала статьи чувствуется, что над проблемой работал программист, а должен проектированием сайта заниматься менеджер проекта. Увы, это и приводит часто к тому что сайт «на аяксе» и всё в нем летает, а продают больше конкуренты.
Проектированием сайта (хоть горшком назови) должен заниматься архитектор-проектировщик, у менеджера проекта другие задачи. Последний раз я видел спроектированный менеджером интернет магазин, главная страница которого открывалась 20 секунд.
На практике в большинстве маленьких веб-студий «проектированием сайта» занимается «специалист по работе с клиентами» стремясь продать клиенту как можно больше готовых блоков, которые уже написаны программистами студии, и внимательно следя, за «удовлетворенностью клиента», что приводит к получению програмистами задач, реакция на которых (дословно) звучит так: «Я конечно могу, но лучше бы я этого не делал». Результат — предсказуем.
На практике в большинстве маленьких веб-студий «проектированием сайта» занимается «специалист по работе с клиентами» стремясь продать клиенту как можно больше готовых блоков, которые уже написаны программистами студии, и внимательно следя, за «удовлетворенностью клиента», что приводит к получению програмистами задач, реакция на которых (дословно) звучит так: «Я конечно могу, но лучше бы я этого не делал». Результат — предсказуем.
Очень полезно, как для составления структуры сайта так и для объяснения клиенту как все работает.
для прототипирования рекомендую Microsoft Sketchflow. На хабре есть несколько статей по нему
Да, мне тоже очень понравилось видео, ещё когда впервые промелькнуло на хабре. Правда в данный момент в роли ОС выступает linux, но это не такая проблема.
Не подскажите, есть ли там возможность создания например html версии, что бы представить заказчику, выложив на сервер?
Не подскажите, есть ли там возможность создания например html версии, что бы представить заказчику, выложив на сервер?
НЛО прилетело и опубликовало эту надпись здесь
для прототипирование нравится SketchFlow.
Никогда не понимал почему Mindmap переводят как «карта памяти» — смысла в этом словосочетании ну никакого. Википедия подсказывает, что скорее Диаграмма связей, хотя и утверждают, что «Иногда в русских переводах термин может переводиться как «карты ума», «карты разума», «интеллект-карты», «карты памяти», «ментальные карты», «ассоциативные карты», «ассоциативные диаграммы» или «схемы мышления».»
Для рисования/прототипирования можно использовать бесплатный Pencil — pencil.evolus.vn/en-US/Home.aspx Последние версии имеют неплохие наборы элементов.
Сколько раз мне давали тех задания и все они были составлены некомпетентными людьми. В большинстве своем просто скопированные из сети. Поэтому делаю всегда как надо и объясняю клиенту что так лучше. А иногда лучше вообще не давать клиенту выбор: вам как хочется так или так. Порой лучше просто сделать. А если дашь клиенту выбор, то он покажет вам всю свою нерешительность и начнутся метания.
Жесть какая.
«Я сначала работаю менеджером продукта, потом архитектором БД, а под конец юзабилистом-интерфейсером».
При этом, что забавно — звена «менеджер проекта» и «программист» тут почему-то нет.
У нас проектирование БД гораздо более важный этап чем проектирование архитектуры кода?
«Я сначала работаю менеджером продукта, потом архитектором БД, а под конец юзабилистом-интерфейсером».
При этом, что забавно — звена «менеджер проекта» и «программист» тут почему-то нет.
У нас проектирование БД гораздо более важный этап чем проектирование архитектуры кода?
Блин, рано коммент опубликовался:
Хм, что-то у меня по ctrl+v форма постится вместо вставки из буфера:
Вы чем там вообще занимаетесь? Кто Вы? На кого ориентированы эти «советы»? Я не придираюсь, мне и вправду непонятно…
Вы чем там вообще занимаетесь? Кто Вы? На кого ориентированы эти «советы»? Я не придираюсь, мне и вправду непонятно…
Это ориентировано на небольшие студии с их не самыми серьезными проектами, без попытки замахнуться на самописные сообщества с кучей кода).
Естественно, намного правильнее, когда прототипирование делает человек, который понимает в юзабилити, а не в построение БД – статья о том что делать, а как уже на совести коллектива.
Естественно, намного правильнее, когда прототипирование делает человек, который понимает в юзабилити, а не в построение БД – статья о том что делать, а как уже на совести коллектива.
DDD в действии, не? :)
А вообще при активном использовании фреймворков диапазон архитектурных решений заметно уменьшается, сводясь чуть ли не к принятию решений уровня «оставить метод в контроллере или всё же ему место в модели». А использование фреймворков (своих или чужих — не важно даже) при производстве большого количества типовых решений, как правило, оправдано экономически.
А вообще при активном использовании фреймворков диапазон архитектурных решений заметно уменьшается, сводясь чуть ли не к принятию решений уровня «оставить метод в контроллере или всё же ему место в модели». А использование фреймворков (своих или чужих — не важно даже) при производстве большого количества типовых решений, как правило, оправдано экономически.
Мы для проектирования БД и связей между ними в университете на начальных этапах использовали ERWin. В принципе, тоже все было наглядно и поозрачно, какие таблицы нкоьходимо связать между собой, где будут ключи и т.п.
Спасибо, статья очень понравилась!
Давно уже собирался начать пользоваться Mindmap, да никто нормально не мог объяснить как это делается, хоть в принципе…
Спасибо за пример.
Давно уже собирался начать пользоваться Mindmap, да никто нормально не мог объяснить как это делается, хоть в принципе…
Спасибо за пример.
Идеалы, идеалы и ещё раз идеалы!
Да действительно так красивее, быстрее, удобнее, и я вообще люблю методологии, анализ — проектирование — разработка — внедрение. Все это так и должно быть. Но даже для среднего проекта, я не беру в расчет документацию (ТЗ, Руководство пользователя, Руководство Администратора, Методика Испытаний, и Календарный план — это святое и без этого некуда) это тоже накладно. Прототипирование интерфейса, схемы базы данных, я бы ещё добавил Use Case в место MindMap, так как тоже наглядная вещь (Вообще UML — это наше всё!) — всё это затратит время специалистов.( В данный момент я не рассматриваю одного разработчика с ИП или Фрилансера, почитавшего умные книжки и готового рисовать и разрабатывать в одиночку). На всё это уйдет время менеджера, или у кого то архитектора, дизайнера, программистов, а это собственно говоря и есть деньги. И даже для средних проектов, это будет неплохой довесок в стоимость разработки. Я не говорю про Москву, я сам с региона, и у нас не получиться взять с заказчика 50 тысяч за сайт визитку или хотя бы 150 — 200 за интернет магазин, чтобы окупить затраты на все эти плюшки, ценность которых я ни сколько не уничижаю. Работая в жесточайшей конкуренции, когда на рынке выбирают что дешевле, а не что лучше, когда студенты и микро-студии предлагают Интернет-магазины написанные на osCommerce за 30 тысяч, и сайты на Joomla за 10 тысяч, не получается следовать стандартам, и делать всё по уму (Хотя конечно очень хочется). Как уже писалось на Хабре, огромное количество заказчиков не понимают ценообразования в отрасли, и практически невозможно доказать что у тебя сайт за 50 тысяч, будет на порядки лучше чем у них за 6 тысяч. Алчность будет побеждать ещё долго, и чтобы быть на плаву, нужно чем то жертвовать, в чем то отходить от этапов, в чем то уменьшать детализацию, находить баланс между ценой разработки, временем разработки, полученной прибылью и желаниями заказчика.
Да действительно так красивее, быстрее, удобнее, и я вообще люблю методологии, анализ — проектирование — разработка — внедрение. Все это так и должно быть. Но даже для среднего проекта, я не беру в расчет документацию (ТЗ, Руководство пользователя, Руководство Администратора, Методика Испытаний, и Календарный план — это святое и без этого некуда) это тоже накладно. Прототипирование интерфейса, схемы базы данных, я бы ещё добавил Use Case в место MindMap, так как тоже наглядная вещь (Вообще UML — это наше всё!) — всё это затратит время специалистов.( В данный момент я не рассматриваю одного разработчика с ИП или Фрилансера, почитавшего умные книжки и готового рисовать и разрабатывать в одиночку). На всё это уйдет время менеджера, или у кого то архитектора, дизайнера, программистов, а это собственно говоря и есть деньги. И даже для средних проектов, это будет неплохой довесок в стоимость разработки. Я не говорю про Москву, я сам с региона, и у нас не получиться взять с заказчика 50 тысяч за сайт визитку или хотя бы 150 — 200 за интернет магазин, чтобы окупить затраты на все эти плюшки, ценность которых я ни сколько не уничижаю. Работая в жесточайшей конкуренции, когда на рынке выбирают что дешевле, а не что лучше, когда студенты и микро-студии предлагают Интернет-магазины написанные на osCommerce за 30 тысяч, и сайты на Joomla за 10 тысяч, не получается следовать стандартам, и делать всё по уму (Хотя конечно очень хочется). Как уже писалось на Хабре, огромное количество заказчиков не понимают ценообразования в отрасли, и практически невозможно доказать что у тебя сайт за 50 тысяч, будет на порядки лучше чем у них за 6 тысяч. Алчность будет побеждать ещё долго, и чтобы быть на плаву, нужно чем то жертвовать, в чем то отходить от этапов, в чем то уменьшать детализацию, находить баланс между ценой разработки, временем разработки, полученной прибылью и желаниями заказчика.
Да, всё это минусы в отрасли, а как с ними бороться каждый решает сам, но однозначного ответа нет(.
Действительно, порой это слишком накладно, тут либо отказываться от подобных задач, либо пытаться снизить расходы. Я лично вижу решение проблемы недорогих сайтов в унификации, подготавливаем стандартный набор документов, который корректируем в некоторых рамках. А вот эти рамки надо четко предоставлять заказчику, а выход за них должен и оплачиваться дополнительно.
Спасибо за такой развернутый комментарий :)
Действительно, порой это слишком накладно, тут либо отказываться от подобных задач, либо пытаться снизить расходы. Я лично вижу решение проблемы недорогих сайтов в унификации, подготавливаем стандартный набор документов, который корректируем в некоторых рамках. А вот эти рамки надо четко предоставлять заказчику, а выход за них должен и оплачиваться дополнительно.
Спасибо за такой развернутый комментарий :)
Составить перечень страниц — это накладно?
Как же вы сайт сдаёте, не договорившись с заказчиком о перечне страниц?
Как же вы сайт сдаёте, не договорившись с заказчиком о перечне страниц?
У меня за спиной более 50 проектов на джанге комерческих за 2010 год. я проектирование сайта начинаю с базы данных в повер дизайнере.
То, что вы показали имхо нагружено сильно очень.
а за этот кусок базы простите школьника я бы рукы вырвал — уж больно много раз я переделывал на нормальную структуру с такой которую представили вы — ни индексов, варчар 256, варчар 64 — вот у меня вопрос куда вы все время экономите! КУДА ???? варчар это не чар дал ему 1024 и нормально. куда все время идет уменьшение( уж простите не сдержался простите Ради Бога)
То, что вы показали имхо нагружено сильно очень.
а за этот кусок базы простите школьника я бы рукы вырвал — уж больно много раз я переделывал на нормальную структуру с такой которую представили вы — ни индексов, варчар 256, варчар 64 — вот у меня вопрос куда вы все время экономите! КУДА ???? варчар это не чар дал ему 1024 и нормально. куда все время идет уменьшение( уж простите не сдержался простите Ради Бога)
Это не рабочий пример и я не занимаюсь проектирование БД, в этом плане мы оба можем спать спокойно :) Спасибо за комментарий)
в том то и ошибка многих, что о базе никто не думает. а думают когда она уже начинает тормозить! и не работать.
Ну почему же не думает — это первая задача программиста после утверждения функционала, подписания тз и т.д.
Если конечно сайт того требует, а не создается с помощью кмс.
Хотя стоит признать, что внимания этому действительно уделяется недостаточно, особенно, когда возникает необходимость к готовой системе дописать новый кусок.
Если конечно сайт того требует, а не создается с помощью кмс.
Хотя стоит признать, что внимания этому действительно уделяется недостаточно, особенно, когда возникает необходимость к готовой системе дописать новый кусок.
Я вот вечно тыкаю TEXT, скажите — это плохо и я ламо?)
Если говорить про mysql — то есть несколько отличий и они иногда могут играть существенную роль
1) основное — когда запрос требует создания временной таблицы, то сначала будет попытка разместить таблицу в памяти, однако если у вас в запросе участвует blob или text то она сразу же будет создана на диске.
2) вы не можете делать индексы по полям text, что может быть важно если у вас есть сортировка по этим полям
ну и вобще — то что чуть выше написано — так яростно говорить что 1024 лучше 256 наверное все же не стоит, на все нужно смотреть с нескольких точек зрения, так, например, ограничение по длине 64 говорит программисту который уже это все верстает, что это поле помещается в определенное пространство в одну строку и что не надо пытаться тут придумывать всякие ухищрения для отображения части которая не влезает на экран или переносится на другую строку.
Ведь обычно как — отдел QA попытается ввести в поле поэму «Евгений Онегин» и создадут на эту тему кучу баг-репортов, что несколько экранов «разъехались» из-за этой строки… а когда у вас 64 в базе стоит ограничение, все что сделает отдел QA — допишет в инструкцию, что длина данного поля составляет 64 символа и к разработчику уже не вернется…
Но не стоит мой комментарий рассматривать как защиту того что всегда надо минимум делать… я лишь хотел обратить внимание, что может быть больше чем одна точка зрения и все они вобщем-то имеют смысл…
1) основное — когда запрос требует создания временной таблицы, то сначала будет попытка разместить таблицу в памяти, однако если у вас в запросе участвует blob или text то она сразу же будет создана на диске.
2) вы не можете делать индексы по полям text, что может быть важно если у вас есть сортировка по этим полям
ну и вобще — то что чуть выше написано — так яростно говорить что 1024 лучше 256 наверное все же не стоит, на все нужно смотреть с нескольких точек зрения, так, например, ограничение по длине 64 говорит программисту который уже это все верстает, что это поле помещается в определенное пространство в одну строку и что не надо пытаться тут придумывать всякие ухищрения для отображения части которая не влезает на экран или переносится на другую строку.
Ведь обычно как — отдел QA попытается ввести в поле поэму «Евгений Онегин» и создадут на эту тему кучу баг-репортов, что несколько экранов «разъехались» из-за этой строки… а когда у вас 64 в базе стоит ограничение, все что сделает отдел QA — допишет в инструкцию, что длина данного поля составляет 64 символа и к разработчику уже не вернется…
Но не стоит мой комментарий рассматривать как защиту того что всегда надо минимум делать… я лишь хотел обратить внимание, что может быть больше чем одна точка зрения и все они вобщем-то имеют смысл…
Понятно, на VPS с маленьким объемом RAM получается TEXT выгоднее))))
Может быть, но как я написал, «иногда могут играть существенную роль»… это все к тому же — различные варианты возможны…
есть же как минимум два подхода — на вопрос почему сделано так или иначе можно привести кучу технических тезисов, привести тесты производительности, расписать варианты нагрузок и т.д… а можно просто ответить что так принято у нас в компании, и второй вариант кстати не лишен свой привлекательности, так как снижает издержки на принятие решения.
есть же как минимум два подхода — на вопрос почему сделано так или иначе можно привести кучу технических тезисов, привести тесты производительности, расписать варианты нагрузок и т.д… а можно просто ответить что так принято у нас в компании, и второй вариант кстати не лишен свой привлекательности, так как снижает издержки на принятие решения.
а когда у вас 64 в базе стоит ограничение, все что сделает отдел QA — допишет в инструкцию, что длина данного поля составляет 64 символа и к разработчику уже не вернется…
Угу, и ещё кучу баг-репортов, что не влазит больше 32 русских букв или 16 нот. Они такие.
1. текст нужно тыкать, как вы говорите только в те поля, которые требуют того.
2. на текст поставить простой индекс будет сложно так как если поле большое, то вставка вызовет ошибку — я говорю про постгре.
2. на текст поставить простой индекс будет сложно так как если поле большое, то вставка вызовет ошибку — я говорю про постгре.
А чего не сразу варчар 65535?
И индексы ставить бездумно на каждое поле тоже смысла не вижу
И индексы ставить бездумно на каждое поле тоже смысла не вижу
хоть и банально и знакомо, однако 241 закладка на статью :))
А нам ведь совсем не нужен вариант, что в середине работы мы вдруг узнаем, что подробный каталог продукции, который мы обсуждали и уже практически реализовали технически, на самом деле будет статической страничкой с прайс-листами, а всё, что нам так усердно рассказывал заказчик — это внутренняя структура прайс-листов, которую мы и не увидим никогда!
ИМХО, не правильный подход.
Заказчики делают сайты не каждый день, в отличие от нас с вами. И они имеют право не разбираться в тонкостях.
И задача менеджера проектов — врубится в сферу деятельности заказчика, изучить его продукцию, изучить конкурентов и предложить решения.
А не спрашивать «а что у нас будет на этой страничке?» или «сколько уровней будет в каталоге?».
hotgloo.com понравился, спасибо.
Мы для прототипов используем Axure.
ИМХО, не правильный подход.
Заказчики делают сайты не каждый день, в отличие от нас с вами. И они имеют право не разбираться в тонкостях.
И задача менеджера проектов — врубится в сферу деятельности заказчика, изучить его продукцию, изучить конкурентов и предложить решения.
А не спрашивать «а что у нас будет на этой страничке?» или «сколько уровней будет в каталоге?».
hotgloo.com понравился, спасибо.
Мы для прототипов используем Axure.
Правильный или нет это подход зависит ещё от ценовой политики. Полностью поддерживаю, что правильнее — именно так, как вы описали, если конечно это возможно по совокупности причин.
Суть абзаца в том, что в любом случае придется утверждать ТЗ и в общих интересах, что бы все максимально точно понимали, что там написано – тут на помощь и приходят понятные всем mindmaps.
ps:
Вы наверняка сталкивались со случаем, когда заказчик не разбирается в тонкостях, но упорно этого не признает и гнет свою линию — наверное самый неприятный момент.
Суть абзаца в том, что в любом случае придется утверждать ТЗ и в общих интересах, что бы все максимально точно понимали, что там написано – тут на помощь и приходят понятные всем mindmaps.
ps:
Вы наверняка сталкивались со случаем, когда заказчик не разбирается в тонкостях, но упорно этого не признает и гнет свою линию — наверное самый неприятный момент.
А что за софт для mindmap вы использовали?
Xmind ( www.xmind.net/ ) на базе eclipse
А подобие Balsamic Mockups для linux есть?
Что почитать о проектирование баз данных для новичка?
Знаком только с синтаксисом MySQL, но как из этого сделать полноценную БД- не знаю.
Знаком только с синтаксисом MySQL, но как из этого сделать полноценную БД- не знаю.
Это думаю стоит у AlienZzzz (выше по комментариям спросить) :)
Ну а я у вас спрашиваю
Я не занимаюсь проектированием баз, в статье просто расписан подход, соответственно и подобной литературы не подскажу.
На деле же, база данных — это набор таблиц и связей между её полями, который можно создать используя как консоль (с помощью SQL), так и специальный софт (phpMyAdmin, SQLyog, MySQL Workbench). Виды и поля этих таблиц определяются Вашими задачами.
Думаю для понимания подойдет любая статья в гугле про создание сайтов на php+mysql
На деле же, база данных — это набор таблиц и связей между её полями, который можно создать используя как консоль (с помощью SQL), так и специальный софт (phpMyAdmin, SQLyog, MySQL Workbench). Виды и поля этих таблиц определяются Вашими задачами.
Думаю для понимания подойдет любая статья в гугле про создание сайтов на php+mysql
Можете глянуть мои методички: ru-mysql.livejournal.com/101612.html
Вот вы добрались до методов проектирования, которые помогают: 1) сделать систему вовремя; 2) сдать систему; 3) получить свои деньги и может даже чтобы 4) заказчик остался доволен процессом сотрудничества.
Ещё лет через 5 вы задумаетесь о том, что есть методы проектирования, которые помогают: 1) сделать систему, которая действительно нужна заказчику и 2) которая приносит ему ощутимую пользу и 3) которая окупается хорошо и быстро.
Ещё лет через 5 вы задумаетесь о том, что есть методы проектирования, которые помогают: 1) сделать систему, которая действительно нужна заказчику и 2) которая приносит ему ощутимую пользу и 3) которая окупается хорошо и быстро.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой подход к проектированию веб-сайтов