16 основных требований к дизайн-макету сайта
06-10-2009 | Автор: Yaroslav.CH |
Рубрика: Дизайн, Техническое задание
Метки: Верстальщику, Дизайнеру, Заказчику
24
В практике разработчика сайта часто встречается следующая ситуация — заказчик обращается к разработчику с готовым (уже согласованным и утвержденным) макетом и предлагает на его основе создать сайт.
На первый взгляд, ничего экстраординарного в таком варианте нет, за исключением того факта, что сами макеты в большинстве случаев сделаны с нарушением технических требований, в результате чего у разработчика практически сразу возникают трения с заказчиком.
Приведу наиболее яркий диалог из собственной практики:
Заказчик: У нас есть макет, мы на его основе хотим сделать сайт.
Я: Ок, давайте посмотрим на макет.
...
Я: Простите, но презентация в PowePoint никак не может быть макетом сайта... Вы уверены? Возможно, это только блок-схема?
Заказчик: Нет, это макет сайта — нам знакомый дизайнер так нарисовал и сказал, что проблем не возникнет! Он хороший специалист, нам его [...] рекомендовали!
Обосновать свою точку зрения удалось исключительно демонстрацией нескольких настоящих дизайн-макетов. А вот вернуть потраченные на вот такой «дизайн» деньги, насколько мне известно, заказчику удалось с некоторым трудом, а кроме того, затраченное на подобную «разработку» время привело к срыву сроков запуска сайта.
Если вам нужен сайт, но вы собираетесь заказывать разработку макета у своего дизайнера — для того, чтобы не попасть в такую ситуацию, обязательно убедитесь в том, что дизайнер ознакомлен с изложенными ниже основными требованиями, которые выдвигаются к дизайн-макетам сайтов.
1.Используйте правильные форматы файлов
Макет представляется только в одном из 2-х форматов — PSD (Photoshop Document) или TIFF (Tagged Image File Format).
PDF, AI, EPS, BMP, QXD, QXT и прочие, не говоря уже о расширениях файлов пакета программ Microsoft Office — не допускаются.
2. Новый элемент — новый слой
Каждый элемент дизайна должен быть представлен в отдельном слое. Это означает, что любой элемент цельного изображения является автономным и может быть в любой момент включен/выключен/удален/изменен — не затрагивая другие элементы.
3. Размер макета для фиксированного по ширине шаблона
Если планируется фиксированный по ширине шаблон — ширина макета обязательно должна учитывать отступы справа-слева от края экрана. Кроме того, отдельно указывается цвет фона «подложки».
4. Размер макета для «резинового» шаблона
Если шаблон «резиновый» — в шапке и подвале страницы не менее 20-50 пикселей с правой стороны должны быть отрисованы так, чтобы их без проблем можно было дублировать.
5. Учитывайте рамки и отступы браузера
Если шаблон рисуется под определенное разрешение, необходимо учитывать, что размер макета создается в соответствии с разрешением окна браузера, а не монитора. Например, при разрешении монитора 1024, размер макета составляет 1002 пикселя.
6. Правильно рисуйте фон
Фон страницы должен быть однородным и повторяющимся. В том случае, если требуется использовать текстурирование — текстура точно так же должна быть однородной и легко дублируемой.
Если вы используете сложные фоновые элементы, обязательно хотя бы небольшую часть изображения сделайте однотипной — для дублирования в случае необходимости.
7. Не используйте фоновые фотографии
Использование в качестве фона «тяжелых» изображений (например, полноразмерных фотографий) — не допускается.
8. Используйте направляющие
Все выравнивания слоев должны делаться по направляющим (rulers), которые не удаляются из макета.
9. Используйте стандартные шрифты
Для текстового содержимого должны использоваться стандартные шрифты. В случае использования нестандартного шрифта, он должен прилагаться к макету и в обязательном порядке должен быть указан шрифт-заменитель из стандартного набора.
10. Используйте текст по назначению
Любые изменения текста должны проводиться в рамках стандартных действий — уменьшение-увеличение размера, междустрочные интервалы, кернинг и т.д. Выгибание текста «аркой», «рыбьим глазом» и прочие видоизменения в рамках работы с текстом — не допускаются, это прерогатива изображений.
11.Осторожно обращайтесь с формами
Стандартные элементы форм должны подвергаться изменениям только в рамках здравого смысла. Для дизайнера, не знакомого с возможностями CSS в этой области, оптимальным будет использование стандартных элементов.
12. Готовьте сборку дизайна
Мелкие элементы дизайна (иконки, стрелки, буллеты и т.д.) в случае их многократного повторения в макете (например, маркированный список, меню и прочее) должны быть представлены в отдельных файлах. В самом макете все повторения могут размещаться в одном слое.
13. Оформляйте внешний вид меню
Выпадающие-выезжающие-разворачивающиеся меню должны быть отображены в двух видах:
- собранный;
- разложенный.
14. Оформляйте пункты меню
Пункты меню должны быть отображены в 2 видах:
- пассивный (курсор не наведен)
- активный (курсор наведен).
Кроме того, тексты пунктов меню должны учитывать возможность длинного названия раздела и переноса его на вторую строку.
15. Оформляйте ссылки
Оформление ссылок должно быть указано в 3 статусах: обычная ссылка (link), ссылка при наведении курсора (hover link), посещенная ссылка (visited link).
16. Оформляйте навигационные цепочки
Навигационные цепочки должны быть прописаны с учетом реальных названий разделов и переноса слов.
3 
170 
13
А где вы их используете при заказе макета?..
У Темплмонстра нет ли стандарта это описывающего, проверенного годами?
зы. При ошибке кода пришлось переписывать коммент, так как он при нажатии на back исчез... лажа имхо.
Onore, в каком смысле — «где»? Требования используются при заказе макета у дизайнера.
Честно говоря, я не видел на www.templatemonster.com таких стандартов, впрочем, не буду утверждать, поскольку их услугами пользовался буквально пару раз.
Буду благодарен за ссылку.
Респект — весьма полезная статья!
Хорошо бы также:
1) В дизайн-макете должны быть представлены внутренние страницы приложения, а не только индексная.
2) Не забыть заполнить поля формы.
@zmei: спасибо за комментарий.
1) Вы абсолютно правы, очень важное дополнение — большое спасибо!
2) а вот здесь, к сожалению, не совсем понятно, что имеется ввиду.
Часто встречается что поля форм в макете оставляют пустыми. Например на вашем сайте форма комментариев по умолчанию пустая, так ее порой видит и дизайнер когда сдает макет в производство. А теперь представим что бэкграуновый цвет сайта белый, цвет шрифта — черный, а бэкграундовый цвет полей формы так же черный. Что делать верстальщику? Черный цвет шрифта для полей формы не поставишь потому как буквы на том же фоне видны не будут, поставить на свое усмотрение — можно не угадать с концепцией дизайна и т.д. Это конечно мелочь, но хорошо офрмленный сайт из мелочей и формируется :)
Я еще один момент вспомнил, гораздо более важный. Контент на живом сайте формируется динамически, а в дизайн макете он иногда, ограничен размерами отведенной для него области (т.е. не рипитится). Представим листинг категорий. Бэкграундовое изображение — например развернутый рулон старинной рукописи со сложной текстурой и диагональной тенью ( думаю вам встречалось нечто подобное). В дизайн макете представлено 5 категорий, а на «живом» сайте их 10. Версальщику надо найти эту однопиксельную полоску которая будет рипитится по Y (вертикали), а ее нет. И таких мест на сайте достаточно много. Важно помнить что количество контента на живом проекте «плавает» и его нельзя жестко ограничивать рамками какой либо плашки. Для того чтобы избежать подобных ситуаций нужна та самая повторяющаяся область (это не обязательно должен быть один пиксель) которая будет рипитится по вертикали или горизонтали (это уже зависит от конкретного проекта).
Если рекомендации изложенные в данной статье будут учитываться дизайнерами, это не только ускорит разработку сайтов, но и повысит качество конечного продукта и больше всего от этого выиграют посетители сайта.
@zmei: большое спасибо! Отличное и мега- , я бы сказал, важное замечание!
Спасибо, интересно было почитать все в одном месте :) думаю для многих дизайнеров это будет очень полезным, я бы перед регистрацией на фрилансе (и подобных проектах, где люди предлогают услуги дизайнеров) добавил бы чекбокса (рядом согласен с правилами) о прочтении этой статьи.
Еще по поводу шрифтов. Их можно кстати сделать не только используя CSS3 font-face (который на сегоднешний день еще не стандарт, и пройдет не мало времени пока таким станет). Вспоминается проект, когда клиенту захотелись оригинальные шрифты + чтобы это работало под ие! Мы сделали при помощи cufon (cufon.shoqolate.com/generate/), но это не было хорошее решения (тормаза сплошные, особенно под ие). Так что, не стоит спешить использывать не стандартные шрифты, как говорится — еще не время.
@slon1024: спасибо за комментарий.
Я не стал упоминать cufon как вариант именно по описанным Вами причинам. Когда-то я ради эксперимента пробовал сделать через него нестандартные варианты шрифта — действительно, тормозило очень сильно, а кроме того в тогда еще более-менее поддерживаемом ИЕ6, все отображалось с ошибками и большими проблемами.
А сущности, я вообще не вижу особого смысла устраивать нестандарт со шрифтами — набор штатных удобен для чтения и восприятия, а если уж действительно нужны «красивости», то практически все можно реализовать с помощью изображений.
По поводу пункта 9 хочу заметить, что есть ведь технология куфон, при помощи которой можно прекрасно использовать нестандартные шрифты.
@ Игорь: спасибо за комментарий.
Да, использовать Cufón можно - спору нет, но только в нем есть несколько недостатков:
— увеличение веса страницы. Поскольку подгружаются внешние скриптовые файлы, это автоматически увеличивает размер документа и страница открывается дольше;
— отключенный JS. Если выключить яваскрипт на страницах, то весь текст, который сделан с помощью Cufón, будет отображаться как обычный текст;
— текст нельзя скопировать;
— не годится для больших объемов текста — по понятным причинам;
— пока скрипт не загрузится и не отработает, пользователь будет видеть весь текст — обычным шрифтом. При сбое — тоже самое.
Соответственно, Cufón — это хорошо, но только в экстраординарных случаях.