Sam używam Fireworks od bardzo dawna – od prototypowania interfejsów po projektowanie stron i mimo wielu prób oraz usilnych starań Adobe by zniechęcić – głównie użytkowników Maków – do programu, wciąż nie znalazłem wygodniejszej alternatywy dla tego programu.

Za możliwość podyskutowania dziękujemy Grześkowi Wolańskiemu – mam nadzieję, że starczy mu zapału do rozkręcania tego. Zapraszam.

Powiązane wpisy:

1. To smutny dzień. Adobe + Macromedia
2. By popular demand – I’m back.
3. Macromedia Studio 8 – wydane!

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

Powiązane wpisy:

1. Pięć rzeczy, których na pewno byście nie chcieli wiedzieć
2. …
3. Co dalej? Dokąd iść, gdzie się zwrócić?

Ponieważ miałem ostatnio kilka serwisów, które trzeba było zoptymalizować, postanowiłem przypomnieć sobie technikę CSS Sprites opisaną przez Dave’a Shea na łamach AListApart. Jeśli ktoś jej nie zna – proponuję się zapoznać. To prosta technika, z korzeniami w świecie gier komputerowych, polegająca na łączeniu wielu plików w graficznych w jeden większy, łatwiejszy w zarządzaniu i zmniejszający ilość zapytań o elementy graficzne.

Niedawno przetestowałem to rozwiązanie w kilku serwisach, które aż prosiły się o optymalizację i trafiłem na ciekawe zachowanie. Ale po kolei. Zakładając, że nasz przeciętny Jan Kowalski, czyta artykuł na ALA po raz pierwszy, skorzysta z zapisu zaproponowanego w artykule:

#panel1b a:hover {
    background: transparent url(test-3.jpg)
    0 -200px no-repeat;}
  #panel2b a:hover {
    background: transparent url(test-3.jpg)
    -96px -200px no-repeat;}
  #panel3b a:hover {
    background: transparent url(test-3.jpg)
    -172px -200px no-repeat;}
  #panel4b a:hover {
    background: transparent url(test-3.jpg)
    -283px -200px no-repeat;}

Puryści i fanatycy optymalizacji już w tym momencie powinni (już możecie) złapać się za głowę. Ale to nie nieoptymalny zapis jest problemem; prawdziwy problem rodzi się, kiedy chcemy skorzystać z tego rozwiązania w serwisie, w którym nasz plik z “duszkami” ma ponad 350kb, przeciętny obiekt wycinany z pliku ma wymiary rzędu 250×160px a takich wycinanek mamy na jednej podstronie około dwudziestu.
W przeciwieństwie do demonstracyjnego pliczku (parę kb) załadowanie takiego potworka chwilę zajmuje i – jak się okazuje – wpływa na sposób budowania strony… w Firefoxie.

Chcieliście napisać: no jasne, że w Internet Explorerze? Właśnie nie. Ten – o dziwo – renderuje stronę tak, jak byśmy chcieli: po załadowaniu pliku, pojawiają się wszystkie elementy graficzne. Od razu. Ale nie w Firefoxie; Firefox wycina je po kawałku tak, jak by nic się nie zmieniło.

Ok, co jest źle z tym zapisem? Przede wszystkim: zupełnie zbędnie powtarza się ten sam kawałek kodu tylko po to, by zmienić jedną/dwie wartości. Deklarację tła i jego powtarzanie możemy przenieść w jedno miejsce tak, by później tylko deklarować co chcemy wyciąć z tego pliku. Poprawniejszy zapis, może wyglądać tak:

#panel1b, #panel2b, #panel3b, #panel4b {
background: url(test-3.jpg);
background-repeat: no-repeat;
}
panel1b {
background-position: 0 -200px;
}

…

I to jest rozwiązanie warte kilka sekund renderowania strony. Firefox nie lubi się z powtarzaniem całej deklaracji ładowanego tła – za każdym razem otwiera plik z grafiką, wycina i wkleja potrzebny fragment wydłużając cały proces w swoistą “nieskończoność”. W moim przypadku, zmieniając deklarację udało mi się zejść z 16-20s renderowania strony (wg YSlow) do 6.

Powiązane wpisy:

1. CSS, Opera i Firefox: Z kamerą wśród przeglądarek (wciąż je psuję)..

Projekty, w których tylko jeden zespół bierze udział w ustaleniach i tylko ten jeden zespół tworzy materiały dla wszystkich podzespołów niżej, wymaga naprawdę dużego doświadczenia, poświęcenia i koncentracji. Niestety, zwykle ten jeden zespół jest do tego najgorzej przygotowany – oczywiście nie zawsze chodzi tu o brak umiejętności. Najczęściej chodzi o brak czasu i zasobów do poprawnego poprowadzenia projektu.

Ten brak czasu zwykle objawia się kiepsko przygotowanymi materiałami i zabawą w buforowany głuchy telefon – informacje i uwagi przekazywane od klienta mają zwykle spóźnienie a w sytuacjach krytycznych, kiedy klient zgłasza problem – zespołom poniżej urządza się piekło, w którym najdrobniejsza kosmetyczna wpadka urasta do rangi końca świata.

A na początku chaosu zwykle stoi jakość przygotowanych projektów – zwykle – graficznych. Te, w sytuacji braku czasu, powstają na zasadzie: strona ma dwanaście unikalnych podstron, my przygotujemy trzy z przykładowymi danymi bo się nam spieszy, wy zróbcie pozostałe dziewięć w oparciu o to, co pokazaliśmy. Resztę materiałów doślemy później.

I choć czasem się udaje, zwykle prowadzi to do problemu: osoby nie biorące udziału w ustaleniach, nie wiedzą wiele ponad to, co zostało przygotowane na makietach/projektach graficznych/spisane w dokumentacji.

Niepełny materiał nie daje poglądu na rozmiar projektu a kwestia przygotowania kolejnych projektów/podstron pokrywa się z pierwszymi  zmianami prowadząc do zatoru komunikacyjnego i utraty kontroli nad realizacją projektu.

To założenie, ta paradoksalna oszczędność paru godzin na początku projektu, niemal zawsze odbija się czkawką pod jego koniec. Góra poprawek rośnie w zastraszającym tempie prowadząc do wewnętrznych starć między grupami, wszystkim się coraz mniej “chce”, a grupa prowadząca obrywa od klienta, którego złość – spotęgowaną – przelewa na podwykonawców.

Paradoksalnie, zwykle takie projekty dobijają szczęśliwie do brzegu. Na końcu pisze się płomienne case study sukcesu, wszyscy się poklepują po plecach choć jeszcze “wczoraj” naliczali sobie kary i zrywali umowy.

Projekty praktycznie zawsze są spóźnione – pytanie czy wolimy potęgować swoją złość i spóźnienie przez brak przygotowania. Jeśli nie – warto poświęcić te parę godzin czy dni więcej, na dokładniejsze przygotowanie materiałów. Wyjdzie to wszystkim stronom na zdrowie, choć na początku będzie się wydawało, że jest inaczej.

Powiązane wpisy:

1. Kiedy pomysły umierają – dlaczego nie warto czekać?
2. Jak zostać dobrym beta testerem
3. Piękną wiosnę mamy tej zimy

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.

Powiązane wpisy:

1. cms.wego.pl – premiera strony
2. Tworzenie stron e-commerce użytecznych i dostępnych dla osób niepełnosprawnych.
3. 10przykazan.com – rok w krótkiej statystyce, i krótko o planach na przyszłość

A tu proszę, szukałem informacji na temat działalności łódzkiego MPK poza Łodzią i trafiłem tam na ankietę właśnie. Pytań nie ma tyle co w Yahoo, ale warto zwrócić uwagę na dwie rzeczy:

Odpowiedzi mamy udzielić w skali sześcio-punktowej, ale możliwości mamy od 0 do 10. Co więcej, podanie innej wartości niż ta, z przedziału 1-6, wyświetla nam prośbę o poprawne wypełnienie ankiety. Wspaniałe!

Swoją drogą, wyniki podawane niżej, wyglądają na równie przemyślane co ilość opcji:

Powiązane wpisy:

1. Yahoo! zatrudnia wróżbitów!
2. Kwiaty zawsze były bezużyteczne
3. Bezużyteczna używalność – nie myl pojęć

Wygląda jednak na to, że Google poważnie zaczyna traktować także wygląd swoich serwisów. Kilka dni temu Doug Bowman potwierdził plotki - jako Visual Design Lead (lepiej brzmi to nietłumaczone)  zajmie się on nadaniem spójnego wyglądu m.in Writely, Page Creator czy Gmail (oraz innych serwisów w rękawie Google).

Nie pozostaje mi nic innego jak pogratulować korporacji, która w pewnym stopniu uprzedziła GC jednym ze swoich nowszych produktów, doskonałego wyboru.

Powiązane wpisy:

1. Google
2. Polskie Getting Real coraz bliżej
3. Google Maps, UFO i Jezus?

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).

Powiązane wpisy:

1. WEGO – Tworzenie interfejsu użytkownika
2. Stopkowy fetysz. Pobieżnie o projektowaniu
3. [WA] A jednak…

Powiązane wpisy:

1. Cała prawda o NBW.
2. Cała prawda..
3. Z przymrużeniem oka: prawda o kobietach…

Czy naprawdę nie da się zrobić nic prostszego i mniej przeładowanego, niż oklepane dwie kolumny?

Kula u nogi – strona domowa

Jeśli przyjąć założenie, że blog jest bezpośrednim potomkiem stron “domowych”, które na początku lat 90tych wyskakiwały w Sieci, to jasnym staje się, dlaczego oprócz notek, otrzymujemy różnego rodzaju “sajdbary” wypełnione informacjami o powiązanych, acz mało ważnych rzeczach w stylu – “mój pies” czy “moja galeria”.

Gdzie podziała się treść?

Dlaczego są to rzeczy mało ważne? Ponieważ wchodzę na bloga, by poczytać coś nowego, coś interesującego – interesuje mnie treść, a nie blogroll, chmura tagów z deli.cio.us (IMHO idiotyczny pomysł) czy feedy RSS. Dlatego to treść powinna być tym, o czym najpierw myślimy, gdy zabieramy się za przeprojektowanie bloga (strony, ale o tym w innym wpisie).

Przeceniony sidebar

Może to za mocno powiedziane, ale jest pewien trend, polegający na wciśnięciu w sidebar wszystkiego, co robiło się w życiu, czym się interesuje, co się czyta, gdzie ma się konto i który antipixel spodobał się najbardziej.

Po co?

Prywatnie, zauważam po sobie, że sidebar, gdy wchodzę na bloga, interesuje mnie najmniej. Jest elementem, który najchętniej bym wyłączył. Jeśli spodoba mi się treść i sposób, w jaki autor pisze – wtedy zobaczę gdzie linkuje i co ma do zaoferowania.

Problem w tym, że sidebar jest z reguły umieszczany po prawej stronie, co sprawia, że najpierw widzę te wszystkie nieinteresujące mnie linki, a dopiero później dostrzegam, że jest na tej stronie coś więcej.

Swoistym przegięciem w moim mniemaniu jest… jeden z moich ulubionych blogów, czyli 456bereastreet.com.

Niedoceniona stopka

Skarbem każdego serwisu są czytelnicy. Choć statystyki odwiedzalności mogą cieszyć, to jednak najważniejszymi użytkownikami, są użytkownicy powracający. Są to ludzie, którzy często czytają Twojego bloga/stronę od początku (topu) do końca (stopki). No właśnie – stopki.

Co oferuje stopka takiemu wiernemu czytelnikowi? Ano – nic. Informację o “prawach autorskich”, ewentualny link “powrót do góry” i to w sumie wszystko.

A gdyby tak wrzucić w stopkę te zbędne informacje, takie jak listę kategorii, archiwum czy blogroll? Może fotki z flickr’a?

Nie ma się co obawiać, że ktoś przegapi informacje zawarte w takiej stopce – odpowiednio przygotowana, może być nawet bardziej interesująca niż pasek boczny, zawierający te same informacje.

Z blogów, które realizują ten pomysł, wartym zwrócenia uwagi jest blog Garretta Dimona. Z polskich blogów, które czasem podglądam, bardzo bliskim mojemu wyobrażeniu ideału, jest blog YaaL.

Podsumowując

Przeładowane układy dwu-trzy kolumnowe na pewno nie wyginą – wszak dla wielu, blog to jedyna szansa, by zaprezentować swoją wiedzę i umiejętności. A reszta? Cóż, gdy pomyślicie o redesignie stron (niekoniecznie bloga) – spójrzcie przychylniej na niepozorną stopkę.

PS. Powrót do pisania po dłuższej przerwie boli.

Powiązane wpisy:

1. Nowe, odświeżone i działające 10przykazan.com
2. Budowanie ankiet – jak tego nie robić
3. Blogi – sława, kobiety, reklamy i zapach pieniędzy