Нет, нет, нет. Я совершенно не собираюсь уподобляться многочисленной армии Вась Пупкиных, которые, склепав во фронтпэйдже страницу из трех разделов ("Как заработать в Интернете", "Моя фотка" и "Гостевая книга"), тут же спешат популяризовать свой бесценный опыт в фундаментальном труде "Как правельно делать посищаемые сайты". Я прекрасно отдаю себе отчет, что мой собственный сайт сделан на любительском уровне, и становиться в позу крутого профессионала веб-дизайна, поучающего других, мне было бы смешно. Поэтому нижеследующие заметки написаны вовсе не с позиции дизайнера - а с позиции того, ради кого, собственно, дизайнеры и стараются. То бишь пользователя. Уж это-то звание принадлежит мне по праву.
Итак, именно с точки зрения пользователя и его удобства я намерен проанализировать некоторые мифы, популярные как среди профессиональных веб-дизайнеров, так и (тем более) среди некритически внимающих авторитетам любителей. С частью этих мифов я регулярно сталкиваюсь на практике, о других узнал благодаря заметкам Артемия Лебедева и Михаила Харитонова. (Надо ли говорить, что сами упомянутые авторы верят в истинность означенных мифов? Надо или нет, но я уже это сказал.) Подчеркиваю, что разбор тривиальных ошибок васьпупкинского уровня в мою задачу не входит; те мифы, с которыми я имел неудовольствие познакомиться на практике, воплотились не на "кошмарных домашних страничках", а на сайтах вполне солидных проектов. Я не занимался систематизацией мифов веб-дизайна, так что порядок их перечисления - вполне произвольный; не претендую я также и на полноту охвата - не исключено, впрочем, что эта статья будет дополняться со временем.
Время доступа к информации на сайте должно быть минимальным (1)
У этой аксиомы есть два частных следствия:
Очевидно, что фреймы (при правильной их организации, конечно)
позволяют нам в любой момент видеть на экране всю структуру сайта
и перемещаться в любой раздел за один клик. Попытка сделать этакую
эмуляцию фреймов, когда структура (оглавление) сайта изображается
непосредственно на страницах (на каждой из них!), нарушает принцип
1.1 - ведь в этом случае объем каждой страницы увеличивается. Кроме
того, если длина страницы больше высоты экрана (что, как вы
понимаете, скорее правило, чем исключение), то при скроллинге вся
структура уезжает за пределы экрана, в то время как во фрейме она
всегда на своем месте.
Строительство же сайтов по старинке, с главным меню, из которого вы
попадаете на страницы подразделов и вынуждены потом возвращаться
обратно по кнопке "Назад" (на самих страницах или в броузере) -
нарушает принцип 1.2.
Таким образом, приличной альтернативы фреймам попросту нет. Какими
же аргументами оправдывают фреймоненавистники свои неприличные
альтернативы?
"Если на страницу попадут не с сайта, а из поисковика, навигация
будет нарушена, ибо страница загрузится без фрейма". Бороться с этим
несложно. Можно на каждой странице поставить ссылку на главную
(все равно она займет гораздо меньше места, чем эмулирующее фрейм
полное оглавление сайта). А можно не делать даже этого, если у вас
понятно организована физическая структура: когда пользователь,
пришедший с поисковика, видит в броузере URL
http://mysite.domain.ru/texts/pupkin.txt
- он понимает, что, стерев "pupkin.txt", он попадет в раздел "texts",
а стерев и "texts" - на главную страницу.
А вот чего делать категорически не следует, так это проверять,
загружена страница с фреймом или нет, и во втором случае автоматически
перезагружать ее с фреймом; подробнее об этом ниже.
"Если документ открыт во фрейме, невозможно узнать его адрес, ибо
вместо его URL в броузере отображается URL фрейма" (аналогичная
претензия - "невозможно посмотреть его код"). С этим тоже легко
бороться - достаточно открыть документ в отдельном окне. Заметим,
что такое требуется гораздо реже, чем просто прочитать страницу,
так что это мелкое неудобство вполне терпимо на фоне удобств,
предоставляемых фреймами. Однако отсюда ясно, почему нельзя подгружать
фрейм принудительно.
Наконец, самая несуразная претензия - "мешает, когда сбоку/сверху/снизу
от текста маячит что-то еще". У авторов подобных утверждений
хочется спросить - а корпус монитора им не мешает? А предметы,
окружающие монитор? А "оконная рама" броузера, а кнопки запущенных
приложений? Пользователь обычно сосредоточивается на тексте, а не
на том, что находится вокруг. Возражение, что пользователь-де к монитору
уже привык, а к фрейму на данном конкретном сайте - еще нет, также
несостоятельно: по этой логике, должен существовать Единственный Дизайн
для всех сайтов, к которому пользователь привыкает раз и навсегда, а сам
пользователь не должен ни апгрейдить компьютер, ни переставлять предметы
на своем столе. Не говоря уже о том, что даже на сайтах без фреймов текст
нередко не занимает весь экран; особенно это актуально для новостных сайтов,
где рядом с колонкой читаемой статьи всегда имеются анонсы других статей,
ссылки и т.п. Более того, узкий текст читается быстрее, чем широкий. Но,
конечно, форма и размер фреймов должны подбираться с умом. Если пользователю
приходится разглядывать документ сквозь узкую щель или клеточку в центре
(или даже не в центре) монитора, это, действительно, мешает и раздражает.
Интересующий пользователя документ должен занимать основную часть
экрана, а фрейм - ненавязчиво оставаться сбоку и не отвлекать внимание
всякими яркими и мигающими спецэффектами.
Не следует делать границы фреймов неподвижными; пусть пользователь,
если ему хочется, подвинет мышкой ваш фрейм так, как ему удобно. На
всех все равно не угодишь. Хотя вариант по умолчанию, разумеется,
должен быть ориентирован на большинство.
Впрочем, для очень длинных (мегабайтных) текстов разбиение на части
все же имеет смысл (естественно, при этом должно быть оглавление,
позволяющее пользователю сразу перейти к любой части; недопустима
ситуация, когда на страницу номер N можно попасть только со страниц
N-1 и N+1). Но 10- и даже 100-килобайтные тексты дробить не стоит.
Насчет якорей вы неправы категорически. Мало того, что якоря удобны
сами по себе - они удобны именно в таком виде, который вы столь
яростно отвергаете (когда по кнопке back происходит возврат к ссылке
на якорь). Пример: имеется текст с примечаниями в конце. Ссылки на
примечания логично делать именно через якоря, ведущие в конец той
же страницы (а не открывать, к примеру, новое окошко или, не дай бог,
не грузить новую страницу на место старой - каковая последняя вполне
может начать качаться по новой при попытке возврата). Далее,
пользователь прочитал примечание и хочет вернуться к тексту.
Естественно, к тому месту, откуда он пошел смотреть комментарий.
Жмет back и возвращается, что может быть проще и естественней?
Можно, конечно, добавлять к каждому примечанию ссылку "назад к
тексту", что увеличивает размер документа во-первых, эстетически
безобразно во-вторых и, наконец, попросту бессмысленно при наличии
более простого способа в-третьих. Back, как вам, очевидно, известно,
означает не "на предыдущую страницу", а "назад". Т.е. туда, где я был
до этого. На этой странице или на другой - не важно. И даже если в
какой-то ситуации мне понадобится вернуться именно на другую страницу
- лишний back по той же странице костей не ломит. Ибо ни к каким
новым скачиваниям не приводит, у нормальных броузеров, во всяком
случае. (А развивая вашу логику, можно заявить, что back-де должна
вообще отсылать юзера на предыдущий _сайт_. Ибо внутри одного сайта
должна быть собственная навигация, и незачем топтать кнопки
броузера.)
И попав на сайт, где, нажав back, я окажусь не там, где был перед
этим, а там, куда меня хочет послать умный веб-дизайнер - я буду, как
вы выразились в другой статье, громко материться. Как, впрочем, и на
сайте, дизайнер коего (по собственной дури или начитавшись ваших
советов) уберет оглавления с якорями из документов типа FAQ,
заставляя несчастного пользователя ползать по многоэкранной простыне
в поисках единственного интересующего его вопроса.
"Скопировать картинку каждый дурак может, а ты попробуй свою создай".
Веб-дизайнер - это не фотограф (и даже не художник в узком смысле),
картинка для него - не самоцель, а средство, элемент оформления сайта.
Его задача - придумать, что вот здесь должна быть такая картинка, а
не рисовать/фотографировать/сканировать ее самостоятельно (если уже
есть готовая). Мне же, как пользователю, совершенно все равно, откуда
взята картинка - главное, чтобы она была к месту и не слишком долго
грузилась. Искать сложный путь там, где есть простой (а конечный
результат - аналогичен) - удел дураков и мазохистов. Использование
сборников дизайнерами столь же оправданно, как и использование
стандартных библиотек программистами.
"Кому нужны десятки сайтов, оформленных одними и теми же стандартными
картинками". Дело в том, что и сборников много, и картинок в каждом
из них - не пять и не десять. Так что разнообразие весьма велико.
Особый разговор, конечно - авторские права. Если некто ворует картинку,
затирает копирайты и кладет ее к себе на сайт - это не может быть
оправдано ни под каким видом.
Вообще, тут уместно напомнить вторую аксиому:
Сайт не должен выполнять никаких действий, кроме тех, которые
запросил пользователь (2)
К таковым действиям относятся открытие новых окон (и закрытие
старых), принудительное добавление фрейма (о чем речь шла выше),
переходы не туда, куда просил пользователь (в том числе и по
кнопке back, см. выше), перезагрузка страниц и т.д. и т.п.
Продолжение может воспоследовать...
Миф первый: фреймы - это плохо
В определенных кругах эта точка зрения обрела уже силу религиозного
предрассудка - и это едва ли не самый нелепый из всех предрассудков
веб-дизайна. Фреймы - штука чрезвычайно удобная; более удобного
средства навигации просто не существует. Для доказательства сначала
приведем аксиому, с которой, надеюсь, никто не станет спорить:
Отдельная страница должна грузиться как можно быстрее (1.1)
Переход из любого раздела в любой должен требовать минимального
числа кликов и загрузок (1.2)
Миф второй: чтобы сайт сразу отображался корректно, надо в заголовке
явно прописывать кодировку (charset)
Не делайте этого ни в коем случае. Сервер сам разберется, что в каком
виде ему отдавать. А если не разберется - разберется пользователь и
выставит нужную кодировку в своем броузере. Если же кодировка прописана
жестко, а сервер ошибется (что бывает не так уж редко) - по крайней мере
в ряде броузеров сделать уже ничего нельзя, сменить ее не удастся.
Миф третий: длинные тексты надо разбивать на страницы
Это еще может иметь какой-то смысл, если длинный текст загнан в
таблицу (которая не показывается, пока не загрузится целиком). Но и
то - лучше уж не загонять длинные тексты в таблицы. Если же текст
отображается по мере загрузки, то его размер особой роли не играет -
он все равно грузится быстрее (даже при скромной скорости порядка
килобайта в секунду), чем пользователь успевает читать. Зато в итоге
пользователь получает весь текст целиком: в нем удобно осуществлять
поиск, его удобно записать на диск или скопировать в буфер, удобно,
наконец, вернуться в начало, если читатель что-то забыл. Он может
выйти в оффлайн и прочитать все спокойно и с комфортом, ему не придется
регулярно снова дозваниваться до провайдера, чтобы скачать очередную
часть (или же с самого начала открывать десяток окон и грузить туда
все части).
Миф четвертый: не следует использовать якоря, а уж если использовать,
то хитро
Речь идет о ссылках на некоторое место страницы, обозначенное
<a name="имя">. Якоря - очень удобная вещь для всяких оглавлений и
комментариев; часто используются для переходов в пределах одной
страницы. Автором мифа является Лебедев, утверждающий, что якоря
лучше не использовать вообще, а если использовать, то так, чтобы
кнопка Back броузера возвращала на прошлую страницу, а не в то место,
откуда произошел переход на "якорь". Привожу здесь свое письмо
Лебедеву на сей счет:
Миф пятый: на странице не должно быть слишком много кнопок счетчиков,
каталогов, "друзей сайта" и т.п.
Да пусть будут. Только в самом низу, чтобы грузились после основного
контента. Я по таким ссылкам неоднократно ходил, а потому считаю эту
информацию небесполезной. Только не забудьте каждой кнопке явно
прописать размер, а то, если какие-то из них не загрузятся, может
нехорошо получиться - все уедет в сторону.
Миф шестой: музыкальное сопровождение недопустимо
Допустимо, если легко отключаемо (т.е. должна быть кнопка на видном
месте). И, пожалуй, лучше, чтобы по умолчанию музыка все же была
выключена.
Миф седьмой: при оформлении нельзя использовать сборники картинок
Обоснований приводится два.
Миф восьмой: в текстах не только можно, но и нужно использовать
специальные символы
Имеются в виду всякие значки параграфов, копирайтов, нестандартные
кавычки ("елочки" и "лапки", в терминологии Лебедева), длинные тире
и короткие (в один символ) многоточия и т.п. Так вот, без крайней
необходимости (каковую мне трудно себе представить, разве что -
предназначенные для печати канонические формы каких-нибудь документов)
использовать их не следует. Во-первых, далеко не факт, что у
пользователя тот же фонт, что и у вас, и что у него этот символ
выглядит так же. Я знаю, о чем говорю - мне не раз приходилось читать
в сети подобные тексты, где лишь по контексту можно было догадаться,
что за значок имел в виду автор. Во-вторых, если ваш текст запишут
на диск в ДОСовской кодировке (code page 866), от ваших спецсимволов
тоже ничего хорошего не останется. За прочие кодировки не поручусь,
но не удивлюсь, если и там не все гладко...
Миф девятый: сайты во flash - это круто
Если вы делаете видеоклип или какую-нибудь онлайновую игрушку, то
может быть. Но если ваш сайт хоть в какой-то степени информационный -
никаких флэшей. Мало того, что все эти навороты слишком долго
грузятся, так с таких сайтов еще и текст нормально не скопируешь.
Миф десятый: пользователь стерпит, если страницу или ее часть
перезагрузить спустя какое-то время
Не стерпит (если это только не страница чата), а обматерит вас
последними словами и постарается больше на вашем сайте не появляться.
Человек, как порядочный, загрузил в броузер страницу и вышел в
оффлайн, чтобы потом спокойно ее почитать. И тут - здрасьте пожалуйста!
The page cannot be displayed!
Миф одиннадцатый: стилизация - это круто
Нередко авторы сайтов в погоне за оригинальностью стараются подыскать
своему детищу какое-нибудь более романтичное или хотя бы нетривиальное
название, нежели "Персональная страница Имярека Имярекова" или "Коллекция
скриптов"; на свет появляются всяческие "рыцарские ордена", "аэропорты",
"бригантины" и даже "клиники". В этом нет ничего плохого, скорее даже
наоборот, особенно если сайт под названием "Аэропорт" действительно
посвящен авиации; но даже если это обычная домашняя страница с литературными
или программистскими упражнениями создателя, проблем пользователю это,
как правило, не создает, ибо большинство каталогов показывают краткое
описание сайта и отображают его в соответствующем реальной тематике
разделе, да и на первой странице обычно сказано, чему посвящен сайт
(если не сказано, то это серьезный недостаток). Сложности начинаются
дальше, когда дизайнер решает не останавливаться на полпути и не
ограничиваться только названием и рядом элементов графического оформления,
а полностью выдержать сайт в соответствующей стилистике. В результате
вместо разделов "Компоненты для Дельфи", "FAQ", "Ссылки" и т.д. появляются
"Трюм", "Кубрик", "Лоция", "Грот-мачта" и иже с ними. С точки зрения
дизайнера, все очень красиво и стильно, но что делать бедному
пользователю, попавшему на "борт" такой "бригантины"? Допустим, он
еще догадается, что "Бутылочная почта" - это е-мэйл, а "Судовой журнал" -
новости сайта (а может, гостевая книга? а может, FAQ?), но всяческие
"Крюйт-камеры", "Кубрики" и "Камбузы", скорее всего, поставят его в
тупик. И если вы рассчитываете, что он перекликает по всем этим
ссылкам, чтобы выяснить, что к чему, и потом еще держать всю эту
структуру в голове - вы заблуждаетесь. Скорее всего, он сразу же
уйдет на другой сайт, не такой стильный, но понятный.