Які помилки роблять ваші користувачі та як ви можете оновити свою програму, щоб обробити їх? [зачинено]

Насправді це питання стосується застережень для покращення якості користувальницької роботи та зменшення дзвінків підтримки, які можна уникнути.

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

Я бачив застарілі програми, де користувачі пройшли навчання:

• не вводити апострофи в імена
• не вводити будь-який символ, крім a-z0-9,
• переконайтесь, що немає тексту перед або після тексту, який вони ввели
• переконайтеся, що в emailполе вводиться правильно відформатована електронна адреса , інакше подальша розсилка цьому користувачеві використовуватиме все, що є в полі, і не вдасться
• переконайтеся, що " http://" ставиться перед веб-адресами

тощо

Усі вищезазначені питання є тими, якими повинен займатися розробник програми. Якщо перевірка вашої інформації по суті є "переконайтеся, що користувач знає, у якому форматі має бути це поле, і довіряйте правильності того, що вони ввели", то несподівані речі обов'язково знайдуть свій шлях до програми. Крім очевидних наслідків для безпеки, користувачі роблять помилки. Як програмісти, ми часто виробляємо наші найкращі продукти, нахиляючись назад, щоб переконатися, що користувач не може помилитися, як би вони не намагалися!

Одного разу мені зателефонували в службу підтримки, тому що мій додаток просто зник. Виявилося, вони відкрили ще одну програму.

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

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

Отже, я можу говорити лише за те, що знаю. Ось деякі поширені проблеми з програмами командного рядка:

Шлях занадто багато варіантів

Якщо ви не пишете компілятор чи редактор рядків, намагайтеся, щоб під час передачі --helpабо /?передачі було обмежено параметри, обмежені одним екраном у буфері фрейму 80х25 . Цілком прекрасно мати більше варіантів, ніж це, але розбити їх на підкатегорії. Наприклад

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, коли це можливо. Ви будете вражені тим, що ви можете зняти за допомогою простого словника клавіш значення.

Немає файлів конфігурації

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

Ніяких знаків "мокрої підлоги"

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

Коли це можливо (це збігається з перевіркою вхідних даних), використовуйте підписку Google:

Ви мали на увазі foo --bar FILENME, ви ввели лише foo --bar

Запропонуйте вихід із руйнівних інструкцій

Мета полягає в тому, щоб повідомити користувачеві, чому це не працює, і спробувати його спробувати ще кілька разів, гарантуючи при цьому, що ви нічого не робите потенційно руйнівно, якщо не виявиться, що користувач дійсно хоче, щоб ви це зробили. Дозволити перемикач , який вимикає «ниття», наприклад , -Yабо , /Yале в іншому випадку дозволити вихід для кого - то , хто просто має «товсті пальці».

Я, мабуть, забуваю кілька покажчиків. Я маю справу з цим часто, тому що дуже-дуже важко зробити інтерфейс "низького рівня" для чогось досить інтуїтивного, щоб більшість людей уникали помилок.

"Ви впевнені, що хочете видалити цей файл / запис? Так / Ні". Клацнув так, а потім подзвонив, що він "помилково" натиснув червону кнопку видалення, і їй потрібні ці дані назад :)

Я не вважаю, що отримання конкретних прикладів перерви / виправлення не так важливо, як усвідомлення цього:

• Користувачі не читають вашої інструкції чи не переглядають ваші підручники. Вони вивчають ваше програмне забезпечення шляхом дослідження.

Якщо через це дослідження вони щось зламають, то як програміст ваша робота або попередити їх про небезпеку, або не допустити, щоб це відбулося в першу чергу. Я не можу пригадати, де я це бачив зараз, але в думках я завжди намагаюся " полегшити робити правильну справу " для користувача мого програмного забезпечення.

Якщо ви наполягаєте на прикладах:

• Користувачеві вдалося ввести мале ім'я, яке порушило код інтеграції / виправлено, виконавши перевірку вводу
• Користувач зміг натиснути неправильну кнопку після виконання дії / виправлення, показавши лише правильні кнопки.
• Користувач зміг зробити X випадково / виправлено, попередивши їх, що вони збираються зробити X.

Бачите, куди це йде? :)

Ось я почув цього тижня. Користувач просить функцію "надіслати мені сповіщення, коли відбувається подія". Досить просто, розробник йде вперед і реалізує це. Звичайно, першим питанням повинно було бути "на що намагаються вирішити це повідомлення?". Я не буду в цьому займатись. Через кілька днів користувач зупиняється розробником і запитує "Я отримав це повідомлення. Що мені робити з цим?".

Я згадав цей комікс Ділберта і запропонував розробнику "написати додаток, щоб зрозуміти, що повинен робити користувач із цим повідомленням".

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

Я не думаю, що користувачі дурні. Вони взагалі не хочуть використовувати вашу або будь-яку програму. Все, що вони хочуть, - це зробити свої речі. Допоможіть їм і не дайте шкоди їм траплятися по дорозі.

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

• Хороший користувальницький інтерфейс повинен бути без тертя.

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

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

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

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

  Ніхто не читає посібник. Єдиним посібником, який я коли-небудь змусив своїх користувачів прочитати, була презентація PowerPoint, що містить покрокові інструкції програмного забезпечення. Я бачив, що це робиться з такими інструментами для відео, як Camtasia, але PowerPoints краще, тому що ви можете легко перевертати назад і вперед по кроках.

Користувач не помиляється. Помилки полягають у програмісті, який не зміг створити корисний інтерфейс.

Тож робіть тести на зручність з кожним випуском!