Этот файл был получен с сервера
Центра Информационных Технологий
(095) 932-9212, 932-9213, 939-0783
E-mail: info@citforum.ru

[Главная] [Интро] [Библиотека] [Гостевуха] [Форум] [Чат] [Фотоальбомы] [Музыкальные группы] [Файловый архив] [Прочее] [Ссылки]

Руководство по стилям для создания online гипертекста

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

Руководство создано для последовательного чтения, но Вы можете выбрать нужную Вам часть. Основные разделы руководства:

Выше приведен список всех частей этого руководства, исключая комментарии индивидуальных пользователей.

Чтобы напечатать этот документ

Единственная длинная страница включающая комментарии читателей доступна для печати, однако имеет некорректные ссылки и не соответствует стандарту html.

Этот документ открыт для комментариев!

Предложения приветствуются, если Вы что-то придумаете, отправьте мне письмо по адресу timbl@w3.org, упомянув the Style Guide for Online Hypertext. Я также заинтересован в URL других руководств по стилям, руководств по корпоративным стилям или Вашей любимой книги по стилям (гипертекст или что-то еще).

Введение

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

Вы будете писать определенное количество отдельных файлов. Эти файлы будут соединены друг с другом и с внешними документами для завершения Вашей работы.

Вы можете расценивать результат своей работы как "документ", ведь если бы он существовал на бумаге, Вы назвали бы его документом. В случае online документов, мы можем относиться к каждому отдельному файлу как к документу. Документ может относиться, по аналогии с книгой, к разделу или подразделу или даже сноске. В этом руководстве мы будем ссылаться на целые коллекции документов как на самостоятельные работы.

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

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

Web этикет

Имеется несколько соглашений, делающих web более практичным и удобным. Как администратор сервера, иными словами - webmaster (термин вводится на этой странице немного ниже) Вы должны быть уверенными в применимости этих правил к Вашим данным. Это руководство дает больше идей для information providers. Особенно обратите внимание на:

Подпись Вашей работы -- особенно welcome page;
Определение статуса документа.

Ваш администратор сервера нуждается в этих установках для каждого сервера:

Welcome page для гостей

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

Welcome page - Home page?

Welcome page сервера часто называют home page, потому что это хороший выбор для клиента -- использовать ее при старте как home (default [по умолчанию]) page. Термин home page означает стартовую точку по умолчанию для Вашего просмотрщика. Не смущайтесь этим. Это две отдельные концепции.

Welcome page будет приветствовать новых пользователей, которые хотят познакомиться с содержанием Вашего сервера. Это послужит сходным целям для Вашей home page, но разница существует для тех, кому она адресована. Часто люди внутри организации используют welcome page как свою home page. В конечном счете они получают представление о том, как их организация выглядит для других людей. Я сам этого не делал, так как у меня много персональной информации на моей home page, которую я не хочу выставлять на welcome page организации или мою собственную welcome page, например, биографию. Welcome page может содержать раз'яснения того, что собой представляет Ваш сервер, что может стать пустой тратой пространства на Вашей home page для местных пользователей. Так что Вы можете захотеть создать отдельную home page для местных пользователей.

Псевдоним для Вашего сервера

Если у Вас серьезный сервер, то он может быть больше, чем машина, на которой он работает. Попросите администратора Вашей сети создать псевдоним для него, чтобы Вы могли ссылаться на него, например, как "www.dom.edu", вместо "mysun12.dom.edu". Это значит, что, когда Вы меняете машину, Вы меняете псевдоним, а связь пользователей с Вашими данными по прежнему работает.

В будущем [3/94] клиенты будут искать локальную "www" машину для использования welcome page, как home page, если в конфигурации явно не указано другое. Это означает, что кто угодно запускающий клиента внутри Вашего домена получит одинаковую начальную страницу.

Псевдоним для самого себя

Вам следует создать mail псевдоним "webmaster" на серверной машине, для того, чтобы люди имеющие проблемы с Вашим сервером могли легко сообщит Вам об этом, используя электронную почту. Это тождественно с псевдонимом "postmaster" для людей имеющих проблемы с Вашей машиной.

Делегирование полномочий

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

Домашний стиль

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

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

Структура

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

Сохраните эту структуру. Это поможет читателям использовать структуру "дерево" как основу для книги: это даст им представление о том, где они находятся. Вы также можете использовать эту структуру для организации файлов в каталогах.

Вы также должны иметь в виду:

Структура для читателя.

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

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

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

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

Если Вы одновременно пишете для нескольких групп, тогда Вы должны поддерживать оба подхода.

Когда Вы делаете ссылку, обозначайте ее таким ключевым словом, чтобы некоторые люди могли пропустить ее. Например, "Если Вы действительно хотите узнать, как это работает, смотрите Internals guide", или "Введение step-by-step можно найти в обучающей части".

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

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

Перекрывающиеся деревья

Вы видите пример работы с двумя отдельными структурами (взято описание некоторых программных функций):

			Обучение			Справочник
			   |				    |
	      Давайте знакомиться вместе	       -----------------
		от простого к сложному  	      |			|
			    |		      по Функциональным      Имена функций
			    |			    группам	  в алфавитном порядке
	  Примеры, ориентированные на задания	      |			|
			    |			       -----------------
			    |				    |
		  Примеры использования 		  Синтаксические определения
		  специфических функций   <-------->    для специфических функций

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

Насколько большим делать каждый документ

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

Документ может быть совсем малым по размеру. Например, это примечание.

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

Читатели, использующие графический интерфейс, обычно пролистывают длинные документы используя scroll bar. Когда scroll bar немного перемещается, документ должен перемещаться на соответственное малое значение, так, чтобы часть оригинального окна осталась видимой. Это позволяет читателю сканировать документ. Если документ оказывается больше, тогда он становится нечитаемым и, при каждом передвижении scroll bar, читатель может потерять место на котором он остановился.

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

Также они не приносят авторам неприятностей создания (или генерирования) большого количества связей и постоянного их обновления в случае изменения данных. Если создание ссылок является проблемой используйте в документе только одну ссылку - на страницу содержания. Некоторые просмотрщики имеют кнопки "next" и "previous", позволяющие просматривать документы по списку.

(Фактически, можно нормально просматривать длинные документы вверх и вниз последовательно страницу за страницей, но это создает впечатление, что Вы работаете с алфавитно-цифровым терминалом).

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

Для online help, menu, дающих доступ к другим материалам лучше не превышать 24 линии. Проверьте это утверждение сидя за текстовым терминалом.
Для текстовых документов - примерно 2.5 листа формата A4.

Ссылка или копия?

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

Имеется несколько причин оставить информацию на прежнем месте:

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

Причины для копирования:

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

Вам следует быть очень осторожными прежде чем ссылаться на Ваши личные коллекции, которые дублируют официальные коллекции:

Internet FAQ *Frequently Asked Questions) lists
RFCs (Request For Comments -- Internet standards etc)
Information by subject
The "best" URLs on the web. Создайте личный список указателей Ваших интересов. Вам это пригодится!

Внутри каждого документа

Этот раздел руководства по стилям посвящен планированию текста внутри документа, минимальной единице информации, которую можно получить из Web.

Дополнения следуют (незаконченный раздел).

Вы должны попытаться:

Подписывайтесь!

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

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

Ваша авторская страница является традиционным местом помещения отказа от прав, заметок об авторском праве и т.д., требуемые законом или традициями. Это спасает сами Ваши заметки и послания от длинных подписей.

(Если Вы используете WorldWideWeb.app редактор гипертекста, Вы можете разместить эту ссылку из default blank page [пустая страница для редактора по умолчанию] так что она автоматически окажется в конце каждого нового документа)

Статус Вашей информации

Некоторая информация носит строго определенный характер, другая может быть поспешно об'единенной и незавершенной. И та и другая может быть полезна читателю, так что не стесняйтесь публиковать незавершенную или устаревшую информацию - она может оказаться незаменимой. Однако, не забывайте устанавливать ее статус. Когда она последний раз обновлялась? Полная ли она? Что она охватывает? Для телефонной книги, например, что за люди присутствуют в ней?

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

Вы конечно можете дать оттенок статуса текста через его язык ... синтаксические ошибки, пропущенные заглавные буквы, "расслабленная" грамматика, все это указывает на неофициальность стиля. Осторожно используйте глаголы "shall" и "should" (для английского текста), а инструкция Long Capitalised Noun Phrases (LCNPs) в конце концов создаст впечатление изучения ISO стандарта. ;-)

Датируйте

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

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

Ссылайтесь на контекст

Главным различием между написанием части последовательного текста и online документа является то, что читатель может попасть в него откуда угодно. Даже если Вы только создали ссылки на документ только из одного места, любой другой человек может пожелать ссылаться на какую то определенную точку и таким образом сделать ссылку на некоторую часть Вашей работы из своей собственной. Так что Вы не можете положиться на читателя, что он последует Вашим путем изучая Вашу работу.

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

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

В момент написания Вами документа было бы неплохо помнить о том, что Вы когда-нибудь можете от него отказаться.

Навигационные рисунки (icons)

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

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

[This style guide was for a long time empty of icons because I was editing it with the old hypertext editor which doesn't handle images. I may fix that with time -tbl]

TITLE (Заголовок)

Заголовок документа определяется элементом - TITLE. Элемент TITLE должен появляться в HEAD документа.

У любого документа может быть только один заголовок Он должен идентифицировать содержание документа в довольно широком контексте.

Заголовок не является частью текста документа, но он относится ко всему документу. Он не может содержать ссылок, меток параграфов или подчеркиваний. Заголовок может использоваться для определения строк в history list, для заголовков окон, показывающих отдельные документы, и т.д. Он обычно не отображается в тексте собственно документа. Этим различаются titles и headings. Идеальная длина заголовка - менее 64 знаков. Таким образом, многие приложения будут показывать заголовки документов в окне для заголовков, в меню, и т.д. - там, где место ограничено. Не существует ограничений на длину заголовков (так как они могут быть автоматически сгенерированными из других данных), но информационные провайдеры должны помнить, что слишком длинные заголовки могут обрезаться.

Примеры использования

Подходящие заголовки:

		<TITLE>Rivest and Neuman. 1989(b)</TITLE>

или

		<TITLE>Рецепт сиропа Flap-Jack</TITLE>

или

		<TITLE>Introduction -- AFS user's Guide</TITLE>

Примерами не совсем подходящих заголовков являются те, которые имеют не одно значение в контексте,

		<TITLE>Инструкция</TITLE>

или слишком длинные,

	<TITLE>Remarks on the Quantum-Gravity effects of "Bean
	Pole" diversification in Mononucleosis patients in Developing
	Countries under Economic Conditions Prevalent during
	the Second half of the Twentieth Century, and Related Papers:
	a Summary</TITLE>

Независимость от устройства

Гипертекст, который Вы пишете запоминается в терминах языка HTML, которые не содержат информации о font-ах, форматах параграфа и заполнителях (метод заполнения пустого пространства), которые должны быть использованы для изображения документа на дисплее.

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

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

Например:

Всегда используйте уровни заголовков в следующем порядке, один заголовок 1-го уровня в начале документа, если необходимо, то несколько заголовков 2-го уровня, и далее, если необходимо, несколько заголовков 3-го уровня внутри каждого заголовка 2-го уровня. Если Вам не нравится то, как форматируется заголовок 2-го уровня, настройте это в своем клиенте, но не перепрыгивайте на следующий уровень заголовков.
Не делайте дополнительных пробелов или пустых линий в Вашем тексте только для "раздувания" документа, исключая преформатированную части (tag PRE).
Не ссылайтесь в Вашем тексте на особенности определенного просмотрщика. Просить кого-то "нажмите здесь" не имеет смысл без мышки, также как и просьба кого-то "выберите ссылку по номеру" опровергается фактом того, что Вы используете не line-mode просмотрщик. Оставьте только ссылку. Инструкции излишни, если пользователь сам знает как выбирать ссылки.

Смотрите также: проверка Вашего документа .

Следуя этим указаниям Вы можете обнаружить, что конечный результат появляется на Вашем экране не в том виде, в котором Вы бы хотели, но возможно Вашим читателям повезет больше.

Легко печатающийся гипертекст

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

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

Старайтесь избегать ссылок в тексте на специфические моменты online гипертекста. "Смотрите раздел независимость от устройства" лучше, чем "За подробностями по идеям о независимости от устройств, нажмите здесь.". Фактически, мы говорим о форме подачи независимости от устройств.

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

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

Делайте Ваш (гипер)текст читаемым

Немного напыщенно вести речь о двух типах стилей статей в гипертексте, и Я считаю излишним и не приветствую это.

Первое - это синдром _HERE_, т.е.:

	Информацию о Blah Blah Blah можно получить нажав _here_.

где слово _here_ ссылка. Этот стиль неуклюж, когда Вы нажимаете 'here', Вы должны "посмотреть по сторонам", чтобы убедиться, что нажимаете правильно. Я настоятельно советую Вам, когда Вы создаете свою HTML страницу, убедиться что то, на что нужно нажать фактически является чем то типа заголовка для того материала, на который Вы перейдете, нажав. Т.е., говорите

	Информация о _Blah Blah Blah_ теперь доступна.

и используйте:

	Информация о _способах поиска_ доступна.

вместо

	Если хотите получить информацию о способах поиска, выберите _эту ссылку_.

Не так уж и плохо, но все же неудобно если кто-то будет использовать словарное слово, как ссылку, одновременно говоря о "ссылке".

   	Здесь ссылки на страницы _КРЕДИТОВ_ и _технических деталей_

вместо этого попытайтесь написать что-то типа:

   	Огромное спасибо _различным людям_ за их содействие

_технические детали_ этой системы теперь доступны всем. Т.е., делайте Ваши HTML страницу такой, чтобы Вы могли читать ее даже если Вы не проходите по всем ссылкам.

Избегайте разговоров о механике

Сообщения об Internet службах обычно следуют на страницах для информации о том, как использовать FTP, почтовых службы и т.д. для получения информации. WWW было создано для того, чтобы избежать необходимости использования этого. Соблазном является вырезать все эти инструкции и оставить ссылку типа:

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

Web обычно читают люди, которые либо не нуждаются, либо, что бывает чаще, не хотят знать о FTP,NFS и даже WWW! Лучше написать следующее:

	Наш архив включает
 множество программных средств и текстов, авторские права на которые уже закончились.

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

Даже если Вы работаете с метафорами web, используйте ссылки, но не говорите о них. Например:

	Вы можете найти больше информации в части, посвященной обучению,
 которая имеет ссылку на home-page.

очевидно будет лучше написать

		обучающая часть содержит больше информации об этом.

Еще одна общая идея

	Обучающая часть содержит разделы по mowing, sharpening the mower,
	и buying a mower.

Дайте читателю передохнуть и позвольте ему обратиться непосредственно к тому разделу, который ему необходим!

	Обучающая часть содержит разделы по mowing, sharpening the mower,
	и buying a mower.

Тестируйте свой документ

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

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

Сколько времени отводить на тест?

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

Если, однако, Вы описываете в документе какую-то непонятную часть системы, которой кроме Вас больше никто не интересуется, или, в том случае, если Вы чувствуете, что читатели рады иметь хоть какую-то информацию о данном предмете, нет смысла на проверку этой части. Если кто-то действительно нуждается в этой информации, он может смириться с некоторыми недочетами и просмотреть все Ваши ссылки чтобы понять, что Вы хотели написать. Это может быть наиболее эффективным. Я акцентирую на этом внимание, потому что очень много информации, которая предназначается для быстрого ознакомления или создания файлов на ее основе, окажется важной для будущих читателей. Лучше, чтобы эта информация была доступна хотя бы в незаконченной форме, чем если она совсем не будет доступна. До появления электронных технологий, усилия на публикацию сырого материала приводили к тому, что эту информацию мало кто видел, или к браку; и могли быть расценены как оскорбление читателя, так как публиковалось то, что было низкого качества. В настоящее время публикация идет на всех уровнях и, как документы высокого качества, так и недоработанные, имеют свою ценность. Поэтому, делая ссылки, указывайте на текущий уровень документа дабы избежать разочарования читателей.

Просмотр log-file сервера даст информацию о том, какие документы вызывают наибольший интерес. Вы можете эффективнее использовать свое время, посвящая его улучшению качества именно этих документов. Конечно, анализ log-file сервера тоже займет некоторое время!

Проверка Вашего HTML

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

Дополнительное чтение

Ниже перечислены некоторые документы родственные по содержанию с Style Guide for Online Hypertext :

The HTML Specification и ссылки из него
A Beginner's Guide to writing HTML
World-Wide Web server software - список указателей
Web Ettiquette -- для администраторов серверов The Web Designer, N Laviolette. Много ссылок

Этот список далеко не полон. Сейчас много книг (1994) о том, как строить web site и писать HTML. Если они имеют общие сбои это значит что они созданы под определенный просмотрщик. Возьмите один, который Вам импонирует, так как все они полны хороших идей. Походите по web, наберитесь идей, и напишите мне отзыв о руководстве.

Reader comments

Я помещаю этот список отдельно от всего руководства, поскольку некоторые из комментариев выражают специфические взгляды.

Примечание

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

Пример ссылки

Не предполагалось, что Вы последуете этой ссылке: она была включена только в качестве примера того, где ставить, а где не ставить ссылку. Вы должны себе представлять, где она может находиться в примере.