nbw: Redefine the undefined

1. Planowanie zaczynasz mniej więcej na rok przed terminem wdrożenia. Jesteś typowym klientem: nic nie wiesz, nie wiesz gdzie szukać, kogo pytać, czego oczekiwać. Prawdopodobnie wybierzesz konsultanta, przez co będziesz pluł sobie w brodę przez resztę życia. A przynajmniej okresu przygotowawczego. I okresu spłaty zadłużenia.
2. Konsultant zaproponuje ci wdrożeniowców, którzy – jeszcze o tym nie wiesz – zjedzą cię razem z kopytami. A potem wystawią rachunek na usługi, o których nikt cię nie poinformował.
3. Jeśli projekt będzie trwał rok, przez 11 miesięcy nic znaczącego się nie wydarzy. Nie licząc oczywiście podpisania umowy, wpłacenia zaliczek oraz pierwszych przymiarek. Jeśli masz mniej czasu na wdrożenie, proporcje będą zachowane choć z racji krótszego czasu wdrożenia, może ci się wydawać, że wszyscy ci pomagają.
4. Konsultant będzie cię nagabywał o przygotowanie i trzymanie się planu projektu. Tak, masz rację, w rzeczywistości nie ma żadnego planu a wszystko co jest spisane to to, co zaproponowałeś na samym początku.
5. Przez większość czasu będziesz płacił za rzeczy, których nie widzisz; różnica z projektem internetowym polega na tym, że w sporej mierze są to rzeczy, których faktycznie nie potrzebujesz.
6. Na etapie oferty, konsultant przedstawi ci listę rzeczy/pomysłów, które nie są już trendi, nie wyglądają dobrze oraz są średnio 4 razy droższe w ofercie niż kosztują w rzeczywistości.
7. Na etapie oferty zostaną ci również przedstawione wodotryski, z których wiadomo od razu, że nikt nie skorzysta. Możesz być niemal pewien, że będzie to oś oferty.
8. Nikt nawet nie ośmieli się zapytać, czy masz może jakiś pomysł przewodni, czy może chciałbyś, by jakiś element z twojego/waszego życia był jakoś wyróżniony…
9. …a jeśli takowy sami zaproponujecie, na drugim spotkaniu zostanie sprzedany jako błyskotliwe odkrycie konsultanta
10. Przez 10 miesięcy będziesz uspokajany, że projekt idzie zgodnie z planem, że wszystko jest pod kontrolą…
11. …oczywiście, tak nie jest. O czym dowiesz się na dwa tygodnie przed, kiedy nagle wszystko stanie na głowie
12. I tak jak w projektach internetowych, prace nie posuną się do przodu jeśli przynajmniej raz dziennie sam się z czymś nie przypomnisz.
13. Prawdopodobnie nikt z konsultantów/podwykonawców nie uczyni nawet najmniejszego kroku by ci coś podpowiedzieć bądź pomóc. Jeśli już, będzie to kosztowało horrendalnie dużo a i tak nie dostaniesz tego, co byś chciał.
14. Aż w końcu, tego wyjątkowego dnia i tak okaże się, że z większością rzeczy nie zdążyliście.

W przeciwieństwie do projektów internetowych – z perspektywy czasu, to i tak nie ma znaczenia. Bo zabawa na pewno będzie przednia.

Od dnia kiedy rozpoczęliśmy tłumaczenie Getting Real od 37signals minęły już dwa lata (właściwie to nieco ponad). Choć przez długi czas wydawało się inaczej, to jednak uda się je skończyć…

Tłumaczenie z przygodami – tak mógłbym w skrócie je określić.

Na początku tłumaczyłem GR sam, później pomagał mi Kuba Filipowski, z którym mieliśmy nadzieję wpiąć tłumaczenia w traduko.info. Niestety, na drodze realizacji tego pomysłu stanęły problemy licencyjne – padło więc na Wiki.

Mediawiki to nienajlepsza platforma do tłumaczenia książek – wszystko ponad standardową edycję i składnię jest dość zawiłe. Poza tym, to armata na komara. Jednak sam wybór wiki był dobry – umożliwiło to wprowadzenie większej liczby ludzi do projektu tłumaczenia i kontrolę nad tym, co w tłumaczeniu się dzieje.

Bardzo dobrym pomysłem było przygotowanie słowniczka trudnych pojęć i próba narzucenia sobie wzajemnie pewnego standardu tłumaczenia. A było o czym dyskutować: czy zwracać się bezpośrednio do czytelnika, czy stosować formy grzecznościowe, czy zmieniać nazwy serwisów na te, które lepiej przemawiają do naszego czytelnika (ot, choćby Facebook > Nasza-klasa). Język angielski jest elastyczniejszy jeśli chodzi o pisanie o technologii. To, co mnie osobiście rozbrajało w niektórych esejach to pseudo-metaforyczne tłumaczenia problemów, które po angielsku są oczywiste i brzmią doskonale. Po przetłumaczeniu na polski – już nie bardzo, niestety. Wypadało zgodzić się z Wolterem: “Tłumaczenia są jak kobiety – piękne nie są wierne; wierne nie są piękne” i zachowując sens i kontekst, stworzyć dany fragment od początku.

Niezłym pomysłem było także dostosowanie się do zagadnień, które zostały zawarte w książce – np.: mając już relatywnie ponad połowę tłumaczenia, postanowiliśmy zacząć wrzucać gotowe fragmenty na stronę Getting Real. I może by to pomogło, gdyby nie pewne ale.

Pierwszym problemem był czas wolny. Właściwie każdy z nas, miał pewien limit czasu wolnego, który mógł przeznaczyć na tłumaczenie.
Drugim problemem była technologia, co jak się okazało, było naszym głównym problemem. Te dwa problemy nałożyły się w momencie, kiedy wiki z tłumaczeniem, trzymane na Dreamhost – padło. Odzyskiwanie danych zajęło długie… miesiące, w czasie których wszyscy się rozeszli, pozmieniali prace, pozakładali rodziny, stali się mikrocelebrytami. Ogólnie: żyli długo i szczęśliwie.

To, co udało się odzyskać z backupów, ustawiłem u siebie i – spędzając wolne wieczory i noce – uporządkowałem, podzieliłem na kategorie i dotłumaczyłem stracone fragmenty oraz te, które nie doczekały się tłumaczenia w ogóle.

W momencie kiedy piszę te słowa, stan tłumaczenia Getting Real to ponad 70 przetłumaczonych esejów, 60 oznaczonych jako wymagające korekty i 2 nieprzetłumaczone/przetłumaczone w połowie. Faktycznie wymagających korekty jest połowa, może nawet mniej – wrzucone są do jednego worka bo i tak trzeba przeczytać je raz jeszcze.

Teraz trzeba wszystkie eseje przejrzeć raz jeszcze, uspójnić, ewentualnie poprawić interpunkcję czy stylistykę. Może świeże spojrzenie umożliwi też znalezienie lepszych tłumaczeń fragmentów już przetłumaczonych.

Jeśli więc czujesz się na siłach by pomóc doprowadzić to nieszczęsne tłumaczenie do szczęśliwego końca – przyda się Twoja pomoc.

W szczególności mile widziane są osoby, które kiedyś już tłumaczyły z nami GR, a na które nie mam już namiarów.

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)