Содержание

RTFM (компьютерный сленг) | это… Что такое RTFM (компьютерный сленг)?

У этого термина существуют и другие значения, см. RTFM.

RTFM — аббревиатура, означающая «Read The Fucking Manual» (Читай долбаное руководство). Исходный вариант расшифровки — Read The Following Materials (Читай сопроводительную документацию) или Read Twice the Fine Manual).

Также имеет место близкое и схожее выражение:
RTFW — аббревиатура, означающая «Read The Fucking Web» (Читай долбаный веб).

Употребляется как ироничный уклон от вопроса, ответ на который может быть получен чтением общеизвестной документации. Подразумевается, что спрашивающий уже должен обладать определенной квалификацией, и знать ответ на задаваемый вопрос (или же информация является легкодоступной, и вопрос свидетельствует, что спрашивающий даже не пытался получить на него ответ). Смысл употребления RTFM буквально таков: «Да прочитай же, в конце концов, это долбаное руководство и перестань задавать глупые вопросы».

Также есть облегченная версия данной аббревиатуры, не столь грубая и часто использующаяся в качестве названия внутреннего сайта организации, содержащего полезную для сотрудников информацию — Read The FAQ & Manuals.

Буква <F> может быть полностью исключена, и акроним примет вид RTM, т. е. Read The Manual (прочитай руководство). Так говорят, если знают, что спрашивающий обладает достаточной квалификацией (или недостаточным чувством юмора), тем самым смягчая степень улыбки над ним, своеобразное проявление уважения.

Облегченный термин — RTBM, т. е. Read This Bloody Manual (прочитай это проклятое руководство), в качестве первоначального ответа. Если обсуждение разрастается, для ответа начинают использовать RTFM.

В сетевом сленге существуют и другие производные этого выражения, например, RTFS, то есть Read The Fucking Source (просмотри долбаный исходник, имеется в виду исходный текст программы), и RTFB, т.  е. Read The Fucking Binary (просмотри долбаный бинарник, имеется в виду машинный код программы). Смысл RTFS несет и вариант, вдохновлённый <Звёздными войнами>: UTSL, то есть Use The Source, Luke (используй исходник, Люк), — игра слов с выражением Use The Force, Luke (используй Силу, Люк).

Эти версии менее бранные чем RTFM и используются в юмористическом смысле, поскольку предполагается, что это ошибка разработчика, не предоставившего документацию — в частности RTFB используется, чтобы указать, что программа является настолько старой или плохо задокументированной, что единственный способ понять, что она делает, — это исследовать машинный код. На Slashdot распространён вариант RTFA, то есть Read The Fucking Article (прочитай долбаную статью), обычно используемый в отношении того, кто оставил комментарий, из которого ясно, что он на самом деле не прочитал соответствующую статью.

Вариант, впервые зафиксированный в Usenet в 1996, — STFW, Search The Fucking Web (ищи в долбаной Сети). Более конкретная версия — UTFG, Use The Fucking Google (используй долбаный Google).

Словарь молодежного сленга — rtfm

  1. прочитай сопроводительную документацию, указание на то, что ответ на вопрос давно известен, а автор вопроса не очень компетентен.
  2. Read the Fucking Manual прочитай чёртову инструкцию.

Пример текста: Умер программист. Попал к Б-гу на суд, и начинает плакаться: Господи, почему я умер так рано? Ведь я был хорошим, жене не изменял, вирусов не писал, на порносайты не лазил, спам не рассылал, за что ты меня лишил жизни? Б-г поднимает библию и говорит: RTFM… • Напомню еще раз истину (RTFM однако). • Чти первоисточники, виндовому админу они нужны нисколько не меньше, RTFM вобщем. • Прочтение данной статьи ни в коем случае не освобождает от прочтения документации, тем более, что она на русском. RTFM, господа! • RTFM, я уже заколебался всем людям с этой материнкой об этом говорить.

Происхождение: Англ. Read the Following Manual (как вариант, Read the Fucking Manual) , означающее ровно то же самое.

Синонимы: РТФМ учи матчасть.

(айтишники, хакеры)

Аббревиатура RTFM является сокращением от английской фразы » read the following manual», что можно перевести на русский язык, как » обратитесь к прилагаемому руководству«. Это типичнейший ответ, который получает простой пользователь после обращения в службу поддержки на какой-нибудь простейший вопрос. Как правило, к ответу прилагается название данной инструкции или его идентификационный номер. Ознакомьтесь с ещё несколькими популярным аббревиатурами, такими как СПС, РОФЛ, ПТН ПНХ и т. д.

Через некоторое время данная аббревиатура получила вторую жизнь во всемирной паутине. Правда здесь её расшифровка несколько изменилась и произносится, как » read the fucking manual» ( прочти эту ёба…ую инструкцию) или (прочти блядь, эту инструкцию наконец). Смысл этой фразы варьируется в зависимости от контекста.

Это такое не очень приятное пожелание новичку, чтобы он перестал задавать примитивные вопросы и вместо этого прочёл прилагаемое руководство или справку. Сначала данное словосочетание активно использовали люди, которые изучали Юникс (операционную систему) в usernet, но в наше время эту аббревиатуру применяют, как по поводу, так и без повода.

Термин RTFM может породить много негатива, особенно, если все знают, что этого самого руководства не существует в природе.

  Как правильно пропатчить KDE 2 под операционную систему Free BSD?

  RTFM нубяра!

Как связана аббревиатура RTFM и аниме?

Этот термин может быть использован в связи с манга, ибо именно манга считается первоисточником. Например » read the fucking manga» (прочти эту ёбан…ую мангу).

Ещё интересная деталь. Вы знаете, что один из форматов текстового редактора Word является .RTF? И что самое забавное большинство инструкций написаны именно в этом формате.

RTFM 3 D анимация

РТФМ | Знай свой мем

43

184 519
0
39
Часть серии о Интернет-сленг. [Просмотреть связанные записи]
Мем
Положение дел
Подтвержденный
Год
1979 г.
Источник
Различные апокрифические источники
Теги
аббревиатуры, инициализмы, textual, fortran, fark, slashdot, lmgtfy, lurk moar, comment, комментарии
Дополнительные ссылки
Энциклопедия Драматика Википедия

О

RTFM — это аббревиатура от «Read The Fucking Manual», которая используется в ответ на вопрос новичка, который может быть сочтен ненужным или излишним, если бы этот человек заранее провел некоторые базовые исследования по этому вопросу.

Противоположностью RTFM является TL; DR, что означает «слишком длинный; не читал.»

Происхождение

Хотя это в значительной степени необоснованно, использование RTFM, возможно, началось как военный жаргон во время Второй мировой войны, когда фраза «Прочитайте боевое руководство» стала основным выражением среди американских солдат в ответ на основные вопросы, заданные новобранцами. Впервые введен в 1939, Полевые уставы армии США содержали инструкции по всем жизненно важным навыкам для солдата, от того, как правильно складывать одежду, до того, как бросить гранату внутрь танка противника.

Самый ранний подтвержденный экземпляр RTFM был напечатан в 1979 году. Руководство пользователя LINPACK

[1] , руководство по использованию программной библиотеки линейной алгебры LINPACK, написанное для языка программирования Fortran. В разделе оглавления текст отображается как цитата, приписываемая Anonymous:

.

Содержание
«R. T.F.M.» —Анонимный

ПРЕДИСЛОВИЕ ……………………………………………………..v
ВВЕДЕНИЕ
1. Обзор………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………. 2.Использование…………………………………………1.2

…

Первая статья Urban Dictionary [2] для RTFM была представлена ​​13 ноября 2003 г., хотя ее использование было задокументировано в комментариях Slashdot еще в марте 1999 г.

Прочтите руководство по траху
Skilless15: что такое rtfm
Skilless15: я забыл
@avaxx: прочитай гребаное руководство.
Скиллесс15: почему
Скиллесс15: ты мог бы просто сказать мне

Разворот

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

пародии

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



Использование

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

Новичок: как стрелять из огнеметов?
Опытный игрок: RTFM чувак.

Однако некоторые критики утверждают, что частые пользователи этого термина просто проявляют элитарность по отношению к новичкам, тем самым отталкивая их, не давая никаких советов или полезных предложений. Это особенно верно, когда RTFM используется, даже не указывая, какое руководство должен читать их корреспондент. При отсутствии мануала можно посоветовать Lurk Moar.

Производные

Существуют также производные термины, используемые в различных типах онлайн-форумов и сообществ:

RTFA : Прочитать чертову статью
WTFV : Посмотреть чертово видео
GIYF : Google – твой друг 4 RTFSC : прочитайте свой гребаный исходный код
LMGTFY : Позвольте мне погуглить это для вас
RTFA

RTFA («Прочитай чертову статью») и TFA («Чертова статья») обычно использовались на Slashdot 9.0054 [3] , Fark [4] , Digg [5] и другие агрегаторы социальных новостей. Одно из самых ранних упоминаний о RTFA можно найти в комментарии [6] , опубликованном пользователем Obi-Juan 20 августа 2003 г.:

.
Блин, хороший заголовок!

/нет RTFA

Л.М.Г.Т.Ф.И.

LMGTFY, или «Позвольте мне погуглить это для вас», представляет собой саркастический вариант RTFM, который, казалось бы, предлагает руку помощи запутавшемуся пользователю, но также высмеивает его / ее, демонстрируя, как легко можно найти самопомощь через всеобъемлющие поисковые системы, такие как Google. LMGTFY.com [7] был зарегистрирован в ноябре 2008 года, предоставляя новичкам надежный обучающий инструмент для поиска Google.

Пользователь A: Откуда мы знаем, что Fox News не является честным и сбалансированным?
Пользователь Б: LMGTFY.

Внешние ссылки

[1] Google Книги – Руководство пользователя LINPACK

[2] Городской словарь – RTFM / Опубликовано 19.11.2003

[3] Slashdot – Спросите у Slashdot: существует ли репозиторий ключей PGP? / Опубликовано 16.03.1999

[4] Фарк — новый Battlestar Galactica отстой — просто спросите парня в нем

[5] Digg — Как привлечь пользователей к RTFM

[6] Fark – FDA снимает предупреждения о продуктах, содержащих олестру, говоря, что им наплевать / 20 августа 2003 г.

[7] LMGTFY — Позвольте мне погуглить это для вас / Запущен в ноябре 2008 г.

Последние видео

В настоящее время нет доступных видео.

+ Добавить видео

Последние изображения

Всего 39 + Добавить изображение

Просмотреть все изображения


RTFM — это слово из четырех букв

Один из этих четырех обменов регулярно происходит в повседневной жизни…

Турист: «Кажется, я заблудился, подскажите, пожалуйста, как пройти в Национальную портретную галерею?»

Полицейский: «Читайте гребаную карту!»

Закусочная: «Извините, какие сегодня блюда?»

Официантка: «Читайте е**ное меню!»

Интервьюер: «А, министр, какова ваша политика в отношении безработицы?»

Политик: «Читайте гребаный манифест!»

Исследователь: «Как преобразовать мою модель в PDF, если она не работает?»

Разработчик: «Читайте гребаный мануал!»

Да, это номер 4, ответ настолько популярен, что у него есть собственная аббревиатура — RTFM — и статья в Википедии!

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

Учитывая объем безмозглых, безвольных, бесхитростных, бесхитростных, злонамеренных, неизбежно анонимных разглагольствований, которые вызывает любой запрос «Прокомментируйте эту новость/публикацию/видео/изображение», это кажется так. Но это печальное положение дел для разработчиков программного обеспечения, и в этой статье я расскажу почему, с помощью единомышленников виртуального мира, которые мне услужливо открыл Google.

Зачем сообщать пользователю RTFM?

Почему RTFM считается подходящим ответом на крик о помощи?

Что ж, RTFM — отличный способ излить свое недовольство на тех пользователей, которые не тратят время на чтение руководства и тратят ваше время на просьбы о помощи. Но RTFM также экономит ваше время, поскольку вам не нужно объяснять этим пользователям ни решения их проблем, ни то, где они могут найти решения. Как следствие, RTFM был принят в качестве действительного ответа в том, что было названо Культура самообучения проектов с открытым исходным кодом, что является следствием ограниченных финансовых и человеческих ресурсов, доступных для этих проектов (см. RTFM! Культура самообучения в проектах программного обеспечения с открытым исходным кодом М. Т. Шефера и П. Кранцльмюллера).

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

Почему вы никогда не должны рассказывать пользователям о RTFM

Итак, у RTFM есть некоторые (предположительно) преимущества, но давайте поднимем камень и посмотрим, какая тьма скрывается под ним…

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

Ваша грубость, в свою очередь, может заставить вас звучать как озлобленный, высокомерный, агрессивный представитель элиты. Энди Лестер комментирует, что RTFM «используется как ответ на вопрос, который компьютерщик думает, что его не должны были спрашивать… это как если бы грубый компьютерщик говорит: «Информация существует по крайней мере в одном месте, о котором я знаю, и поэтому вы тоже должны знать эту информацию». Джек Уоллен, которому сделал RTFM с небольшим успехом, комментирует, что «если вы когда-нибудь ищете помощи с… открытым исходным кодом и слышите фразу RTFM, знайте, что, скорее всего, это либо кто-то слишком ленив, чтобы печатать или помочь, либо кто-то хочет убедиться вы точно понимаете, какую помощь вы ищете, прежде чем искать ». У разработчиков программного обеспечения достаточно проблем с имиджем, даже если они добровольно не подчиняются своим худшим стереотипам! Хуже того, кто-то может подписаться на вас с полезным ответом. Как подчеркивается в блоге SQLskills.com, «… придет полезный человек и добавит хороший ответ с несколькими полезными ссылками и советами… и парень с ‘RTFM’ в конечном итоге будет выглядеть как болван!»

Мало того, что RTFM может плохо отразиться на вас, его порча может распространиться на вашу организацию или сообщество. Рассмотрим этот комментарий в блоге SQLskills.com «RTFM — стандартный ответ, который вы получаете на форумах [имя удалено, чтобы не краснеть]. Неужели мы действительно хотим так повернуться?» Это может быть особенно разрушительным для имиджа проектов с открытым исходным кодом, поскольку противоречит (предполагаемой) общественной направленности таких проектов (в отличие от скрытного злого мира проприетарных корпораций). Джек Уоллен комментирует, что «RTFM» — это «…почти боевой клич сообщества открытого исходного кода». Grumpy Nerd в своем блоге под названием «Я ненавижу программное обеспечение с открытым исходным кодом — почему открытый исходный код — это отстой» утверждал «… я должен поставить свою работу на то, сколько времени обработают заявку четырех сварливых кретинов, болтающихся на Source Forge, которые собираются сказать мне в RTFM» (до добавления «к которому нет гребаного мануала, потому что никто не удосужился его написать»).

Итак, RTFM может привести к тому, что вы, ваш проект, ваша организация и ваше сообщество потеряете лицо, но все равно сэкономит время, верно? Э, нет, это не намного быстрее, чем вежливый ответ. Плакат в блоге SQLskills.com комментирует: «Я всегда хихикаю, когда кто-то публикует ответ типа «RTFM», хотя было бы быстрее просто ответить на вопрос». Действительно, помогая пользователю найти информацию сейчас, вы можете уберечь себя от запросов о помощи от того же пользователя в будущем.

Если этого недостаточно, RTFM также предполагает, что пользователь еще не прочитал руководство. В то время как некоторые люди взывают о помощи при первых признаках беды, для многих других это крайняя мера. Сообщение в блоге Джека Уоллена под метким названием «RTFM: я сделал, и это не помогло» перечисляет его сражения с руководством. Череда сражений с плохим руководством может сделать пользователя более склонным обращаться за помощью в первую очередь. Без дополнительной информации, как вы знаете?

RTFM также может удерживать других от обращения за помощью. Рассмотрим нового пользователя, который ищет помощи, безрезультатно ищет, думает о том, чтобы отправить электронное письмо за помощью, сначала проверяет архив электронной почты, затем видит «RTFM… RTFM… RTFM» и решает хранить молчание. Это может, как следствие, удержать их от использования вашего программного обеспечения, а не программ с аналогичными функциями, но более поддерживающими сообществами.

Возможно, пользователь не может найти ваше руководство

Может быть, пользователь не может найти руководство, потому что ваш дистрибутив или версия программного обеспечения плохо спроектированы? Как говорится в комментарии в блоге SQLskills.com, «TFM не всегда легко прочитать или найти». Обычный ответ на это — «используйте Google», но если пользователь может узнать больше о вашем программном обеспечении только через Google, что это говорит о простоте использования и навигации по вашему веб-сайту? Это проблема, которая нуждается в сортировке, вот что он говорит!

Вместо того, чтобы прыгать с «RTFM», подумайте, легко ли доступно ваше руководство (или часто задаваемые вопросы, учебник или что-то еще). Да, вы знаете, где это, но это ваше программное обеспечение, а как насчет нового пользователя? Повторяющиеся просьбы о помощи могут указывать на то, что у пользователей возникают проблемы с поиском вашего руководства, и пока вы их не спросите, вы никогда об этом не узнаете.

Возможно, ваше руководство можно было бы улучшить

Возможно, ваше руководство плохо составлено, неполно или неясно. Откуда вы знаете? Вы когда-нибудь использовали его сами? Возможно, нет, поскольку вы написали свою программу так, что она вам не нужна. Программное обеспечение с открытым исходным кодом, в частности, было забито из-за качества документации. Возьмем, к примеру, Grumpy Nerd: «Писать документацию — отстой. Вот почему большинство программ с открытым исходным кодом содержит ошибки и практически не содержит документации, что делает их бесполезными для всех, кроме авторов». Или Design by Fire, который комментирует в посте под заголовком «Я бы выбрал RTFM, если бы существовала связь между FM и FR», что «документация по технологии OpenSource поистине ужасна… тем, у кого в жизни нет ничего лучше, чем запоминать огромное количество непонятного синтаксиса командной строки и пить много Red Bull». Джек Уоллен документирует свои сражения с конкретным продуктом с открытым исходным кодом и его документацией и справедливо заключает, что в таких ситуациях у пользователей может не быть другого выбора, кроме как обратиться за помощью, «в сообществе открытого исходного кода FM — это сообщество в большинстве случаев. И когда мы обращаемся за помощью, мы ЗВОНИМ».

Что он делает, как он это делает и как его использовать

Иногда руководства не предоставляют пользователям информацию, необходимую им для использования программного обеспечения. Руководства часто сосредоточены на том, что делает программное обеспечение, с исчерпывающими списками параметров и параметров командной строки. Программное обеспечение для исследований часто указывает пользователям на документ, в котором описывается, как работает программное обеспечение, что понятно, поскольку код воплощает новизну исследования. К сожалению, рассказать пользователю, что делает программное обеспечение и как оно работает, — это не то же самое, что рассказать ему, как его использовать, не более чем рассказать человеку, что делает машина и как работает двигатель, который помогает ему управлять ею. Это был опыт Джека Уоллена: «Я никогда не сталкивался с« FM », которому так не хватало фактической области« как ».

Пользователи отклоняются от документации

Carroll et al. при исследовании минимальных руководств заметил, что пользователи, особенно новые пользователи, часто отклоняются от пошагового механического следования документации с «эпизодами самостоятельного решения проблем». Такое поведение было мотивировано скрытой мотивацией пользователей начать использовать программное обеспечение для решения своих проблем и достижения своих целей как можно скорее. Они цитируют одного пользователя, который прокомментировал: «Я хочу что-то делать, а не учиться делать все». Несмотря на то, что они датируются серединой 80-х годов, наблюдения Кэрролла и др. представляют интерес для чтения:

  • Минимальное руководство от Carroll, J.M., Smith-Kerker, P.L., Ford, J.R. и Mazur-Rimetz, S.A..
  • Обучение использованию текстовых процессоров: проблемы и перспективы, Мак Р.Л., Льюис С.Х. и Кэрролл Дж.М.
Разные типы пользователей имеют разные потребности

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

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

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

Например, программное обеспечение для управления распределенными данными OGSA-DAI может быть развернуто для предоставления баз данных в качестве веб-служб или конечных точек RESTful без необходимости написания какого-либо кода: оно предоставляет клиентский инструментарий Java, позволяющий разрабатывать клиенты, использующие эти конечные точки для доступа к данным; он предоставляет серверные API, позволяющие писать компоненты для реализации функций преобразования данных; и это открытый исходный код, поэтому саму структуру OGSA-DAI можно изменить. Каждый из этих классов пользователей — развертыватель, пользователь клиента, разработчик клиента, разработчик сервера, разработчик фреймворка — имеет определенные задачи, которые они хотят выполнять, и для этого требуются определенные типы знаний. Как следствие, пользовательская документация разделена на разделы для каждого из этих классов пользователей.

Неверная и противоречивая информация

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

Неточная информация

Я сбился со счета, сколько раз я читал руководства, в которых говорится: «теперь отредактируйте файл конфигурации соединения», «используйте класс запросов» или «теперь запустите приложение на входах». Затем мне нужно просмотреть программное обеспечение или документацию, чтобы найти расположение файла конфигурации соединения, полный пакет Java и имя класса класса запроса или точно, какой вызов командной строки необходим для запуска приложения. Еще больше расстраивает, если я знаю, что разработчик, написавший документацию, знал эту информацию, но не удосужился потратить время на то, чтобы поделиться ею с такими пользователями, как я!

ВАБМ?

Вместо того, чтобы прыгать с «RTFM», подумайте, нужен ли вам WABM («напишите лучшее руководство»). Не относитесь к руководствам как к чему-то второстепенному, а как к неотъемлемой части вашего программного обеспечения, заслуживающей столько же времени, заботы и внимания с точки зрения дизайна, разработки и — да — тестирования, а также постоянного улучшения и рефакторинга, как и ваш код!

Советы по написанию пользовательской документации см. по адресу:

  • Гуру юзабилити Брюс Тоньяццини «Как опубликовать отличное руководство пользователя»
  • UserFocus, Советы по написанию руководств пользователя

Возможно, ваше программное обеспечение можно улучшить

Возможно, проблема не в руководстве, а в программном обеспечении! Упрощение использования вашего программного обеспечения может уменьшить зависимость пользователя от вашей документации и снизить риск того, что ему придется обратиться за помощью. Это также может облегчить написание вашей документации — распространено утверждение, что чем более удобно использовать программное обеспечение, тем легче его описывать и объяснять.

Гуру юзабилити Якоб Нильсен перечисляет эвристики для разработки полезного программного обеспечения. Это относится не только к графическим интерфейсам, но и к инструментам командной строки. Одна эвристика — «Помогайте пользователям распознавать, диагностировать и исправлять ошибки». Теперь следующее поможет пользователю распознать ошибку:

$ загрузить configFile.xml
Ошибка

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

$ загрузить configFile.xml
Ошибка синтаксического анализа XML в строке 4, символ 2 в файле configFile.xml.
Неизвестный элемент: база данныхUL.
Правовые элементы включают в себя: databaseURL, databaseUserName, databasePassword.

Пользователь информируется не только о наличии ошибки, но и о причине возникновения ошибки и ее происхождении.

Малкольм Барклай комментирует , что «RTFM не является оправданием для того, чтобы не иметь хорошо продуманного, кодированного и отполированного дизайна с хорошим удобством использования, размещенным прямо в центре».

Но как насчет пользователей, которые кричат ​​«помогите» в первую очередь, а не в последнюю очередь?

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

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

Предложения для более гражданского мира программного обеспечения

Итак, резюмируя некоторые важные советы,

  • Будьте любознательны. Возможно, пользователь прочитал руководство… вы не можете знать, пока не спросите. Джефф Лант комментирует: «Спросите, почему — прежде всего вам нужно понять, почему у пользователя возникла проблема с вашим приложением, затем вам нужно исправить недостаток, который вызывает проблему, в первую очередь, тем самым устраняя необходимость в том, чтобы пользователь вообще задавать вопрос».
  • Это не просто ваше изображение. Когда вы взаимодействуете со своими пользователями, вы представляете не только себя, но и свой проект, организацию и сообщество, а пользователи будут судить о целом по его частям.
  • Рассматривайте просьбы о помощи как возможность для самосовершенствования. Вместо ответа с помощью RTFM подумайте, не нужно ли вам переписать ошибочное руководство. Читайте о пользовательском опыте и о том, что хорошо, а что плохо, документацию и справку. Или подумайте, не могли бы вы переписать свое программное обеспечение, чтобы сделать его более удобным в использовании.
  • Итеративная разработка работает и для руководств. Не относитесь к руководствам как к чему-то второстепенному, а как к неотъемлемой части вашего программного обеспечения, заслуживающей такого же постоянного улучшения и рефакторинга, как и ваш код!
  • Вежливость ничего не стоит. В то время как написание документации сложно и занимает много времени, вежливость — это легко и дешево.

    No related posts.