nbw: Redefine the undefined

Ludzie potrafią przewijać strony w dół… ommm… Ludzie potrafią przewijać strony w dół… ommm.. Ludzie naprawdę potrafią przewijać strony w dół… ommm…

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.

W życiu każdego popularnego serwisu internetowego przychodzi czas, kiedy należy zabrać się za jego optymalizację. Zwykle dokupuje się dodatkowe serwery, wpina memcache, optymalizuje kod serwisu i zapytania do bazy danych. Frontend jest zwykle pomijany, choć w rzeczywistości, optymalizując szablony, można uzyskać całkiem niezłe wyniki relatywnie niskim nakładem sił i środków.

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.

Nie chodzi o możliwości, kod czy rozwiązania. Grono kopiuje lepiej bądź gorzej, ale też nie można nie przyznać, że trochę dobrego chłopaki i dziewczyny z tego projektu zrobili.

To, z czym kompletnie sobie nie radz,ą to zarządzanie informacją. To PR. Jest hype a grono milczy. Od razu przypomina mi się ten obrazek:

z xkcd

Jak kilka słów może diametralnie odmienić sens wypowiedzi, dowiedzieć możemy się z tekstu Microsoft: 2400 stron jest niekompatybilnych z najnowszym IE na Gazeta Technologie.

Czytając, uświadmiamy sobie, że nadchodzi apokalipsa a Microsoft znów jest tym złym, który jeszcze śmie mówić, że tysiące stron w Internecie jest niekompatybilna z jego najnowszym produktem, kiedy to sam, przez lata, olewał standardy. Chciałoby się powiedzieć: standard. Chwytliwy tytuł jest, sensacja w treści jest, popularność leci, wierszówka też i wszystko dobrze. Ale wystarczy zajrzeć na stronę ZDNet na którą powołuje się autor artykułu, by zauważyć, że pozwolono sobie na pewne “semantyczne nadużycie”. W oryginale wspomina się bowiem o IE8 w trybie “standards-mode”, który łamie kompatybilność ze starszymi wersjami IE.

Jak wiemy, Microsoft chce nadgonić stracony czas i IE8 ma zawierać całą masę poprawek w sposobie renderowania stron zgodnych ze standardami, by w końcu przestać być utożsamianym z najbardziej problematyczną przeglądarką na rynku. Poprawienie setek błędów, które przez lata zostały uznane za standardowe zachowanie oznacza, że większość (jeśli nie wszystkie) haki na IE w IE8 przestaną działać co z kolei oznacza, że jeśli strona została źle zaprojektowana – prawdopodobnie rozpadnie się w mniej lub bardziej efektowny sposób.

Dlatego została opublikowana lista stron “niekompatybilnych”, którą można pobrać i zainstalować w IE. Jeśli zdecydujemy się na instalację i wejdziemy na “problematyczną stronę” – IE8 wyrenderuje ją w sposób zgodny z IE7.

Chcąc liczyć się na rynku przeglądarek, Microsoft musiał zdecydować się na lepszą obsługę standardów, nawet kosztem zerwania kompatybilności ze starszymi wydaniami IE.
Lista kompatybilności to dobry kompromis a dodatkowo także autorzy stron mogą powiedzieć – na przykład, za pomocą dyskusyjnego tagu X-UA-Compatibile – IE8, że nie mają czasu by odgruzowywać kod i usuwać haki, więc niech będzie tak miły i grzecznie pokaże stronę jak IE7.

Do całej sprawy odniesiono się także na oficjalnym blogu IE, podając “po prostu fakty” w notce: Just The Facts: Recap of Compatibility View, z której dowiemy się więcej na temat problemu, z perspektywy tych, którzy IE8 tworzą.

• Microsoft’s IE 8 incompatibility list: 2,400 major sites (and counting)
• Just The Facts: Recap of Compatibility View
• Microsoft: 2400 stron jest niekompatybilnych z najnowszym IE

Projekty realizowane w ramach wspołpracy między firmami (podwykonawcami), są już w założeniu bardzo ryzykownymi i trudnymi przedsięwzięciami.

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.

Polubiłem Internet Explorer 7 od samego początku – większość błędów z którymi trzeba się użerać w IE6 jest załatana co czyni pracę kodera zdecydowanie łatwiejszą.

Pojawiło się jednak parę nowych problemów, w tym takie, które nie istniały w IE6. Dwa dni temu spotkałem się z ciekawym błędem dotyczącym nadawania z-index elementom.

W wielkim skrócie, chodzi o to, że IE7 nie potrafi zmienić raz zadeklarowanego z-index dla elementu. Nie działa nawet !important.

Na przykład, mamy dwa divy, z których jeden ma zasłaniać drugi w momencie najechania na niego kursorem myszy.

div {
  ...jakiś kod... ...position: itd...
  z-index: 0;
}
div:hover {
  z-index: 1;
}

Taki zapis zadziała w większości normalnych przeglądarek, a nawet w IE6 (z whatever:hover). W IE7 natomiast nie. Element <div> w IE7 w stanie :hover wciąż ma z-index: 0.

z-index zmienić można, za pomocą Javascript. Zadziała nawet najgłupsze onomouseover="this.style.zIndex='1';".

PS. Jak się okazało inni też wiedzą o tym błędzie.