Връзка: disambiguity – В» pair design pays dividends

pair design. Добра идея. Накратко – една от основните agile практики е програмирането по двойки (pair programming), което само по себе си води до има редица преимущества. Според автора на статията, дизайнът на едно уеб приложение също може да се прави от двойка дизайнери. Мисля, че наистина има логика и смисъл – особено, когато например единият дизайнер е по-добър във визуалната част на нещата, а другият – в интерктивността и двамата взаимно се допълват. Нещо като лява и дясна половина на мозъка.

Връзка: Functioning Form – Interaction Design Books

Люк Вроблевски е направил списък с книги свързани с Interaction Design. От различни отзиви из блогове, списания и амазон съдя, че наистина списът е наистина адекватен. Имам някои от заглавията, а останалите задължително рано или късно ще поръчам. Най-много ме е яд, че никой не превежда подобни неща на български. Дори не се внасят подобни книги в България.

Колко често трябва да се прави редизайн на един сайт?

30 минути.

Тридесет.

Ето какво споделя Том Коутис относно уоркшопа, който хората от Flickr направиха миналия месец в Лондон. Най-забележителната част превеждам:

[…]Цялата работа се върти около непрестанната, продължаваща винаги разработка и подобрение и реагиране, което най-вероятно изяснява друг зашеметителен момент от сесията – когато Кал призна, че в “добрите дни”, Flickr пуска нова версия на всеки половин час. За да е възможен този начин на работа, те са създали структура, която ‘подпомага (много) бързите итераци, но налага поне малко повече строгост’.

[…]

Cal Henderson on “How We Built Flickr”… (plasticbag.org)

 

Удивително наистина. След като в обичайната практика ставаме свидетели на нова версия едва след седмица (супер рядко), след месец-два (доста рядко) или след половин или една година (по-често).

И една забележка от коментарите към същия пост на Том:

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

 

Гъвкава ползваемост

Като продължение на размислите от миналия пост идва и случайното ми натъкване на една потребителска група в Yahoo! – Agile Usability.

(Вместо въведение, за да сме на една страница всички – превод от Manifesto for Agile Software Development:)

Оценяваме:Личностите и взаимоотношенията повече от процесите и инструментите

Работещият софтуер повече от изчерпателната документация

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

Готовността за отклик при промяна повече от следването на плана

И сега – на какво се натъкнах в споменатата потребителска група.

Имаше съобщение на тема „Some Agile and HCI articles”.

Ще си позволя да цитирам една от статиите, която обясняваше как могат да се съвместят методологиите на пъргавото програмиране и ползваемостта (Are Agile and Usability Methodologies Compatible, Alain Desilets):

По-долу е изложено личното ни виждане за това как един практикуващ потребителски-центирарано проектиране (user-centered design) професионалист може да помогне в работата по гъвкав (agile) проект.- Професионалистът, практикуващ потребителски-ориентиран дизайн, използва малко време в началото на проекта (примерно, 2 седмици при 6-месечен проект), събирайки информация от потребителите и други заинтересовани страни чрез интервюта, хартиени прототипи и др.

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

– После прави груба скица на потребителския интерфейс като цяло (работа за два дни). Целта на тази скица е да даде на екипа разработчици нещо, към което да се стремят. Това не е солиден план и финалната имплементация най-вероятно ще се различава значително от него.

– След това става активен участник във фазата на разработка на системата. Неговата роля е да е част от екипа на клиента и да използва своето разбиране на клиентските и потребителските нужди, за да води разработката към ползваем и полезен софтуер.

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

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

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

 

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

Launch Small

В един от последните проекти, по който работя, екипът ни се сблъска с проблема на непрекъснатите искания за промени от страна на клиента.

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

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

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

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

В този момент нещата започнаха да се объркват.

Не успяхме да стигнем до единодушие кога трябва да престанем да внасяме промени в прототипа. Появиха се нови изисквания към системата. Едновременно се правеха промени от различен мащаб – от запетайки в текстовете до основополагащи принципи на бизнес логиката. Престанах да броя итерациите след 8 или 9 версия на прототипа.

Т.е. не успяхме да приключим етапа на спецификация.

Започнахме разработка преди да имаме знание за това какво точно трябва да представлява сайтът в крайна сметка. Започнахме да тестваме преди да сме приключили с разработката. В крайна сметка се принудихме да пуснем сайта преди да сме разработили и тествали поне нещо в завършен вид.

Което е най-малко желания начин за старт на нов продукт ever – има го, изглежда готово, но не работи.

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

Как можехме да се спасим от това положение?

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

За да използвам метафората с балоните – вместо да имаме един огромен и надут до пръсване балон (който в нашия случай се пръсна), трябваше да имаме няколко малки, умерено надути балони, всеки от които е проверен за слаби места и е 100% сигурно, че няма да се поддаде. Пък и някой балон от групата да гръмне винаги можеш да разчиташ на останалите.

Пускайте малки, но работещи продукти вместо големи и неработещи.

“Слез на земята, започни с потребителския интерфейс”

В един от последните проекти имах възможността и задължението да изпробвам на практика една от най-дискутираните напоследък техники.

Get real, start with the UI е предложение на Джейсън Фрайд, в основата на което стои идеята да се пренебрегва писането на детайлни функционални спецификации и да се преминава направо към създаване на живия HTML интерфейс.

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

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

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

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

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

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

Държавната администрация в интернет – лошо, Седларов, лошо!

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

Всъщност един екран, който казва доста:

Странното е потребителското име, което ми беше определено. YFFONKOTDI5WPS0GMW8Z !? Благодаря. Ей сега ще го запомня.

И за да ви спестя малко време – след това няма начин да промениш това име.

Никога не правете така!

Моите златни CSS правила

  1. Един CSS за еднаквите елементи във всяка страница на сайта. Отделни CSS файлове за специфичните страници.

    От известно време насам, вместо да пиша един огромен CSS, започнах да го дробя на парчета, което не само улеснява редактирането му, но и оптимизира значително скоростта на зареждане на отделните страници. Също, вместо да си губя времето с разни хакове за IE5, по примера на Microsoft, правя отделен CSS за него, където донаписвам съответните безумни поправки.
    Евгени Динев

  2. Нулиране на margin и padding
    Global White Space Reset
  3. Указване на правилен DOCTYPE

    Правилният DOCTYPE (Джефри Зелдман)

    Декларацията за Вида на Документа или DOCTYPE казва на браузъра по какъв начин да покаже вашата страница. Когато този DOCTYPE e неверен или просто липсва, браузърът не показва страницата по начина, по който бихте искали. Ето един полезен списък с правилните DOCTYPEs, съставен от Джефри Зелдман.

  4. Валидирай – един незатворен таг ти разказва играта

    Когато се съмнявате, валидирайте Когато дебъгвате (дебъгване – процес по откриване на грешки в програмен код), можете да си спестите много главоболия като от начало просто валидирате своя код. Неправилно форматираният XHTML /CSS е причина за много проблеми с лейаута.
    Дейв Шеа

    W3C Validator

  5. За да няма проблеми с box model в IE – margin вместо padding

    Опитвайте се да избягвате задаването на padding/border и едновременно с това фиксиран размер на елемента. IE5 разбира box model (блоковия модел) по погрешен начин, което наистина обърква нещата. Има начини за справяне с проблема , но винаги е по-добре проблемът да бъде заобиколен като padding.ът се прилага на родителски елемент вместо на наследяващ елемент, който е с фиксиран размер.
    Дейв Шеа

    Казано иначе, никога не указвайте padding или border за елемент с фиксирана широчина. Можете да укажете margin на елемента, което ще го отдалечи от рамката на родителския му елемент и същевременно няма да проимени фиксирания размер.

  6. Използвайте възможно най-малко несемантичен код – излишните div и span не носят особен смисъл и замърсяват кода. Използвайте малко-познатите тагове на HTML като fieldset, legend, cite, label и т.н..
  7. Комбиниране на селектори – когато задавате стил за даден елемент на страницата използвайте HTML структурата на документа, за да го адресирате, вместо да задавате отделен клас.

    Комбинирайте селектори. За да оптимизирате времето за зареждане, трябва да се стремите към малки CSS файлове; опитвайте се колкото се може повече да групирате селектори, разчитайте на наследяването и намалявайте излишните повторения като използвате съкратен ( shorthand ) запис.
    Дейв Шеа

  8. Филтри за различните браузъри – само в краен случай, защото има достатъчно начини да напишем ист CSS, който няма нужда от хакове и не се разпада в различните браузъри.

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

  9. Смислени и уеднаквени имена на класове и ID

    Именувайте класовете / ID-тата според тяхната функция, а не според външния им вид. Ако създадете клас .smallblue и по-късно получите молба да промените размера на шрифта в по-голям или цвета – на червен, този клас престава да носи всякакъв смисъл. Вместо това използвайте описателни класове като .copyright и .pullquote.
    Дейв Шеа

По-добър или най-добър

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

Както аз разбирам нещата, една от основните цели на конкурса е да направи реклама на Интернет като медия, като място, като комуникационен канал, в който си заслужава да вложиш пари.

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

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

И не случайно изпълнителният директор на най-успешния сайт за електронна търговия до момента – Amazon.com, – Джеф Безос казва: „Рекламата „от уста на уста” добива все по-голяма сила. Ако предлагаш страхотна услуга, хората я откриват…” Безос предсказва, че във всички отрасли на икономиката парите отделяни за маркетинг и реклама ще намаляват, а в резултат на това сумите отделяни за разработка на по-добри продукти и услуги ще се увеличи. „Ако днес успешната рецепта е да изразходваш 70% от средствата си, крещейки наоколо за своята услуга и 30% – за създаването на по-добра услуга, през следващите 20 години това ще се промени.”

Ето защо намирам, че е далеч по-полезно за бизнеса парите вложени в конкурси за най-добър сайт да се вложат в създаване на по-добри сайтове.