Po długich miesiącach (a w sumie to i latach) 10przykazan doczekało się nowej odsłony.

Uruchomiona dziś wersja to przede wszystkim “wygładzona” wersja druga, napisana od nowa w Django, ze zdecydowanie lepszym projektem graficznym i serwowana z Polski, przez co jest odczuwalnie szybciej.

Z funkcji które uległy bardziej widocznym zmianom, warto wymienić dodawanie blogów, które obecnie dostępne jest dla zarejestrowanych użytkowników: w trzeciej odsłonie wystarczy podać adres bloga i tagi - adres feedu zostanie sprawdzony automatycznie a z niego zostaną wyciągnięte tytuł i opis bloga.

Pojawiło się także przypominanie hasła a z czasem profil użytkownika stanie się jeszcze bardziej użyteczny, w związku z planowanym “zajmowaniem” bloga (”claim your blog”) i głosowaniem na kolejkę zgłoszonych blogów - tym samym spróbujemy oddać wcześniej bardzo krytykowaną funkcję w ręcę użytkowników.

Na razie mogą występować przejściowe problemy z działaniem/dostępnością serwisu dlatego prosimy o trochę cierpliwości i zapraszając do nowej wersji, życzę wygodnego korzystania z naszej aplikacji.

Z perspektywy e-commerce, pasaże handlowe mogą jawić się jako doskonałe miejsce do publikowania produktów swojego sklepu internetowego: duża odwiedzalność, silna marka stojąca za pasażem, relatywnie niewysoki, kuszący koszt publikacji w pasażu.

A potem przychodzi rozczarowanie - mimo usilnych starań, efektywność sprzedaży w pasażu jest bardzo niska. Od czasu do czasu pojawiają się głosy od potencjalnych klientów, że nie mogą sfinalizować transakcji gdyż “produkty giną z koszyka“.

I okazuje się, że ta pozorna niesprawność koszyka jest właśnie kluczem do wyjaśnienia znikomej skuteczności pasaży handlowych - zagłębiając się bardziej w kwestię, okazuje się, że znikanie produktów dotyczy tylko koszyka wyświetlanego przez pasaż, a idąc dalej - dotyczy tylko ukochanej przeglądarki każdego szanującego się webdevelopera - Internet Explorer.

A za wszystkim stoi polityka prywatności IE, domyślnie ustawiona na poziom Średni.

Problem dotyczy obsługi ciasteczek i specyficznego rozumienia terminu “third-party” w kontekście ciasteczek w IE6. Jeśli serwis jest wyświetlany w jednym miejscu, a dane pobiera z drugiego (ramki w pasażach handlowych to jeden z tych przypadków), IE blokuje wszystkie ciasteczka wysyłane z drugiej maszyny - tym samym blokuje możliwość utworzenia sesji. Chyba, że dostarczymy przeglądarce nagłówki P3P (zwane przez MS Compact Privacy), które wymuszą przetrwanie naszych ciasteczek.

Tadaaam, właśnie w ten sposób ~60-70% transakcji w pasażach kończy się, zanim się zacznie - standardowo, wszystkie sklepy w pasażach osadzone są w ramce. Dotyczy to także niektórych kampanii. Najpopularniejszy objaw to właśnie “znikające” produkty z koszyka.

Nurtuje mnie, dlaczego nigdy nie spotkałem się z informacją o takim błędzie od nikogo z pasaży handlowych? Dlaczego nie zauważyłem w żadnym dokumencie informacji: “istnieje błąd w IE6, który polega na tym i tamtym, aby go usunąć, prosimy o dołączenie P3P do nagłówków wysyłanych przez państwa serwer”? Tym bardziej, że jest to problem stary jak świat: http://www.oreillynet.com/mac/blog/2002/06/p3p_in_ie6_frustrating_failure.html

Nie mam zamiaru doszukiwać się żadnej teorii spiskowej na siłę, niemniej jeśli weźmie się pod uwagę standardowy tryb rozliczeń - stała miesięczna opłata - można dojść do wniosku, że to pasażom na rękę.

Nie wspominam o tym, że wiele firm (tzw. agencji) korzysta w takich sytuacjach oferując przepisanie koszyka za odpowiednią opłatą. (Nie) Wiedząc, że to nie zadziała…

Link via Filip Wośko / Janmedia.

Kilka razy spotkałem się z pytaniem osób testujących rozwojową wersję WEGO CMS, dlaczego nasz system nie może stać się czymś na miarę polskiego Basecamp. Choć równanie WEGO CMS do Basecamp - niezależnie od tego jak miłe by to było - całkiem obiektywnie wydaje mi się być mocno na wyrost, to zacząłem się zastanawiać - w gruncie rzeczy, dlaczego nie?

Osoby, które na ostatnim GrillIT zadawały mi pytania co dalej z WEGO CMS, zapewne ucieszą się, że system jest już prawie gotowy a dziś oficjalnie uruchamiamy stronę internetową, która okrzepła już na tyle, by można było ją pokazać szerszej publiczności.

Jeśli chodzi o stronę: projekt graficzny przygotowała Ola Drachal, za kod i większość tekstów odpowiadam ja. Strona działa w oparciu o nasz system CMS.

Systematycznie będziemy poprawiać i uzupełniać teksty oraz przygotowujemy wersję demo strony i panelu, gdzie będzie można przetestować działanie systemu “na żywym organizmie”. Dla osób potencjalnie zainteresowanych wdrażeniem WEGO w swoich realizacjach, przygotowujemy cykl screencastów prezentujących system od strony szablonów, a także wersję “nightly” - niestabilne buildy z SVN.

Zapraszam zatem na cms.wego.pl. Wszelkie uwagi i błędy (a jest ich jeszcze sporo) dotyczące strony internetowej, można zgłaszać mi, pod adresem nbw@icenter.pl.

Więcej informacji wkrótce.

PS. Zastanawiałem się czy to przedpremiera, premiera czy beta start. Niech będzie premiera.

W imieniu zespołu tłumaczącego, miło mi poinformować, że prace nad polskim tłumaczeniem Getting Real mają się ku końcowi. Przed nami uzupełnienie kilku tekstów i korekta oraz dopieszczanie szczegółów. Korzystając z tego, że 37signals przygotowało już miejsce na polskie tłumaczenie, postaramy się wkrótce opublikować dwa-trzy ukończone fragmenty jako zapowiedź pełnej wersji.

Przy obecnym tempie prac pełna wersja powinna być gotowa pod koniec lutego.

EDIT: Zauważyłem, że niektórzy pytają czym jest Getting Real. Getting Real to książka napisana i wydana przez firmę 37signals, opisująca jak szybciej, sprytniej i wydajniej tworzyć aplikacje internetowe. Zawiera zbiór uniwersalnych zasad, które można stosować także w innych dziedzinach życia.

Często w swojej pracy spotykam się z różnymi osobami, które mają pewne pomysły na start-upy.

Projekty bywają różne - część z nich jest bez sensu już na etapie pomysłu, część umiera później. Niestety, prawda jest taka, że dziewięć na dziesięć ciekawych projektów umiera zanim w ogóle wejdzie w fazę realizacji.

Dlaczego?

Abstrahując od problemów związanych z brakiem infrastruktury czy umiejętności, najczęstszą przeszkodą jest próba… zbyt szczegółowego opracowania projektu.

Tworzenie martwych dokumentów to jeden z największych absurdów. Pisanie pomaga zrozumieć istotę projektu, pozwala rozłożyć go na czynniki - sam rysuję i piszę, gdy mierzę się z nowym projektem. Ale stronię od tworzenia dokumentów, które będą użyteczne tylko dla jednej osoby. Stronię także od tworzenia dokumentów, dla samego sensu ich tworzenia.

Zamiast pisać - zacznij tworzyć.

Jedna z bolesnych prawd jakie odkryłem projektując gry komputerowe: nikt poza tobą nie czyta specyfikacji do końca. Im dłuższy dokument stworzysz, im bardziej złożonym językiem operujesz, tym mniejsze prawdopodobieństwo, że ktoś dobrnie do końca.

Projekt musi mieć dokumentację, to fakt. Projekt musi mieć jednak dobrą, zwięzłą dokumentację, napisaną z myślą o ludziach, którzy będą ją czytać i będą jej używać. Dokumentacja musi być narzędziem, jak każde inne - musi być na tyle czytelna i użyteczna by można było ją przekazać i nie tracić czasu na wyjaśnienia o co w niej chodzi.

Czynnik ludzki

Jeśli tworzysz projekt w którego realizację jest zaangażowana większa ilość osób po prostu musisz przyjąć założenie, że to oni są twoimi największymi przeszkodami w jego realizacji.

Pozoronie paradoksalnie - ludzie, bez których nie jesteś w stanie projektu zrealizować, są jednocześnie w stanie wywrócić cały projekt do góry nogami.

Im dłużej zastanawiasz się nad tym, jak jakiś projekt ma działać i co powinno się w nim znaleźć, tym bardziej oddalasz się od jego realizacji. Ponieważ rozważamy projekty spontaniczne, bez zaplecza finansowego, którym można “stymulować” grupę osób, jedynym stymulantem jest coś bardzo eterycznego - idea. Pamiętaj - eterycznego, czyli ulotnego.

Jeśli nie uda ci się utrzymać żywej idei w grupie przez odpowiednio długi czas - przegrałeś.

Przeszkody przez innowacyjność

W książce “Mityczny osobomiesiąc” jedna z przewodnich myśli brzmi - jeśli tworzysz projekt innowacyjny, stykając się z technologiami czy metodyką z którą wcześniej nie miałeś do czynienia, pierwsza wersja powinna być potraktowana jako tester, prototyp. Dopiero w oparciu o wyciągnięte wnioski z tej wersji, istnieje szansa na realizację udanego projektu oficjalnego.

Sęk w tym, że to idea sprawdzająca się w tworzeniu oprogramowania, przy projektach rozłożonych na lata. A mówimy przecież o projektach, których cykl projektowy trwa kilka-kilkanaście dni.

Niech twój projekt oficjalny stanie się jednocześnie prototypem - uruchom coś, cokolwiek. Wyrzuć wszystkie funkcje, których nie jesteś w stanie wdrożyć w odpowiednio krótkim czasie. Pracujcie na żywym organizmie. Ludzie mogą twierdzić, że projekt który realizujecie jest niedopracowany, że się źle nazywa, że ma kiepski projekt graficzny - na to wszystko przyjdzie czas, później.

W 37signals twierdzą: nie skupiaj się na szczegółach za wcześnie i mają rację.

Mało znaczy dużo

Początek jest taki sam dla niemal każdego “wielkiego” pomysłu - szukanie ludzi, gdy tak naprawdę nie mamy im nic do zaoferowania; szukanie pieniędzy, gdy nie ma się nic do pokazania.

Im większy zespół tym więcej problemów. Jeśli potrzebujesz godzinę by wytłumaczyć jednej osobie ideę projektu, w który chcesz tę osobę wciągnąć, to jeśli musisz to samo przedstawić grupie dziesięciu osób tracisz już dziesięc godzin. Dziesięć godzin, które mógłbyś wykorzystać na stworzenie czegoś użytecznego, czegoś co nie umożliwia dowolnej interpretacji - szkic interfejsu, kawałek kodu, działająca funkcjonalność. Pamiętaj, że każdej kolejnej osobie, którą zaprosisz do pomocy przy nieistniejącym projekcie będziesz musiał tłumaczyć wszystko od początku.

Duże zespoły wymagają kontroli. Duże zespoły potrzebują raportów, zebrań, spotkań, dyskusji. Im większy zespół tym większego wysiłku potrzeba do koordynacji projektu. Zamieszanie wokół wielkich zespołów jest na tyle duże, że pozwala ukryć fakt, że realnie pracuje tylko kilka osób - reszta jest bierna, z reguły nie rozumiejąc o co w projekcie chodzi.
Im więcej osób ma wpływ na projekt na wczesnym etapie - na etapie planowania, tym większe prawdopodobieństwo, że ostateczny produkt będzie wszystkim, tylko nie tym, czym miał być. Jedna osoba to z reguły dwa różne pomysły, dwie osoby to już cztery ale trzy osoby to już dziewięc sprzecznych ze sobą pomysłów.

Doświadczyliśmy tego w generated content - mylą się bowiem ci, którzy myślą, że 10przykazan.com to nasz pierwszy wspólny projekt. Starszy jest projekt, w który zaangażowane jest kilka osób - jego planowanie mogłoby posłużyć za przykład jak tego nie robić. I prawdopodobnie kiedyś to jeszcze opiszemy.

Trzy fazy upadku

W projektach innowacyjnych wydzielam trzy fazy upadku:

1. IDEA - ludzie gromadzą się wokół jakiegoś pomysłu. Pomysł jest niedookreślony, ale na tym etapie to nieważne - ludzie mają entuzjazm, cieszą się, mają głowy pełne pomysłów
2. “O co tu chodzi?” - przeciąganie terminu realizacji projektu i notoryczny brak dookreślenia założeń sprawia, że coraz więcej osób zadaje właśnie to pytanie. Więcej osób pytających generuje więcej czasu potrzebnego na wytłumaczenie o co chodzi
3. Jeśli na etapie drugim nie uda się uruchomić projektu, to na etapie trzecim już nikt, łącznie z samym pomysłodawcą, nie jest w stanie określić o co w projekcie chodziło. Osoby bezpośrednio zaangażowane tłumaczą o co chodziło, inni kręcą się w kólko nie wiedząc co mają robić. Projekt umarł.

Projekty, bez zaplecza finansowego, nie mają za dużo szczęścia. Dlatego staraj się jak najszybciej dostarczyć cokolwiek działającego. Jeśli budujesz serwis gromadzący ciekawe notki na jakiś temat, nie czekaj aż otrzymasz profilowany CMS - załóż bloga, np. na Wordpressie czy Text Pattern z dostępem dla wielu użytkowników.
Pozwoli ci to szybko zweryfikować na kogo możesz liczyć oraz wskaże dalszą drogę rozwoju.

Rozwój przez wyrzuty sumienia

Jeśli wypuścisz produkt, poczujesz ulgę. Ale to dopiero początek drogi i z doświadczenia powiem, że było to łatwiejsze niż to, co czeka cię teraz - rozwój produktu.

Nie oszukujmy się - w polskich realiach najwięcej innowacyjnych czy po prostu ciekawych pomysłów, mają ludzie w wieku 18-25 lat. Z reguły nie mają zaplecza finansowego, często rozwijają wszystko za własne pieniądze. Często muszą utrzymać siebie, skończyć szkołę/studia, utrzymać się w pracy codziennej. Projekty, które rozwijają są wynikiem ich pasji, często te projekty w ogóle nie mają potencjału komercyjnego - nie da się ich spieniężyć, wrzucenie reklam jest równoznaczne z degradacją projektu.

To wszystko pochłania czas i nagle okazuje się, że nie ma go na to, by rozwijać pomysł. I w tym momencie właśnie pojawia się kolejna zaleta tego, że projekt został uruchomiony i ktoś z niego korzysta - wyrzuty sumienia, które w końcu popchną cię do tego, by wprowadzić te wszystkie zmiany o które były planowane.

Brzmi strasznie, ale w rzeczywistości to dobrze, że tak jest. Ograniczenia zmuszają do szukania rozwiązań.

Pojawia się jednak w tym miejscu jeden poważny problem, z którym musi sobie dać radę każdy - umiejętność podzielenia się projektem. Każdy chce być sławny i bogaty, nie oszukujmy się. Przychodzi jednak taki moment, w którym trzeba zwrócić się o pomoc do kogoś innego. Możesz być super programistą, super grafikiem czy super koderem, ale jak brzmi stare powiedzenie gruzińskie: “i Herkules dupa, gdy wroga (problemów) kupa”.

Odstąp część obowiązków komuś innemu, pozwól wnieść w swój projekt trochę świeżości. To wciąż twój projekt ale nie rozwiniesz go, jeśli cały czas będziesz trzymał wszystko na swoich barkach. Nam się udało - przy nowym 10p pracuje jeszcze kilka osób “z zewnątrz”. Tłumaczenie Getting Real to mój pomysł, który udało się zrealizować dzięki temu, że podzieliłem się nim z Kubą Filipowskim a razem uznaliśmy, że lepiej będzie jeśli zarządzanie projektem weźmie na siebie ktoś, kto ma od nas więcej czasu i odpowiednio duże doświadczenie w takich projektach (Michał Tosza).

Nie bój się błądzić - obserwuj ludzi, którzy dają jasne sygnały co im się podoba a co nie. Może z początku będziesz musiał zmagać się z krytyką ale tego nigdy nie unikniesz. Może z początku będziesz sądził, że wypuszczanie niedokończonych projektów w Sieć trąca amatorszczyzną, jest po prostu śmieceniem - i będziesz miał rację. Ale w przypadku braku zaplecza finansowego, to często jedyny sposób, by twój pomysł nie umarł zanim się narodzi.

Bardzo dobrze, z menadżerskiego punktu widzenia, opisał to Marcin Niebudek w notce Planować czy startować.

Od powstania 10przykazan.com minął rok. Zbliżający się nowy rok to dobra okazja do krótkich podsumowań. Mimo rozbieżnych opinii o serwisie udało nam się przetrwać ten rok a serwis uzyskał pewną ugruntowaną pozycję.

10przykazan.com w statystyce to:

• 3,643,808 odsłon, od początku istnienia
• 28.46 gigabajtów danych wysłanych, od początku istnienia

Co po uśrednieniu, tygodniowo przekłada się na:

• 105,103 odsłon
• 917.57 megabajtów danych wysłanych
• 1.997 unikalnych adresów IP

Ogólnie nie jest to dużo jak na serwis, ale całkiem sporo jak na serwis, którego wcale nie trzeba odwiedzać by z niego korzystać. Nie jesteśmy “statofilami”, więc w tej chwili nie jestem w stanie zaprezentować bardziej złożonych statystyk.

Oczywiście, miesiąc się jeszcze nie skończył a statystyki mogą uleć poprawie, tym bardziej, że od dwóch dni 10przykazan.com jest jednym z “kanałów sponsorowanych” w polskiej wersji serwisu netvibes. Dziękujemy.

Rodzi się oczywiście pytanie - ok, ale co dalej?

Nie da się ukryć, że w chwili obecnej cała nasza praca skupiona jest na uruchomieniu innych aplikacji oraz stron firmy w której pracujemy, przede wszystkim systemu WEGO CMS i jego strony domowej. Nie oznacza to jednak, że nie szykujemy aktualizacji 10p. Będzie to pierwsza aktualizacja funkcjonalna, w której zmianie ulegnie nie tylko wygląd serwisu. Dojdą nowe funkcje o które dopytywaliście się przez cały rok oraz te, które planowaliśmy wprowadzić od samego początku. Serwis stanie się bardziej interaktywny i mniej zależny od naszego czasu. Aktualizacja przebiegnie dwuetapowo - pierwsza aktualizacja będzie aktualizacją funkcjonalną, z małym face-liftingiem. Z racji tego, że dojdzie więcej funkcji, zmianom ulegnie wygląd serwisu (choć staramy się zachować obecny układ). Kolejna aktualizacja będzie już tylko wizerunkowa, a o samym projekcie nowego 10p jeszcze wspomnę w nieodległej przyszłości.

Ponadto, jeszcze przed nowym rokiem szansę, by ujrzeć światło dzienne ma wczesna wersja podserwisu 10p i traduko.info. Powstała jako wynik długotrwałej i długofalowej współpracy generatedcontent.com oraz yashke.com

Podsumowując, w imieniu zespołu 10p chciałbym podziękować za krytykę i pochwały, którymi nas i nasz serwis obsypywaliście oraz życzyć Wam pogodnych i wesołych Świąt Bożego Narodzenia, Szczęśliwego Nowego Roku oraz dalszego korzystania z naszych (tak GC jak i Yashke) serwisów. Oczywiście, idąc śladem przedostatniej notki z bloga iCenter możecie składać swoje życzenia dotyczące serwisu 10p.

O tym, że przejście ze specyfikacji Transitional na Strict trwa zbyt długo pisało już wielu autorów, w tym Roger Johansson. I odkąd zajmuję się stronami - również byłem zwolennikiem tego, by podchodzić do kodu jak najbardziej rygorystycznie. Z tym, że z czasem zauważyłem, że na pewne zmiany jest za wcześnie i zamiast narzucać pewne reguły, trzeba by się zastanowić, czy jesteśmy w ogóle w stanie je spełnić.

Dawno nie poruszałem kwestii technicznych na swoim blogu, więc przypomnę jedynie, że jestem umiarkowanym przeciwnikiem XHTML w warunkach komercyjnych, skłaniającym się w stronę “HTML5″.

Zatem, czy jesteśmy w stanie spełnić wymogi specyfikacji Strict, nawet na poziomie zwykłego HTML, bez marketingowego “X”?

My, jako twórcy - owszem - w pewnym zakresie - jesteśmy. Czy przeciętny, nietechniczny, użytkownik końcowy jest w stanie spełnić wymogi stawiane mu przez technologię? Nie, nie jest.

Patryk Zawadzki poruszył kwestię semantyki w dokumentach biurowych - kwestię, która wychodzi poza wybór Worda czy Excela do napisania dokumentu, bo dotyczy także kreowania treści w stronach internetowych.
Warto bowiem zwrócić uwagę na fakt, że w dyskusjach przed projektem niemal każdy stwierdza, że treść jest najważniejsza. Lecz kiedy przychodzi czas jej wprowadzania okazuje się, że jest to element traktowany kompletnie po macoszemu - zajmuje się tym osoba, która nie ma o tym pojęcia.

I naprawdę, nie jest to kwestia edytorów - nieważne czy taka osoba dostanie FCKEditor, TinyMCE, składnię wiki czy markdown. To tylko narzędzia - tak, jak nie da się zabronić człowiekowi użycia siekiery w charakterze broni, tak nie da się go zmusić do tego, by nagłówek był nagłówkiem, akapit akapitem a tabela tabelą. Jako deweloperzy mamy prawo i obowiązek edukować klientów i użytkowników końcowych w tworzeniu semantycznych dokumentów.
A na razie, dopóki liczba ludzi kompetentnych nie zmarginalizuje tych niekompetentnych (wyeliminować niekompetencji całkowicie się nie da), nie warto pchać się w technologie zbyt rygorystyczne. Jeśli nie mamy kontroli nad tym, jak ostatecznie będzie wyglądała strona i kto będzie nią zarządzał, lepiej brać pod uwagę najbardziej pesymistyczne scenariusze i z góry uprzedzać przeglądarkę, że ładuje kod, który potencjalnie stał się zupą tagów. To, czy będzie to XHTML czy HTML zależy tylko i wyłącznie od wiedzy i umiejętności nazwania rzeczy po imieniu.

Z komercyjnego życia - niedawno prowadziłem projekt klientowi, który na etapie specyfikacji określił, ku mojemu miłemu zaskoczeniu, że chciałby by strona spełniała wymogi XHTML Strict, WAI-AA i była w pełni nawigowalna z poziomu przeglądarek tekstowych.
Żadnego flasha, żadnych splashów, żadnych javascriptowych rozwijalnych menu.

Nie jest to co prawda pierwszy taki klient - coraz częściej się tacy świadomi klienci zgłaszają, lecz jest to wciąż margines zleceń. Problem pojawił się na etapie przedstawiania wyceny, gdy okazało się, że wprowadzenie treści to prawie 1/3 całego projektu (chodziło o wprowadzenie kilkuset dokumentów i produktów).

Znikoma częstotliwość z jaką obecnie pisuję spowodowana jest okołowakacyjnymi rozjazdami oraz kilkoma projektami nad którymi pracuję.

Nie wdając się w szczególy, bo czasu za wiele nie mam (za chwilę szybki marsz na pociąg), pragnę tylko poinformować, że poszukuję stałych współpracowników do powstającego magazynu internetowego. Tematyka: Web i okolice (bliższe i dalsze).

O szczegółach napiszę z czasem, na razie proszę kierować ewentualne zgłoszenia od zainteresowanych osób na adres: nbw@generatedcontent.com (wszelkie pytania rzecz jasna także)

Kiedy przychodziłem do Internet Center Polska, wiedziałem, że jednym z podstawowych atutów tej firmy jest powstający system CMS.
Od tego momentu minęły już prawie 4 miesiące, panel dorobił się nazwy, logo, strony produktowej (powstającej) i strony testowej (która będzie dołączana do każdej wersji) - codziennie zamienia się z brzydkiego kaczątka w ładnego łabędzia o niesamowitych umiejętnościach. Dodatkowo firma przechodzi metamorfozę i nadrabia stracony czas. Gdyby był to tekst stricte marketingowy, pisany w stylu amerykańskim dodałbym: “it’s very exciting!”. Ale niezupełnie o tym chcę dziś napisać.

Patryk zaprezentował wczoraj filmik z bardzo wczesnej wersji WEGO CMS, a ja od pewnego czasu zbieram się do spisania cyklu artykułów, które są wynikiem pracy m.in. nad tym projektem.

Czym jest CMS? Czym być powinien?

Na szczęście na to pytanie nie musieliśmy sobie odpowiadać - wszyscy wiemy, że CMS to nie przedłużenie phpMyAdmin. Jeśli nie jesteś w stanie wymyślić nic bardziej oryginalnego i wygodnego niż PMA - daruj sobie (mówimy o warunkach komercyjnych, a nie tworzenia czegoś dla nauki).

Niestety, znam wiele rozwiązań, które są podpisywane jako CMS, gdy tak naprawdę cechują się funkcjonalnością i użytecznością bliską zeru. W skrajnych przypadkach wygodniej jest pracować bezpośrednio na bazie danych, niż katować się czymś, co szumnie nazywane bywa “panelem administracyjnym”, a nie ma nawet opcji kopiowania artykułów.

Chcesz sprawdzić, czy Twój CMS sprawdzi się w praktyce? Odpowiedz sobie, jak łatwo użytkownik może przepisać kategorie dla 100 produktów? Jak łatwo może skasować 200 spośród tysiąca wybranych artykułów? Czy nie sprawi mu kłopotu jednoczesna zmiana ceny o 2%, dla kilkudziesięciu wybranych produktów?

Założenia wizualne

Najczęstszym konfliktem jest płaszczyzna porozumienia między osobami, które mają wpływ na panel. Bez wspólnej wizji naprawdę nie ma co zaczynać - prowadzi to w prostej linii do kłopotów i niepotrzebnych nerwów.

Mniej znaczy więcej - jest to hasło, które wspaniale pasuje do CMSów. Panel powinien być przejrzysty, cechować się dobrą typografią, lekkością, doskonałą ikonografią. W założeniu jest to całkiem oczywiste, lecz gdy przychodzi do realizacji, wtedy rodzą się problemy.

Dobry wygląd to taki, który nie przeszkadza. Masowość - on ma być przyjemny, niekoniecznie dziełem sztuki. Stonowane kolory, dobra typografia zapewniająca czytelność, odpowiednio dobrany rozmiar elementów, by zminimalizować przypadkowość, dobrze dobrana i opisana ikonografia to klucz do sukcesu.

Jeśli stosujesz ikony - oszczędzasz miejsce na ekranie, ale sprawdź, czy Twoje ikony są opisane (title, anybody?). Nie ma nic gorszego niż zastanawianie się, czy kliknięcie na znaczek doda, czy może skasuje artykuł.

Założenia technologiczne

W przeciwieństwie do strony internetowej, w panelu można poszaleć. Jeśli są miejsca w których AJAX pasuje, to zdecydowanie są to rozwiązania CMS - im mniej przeładowań strony, tym lepiej. Im szybciej klient może wprowadzić poprawkę w ofercie - tym lepiej.

W WEGO pokusiliśmy się między innymi o zlikwidowanie wszelkich wyskakujących okien, co będziemy prezentować w kolejnych screencastach.

Odwróć kolejność projektowania - funkcjonalność i użyteczność przede wszystkim

Jednym z ważniejszych powodów, dla których według mnie wiele paneli nie nadaje się do użytku jest to, że ich autorzy zaczęli je tworzyć od obmyślenia jak mają wyglądać. Gdy zaczęły wzbogacać się o dodatkowe funkcje okazało się, że nie ma już szans by atrakcyjnie wpasować nowe elementy. Jeśli właśnie pracujesz nad systemem - uwierz mi, szkoda czasu. Zacznij myśleć o funkcjach, które panel ma zawierać. Zacznij myśleć o tym, jak użytkownik będzie z niego korzystał, jakich rzeczy będzie poszukiwał.

Pamiętaj również o tym, że jeśli jakaś funkcja wydaje ci się mało ważna to znaczy, że jest zbędna. Jeśli opracowujesz edytor wizualny, nie oddawaj w ręce finalnego użytkownika całego MS Worda. W praktyce i tak będzie korzystał tylko z kilku podstawowych funkcji takich jak pogrubienie, pochylenie czy wklejenie obrazka. Marketingowcy mogą się oczywiście oburzyć - “no jak to, a gdzie zmiana koloru fontów, ich rozmiaru, czcionki??”.

Odpowiedź jest bardzo prosta - nie po to grafik projektuje stronę a koder ją koduje, by później “pani Jadzia” zepsuła cały look’n'feel tabelką z MS Worda z rózowymi tekstami na żółtym tle.
Dobrą praktyką, choć trudną w przestawieniu się, jest rozpoczęcie projektowania od najbardziej rozbudowanych elementów po te, które są najprostsze. Unikniesz w ten sposób poprawek wynikających z tego, że nagle pojawił się box, którego nie idzie nigdzie wcisnąć. Oczywiście, wymaga to treningu i praktyki, by nie okazało się, że strona główna straszy pustkami.

I na każdym kroku upraszczaj.

Kreatywność ujęta w ramy

Niestety, nie zawsze da radę zaprojektować wszystko od samego początku. Czasem zastaniesz gotowy produkt, który już działa a nawet doczekał się kilku wdrożeń. Tak na przykład jest z WEGO.

Wtedy wprowadzanie zmian przeradza się w grę strategiczno-taktyczną z uwzględnieniem zmian wprowadzanych przez programistów oraz sugerowanych przez zarząd (w znacznej mierze z gatunku “WTF?”).

Jeśli jesteś w stanie - jak najszybciej oceń przydatność uwag członków zespołu i wyeliminuj (może nie dosłownie tych, których pomysły są niedorzeczne. Z reguły chodzi o zarząd - wtedy musisz być przygotowany na wprowadzanie zmian na siłę, bez konsultacji i próśb o akceptację. Mało popularna metoda; dobra, jeśli masz ugruntowaną pozycję i doświadczenie.

Pytania, na które musisz sobie odpowiedzieć

Jeśli już palisz się do zaprojektowania od nowa, bądź wprowadzenia zmian w obecnym projekcie, zaczekaj, usiądź i znajdź odpowiedź na pytania:

• co chcę przekazać
• co chcę osiągnąć
• co mnie interesuje jako użytkownika
• co bym chciał zrobić na danej stronie
• do kogo skierowany jest mój CMS

Są to pytania o równie silnym znaczeniu. Dopiero odpowiedź na nie determinuje to, jak ma działać i wyglądać panel. Oczywiście, pamiętaj, że nie da się zadowolić wszystkich.

Na zakończenie

Jeśli zdarzy się Wam kiedyś przeprojektowywać panel zarządzania stroną, nie zawsze traficie na ludzi, którzy podzielają Waszą wizję . Nie zawsze traficie na grafików, którzy potrafią tworzyć dla Webu, programistów, którzy mają jakieś pojęcie na temat atrakcyjnego wyglądu, który nie przypomina konsoli uniksa oraz nie zawsze będziecie mogli skonfrontować swoje pomysły ze specjalistami od użyteczności i dostępności. Wygląda na to, że nam się udało.
Razem z Patrykiem zapraszamy Was do śledzenia kolejnych raportów (screencastów) z prac nad systemem WEGO CMS.

Pewien klient (nazwijmy go K - klient), pewnej firmy (nazwijmy ją A), poszedł po rozum do głowy, i zażyczył sobie badanie użyteczności projektu, który przygotowała mu firma A. Ekspertyzę przygotowała pewna znana i ceniona firma w tej branży, która rozdaje ciasteczka przy zgłoszeniu strony. Firmę tę nazwiemy B.

Okazało się, że projekt, choć całkiem niezły wizualnie, posiada wiele mankamentów.

Wywołało to falę oburzenia na licu menadżera firmy-wykonawcy strony. Bo przecież, jak można wydawać pieniądze na jakieś durne ekspertyzy u KONKURENCJI (mniejsza o to, że wykonawca nie ma pojęcia o ekspertyzach użyteczności stron).

Owszem, sam termin “konkurencja” w przypadku firmy tworzącej ekspertyzy, jest bliski prawdy, bowiem firma ta, w swoich materiałach, stosuje nachalne wręcz stwierdzenia podchodzące pod “my takich błędów nie popełniamy - my zrobimy lepiej, płać nam”. Mógłbym się oczywiście uczepić i wypomnieć BIP pewnej firmy, wykonany właśnie przez wzmiankowaną firmę B - ale okej, takie są realia rynku - skoro firma B zajmuje się również tworzeniem stron, to dlaczego miałaby nie informować o tym? Wszak to klient (K) wybiera ostatecznie.

Co więcej - menadżer uznał, że użyteczność strony, można ocenić dopiero po jej ukończeniu i podpięciu statystyk.

I rzekomo, na podstawie statystyk, możemy wysunąć wnioski, czy nasza strona jest użyteczna.

Nie, nie możemy. Co najwyżej, możemy wysunąć wniosek, że nasza strona jest używalna.

Na czym polega różnica?

Wyobraźmy sobie, że do otwarcia konserwy, mamy do wyboru siekierę, nóż i otwieracz. Każdym z tych narzędzi, możemy tę konserwę otworzyć, ale to otwieracz jest do tego stworzony (chyba, że chodzi o stare, radzieckie konserwy - wtedy siekiera może być bardziej odpowiednia). Zatem siekiera jest używalna, ale to otwieracz ma większą użyteczność.

Podobnie jest ze stronami - jeśli użytkownik jest zdesperowany, to przymknie oko na krzyczące kolory, na to, że nie wie który element kliknąć i będzie ze strony korzystał.
Ba, dzięki wrodzonej inteligencji, po jakimś czasie się nauczy i nawet przyzwyczai do tego, że by dostać się do kalkulatora oszczędności na stronie banku, by sprawdzić sobie dwie rzeczy, musi poświęcić dziesięć minut na wędrowanie w gąszczu stron i wypatrywaniu malutkiego szarego napisu na białym tle.

Użyteczność serwisów to nie jest wartość dodana, na którą szkoda czasu. Nie jest to również wartość, o której można zapominać. Strona internetowa, najwyraźniej wbrew wyobrażeniom wielu, to nie obrazek, który zawieszamy w antyramie i zabieramy się za następny. Użyteczność serwisu to element, który ma bezpośrednie przełożenie na jego efektywność.

Spotyka się to jednak ze zrozumiałym oporem ze strony menadżerów, którzy “wiedzą lepiej”, wszak mają wieloletnie doświadczenie (sięgające pierwszych dot comów - respekt, ale czasy się zmieniły) i grafików, którzy rzadko kiedy mają choć pobieżną wiedzę z zakresu budowania i funkcjonowania serwisów po wyjściu z Photoshopa.

Użyteczność a funkcjonalność

Między tymi dwoma określeniami nierzadko stawiany jest znak równości. Tak, mogą być ze sobą powiązane. Nie, nie są od siebie zależne. Serwis funkcjonalny, czyli zawierający funkcje służące do realizacji określonego celu, nie musi być użyteczny - czyli, po prostu, wygodny.

Mniej znaczy więcej

Złota zasada, do której będę nawiązywał niejednokrotnie, głosi, że im mniej elementów na stronie, tym większe prawdopodobieństwo, że użytkownik podejmie właściwą decyzję.

Minęły czasy dogłębnego poznawania serwisów (zostało dogłębne poznawanie koleżanek, ale tu nie o tym), nie ma co liczyć na to, że przeciętny użytkownik-meteor, który trafił na naszą stronę z rekomendacji znajomego czy wyszukiwarki, skupi się na rozbieraniu naszej strony na czynniki, pieszczeniu każdego elementu wzrokiem. Liczy się treść i szybkość, z jaką otrzyma to, czego szuka. W dobie dziesiątek serwisów, które oferują niemal to samo, wygrywają te, które rozumieją użytkownika (to już złotą zasadą nie jest).

Przekładając słowa na czyny

Kiedy przychodzi czas na praktykę, naprawdę trudno o odkrycie Ameryki. Wiemy już, że nasi użytkownicy oczekują od nas przede wszystkim “kontentu”. Zatem jak najszybciej możemy doprowadzić ich do frustracji i opuszczenia naszego sajtu? Utrudniając im odnalezienie tego, po co przyszli.

O budowaniu serwisów nakierowanych na użytkownika będę jeszcze z pewnością nie raz pisał, niemniej już teraz zacznijmy od wpojenia sobie myśli: “projektując, myśl o tym, co by chciał osiągnąć użytkownik”. Określ najpierw to, czym jest projekt który realizujesz i jakie są jego główne zadania. Następnie usiądź przed draftem, który zapewne wcześniej przygotowałeś i wyeliminuj wszystkie elementy zbędne. Z doświadczenia wiem, że w przypadku tradycyjnych dizajnów znaczna część elementów jest co najmniej zbędna. Na teraz uwaga: jeśli nie wiesz jak zmieścić jakiś box w danym miejscu - prawdopodobnie on tam nie pasuje.

Zamiast tłumaczyć się z każdej decyzji - twórz serwisy, po których nawigacja jest intuicyjna. Chyba, że planujesz dodawac 200 stronnicową instrukcję obsługi albo interaktywnego spinacza.

Niestety, odnoszę wrażenie, że upłynie jeszcze sporo wody w polskich rzekach, nim koncepcje użyteczności, dostępności czy semantyki przebiją się przez komercjonalizm polski. Przebiją się i staną się istotnymi elementami każdej strony, a nie tylko reklamową paplaniną, którą wciska się gdzieś między “nasze strony są w XHTML więc wyglądają wszędzie tak samo” i “stosujemy AJAX” (do animowania elementów). Na razie jednak decyzję o wyglądzie stron podejmują szefowie, którzy z nowoczesnymi standardami mają tyle wspólnego, co ja z budowaniem wahadłowców - “gdzieś o tym czytałem”.

PS. Ta notka została skrócona, ciąg dalszy nastąpi (prawdopodobnie).