MalyDaemon

Wyjaśnienie

Krótkie wyjaśnienie dotyczące skrótów, które mogą nie być dla wszystkich zrozumiałe:

1. CMS - ang. Content Management System czyli system zarządzania treścia. Są to systemy których zdaniem jest ułatwienie zarządzania treścią (”content”) stron WWW
2. edytor WYSIWYG - w kontekście systemów zarządzania treścią jest to specjalne pole w którym wpisujemy tekst który ma zostać wyświetlony na stronie. Dodatkowo możemy dokonać formatowania tekstu (pogrubienie, podkreślenie). W przypadku bardziej zaawansowanych edytorów możliwości te mogą być rozszerzone o wstawianie obrazków, linków czy innych elementów.

Wstęp

Od jakiegoś czasu obserwuje znaczący wzrost liczby Klientów którzy w specyfikacjach systemów internetowych umieszczają mniejwiecej takie sformułowanie:

“Wszelkie teksty, opisy, materiały [tutaj mamy wyliczanke - przyp. aut.] muszą być edytowalne przez nie techniczny personel firmy. Dodatkowo edycja powinna być równie prosta co obsługa typowego edytora tekstu.”

Jest to oczywiste stwierdzenie że Klient oczekuje wdrożenia systemu CMS. Jednak zazwyczaj pojawia się kilka aspektów które przemawiają za tym aby tego nie robić. Troche będe generalizował, ale zazwyczaj się one sprawdzają:

1. Klienci tak na prawde rzadko uaktualniają strony
2. Klienci przywiązują zbytnią wagę do formy a nie treści
3. Klient nawet po otrzymaniu bardzo dobrego systemu CMS, zleci jego obsługę pracownikom technicznym.
4. Koszt wdrożenia dobrego systemu CMS jest wysoki w stosunku do korzyści.

Jednak te argumenty zazwyczaj nie docierają do Klientów. Jest to spowodowane tym że posiadanie CMS jest trendy. Praktycznie każda firma wdrażająca systemy internetowe, zaczyna prezentacje swoich produktów od pokazania ładnego, “Wordowego” edytora i opowiadania jakie to jest cudowne narzędzie. Natomiast nikt nie mówi o wadach tych rozwiązań.

Aby lepiej zrozumieć istotę problemu i dlaczego Klientom tak bardzo zależy na posiadniu systemu zarządzania trescią (oprócz tego że jest to trendy) musimy się trochę cofnąć w czasie.

Zamieszchłe czasy zarządzania stronami

Po tym jak wszelkiej maści specjaliści od marketingu poznali możliwości internetu, zaraz chcieli umieszczać wszystkie swoje pomysły w sieci. Jednak trafili na “drobny” opór - powiedziałbym że techniczny. Mianowicie ich wiedza nie pozwalała im na samodzielne tworzenie i zarządzanie stronami. Jeżeli chcieli cokolwiek zmienić na stronie czy coś dodać musieli zwracać się z prośbą do informatyka lub też zewnętrznej firmy. Pewnie nie było by w tym nic złego gdyby nie fakt że zaraz po publikacji nowej treści była ona wielokrotnie zmieniana. Niestety Klienci bardzo często werbalizują swoje potrzeby dopiero jak coś zostanie wykonane i pokazane.
Dodatkowo pojawiały się błędy wynikające z niezrozumienia (typu.: “Logo miało być pod zdjęciem a nie nad”). Powodowało to zarówno frustrację webmasterów którzy musieli kilkakrotnie wykonywać tą samą pracę jak i specjalistów od marketingu których pomysły nie zawsze były realizowane zgodnie z ich założeniami.

Jednak wraz z rozwojem technologii, pojawiły się narzędzia pozwalające na prostą edycję stron WWW.

A wszystko zaczeło się od FrontPage…

Jednym z pierwszych edytorów WYSIWYG był Microsoft FrontPage - pozwalał on na stosunkowo prostą edycję materiałów na stronach WWW. Nie tylko pojedyńczych podstron ale także całych witryn. Użytkownik mógł sobie “wyklikać” całą strone - na dodatek odrazu widział jak to będzie wyglądać.
Niestety cena wygody była wielka. Po pierwsze: kod HTML generowany przez niego był koszmarny. Nie dość że nie trzymał się żadnych standardów to dodatkowo był nadmiernie
obszerny. Po drugie: kod wygenerowany przez FrontPage’a działał praktycznie tylko w Internet Explorerze.
Wielu firmom / osobom jednak powyższe wady nie przeszkadzały i rozpoczeła się “mania klikalnego tworzenia stron”.

FronPage był jednak osobnym produktem i pozwalał tylko na edycję statycznych stron. Rozwiązaniem stały się edytory “osadzane” na stronach WWW. Zazwyczaj są napisane w języku JavaScript choć zdażają się także rozwiązania jako ActiveX oraz aplety Java.

Ich zaletą była możliwość łatwej integracji z formularzami WWW.

Rodzą sie CMSy

Systemy zarządzania trescią powstały razem z dynamicznymi stronami WWW. Początkowo nie miały służyć bezpośrednio Klientom - ułatwiały prace webmasterom którzy nie musieli tworzyć setek plików które przy każdej zmianie trzeba było edytować.

Jednak skoro można już było zintegrować prosty edytor z formularzem na stronie WWW, to już nie wiele więcej wysiłku kosztowało programistów napisanie systemu który pozwalał by zarówno na edytowanie treści jak i ich proste dodawanie. Systemy zarządzania treścią zaczeły pojawiać się masowo na rynku. Ponieważ na rynku najważniejszy jest Klient, większość z nich poszła w jego stronę maksymalnie uproszczając wszelkie czynność - nie wymagały one juz żadnej specjalistycznej wiedzy.

Święty gral czy przekleństwo ?

Takich możliwości brakowało działom marketingu. Każdy teraz chce mieć CMS do strony (który częstokroć jest dużo droższy niż stworzenie strony i jej aktualizacja przez zewnętrzną firmę) wraz z edytorem WYSIWYG.

Żadne argumenty nie potrafią odciągnąć Klienta od tego trendu.
Edytory WYSIWYG mają jednak podstawową wadę - pozwalają na stworzenie kodu podobnie koszmarnego, jak kod wygenerowany przez FrontPage’a, który jest zupełnie nie zgodny ze standardami W3C.

Kod takiej strony szybko rozrastał się i powodował jej wolne ładowanie. Pozatym Klient nie obeznany w tajnikach budowy stron może dzięki takiemu edytorowi spowodować całkowite “rozlecenie” się layoutu poprzez złe wstawienie różnych elementów (np.: za dużej grafiki, czy też źle sformatowanej tabelki).

Dodatkowo taka strona ma bardzo duże szanse być źle oceniona przez Google (ze względu na niekorzystny stosunek treści do kodu HTML)

Może podejść do tego inaczej…

WYSIWG to moim zdaniem zła droga. Zaproponuje inne roziwązanie które uważam za całkowicie wystarczające dla większości Klientów.
Jest one jednak troche trudniejsze w implementacji, jednak pozwala na zachowanie zarówno dobrej funkcjonalności oraz zgodności ze standardami.

Polega ona na opracowaniu zestawu znaczników, którymi będą musieli się posługiwać Klienci podczas edycji tekstu. Chcąć pogrubić tekst będą musieli napisać przykładowo

{BOLD}tekst{KONIEC_BOLD}

poźniej takie znaczniki będą odpowiednio interpertowane przez oprogramowanie i przekształcane do HTMLa.

Zalety są następujące:

1. Klient wstawi kodu na który mu nie pozwolimy
2. “Rozlecenie” się layoutu jest zminimalizowane
3. Kod nie będzie się rozrastał i pozostanie zgodny ze specyfikacją

Stosując jednak to rozwiązanie, należy pamietać o umieszczeniu gdzieś przy edytorze “sciągawki” dzięki której Klient będzie mógł podejżeć zestaw znaczników i efekty ich użycia.

Na tależu…

Nie trzeba odkrywać koła na nowo. Istnieją już gotowe narzędzia do obsługi mechanizmu który zaproponowałem. Moim faworytem jest Textile - można łatwo się do niego przyzwyczaić oraz istnieją już gotowe klasy do obsługi tego formatu w wielu językach. Kolejnym formatem którego można użyć jest BBCode. Jest to standard używany w dość popularnym forum phpBB. Niestety nie wiem czy isnieją gotowe implementacje interpertatora dla innych języków.

Istnieją także inne gotowe formaty, jednak bardziej chodziło mi o pokazanie wad WYSIWYG i możliwości zastąpienia ich prostszymi (bardzo często lepszymi) mechanizmami.

Czasami zdarza się że aplikacja FastCGI działająca w jednym miejscu, po odpaleniu nowej instancji w nowej lokalizacji (zwłaszcza w środowiskach unixowych) zupełnie przestaje działać. W logach często pojawia się dość niezrozumiały komunikat:

FastCGI: incomplete headers (35 bytes) received from server

który nie jest zbyt pomocny podczas rozwiązywania problemu, zaś w samej przeglądarce zazwyczaj zobaczymy

500 Internal Server Error

Oto kilka możliwych przyczyn powyższego stanu rzeczy:

1. Uprawnienia do plików/katalogów używanych w aplikacji. Często zdaża się że pozwalamy na zapis procesowi FastCGI do jakiegoś katalogu (np.: logs) i brak dostępu może powodować problem. Najprosciej zweryfikować ten problem tworząc testową instancję aplikacji w której zmodyfikujemy uprawnienia w ten sposób, aby każdy użytkownik mogł nadpisać dowolny plik. Jeżeli aplikacja wystartuje to sprawa jest jasna - problemem są uprawnienia
2. Jest zbliżony do powyższego problemu, ale trudniejszy w diagnozie. Problem polega na złych uprawnieniach ale do plików sesji głownie w sytuacji kiedy pierwsza instancja pracuje z prawami użytkownika X zaś druga z prawami Y. Aplikacje zazwyczaj używają cookies do przekazywania sesji - przełączenie pomiędzy instancjami może spowodować konflikt, polegający na próbie otworzenia pliku utworzonego przez użytkownika X przez inną instancję. Rozwiązaniem częściowym jest wyczyszczenie wszystkich plików sesji, natomiast podobna kolizja może wystąpić w przyszłości. Właściwym rozwiązaniem tego problemu jest uwtorzenie w każdej instancji aplikacji katalogu w którym będziemy umieszczali pliki sesji. Ewentualnie mozna użyć innego sposobu przechowywania sesji niż pliki (np.: w bazie danych)

Napewno powodów może być więcej, jednak dwa powyższe są nagminne. Drugi zaś potrafi być bardzo absorbujący i trudny do wychwycenia - mam nadzieję że komuś to oszczędzi troche czasu.

Graficzne maile, czyli takie w których główną formę przekazu stanowi obraz, są wręcz uwielbiane przez wszelkiego rodzaju specjalistów od marketingu. Zwłaszcza jeżeli mają służyć do wysyłania firmowego newslettera.
Nie uważam że wysyłanie “graficznych” czy “htmlowych” maili jest słuszne. Jeżeli już musisz (czyt. szef wydał takie zalecenie pod rygorem zwolnienia z pracy), to przynajmniej zastosuj się do moich rad.

Oto one:

Zastosuj prosty i czytelny layout oparty na CSS. Nie używaj tabelek. Używając CSS zwiększasz szanse na przeczytanie wiadmości przez osoby, które nie akceptują maili w HTMLu bądź mają wyłączone niektóre elementy ich dotyczące.

Nie osadzaj obrazków przy pomocy tagu “img”. Zamiast tego zastosuj podkład w CSS. Dzięki temu, jeżeli ktoś nie pobiera obrazków dalej będzie miał czytelną wiadomość. Dodatkowo unikniesz wyświetlania błędu pobierania obrazka jak to ma miejsce w przypadku niektórych blokad w Outlook Expressie.

Jeżeli potrzebujesz skorzystać z obrazków, nie załączaj ich do wiadomości. W CSS ustaw aby były sciągane z firmowego serwera WWW np.: background-image: url(http://www.firma.pl/newsletter03/img/obrazek.jpg) .

Zwróć uwagę na typografię. Używaj nagłówków, paragrafów. Sformatuj tekst w taki sposób, aby był czytelny bez layoutu.

Jeżeli zastosujesz się do powyższych rad, Twój “graficzny” mail będzie czytelniejszy, zgodny ze standardami, oraz nie będzie sprawiał problemów użytkownikom którzy nie preferując pięknych graficznie, a wnoszących mało treści emaili.

Przy okazji mojego pobytu w zeszły weekend w Krakowie (z okazji “Nocy linuksożerców“), zostałem poproszony o wygłoszenie prezentacji na temat baz danych. Przed wykładem nie wiedziałem z jaką publiką będe miał doczynienia - jedyna informację jako otrzymałem było że “większość grupy nie jest informatykami”.

Po przyjechaniu na miejsce ( i oporządzeniu się po 20 min. spóźnieniu) szybko przystąpiłem do prezentacji. Okazało się że wykład był prowadzony dla słuchaczy studiów podyplomowych. Ucieszyłem się niezmiernie, ponieważ nie ma nic gorszego niż grupa studentów którzy chcąc, nie chcąc wykład “odbębnić” muszą.

Tutaj sytuacja wyglądała zupełnie inaczej. Grupa reagowała na moje błędy i potknięcia (co oznaczało że słuchali :). Co ważniejsze mogliśmy dyskutować o realnych problemach i procesach z którymi spotykają się w swojej pracy. Dla typowego studenta nie ma większej różnicy między fakturą proforma a fakturą VAT. Dla tych ludzi, którzy od jakiegoś czasu pracują róźnica jest zauważalna odrazu. Dzięki temu nie musiałem się odnośić do jakiegoś wysokiego poziomu abstrakcji w tłumaczeniu, jak to miałem zwyczaj czynić w przypadku wykładów dla studentów.

Nie wiem jak słuchaczy, ale dla mnie wykład ten był bardzo ciekawy. Prawdopodobnie była to zasługa tego że Ci ludzie przyszli tam z własnej woli i chęci nauki, a nie dlatego że “ktoś im kazał”.

Podejżewam że moje wykłady będą znacznie ciekawsze jeżeli będę miał okazje prowadzić je takich grup jak tamta.

Co zaś tyczy się studentów: nie dziwcie się że wykładowca prowadzi “opornie” zajęcia jeżeli widzi że nikogo to nie interesuje. Zamiast ciekawej prezentacji jest zmuszony do prowadzenia nudnego, oderwanego od rzeczywistości “przemówienia”