Гадно ли е да не предоставяте изящни грешки на потребител, който не използва уебсайта правилно?

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

Тъй като не е много ясно, ето един пример.

Да кажем, че посетител може да коментира нещо.

  • Коментарът се записва в база данни в колона nvarchar(500).
  • Дължината на полето <input /> е ограничена до 500.

Но, разбира се, нищо не забранява на по-напреднал потребител да деактивира ограничението за дължина и да въведе 501 символа.

(Други примери: подаване на опция, която дори не съществува в <select />. Но има има изящна грешка, когато потребителят бъде помолен да въведе число, а тя въведе вместо това не е число, тъй като събитията на натискане на клавиши се контролират чрез JavaScript и JavaScript може да бъде деактивиран)

Ако посетителят го направи, ще има провал на ниво кодови договори. Заявката AJAX ще се провали с неочаквана грешка (или при изпращане на страницата ще има неочаквана грешка). Във всички случаи посетителят ще види, че се е случило нещо нередно, но няма да има изящно съобщение, указващо, че дължината на изпратения коментар е твърде дълга.

Защо е лоша практика? Защо да си правя труда да проектирам ясни и изрични съобщения за грешка за случаите, когато посетителят, който използва правилно уебсайта, никога няма да има?

Забележка: Разбирам, че е гадно да се показва подробна грешка на .NET Framework и проследяване на стека, когато се случи нещо подобно. Ако го направя, това е сериозен проблем със сигурността. Но в моя случай има само AJAX отговор с нещо много общо или пренасочване към обща страница с извинения за грешка.


user-interface asp.net usability
person Arseni Mourzenko    schedule 14.01.2011    source източник
comment
Ти се шегуваш, нали? Звучи сякаш просто не искате да вършите работата. Потребителят не трябва да вижда куп грешки в кода. Трябва да разполагате с подходяща проверка за грешки, която не трябва да позволява на потребителите да правят неща, които очевидно не трябва. Трябва да проверите това във фронтенда (JavaScript) и бекенда. Ако потребител заобиколи проверките на javascript по някакъв начин, вашата система трябва да го улови, преди да се опита да го изпрати в DB.   -  person xil3    schedule 14.01.2011
comment
@xil3 - Ти изобщо прочете ли въпроса? В него се посочва, че е защитен на FrontEnd с помощта на maxlength и на backend с помощта на кодови договори. Той пита дали трябва да покаже форматирано (и потенциално преведено) съобщение за грешка за сценарий, който може да бъде причинен само от злонамерен потребител.   -  person Richard Szalay    schedule 14.01.2011
comment
@MainMa - Мисля, че трябва да перифразирате въпроса си, тъй като всеки отговор тук е пропуснал смисъла.   -  person Richard Szalay    schedule 14.01.2011
comment

Използвам DropDownListFor според моя изглед:

<%: Html.DropDownListFor(model => model.Type, 
                        new SelectList(ComponentsFactory.GetTypeList().Select(a => new { Name = Regex.Replace(a, @"^.*\.", ""), Value = a }).OrderBy(a => a.Name),
                            "Value", "Name", Model.Type), "Select . . .", null) %>

Имам и функция JQuery във файл със скриптове .js, който вече е включен в заглавката ми и всичко:

function GetRequiredFields(type) 
{
...//do JQuery AJAX stuff
}

Искам да извикам „GetRequiredFields“ с параметър „type“ като стойност на избрания елемент при избор и да го използвам за актуализиране на „div“, наречен „RequiredFields“. Как мога да направя това? Трябва ли да използвам нещо различно от Html.DropDownListFor?

  -  person xil3    schedule 14.01.2011
comment
@xil3 - Тук не грешиш.   -  person Richard Szalay    schedule 14.01.2011
comment
Току-що го препрочетох отново и въз основа на това, което той написа, няма индикация, че той прави някакво бек-енд валидиране. If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). - не трябва да е „неочаквана“ грешка, ако е валидирана в задната част. Ако е изпратено чрез AJAX с 501, задната част трябва да го обработва правилно, а не просто да се провали.   -  person xil3    schedule 14.01.2011
comment
@xil3 - Договорите за код ще хвърлят изключение, ако валидирането е неуспешно. Върнатата грешка не съдържа информация за изключение (той споменава това в бележката в долната част). Той пита дали грешката се нуждае от персонализирано съобщение за грешка.   -  person Richard Szalay    schedule 14.01.2011
comment
Гадно ли е? какво е това, Диг?   -  person adolf garlic    schedule 14.01.2011
comment
Като настрана: според моя опит като потребител предпочитам, когато текстово поле не ограничава това, което въвеждам, а вместо това проверява полетата, когато натисна изпращане (прекъсвам и маркирам лошите полета, ако нещо не е наред).   -  person Dunes    schedule 14.01.2011

Отговори (6)


arrow_upward
8
arrow_downward

Тъй като изглежда всички пропускат истинския ви въпрос, ще поставя моето 2c (въпреки че без съмнение ще бъда отхвърлен като отмъщение)

Докато вашите въведени данни са валидирани от страна на сървъра (вашата максимална дължина от страна на клиента вероятно е ок, въпреки че някои неясни браузъри може да не го поддържат), можете да върнете общо съобщение за грешка, стига то да не съдържа информация за изключение (което сте посочили не).

Ако обаче е възможно валидирането да се провали поради липса на javascript или неправилно въвеждане, тогава трябва да се предостави персонализирано съобщение за грешка в името на разума на потребителя.

Накратко, това, което правите, е добре.

person Richard Szalay    schedule 14.01.2011

arrow_upward
4
arrow_downward

Първо най-важното

Трябва да потвърдите всичко, което потребителят предоставя на сървъра! Това означава да не пропускате 501 букви

Освен това, ако възникне необработено изключение, трябва да покажете на потребителя съобщение, което не издава нищо. Ако трябва да върнете информация за изключение, това е златен прах за нападател.

Най-добрият метод е да покажете обща грешка като „Съжаляваме, работим по проблема веднага“ и да изпратите по имейл информацията за изключението на разработчиците, за да могат да я поправят.

person m.edmondson    schedule 14.01.2011
comment
Въпросът уточнява, че дългият запис ще бъде уловен. Той пита дали трябва да се покаже удобно за потребителя съобщение за ситуация, в която потребителят очевидно се забърква със системата. - person Richard Szalay; 14.01.2011
comment
Ако потребител знае как да се забърква с вашето приложение, вие със сигурност не трябва да му помагате, следователно трябва да показвате само общо съобщение - person m.edmondson; 14.01.2011
comment
Какво имаш предвид под валидиране? Ако използвам кодови договори, за да огранича дължината до 500 знака, това означава, че потребителят едва ли ще може да отиде по-далеч от бизнес слоя, когато изпраща 501 писма. Дори и да го направи, колоната на базата данни е ограничена до 500 знака (дори и да не харесвам идеята да изпратя към базата данни заявка, която ще се провали със сигурност). - person Arseni Mourzenko; 14.01.2011
comment
Във вашата ситуация кодовите договори ви защитават - но трябва също да търсите да използвате контроли като контролите за валидиране на ASP.NET. Това гарантира, че невалидните данни ще бъдат спрени при първа възможност. - person m.edmondson; 14.01.2011
comment
@MainMa трябва да имате преден и бек-енд валидиране, а не само преден край. - person xil3; 14.01.2011
comment
-1 Въпреки че нищо от казаното от вас не е невярно, вие сте пропуснали цялата същност на въпроса. Въпросът гласи, че той не връща информация за изключение и че валидирането е защитено от страна на сървъра. - person Richard Szalay; 14.01.2011

arrow_upward
2
arrow_downward

Защо да си правя труда да проектирам ясни и изрични съобщения за грешка за случаите, когато посетителят, който използва правилно уебсайта, никога няма да има?

Ако всички използваха мрежата правилно, никога нямаше да имаме нужда от валидиране.

Както веднъж каза Роналд Рейгън: „Доверявай се, но проверявай“.

Поставете проверка от страна на сървъра за дължината на полетата. Поставете проверка, за да се уверите, че няма XSS или SQL Injection атаки. Трябва да се тревожите не за хората, които използват вашия сайт правилно, а за тези, които го използват злонамерено.

person George Stocker    schedule 14.01.2011
comment
-1 ОП заяви, че използва кодови договори. Той пита дали трябва да се върне конкретен код за грешка или ако обща повреда (без информация за изключение) е наред. - person Richard Szalay; 14.01.2011

arrow_upward
2
arrow_downward

Мисля, че най-голямата част от проблема е, че приемате, че валидирането трябва да се извършва само в потребителския интерфейс. Наистина е най-добре да потвърдите в потребителския интерфейс и в бекенда. Няма нужда да връщате проследяване на стека или подробна информация за изключение. На Page_Load() винаги трябва да проверявате отново всички въведени от потребителя данни и да показвате информацията статично, сякаш потребителят е деактивирал JavaScript.

person Joseph Ferris    schedule 14.01.2011
comment
Знам, че въпросът не е 100% ясен, но той очевидно не прави такова предположение. - person Richard Szalay; 14.01.2011
comment
Всички разбираме, че сме пропуснали смисъла на въпроса, но намирам за малко грубо, че трябваше да отделите време, за да посочите това във всеки друг отговор, различен от вашия собствен, и дори да кажете, че сте гласували против другите. Нека отговорът ви остане сам по себе си. Независимо дали сте единственият, който го е получил, все още има много ценна информация в тези публикации. - person Joseph Ferris; 14.01.2011
comment
Липсата на разбиране на въпроса е единствената причина, поради която добавих отговор и, честно казано, намерих за грубо, че почти всички отговори грешно прочетоха въпроса и след това намекнаха, че ОП е някак си мързелив или по друг начин некомпетентен . Добавих -1 коментара, защото не ми харесва, когато хората анонимно гласуват против. Несвързана бележка, ако добавите към коментара си префикс @Richard (само първите 3 знака имат значение), ще бъда автоматично уведомен. - person Richard Szalay; 15.01.2011

arrow_upward
2
arrow_downward

Това, което описвате, не е просто лоша практика, а лош дизайн. Ако можете да предвидите грешка или изключение, тогава трябва да предвидите методи за справяне, смекчаване или облекчаване. Това важи за всеки дизайн на интерфейс, независимо дали е за уебсайт или хладилник. Ако посетител получи обща грешка и не му бъде дадена представа как да я поправи, тогава защо този човек трябва да си прави труда да използва вашия уебсайт? Ако са принудени (може би поради служебни причини), тогава всичко, което сте направили, е да отчуждите клиента си и да си създадете лошо име.

Предлагам ви да се запитате защо не се справяте с тези много лесни за контрол ситуации. Мързел ли е или просто ви липсва опит като потребител?

person Joel Etherton    schedule 14.01.2011
comment
Това, което описвате, не е това, което той описва. - person Richard Szalay; 14.01.2011

arrow_upward
0
arrow_downward

Валидирането от страна на сървъра е за две основни цели:

  • като грациозна деградация, ако валидирането на клиента не работи по някаква причина

    • in this case, you want a nice user-friendly message

  • като мярка за сигурност, за да се гарантира, че злонамерени клиенти не могат да повредят вашата система.

    • in this case, you want no internal details displayed

Ако искате да поемете по пътя на истинската грациозна деградация, би било ХУБАВО, ако сървърът все пак връща на потребителя приятелско съобщение за всяко валидиране.

В случай на maxLength това е малко вероятно да е необходимо. Но много видове валидиране използват Javascript и все още има хора или платформи, които не поддържат Javascript. По-старите мобилни платформи биха били основните заподозрени тук.

В наши дни обаче повечето от нас приемат, че на Javascript може да се разчита, така че общо съобщение за грешка, ако валидирането на сървъра е неуспешно, е добре.

person O'Rooney    schedule 31.10.2011