О значимых сообщениях в вашем программном обеспечении

Question

Я не понимаю, как писать хорошие сообщения для моего ПО. как это ниже:

"Чтобы сохранить проект, нажмите кнопку« Сохранить ». Чтобы отменить его, нажмите кнопку« Отмена »."

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

Answer 1

Лично мне нравятся сообщения, которые не должны много объяснять. Ошибка номер один в приложениях для Windows - наличие кнопок со стандартным текстом вместо операции, выполняемой при нажатии.

Пример: вместо этого:

Do you want to save the changes before closing?
- To save the changes press Yes
- To discard the changes press No
- To cancel and keep the application open press Cancel
[Yes] [No] [Cancel]

Мне нравится

Do you want to save the changes before closing?
[Save] [Discard] [Cancel]

Answer 2

В режиме doupt добавьте параметр справки.

Так что вместо:

«Введите S для сохранения C для отмены»

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

«Введите S для сохранения, C для отмены или H для помощи»

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

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

По этой причине поставщики (Apple, Microsoft) часто публикуют руководства по стилю о том, как приложение должно взаимодействовать с пользователем на их платформе. Например, у Microsoft есть Руководство по взаимодействию с пользователем , которое:

«Цели этих официальных Руководств по взаимодействию с пользователем (или сокращенно« Руководство по UX ») для Windows:

Создание базовых показателей высокого качества и согласованности для всех приложений на базе Windows. Ответьте на ваши конкретные вопросы об опыте пользователей. Сделай свою работу проще! "

Answer 3

• Не указывайте очевидное
• Но не думайте, что то, что очевидно для вас, очевидно для пользователя.
• Ссылка на разделы справки, объясняющие, что означают термины, используемые в вашем сообщении
• Эмулируйте Mac: у многих подсказок есть "А?" ссылка, которая ведет к дальнейшей помощи.

Answer 4

Если это приглашение, я бы использовал стиль вопросов и ответов:

Сохранить изменения в этом проекте?

[Да] [Нет]

Answer 5

Держите это коротким!

Пользователи не будут читать абзац, объясняющий все входы и выходы какой кнопки нажимать. Вы получите максимум 2 предложения, которые прочитает пользователь. Сколько людей на самом деле читают этот второй абзац?

Answer 6

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

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

Answer 7

Опишите варианты с точки зрения действий пользователя. Будь кратким. «Пропустить ненужные слова». В идеале, кнопки будут описывать действия, и вам не нужен текст, чтобы замедлить пользователя. Предположим, что пользователь ненавидит читать что-либо на экране; даже если пользователь очень грамотный и использует ваше приложение для написания бессмертной прозы, его интересует то, что он написал, а не подробный текст о том, что делает система.

Answer 8

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

Например, если пользователь видит страницу 404, вам не нужно писать для него целую статью, НО вы должны указать «Почему я вижу эту страницу?»

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