Блог за UX и ползваемост » код за достъп http://www.lucrat.net/blog Трудно ли е да е лесно Fri, 03 Sep 2010 15:08:37 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Ех, тези грешки http://www.lucrat.net/blog/publications/message/ http://www.lucrat.net/blog/publications/message/#comments Wed, 27 Aug 2008 12:45:04 +0000 Alexo56 http://www.e-lesno.com/blog/message/ Скоро се натъкнах на следното съобщение за грешка, до сега си мислех, че подобни съобщения не могат да се срещнат никъде из мрежата, но уви. Хубавото е, че поне има пример.

Ненужно съобщение за грешка

Повече информация за кодове за достъп, виж статия Уеб форми и ползваемост.

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

error2.jpg

]]> http://www.lucrat.net/blog/publications/message/feed/ 0 Уеб форми и ползваемост http://www.lucrat.net/blog/publications/forms_and_usability/ http://www.lucrat.net/blog/publications/forms_and_usability/#comments Wed, 31 Jan 2007 15:00:24 +0000 Alexo56 http://www.e-lesno.com/blog/forms_and_usability/ Електронните формуляри са вече толкова популярни и масови, че се налага почти всеки ден да се регистрираме за какво ли не. В повечето случаи регистрациите са задължителни и досадни, никой не ги харесва, губят много време и са неудобни за ползване.

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

Наскоро попълвах уеб формуляр, който се оказа истинско предизвикателство. Направих пет опита и загубих около 15 минути докато успея да стигна до „Вашата регистрация премина успешно”.

Често срещани проблеми

Изборът на потребителско име бе най-досаден. При два от петте опита, името което избирах не беше свободно и вероятно щях да направя още 10-ина опита, ако не се спрях на име от типа „Alex123456” само и само системата да не ме върне отново. На третия опит „грешката” беше че съм въвел парола, която трябва да е минимум 8 знака и да съдържа и ГЛАВНИ букви.

След като попълних всичко за сетен път, в бързината натиснах бутон „изчисти”, вместо бутон „изпрати” поради простата причина, че са един до друг и страшно много си приличат. Чак след последния опит разбрах, че „година на раждане” е задължителна и няма как да не въведа и нея.

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

Хитри решения за ползваеми форми

Наскоро попаднах на друга регистрация, която попълних от първият път и ми отне по-малко от минутка. Хората които са работили над сайта бяха решили да не губят времето на потребителите си в безсмислени и многократни опити да станат техни клиенти…

Ето пример за електронен формуляр, който не губи време поради това, че не допуска потребителят да сгреши при въвеждане на нужната информация. Формулярът е интерактивен – пробвайте да го попълните.

[include file=/content/other/test.php]

Задължителни полета *

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

Употреба на етикети

Добавянето на етикети към елементите не е трудно и същевременно е доста полезно, защото правят някои елементи по-лесни за цъкане. В следващия пример са показани две възможности за избор. Обърнете внимание, че текста: “ИЗБОР1″ е цъкаем и активира чавката, за разлика от другия пример където цък върху: текста на “ИЗБОР2″ не върши никаква работа:

Пример 1 – етикети


ИЗБОР2:
 Избор 2:

 

HTML


Етикет


CSS

label {cursor: pointer;}

Употреба на алтернативен текст

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

Пример 2 – алтернативен текст

HTML

Бутон “Изчисти” (Reset)

Това е най-безсмисленият елемент в 95% от формите. В повечето случаи този бутон се ползва по грешка, при което се губи цялата информация. Ако някой иска да промени нещо, по-скоро би променил отделно поле отколкото целия формуляр. Понякога подобни бутони може да срещнем под различни имена „Отказ“, „Назад“, „Изчисти“ и др., по добре е да избегнем употребата им.

Умерена информация

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

Пример 3 – групиране на информацията

Проверка на данните (form validation)

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

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

Предпазване от грешки

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

Пример 4 – примери за въвеждане

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

Пример 5 – дефиниран избор

HTML

Обекти

или

Добре е да избягваме безмислени повторения за избор. Например: Изберете Град (София), Изберете Област (Софийска). Ако ни е нужна областта, лесно ще си я проверим.

Някои елементи от формуляра може да са повече от очевидни, че трябва да бъдат избрани от потребителите. Добре е предварително да ги нагласим по подразбиране (default). Такива елементи са от типа: „Съгласен съм с условията на сайта“ или по-подразбиране сме избрали държава – България.

Добре е да оразмерим полетата в които е необходимо да се въведат точно определен брой символи. Ако например питаме за година на раждане е по-добре да ограничим въвеждането до четири символа, отколкото полето да е с възможност за въвеждане на 20 символа. Ако е с повече символи потребителите биха предположили, че трябва да въведат и дата и месец – възможността за грешка е по-голяма. Полетата за въвеждане на текст (textarea) би трябвало да са с по-големи размери, което ги прави по-удобни за писане и редактиране.

Външен вид

Най-добре е да организираме формата чрез стилове – CSS, като дефинираме размера на шрифта да е в проценти, което ще позволи на потребителя да променя размера на текста директно от своя браузер. Също така, по-големите по размер полета са за предпочитане, защото въвеждането при тях е по-лесно (вж. пример на сайта на WordPress). Възможно е да структурираме формата и в таблица, но не е за предпочитане, защото би довело до проблеми с достъпността. Там където е належащо формата да се структурира в таблица е добре да се направи допълнителна оптимизация, за да се избегнат някои проблеми с достъпността. Повече за организирането на формите в таблици четете статия: Using Layout Tables for Forms. Едно интересно изследване (Label Placement in Forms от 12 юли 2006г), направено чрез система за следене на погледа (eyetracking или окослед) показва, че за имената на полетата е по-добре:

  • да ги поставим веднага над полетата, вместо от ляво;
  • ако все пак ги поставим от ляво, да ги равняваме на дясно към полетата, вместо на ляво;
  • да не ги удебеляваме (bold);

Подходящо оформяне на форми

Скрити елементи и неочаквани събития

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

Да, ползвам
Имате ли компютър

Да

Такива форми са рядкост, но все пак се срещат. Логиката е напълно объркана. На места не е ясно какво точно трябва да се попълни. Въпросите са отляво, а не над елементите, което затруднява отговора. Прекалено много елементи са скрити и дори бутонът „Запис“ е нелогичен като наименование. Надявам се все по-малко да ни се налага да попълваме подобни „умни“ формуляри.

Кодове в картинки

Наричат ги CAPTCHA (вж. повече информация в Уикипедия) и какво ли още не, но по същество са си кодове за достъп. Кодовете най-често се ползват за да се провери дали този, който попълва формуляра или влиза в своя профил е човек, а не машина. Код в картинкаПостепенно започват да се появяват навсякъде, и по-скоро дразнят отколкото да вършат добра работа. Вярно защитата е важна, но е лошо когато това оказва влияние върху взаимодействието със сайта. Понякога дори не може да различим символите, защото знаците са повече от изкривени, а други са с бледи цветове. Повече алтернативни решения четете на: Inaccessibility of CAPTCHA

Буквата (О) и цифрата (0)

Повечето сайтове с подобна защита използват всички символи при генерирането на кода. Но при това положение изниква един проблем между цифрата нула (0) и буквата (О), те си приличат толкова, че когато са разкривени не могат да се различат. Ето това би принудило стотици потребители да грешат многократно.

Брой символи

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

Прекалено дълги кодове

Попадал съм на места където кодът се състои от 10 символа – цифри, големи и малки букви. Дългите кодове трудно се въвеждат, отнемат повече време, възможни са повече грешки. Добре е да се редуцират до 4-5 символа, само малки букви.

Добри решения

Представяте ли си, че се налага всеки ден по три пъти да ползвате своя достъп за електронно банкиране и трябва да въвеждате по три пъти кода за достъп всеки път и ако грешите по два пъти на опит, сметката става голяма. Ето едно отлично решение на което се натъкнах на сайта на Банка ДСК. Разработчиците са се постарали да направят проверката за „човечност“ да се появява след третия грешен опит, а не още с влизането на сайта – това пести много време.

На сайта на Банка ДСК картинката за проверка се появява само след трети грешен опит

А ето друго полезно решение на сайта на Hotmail. Разработчиците са предоставили възможност кодът от картинката да бъде произнесен гласово, което позволява на незрящи хора също да ползват тяхната услуга. Позволили са на потребителя да „смени“ картинката с кода като използва бутон – обнови (refresh), което е много удобно ако кодът не е достатъчно четим.

На сайта на hotmail картинката за проверка се изговаря гласово

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

А пък този екземпляр тук сигурно отнема часове: Жалба пред европейския омбудсман.
Гледайте да не се объркате да натиснете бутон „Възстанови“ вместо „Изпрати“ :)

Външни препратки:

  1. Accessible Data Forms – The University of Wisconsin-Madison
  2. Accessible HTML/XHTML Forms – The Web Standards Project
  3. Accessible forms: Guidelines, examples and accessible JavaScript tricks – WebSemantics – Accessibility
  4. Creating Usable Forms – WebQuarter Design
  5. Creating Accessible Forms – WebAIM
  6. Forms, usability, and the W3C DOM – Digital Web
  7. How to Create User-Friendly Forms – About.com
  8. Simple Tricks for More Usable Forms – SitePoint
  9. Usability and HTML Forms – ECommerce-Guide
  10. Web Application Form Design – LukeW
]]> http://www.lucrat.net/blog/publications/forms_and_usability/feed/ 0