Ще отговоря на следните въпроси:

• Какво е Ъдаптив паат и кои са хората там?
• Каква работилница организират?
• Какво беше покрито по време на срещата?
• Какво беше добро, какво полезно и какво не беше хубаво?
• Кой присъства?
• Къде стоим ние спрямо показаното?

Какво е Ъдаптив паат и кои са хората там?

Организаторът на събитието е американска фирма — сдружение на няколко души, които се занимават с човеко-насочено проектиране на сайтове.

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

Ето и няколко думи за водещите:

Питър Мерхолц (Peter Merholtz).

Информационен архитект. Работил е като творчески директор на www.epinions.com. Проект, с който се гордее е www.peoplesoft.com и особено с индексирането на продуктите им.

Джефри Вийн (Jefrey Veen).

Журналист и проектант на интерфейси. Работил е в Wired Digital и Lycos Inc. като изпълнителен директор по интерфейсите. Негово дело е www.wired.com. Написал книгата Проектирането за мрежата — изкуство и наука (The Art and Science of Web Design).

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

Каква работилница организират?

Работилницата, в която участвах се нарича Отвъд ползваемостта (Beyond Usability). Както подсказва името и, целта е да се покажат подходи в проектирането, които обхващат не само следване на правила за ползваемост и тестване с потребители.

За Нийлсен и правилата

Хората си позволиха да се присмеят на Джейкъб Нийлсен и да го използват за отправна точка на собственото си представяне. Kазаха така: видите ли, Джейкъб твърди, че за да е ползваема началната страница на един сайт, тя трябва да отговаря на тия 10 правила (www.useit.com/alertbox/20020512.html). Ние обаче ви показваме един сайт (www.quixtar.com), който не отговаря на нито едно от тях и въпреки това прави по повече от един милиaрд долара годишно.

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

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

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

Собственият им модел е трифазов:

1. Проучване на концептуално ниво:

• Събиране на изисквания и предположения;
• Запознаване с конкуренцията и анализирането и;
• Проумяване на целите и задачите;
• Разработване на образи.

2. Проектиране:

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

3. Потвърждаване:

• Проверка с потребители за ползваемост.

Какво беше покрито по време на срещата?

Работилницата, както вече споменах, протече забавно и приятно. Успяхме да покрием целия предвиден материал, сиреч целия процес на проектиране от запознаване с проекта и събиране на изискванията до валидиране на прототипа чрез тестване с потребители. Имаше неща, които останаха недоизказани, а имаше и неща, които бяха претупани.

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

Какво беше добро, какво полезно и какво не беше хубаво?

Хубавите неща:

• Структурирано, последователно изложение на материала.
• Много примери от собствената им работа.
• Упражнения, чрез които всеки от участващите пробва да направи някои от нещата, за които се говори.
• Силен фокус върху нуждите на потребителите.
• Взаимодейственост — всички участват, питат, предлагат, поставят под съмнение.

Полезните неща:
Дизайн и потребителски цели Отлично илюстрираха връзката между дизайна и целите на потребителите, както и различните предизвикателства, които стоят пред дизайнерите:

• структуриране;
• поставяне на имена;
• изграждане на навигационна система;
• интуитивност;
• класифициране;
• глобализация — отразяване на културни различия;
• достъпност;
• жаргонизация;
• политизация;
• разширяемост;

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

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

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

Одит на съдържание
Интересен подход за класифициране на съдържанието на съществуващи сайтове и системи. Много често един сайт се развива в движение. Непрестанно се добавят нови неща и в един момент се оказва, че съдържанието става неуправляемо. Преди да се пренаправи сайтът, се прави одит на съдържанието, за да се класифицират типовете налични материали и да се структурират данните. Много полезни за това упражнение могат да бъдат контролирани речници като www.taxonomywarehouse.com или http://dublincore.org.

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

1. Изготвяне на първоначален списък с черти;
2. Зависимости и отношения между чертите;
3. Оценяване по две скали — изпълнимост и важност — от няколко души;
4. Графично изразяване на резултата в четири квадранта.

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

Нещата, които куцаха:

• Неравномерно покриване на материала.
• Едностранчив поглед върху прилагането на правила и насоки в практиката — вж. За Нийлсен и правилата по-горе.
• Говориха за процес на първоначално откриване, но не споменаха как се разбира, че вече сме открили достатъчно — кога трябва да се спре. Определянето на обхвата на проекта не беше обяснено добре.
• Претупаха проектиране на взаимодействието.
• Не споменаха как се избира обща рамка или разположение. Впечатлението, което оставиха е, че току в един момент човек започва да рисува и дизайнът се получава от самосебе си.
• Показаха примерен екип за разработване на сайт, но не предложиха метрични данни за разпределението на усилието в екипа — по-долу, текстът в скобите е мой за пояснение. Липсващо тук е срещу всяка роля да има число, което показва каква част от работата по проекта се върши от съответната роля. Другото, което липсва е ролята на тестера.

1. Продуцент (ръководител на проекта);
2. Редактор (очевидно отговаря за съдържанието);
3. Проектант (дизайнер);
4. Информационен архитект;
5. Производител (онзи, който вкарва съдържанието – HTML);
6. Инженер (онзи, който пише кода).

Кой присъства?

Участваха около 70 души. Предимно от Европа. Предимно от западна Европа. Основно от Англия, Холандия и Германия. Имаше около 20 души от БиБиСи. Имаше и случайности като мен от България и един младеж от далечен Хонг Конг.

Нямаше голямо разнообразие в занятията на хората, записали се за участие (поне на тези, с които говорих — нямаше как да си поговоря с всичките 70 души). Много от тях са със звания Информационен архитект, Графичен дизайнер, Интерфейсен дизайнер, Проектът на взаимодействие. Имаше и такива, които са уебмастъри, но малко. Програмисти не срещнах.

Къде стоим ние спрямо показаното?

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

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

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

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

Има и неща, които ние правим, но не бяха споменати или обсъдени.

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

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

Ще се радвам да чуя ваши мнения. Пишете ми на office@lucrat.net.