WebDesign.Doc - электронная библиотека веб-мастера: Советы по Web-разработке. Выпуск 238
WEbDESiGN.doc // №238
Приветствую, дорогие друзья и коллеги!
читайте в этом выпуске:
Мастерская. Советы по Web-разработке
Десять (или чуть больше) файлов, необходимых для каждого Web-сайта
Библиотека
Создаем динамические веб-сайты с помощью PHP, MySQL и JavaScript
Смотри и учись!
Видеокурс "Интернет на 100%!"
→ рекомендую:Видео-двойники! Сайты с человеческим лицом! Инновационный метод привлечь посетителей на Вашем сайте и поднять конверсию сайта в несколько раз! Для многих сайт это лицо бизнеса, с помощью нашего метода Ваш бизнес будет иметь человеческое лицо! Смотрите видео здесь - http://panferoff.alphamarketing.ru
Мастерская. Советы по Web-разработке
Десять (или чуть больше) файлов, необходимых для каждого Web-сайта
Введение
Существует несколько стандартных файлов, которые должны быть, но далеко не всегда присутствуют в каждом Web-сайте. Как правило, это вопрос исключительно удобства, а не технической необходимости, но, забывая о них, вы вредите своему же сайту. Если пользователи наудачу пробуют обращаться по разным URL, то будет лучше, если они будут находить то, что искали, в основном. В этой статье мы кратко рассмотрим каждый из стандартных файлов.
Как именно пользователь получает доступ к тому или иному ресурсу, зависит от Web-сервера и архитектуры вашего Web-приложения. При использовании “традиционных” серверов типа Apache, работающих со статичными ресурсами, ресурсы, как правило, представляют собой обыкновенные файлы на сервере. Но в другом случае они могут являться записями в базе данных, строками конфигурационного файла, классами некоего серверного процесса и т.д. В этой статье речь пойдет о том, что, в конечном счете,
получит пользователь, а не о том, как именно это будет реализовано.
404.html
При работе с вашим сайтом пользователи обязательно попробуют обратиться к несуществующим ресурсам. В основном это происходит из-за опечаток в адресах страниц, но также встречаются недействительные ссылки, ошибки в конфигурации сервера, искаженные по разным причинам URL и т.д. Поэтому, если ресурс по той или иной причине недоступен, желательно перенаправить пользователя на некую резервную страницу, с которой он может продолжить навигацию по сайту. Конечно, получив стандартное сообщение “страница
не найдена”, пользователь поймет, что произошло, но это никак не поможет ему решить, что делать дальше.
Есть одна вещь, о которой необходимо помнить при создании собственной страницы 404.html (или при использовании механизма, поддерживаемого вашим Web-сервером, для замены стандартного сообщения “страница не найдена”). Очень часто разработчики совершают ошибку, используя так называемую “мягкую” страницу 404. Другими словами, сервер перенаправляет пользователя к странице, которая возвращается с заголовком “200 OK”. Как правило, эта страница просто содержит текст
“страница не найдена”, часто даже не упоминая об ошибке 404. Не делайте этого! Всегда четко информируйте своих пользователей (а также их браузеры и другие программы) о произошедшем, используя точные заголовки ответов.
about.html
Итак, зачем вы вообще создали этот сайт? Иногда на этот вопрос отвечает главная страница. Но зачастую это не так, страница просто предлагает пользователям авторизоваться, создает общее впечатление о сайте, показывает заставку и т.д. Несмотря на то, что, скорее всего, к странице “о сайте” (about.html) можно перейти по ссылке с главной страницы, лучше всегда размещать ее по адресу http://mysite.example.com/about.html. Кто-нибудь обязательно попробует обратиться по этому URL
напрямую.
Качественно сделанная страница about.html должна содержать краткий обзор вашего сайта, возможно, информацию о том, зачем вы его создали, чем он интересен, а также несколько ссылок для обратного перехода к основным разделам сайта. Этой странице не требуется никакого продвинутого оформления и, как правило, она его не содержит. Сделайте ее достаточно лаконичной, чтобы пользователь мог быстро перейти к более важным вещам, представленным на вашем сайте.
contact.html
А сами-то вы кто? Как и в случае с about.html, пользователи, наверное, смогут докопаться до этой информации, сделав несколько кликов, начиная с главной страницы. Но не заставляйте их делать этого, разместите страницу contact.html по адресу: http://mysite.example.com/contact.html. Поместите ту же информацию на страницу contacts.html, а также продублируйте файлы, поменяв расширение на .htm. Лишние файлы ничему не повредят. При этом можно оставить ссылки, ведущие к contact.html –
в подобной избыточности нет ничего страшного.
copyright.html
Кто является правообладателем этой информации? Скорее всего, именно вы, но опять же – кто вы? Частное лицо? Компания? Какое-то объединение? Государственная организация? Если информация, выложенная на вашем сайте, является общедоступной или она защищена какой-то из свободных лицензий – важно, чтобы пользователи об этом узнали. В настоящее время весь контент изначально считается защищенным авторскими правами, поэтому, если в случае ваших материалов это не так, укажите на это пользователям.
Подобным вещам уделяют внимание не так много Web-сайтов, но почему бы об этом не позаботиться? Кому-нибудь это обязательно пригодится.
Разумеется, разные материалы могут иметь разных правообладателей. В этом случае пусть на главной странице объясняется, как определять различия такого рода для разных страниц. Также, в случае необходимости, можно упомянуть и о защите торговых марок.
index.html и index.htm
Далеко не в каждом Web-сайте роль главной страницы играет файл index.html. В зависимости от конфигурации могут использоваться преобразования URL, динамическая генерация и т.д. Но пользователям-то все равно! Просто убедитесь, что URL http://mysite.example.com/index.html указывает на главную страницу, даже если вам для этого придется создать простой HTML-файл, перенаправляющий пользователя по нужному адресу.
Вдобавок не забудьте убедиться, что так же будет работать уродливое расширение .htm, ранее использовавшееся в Windows. А если хватит терпения, можно заставить и index.cgi перенаправлять пользователя к главной странице.
index.rss
В настоящее время большой объем информации доступен через каналы RSS. Имеет смысл их добавлять ко многим, хотя и не ко всем Web-сайтам. При этом вполне приемлемо генерировать разное содержимое лент в зависимости от настроек пользователя, авторизации или факта оплаты определенной информации. RSS-ленты совершенно не обязательно должны быть унифицированными.
Тем не менее, если некоторую информацию в RSS добавлять можно всегда, то просто возьмите и сделайте это. Например, в index.rss можно поместить своего рода "приманку", рассказав при этом, чем может быть полезно полное содержимое ленты. Или хотя бы пояснить, почему RSS не нужен для вашего сайта.
privacy.html
Если вы планируете собирать любую информацию о пользователях, даже если это всего лишь имена для входа в систему или логин для учета трафика, обязательно сообщите им, как вы собираетесь ее использовать. Юридические вопросы, возникающие вокруг создателей и пользователей сайтов, весьма сложны, а я не юрист, и уж тем более – не ваш юрист. Но могу сказать, что пользователи будут чувствовать себя спокойнее, зная, что вы подумали о конфиденциальности их данных. Кстати, вполне
возможно, что имеет смысл проконсультироваться с юристом по поводу использования информации о пользователях.
robots.txt
Если вы не хотите, чтобы все материалы на вашем Web-сайте автоматически индексировались, укажите это в файле robots.txt. На самом деле, даже если вы хотите, чтобы индексировалось все - явно напишите об этом. Директива стандарта исключений для роботов (Robots Exclusion Standard) не является строго обязательной для следования. Поэтому, если вам очень не хочется, чтобы какие-то ресурсы были проиндексированы, то либо вообще не помещайте их на Web-сайт, либо защищайте соответствующими
правами доступа. Но все основные сканирующие системы следуют инструкциям в файле robots.txt. Так что указывайте ваши пожелания явно.
security.html
Файл security.html может использоваться по-разному. Однако если при работе с вашим сайтом у пользователей возникнут вопросы о конфиденциальности данных, например, если вы получаете от них некую секретную информацию, то методы обеспечения конфиденциальности рекомендуется документировать (хотя бы перечислить их). Также в этот файл можно поместить контактную информацию, чтобы пользователи знали, куда направлять вопросы и пожелания. Подобное описание политики безопасности должно легко находиться
по ссылкам. Но не помешает поместить копию файла по адресу http://mysite.example.com/security.html.
Карта сайта
Способ представления карты сайта не очень хорошо стандартизирован. Существуют общие полезные рекомендации, но насколько детальной будет карта, зависит от того, насколько динамическим является содержимое вашего сайта. Кроме того, доступность информации зависит от предназначения сайта. Например, не следует указывать пользователям о существовании некого материала X, если у них нет к нему доступа. Поэтому решайте сами, но старайтесь все же предоставить карту сайта в каком-то виде.
Для многих сайтов карта – это всего лишь способ удобного расположения информации для роботов, например поисковых сервисов. В частности, Google предложил соглашение в дополнение к robots.txt. Вкратце: создается файл XML, в котором описываются все материалы данного сайта; он играет роль “списка включений” в дополнение к “списку исключений” файла robots.txt.
Адреса e-mail
Есть вещи, которые происходят вне Web. Например, если навигация на вашем сайте не оправдывает надежд или же пользователи оказываются не способными оценить его элегантный дизайн, то, по крайней мере, они должны иметь возможность связаться с вами через электронную почту.
Любыми способами повсюду помещайте контактную информацию, например, в contact.html. При этом удостоверьтесь, что письма, посланные на несколько адресов общего назначения, будут перенаправлены нужному человеку. К подобным адресам относятся как минимум следующие: postmaster@mysite.example.com, webmaster@mysite.example.com и security@mysite.example.com. Специально для пользователей старой закалки можно также включить адрес root@mysite.example.com (не перенаправляя письма пользователю “root”
из соображений безопасности). Можно также добавить с десяток адресов, органично вписывающихся в тематику вашего сайта. В наше время адреса e-mail практически так же дешевы, как символьные ссылки в каталоге вашего Web-сервера.
Конфигурирование сообщения об ошибке 404 в Apache достаточно просто (как и все в Apache). За информацией о других Web-серверах обратитесь к
документации Apache. (EN)
Множество практических советов можно найти в статьях технической библиотеки в
разделе Web-разработки. (EN)
Об авторе
Дэвид Мерц (David Mertz) - большой знаток в области открытых стандартов и только умеренно пугает многословием. С Дэвидом можно связаться по
mertz@gnosis.cx его жизнь описывается более подробно на
http://gnosis.cx/dW/. Предложения и комментарии по этой, предыдущей или будущей статьям приветствуются. Можете также посмотреть книгу Дэвида
Text Processing in Python.
Библиотека
Создаем динамические веб-сайты с помощью PHP, MySQL и JavaScript, 2011 г. Никсон Робин
Если у вас есть базовые навыки работы с HTML, то с помощью книги Робина
Никсона, опытнейшего разработчика и автора многочисленных бестселлеров
по веб-мастерингу, вы без особого труда научитесь создавать
динамические сайты, характеризующиеся высоким уровнем взаимодействия с
пользователями....
дальше
Надеюсь, что вам понравился этот выпуск рассылки и вы узнали что-то новое и полезное для себя. Если у вас есть пожелания или предложения как сделать рассылку лучше, присылайте их на наш e-mail:
webmastersoft@mail.ru
Создаем динамические веб-сайты с помощью PHP, MySQL и JavaScript
