Lazy Bastard’s Blog

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

Целият проект по редизайна на сайта на най-голямата българска банка - собственост на групата Уникредито (които от своя страна наскоро се сляха с HVB) - започна доколкото си спомням в края на 2003-та година и се проточи до края на 2004-та. Тогава напуснах преди�?ната си работа, за да отида в Нетейдж и откровено казано до тази вечер бях изгубил надежда, че проектът, в който бях вложил доста усилия ще види бял свят.

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

Така като гледам HTML & CSS са били омазани впоследствие и сега сайтът възражда ло�?ите спомени от така популярната до скоро таг чорба.

Графичният дизайн също е бил променен в сравнение с визията, която създадох навремето. Приятната част от работата тогава бе�?е, че самата банка използва�?е корпоративна идентичност на Уникредито и съответно правилата бяха доста ясни и строги. Въпреки това има�?е място за импровизация и творчество. Резултатът бе един от най-добрите (всъщност един от малкото) дизайни, които някога съм правил - лично мое мнение.

Макар сега да виждам редица несъвър�?енства - и в прототипа, и в завър�?ения сайт - това си остава един от любимите ми проекти и се гордея с него.

Докато търсех допълнителна информация за утре�?ната лекция, която ще имам пред едни студенти информатици, се натъкнах на следното доста добро - кратко и разбираемо написано и нарисувано - описание на Microsoft Solutions Framework - Agile.Това е новата версия на майкрософтските препоръки за реализиране на софтуерни проекти, които в тая си четвърта версия звучат доста актуално и разумно.

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

Въпросният блог е този на конкурса Български сайт.

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

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

Тъй че ако ти е интересно да чете�? как се прави конкурс като Български сайт, този нов блог може да е твоето място.

От няколко години Майкрософт проектират новата версия на техния популярен пакет с програми Microsoft Office. Преди�?ната бе�?е Office 2003, новата доскоро се крие�?е зад тривиалното Office 12, но явно за да се подчинят на традицията от компанията ре�?иха в крайна сметка да бъде атрактивното Office 2007.

�нтересното в новия Офис е преди всичко радикално промененият потребителски интерфейс. Вече ги няма хилядите ленти с инструменти, които се показват и скриват неизвестно как, няма ги типичните менюта File, Edit, View… Всичко изглежда някак по-празно, просто и изчистено.

Но възможностите на отделните програми не са орязани. Всяка програма от Офис пакета има хиляди възможности, настройки, дизалози и т.н., и всички те са си в новата версия. Разликата е в това, че са направени по-лесно достъпни и откриваеми.

Една от отличителните черти на новия интерфейс е т.нар. лента, панделка или както там се превежда ribbon (всъщност официалното маркетингово название е Command Tabs – още по трудна за смислен превод фраза; нека бъде „командни табове” засега).

Продуктовият мениджър и отговорник за потребителския интерфейс на Office 12 Дженсен Харис обяснява достатъчно добре на своя блог за какво служи тази панделка и защо е толкова хитро изобретение и затова няма да преразказвам нищо.

Накратко философията на Майкрософт за новия офис е да оставят възможно най-много пространство за онова, върху което се труди човек – било то Word документ, таблица в Excel или презентация в PowerPoint, докато всички други части от интерфейса, свързани с оформянето/настройването на съдържанието, да се показват само тогава, когато изникне нужда от тях в хода на работата на потребителя.

Пример: сега, когато вмъкне�? картинка в Word се показва Image toolbar-а, който ти дава възможност да прави�? разни неща с картинката; когато вмъкне�? таблица в документа се показва Table Toolbar-a. Но когато вече си свър�?ил работата си с картинките и таблиците в документа си тези тулбарове си остават отворени. Остават отворени дори и когато започне�? работа с нов документ. В крайна сметка екранът ти се затлачва с десетките тулбарове и таскпанели и някъде там в средата остава едно малко правоъгълниче с документа, върху който в крайна сметка работи�?. (позната гледка и за онези, които се занимават с Flash разработка).

Стархотните хорица от 37signals имат едно понятие – „епицентър на дизайна”. Общо взето то е подход към дизайна на всеки екран от дадено приложение, при който проектантът се опитва да открие кое е най-важното нещо за един екран. Щом го открие, той трябва да се постарае да навърже останалите елементи (навигация, картинки, маркетингови брътвежи) около него така, че всичко да служи на основния елемент (който е всъщност епицентърът на цялото нещо) а не обратното. Обратното е да има�? най-различни елементи – лого, навигация, банери, с тях да направи�? една рамка и в останлото място да излее�? специфичната за този екран информация/функционалност. Горният пост в блога им и един наскоро�?ен пример, който направиха разясняват доста добре какво значи епицентър дизайн.

Разбира се пи�?а всичко това само, за да обясня откъде дойде идеята за един от най-сложните интерфейси, които ми се е налагало да правя.

В интерфейса на системата за управление на повече от дузината сайтове, които разработваме за Уеб медия груп (УМГ) има изобилие от възможности за настройка, процеси от по няколко стъпки, диалози система – потребител. Въобще всички онези всевъзможни неща, които обикновено стъжняват живота на хората, които ще използват дадения софтуер – просто защото са представени твърде объркващо, трудни са за разучаване и изискват наличието на свръх-чове�?ки умения у потребителите. Но неща, които в крайна сметка са необходими, за да вър�?и работата качествено.

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

Ако трябва да се направят допълнителни настройки, да се добави нещо, да се набави допълнителна информация до основната работна площ има�? една тънка вертикална ивица (наричаме я „Рибъна”), в който се развиват всички второстепенни действия. Съдържанието на лентата е се мени в зависимост от контекста и действията на потребителя.

(Скрийн�?от.)

Пример: пи�?е�? статия. �ска�? да осигури�? на читателя си малко допълнителна информация – фон за историята. Това могат да са връзки към стари новини, снимки, каквото и да е от информацията, налична в системата. Просто стартира�? търсене в Рибъна, преглежда�? резултатите, харесва�? онзи който ти трябва, с един клик го добавя�? до материала и то цъфва в основната част. 1. Без да се налага да отваря�? отделен прозорец, в който да пуска�? търсачка, 2. Без да копира�? от там каквото ти трябва, 3. без да се прехвърля�? обратно в първия прозорец 4. без да се чуди�? къде точно си искал да го вмъкне�?, 5. без да се налага да запазва�? цялото нещо, за да види�? как точно ще се отразят промените и т.н. и т.н..

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

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

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

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

Ето как се опитахме да спестим възможно най-много от мъките на бедните хора, които ще трябва по цял ден да работят със системата, създадена от нас. С въвеждането на идеята за Рибъна постигнахме два много важни ефекта:

1. по-голяма консистентност на интерфейса
2. по-прост, т.е. лесен за възприемане и разбиране интерфейс

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

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

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

За този конкретен пост бях провокиран от скоро�?ните мисли Кхой Вин – дизайнер, който понастоящем е нещо като уеб арт директор за NYTimes.com, а доскоро работе�?е в едно от любимите ми дизайнерски студиа – Behaviour. В The Elements of Style Manuals, Part One и The Elements of Style Manuals, Part Two Кхой разказва основно за ръководствата за стил (от англ. style gudes – документи, които придружават крайния продукт от работата на графичния дизайнер и обясняват как трябва да се използва той в различен контекст. Примерно, ако продуктът е корпоративна идентичност ръководството за стил ще обяснява как да бъде използвана тази идентичност в различни медии – печат, телевизия, интернет).

Тези ми ти ръководства имат редица проблеми, които са добре описани от Кхой, а ето какви са те и според мен:

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

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

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

За толкова голям проект като системата, която правим за УМГ обаче дори толкова полезен инструмент като на�?ите прототипи не може да свър�?и цялата работа. Все пак ще�?е да ни се наложи да документираме по-подробно както насъбраните изисквания, така и спецификациите за проекта. � то в продължение на целия проект (ще приключи към пролетта на 2007 година). � то при непрекъснато настъпващи изменения – все пак никой не е в състояние да проектира толкова голяма система още в началото, предвиждайки всички случаи на употреба, проблеми, ограничения и нови възможности.

Само че, горчивият ми опит с поддържaнето на подобен род спецификации ме накара да се замисля за по-добър начин за опсиване на нещата. Word, Excel и Visio са прекрасни продукти, но когато един документ трябва да се обновява непрекъснато за по-дълъг период от време и от повече хора настава едно тотално мазало. �мейлът пък има свойството да е прекалено обвързан с времето – в смисъл новите неща изместват старите на заден план, независимо от това, че старите могат да са доста важни.

� така, имахме нужда от средства, чрез което:

• Да документираме всичко, което става в проекта
• Да държим описанията на едно място
• Описанията да са достъпни от всички участници
• Всички да могат да допринасят за описанието
• Да можем лесно да следим развитието на един документ
• Ако се наложи да отменим някои нововъведения и да върнем стара версия
• Евентуално да навържем всички описания в една стройна и цялостна картина

Ако този списък те е навел на мисълта за Wiki (Wiki, като във Wikipedia), то значи сме на една вълна.

�нсталирах за около 15 минути вики на един от сървърите ни. Трябва�?е ми още около половин час, за да разуча как се работи с него. � започнах да нахвърлям първите си записки по проекта (мисля, че бяха основните случаи на употреба – a.k.a. use cases).

Това се случва и досега. Основната част от документацията към проекта е във викито. Освен това разбира се имаме и доста подробен прототип, схема на базата данни (която скоро едва ли ще се побира на чар�?аф А3/А2) и спецификации на сървърите, на който ще работи системата.

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

В заключение искам да кажа, че в момента все още не виждам друг адекватен начин за документиране на софтуерен проект. Хартията и дори Word изживяха своя живот. Те сковават човек, губят времето му и го демотивират.

Както казва Кхой Вин:

But in another sense, wiki-driven style manuals are truer to the often touted idea that the best design solutions are in fact living systems that can grow and adapt with changing needs. It’s the 21st Century, after all, and we should be documenting our design in a 21st Century fashion.