Usability пример: забранени (disabled) менюта и бутони
Дали в потребителския интерфейс да забраним менютата и бутоните, които в момента не могат да бъдат използвани, т. е. функцията, която предлагат, не е приложима в конкретната ситуация? Това е един въпрос, който често сме обсъждали с колеги без да можем да стигнем до еднозначен отговор, удовлетворяващ всички.
Поводът отново да се върна на него е един пост на Joel Spolsky, в който той категорично отстоява позицията, че менютата трябва да бъдат разрешени и при избор от страна на потребителя, трябва да се изведе съобщение, обясняващо защо тази операция не можа да бъде извършена в този момент.
Аргументът на Джоел е прост – като види едно забранено меню, потребителят има да се чуди защо е така и няма да може да си върши работата добре. Това е напълно валиден аргумент, що се отнася до хора, които още не познават системата добре и имат нужда от помощ. Но от друга страна, опитният потребител би се почувствал досадно ако избере меню или бутон и му се каже: “Сори, но това в момента не работи.”
Определено дилемата тук е между опитния и неопитния потребител. Неопитният има нужда да вижда всичко и да може да цъка навсякъде. Дори и да не може да свърши определена задача, съобщението, което ще получи, ще му даде ценен урок защо това не може да стане в дадения момент. Програмата за него е не само средство да си свърши работата, но и средство да я научи по-добре.
От друга страна, опитния потребител предпочита всички ненужни неща да изчезнат от погледа му, за не го разсейват. Избирането на бутон, който не работи и четенето на обяснителното съобщение за него е губене на ценно време. Един забранен (disabled) бутон е достатъчно красноречив начин да разбере, че тази функция не работи и за него не е трудно (понеже е опитен) да се сети защо.
Следователно големият въпрос е: как да направим нашия софтуер така, че с него да могат да работят и опитни, и неопитни потребители? Отговорът, разбира се, никак не е прост. Един от механизмите, които смятам, че са полезни в това отношение, е използването на системни параметри за настройването на тези опции.
Например, можем да предположим, че всеки потребител в началото е неопитен (поне по отношение на самия продукт). Следователно, всички менюта и бутони трябва да бъдат разрешени и да издават обяснително съобщение, когато не могат да изпълнят функцията си. Но трябва да предвидим параметър, чрез който потребителят сам да избере да премахне тази възможност, когато придобие достътчно опит в работата си с продукта, и неработещите функции да бъдат забранени или скрити.
Това решение, на практика включва в себе си и единия, и другия подход, което го прави и по-скъпо за реализация. По-голямата цена, както и традиционният мързел, са основната причина, поради която дизайнерите на визуалния интерфейс правят компромиси с ползваемостта. Въпреки всичко, аз смятам, че ако се разработва продукт за много потребители, повечето труд и средства, инвестирани в подобряване на потребителския интерфейс, ще доведат и до по-широко пазарно възприемане на самия продукт, а оттук и до по-големи печалби.
Компромисът е приемлив може би в поръчкови системи или такива, които се ползват от отнсително малко на брой потребители, които могат да бъдат специално обучени и за тях да се спести разработката на мехнизма на информиращите съобщения и всички неизползваеми функции просто да бъдат забранени.
Бих искал да знам и вашето мнение и затова съм отворил нова анкета, в която въпросът е: да забраняваме или да не забраняваме? Споделете вашите предпочитания, гласувайки.
Естествено, осъзнавам, че качественият отговор не е толкова прост, така че очаквам вашите мнения и като коментари под този пост.
Гласувайте за тази статия в Svejo.net: [wp:svejo-net]
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Според мен решението с параметъра е доста тежко.
Мисля, че менютата трябва да са разрешени, като ги избереш да те информират защо не може да се извърши действието, но да се визуализират по различен начин – например да се виждат като забранени.
Другия вариант са хинтове върху забранените менюта, които да казват защо са забранени.
Според мен трябва да са разрешени. Дали е опитен или не, потребителят е любопитен. Цъка навсякъде, където има не кликай тук 😀
Вместо да види, че нещо му е забранено и да си мисли, че е с “орязани” права за достъп до приложението, най-добре си е с един алерт да му се казва, че това не фукционира в момента.
Всички са доволни … 🙂
В момента работя по един проект и имаме сходен казус.
В няколко полета се въвеждат стойности за продължителност и тип на продължителност на даден елемент. Посредством дроп-даун се избира поделемент и същите параметри за него са забранени, като те приемат глобалните стойности. Логиката на проекта е такава, че е възможно да имат може да се приемат и различни от глобално зададените стойности за продължилност и тип продължителност.
Върви обяснявай на девелопъри, че трябва да са разрешение и че всеки елемент трябва да може сам по себе си да получава различни стойности. Още повече, ако БА-то ти каже: остай ся, за какво да си създаваме главоболия 🙂
тъ мойто скромно мнение е, че трябва да са разрешени…на потребителят трябва да се дава максимална свобода, за да не се чувства ограничен 🙂
Аз предпочитам да са изключени. А напоследък слагам tooltip подсказка, която да илиза на mouseover, така хем неопитния потребител е информиран, хем опитния няма да бъде занимаван. А това с alert-ите ми се струва повече дразнещо от колкото полезно. Да не говорим за ситуацията която по погрешка натиснеш бутон които трябва да е не активен и ти излезе събощение което ти спира работата.
RStankov, ми че за къде бързаш 😀
Гледай къде натискаш 🙂
Решението и при нас е tooltip с обясняващ текст.
Друг момент е дали команди, които няма как да бъдат разрешени в рамките на текущата потребителска сесия (защото, да речем, потребителят е с орязани права) въобще да се показват в менютата. Предпочитаме да ги показваме изключени, защото ако потребителят някога е имал права за дадена операция и сега не я вижда в менюто се обърква повече и започва да се чуди дали недовижда, пък и по-лошо – почва да звъни на поддръжката 🙂 Затова нека е там командата, където си знае потребителят, че трябва да е, пък просто да е забранена.
Друг момент е, ако условието дали командата е забранена или разрешение изисква времеотнемаща сметка. В този случай да се покаже съобщение, когато потребителят се опита все пак да използва командата от менюто май е по-добре, отколкото менюто да се отваря със забавяне, заради изчислението.
Аз още преди да прочета поста до средата също си мислех за варианта със настройката на поведението на приложението. Това е гъвкав вариант а и ако се обмислят нещата добре не е толкова скъп за реализация. Но се сещам и за 3ти вариант: да се скрие опцията – примерно много от приложенията в пакета ms office в зависимост от това какво правим показват различни менюта с различни елементи в тях.
Освен това се сещам и за друг аспект, че някои неща се забраняват с цел authorization, като там пак я има същата дилема (трилема): скрит, enabled, disabled
решението, така като помисля…
по принцип потребителят като вижда неща, по които не може да кликне, че го ограничават и не се чувства добре.
Решението го каза и entwickler – най-добре според ролята, която има да вижда различни неща. Важното е всичко, което вижда да може да се цъка, иначе рискуваме да го вкараме в размисъл “а това, по дяволите, защо не работи?”
Примерно имаме меню с А, Б, С и Д.
Когато говорим за админ – тои вижда всички
Когато е модаратор вижда А, Б и С
обикновен потребител вижда само А и Б
Всичко което се вижда е активно и може да бъде избрано, вследствие на което да настъши някакво действие.
Не ограничавайте потребителите и не ги затормозявайте с излишни неща. Каквото му трябва, това да вижда 🙂
Аз бих формулирал следните правила:
1. Ако в дадената сесия, потребителя като роля няма права над дадени функции, те да бъдат невидими. Няма смисъл нещо, което въобще не е предназначено за него, да му се мярка пред очите.
2. Ако в даден момент не е възможно да се използва някоя функция, тя да бъде забранена. Смятам, че е добро решение да има tooltip, който да обяснява защо е забранена.
3. Ако проверката за това дали може или не може да се извърши дадена работа, е твърде бавна, по-добре е бутонът или менюто да останата разрешени, а самата проверка да се направи при натискането им, за да се спести губенето на време при зареждане на формата.
Май това обобщава повечето от мненията дотук, а?