Мой подход к проектированию веб-сайтов

Прелюдия


image Вероятно, всем известно и все прекрасно понимают, что главной частью в работе над программным продуктом, будь то сайт или настольное приложение, является совсем не процесс написания кода. Под словом главный я не подразумеваю время, которое уходит на этапы разработки, я имею ввиду наиболее важный этап, который определяет успешность дальнейшей работы над проектом. Трудно будет получить автомобиль, если на бумаге уже расписано создание велосипеда!

В рамках данной статьи я поделюсь своим опытом проектирования сайтов средней сложности. Данный подход зарекомендовал себя понятным как разработчикам, так и клиентам. Я не собираюсь открывать Америку, представленные ниже инструменты всем прекрасно знакомы. Суть данной статьи как раз в том, что бы продемонстрировать насколько просто можно представить достаточно сложные задачи.



Всё начинается с…


Существует два варианта начала работы над проектом: идеальный и неидеальный.

картинка тут, да1) Идеальный вариант подразумевает, что заказчик представляет контору, которая знает, чего хочет достичь, и имеет на руках подготовленное ТЗ. Изучить, внести незначительные коррективы и благополучно реализовать всегда намного проще, чем вытягивать у клиента эту информацию.

2) «Неидеальный вариант» обычно хочет, что бы всё летало, в каждом углу были анимированные часики, но при этом никак не может определиться что же за информацию необходимо разместить на сайте. А нам ведь совсем не нужен вариант, что в середине работы мы вдруг узнаем, что подробный каталог продукции, который мы обсуждали и уже практически реализовали технически, на самом деле будет статической страничкой с прайс-листами, а всё, что нам так усердно рассказывал заказчик — это внутренняя структура прайс-листов, которую мы и не увидим никогда! Для того, что бы избежать данных трений, с такими заказчиками приходится совместно заниматься разработкой технического задания.
Но текст является не лучшим способом преподнесения информации, а главное не самым интуитивным. Поэтому прежде, чем задокументировать в строчках будущий проект бывает неплохо его доступно проиллюстрировать и обсудить.

… И тут на помощь приходят они!

Mindmap, создаем структуру сайта


Основной плюс создания структуры сайта с использованием карт памяти заключается в простоте и интуитивности данного решения. Заказчики обычно очень положительно реагируют на “данные картинки”, особенно если они оформлены должным образом без использования техники “вырви глаз, заметь меня”.

Так же не стоит ограничиваться лишь возможностью использовать древовидные структуры, надо пойти немного дальше: использовать цветовое кодирование, использовать понятные формы, значки и другие графические элементы, которые позволят упростить восприятие.

Пример 1:
image

На данной схеме приведена структура неповторимого сайта DevSite, который отличается от всех своей уникальностью и новаторской структурой.

Описание схемы:
  • элементы желтого цвета — это сущности, физические разделы сайта
  • элементы серого цвета — условные разделы для группировки в нем элементов (раздел Пользователи)
  • черные прямоугольники — функциональные элементы страницы, которые несут за собой некоторую логики или действия
  • восстановление пароля в разделе пользователи является всплывающим окном или вы уже догадались?


Пример 2:
image

Использование таких иконок довольно полезно для изображения среза, текущего состояния проекта или постановки задачи, отображая текущее состояние дел.
Кстати для построения карт я использую XMind, которая предоставляет все вышеперечисленные плюшки, рекомендую посмотреть.

Так же помимо вышепредставленных элементов можно изображать вспомогательные элементы на этой же карте, такие маленькие подкарты и организовывать связи между ними и основной схемой. Иногда полезно представить часть информации ввиде таблицы.

БД


Проектирование базы данных – тот этап, куда заказчик не суется, но это не значит, что стоит относиться к этапу со словами “мы 100 раз это делали, нам и так всё ясно”. Когда ведешь проект красиво, работа над ним приносит намного больше положительных эмоций и не превращается в рутину.

При этом я не призываю делать повторно какие-то стандартные элементы, их действительно зачастую проще взять из предыдущих проектов, либо они уже существуют и давно спроектированы в рамках применяемой системы управления. Что же касается вновь проектируемых и создаваемых элементов, то этап проектирования БД порой позволяет выявить упущенные на этапе создания структуры части разрабатываемой системы, лучше их осознать и скорректировать её свойства и связи.

Ну и конечно же не малую роль играет удобство, лично мне намного приятнее слепить БД в софте типа MySQL Workbench и экспортировать результат в SQL, предварительно проставив связи, ключи свойства и визуально проверив результат. В любом случае это намного удобнее, чем самый распространенный способ заполнения БД в phpMyAdmin

Скрин таблицы из MySQL Workbench
image

Прототипирование, создание wireframe’ов


Этот этап довольно накладен и прибегать к нему стоит тогда, когда это действительно нужно. В основном имеет смысл на сайтах и сообществах с большими объемами информации, а так же на страницах с большим количеством управляющих элементов. Часто имеет смысл прибегнуть к созданию wirefram’ов для отдельных элементов системы, как например системы фильтрации и гибкого поиска или наоборот для очень общих элементов, таких как расположение больших блоков на сайте (меню, контент, столбцы, думаю понятно).

Но стоит иметь ввиду, что грамотно пройденный этап прототипирования и утверждения данных макетов у заказчика, может сэкономить кучу нервов Вам и дизайнеру, работающему над полноценным дизайном, а не структурой.

image
Скриншот с tarekshalaby.com по наводке google image search

В качестве инструмента не буду советовать какой-то конкретный, так как сам ещё окончательно не определился. Лично приходилось работать с настольным приложение Balsamic Mockups и веб-сервисом Hotgloo. Hotgloo конечно интересен тем, что можно сделать макеты с переходом по ссылкам и пародиями на такие действия как “положить товар в корзину”, но мне не очень нравится его ценовая политика, а иногда просто удобнее использовать настольное приложение.

image
Скриншот с оффсайта Balsamic Mockups

В Заключение


Данная статья ориентирована в первую очередь на небольшие веб-студии, менеджеров и руководителей проектов, отдельных фрилансеров, занимающихся веб разработкой или участвующих в цепочке разработки. Как видно простой подход с использованием mindmap’ов позволяет не просто разложить структуру, а сделать постановку задачи более наглядной для её исполнителей, отразив как текущее состояние, так и свойства, представленных в структуре сущностей. Но, как ни странно, этот стандартный заложенный в софт функционал зачастую остается незамеченным и невостребованным. Обидно!

Спасибо за чтение и желаю Вам интересных и красивых проектов в 2011 году!
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 68
  • +2
    Надеюсь, я тоже когда-то научусь проектировать
    А то все как-то в голове, да в голове, да «примерно как-то вот так», а потом вспоминай сиди что ты там как-то раз, сидя на кухне, придумал
    • 0
      Ну тут обычно важнее не спроектировать, а успеть записать пока мысли из головы не пропали :) А то действительно потом начинаешь вспоминать, что, где, как, а представления четкого уже нет.
      • +1
        «Кстати, важный момент — очень помогает писать на обратной стороно [разлинованной в клетку] бумаги, чтобы линии разметки не доминировали в чертеже!» Ⓒ Сэймур Крэй
    • +1
      Для небольших сайтов достаточно тз/брифа, а вот для крупных проектов без проектирования и т.д.
      Сам стараюсь с сайтами сложнее визиток/банальных ИМ расписывать все на бумаге и рисовать эскизы интерфейсов.
      • 0
        Да, естественно для сайтов из 5 страничек вырисовывать кучу картинок и проетировать интерфейс — это круто, но не очень разумно. А когда задача усложняется, полезно строить схемы даже для собственного понимания, да и приносит положительные эмоции, что всё делается четко.
        • +6
          Разумно-разумно. Если проект маленький, значит технологическая цепочка просто будет быстрее прогоняться.
          • +3
            удивляет, что народ до сих пор меряет сложность работы «страничками». чаще всего нестыковки с заказчиком именно в этом — всех интересует цена джамшутовского метра квадратного, не понимают что страничка страничке рознь.
            • 0
              Ну в данном случае под пятью страничками, я подразумевал слово «простой», обычно состоящий из статики.

              Но вот с точки зрения общения с заказчиком действительно приходится сталкиваться с удивлениями «почему столько стоит, это же всего одну страничку добавить» :)
        • +3
          Для небольших сайтов можно прорисовать все что угодно с самого начала и это будет 90% работы.

          Для крупных проектов делать все вышеуказанное одному человеку невозможно. И это учитывая, что куча этапов тут не расписаны как суть.
          • 0
            Да, Дмитрий, поэтому я указал в статье, что это относится к средней по сложности сайтам.

            Хотя сайт на подобии покерофа данным образом спроектировать можно, но естественно не только с одной ассоциативной картой и этапов будет больше, придется ограничивать вложенность пунктов и раскрывать что-то по-отдельности.

            Некоторые вещи придется менять уже на живом сайте (юзайбилити на 100% обычно не предусмотреть и всё равно нужно будет корректировать по инфе от пользователей), что у Вас так же происходило и мне, как одному из Ваших пользователей, нравится, что получилось в итоге.
        • +2
          Как же хорошо, когда структура подобным образом утверждается до дизайнерской работы. На практике чаще приходится сталкиваться с готовым дизайном, напрочь оторванным от реальности. В этом случае подход немного иной, можно составить карту блоков и элементов по существующему дизайну и утвердить с заказчиком связи между всем этим
          • +1
            Абсолютно верное замечание и полезный совет про «комбирование блоков», действительно бывает, что приходится готовые элементы пытаться адаптировать, но это не всегда так просто как звучит оказывается.
          • +1
            «что главной частью в работе над программным продуктом, будь то сайт...» — я бы сказал, что логичнее называть сайт не «программным продуктом», а инструментом продаж.

            Уже с самого начала статьи чувствуется, что над проблемой работал программист, а должен проектированием сайта заниматься менеджер проекта. Увы, это и приводит часто к тому что сайт «на аяксе» и всё в нем летает, а продают больше конкуренты.

            • +1
              Проектированием сайта (хоть горшком назови) должен заниматься архитектор-проектировщик, у менеджера проекта другие задачи. Последний раз я видел спроектированный менеджером интернет магазин, главная страница которого открывалась 20 секунд.

              На практике в большинстве маленьких веб-студий «проектированием сайта» занимается «специалист по работе с клиентами» стремясь продать клиенту как можно больше готовых блоков, которые уже написаны программистами студии, и внимательно следя, за «удовлетворенностью клиента», что приводит к получению програмистами задач, реакция на которых (дословно) звучит так: «Я конечно могу, но лучше бы я этого не делал». Результат — предсказуем.
              • +1
                если после работы менеджера страница открывается 20 секунд, значит, скорее всего эту страницу делал сам менеджер :) А на самом деле это косяк программиста — в его задачи входит сделать так чтоб такого не было.
            • 0
              Очень полезно, как для составления структуры сайта так и для объяснения клиенту как все работает.
              • 0
                для прототипирования рекомендую Microsoft Sketchflow. На хабре есть несколько статей по нему
                • 0
                  Да, мне тоже очень понравилось видео, ещё когда впервые промелькнуло на хабре. Правда в данный момент в роли ОС выступает linux, но это не такая проблема.

                  Не подскажите, есть ли там возможность создания например html версии, что бы представить заказчику, выложив на сервер?
                  • 0
                    там есть возможность сделать silverlight-приложение и выложить на сервер и даже linux =), надо только чтоб заказчик был под виндой и смог установить себе плагин
                    • 0
                      Спасибо, буду иметь ввиду :)
                  • +3
                    А чем оно за 600$ лучше balsamiq mockups за 80$?
                    • 0
                      Бог с вами! Кто задумывается о такой мелочи, как $600? У нас же всё бесплатно! Страна коммунизма, чоуштам.
                  • 0
                    для прототипирование нравится SketchFlow.
                    • +1
                      Никогда не понимал почему Mindmap переводят как «карта памяти» — смысла в этом словосочетании ну никакого. Википедия подсказывает, что скорее Диаграмма связей, хотя и утверждают, что «Иногда в русских переводах термин может переводиться как «карты ума», «карты разума», «интеллект-карты», «карты памяти», «ментальные карты», «ассоциативные карты», «ассоциативные диаграммы» или «схемы мышления».»
                      • 0
                        Это я по непривычке называть их как-то кроме mindmap на англ., согласен с Вами, карта памяти довольно бессмысленное выражение.
                      • +2
                        Для рисования/прототипирования можно использовать бесплатный Pencil — pencil.evolus.vn/en-US/Home.aspx Последние версии имеют неплохие наборы элементов.
                        • 0
                          Спасибо, никогда не сталкивался с Pencil, но по скриншотам достаточно удобно — попробую!)
                          • 0
                            Штука и правда хорошая, но у меня так и не вышло экспортить результат в PDF. Поэтому на выходе получаю HTML-ку со встроенными «картами» :(
                          • +1
                            Сколько раз мне давали тех задания и все они были составлены некомпетентными людьми. В большинстве своем просто скопированные из сети. Поэтому делаю всегда как надо и объясняю клиенту что так лучше. А иногда лучше вообще не давать клиенту выбор: вам как хочется так или так. Порой лучше просто сделать. А если дашь клиенту выбор, то он покажет вам всю свою нерешительность и начнутся метания.
                            • 0
                              В торговле у продавцов такое правило почти обязательно, предложить выбор между двумя вещами, что бы покупатель ничего не придумывал и не ломался. Он после такого действия себя психологически ограничивает, но в тоже время ему кажется, что есть выбор — хороший прием, да.
                            • +2
                              Жесть какая.
                              «Я сначала работаю менеджером продукта, потом архитектором БД, а под конец юзабилистом-интерфейсером».
                              При этом, что забавно — звена «менеджер проекта» и «программист» тут почему-то нет.

                              У нас проектирование БД гораздо более важный этап чем проектирование архитектуры кода?
                              • +1
                                Блин, рано коммент опубликовался:
                                • +2
                                  Хм, что-то у меня по ctrl+v форма постится вместо вставки из буфера:
                                  Вы чем там вообще занимаетесь? Кто Вы? На кого ориентированы эти «советы»? Я не придираюсь, мне и вправду непонятно…
                                  • 0
                                    Это ориентировано на небольшие студии с их не самыми серьезными проектами, без попытки замахнуться на самописные сообщества с кучей кода).

                                    Естественно, намного правильнее, когда прототипирование делает человек, который понимает в юзабилити, а не в построение БД – статья о том что делать, а как уже на совести коллектива.
                                • +3
                                  DDD в действии, не? :)

                                  А вообще при активном использовании фреймворков диапазон архитектурных решений заметно уменьшается, сводясь чуть ли не к принятию решений уровня «оставить метод в контроллере или всё же ему место в модели». А использование фреймворков (своих или чужих — не важно даже) при производстве большого количества типовых решений, как правило, оправдано экономически.
                                  • 0
                                    В точку, самое выгодное решение — это незаметно для заказчика приподнести ему уже максимально сложенные кубики и покрасить их в нужный цвет (дизайн).

                                    В таком случае mindmap можно применить для внесения ясности :)
                                • 0
                                  Мы для проектирования БД и связей между ними в университете на начальных этапах использовали ERWin. В принципе, тоже все было наглядно и поозрачно, какие таблицы нкоьходимо связать между собой, где будут ключи и т.п.
                                  • 0
                                    Я предпочитаю Sybase Power Designer
                                  • 0
                                    Спасибо, статья очень понравилась!
                                    Давно уже собирался начать пользоваться Mindmap, да никто нормально не мог объяснить как это делается, хоть в принципе…
                                    Спасибо за пример.
                                    • 0
                                      Спасибо, рад, что понравилось)
                                    • +1
                                      Идеалы, идеалы и ещё раз идеалы!
                                      Да действительно так красивее, быстрее, удобнее, и я вообще люблю методологии, анализ — проектирование — разработка — внедрение. Все это так и должно быть. Но даже для среднего проекта, я не беру в расчет документацию (ТЗ, Руководство пользователя, Руководство Администратора, Методика Испытаний, и Календарный план — это святое и без этого некуда) это тоже накладно. Прототипирование интерфейса, схемы базы данных, я бы ещё добавил Use Case в место MindMap, так как тоже наглядная вещь (Вообще UML — это наше всё!) — всё это затратит время специалистов.( В данный момент я не рассматриваю одного разработчика с ИП или Фрилансера, почитавшего умные книжки и готового рисовать и разрабатывать в одиночку). На всё это уйдет время менеджера, или у кого то архитектора, дизайнера, программистов, а это собственно говоря и есть деньги. И даже для средних проектов, это будет неплохой довесок в стоимость разработки. Я не говорю про Москву, я сам с региона, и у нас не получиться взять с заказчика 50 тысяч за сайт визитку или хотя бы 150 — 200 за интернет магазин, чтобы окупить затраты на все эти плюшки, ценность которых я ни сколько не уничижаю. Работая в жесточайшей конкуренции, когда на рынке выбирают что дешевле, а не что лучше, когда студенты и микро-студии предлагают Интернет-магазины написанные на osCommerce за 30 тысяч, и сайты на Joomla за 10 тысяч, не получается следовать стандартам, и делать всё по уму (Хотя конечно очень хочется). Как уже писалось на Хабре, огромное количество заказчиков не понимают ценообразования в отрасли, и практически невозможно доказать что у тебя сайт за 50 тысяч, будет на порядки лучше чем у них за 6 тысяч. Алчность будет побеждать ещё долго, и чтобы быть на плаву, нужно чем то жертвовать, в чем то отходить от этапов, в чем то уменьшать детализацию, находить баланс между ценой разработки, временем разработки, полученной прибылью и желаниями заказчика.
                                      • 0
                                        Да, всё это минусы в отрасли, а как с ними бороться каждый решает сам, но однозначного ответа нет(.

                                        Действительно, порой это слишком накладно, тут либо отказываться от подобных задач, либо пытаться снизить расходы. Я лично вижу решение проблемы недорогих сайтов в унификации, подготавливаем стандартный набор документов, который корректируем в некоторых рамках. А вот эти рамки надо четко предоставлять заказчику, а выход за них должен и оплачиваться дополнительно.

                                        Спасибо за такой развернутый комментарий :)
                                        • 0
                                          Составить перечень страниц — это накладно?
                                          Как же вы сайт сдаёте, не договорившись с заказчиком о перечне страниц?
                                        • 0
                                          У меня за спиной более 50 проектов на джанге комерческих за 2010 год. я проектирование сайта начинаю с базы данных в повер дизайнере.

                                          То, что вы показали имхо нагружено сильно очень.

                                          а за этот кусок базы простите школьника я бы рукы вырвал — уж больно много раз я переделывал на нормальную структуру с такой которую представили вы — ни индексов, варчар 256, варчар 64 — вот у меня вопрос куда вы все время экономите! КУДА ???? варчар это не чар дал ему 1024 и нормально. куда все время идет уменьшение( уж простите не сдержался простите Ради Бога)
                                          • 0
                                            Это не рабочий пример и я не занимаюсь проектирование БД, в этом плане мы оба можем спать спокойно :) Спасибо за комментарий)
                                            • 0
                                              в том то и ошибка многих, что о базе никто не думает. а думают когда она уже начинает тормозить! и не работать.
                                              • 0
                                                Ну почему же не думает — это первая задача программиста после утверждения функционала, подписания тз и т.д.
                                                Если конечно сайт того требует, а не создается с помощью кмс.

                                                Хотя стоит признать, что внимания этому действительно уделяется недостаточно, особенно, когда возникает необходимость к готовой системе дописать новый кусок.
                                            • 0
                                              Я вот вечно тыкаю TEXT, скажите — это плохо и я ламо?)
                                              • +1
                                                Если говорить про mysql — то есть несколько отличий и они иногда могут играть существенную роль
                                                1) основное — когда запрос требует создания временной таблицы, то сначала будет попытка разместить таблицу в памяти, однако если у вас в запросе участвует blob или text то она сразу же будет создана на диске.
                                                2) вы не можете делать индексы по полям text, что может быть важно если у вас есть сортировка по этим полям

                                                ну и вобще — то что чуть выше написано — так яростно говорить что 1024 лучше 256 наверное все же не стоит, на все нужно смотреть с нескольких точек зрения, так, например, ограничение по длине 64 говорит программисту который уже это все верстает, что это поле помещается в определенное пространство в одну строку и что не надо пытаться тут придумывать всякие ухищрения для отображения части которая не влезает на экран или переносится на другую строку.

                                                Ведь обычно как — отдел QA попытается ввести в поле поэму «Евгений Онегин» и создадут на эту тему кучу баг-репортов, что несколько экранов «разъехались» из-за этой строки… а когда у вас 64 в базе стоит ограничение, все что сделает отдел QA — допишет в инструкцию, что длина данного поля составляет 64 символа и к разработчику уже не вернется…

                                                Но не стоит мой комментарий рассматривать как защиту того что всегда надо минимум делать… я лишь хотел обратить внимание, что может быть больше чем одна точка зрения и все они вобщем-то имеют смысл…
                                                • 0
                                                  Понятно, на VPS с маленьким объемом RAM получается TEXT выгоднее))))
                                                  • 0
                                                    Может быть, но как я написал, «иногда могут играть существенную роль»… это все к тому же — различные варианты возможны…
                                                    есть же как минимум два подхода — на вопрос почему сделано так или иначе можно привести кучу технических тезисов, привести тесты производительности, расписать варианты нагрузок и т.д… а можно просто ответить что так принято у нас в компании, и второй вариант кстати не лишен свой привлекательности, так как снижает издержки на принятие решения.
                                                  • 0
                                                    а когда у вас 64 в базе стоит ограничение, все что сделает отдел QA — допишет в инструкцию, что длина данного поля составляет 64 символа и к разработчику уже не вернется…


                                                    Угу, и ещё кучу баг-репортов, что не влазит больше 32 русских букв или 16 нот. Они такие.
                                                  • –1
                                                    1. текст нужно тыкать, как вы говорите только в те поля, которые требуют того.
                                                    2. на текст поставить простой индекс будет сложно так как если поле большое, то вставка вызовет ошибку — я говорю про постгре.
                                                  • 0
                                                    А чего не сразу варчар 65535?

                                                    И индексы ставить бездумно на каждое поле тоже смысла не вижу
                                                    • 0
                                                      нет нет канешно индексы нужно с умом ))
                                                  • +1
                                                    хоть и банально и знакомо, однако 241 закладка на статью :))
                                                    • +1
                                                      А нам ведь совсем не нужен вариант, что в середине работы мы вдруг узнаем, что подробный каталог продукции, который мы обсуждали и уже практически реализовали технически, на самом деле будет статической страничкой с прайс-листами, а всё, что нам так усердно рассказывал заказчик — это внутренняя структура прайс-листов, которую мы и не увидим никогда!

                                                      ИМХО, не правильный подход.
                                                      Заказчики делают сайты не каждый день, в отличие от нас с вами. И они имеют право не разбираться в тонкостях.
                                                      И задача менеджера проектов — врубится в сферу деятельности заказчика, изучить его продукцию, изучить конкурентов и предложить решения.
                                                      А не спрашивать «а что у нас будет на этой страничке?» или «сколько уровней будет в каталоге?».

                                                      hotgloo.com понравился, спасибо.
                                                      Мы для прототипов используем Axure.
                                                      • 0
                                                        Правильный или нет это подход зависит ещё от ценовой политики. Полностью поддерживаю, что правильнее — именно так, как вы описали, если конечно это возможно по совокупности причин.

                                                        Суть абзаца в том, что в любом случае придется утверждать ТЗ и в общих интересах, что бы все максимально точно понимали, что там написано – тут на помощь и приходят понятные всем mindmaps.

                                                        ps:
                                                        Вы наверняка сталкивались со случаем, когда заказчик не разбирается в тонкостях, но упорно этого не признает и гнет свою линию — наверное самый неприятный момент.
                                                      • 0
                                                        А что за софт для mindmap вы использовали?
                                                      • 0
                                                        А подобие Balsamic Mockups для linux есть?
                                                        • 0
                                                          Ну Balsamic Mockups на adobe air и работает под linux'om
                                                        • 0
                                                          Что почитать о проектирование баз данных для новичка?
                                                          Знаком только с синтаксисом MySQL, но как из этого сделать полноценную БД- не знаю.
                                                          • 0
                                                            Это думаю стоит у AlienZzzz (выше по комментариям спросить) :)
                                                            • 0
                                                              Ну а я у вас спрашиваю
                                                              • 0
                                                                Я не занимаюсь проектированием баз, в статье просто расписан подход, соответственно и подобной литературы не подскажу.

                                                                На деле же, база данных — это набор таблиц и связей между её полями, который можно создать используя как консоль (с помощью SQL), так и специальный софт (phpMyAdmin, SQLyog, MySQL Workbench). Виды и поля этих таблиц определяются Вашими задачами.

                                                                Думаю для понимания подойдет любая статья в гугле про создание сайтов на php+mysql
                                                            • 0
                                                              Можете глянуть мои методички: ru-mysql.livejournal.com/101612.html
                                                            • 0
                                                              Вот вы добрались до методов проектирования, которые помогают: 1) сделать систему вовремя; 2) сдать систему; 3) получить свои деньги и может даже чтобы 4) заказчик остался доволен процессом сотрудничества.

                                                              Ещё лет через 5 вы задумаетесь о том, что есть методы проектирования, которые помогают: 1) сделать систему, которая действительно нужна заказчику и 2) которая приносит ему ощутимую пользу и 3) которая окупается хорошо и быстро.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.