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