Bulgarian Experience

На 7 октомври 2010 направих една презентация на тренинга на Лукрат “Съдържание за уеб”. Говорих и показвах примери за това как се прави съдържание за уеб по-ползваемо. Т.е. как хората да го възприемат възможно най-лесно и бързо.

Моята презентация

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

Освен мен, презентации имаха и Владимир Петков (Каладан), Огнян Младенов и Борил Караиванов.

Другите презентации

Основната идея на Владо беше да накара хората да се съобразяват с конктекста, в който създават съдържание.

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

Огнян Младенов говори за SEO. Той вече публикува презентацията си. От слайдовете доста добре може да се придобие усещане за какво говори (рядко съм виждал слайдове с толкова много текст :)).

Борил пък направи нещо като въведение в типографията за начинаещи.

И така.

Не казахме най-важното

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

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

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

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

Има и инструменти, с които да тестваш варианти на едно съдържание, за да видиш кой вариант се представя по-добре.

Супер важно е да следиш какво се случва и да се опитваш да оптимизираш непрекъснато. Иначе просто умираш.

Web forms design guidelines: an eyetracking study | cxpartners

Prototyping with Production Purposes in Mind | Viget Advance

Най-хубавото в SEO е, че е магическият начин да убедиш клиента в някое по-ползваемо решение. Ако кажеш:  “Да направим това и това, за да подобрим ползваемостта,” срещаш див отпор. Ако смениш “ползваемост” със “SEO” получаваш мигновенно съгласие. How come that?

Game Mechanics for Interaction Design: An Interview with Amy Jo Kim – Bokardo

Wireframing Visual Priority with Tone › Wireframes Magazine

5 Design Decision Styles. What’s Yours?

Writing Decisions: Saving space without losing meaning – (37signals)

Моя статия от брой 183 на българското списание .net.

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

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

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

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

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

Когато става въпрос за промяна на някакви данни е правилно да се използват бутони. Пример за това е функционалността „Добави в пазарската кошница”, която увеличава броя на артикулите, които потребителят си е поръчал от даден онлайн магазин. Когато обаче става за навигиране е напълно погрешно да се използват бутони – линковете са най-естественият начин да обозначиш възможността за преминаване към нова страница.

Разбира се има и изключения от тези правила. Така например, когато имаме процес, в който се минава през няколко екрана (или страници) няма нужда да използваме линкове, а вместо това в интерфейса да имаме бутони „Напред” или „Нататък”. Или пък обратното: когато става въпрос за команди, които са оформени като линкове – „Назад” или „Отмяна”. Такива командни линкове са много популярни в уеб2.0 приложенията и намериха приложение дори в Windows Vista.

И това не е случайно. Изследванията за ползваемост показват, че в една уеб форма могат успешно да се комбинират и двата подхода – използване на бутони за основното действие (напр. „Изпращане”) и командни линкове за второстепенното (напр. „Отмяна”). Това помага на потребителите да се ориентират по-бързо и чисто визуално по-лесно да открият елемента, чрез който да реализират най-важното за тях действие.

А точно това е основната задача на дизайнера. Затова изборът дали даден елемент да бъде линк или бутон трябва да бъде воден от това, колко внимание искаме да насочим към него и каква функционалност искаме да комуникираме чрез него.

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

Wireframes Magazine