Какие ошибки делают ваши пользователи, и как вы можете обновить свое приложение, чтобы справиться с ними? [закрыто]

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

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

Я видел старые приложения, в которых пользователи были обучены:

• не вводить апострофы в именах
• не вводите никаких символов, кроме a-z0-9,
• убедитесь, что нет пробелов до или после введенного текста
• убедитесь, что в emailполе введен правильно отформатированный адрес электронной почты , в противном случае последующие почтовые рассылки этому пользователю будут использовать все, что находится в поле, и потерпят неудачу
• убедитесь, что " http://" ставится перед веб-адресами

и т. д.

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

Однажды мне позвонили в службу поддержки, потому что мое приложение просто исчезло. Оказалось, что они открыли другое приложение сверху этого.

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

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

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

Слишком много вариантов

Если вы не пишете компилятор или редактор строк, старайтесь ограничивать параметры одним экраном, заполненным в буфере кадра 80x25, когда --helpили /?передано. Прекрасно иметь больше вариантов, чем это, но разбить их на подкатегории. Например

foo --help

foo --help option_name

Нет длинных вариантов

Это гораздо легче запомнить, foo --attach_to [argument] --volatile --verboseчем запомнить foo -a [arg] -v +V. Это не всегда возможно, но в большинстве случаев так и есть.

Нет подтверждения ввода

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

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

Я действительно однажды получил сообщение об ошибке, где ожидалось целое число и кто-то печатал f*** my lifeв кавычках. Я не писал эту программу, я имел несчастье наследовать ее.

Нет кнопки «многословие»

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

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

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

В режиме отладки нет ошибки

Многие программы предлагают своего рода переключатель «отладки», который предлагает дополнительную болтовню относительно того, что происходит с программой, но очень немногие предлагают следующее:

• Способ автоматически отправлять отчет по HTTP / HTTPS и получать какой-то сервисный ссылочный номер
• Способ выгрузки полезной информации в файл, который можно отправить в виде вложения в запрос на поддержку

Или, возможно, вам нравится слышать, как люди читают по телефону следующее:

Это говорит о непредвиденном состоянии в ноль, о, о, о, о, о, о, о, о, о, о, нулю.

Слишком сложные конфигурационные файлы

Не оправдывайте необходимость разбора конфигурации как предлога, чтобы получить удовольствие от большого количества синтаксического сахара. Попробуйте использовать формат, который люди действительно знают, даже если это требует дополнительной работы при разборе. Я стараюсь использовать формат стиля INI, когда это возможно. Вы будете поражены тем, что вы можете сделать с помощью простого словаря key-> value.

Нет конфигурационных файлов

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

Никаких признаков «мокрый пол»

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

По возможности (это совпадает с проверкой ввода) используйте Google Apporach:

Вы имели в виду foo --bar FILENME, вы набрали только foo --bar

Предложите выход из разрушительных инструкций

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

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

Msgstr "Вы уверены, что хотите удалить этот файл / запись? Да / Нет". Нажал «да», а затем получил вызов, что он «по ошибке» нажал красную кнопку удаления, и ему нужны эти данные обратно :)

Я не чувствую, что получение конкретных примеров ошибок / исправлений так же важно, как реализация этого:

• Пользователи не читают ваше руководство и не смотрят ваши учебники. Они изучают ваше программное обеспечение через исследование.

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

Если вы настаиваете на примерах:

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

Видишь, куда это идет? :)

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

Я вспомнил этот комикс Дилберта и предложил разработчику «написать приложение, чтобы выяснить, что пользователь должен делать с этим уведомлением».

Как сказал mpeterson, пользователь очень конкурентоспособен в своей области знаний. Они просто не думают как разработчик программного обеспечения или дизайнер.

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

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

• Хорошие пользовательские интерфейсы должны быть без трения.

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

• Хорошие пользовательские интерфейсы должны быть обнаружимы.

  Несмотря на то, что лента в Microsoft Office становится слишком сложной, поскольку она заставляет старых пользователей Word менять свои способы, лента является ярким примером того, как можно сделать интерфейс доступным для обнаружения (то есть легко обнаруживаемым).

• Хорошие пользовательские интерфейсы, такие как хороший код, должны быть понятны.

  Никто не читает руководство. Единственное руководство, которое я когда-либо читал своим пользователям, было презентацией PowerPoint, содержащей пошаговые пошаговые руководства по программному обеспечению. Я видел, как это делается с помощью видеоинструментов, таких как Camtasia, но PowerPoints лучше, потому что вы можете легко перемещаться назад и вперед по шагам.

Пользователь не делает ошибок. Ошибки лежат с программистом, который не смог создать удобный интерфейс.

Сделайте юзабилити-тесты с каждым выпуском