Записи с темой «Блог дизайнера»
Валидация форм и её необходимость
Когда мы пытаемся открыть дверь не тем ключом, мы сразу понимаем, что что-то не так, и берём другой ключ. Когда мы заполняем бланк неправильно, мы его комкаем и выкидываем, берём бумагу снова и заполняем второй раз — это изначально настраивает на правильное заполнение строк (особенно если бланк большой и подробный, например, договор с банком). Если мы отправляем бумажное письмо без заголовка, конверт не сообщает нам, что мы что-то делаем неправильно.
Интернет же изначально приучает к бардаку, расслабленному и невнимательному отношению к тому, что мы делаем. Неправильный пароль — нам сообщат об этом. Забыли заполнить какое-то поле — услужливо подсказали, какое. Не вписали тему сообщение — «вы действительно хотите отправить письмо без темы»?
Да, действительно хочу.
Я хочу писать в интернете по человеческим правилам, а не по электронным. Если я что-то забыл — моя вина. (Пользователи должны помнить свои пароли, а не восстанавливать при каждом посещении в силу своей забывчивости.) Если я что-то не захотел заполнять — моё право.
Однако в современных фреймворках и CMS очень большая часть кода посвящена валидаторам. На каждую неточность — очень подробное сообщение красными буквами, подсветка поля и т.п. Программная логика, которая сравнивает то, что вписано, с тем, что должно быть (единственная, на мой взгляд, необходимая часть в данном случае).
В CMS Meruert Lulu я попытался обойтись вообще без сообщений валидатора. Данные проверяются, но:
1) отношение к ним не такое строгое, как могло бы быть: если пользователь что-то не ввёл, значит, ему просто не захотелось — из этого я и исхожу. Если что-то введено неправильно (это только про критичные случаи), то просто ничего не получится (например, не получится войти с неправильным паролем),
2) в системе нет ни одного сообщение об ошибке (впрочем, и об успешном выполнении задачи тоже: эти сообщения уже навязли в зубах, особенно слово «успешно») — если всё хорошо, то результат и так виден; если что-то не получилось (что сложно представить), то и результата не будет.
Почта Gmail, если я в письме употребил слово «приложено» или подобные, но не прикрепил к письму ничего, сообщит мне об этом: а вдруг я что-то хотел приложить, но забыл? Забота и внимание к пользователю, достойные уважения, но именно эта забота делает пользователей интернета невнимательными: робот всё будет помнить за меня.
Внимание к мелочам
На сайте, посвящённом вину, встретил замечательную форму голосования вместо привычных пяти звёздочек.
Внимание к подобным мелочам — признак тщательно спроектированного и проработанного дизайна.
Баланс между семантической вёрсткой и дизайнерскими решениями (HTML)
С одной стороны, всегда хочется верстать семантически, чтобы облегчить работу программистов, поддержку сайта и последующий редизайн. С другой стороны, часто дизайнеры рисуют дизайн так, что без введения несемантических блоков не обойдёшься. Приходится балансировать: обходясь без старых добрых таблиц, верстать так, чтобы этот HTML-код в будущем можно было бы почти не менять. Для этого нужно соблюдать некоторые базовые принципы.
1. Использовать общую и частную обвёртки и идентификаторы для <body>
Обычно я использую в тэге <body> идентификатор, строящийся на URL страницы: у страницы www.site.com/test/page будет <body id="test_page">.
Общая обвёртка (тот же <div>) с идентификатором, общим для всех страниц или для одного большого раздела, служит сразу двум целям: основа вёрстки (особенно если вёрстка фиксированная) и задание родовых компонентов в стилях. Частные обвёртки из блоков с уникальными идентификаторами нужны, чтобы для каждой страницы можно было задавать специфическое оформление; при этом желательно блокам с разными именами присвоить общий CSS-класс на случай, если в одной из версий дизайна появится необходимость задавать этим блокам одинаковые параметры или JavaScript’ом заставлять блоки вести себя схожим образом.
Во-первых, обвёртки позволяют изолировать содержимое от неправильного поведения; во-вторых, им можно назначать сложные фоны или границы, т.е. дизайн от этого только богаче.
2. Упорядочивать структуру CSS-файлов
Изначально мы делаем так: сначала пишем в файле т.наз. «ластики» (erasers, т.е. правила, которые унифицируют отступы, цвета, поведение текста, шрифты и т.п.), потом базовые правила, а потом двигаемся сверху вниз от общего к частному. И если один верстальщик поддерживает проект, то иерархия и принцип сохраняются. Но если над проектом работает несколько человек, то правки в CSS-код могут вносить сразу несколько человек (типичная ситуация: добавился новый фрагмент кода, взятый из другого проекта, вместе с ним пришли и стили, и часто они просто дописываются в конец файла). С течением времени файл замусоривается, найти там что-либо очень сложно.
Простые принципы, которые нужно соблюдать всегда — разделение CSS-файлов, соблюдение иерархии и комментарии к блокам кода.
2.1. Разделение CSS-файлов
Удобно делать так, что есть один (даже его можно разделить на несколько) главный файл и несколько файлов по разделам и по компонентам. Главный файл должен содержать:
— «ластик»
— определения вспомогательных классов, применяющихся везде
— определения элементов форм
— определение базовых элементов вёрстки основного шаблона.
Важно понимать, что изменения в этом файле коснутся всех страниц, поэтому редактировать его можно с большой осторожностью.
Для каждого раздела стоит держать отдельный стилевой файл, если разделы хотя бы немного различаются между собой. Правильным был бы подход, если бы основная часть имени стилевого файла совпадала с основной частью имени корневого файла раздела — это облегчит поддержку сайта в дальнейшем.
В файлах такого рода может быть два основных раздела:
— правила, переопределяющие для данного раздела те правила, которые уже определены в основном файле,
— и правила, необходимые только для данного раздела.
В первом случае не следует копировать определение всего селектора, а стоит переопределить только изменённые правила.
Примечание
Вероятно, в проекте стоит держать временный CSS-файл на случай, если программисты или иные люди, вносящие изменения, не разберутся в структуре сходу, чтобы не нарушать целостность остальных файлов и держать под контролем стили. А уже верстальщик должен по запросу выносить из этого файла правила на нужное место.
2.2. Соблюдение иерархии
Описывать селекторы важно от общего к частному, сохраняя такую иерархию на протяжении всей работы. Т.е. сначала описываются body и основные используемые тэги, потом основа вёрстки (основные компоненты страницы, например, шапка, сайдбар, контент, футер и т.п.), потом фрагменты основных компонентов страницы, потом их внутреннее содержимое и т.п.
Очень часто бывает удобно пользоваться вложенностью элементов.
3. Наследование и прототипы в вёрстке
Отдельная глава тут.
По мотивам Спрашивай.ру
На вопрос «Что вы можете посоветовать выпускнику дошфака, мечтающему профессионально заняться веб-дизайном?» я ответил так:
Вне зависимости от полученного образования: выучить языки HTML и CSS, неплохо знать JavaScript и хотя бы один из фреймворков типа jQuery, иметь понятие о серверных языках программирования типа PHP, ASP.NET, Java, Ruby, Python, Parser и уметь писать код хотя бы на одном из них, уметь работать с базами данных, иметь понятие о фреймворках типа Zend, Symphony и т.п., уметь работать с CMS типа Drupal, Wordpress, Joomla, Битрикс, понимать, зачем нужны фреймворки и в каких случаях можно обойтись без них, знать о браузерной совместимости и разных ширинах мониторов и разрешениях, уметь оптимизировать графику для веба, знать о шрифтах для веба, иметь представление о Flash / ActionScript, знать основы композиции, видеть перспективу, уметь работать с цветом, иметь представление о графических стилях и стилях веб-дизайна, иметь установленными не менее 3-4 браузеров, просматривать и анализировать большое количество сайтов, читать блоги и статьи про веб-дизайн и относиться к ним критично, быть в курсе новинок, модных или полезных тенденций, иметь чёткое представление о процессе (постановка задачи или переговоры, проектирование, прототип, дизайн, вёрстка, интеграция, программирование, деплоймент, а также постоянные тестирование и согласование на всех этапах), фиксировать свой опыт в виде портфолио, держать все проекты в порядке, делиться опытом, держать в порядке софт для разработки, всегда всё тестировать в разных средах (браузеры, ОС, мониторы, разные устройства, разные пользователи), понимать, что сайт — не только произведение искусства, но и интерфейс, призванный отдавать и получать информацию, знать основные положения SEO и применять их, помнить о том, что информацию нужно держать в безопасности. Это самое основное.
Самые глупые тенденции современного веб-дизайна
1. Закрывать часть слишком длинного текста градиентом от прозрачного до цвета фона: часть слова как бы растворяется в фоне.
2. Повторять шапку как отдельный блок, если страница прокручена ниже.
3. Делать ссылку «наверх» (это самая взрослая глупость: она уже с 90-х годов на ваших экранах).
4. Делать всё очень крупным (особенно кнопки и прочие элементы форм).
5. Позволять себе опечатки, ошибки и жаргон на веб-страницах.
6. Увлекаться Ajax и вообще джаваскриптами якобы для ускорения загрузки страниц, не следя за ошибками в навигации.
7. Делать любой контент в форме блога.
8. Использовать лакировку под веб-2.0 или под Mac OS X.
Неправильное начало
Начинающие дизайнеры часто неправильно начинают работать: они делают что-то, исходя из своих возможностей и навыков, а не целей. Например, им нравится эффект падающей тени, и они его активно используют там, где надо и не надо. Получается вещь совершенно непродуманная.
А начинать надо так: проектируешь продукт, как будто умеешь всё и немного больше. Плюсов два: продуманное произведение дизайна выглядит гораздо более достойным, ну и в процессе создания можно выяснить то, чего не знал.
В общем, сначала думать, потом делать.
Основной текст
Основной текст (это может быть художественное произведение, а могут быть тексты писем в переписке, следующие в подборке друг за другом) не должен быть набран курсивом или полужирным. Также он не должен быть набран прописными (заглавными) буквами или подчёркнут. Наконец, цвет текста должен быть контрастным по отношению к цвету фона.
Те, кто оформляет большое количество букв в отклонении от этого правила, очевидно, сам не перечитывал свои тексты. Любого верстальщика или дизайнера надо обязывать читать тексты, с которыми они работают.
Даже объявление на листке A4 читается плохо, если его набрать прописными буквами.
О валидной вёрстке
В погоне за чистотой кода вёрстки (валидностью) веб-разработчики часто забывают о пользователе. Я совсем не противник чистого кода, но не в ущерб конечному потребителю.
Представьте: посетитель заходит на сайт с помощью Internet Explorer, а там колонка с информацией съехала вниз. И ему вряд ли будут утешением уверения разработчика, что код соответствует модели Strict и с точки зрения семантики является безукоризненным. Вёрстка-то ползёт!
Есть ряд приёмов, которые не слишком пагубно сказываются на семантике и соблюдении стандартов, но при этом позволяют добиться приемлемых результатов во всех современных браузерах. Несомненно, их надо использовать, даже если они идут вразрез с вашими идеалами. Сайтом ведь будете пользоваться не только вы. И вы вряд ли сможете предписать пользователю, каким браузером и с каким разрешением монитора нужно смотреть на страницы.
И ещё: ссылки на валидаторы и указания на Best viewed with... являются самыми бесполезными фрагментами сайта.
Верстая сайт, нужно смотреть на него глазами пользователей, а не валидатором.