Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции веб дизайн.doc
Скачиваний:
35
Добавлен:
03.09.2019
Размер:
263.68 Кб
Скачать

Создание карты сайта.

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

Степень детализации зависит от сложности сайта. Карта должна быть понятной. Например, страницы с подобным содержанием, навигацией и пр. лучше представить как один элемент. Если же сайт состоит менее чем из 10 страниц, то от карты можно и отказаться.

Карта сайта показывает все страницы в каждом разделе и самые главные ссылки.

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

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

Имея визуальное представление, можно продумывать организационные аспекты. Должна ли быть связь между какими-либо основными страницами. Нужен ли переход с вторичных страниц на страницы 1-го уровня. Может, логичнее сгруппировать страницы по-другому?

Создание макета.

Макеты – это «раскадровки» страниц. Макеты показывают положение текста, графики, навигацию, другие элементы. Они не дают представления о визуальном дизайне.

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

Контрольный список содержания макета:

  • изображения

  • контент (общее направление содержимого или текст, если он готов)

  • глобальная навигация (навигационная панель или общие элементы для всех страниц)

  • первичные ссылки

  • вторичные ссылки

  • описание основных функциональных возможностей страницы

  • размер окна

  • данные для заголовка и футера (название проекта, страницы, номер версии, копирайт)

  • мультимедиа (если есть)

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

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

Именования.

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

Именования на всем сайте должны быть определенными и согласованными и соответствовать представлениям целевой аудитории сайта.

Определение основных маршрутов пользователей.

Актуально, если требуется выполнять особые действия: регистрироваться, заполнять формы, совершать покупки.

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

Моделирование маршрутов позволяет:

  • выявить экраны, упущенные при создании макетов

  • проследить взаимосвязь экранов

Существует два типа пользовательских маршрутов:

  • функциональные

  • нефункциональные

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

Функциональные маршруты - покупательская корзина, вход с паролем, др.

Не нужно исследовать все пути – определяются только необходимые, и страницы формируются только на этом маршруте.

Десяток страниц, через которые нужно пройти пользователю, большое количество форм и полей, которые нужно заполнить, только раздражает и отпугивает их. Моделирование маршрутов позволяет найти оптимальное решение, «прощелкав» его в макете, а не переписывая код заново.