Сообщения для всех и проверка текстов - Сайт неОчем
Сайт неОчем
Статистика


Нас находят по:
Форма входа
Инструменты сайта
Вы можете быть услышанными на следующих страницах:

Следите за новыми статьями на сайте через:
Следить в Twitter
Следить в Digg
Или читайте мысли в RSS: Читать через RSS

Так же вы можете:
  • Слушать on-line радио

Каталог мыслей


Главная » Каталог мыслей » QA » Сообщения для всех и проверка текстов

2010-03-12
[22:40]
Сообщения для всех и проверка текстов
Вы наверняка попадали в ситуацию, когда программа отказывается выполнять какую-либо команду, выбрасывает сообщение об ошибке, и, тем не менее, Вы не знаете, что делать дальше, как обойти и решить проблему.
Почему возникают такие тупиковые ситуации? Кто-то скажет: "Так научись пользоваться программой, прочитай руководство пользователя, а потом пользуйся программой!". Или, как вариант: "Изучи технологию сперва и все станет ясно". Некоторые "умники" могут даже сказать: "Что ж тут не ясно?! Надо установить дополнительный модуль Х и только потом выполнять эту команду. Эх, ламер!". Такая установка разработчиков ПО - это демонстрация непрофессионализма.

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

Вот один из характерных, но не самых ужасных, примеров. При попытке открыть определенный (не все) PICT файл в Adobe Illustrator 7 for Macintosh, программа сообщает:

"The MPS parser is unable to parse the file. [OK]"

При этом:

PICT файл успешно открывается в других программах (Picture Viewer, PowerPoint).
PICT файл успешно открывается в новых версиях Illustrator.
Есть вероятность того, что программа У, которая создала PICT файл, не совсем корректно записала определенную информацию, так как другие PICT файлы (с другими наборами объектов на изображении), открываются в Illustrator нормально.
В любом случае, вне зависимости от того, правильный ли PICT или нет, Illustrator (равно как и другие программы) должны выдавать адекватные и понятные сообщения. А что мы видим в данном случае?

"MPS parser". Что такое MPS? Я думаю, что большинство читающих эти строки не знают, что это такое. При этом, так или иначе, пользовались или как минимум запускали Illustrator. Я не являюсь исключением в этом отношении. Подозреваю, что MPS parser - это какой-то Adobe'вский модуль, предназначенный для интерпретации PICT команд. Поверхностный поиск определения "MPS" в Google ничего не дал. Но при этом я встретил много пользователей Illustrator на форумах, которые пытались выяснить, как обойти это сообщение. По большому счету, не так уж и важно обыкновенному пользователю знать, что такое MPS. Но я думаю, многие согласятся, что сокращение "MPS" просто конфузит большинство пользователей, и не дает никакой подсказки или идеи, что ж это за парсер.

"unable to parse". Это уже что-то! Тут Вам уже ясно, что в PICT файле есть что-то, что Illustrator не понимает. Но что? Об этом Adobe почему-то умалчивает. Но ведь эта информация является ключевой для того, чтобы подсказать пользователю, что делать дальше.

Далее... Ну и что, что "unable to parse"? Что это означает? Файл не будет открываться вообще? Или же файл откроется, но без определенных объектов? Не ясно... Не ясно, пока Вы не нажмете ОК в сообщении. А может, для кого-то вызывать это сообщение и нажимать ОК придется несколько раз, чтобы понять, что файл не будет открыт вообще. И, наконец, самое главное...

Что Вам теперь делать? Я думаю, для многих пользователей такое сообщение - это тупик, если не связаться со службой технической поддержки Adobe... или производителя программы У. Это выбор и еще одна неуютная ситуация для пользователя. Особенно если еще учесть, что не часто техподдержка бывает понятной и оперативной, при этом пользователю надо срочно закончить работу с этим PICT файлом... Короче, получаем несчастного пользователя, который недоволен и Adobe, и PICT файлом, и программой Х, и техподдержкой. В итоге, как минимум, у пользователя остается негатив о работе с программой, пользователь жалуется своим коллегам на программу. Или чего хуже - возвращает программу производителю. В любом случае производитель теряет пользователей и деньги.

Вот еще несколько примеров реальных плохих сообщений:

Sorry, the operation could not be completed due to a system error: (Access Denied)
[OK]

Unable to open a required temporary file. Please verify that you have the proper permissions for your system.
[OK]

А вот совсем курьезные сообщения:

CPU not found! Sorry.
[OK] [Report]

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

Неопределенная ошибка.
[Закрыть] [Подробности]

А чего стоят сообщения типа "Ошибка №45876 [OK]" ?!

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

Как должны выглядеть информативные и понятные сообщения?

По-моему, самые интересные и полезные советы и рекомендации можно найти в руководствах по разработке пользовательского интерфейса от Apple, в частности, в "Руководстве по разработке пользовательского интерфейса Аква" (Aqua Human Interface Guidelines). Я (да и не только) считаю Apple законодателем мод в разработке пользовательских интерфейсов. Также соответствующие разделы по разработке сообщений можно найти в документации от Microsoft, в частности, "Vista UX Guide".

Я следую следующим принципам и приемам в написании сообщений:

1. В общем случае сообщения должны содержать 3 условные части:
    1) Утверждение о том, что произошло. Как правило, это утверждение того, чего не удается сделать, что не будет сделано программой.
    2) Причина проблемы.
    3) Рекомендации как решить, или обойти проблему
    В отдельных простых и очевидных случаях можно комбинировать или опускать эти составляющие.
2. Избегайте сокращений.
3. Сообщения должны быть написаны простым человеческим языком.
4. Сообщения должны быть лаконичными, без лишних технических деталей (если того не требует аудитория).

Таким образом, Адобовское сообщение про "unable to parse" я бы переписал следующим образом:

Cannot open the file.
Adobe Meta Picture Series parser cannot handle data in the file you try to open.
Make sure: 
- the file is not corrupted
- Adobe Illustrator is properly installed. You may want to reinstall it.
- You have the latest version of Meta Picture Series parser installed. Check www.adobe.com for it.
Then try to open file again.
[OK]

Сразу уточню, я не знаю, как расшифровать MPS. "Meta Picture Series" - это моя выдумка. Я не знаю всех случаев, когда должно появляться оригинальное сообщение. Я только знаю, что этот парсер "загибается" на определенных последовательностях PICT команд. И это не только ошибка PICT файла, так как новые версии Illustrator открывают этот файл.
Я надеюсь, Вы понимаете, что мои предположение не столь важны для этого примера. В любом случае, обладая полной информацией, можно написать отличное сообщение.

Или как вариант:

Сannot open the file.
The file requires a bigger canvas to display than the maximum canvas size of Illustrator. 
Decrease the picture size and try to open the file again.
[OK]

А вот как бы я переписал сообщение про "unable to open a required temporary file":

[Program] cannot run because it cannot create a temporary file.
Either the temporary folder does not exist or it exists but [program] cannot write a file in it (probably the file is write protected).
Location [program] is trying to access: [path]
Check that this folder exists, and that its properties are set to allow programs to create new files within it.
[OK]

Как обеспечить Вашу программу качественными сообщениями?

Вы, как тестировщик проекта, должны организовать процесс написания, проверки, корректировки и утверждения сообщений и контролировать его. Сообщения должны соответствовать правилам и рекомендациям по написанию сообщений, таким как, AHIG, APPLE Publications Stye Guide, Vista UX Guide. 

Может возникнуть вопрос, а кто должен составлять сообщения. Как правило, сообщения - это результат коллективного труда. Кто как не программист знает, в каких случаях возникает ошибка. Зная причину ошибки, именно программист может обобщить, описать ошибку и рассказать, как ее обойти. Поэтому как минимум, программист должен составить черновой вариант сообщения, который будет отражать суть проблемы и пути ее решения. Хорошо, если инженер корректно и грамотно изложил сообщение. В противном случае, может понадобиться помощь ваша или технического редактора в редактировании текста. Так что учите программистов писать хорошие сообщения. Программисты должны иметь хотя бы общее представление о принципах написания сообщений.

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

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

Тексты на чужом языке

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

Проверять нужно не только новые тексты, но и изменения в уже существующем тексте.

Какие тексты следует проверять помимо текстов сообщений:

- Тексты в окне документа (панели инструментов, панель статуса, и т. д.)
- Подсказки на кнопках панели инструментов, подсказки в диалоговых окнах
- Любые тексты в диалогах
- Окно "О программе"
- Тексты в руководстве пользователя
- Пункты меню
- Тексты на картинках (splash screens)
- Названия папок программы
- Названия файлов программы
- Тексты в шаблонах, примерах и других модулях, поставляемых с программой.
- Тексты, которые автоматически генерируются программой.
- Техническая документация, которую может увидеть заказчик

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

Проверка и корректировка текстов 

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

Проверять и корректировать текстов можно как по ходу разработки программы (по мере возникновения необходимости в сообщении), так и все тексты сразу в конце разработки.

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

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

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

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

Добавил: Elio | Дата: 2010-03-12 | Просмотров: 1321 | Комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Карта сайта
Copyright elio.net.ua©
Хостинг от uCoz