Гиперкниготексты
Я опросил многих своих знакомых, которые умеют писать хорошие тексты. Все они выдали одну и ту же цифру: устойчиво писать можно примерно 7Кзнаков с пробелами хорошего (нехудожественного) текста за день. Есть две крайние стратегии такого написания: либо ты сидишь весь день за компьютером, и вымучиваешь в конце дня законченные 7К, либо напряженно размышляешь весь день на предмет написания, практически весь день ничем больше не занимаясь -- и в конце дня за час-два быстро оформляешь надуманное в виде текста. Быстрее хорошие тексты пишутся очень редко (ежели быстрее, то это означает, что вы все равно потратили раньше значительное время на обдумывание).
7Кзнаков -- это много. За месяц работы можно написать 210Кзнаков, за три месяца -- книжку на 600Кзнаков. Но крижку писать много труднее. Добавляется существенное время на увязку текстов между собой. Это время кажется непроизводительным для писателя, ибо от этой работы текста не прибавляется. Но эта работа помогает читателю.
Современные системы управления гипертекстовым контентом имеют две главных категории пользователей: писатели и читатели. Писатели пишут в них кусочки текста, читатели эти тексты потом читают.
У читателя тоже есть своя статистика. За один час читатель может вдумчиво прочесть от тех же 7 до 20Кзнаков. Просмотреть "по диагонали" (это буквализм -- просмотр страницы в таком режиме действительно часто соответствует диагональным, зигзагообразным движениям точки взгляда), чтобы получить представление о предметной области -- до 100К. Гипертекстовые системы диагонали не имеют. Все эти wiki имеют либо что-то типа алфавитных указателей и списков, либо обрывки текста, прихотливо собранные в лабиринт с четким входом но без надежды на выход. Можно годами бродить по этому лабиринту, не понимая, сколько содержания ты уже прочел, десятки раз натыкаясь на один какой-нибудь кусочек содержания, и никогда не сталкиваясь с другим. Беда: в книге я всегда знаю, что прочел ее до половины -- и могу как минимум планировать собственное время на оставшееся чтение (а время и возможность его планировать -- это самый ценный ресурс). Писателю становится легко, у него занимает гораздо меньше времени "вписать" текст в общую гипертекстовую кашу, и эту кашу заваривать могут даже множество писателей. Читателей ожидает большая проблема. Все книжки становятся похожими на энциклопедию. Ежели я забежал на минутку поглядеть, кто такой Навуходоносор и что там с ним связано, то мне, конечно, нужна именно энциклопедия -- маленький кусочек текста и ссылочки на упоминающиеся в нем места, что еще почитать и т.д. Ежели я хочу получить системное представление (получить не справку, а в какой-то мере образование, понимание предметной области) о том времени, откуда взялся Навуходоносор, чтобы потом читать эту справку хоть в каком-то то контексте, то мне нужно прочесть книжку. Да, потратить пару тройку дней, но получить системное представление. Я не встречал еще ни одной гипертекстовой системы, которая давала бы мне такое представление, какое дает обычная большая статья, не говоря уже о книге. Писательское достоинство превращается в читательское разочарование.
А уж когда речь идет о проектах, то всегда наступает стандартная беда: доступны вразнобой тысячи обрывков информации (в виде мемо, комментариев, писем разработчиков, отдельных спецификаций, обрывков инструкций к крошечным кусочкам проекта), но никогда ни у кого не доходят руки до оформления этих кусочков в связное изложение. Электронная форма фиксации знания развращает. Знания фиксируются -- каждая капля бесплатно. Накапать можно сколько хочешь, каплями. Стаканчика накапать таким образом нельзя. Капли просто не сольются в одно целое, так и останутся слабосвязанными (в голове -- не в гипертексте) кусочками информации, а не пониманием.
Увы, я встретил много исследований о том, как лучше писать запутанные гипертексты. Я не встретил исследований о том, как их лучше читать, и что при этом думает о писателях этой мешанины читатель.
Какие можно сделать конструктивные выводы из этого наблюдения?
1) Ежели предполагается подключать к проекту других людей, или проект в какой-то мере является образовательным, то современные гипертекстовые системы следует признать развращающими, и минимизировать их использование для подобных целей. Следует фиксировать результаты проекта не в виде гипертекста, а в виде книжки. Книжку много легче порезать в гипертекст, чем из гипертекста собрать потом книжку.
2) Гипертекстовые системы нужно "вывернуть наизнанку": вместо основного представления маленьких кусочков текста со ссылками, ведущими в другие кусочки текста, нужно иметь "книжное представление" с единой лентой длинного текста, а ссылки должны вести в другие места этого длинного текста (типа механизма сегодняшних anchors в HTML). То есть писатели должны писать один (в самом крайнем случае -- всего несколько) большой текст-книгу, и размечая куски текста и их связь в этой книге, чтобы читатель мог выбрать либо образовательный режим (чтения книги) либо справочный режим (чтения гипертекста). Принудительный режим писательства "снизу вверх" (сначала кусочки, которые постепенно собираются в общую структуру по мере их появления) должен быть заменен на выбор такого режима писателем -- он может Insert text (включить уже готовый текст в какую-то точку своего повествования), а может, наоборот, объявить какой-то кусок слитного текста в какой-то мере автономным объектом (абзацем, главой, врезкой, сноской-примечанием и т.д.). Для этого не должно быть нужно манипулировать открывающимися окошками и формами -- только выделениями текста разными стилями, или даже вставкой заголовков с соответствующими стилями. Окошки -- опциональны (например, даже тот же Ворд предлагает стандартных два окошка в один и тот же текст).
3) Конечно, действительность может быть много богаче, но принцип остается тем же: ежели писателя посадить писать книгу, он напишет книгу. Ежели ему сказать, что он "заполняет формочки" и "провязывает связи" -- он напишет набор формочек. Дальше нужно просто определиться: писатель пишет для себя, или все-таки для читателя. Если для читателя -- нужно дать писателю инструментальные средства писать для читателя. Пока единственным таким средством является Ворд. В Ворде можно написать книжку. В известных мне веб-системах -- нельзя (много-много сильно связанного между собой текста -- это еще не книжка). В ворде плохо писать справочники. В CMS (и особенно -- в викоидах) только их писать и можно. Нужен другой инструментарий, инструментарий не синтеза текста из кусочков, а декомпозиции большого замысла в гипертекст! Должен быть обеспечен писательский WYSIWYG на другом уровне -- уровня аутлайна (в некоторых CMS, правда, это есть, равно как и в Ворде) и главное -- уровня общего текста (а это уже есть только в Ворде. В CMS WYSIWYG-представления абсолютно разные для аутлайна и для собственно текста). Писатель не должен во время письма слишком часто и трудоемко перещелкивать уровни сборки текста, контексты его представления. Писатель должен иметь возможность видет текст в виде маршрута, по которому его читатель читает -- лента "сверху вниз". Это задает новое направление для дизайна гипертекстовых систем. Это уже не столько системы управления контентом (контент асинхронно приходит из разных мест и асинхронно распределяется в разные места), сколько системы обеспечения понимания и управления пониманием. Это совсем другой фокус внимания для разработчиков подобных систем: они должны сосредоточиться не на контенте, а на процессе обеспечения понимания читателя и процессе такого его писательства, которое будет стимулировать читательское понимание.
Назовем эти системы гиперкниготекстовыми, а порождаемые ими "сложные интерактивные книги со средствами стимулирования понимания" -- гиперкниготекстами.
4) Учитывая то, что вдумчивые читатели зачастую сами являются писателями, этот подход предъявляет другие требования к построению систем аннотирования (комментирования) подобных гиперкниготекстов.
5) Учитывая то, что традиционное синдицирование контента ("появился такой обрывок информации", "появился еще один обрывок информации") для подобных "книжных" систем теряет смысл, нужно придумывать другую систему отслеживания хода проекта -- интересно, как могла бы выглядеть система отслеживания проекта по написанию книги? Это был бы сплошной changelog, для которого пришлось бы обсуждать его собственную структуру (ну не в терминах же текстового diff его вести ;) Журнал (регистр) подобной гиперкниготекстовой системы тоже бы отличался от традиционного. Да и собственно синдицирование текстов из нескольких проектов (для меня журналирование и синдицирование контента -- близнецы-братья) выглядело бы странным. Как вы будете синдицировать содержание разных книг? Постранично, поглавно или потемно? ;)
6) Собственно, в системах управления контентом не нужно ничего менять: текст все равно будет храниться как множество связанных друг с другом обрывков, сборка будет производиться на основании метаданных прямо на компьютере читателя с учетом выбранного им (или подразумеваемого писателем) view. Движки-сервера могут быть прежними. Коренным образом должны меняться фронт-энды, клиенты. Не удивлюсь, ежели создание таких систем станет возможным только при появлении какого-нибудь очередного поколения крутых настраиваемых XML-редакторов. А экспериментировать можно будет, делая клиента-прототипа из таких странных программ, как Emacs. И
7) Совсем не удивлюсь, ежели такая система вырастет как серверная часть к очередному Ворду или следующему поколению OpenOffice (и это будет позиционироваться как "система коллективной разработки документации". Только "документация" будет настоящим гипертекстом, гиперкниготекстом, синдицируемым контентом из разных источников, поступающим асинхронно). И тогда опять раздадутся вопли обиженных юниксоидов, которые разрабатывали-разрабатывали викоиды, чтобы им удобнее было писать, а потом пришли системы, ориентированные на читателей, и захватили весь мир. Замечу -- читательский мир. Ибо писателей в мире все-таки меньшинство, что бы там ни говорили любители информационной демократии. Кормят жителей земли в развитых странах уже не 50% населения, а 2% населения. Духовно кормить смогут столько же. Так вот, кто-то должен подумать об удобствах не только этих 2%, но и остальных 98%. Вот эта разница и отличает фокус линуксоидно-викоидных систем и... гм... альтернативных.
Дайте мне альтернативную систему, и я напишу онлайновую книжку. Я напишу гиперкниготекст.
7Кзнаков -- это много. За месяц работы можно написать 210Кзнаков, за три месяца -- книжку на 600Кзнаков. Но крижку писать много труднее. Добавляется существенное время на увязку текстов между собой. Это время кажется непроизводительным для писателя, ибо от этой работы текста не прибавляется. Но эта работа помогает читателю.
Современные системы управления гипертекстовым контентом имеют две главных категории пользователей: писатели и читатели. Писатели пишут в них кусочки текста, читатели эти тексты потом читают.
У читателя тоже есть своя статистика. За один час читатель может вдумчиво прочесть от тех же 7 до 20Кзнаков. Просмотреть "по диагонали" (это буквализм -- просмотр страницы в таком режиме действительно часто соответствует диагональным, зигзагообразным движениям точки взгляда), чтобы получить представление о предметной области -- до 100К. Гипертекстовые системы диагонали не имеют. Все эти wiki имеют либо что-то типа алфавитных указателей и списков, либо обрывки текста, прихотливо собранные в лабиринт с четким входом но без надежды на выход. Можно годами бродить по этому лабиринту, не понимая, сколько содержания ты уже прочел, десятки раз натыкаясь на один какой-нибудь кусочек содержания, и никогда не сталкиваясь с другим. Беда: в книге я всегда знаю, что прочел ее до половины -- и могу как минимум планировать собственное время на оставшееся чтение (а время и возможность его планировать -- это самый ценный ресурс). Писателю становится легко, у него занимает гораздо меньше времени "вписать" текст в общую гипертекстовую кашу, и эту кашу заваривать могут даже множество писателей. Читателей ожидает большая проблема. Все книжки становятся похожими на энциклопедию. Ежели я забежал на минутку поглядеть, кто такой Навуходоносор и что там с ним связано, то мне, конечно, нужна именно энциклопедия -- маленький кусочек текста и ссылочки на упоминающиеся в нем места, что еще почитать и т.д. Ежели я хочу получить системное представление (получить не справку, а в какой-то мере образование, понимание предметной области) о том времени, откуда взялся Навуходоносор, чтобы потом читать эту справку хоть в каком-то то контексте, то мне нужно прочесть книжку. Да, потратить пару тройку дней, но получить системное представление. Я не встречал еще ни одной гипертекстовой системы, которая давала бы мне такое представление, какое дает обычная большая статья, не говоря уже о книге. Писательское достоинство превращается в читательское разочарование.
А уж когда речь идет о проектах, то всегда наступает стандартная беда: доступны вразнобой тысячи обрывков информации (в виде мемо, комментариев, писем разработчиков, отдельных спецификаций, обрывков инструкций к крошечным кусочкам проекта), но никогда ни у кого не доходят руки до оформления этих кусочков в связное изложение. Электронная форма фиксации знания развращает. Знания фиксируются -- каждая капля бесплатно. Накапать можно сколько хочешь, каплями. Стаканчика накапать таким образом нельзя. Капли просто не сольются в одно целое, так и останутся слабосвязанными (в голове -- не в гипертексте) кусочками информации, а не пониманием.
Увы, я встретил много исследований о том, как лучше писать запутанные гипертексты. Я не встретил исследований о том, как их лучше читать, и что при этом думает о писателях этой мешанины читатель.
Какие можно сделать конструктивные выводы из этого наблюдения?
1) Ежели предполагается подключать к проекту других людей, или проект в какой-то мере является образовательным, то современные гипертекстовые системы следует признать развращающими, и минимизировать их использование для подобных целей. Следует фиксировать результаты проекта не в виде гипертекста, а в виде книжки. Книжку много легче порезать в гипертекст, чем из гипертекста собрать потом книжку.
2) Гипертекстовые системы нужно "вывернуть наизнанку": вместо основного представления маленьких кусочков текста со ссылками, ведущими в другие кусочки текста, нужно иметь "книжное представление" с единой лентой длинного текста, а ссылки должны вести в другие места этого длинного текста (типа механизма сегодняшних anchors в HTML). То есть писатели должны писать один (в самом крайнем случае -- всего несколько) большой текст-книгу, и размечая куски текста и их связь в этой книге, чтобы читатель мог выбрать либо образовательный режим (чтения книги) либо справочный режим (чтения гипертекста). Принудительный режим писательства "снизу вверх" (сначала кусочки, которые постепенно собираются в общую структуру по мере их появления) должен быть заменен на выбор такого режима писателем -- он может Insert text (включить уже готовый текст в какую-то точку своего повествования), а может, наоборот, объявить какой-то кусок слитного текста в какой-то мере автономным объектом (абзацем, главой, врезкой, сноской-примечанием и т.д.). Для этого не должно быть нужно манипулировать открывающимися окошками и формами -- только выделениями текста разными стилями, или даже вставкой заголовков с соответствующими стилями. Окошки -- опциональны (например, даже тот же Ворд предлагает стандартных два окошка в один и тот же текст).
3) Конечно, действительность может быть много богаче, но принцип остается тем же: ежели писателя посадить писать книгу, он напишет книгу. Ежели ему сказать, что он "заполняет формочки" и "провязывает связи" -- он напишет набор формочек. Дальше нужно просто определиться: писатель пишет для себя, или все-таки для читателя. Если для читателя -- нужно дать писателю инструментальные средства писать для читателя. Пока единственным таким средством является Ворд. В Ворде можно написать книжку. В известных мне веб-системах -- нельзя (много-много сильно связанного между собой текста -- это еще не книжка). В ворде плохо писать справочники. В CMS (и особенно -- в викоидах) только их писать и можно. Нужен другой инструментарий, инструментарий не синтеза текста из кусочков, а декомпозиции большого замысла в гипертекст! Должен быть обеспечен писательский WYSIWYG на другом уровне -- уровня аутлайна (в некоторых CMS, правда, это есть, равно как и в Ворде) и главное -- уровня общего текста (а это уже есть только в Ворде. В CMS WYSIWYG-представления абсолютно разные для аутлайна и для собственно текста). Писатель не должен во время письма слишком часто и трудоемко перещелкивать уровни сборки текста, контексты его представления. Писатель должен иметь возможность видет текст в виде маршрута, по которому его читатель читает -- лента "сверху вниз". Это задает новое направление для дизайна гипертекстовых систем. Это уже не столько системы управления контентом (контент асинхронно приходит из разных мест и асинхронно распределяется в разные места), сколько системы обеспечения понимания и управления пониманием. Это совсем другой фокус внимания для разработчиков подобных систем: они должны сосредоточиться не на контенте, а на процессе обеспечения понимания читателя и процессе такого его писательства, которое будет стимулировать читательское понимание.
Назовем эти системы гиперкниготекстовыми, а порождаемые ими "сложные интерактивные книги со средствами стимулирования понимания" -- гиперкниготекстами.
4) Учитывая то, что вдумчивые читатели зачастую сами являются писателями, этот подход предъявляет другие требования к построению систем аннотирования (комментирования) подобных гиперкниготекстов.
5) Учитывая то, что традиционное синдицирование контента ("появился такой обрывок информации", "появился еще один обрывок информации") для подобных "книжных" систем теряет смысл, нужно придумывать другую систему отслеживания хода проекта -- интересно, как могла бы выглядеть система отслеживания проекта по написанию книги? Это был бы сплошной changelog, для которого пришлось бы обсуждать его собственную структуру (ну не в терминах же текстового diff его вести ;) Журнал (регистр) подобной гиперкниготекстовой системы тоже бы отличался от традиционного. Да и собственно синдицирование текстов из нескольких проектов (для меня журналирование и синдицирование контента -- близнецы-братья) выглядело бы странным. Как вы будете синдицировать содержание разных книг? Постранично, поглавно или потемно? ;)
6) Собственно, в системах управления контентом не нужно ничего менять: текст все равно будет храниться как множество связанных друг с другом обрывков, сборка будет производиться на основании метаданных прямо на компьютере читателя с учетом выбранного им (или подразумеваемого писателем) view. Движки-сервера могут быть прежними. Коренным образом должны меняться фронт-энды, клиенты. Не удивлюсь, ежели создание таких систем станет возможным только при появлении какого-нибудь очередного поколения крутых настраиваемых XML-редакторов. А экспериментировать можно будет, делая клиента-прототипа из таких странных программ, как Emacs. И
7) Совсем не удивлюсь, ежели такая система вырастет как серверная часть к очередному Ворду или следующему поколению OpenOffice (и это будет позиционироваться как "система коллективной разработки документации". Только "документация" будет настоящим гипертекстом, гиперкниготекстом, синдицируемым контентом из разных источников, поступающим асинхронно). И тогда опять раздадутся вопли обиженных юниксоидов, которые разрабатывали-разрабатывали викоиды, чтобы им удобнее было писать, а потом пришли системы, ориентированные на читателей, и захватили весь мир. Замечу -- читательский мир. Ибо писателей в мире все-таки меньшинство, что бы там ни говорили любители информационной демократии. Кормят жителей земли в развитых странах уже не 50% населения, а 2% населения. Духовно кормить смогут столько же. Так вот, кто-то должен подумать об удобствах не только этих 2%, но и остальных 98%. Вот эта разница и отличает фокус линуксоидно-викоидных систем и... гм... альтернативных.
Дайте мне альтернативную систему, и я напишу онлайновую книжку. Я напишу гиперкниготекст.