После того, как закончите с мастер-страницами приступайте к каждому механизму отдельно. Опять же, проектируйте исходя из потребностей того или иного персонажа. Пусть он сам определяет как ему удобнее пользоваться сайтом.
Какие-то механизмы, возможно, будут совмещены на одном макете. Это решение надо также принимать на основании мнений персонажа. Здесь на все время забудьте о своем Я и полностью погрузитесь в мир своих персонажей подобно писателю романов или новелл.
Стоит особо отметить один макет, который обычно необходим на всех сайтах. Я говорю о макете страницы с типовым текстовым контентом. На вашем сайте в любом случае будут страницы с текстом и вы (вернее ваши персонажи) должны заранее решить, как будет выглядеть текст на вашем сайте.
В итоге после этой кропотливой работы вы получите список макетов, на которых представлена большая часть вашего сайта.
Желаете удобный сайт для вашего бизнеса?
Используйте проектирование взаимодействия.
А теперь попробуйте провести небольшое тестирование. Разложите все макеты на столе и попробуйте “побродить по сайту” в качестве каждого персонажа по очереди. Вы можете не рассматривать других людей, поскольку это не ваша целевая аудитория.
Допустим, вы показываете свои макеты человеку из своего окружения. Это могут быть ваши друзья, коллеги или родственники. Он говорит, что “тут все и так понятно” или, наоборот, ему ничего непонятно. Не принимайте близко к сердцу – он не из вашей целевой аудитории.
Что делать, если этот человек принадлежит целевой аудитории? Необходимо вернуться в своим персонажам и пересмотреть их. Возможно, их следует детализировать или даже видоизменить.
Задание. Используйте полученные знания для создания макетов страниц вашего будущего сайта.
Для каждого макета имеет смысл определить какие-то дополнительные текстовые требования, которые раскрывают динамику макета. Динамикой может быть движение некоторых элементов страницы при каких-то действиях посетителя (например, навел мышку на элемент). Это позволит исполнителю лучше понять задумку ваших макетов.
Также хорошей идеей будет определить макеты административной панели. Здесь вам уже не потребуются персонажи, поскольку главным персонажем в данном случае являетесь вы. Обычно принято для разработки административной панели выделять ресурсов меньше, чем для реализации лицевой части сайта (front-end). На мой взгляд, подобное распределение не является обоснованным по той причине, что вам самим в дальнейшем работать именно с этой частью сайта. И если она будет неудобная, это скажется на вашей производительности и эффективности.
Теперь вы знаете основы проектирования взаимодействия и умеете их применять для создания макетов интерфейса сайта.
Итак, мы определились с макетами, которые, по сути, составляют ядро ваших требований. Теперь можно перейти к составлению более специфичных требований.
Специфичные требования
Браузеры. В первую очередь, надо помнить, что сайт – это приложение, которое работает в браузерах. А браузеров – великое множество. Раньше, в 90-е года прошлого века и в начале 2000-х годов с этим вопросом была очень большая проблема, т.к., по сути, производители браузеров очень плохо выполняли стандарты разметки HTML. Особенно в этом плане отличился браузер Microsoft Internet Explorer. Перечислить все отличия этого браузера не представляется возможным, но это скорее проблемы разработчика, а не заказчика. В данный момент имеет смысл поддерживать браузеры Internet Explorer 8 и 9 версии.
Разница реализации движков браузерах приводила к тому что, что сайт выглядел по-разному в разных браузерах. Сейчас ситуация стала гораздо лучше, и различия в выводе интерфейса практически отсутствуют. Тем не менее, лучше сразу определиться с теми браузерами, которые должен поддерживать сайт.
Как мне понять, какие браузеры надо поддерживать, а какие нет? Очень просто. Существует интернет-статистика использования браузеров. Здесь я не буду приводить ссылку, т.к. статистика постоянно меняется. Просто наберите в Яндексе “Статистика использования браузеров 2013 год”. В этой статистике вы можете увидеть процент использования по каждому браузеру. Желательно знать статистику и по версиям браузеров, чтобы вы могли указать браузеры и их версии. К примеру, браузер Internet Explorer имеет версии 6,7,8,9. Версии 6,7 практически уже никто не использует. А вот версия 8 пока пользуется достаточно большой популярностью, чтобы списывать ее со счетов.
В итоге по браузерам у вас будет их список с указанием версий, в которых сайт должен выводиться и функционировать корректно.
Скорость и размер. Эти два параметра взаимозависимы. Чем меньше размер загружаемых страниц, тем быстрее работает сайт. Никому не нравится очень долго ждать, когда сайт подолгу загружает свои файлы. Эти требования хорошо бы прописать, чтобы подстраховаться от совсем долгой загрузки. Наверное, нет смысла формулировать “для всех страниц – время такое-то”. Гораздо лучше использовать следующую формулировку “для главной страницы – не более Х секунд, для 70% – не более Y секунд”. Скорость сайта – это критическая составляющая успеха сайта. Чем “легче” сайт, тем комфортнее чувствует себя посетитель. В качестве хорошего примера быстрого сайта рекомендую посмотреть сайт Википедии – очень много данных, но несмотря на это сайт “летает”.
Нагрузка на сайт. Допустим, вы сделали сайт. Все замечательно, он вам очень нравится. Сайт запускается. Но со временем происходит большой наплыв пользователей и сайт “падает”, т.е. не может больше обрабатывать запросы от посетителей. Это довольно сложно проверить на этапе разработки сайтов, только если программно, но и это не является гарантией от падений в дальнейшем по множеству причин. Дело в том, что здесь в игру вступают аппаратные ограничения хостинга или сервера, на котором работает ваш сайт.
Поэтому трудно просчитать всевозможные варианты эксплуатации сайта.
Самое главное, если вы готовитесь к массированному привлечению клиентов на свой сайт, вы должны включить требования в техническое задание по нагрузке на сайт, например, “сайт должен корректно функционировать при одновременной работе 1000 посетителей”. Это обяжет разработчиков более бережно относиться к серверным ресурсам. Это в первую очередь процессорное время, память, подключения к базе данных, пул http-соединений.
Мобильный интернет. Ни для кого не секрет, что мобильные телефоны набирают популярность как средство для выхода в интернет. На данный момент настольный интернет все-таки преобладает, но никто не знает, что будет в будущем. Если посетители вашего сайта будут использовать телефон для выхода в интернет, об этом также стоит упомянуть. Раньше для мобильников создавался отдельный сайт с урезанным функционалом. Сейчас, когда стандарты набирают силу, есть возможность делать сайты и для настольных браузеров и для мобильников. Здесь есть один момент – сайт под мобильные устройства может быть адаптируемым, т.е. контент сайта не требует горизонтальной прокрутки. Это так называемый Responsive Design в котором ширина меняется динамически в зависимости от параметров и возможностей браузера. Второй вариант – это более распространенный дизайн с фиксированной шириной макета. Это приводит к тому, что в мобильном браузере появляется горизонтальная прокрутка. Это менее удобно, чем первый вариант, но гораздо проще в реализации и сопровождении.
Ограничение на технологии. В моей практике был такой случай, когда введение ограничения на технологии привело к довольно большим финансовым затратам. Этот проект был разбит на две части, каждая из которых делалась на своем языке программирования. Нет смысла вдаваться в малозначащие детали, скажу только, что это привело к существенной сложности и нестабильности проекта. В итоге пришлось все переписывать на один язык. Время и деньги потрачены впустую вследствие того, что не были поставлены требования на использование технологий.
Вы можете, например, сделать требование “сайт должен быть разработан на ASP.NET Web Forms”. Тем самым вы отсекаете все остальные платформы, но при этом получаете некоторую уверенность, что сайт не будет разработан на какой-то редкой, никому не известной технологии, которую сможет поддерживать только создатель проекта.
Также считаю важным предупредить вас об использовании flash-сайтов: они очень плохо индексируются поисковыми роботами, что затрудняет продвижение вашего сайта в поисковых системах, например Google и Яндекс. Помните об этом.
Локализация. Если на вашем сайте будет использоваться множество языков, например русский, английский и немецкий, то об этом лучше упомянуть сразу. Это требование очень сильно влияет на структуру базы данных, поэтому если вам требуется более одного языка на сайте, упомяните об этом в техническом задании.
Поисковая оптимизация. Обязательно включите требования по продвижению в поисковых системах. Во-первых, у вас должна быть в административной панели сайта возможность менять заголовки, теги title и метатеги description и keywords. Это важно для оптимизации страниц под ключевые запросы.
Во-вторых, у вас должна быть возможность менять файлы sitemap.xml и robots.txt. Эти файлы необходимы для правильной индексации вашего сайта поисковыми системами.
В-третьих, это правила перенаправления с кодом 301. Для поисковых систем очень критичен вопрос дублирования контента. Дублирование контента – это по сути ситуация, когда контент доступен по двум разным URL-адресам. Проблема в том, что одна и та же страница
может быть вызвана под разными адресами. Например, страницы site1.ru, www.site1.ru, site1.ru/default.aspx, site1.ru/Default.aspx