Начальные этапы создания сайта — Веб-сайты, как и другие сложные структуры в материальном мире, требуют уникальной последовательности разработки и сборки. Следование этим шагам почти наверняка обеспечит достижение ожидаемых результатов. В реальных проектах разработка вообще не начинается с написания кода. Кодирование составляет лишь малую долю от общих трудозатрат. В разработке могут участвовать несколько человек с совершенно разным опытом.
Для начало создание сайта нужно подготовить ТЗ
Если вы работаете на клиента или сами являетесь заказчиком и исполнителем, вам необходимо хорошо представлять себе, какой сайт вы хотите создать. Без этого видения конечный результат заставит вас начинать все сначала, что явно не входит в ваши планы. Часто заказчики сами не знают, чего хотят, и не могут выразить свои потребности словами.
Вам нужно помочь им в этом, показать примеры и рассказать, как они собираются это использовать. Если вам нужно ввести новую единицу персонала (например, онлайн-чат), крутые возможности сайта конкурента могут показаться не такими уж привлекательными. Вам необходимо проанализировать, какие товары и для кого вы собираетесь демонстрировать на своем сайте, поскольку многое зависит от структуры сайта, его содержания, дизайна и методов продвижения. Вам необходимо тесно сотрудничать с вашими клиентами, поскольку они, скорее всего, знают о ваших товарах больше, чем вы.
Не стесняйтесь задавать глупые вопросы. После сбора информации разработчик должен составить техническое задание и предоставить его заказчику; ТЗ необходимо для того, чтобы
- обеих сторон, чтобы каждая удостоверилась, что хорошо понимает друг друга;
- заказчика, который ко времени завершения проекта забудет, что заказывал;
- всех специалистов, участвующих в процессе.
ТЗ пишется в свободной форме и подписывается сторонами. Это документ, позволяющий отстаивать свои права и заставляющий нести обязанности. В нем, помимо текста, могут быть блок-схемы, распечатанные схематические макеты веб-страниц, согласования цветовых палитр и пр.
Макет сайта и верстка макета
Если заказчик готов платить, создается дизайн/план будущего сайта. Дизайнер «рисует» сайт в графическом редакторе на основе грубых эскизов, приложенных к ТЗ. В конце он может уточнить детали или кардинально их изменить, а также четко указать, какой именно дизайн ожидается.
Сегодня уникальными дизайнами уже никого не удивишь. Более того, макеты приходится разрабатывать для нескольких экранных устройств, а на мобильных телефонах, с которых в интернет выходят более 85 % пользователей, приходится вычерчивать каждую закорючку, поэтому добавлять художественную изюминку практически бессмысленно. Тем не менее, компания платит за это.
Популярные причины, по которым избегают совсем уж уникальный дизайн:
- Покупателю не принципиально важно, какого цвета кнопка на сайте, если в общем сайт удобен.
- Коммерческий шаблон, как правило, будет всяко качественней в плане верстки, по сравнению со среднестатистическим уникальным.
- У заказчика изначально нет фирменного стиля, требующего своего присутствия и в интернете. Соблюдать ничего не нужно.
При наличии или отсутствии макета дизайнер верстки создает HTML-шаблон для сайта. Этот шаблон стилизуется с помощью CSS, а JavaScript используется для анимации, эргономики интерфейса и асинхронных запросов. Из-за сложности различных технологий, в зависимости от амбициозности проекта, за верстку может отвечать более одного человека.
Шаблоны создаются с учетом любого размера экрана, поэтому создание всего с нуля потребовало бы дополнительного времени и нескольких дней работы. Существуют специальные CSS-библиотеки (например, Bootstrap, Semantic UI, Uikit), настраиваемые CSS-сетки и готовые элементы интерфейса, которые могут значительно ускорить адаптивную верстку сайта.
Однако большинство таких сайтов очень похожи друг на друга. Библиотеки CSS имеют свои преимущества, но как насчет уникального дизайна? На самом деле, не все дизайнеры могут визуализировать свои макеты с учетом особенностей этих библиотек. Поэтому верстальщики и дизайнеры должны говорить на одном языке, чтобы избежать разногласий и неожиданностей.
У CSS-библиотек есть недостатки; куда же без них
- Конечный CSS-файл содержит много лишних стилей, которые каждый раз запрашиваются с сервера, что подтормаживает загрузку страницы.
- Добавляется новый уровень абстракции. Во многом вы оперируете не самими стилями, а уже готовыми классами, и это приводит некоторых в замешательство, препятствует быстрому решению нетривиальной задачи.
- Приходится «играть по правилам» библиотеки, иначе нет смысла ее использовать. Чтобы игра была выгодной для вас, инструмент нужно хорошо изучить.
Когда мы говорим о HTML-шаблоне, мы подразумеваем, что этот шаблон разрезан на части и запрограммирован. Иначе можно было бы сказать, что HTML-шаблон — это почти статичный сайт, страницы которого остается только скопировать и заполнить текстом и изображениями. Однако сегодня такое встречается редко.
Программирование сайта
В общем случае программирование сводится к тому, что сайт получает данные из базы данных (БД) и динамически генерирует HTML-страницы, либо сайт получает данные от пользователей и записывает их в БД. Это стандартная функция, присутствующая на большинстве сайтов. Именно здесь и возникает множество споров.
Кто-то использует CMS, кто-то пишет панель управления под конкретный проект. Суть ее в том, что владелец сайта получает возможность самостоятельно управлять контентом, следить за статистикой и отвечать на сообщения пользователей, отправленные через формы обратной связи. Программа, о которой идет речь, работает на удаленном сервере хостинг-провайдера, где также имеется сервер баз данных. Программа создается на PHP, Java и т.д., все зависит от уровня задачи. Поскольку в Интернете много шума вокруг CMS-ками, клиенты вряд ли могут доверять CMS-кам и быть уверенными, что вы не первооткрыватель. Однако у CMS, как и у доморощенного двигателя, есть две стороны медали.
Преимущества от использования CMS
- Бесплатность. Очень много достойных движков бесплатны, и для старта проекта это хорошее подспорье.
- Надежная поддержка. Бесплатные движки поддерживаются огромным интернет-сообществом энтузиастов, вам помогут найти любой ответ. Популярность движка также позволит подыскать другого специалиста, если прежний вас подвел.
- Много готовых модулей. Практически под любую задачу кто-то уже написал расширение для движка, которое остается только установить.
Недостатки CMS
- Чрезмерная универсальность. В попытке объять необъятное производители движков состязаются в поиске «серебряной пули». Чтобы показать простую веб-страницу, система выполняет длинную цепь логических задач, что сказывается на производительности сайта.
- Уязвимость. Ежедневно и ежечасно ведется работа над устранением слабых мест в системе, однако, противоположную работу ведут и злоумышленники, особенно когда система очень востребована в массах.
- Диктует свои жесткие правила, еще сильнее, чем фреймворки (готовые архитектурные каркасы), лишая программиста свободы мысли настолько, что конечные результаты очень похожи друг на друга.
Программирование сайта — сложная и ответственная работа. Если однажды не загрузилось изображение — не беда, — проблема, если чьи-то денежки ушли не туда. Поэтому код должен тщательно тестироваться как в момент написания, так и в целом, перед сдачей проекта.
Наполнение и тестирование
Любое содержимое должно отображаться в определенной форме, иметь допустимую ширину и высоту, а записи не должны пересекать эту границу. Таков замысел разработчика.
Что произойдет, если разработчик введет несколько названий товаров до 70 символов, владелец сядет за наполнение сайта, введет реальное название товара в 150 символов, и оно перейдет на следующую строку?
Блок под названием сдвигается вниз, создавая неожиданный эффект. Есть много вещей, которые могут показаться банальными, но они даже не имеют отношения к дизайну. Например, предположим, что в базу данных отправляется запись, превышающая допустимое количество символов. В целях оптимизации программист записал city как varchar (20), думая, что населенных пунктов с длинными названиями больше не будет.
Однако покупатель сказал, что живет в селе Старокозьмодемьяновское. Это только один пример. О чем эта история. Перед тем как передать проект, хотя бы один экземпляр (товар, статья, сообщение и т. д.) сайта должен быть наполнен каким-либо уникальным блоком. По возможности их должно быть больше.
В процессе наполнения появляются ошибки, которые раньше были незаметны. Каждая ссылка, каждый POST-запрос, каждая кнопка, включая 404 страницу, должны работать в соответствии с ТЗ. Тестирование — это особая часть разработки. Его рекомендуется поручать людям, которые никогда не писали тестируемый код и вообще далеки от программирования. Это связано с тем, что они могут выполнить на сайте действия, которые программисту могут не прийти в голову.
Что дальше?
Ведь после завершения проекта жизнь сайта должна не заканчиваться, а только начинаться. Нет предела совершенству, особенно когда технологии развиваются семимильными шагами.
Чтобы не отставать от конкурентов, необходимо вносить некоторые новшества. Разработчики предоставляют клиентам все инструменты администрирования: пароли от админ-панели и личного кабинета хостинг-провайдера.
Предоставляют краткие и, возможно, подробные инструкции по использованию сайта (как добавлять контент, как оплачивать хостинг и домены и т. д.). Постепенно сайт совершенствуется и переходит в стадию продвижения.
Процесс поддержки сайта не заканчивается, и вопрос о том, кто именно будет этим заниматься, уже является финансовым. Ценность сайта зарабатывается не в момент его первой публикации, а после нескольких лет планомерной работы.
Сайт получает трафик, его узнают, у него появляются постоянные клиенты, и все это приносит доход владельцу. Выше описана общая последовательность развития сайта. Это не значит, что вы должны следовать ей без оглядки. Для каждого человека все индивидуально.
Например, один из вариантов — сделать подготовку контента и наполнение на этапе создания сайта. Если заказчик готов положиться на мнение разработчика, он может обойтись без черновых или дизайн-макетов. Самый первый этап тоже не всегда проходит путь, многое опускается и, по сути, все решается на словах. Однако это касается небольших проектов. Иначе все может развалиться еще до того, как будет построено.
