Владислав Головач, Екатерина Филатова

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

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

Тем не менее, определенная надежда есть. Знание основных особенностей интерфейсных текстов значительно облегчает как, собственно, написание текстов, так и получение навыков письма. Главное – знать эти особенности, а остальное приложится.

Виды интерфейсных текстов

Видов интерфейсных текстов всего два – наименования и интерфейсная справка.

Наименованиями являются названия объектов интерфейса или самой системы. Например, наименованиями являются подписи к элементам управления, названия окон или функций.

Внедренная в интерфейс справка (далее ВИС) – любой текст в самом интерфейсе, объясняющий пользователю, что сейчас произошло, что делать дальше и зачем, для чего нужны те или иные объекты и т.п. К ВИС относятся: всевозможные подсказки, тексты сообщений об ошибках (в отличие от названий ошибок, которые проходят по разряду наименований), Очень Важные Предупреждения и др.

Наименования

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

Коллективное и бессознательное

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

К сожалению, слов мы знаем маловато.

Возьмем, к примеру, приснопамятную Эллочку Щукину. Она, как известно, обходилась всего тридцатью словами (набор слов, который мы используем сами, называется активным лексиконом), хотя понимала она гораздо больше слов, чем говорила сама, т.е. ее так называемый пассивный лексикон был много больше активного. У нас тоже самое. При раздаче объектам наименований совершенно неважно, сколько слов нам знакомо, важно, сколько мы используем сами, а таких слов в разы меньше. Разумеется, оценить уже придуманное слово гораздо проще – мы ведь прекрасно его знаем, так как оно уже находится в пассивном лексиконе.

В практическом плане все это значит следующее:

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

Глоссарий

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

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

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

Стандартность терминологии

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

Лирическое отступление. Русское слово «стул» не кажется кому-то необычным или имманентно плохим, хотя, во-первых, у него есть медицинский омоним и, во-вторых, оно вдвойне искаженное (см. этимологический словарь). Если бы стулья изобрели сейчас, мы, по всей видимости, называли стул словом «чайр» (множ. – «чайры»), поскольку большинство новых слов в настоящее время приходит в русский язык из английского. А слово «самолет» вообще изобрели славянофилы, до этого использовалось слово «аэроплан».

Впрочем, возможно, что если вы используете нестандартные термины, это плохо характеризует не только вас, но и сам стандарт. В самом деле, если используемый термин нестандартен, он, по-видимому, стал таким из-за того что писатель не знает стандартного. А если его не знает писатель, почему его должен знать читатель? Читатели и не знают.

Наконец, нестандартные термины плохи уже тем, что они, как правило, корявы сами по себе. Термин «выпадающий список» будет воспринят потребителем так же легко и быстро, как «раскрывающийся список», а может быть, еще быстрее, но зато он заведомо менее привлекателен. Конечно, все мы непогрешимы и уж если решаем использовать какой-либо нестандартный термин, этот термин – лучший. Но полезно помнить, что, к примеру, глоссарий Microsoft составляется специально работающими над ним профессионалами. Они тоже непогрешимы, при этом заведомо более опытны (просто за счет несопоставимо большего объема работы). Нужно иметь очень веские основания, чтобы не следовать их глоссарию. Если вы делаете это по незнанию или из-за упрямства, вы, по всей видимости, совершаете ошибку.

Внедренная в интерфейс справка

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

• Чтобы воспользоваться справкой или бумажным руководством, пользователю нужно признать, что он не справляется с проблемой. Это психологически тяжело.
• Пользователь знает, что если он воспользуется справкой или, особенно, бумажным руководством, ему придется потратить свое время и силы на поиск нужных сведений – без каких-либо гарантий того, что он вообще найдет ответ на свой вопрос.

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

Но факт налицо. Существует множество вопросов, на которые традиционные руководства отвечают плохо, например:

• Что это такое?
• Как это называется?
• Зачем это нужно?
• Что еще я могу сделать сейчас?

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

Общие требования к ВИС

Внедренная в интерфейс справка должна быть:

• уместной
• легко воспринимающейся
• полезной.

Отсутствие любого из этих качеств делает ВИС неработоспособной, а значит ненужной и лишней.

Уместность

Очень противно, когда мы работаем, а кто-то дает нам непрошенные советы. Даже если совет хорош, он будет принят с благодарностью только в тот момент, когда его можно применить сразу и без раздумий («говорю тебе, нужно было пылесос использовать! Пылесос, а не веник! Теперь конечно уже поздно, но в следующий раз уж будь добр пылесосом сосать!»). Это в полной мере относится и к ВИС. Предъявлять ее пользователю нужно именно в тот момент, когда она действительно нужна и есть основания полагать, что без ВИС пользователь не справится.

Именно нарушение этого требования приводит к фактической неработоспособности подсказок, не относящихся напрямую к текущему действию пользователя (например, MS Agent или так называемые подсказки Совет дня, которые пользователи первым делом отключают).

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

Легкость восприятия

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

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

Соответственно, легкость восприятия ВИС составляется из двух качеств:

• Краткость. Легко достигается редактурой. Наш опыт показывает, что любой свеженаписанный текст можно сократить на четверть, просто убрав лишние слова и обороты, и еще на четверть – выкинув несущественные подробности.
• Качество и однозначность текста. Также достигается редактурой, но уже более сложной (об этом ниже).

Полезность

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

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

Следующие методы неплохо обеспечивают полезность ВИС:

• Лучше не писать в ВИС ответы на вопросы Как сделать?, ограничившись ответами на вопросы Что можно сделать? и Зачем это делать?
• Наиболее полезная часть ВИС – реклама функций, имеющих неочевидный побочный полезный эффект и функций, нужных редко, но зато если уж нужных, то сильно.
• Как и в случае уместности, полезно сначала сделать ВИС и затем спросить себя, не стоит ли ее выкинуть.

Редактирование текстов ВИС

Несмотря на то, что общепринятых критериев качества текста, строго говоря, не существует, несложно выявить четыре общие проблемы текстов, особенно неблаготворно влияющие именно на ВИС:

• Неоднозначность. К этому типу проблем относятся не только формулировки типа «казнить нельзя помиловать», но и более мягкие формы, например, выброшенные слова. В предложении «Кнопка А вызывает Б, а кнопка В – Г» пропущено слово «вызывает» («Кнопка А вызывает Б, а кнопка В вызывает Г». Это вполне приемлемо в обычных текстах (так, этот прием смело применен уже в следующем абзаце), но неприемлемо в ВИС, т.к. требует от пользователя достроить предложение в уме, а на это уходит время.
• Некорректная структура текста. Самое важное должно быть в начале, менее важное – в конце. Например, фраза «Нажмите кнопку А, чтобы сделать Б» некорректна – почему пользователь должен читать первую половину предложения, если он, возможно, делать Б вовсе не хочет? То же относится и ко всему массиву текста ВИС – в начале должно быть самое главное, менее существенные сведения должны приводиться в конце. Кроме того, очень плохи глаголы, оторванные от своих существительных. Фраза «Кнопка А, в обычное время заблокированная, делает Б» не очень хороша – только очень грамотные пользователи воспринимают такие предложения так же быстро, как предложения без разрывов, вроде «Кнопка А делает Б (в обычное время она заблокирована)». Так же стоит соблюдать последовательность в описаниях действий. Например, фраза «сделайте Б, после того как вы сделали А» запутает пользователя. Правильнее написать «сделайте А, а затем Б».
• Медленно воспринимающиеся грамматические конструкции. Фраза «Иннокентий вышел на крыльцо и почесался» воспринимается быстрее фразы «Иннокентий, почесываясь, вышел на крыльцо». Деепричастные обороты всегда воспринимаются медленно; как следствие, использовать их в ВИС не стоит (тем более, что действия, выполняющиеся параллельно, в интерфейсах великая редкость). Еще хуже обстоят дела с отглагольными существительными («выделение») и, в меньшей степени, отглагольными прилагательными («выделенный»). В терминологии Шалтая-Болтая отглагольные существительные – слова-бумажники; чтобы понять, их нужно разложить на составляющие, для чего необходима некоторая когнитивная работа. Только некоторые отглагольные части речи настолько распространены, что их не обязательно декомпозировать при чтении; от остальных нужно безжалостно отказываться. Кроме того, лучше не использовать отрицательные формулировки в описании действий («Не удаляйте нужные файлы»), поскольку такие конструкции изначально содержат избыточность (т.е. отрицание). Текст должен объяснять пользователю, что нужно сделать, а не то, чего делать не нужно – «Вы можете удалить ненужные файлы».
• Лишние слова. Затрудняют восприятие текста и лишние (например, вводные) слова. Следует избегать таких слов, как следовательно, вероятно, разумеется, конечно и т.п.

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

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

1. Перепишите каждое предложение, чтобы оно стало возможно короче (не следя за благозвучностью). Здесь нужно не разделять предложения на части, а вычеркивать несущественные подробности и лишние слова. Если в предложении есть сведения, важные не всем или не всегда, переместите их ближе к концу текста.
2. Избавьтесь от 4/5 отглагольных существительных и прилагательных, превратив их в глаголы.
3. Убедитесь, что все сложные предложения типа «если – то» начинаются с «если», а не с «того».
4. Избавьтесь от половины причастных и от всех деепричастных оборотов. Если понадобится, разделяйте предложения на части.
5. Перепишите текст в командном стиле (в повелительном наклонении).
6. Вычитайте текст на наличие глаголов и прилагательных, оторванных от их существительных.
7. Перепишите текст так, чтобы он обращался к конкретному пользователю, а не просто описывал абстрактное действие. Не «На этом экране можно сделать то-то и то-то», а «На этом экране вы можете сделать то-то и то-то».
8. Избавьтесь от отрицательных формулировок.
9. Проверьте все термины по глоссарию.
10. Теперь и только теперь можно улучшать благозвучность текста. Можете вернуть причастные обороты, чтобы вылечить слишком короткие и от этого неблагозвучные предложения (не надо только возвращать деепричастные обороты).
11. Перечитайте текст ВИС и решите, достаточно ли он хорош, чтобы его оставить. Если сочтете, что текст получился малополезным – уберите его.

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

• Не забывайте выполнять резервное копирование. Фраза прекрасна по форме, но содержание можно улучшить – здесь никак не говорится, зачем резервное копирование нужно пользователю и когда его надо выполнять. Каждый новый день без резервного копирования грозит вам потерей ваших данных и большими неприятностями.
• Чтобы приступить к поиску, следуйте инструкциям на левой панели. Слишком длинно. Начните поиск в левой панели.
• Часть имени или имя файла целиком. Длинно и сложно по форме. Имя или часть имени файла.
• Выключение брандмауэра Windows приводит к снижению защищенности компьютера от вирусных атак и злоумышленников. Три отглагольных существительных (выключение, снижение, защищенность) и обезличенное предложение. Если вы отключите брандмауэр Windows, ваш компьютер будет хуже защищен от вирусов и злоумышленников.
• Если Вы имеете большое количество адресатов, довольно удобно осуществлять поиск по адресной книге. Слишком длинное предложение. Достаточно всего лишь подсказать пользователю, что удобнее пользоваться адресной книгой. Используйте адресную книгу для поиска адресатов.
• Вы можете добраться до интересующего вас мероприятия, воспользовавшись панелью навигации в левой части страницы. Лишний деепричастный оборот и отсутствует командный стиль. Слово «интересующий» можно выкинуть как лишнее, т.к. уже подразумевается, что пользователь выбирает именно интересующее его мероприятие. Фразу «в левой части страницы» можно и нужно заменить на «слева». Выберите мероприятие из списка в левой панели.
• Осуществить выбор адресата для написания письма можно со страницы «Написать письмо». «Осуществить выбор» – отглагольное существительное («выбрать»). «Для написания письма» – абсолютно лишняя фраза (к тому же с отглагольным существительным). Отсутствует командный стиль. Выберите адресата на странице «Написать письмо».
• Для оптимизации работы вам предоставляется возможность настройки режима фильтрации. Фраза «предоставляется возможность настройки» слишком длинная, не говорит о действии, которое может совершить пользователь, и содержит отглагольное существительное. Достаточно написать «настройте» (при этом само предложение превратится в командное). Для оптимизации работы настройте фильтры.
• Страница предназначена для создания нового письма и выполнения с ним необходимых операций. Помимо создания текста письма, на этой странице можно осуществить прикрепление файла. «Страница предназначена» – проще и короче заменить на «здесь». «Создание», «выполнение» и «прикрепление» – отглагольные существительные. «Нового письма» – слово «новое» является лишним. Если вы создаете письмо, а не дописываете его, то уже подразумевается, что письмо новое. «Помимо создания текста письма» – слишком длинная и лишняя фраза, повторяющая смысл первого предложения, ее можно заменить на «а также». «На этой странице» – повтор. «Можно осуществить прикрепление» – канцеляризм (сложное сказуемое в сочетании с отглагольным существительным), нужно упростить до глагола «прикрепить». Наконец, говорить о том, что пользователь может выполнить «необходимые операции» бессмысленно, эта формулировка полностью неконкретна: если не получается написать, что именно можно делать, лучше не писать ничего. Здесь вы можете создать письмо и прикрепить к нему файл.
• Непосредственно перед созданием дистрибутива следует убрать отладочную информацию. «Следует убрать» – «уберите». Слово «непосредственно» лишнее рядом с предлогом «перед». Уберите отладочную информацию перед созданием дистрибутива.
• Найти можно все, используя одно или несколько слов, касающихся интересующей вас темы, и везде – выбрав в списках нужный раздел или формат или отрасль. Запутанное предложение с многочисленными грамматическими конструкциями. Его можно сильно упростить, просто указав пользователю, что и как он может сделать. Вы можете искать по словам или же выбрать в списках нужный раздел, формат или отрасль.

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