Сумрачный блог Кирилла Панфилова

Записи с темой «Блог дизайнера»

Валидация форм и её необходимость

Когда мы пытаемся открыть дверь не тем ключом, мы сразу понимаем, что что-то не так, и берём другой ключ. Когда мы заполняем бланк неправильно, мы его комкаем и выкидываем, берём бумагу снова и заполняем второй раз — это изначально настраивает на правильное заполнение строк (особенно если бланк большой и подробный, например, договор с банком). Если мы отправляем бумажное письмо без заголовка, конверт не сообщает нам, что мы что-то делаем неправильно.

Интернет же изначально приучает к бардаку, расслабленному и невнимательному отношению к тому, что мы делаем. Неправильный пароль — нам сообщат об этом. Забыли заполнить какое-то поле — услужливо подсказали, какое. Не вписали тему сообщения — «вы действительно хотите отправить письмо без темы»?

Да, действительно хочу.

Я хочу писать в интернете по человеческим правилам, а не по электронным. Если я что-то забыл — моя вина. (Пользователи должны помнить свои пароли, а не восстанавливать при каждом посещении в силу своей забывчивости.) Если я что-то не захотел заполнять — моё право.

Однако в современных фреймворках и 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... являются самыми бесполезными фрагментами сайта.

Верстая сайт, нужно смотреть на него глазами пользователей, а не валидатором.

Яндекс.Метрика