Поводът отново да се върна на него е един пост на Joel Spolsky, в който той категорично отстоява позицията, че менютата трябва да бъдат разрешени и при избор от страна на потребителя, трябва да се изведе съобщение, обясняващо защо тази операция не можа да бъде извършена в този момент.

Аргументът на Джоел е прост – като види едно забранено меню, потребителят има да се чуди защо е така и няма да може да си върши работата добре. Това е напълно валиден аргумент, що се отнася до хора, които още не познават системата добре и имат нужда от помощ. Но от друга страна, опитният потребител би се почувствал досадно ако избере меню или бутон и му се каже: “Сори, но това в момента не работи.”

Определено дилемата тук е между опитния и неопитния потребител. Неопитният има нужда да вижда всичко и да може да цъка навсякъде. Дори и да не може да свърши определена задача, съобщението, което ще получи, ще му даде ценен урок защо това не може да стане в дадения момент. Програмата за него е не само средство да си свърши работата, но и средство да я научи по-добре.

От друга страна, опитния потребител предпочита всички ненужни неща да изчезнат от погледа му, за не го разсейват. Избирането на бутон, който не работи и четенето на обяснителното съобщение за него е губене на ценно време. Един забранен (disabled) бутон е достатъчно красноречив начин да разбере, че тази функция не работи и за него не е трудно (понеже е опитен) да се сети защо.

Следователно големият въпрос е: как да направим нашия софтуер така, че с него да могат да работят и опитни, и неопитни потребители? Отговорът, разбира се, никак не е прост. Един от механизмите, които смятам, че са полезни в това отношение, е използването на системни параметри за настройването на тези опции.

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

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

Компромисът е приемлив може би в поръчкови системи или такива, които се ползват от отнсително малко на брой потребители, които могат да бъдат специално обучени и за тях да се спести разработката на мехнизма на информиращите съобщения и всички неизползваеми функции просто да бъдат забранени.

Бих искал да знам и вашето мнение и затова съм отворил нова анкета, в която въпросът е: да забраняваме или да не забраняваме? Споделете вашите предпочитания, гласувайки.

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

Гласувайте за тази статия в Svejo.net:

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.

Вижте и тези публикации:

• Проучване на в. InfoWeek за пазара на труда в ИТ сферата
• Добрите практики на софтуерното производство – анкета
• Кой решава дали да стартира един проект?
• World Usability Day
• Хиляда лева за мотивация. Резултати от анкетата