Skocz do: nawigacji lub treści
Jak co roku, A List Apart opublikowała ankietę podobną do tej, którą ja organizowałem tutaj, dotyczącej zarobków i ogólnej sytuacji w webdesignie i webdevelopmencie. Ja (jak co roku) wypełniłem, wysłałem i czuję, że spełniłem „obywatelski obowiązek”, dlatego też zapraszam was do wypełnienia. :^)
W nawiązaniu do posta na temat wyceny projektów postanowiłem uruchomić małą ankietę w temacie — jak pracujemy i ile zarabiamy?
Ankieta będzie aktywna przez 7 dni pod tym adresem, po jej zakończeniu postaram się jak najszybciej przeanalizować wyniki i podzielić się nimi na blogu — kto chętny, niech wypełnia.
PS. Mam szczerą chęć uruchamiania takich ankiet co jakiś czas, jeśli będzie zainteresowanie, bo jak przekonałem się czytając komentarze, część ludzi nie wie, na ile tak naprawdę można wyceniać projekty.
Ostatnio spędzam sporo czasu oglądając sobie różne serwisy różnych profesjonalnych przysłowiową „pełną gębą” agencji internetowych z wypasionym designem i dużymi korporacjami w portfolio klientów. Nie, żebym szukał pracy, ale czasem po prostu lubię podpatrzeć innych, żeby zobaczyć co mogę poprawić w swojej pracy.
Przeglądam więc czasem fora Goldenline i Profeo, czytam wątki tworzone i rozwijane przez ludzi o tytułach „front-end developer”, gdzie radzą, prawią i mądrzą się w sprawach standardów, semantyki HTML’a i tym podobnych spraw. Potem mam w zwyczaju oglądać serwisy firm oraz klientów ludzi światłych w temacie… i tu niestety zaczyna się zgroza. O ile na strony zbudowane na table-based layoutach już raczej się nie trafia (chociaż i takie kwiatki widziałem), strony te cierpią na dwa podstawowe problemy.
Znakomita większość stron agencji, które odwiedziłem do tej pory, cierpi na zaawansowane stadium tego, co zachodni front-end developerzy nazywają divitis. Divitis objawia się w następujący sposób — webdeveloper, który ją przygotowywał, wiedział jedynie, że tabelki są „be”, a divy są „cacy”. Niestety, o takim zagadnieniu jak dostępność serwisu, czytelność w urządzeniach mobilnych z wyłączonymi arkuszami stylów oraz semantyka samego HTML’a już nikt mu nie wspomniał i efekt jest prosty — strona składa się wyłącznie z elementów div. Gdy zwróci się takiemu developerowi uwagę, nie będzie widział problemu. Co zrobić wówczas? Uświadamiamy takiego człowieka, że HTML nie składa się wyłącznie z elementów div, a oraz span , natomiast W3C wymyśliło kilka fajnych tagów, aby ustrukturyzować HTML m.in. dla przeglądarek nie obsługujących styli czy chociażby crawlerów wyszukiwarek i najprostszym sposobem na poprawienie wyszukiwalności strony jest nauczyć się tych tagów używać. Rekordziści rzekomo zatrudniający etatowych front-end developerów nie mieli ani jednego taga innego niż div użytego na stronie — wielopoziomowa nawigacja potrafiła sprowadzić się do ładnie ostylowanych linków upchniętych pojedynczo w divy, opakowane w… diva z id="menu" . Owszem, walidowało się, jako XHTML 1.0 Strict nawet, ale co z tego, skoro po wyłączeniu styli nawet nie muszę chyba wspominać jak wyglądało.
Oczywiście, są miejsca, gdzie przesadne strukturyzowanie HTMLa oraz jego semantyka nie mają specjalnego znaczenia — są to m.in. aplikacje internetowe mające „emulować” aplikacje desktopowe. Zwykle z powodu wyskakujących Javascriptowych okienek modalnych, czy innych tricków strona bez styli i JavaScriptu nie miała by sensu istnienia, ale w przypadku strony głównej agencji, która chwali się tworzeniem „użytecznych, dostępnych i zgodnych ze standardami serwisów internetowych”, warto zwrócić na takie kwiatki uwagę.
Zainteresowanych odsyłam do artykułów zewnętrznych:
Kolejnym podstawowym problemem spotykanym w tego typu serwisach jest nagminne bezsensowne użycie Javascriptu, w tym braku separacji markupu HTML od jego zachowania oprogramowanego Javascriptem. Cóż z tego, że używasz Prototype, Mootools, czy jQuery, skoro nie rozumiesz ich idei? Biblioteki te powstały między innymi, aby wspomagać pisanie Javascriptu, który jest odseparowany od markupu, czyli tzw. „unobtrusive Javascript”. A tymczasem na wielu stronach agencji chwalących się profesjonalnym podejściem do tematu możemy zobaczyć takie kwiatki jak onclicki w markupie, czy linki prowadzące donikąd.
Czy Ty, drogi front-end developerze znanej agencji, zastanowiłeś się kiedyś co dzieje się ze spiderem przeszukującym serwis Twojego klienta, kiedy natrafia on na link z href="#" i onclick="openModal(test.html)"
Nie? To ja Ci powiem — próbuje podążać za wartością href i trafia donikąd, a więc nie indeksuje wyskakującego modala. To samo stanie się, gdy osoba niewidoma lub niedowidząca trafi na Twoją stronę używając screen readera — „kliknie” w otwórz okno i nic się nie stanie. Jeśli uważasz, że tworzysz dostępne i dobrze wyszukujące się serwisy, napisz link tak, aby prowadził on gdzieś nawet gdy nie ma Javascriptu. Jeśli pop-up, który ma wyskoczyć jest zaszyty gdzieś w kodzie, tylko ma ustawione display:none, ustaw mu ID i kieruj linkiem pod #ID. Jeśli otwiera się zewnętrzna strona, poprowadź href do tej strony, a do Javascriptu obsługującego event click dodaj return false;, aby przeglądarki obsługujące JS nie podążyły za linkiem, a jedynie otwarły go w modalu — dzięki temu wilk będzie syty i owca cała. Gdzie możliwe, odseparuj Javascript od markupu, wsadzając go w osobne pliki, podłączające się do strony za pomocą uchwytów (event handlers) — oszczędzisz pracy przeglądarkom bez Javascriptu, a i kod będzie łatwiejszy w zarządzaniu. Zainteresowany? Odsyłam więc, tak jak poprzednio, do kilku zewnętrznych artykułów.
Kuba, wyraźnie nudząc się w domu, w którym nie podłączyli mu jeszcze Internetu, zaczął wgryzać się w kod dedykowanego webservera do Ruby’ego, Ebb, który dzięki temu że został napisany w pure C, jest znacznie wydajnieszy od Mongrela, czy Thina i planujemy go używać przy okazji hostowania utype. Wyniki jego analizy razem z kawałkami kodu można znaleźć na jego blogu.
Developerów Ruby może zainteresować.
Ostatnio na A List Apart pojawił się ciekawy artykuł dotyczący nowej techniki pozycjonowania layoutów XHTML/CSS przy pomocy tzw. faux absolute positioning.
Na czym polega owa technika? Otóż jeśli zajmujecie się zawodowo projektowaniem serwisów tudzież przekładaniem waszych projektów na XHTML/CSS, wiecie na pewno że przy layoutach opartych na siatkach (tzw. gridy) istnieją dwie popularne techniki pozycjonowania przy pomocy CSS -– pierwszym z nich jest floating, czyli pozycjonowanie przy użyciu float oraz pozycjonowanie przy pomocy position:absolute.
Pierwszy sposób jest niesamowicie niewygodny przy liquid layoutach głównie ze względu na różnice w zaokrąglaniu m.in. atrybutu width w Firefoksie i Internet Explorerze oraz różne interpretacje box modelu pomiędzy przeglądarkami. Drugi zaś sposób jest problematyczny m.in. przy pozycjonowaniu wszelakich stopek, ponieważ praktycznie nie da się ustawić kontenerów relatywnie pod absolutnie pozycjonowanymi kolumnami. Eric Sol i jego team dość długo zmagali się z tymi problemami podczas swoich projektów, więc opracowali nową technikę, wspomniane już wyżej faux absolute positioning, która wydaje się eliminować powyższe problemy (przy okazji wprowadzając kilka swoich, ale nikt nie jest doskonały ;)). Po szczegóły odsyłam do źródła.
Urodziłem się 9 października 1984 w Krakowie. Obecnie jestem studentem Informatyki Stosowanej na Akademii Górniczo-Hutniczej w Krakowie.
Projektowaniem graficznym i wzornictwem przemysłowym interesowałem się od zawsze. Jako dziecko rysowałem jak szalony, potem zajmowałem się grafiką i ASCII-artem na demoscenie. Mniej więcej od 2000 roku zajmuję się projektowaniem stron internetowych, od czasu posiadania Internetu w domu zainteresowałem się także standardami, SEO/SEM, dostępnością i użytecznością serwisów internetowych.