Wpisy w kategorii 'Standardy sieciowe'
Czasem nie można polegać na aktywnym JavaScripcie - niektóre osoby wyłączają skrypty domyślnie, gdyż zbyt obciążają łącze. Ma to sens choćby w komórkach, gdzie ‘zassanie’ jakiegoś większego skryptu potrafi mocno opóźnić załadowanie się całej strony. Między innymi dlatego podczas tworzenia serwisów warto stosować nieinwazyjny JavaScript (z ang. unobtrusive). Jednakże, cały czas można spotkać osoby, które nie widzą potrzeby w stosowaniu takiego podejścia. W końcu dużo prościej jest założyć, że wszyscy mają pełne wsparcie JavaScriptu - któż się nie spotkał z argumentem, że dla kilku % użytkowników bez tego wsparcia nie warto się wysilać… Na szczęście przybywa osób widzących w nieinwazyjnym JavaScripcie coś więcej niż tylko nośne hasło - osobom nieobeznanym z tym zjawiskiem proponuję kilka zasad składających się na jego charakterystykę.
- Należy unikać błędnych założeń - warto przetestować gotowy serwis przy wyłączonym JavaScripcie, a jeśli coś działa niepoprawnie, to jest to wynik błędnego założenia, że wszyscy mają aktywny JavaScript w swojej przeglądarce;
- Należy logicznie zaprojektować kod HTML - warto przed lub w czasie kodowania zaplanować wszelkie możliwe relacje elementów kodu HTML z JavaScriptem, co pozwoli na łatwe ‘zaczepienie’ skryptu o wybrany element struktury strony;
- Należy unikać rozdętych skryptów - warto używać CSS tam, gdzie jest to możliwe; trawersowanie drzewa dokumentu z użyciem JavaScriptu jest wolniejsze i często zbędne, szczególnie jeśli chodzi tylko o aspekt wizualny danego elementu;
- Należy zrozumieć zarówno przeglądarki, jak i użytkowników - warto zastanowić się czy wielkie możliwości, jakie oferuje JavaScript nie stoją w sprzeczności z możliwościami przeglądarek, jak również z potrzebami użytkowników; bywa, że przy wyłączonym JavaScripcie ‘przebajerzone’ interfejsy po prostu zawodzą;
- Należy pojąć naturę zdarzeń - warto zagłębić się w dokumentację JavaScriptu i ze zrozumieniem stosować obsługę zdarzeń (z ang. event handling), co pozwoli w pełni odseparować skrypty od kodu HTML;
- Należy unikać konfliktów - warto zastanowić się czy zastosowanie dwóch różnych bibliotek/skryptów nie spowoduje błędów w działaniu całego serwisu internetowego; warto też optymalizować już istniejący kod;
- Należy brać pod uwagę przyszłość serwisu - warto pisać skrypty tak, aby kolejny koder lub programista nie mieli problemu z rozeznaniem się w zastanych zapisach (komentarze - choćby bardzo ogólne - są rzeczą niezwykle cenną).
Mam nadzieję, że powyższe zasady pozwolą zrozumieć sens planowania i tworzenia nieinwazyjnego JavaScriptu. Dzięki temu końcowe serwisy internetowe mogą powstawać szybciej, charakteryzować się większą jakością i być łatwiejsze w utrzymaniu. Więcej na temat dobrych praktyk związanych z nieinwazyjnym JavaScriptem do znalezienia w artykule Christiana Heilmanna, który jest niekwestionowanym autorytetem w tej dziedzinie.
{griter}
wtorek, 20 maj, 2008
Do góry
Wokół prac związanych z HTML 5 narosło wiele niedopowiedzeń lub błędnych interpretacji związanych ze specyfikacją tego standardu. Jedną z niewiadomych jest dla wielu osób składnia tego języka. Jak jest naprawdę? - ano HTML 5 może być tworzony zarówno jako zwykły hthml, jak i XML…
Specyfikacja HTML 5 jest charakterystyką słownictwa, które może być opisane za pomocą dwóch różnych składni (html lub XML) zależnie od potrzeb programistycznych, produktowych i finalnie rynkowych. Poprzednie wersje słownictwa HTML (HTML+, HTML 2.0, HTML 3.2) były napisane przy użyciu zasad składni SGML. HTML 4 posiada już dwie składnie: SGML (nazywana HTML 4.01) oraz XML (nazywana XHTML 1.0).
HTML 5 jest tworzony w oparciu o dwie składnie: html oraz XML. Ponieważ składnia SGML nigdy nie miała odpowiedniego wsparcia w przeglądarkach oraz narzędziach wspomagających pisanie kodu, to HTML 5 definiuje nową serializację zwaną html, która ma wiele wspólnego ze składnią znaną wcześniej jako SGML. Poniżej rysunek obrazujący tę dwoistość HTML 5 (koncepcja autorstwa Jamesa Grahama):

{griter} - w oparciu o artykuł zamieszczony na blogu W3C.org
sobota, 19 styczeń, 2008
Do góry
Mniemam, że czas najwyższy coś napisać - brak czasu nie usprawiedliwia braku nowych wpisów ;)
Wiele osób uważa, że pierwsza wersja CSS była czymś przełomowym - trudno się z tym nie zgodzić. Druga wersja CSS została przyjęta już nieco chłodniej - wytykano brak spójnej wizji dalszego rozwoju tego standardu. Czas płynie szybko i w 10 lat po narodzinach CSS krystalizuje się wersja numer trzy. W środowisku można słyszeć zarówno głosy poparcia, jak i krytyki (przeważające). I tak, przeglądając przepastne połacie blogosfery, natrafiłem na bardzo ciekawy głos w sprawie ewolucji CSS - mocno krytyczny…
Chodzi mi o świetny artykuł Alexa Russella. Uważa on, iż tak istotne kwestie jak dziedziczenie zapisów i możliwość tworzenia własnych zmiennych powinny być już ujęte w CSS 2. Okazuje się, że w wersji roboczej CSS 3 również tych zagadnień nie znajdziemy - w zamian osoby pracujące nad rozwojem CSS skupiają się na mniej ambitnych celach. Faktem jest, że na chwilę obecną kwestia dziedziczenia jest mocno zaniedbana, choć w jakiejś formie (selektory potomne) CSS sobie z tym radzi… Jednakże, często narzuca się, aby zaimportować do jakiejś klasy inną - wcześniej zdefiniowaną o uniwersalnym charakterze. Niestety takiego mieszania klas zrobić się nie da - pozostaje mozolne dopisanie wartości, co niewątpliwie wpływa na puchnięcie całego kodu.
Idąc dalej tym tropem Alex proponuje jeszcze jedną ciekawą rzecz - definiowanie zmiennych. Wcześniejsze ustalenie zmiennych globalnych - np. koloru czcionki lub tła - pozwoliłoby na ponowne odchudzenie kodu i na dużo łatwiejszą edycję całości. Wystarczy przecież wyedytować zmienne, aby efekt tych zmian był widoczny w całym arkuszu i na stronie. Jest to inicjatywa ze wszech miar słuszna i nie pozostaje mi nic innego jak tylko jej przyklasnąć. Wypada mieć nadzieję, że presja środowiska będzie mieć dobroczynny wpływ na członków grupy roboczej CSS.
{griter}
niedziela, 30 wrzesień, 2007
Do góry
Wszyscy mamy problem z promowaniem standardów sieciowych, jako że nasi klienci nie są zazwyczaj nimi zainteresowani.
To dosyć frustrujące, kiedy kogoś zupełnie nie obchodzi to, co dla nas jest pasją. Wraz ze wzrostem doświadczenia staje się to bardziej znośne, lecz nie jest to rozwiązanie problemu. Cały wysiłek i energia włożona w promowanie jakiejś technologii względem osoby nie mającej z tą technologia niewiele wspólnego można zaoszczędzić dzięki bardziej pragmatycznemu podejściu: należy wyjaśniać o ile więcej pieniędzy można zarobić dzięki witrynie zgodnej ze standardami sieciowymi.
Innymi słowy, sposobem na odniesienie sukcesu u klienta nie jest rozprawianie o kwestiach technicznych, lecz pokazanie mu stosu złotych sztabek. Pytając przy tym “chciałby Pan kilka dla siebie?”…
Zrozumienie podstaw
Pierwsza rzecz, jaką powinno się wyjaśnić potencjalnemu klientowi, to że nie musi sam robić swojej witryny. Po drugie - ważnym jest, aby efekt Twoich działań względem klienta był długotrwały i dostrzegalny przez innych.
Istnieje kilka ważnych aspektów dotyczących budowy stron i aplikacji internetowych, o których trzeba wspomnieć na początek. Nawet dzięki nieustannej walidacji nie pozbędziemy się fundamentalnych błędów spowodowanych bałaganem na starcie. Z drugiej strony, witryny uporządkowane i odnoszące sukces mogą mimo to mieć bardzo długą drogę do pełnej zgodności ze standardami (jak np. Amazon, czy też Google).
Dobre wzornictwo
Są ludzie tacy jak Douglas Bowman (Stopdesign), ale jest również wielu utalentowanych grafików, którzy nie mają pojęcia czym są standardy sieciowe - wystarczy zobaczyć jak wielu fachowców od Flasha działa na rynku. Należy dać klientowi znać o swoich umiejętnościach artystycznych i wiedzy pozwalającej na tworzenie zachwycających projektów. Portfolio powinno mówić samo za siebie…
Rozsądna architektura informacji
Witryna o właściwie rozplanowanej strukturze dostarcza informacji tam, gdzie i kiedy jest to konieczne. Projektując strukturę witryny należy pokazać klientowi jak wielką przykłada się wagę do jego wymagań i celów; należy dać mu znać, że jego witryna będzie zbudowana na solidnym fundamencie. Dobre studia przypadku mogą się tu okazać całkiem pomocne.
Zorientowanie na użytkownika
Tworzenie satysfakcjonującego i zapadającego w pamięć zjawiska sieciowego polega na wyobrażeniu sobie jak dana witryna ma oddziaływać na użytkownika. Kiedy wymagania użytkownika są stawiane na pierwszym miejscu w procesie projektowania już na starcie, to wtedy końcowym efektem jest witryna, gdzie znalezienie informacji jest szybsze, kupowanie produktów łatwiejsze, a komunikacja bardziej efektywna. Bądź osobą zorientowaną na użytkownika w swoim podejściu do projektowania graficznego; objaśnij swoje podejście klientowi; dodaj nieco referencji dla lepszego efektu.
Hej, jest tego więcej…
Przedstawiaj standardy sieciowe jako sposób na wyróżnienie się, w rozumieniu kreowania przewagi konkurencyjnej. Zacznij opisywać korzyści płynące z używania standardów sieciowych i czym mogą się one stać w przyszłości.
Więcej użytkowników
Strony tworzone w zgodzie ze standardami sieciowymi są dostępne i niezależne od urządzeń, na jakich się je ogląda, a więc są świetnym sposobem na komunikowanie się z większą ilością osób - łatwo i oszczędnie.
Wyjaśnij dlaczego dostępność jest ważna - jest coraz bardziej poważana przez prawo, istotny jest aspekt etyczny oraz pozytywny wydźwięk biznesowy, jaki można dzięki niej osiągnąć.
Warto uwypuklić to zagadnienie - pokaż czym naprawdę jest niezależność sprzętowa; weź swoją komórkę i pokaż stronę zrobioną przez ciebie. Pokaż jak bardzo jest dostępna i zaznacz, że dzięki standardom sieciowym ich witryna może mieć podobne właściwości bez niepotrzebnego zwiększania wydatków.
Być widocznym
Wyszukiwarki kochają strony tworzone ze standardami sieciowymi. Jeśli zawartość strony będzie poprawna semantycznie, to nie ma potrzeby odszyfrowywania kodu źródłowego strony celem wyjaśnienia czegokolwiek. Wyjaśnij klientowi korzyści płynące z SEO (statystki są po Twojej stronie) i wspomnij, że stanowi to nieodzowną część twojej oferty.
Uszczęśliwiać użytkowników
Zgodne ze standardami strony są lżejsze i szybciej się ładują. Są dużo bardziej przyjazne dla użytkowników mających wolne łącze internetowe, bądź też używających niestandardowych platform. Standardy sieciowe wzmacniają doznania użytkownika - Twój klient nie może się oprzeć wizji szczęśliwych użytkowników…
Mniejsze koszty hostingu
Ponieważ strony są lżejsze, to są mniejszym obciążeniem transferowym dla serwerów. Wyjaśnij klientowi, że dzięki stronom zgodnym ze standardami można uzyskać 25%-50% redukcję wagi danej strony, co w rezultacie daje podobną redukcję w transferze danych. Twoje rozwiązanie serwuje użytkownikom tą samą zawartość, acz przyrządzoną dużo lepiej niż miałoby to miejsce w przypadku stron opartych na tabelkach.
Bezproblemowe utrzymanie witryny
Powodem jest odseparowanie struktury od warstwy prezentacyjnej, ale powiedz to łagodnie - dzięki standardom sieciowym zmiana warstwy prezentacyjnej witryny jest dużo prostsza niż w przypadku metod wziętych ze starej szkoły. Nadmień, iż proces ten zabiera mało czasu, co przekłada się na mniejsze wydatki związane z aktualizacją. Projekty z CSS Zen Garden będą tu dobrą ilustracją.
Brak zmartwień względem przyszłości
Najlepsze witryny rosną i rozwijają się - witryna Twego klienta także tego doświadczy. Planowanie wzrostu, czy też ekspansji jest łatwiejsze ze standardami sieciowymi. Właśnie po to są standardy - zapewniają pełną operacyjność i skalowalność. Gdy nadchodzi nieunikniona potrzeba ekspansji, Twój klient będzie miał mniej zmartwień i mniej wydatków mając witrynę zgodną ze standardami. Upewnij się, że on również wie o tym fakcie…
Więcej elastyczności - mniej ograniczeń
Ponieważ Twoje rozwiązania są zgodne ze standardami, Twój klient będzie mniej zależny od Ciebie. Ma większą elastyczność przy wyborze firmy mającej się zająć ta samą witryną w przyszłości. Daj znać klientowi, ze jesteś przeciwnikiem ograniczenia się do jednego wykonawcy. Dzięki temu staniesz się bardziej człowiekiem, niż dostawcą rozwiązań internetowych. Ciesz się z dobrego wrażenia jakie wywarłeś na kliencie - przy następnym zleceniu zapewne sobie o Tobie przypomni.
Tak więc czym są standardy sieciowe
To podchwytliwe pytanie. Będziesz naciskany, aby dać wykład o naszej misji odzyskiwania sieci. Nie ulegaj pokusie - bądź zwięzły i rzeczowy, pozostając przy tym z dala od detali technicznych. Mów obrazowo wymieniając podstawowe fakty:
- standardy są podwaliną sukcesu Internetu;
- rozwijane przez ekspertów przy wkładzie całej społeczności internetowej;
- publikowane przez W3C, IETF, ISO itp.;
- zapewniają solidny fundament pod rozwojowe i wydajne aplikacje;
- np.: XHTML, CSS, RSS…
Wspomnij o istniejących online aplikacjach umożliwiających testowanie kodu (XHTML i CSS) oraz dostępności. Pozwól swemu klientowi pobawić się nimi trochę.
Jeśli klient nie ma wiedzy technicznej, to właściwie wszystko co powinien wiedzieć o standardach sieciowych. Od teraz powinien wszystko przeliczyć na złotówki, które może zaoszczędzić, myśląc jednocześnie o potencjalnych klientach serfujących po sieci za pośrednictwem swoich komórek.
Jeśli klient posiada wiedzę techniczną lub w rozmowie uczestniczy pracownik z działu IT zaznacz, że możesz wyjaśnić czym są standardy sieciowe w szczegółach. Jeśli zechcą posłuchać Twoich wywodów, to jesteś szczęśliwcem - śmiało, zanudź ich na śmierć mówiąc o XHTML, CSS, W3C i WaSP…
{Prabhath Sirisena}
PS: Tłumaczenie artykułu i publikacja za zgodą autora…
niedziela, 25 luty, 2007
Do góry
Czas jakiś temu Ben Henicek napisał na łamach A List Apart świetny artykuł, w którym stara się przekonać do standardów sieciowych tych, którzy przekonani jeszcze do nich nie są – argumenty są dosyć ciekawe, jako że autor opiera się w swoich wywodach na własnych doświadczeniach w tym zakresie. Jak sam pisze, przejście z tworzenia stron na bazie tabel na rzecz CSS zajęło mu ponad dwa lata… Rozumie zatem doskonale tych, którzy czują niechęć do CSS – do tych właśnie osób kieruje swoich 12 przykazań. Wnioski z nich płynące prezentuję poniżej:
#1: Wiesz tyle, co nic
Kiedy przychodzi do nauki CSS okazuje się, że wiedza jaką się dotychczas posiadło może się okazać ograniczeniem, a nie wsparciem. Najlepiej więc “wyczyścić” sobie pamięć, zanim przystąpimy do nauki czegoś nowego. Nalezy rozważyć usunięcie na jakiś czas ze słownika słów “ale” i “powinno” na rzecz słów “jak” i “dlaczego” - z pewnością ułatwi to przyswajanie nowej wiedzy. Rzeczą od której warto zacząć, jest zrozumienie podstawowych różnic między układem tabelarycznym a semantycznym:
| Układ tabelaryczny |
Układ semantyczny |
Implikacje |
| Linearny |
Hierarchiczny |
Design wspierający przekaz, a nie zastępujący go. |
| Proceduralny |
Funkcjonalny |
Przypisuje elementom właściwe miejsce. |
| Lokalny |
Kontekstowy |
Niech układ strony zdefiniuje czym jest dany element, zanim ty zdefiniujesz gdzie ma być. |
| Ograniczony |
Otwarty |
Nic na siłę - elastyczne elementy dopasowują się do danej sytuacji i potrzeb użytkownika. |
Nie można rzecz jasna zapominać, iż tabele nadają się znakomicie do prezentacji danych tabelarycznych, toteż całkowite ich odrzucenie nie ma zastosowania - kwestia poznania ograniczeń jakie mają zarówno tabele, jak i CSS.
#2: Różnice istnieją
Istnieje wiele różnic między przeglądarkami - tym samym powoduje to różnice w wyświetlaniu się danej strony. Nie pozostaje zatem nic innego, jak tylko przyzwyczaić się do tej myśli i starać się niwelować te różnice w jak największym stopniu.
#3: Ideały a praktyka
Życie i praca to często sztuka kompromisu - czasem przychodzi wybierać między złym i gorszym rozwiązaniem, a czasem wręcz nie mam się wyboru… Aby uczynić te wybory łatwiejszymi należy nauczyć się efektywnego planowania. Precyzyjny wybór celów danego projektu pozwala na przekonanie innych do naszych argumentów. Przyjdzie nam stoczyć niejedną bitwę o jakieś zagadnienie projektu - jednakże należy się skupiać tylko na tych, które mamy szanse wygrać.
#4: Dążenie do perfekcji
Kod wygląda dobrze nie wtedy, gdy nic już do niego nie trzeba dodać, lecz gdy nic już z niego nie można usunąć… Część osób rezygnując z układu opartego na tabelkach, nie pozbywa się wcale złych nawyków projektując strony z użyciem CSS i XHTML. Objawia się to przesadną ilością elementów blokowych (’divitis’), co czasem prowadzi do tego, że strony oparte na takim koślawym kodzie są trudniejsze w edycji, niż te oparte na tabelkach. Zatem im mniej znaczników, tym lepiej…
#5: Współpraca popłaca
Podczas realizacji projektów - szczególnie tych małych - zdarza się, iż projektowanie graficzne strony jest całkowicie oderwane od jej późniejszej implementacji. Brak współpracy między grafikiem a koderami prowadzi w efekcie do przekroczenia terminu zakończenia prac, co niewątpliwie odbija się również na firmowej kieszeni. Dlatego - jeśli jest to tylko możliwe - należy sklecić dobrze działający zespół ludzki, który będzie realizować projekty całościowo, a nie w rozbiciu na odrębne bloki.
#6: Czas przeglądarek
Liderom rynku przeglądarek w latach 90 (chodzi o IE i Netscape) dostosowanie swoich produktów do przetwarzania tabel zajęło pięć lat. Po wprowadzeniu CSS niewiele się zmieniło - IE wciąż wydaje się być w okolicach roku 1998… Na szczęście są juz inne, lepsze przeglądarki, co nie oznacza że nie należy brać pod uwagę wszystkich. Wynikuje to koniecznością nieustannego porównywania działania stron w przeglądarkach istniejących obecnie na rynku.
#7: Czystość kodu
Jeśli kod danej strony sprawia, że po wyłączeniu CSS nadal będzie można odczytać jej zawartość, to właśnie świadczy o jego wartości. Stosowanie dobrych praktyk przynosi klika korzyści:
- CSS zamiast specjalnych stron dla druku;
- CSS są łatwiejsze w edycji i utrzymaniu;
- kod strony staje się mniej skomplikowany;
- nawigacja za pomocą klawiatury jest prostsza;
- dużo łatwiej zmienić design strony…
#8: Dziedziczność CSS
Złym nawykiem wziętym z układu opartego na tabelach jest konieczność opisania każdego z elementów strony z osobna. Dzięki dziedziczności selektorów w CSS mamy sytuację zupełnie odwrotną. Przypisując jakiemuś elementowi (np. odnośnikom) globalne cechy możemy redukować ilość klas w kodzie strony, o elementach blokowych nie wspominając. W kombinacji z obrazkami tła i innymi właściwościami układu strony CSS pozwala na to, o czym w układzie tabelarycznym mozna było tylko pomarzyć…
#9: CSS hacks
Tak, nIEktóre przeglądarki mają problemy z odczytywaniem CSS. Są na to obejścia - aczkolwiek nie zawsze korzystanie z nich popłaca, o czym świadczy premiera IE7, przeglądarki wymuszającej niejako korzystanie ze specjalnych arkuszów styli (patrz: “Komentarze warunkowe“). Było nie było, umiejętne korzystanie z odpowiednich hacków z pewnością może ułatwić życie.
#10: Zabawa z błędami
Podczas pracy z kodem zdarza się, iż to co w jednej przeglądarce wygląda świetnie, w innej może wyglądać zupełnie inaczej. Sprawdzamy wtedy kod w poszukiwaniu błędu - niestety, często po jego poprawieniu okazuje się, że sytuacja się odwróciła; tam gdzie było dobrze jest źle, a tam gdzie było źle jest dobrze… Takie beznadziejne przypadki potrafią nieźle wkurzyć - na szczęście może się zdarzyć, że ktoś miał już podobne doświadczenia i podzieli się z nami swoją wiedzą. Najczęściej wystarczy odpalić wyszukiwarkę i dobrze poszperać w światowych zasobach Internetu.
#11: Budowanie layoutu
W czasie pracy nad stroną szczególnie układy kolumnowe lubią sprawić niemiłą niespodziankę i spowodować, że rzeczy nie wyglądają tak, jak wyglądać powinny. Coś się rozjeżdża, coś ucieka na dół - standardowe rozterki kodera. Toteż podstawową kwestią jest zdecydowanie się na układ płynny, bądź też na układ statyczny - w sieci można znaleźć wiele gotowych i sprawdzonych rozwiązań dotyczących layoutów. Prawidłowa decyzja plus porządnie napisany CSS mogą nam zaoszczędzić wiele cennego czasu.
#12: Obrazki w tle
Obecna w CSS możliwość przypisania dowolnemu elementowi obrazka w tle jest właściwością nie do przecenienia. Jednym z narzucających się zastosowań obrazków tła jest chociażby podmiana nagłówków w treści strony, dzięki czemu możemy korzystać z uroków wysublimowanej typografii. Również dzięki nim można dobrze symulować zachowanie obramowań - szczególnie dobrze sprawdza się to w układach płynnych. A zastosowań jest dużo, dużo więcej - nic tylko korzystać z nieodpartych uroków CSS…
Inspiracją dla tekstu powyżej był artykuł autorstwa Bena Heniceka napisany dla A List Apart.
{griter}
wtorek, 31 październik, 2006
Do góry
Poprzednie wpisy