Памятка дизайнеру сайтов

[Nemesis]

Надо хоть как-то расшевелить раздел .

Памятка дизайнеру сайтов

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

Модульная сетка


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

«Резина»

Мы делаем только «резиновые» сайты.
Все элементы масштабируются в зависимости от размера экрана пользователя и размера шрифта.
Вся модульная сетка, блоки и прочие горизонтали масштабируются в процентах.
Все шрифты, отступы, почти все вертикали масштабируются в em. Во многих случаях, это касается даже рамок (border).
Исключение могут составлять лишь картинки. И то, для многих изображений жесткий размер в px — ограничение лишь по вертикали.

«Сжатие-растяжение»

Мы используем «полу-резину», т.е. сайт растягивается и сжимается до определенного предела.

min

Первое, с чего начинаем, это находим минимальное сжатие сайта. Раньше мы использовали величину в 760px, теперь используем 1000px.
Учитываем в дизайне минимальное сжатие, для каждого элемента модульной сетки, чтобы не возникало наездов/нахлестов элементов друг на друга.

max

Максимальная ширина сайта, может быть разной, но, как правило, мы используем диапазон 1500–1700px. Это обусловлено тем, что при растягивании сайта более, чем в полтора раза, композиция сайта, обычно, рушится.
Учитываем, что произойдет со всем сайтом, при размере монитора пользователя свыше максимальной ширины.
Решаем, куда он будет выравниваться. Вправо? Влево? По центру?
Добиваемся завершенного вида сайта и его естественного перехода в окружение при разрешении свыше максимального. Недопустимо, чтобы сайт на большом мониторе выглядел как «обрезанный».
Учитываем и прорисовываем все иллюстрации и неповторяющиеся фоны из принципа «у кого больше монитор, тот больше увидит». Обычно, ширина иллюстраций обусловлена шириной отведенных ей блоков модульной сетки в состоянии max.

Запас на рост сайта

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

Шрифтовая схема

Как правило, мы строим дизайн сайта на основе одного-трех шрифтов.
Базовый шрифт — основной шрифт материалов сайта.
Акциндентный — шрифт для заголовков.
В некоторых случая х вводятся дополнительные шрифты для:

• меню и навигации;
• блоков выделения (важной информации, цитат, выносок);
• для мелкого текста, с целью повысить читабельность.

Дизайнер должен спланировать единую общую схему размеров отступов/заступов для всех элементов на сайте, иеархию заголовков и навигационных элементов (например, для древовидного меню или облака тегов). Она должна прослеживатся на всех страницах сайта.
Всё последующее оформление информации на сайте должно строится на базе общей схемы.

Реакция на пользователя

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

Навигация

В зависимости от типа и масштабности сайта, нужно показать ряд состояний пункта навигации.
Типичный набор:

• Нормальный вид.
• Мы навели курсор.
• Мы находимся в этом разделе.
• Мы находимся в этом разделе, но прошли глубже.
• Мы навели курсор на пункт родительского раздела.

При этом минимальный набор для всех элементов навигации, включая переключатели и элементы управления — это нормальный и активный вид. Т.е. минимум, для всех управляющих и навигационных элементов это «вкл./выкл.».

Ссылки

Ссылки в тексте всегда подчеркнуты и должны отличаться по цвету от основного текста.
Желательно (а в навигации обязательно), предусмотреть внешний вид ссылки, при наведении курсора.
В больших объемах текста и при выдаче разнородной информации, обязательно предусмотреть состояние visited.

Псевдо-ссылки

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

Табы

Это некоторая смесь элемента навигации и элемента управления.
Для них учитываем состояния:

• таб неактивен
• наведен курсор (opt)
• загрузчик содержания (opt)
• таб активен

Курсор

Предусматриваем реакцию курсора при наведении. Особенно, если речь идет о нестандартных элементах управления, таких как навигация, псевдо-ссылки и табы (hand), подсказки (help), изменение размера элемента и перетаскивание.

Рыба

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

Оформление содержания

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

• абзац текста;
• иеархия заголовков трех-четырех уровней;
• ссылки, псевдо-ссылки;
• элемент выделения важной информации;
• цитата;
• ненумерованный список;
• вложенный список;
• нумерованный список;
• иллюстрация на полосу, в текст;
• таблица;
• файл для скачивания;
• выноска;
• подача информации в 2–3 колонки (зависит от сетки);
• простая форма.

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


Размышлял Павел Колодяжный
Copyright © дизайн-бюро «make»

[aaaee2]

"min

Первое, с чего начинаем, это находим минимальное сжатие сайта. Раньше мы использовали величину в 760px, теперь используем 1000px."

И то и другое неверно

"max

Максимальная ширина сайта, может быть разной, но, как правило, мы используем диапазон 1500–1700px. Это обусловлено тем, что при растягивании сайта более, чем в полтора раза, композиция сайта, обычно, рушится."

Бред. Хотел бы я посмотреть на все их дизайны...


Вообще глупость какая то вся статья, но для начинающего пойдет. Способствует чтобы задуматься.

Nemesis, спасибо за расшевеление раздела

[Jack]

Я тоже так просмотрел. Много через чур идеализировано. Если делать за себя или за очень большие бабки с очень длинными сроками то конечно хорошо, и посидеть голову над относительными величинами поломать (где нужно пиксели использовать, где-то em).

[aaaee2]

Поддержим трафик ...

Эта их памятка с грубыми ошибками и ущербная. Зажимает реализуемые технологии и реализуемый полет фантазии в крайне узкие рамки. Если такое писать, то уж полностью, что займет 10 томов "войны и мир" и будет неактуально уже через полгода или даже в процессе написания. Нет смысла. Браузеры, стандарты, на которые кладут браузеры, плодятся быстрее, чем можно выработать и зафиксировать для себя какие-либо четкие повторяющиеся методики создания сайтов.

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

[Chezer]

Сообщение от aaaee2

[I]"min

Бред. Хотел бы я посмотреть на все их дизайны...

если я не ошибаюсь это запись арт-директора студии make

[aaaee2]

Сообщение от Chezer

если я не ошибаюсь это запись арт-директора студии make

Да, это видно в первом сообщении. А что это дает?

[Chezer]

Сообщение от aaaee2

Да, это видно в первом сообщении. А что это дает?

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

[aaaee2]

Сообщение от Chezer

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

Ах, ну да Посмотрел конечно.

[Nemesis]

Продолжим тему , на сколько это будет возможным.

Сообщение от http://habrahabr.ru/blog/webdev/34718.html

О чем не стоит забывать, когда верстаешь HTML
Когда верстаешь (X)HTML, порой не знаешь или забываешь о многих фичах, которые стоит использовать. Перечислю те, о которых вечно забываю сам, а зря

1. тег <label>
Очень полезная вещь, сильно повышающая юзабельность сайта. Определяет собой метку для элемента формы, т.е. если кликнуть по ее содержимому, флажок (кнопка) поставится (уберется), курсор попадет в текстовое поле и т.д.
Единственный нужный параметр: for, содержащий в себе id элемента, к которому метка относится.
Пример:

<label for="login">Логин: </label><input id="login" />

2. теги <link>
Помимо ссылок на CSS-страницы, может содержать себе много чего интересного (кстати, я видел поддежку этого интересного лишь в опере (ну, может есть плагины firefox'a для этого) но использовать все равно стоило бы). Например, в атрибуте rel может стоять:

• 'alternate' - определяет документ в других версиях, например - в RSS (в какой - зависит от других аттрибутов).
  
• 'start', 'next', 'prev' - определяет другие документы из списка, если их много и у них есть порядок (как в бизнес-линче, например)
  
• 'сopyright' - адрес страницы с копирайтом, например у википедии там ссылка на GPL

и т.д.

3. списки (<ul> - <li>)
Если у нас есть несколько однотипных сущностей на странице, например - ссылки в оглавлении, стоит оформить их в список. Даже если они у вас стоят горизонтально или по кругу - ставите в список и оформляете CSS'ом. Тогда ваша страница будет без стилей выглядеть не так убого.

4. стили и структура
HTML документ должен описывать только данные и ничего кроме данных, разве что ссылки на то, что показывает, как эти данные визуализировать. Т.е. на CSS и JS, вынесенные в отдельные фаилы.
Этот пункт говорит сразу о трех вещах: во-первых, весь CSS и JS надо выносить в отдельный фаил, во-вторых, все названия классов и id элементов необходимо давать лишь по типу содержимого, но никак не по стилю, а в-третьих, никогда не стоит верстать табличками (т.к. таблички - они для табличных данных), увлекаться <b> вместо <strong> и т.п., а так же всюду лепить div'ы и span'ы, где можно поставить список (см. п3), хедер (<h[1..]>) (от них, кстати, почему-то все бегают, хотя стоило бы их использовать для заголовков всегда, даже если потом придется в CSS (да-да, именно в CSS! никакого дизайна в html!) сделать текст невидимым и поставить туда картинку) или еще какой-нибудь "честный" элемент.
Чтобы было проще следовать этому правилу, поставте себе на firefox webdeveloper и жмите ctrl-shift-C (CSS → disable styles → all styles).
Да, и добавление от посмотреть профиль b2k: не стоит прописывать стили по id

5. мнемоники
Не стоит ставить в текст (tm), (c), ->, если есть ™, ©, →. Тем более не стоит использовать картинки.
Вот список.

6. strict
Всегда верстайте в strict! Это несложно, но интересно

7. фреймы
Если вам нужен фрейм, которого в HTML нет (нет такого элемента в стандарте... ну почти , используйте не тег <frame>, а тег <object>.

8. работа и результат должны быть приятны
Если вы смотрите на сайт и код, и говорите себе: "ГоспАди, сколько ж хаков, оперный енот" или "О ужас, если сюда ченить вписать или это переставить все опять поедет ", то сотрите это всё и напишите заново.
Когда я пишу красивый валидный код, я доволен собой. И это не оргазм после секаса с браузерами

9. код должен быть готов к анализу машиной
Вместо того, чтобы плодить API, можно делать страницу понятной для анализа при помощи всяких XML-парсеров и т.п.

[antina]

Конечно намудрили в создании дизайнов, и подгонки под рамки браузеров...Наверное все проблемы из за браузеров.