Mała ankieta dot. zarobków

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.

There are six million iBricks in Apple…

Techcrunch donosi o soczystym EPIC FAIL w wykonaniu Apple. Okazało się, że producent ładnych gadżetów spod znaku jabłuszka nie poradził sobie z obsłużeniem ruchu na nowootwartym App Store i ostatni krok instalacji softu w iPhone (zarówno starych 2G jak i nowych 3G) powoduje, że telefonem można co najwyżej wybić komuś okno.

Na szczęście Crunchgear opublikował już fix, który pozwala jakoś obejść timeout.

A teraz wszyscy razem — dziękujemy, Steve! ;)

Jak wyceniać projekty?

Ostatnio na Design Talkboard ukazał się całkiem ciekawy artykuł dotyczący wyceniania projektów graficznych dla klienta. Poza wylistowaniem czynników, które powinniśmy brać pod uwagę przy wycenianiu projektu graficznego, porusza on także temat wyceny tzw. „płaskiej” (stała, zapisana w kontrakcie cena za projekt) kontra stawki godzinowej. Autor artykułu nie zagłębia się zbytnio w szczegóły, postanowiłem więc opisać mój punkt widzenia. a także rozszerzyć temat o front-end development, czy też development ogólny. Na pierwszy rzut weźmy…

Płaska stawka

Stosowanie płaskiej stawki za całość projektu lub jego część jest z mojego doświadczenia formą preferowaną przez klientów korporacyjnych, gdzie wszystko musi przejść przez machinę księgowo-biurokratyczną, podbite tysiącem pieczątek i podpisane zgodą pięciu dyrektorów, dwóch asystentów i czternastu księgowych. Z powodów wyżej wymienionych stawka godzinowa jest dla takiego klienta zwyczajnie niewygodna, więc unikają jej jak ognia. Jeśli zgodzisz się na taką formę współpracy z klientem, pamiętaj o jednej podstawowej zasadzie — naucz się estymować. Estymacja godzin ma jedną podstawową zasadę — zawsze estymuj „z górką”. Musisz zawsze rozpatrzyć najbardziej optymistyczny (klient jest zachwycony, nie ma poprawek, nie ma problemów), jak i najbardziej pesymistyczny (klient nie może się zdecydować, masa poprawek/update‘ów w każdej fazie projektu), a następnie wyestymować najgorszy scenariusz plus kilka(naście) godzin na zdarzenia nieprzewidywalne. W ten sposób masz pewność, że zdążysz i nie skończy się na siedzeniu po nocach i klęciu na czym świat stoi, że musisz pracować za darmo. Podczas estymacji możesz także zastosować starą zasadę wyceniania więcej, niż wyestymowałeś, bo często klient w toku negocjacji próbuje trochę spuścić z ceny.

Z mojego doświadczenia wynika, że na tym typie kontraktów można wyciągnąć zasadniczo wyższą średnią stawkę za godzinę pracy, jednak jest on obarczony ryzykiem dla projektanta — klient może być kapryśny i tracimy pieniądze, pracując za darmo.

Hourly rate, czyli stawki godzinne

Z mojego doświadczenia wynika, że jest to forma preferowana przez małe firmy i osoby prywatne. Jest to forma bardziej agile, niż płaskie stawki, zwykle wymaga częstego kontaktu z klientem w celu zapewnienia obustronnego zaufania. Jest ona mniej ryzykowna dla projektanta, natomiast bardziej ryzykowna dla klienta, dlatego należy się przyzwyczaić do faktu „zerkania przez ramię”, czy aby na pewno coś się w projekcie dzieje, czy też nabijamy puste godziny. Budowanie zaufania przy stawkach godzinnych zwykle jest długie i żmudne, dobrze sprawdza się w tym przypadku metodyka Scrum, dzięki której klient cały czas trzyma rękę na pulsie, natomiast projekt jest na bieżąco konsultowany z klientem, co podnosi znacznie wygodę pracy projektanta.

Projekty negocjowane na stawki godzinne zwykle przynoszą niższe zyski niż projekty „płaskie”, głównie ze względu na fakt, że nie da się estymować „z górką”, dlatego też zwykle negocjuję wyższą godzinną stawkę dla takich projektów, osobno doliczając koszty ew. licencji zakupionych dla klienta.

Złota zasada

Chciałbym jeszcze wspomnieć o złotej zasadzie przy dowolnej wycenie projektu — nie psuj rynku. Spójrz uczciwie na swoje doświadczenie i umiejętności, wliczaj w umowy koszty oprogramowania, czcionek, ikon, technologii, w które będziesz musiał zainwestować (nie jesteśmy organizacjami dobroczynnymi, tylko projektantami) zorientuj się w stawkach na lokalnym rynku, nie wyceniaj poniżej tego, na ile Cię stać — psujesz wówczas rynek innym, a poza tym… coś trzeba jeść, prawda?

Jak to w końcu jest z tym GIMPem?

No więc jak zapewne część z was zauważyła, mam nowy design. Został od początku do końca stworzony w GIMPie, ale to nie dlatego, że nie stać mnie / nie chcę używać pakietu Adobe. Wręcz przeciwnie — znakomitą większość czasu pracy nad grafiką spędzałem obcując nie z darmowymi pakietami, a właśnie z pakietem firmy Adobe. Na layout tego bloga „rzuciłem się” w celu nie innym, jak przetestowanie, co tam panie w GIMPie od czasu, kiedy ostatnio go używałem. Postanowiłem się podzielić kilkoma spostrzeżeniami.

Wstęp

Jak wiadomo — nie pakiet graficzny czyni grafika i można mieć pełne CS3 Design Premium i nie umieć projektować. Takie przypadki znamy, widzieliśmy, raczej wolimy zamknąć w szafie i nie wracać. Pakiet graficzny jednak — jak każde narzędzie — może znacznie ułatwić lub znacznie przeszkadzać w procesie tworzenia. Na tym właśnie planuję oprzeć swojego posta — co GIMP ma, a czego mu brakuje, aby stać się pełnoprawnym konkurentem pakietów Adobe na polu, którym ja się zajmuję (a więc głównie projektowanie serwisów internetowych). Zaznaczam, że są to bardzo subiektywne odczucia i oczywiście jeśli ktoś się nie zgadza lub wie coś, czego ja nie wiem — chętnie poczytam o tym w komentarzach.

Co GIMP ma?

Czego na pewno nie można odmówić GIMPowi (w wersji 2.4, bo taką właśnie mam zainstalowaną na moim komputerze) to poprawna obsługa warstw, a także podstawowy pakiet narzędzi, który każdemu grafikowi związanemu z webdesignem powinien w zupełności wystarczyć.

GIMP, od czasów kiedy ostatnio go używałem, otrzymał także całkiem zgrabnie działającą obsługę linijek, znacznie ułatwiających pracę nad layoutem, wymiarowanie, a także późniejsze cięcie grafiki.

Sporym plusem jest także dodana obsługa pędzli w formacie *.abr, co pozwala (nareszcie) na używanie ogromnej ilości zasobów stworzonych pod Photoshopa. Miły, przydatny akcent.

Dzięki obsłudze Python-Fu, a także Script-Fu (chociaż jakoś ten pierwszy ma więcej sensownych implementacji), przy odrobinie szczęścia możemy znaleźć sporo przydatnych i użytecznych filtrów oraz odpowiedników photoshopowych „akcji”. Niestety, aby to zrobić trzeba przebić się zwykle przez masę niepotrzebnych nikomu śmieci w stylu „zmień teściową w kosmitę jednym kliknięciem”, ale i tego w zasobach photoshopowych nie brakuje.

Edycja zaznaczenia — muszę przyznać, że GIMPowa edycja zaznaczenia, a także fakt, że przechodzi w tryb edycji zaznaczenia przy jego tworzeniu, są świetnie zrobione jak na darmowy projekt. Jestem pod wrażeniem.

Czego GIMPowi brakuje?

Najbardziej moim zdaniem denerwującym brakiem są niedoróbki narzędzia do edycji tekstu. Jak wiadomo, w webdesignie tekstu jest sporo i w projekcie należy go uwzględnić. Chodzi mi o tu między innymi o takie rzeczy jak zaznaczenie chociażby linka (w Photoshopie wystarczy zaznaczyć kawałek tekstu i zmienić mu kolor/styl, w GIMPie nic takiego nie znalazłem, uparcie zmieniał styl dla całego bloku). Podobnie ma się sprawa w przypadku próby oznaczenia bloku tekstu, który ma się zaczynać i kończyć w odpowiednim miejscu (bardzo przydatna sprawa przy wizualizacji kolumn layoutu). W GIMPie da się po prostu wklepać tekst, nie znalazłem narzędzi pozwalających po prostu kliknąć i rozciągnąć blok tekstu tak, żeby GIMP sam zadbał o jego łamanie w ramach bloku.

Grupowanie warstw — kolejna rzecz, której bardzo brakuje. Jak wiadomo, bardzo często zdarza się, że projektujemy np. aktualności, czy bloga, gdzie pewne części powtarzają się. W Photoshopie stosuje się w tym celu grupowanie warstw i po prostu duplikuje daną grupę, co znacznie przyspiesza projektowanie. W GIMPie trzeba duplikować poszczególne warstwy, co jest wyjątkowo żmudne i męczące.

Style warstw — spory brak. Bardzo wygodną rzeczą w Photoshopie jest to, że dla danej warstwy możemy przypisać styl, obejmujący takie rzeczy jak obrys, cień, wypełnienia kolorem, gradientem i tym podobne rzeczy. W GIMPie tego po prostu nie ma, nie obsługuje on także styli warstw w plikach *.psd, co boli, jeśli dostajemy od kogoś zrobiony w Photoshopie layout do pocięcia. Oczywiście efekty w stylu gradient overlay, color overlay, border czy drop shadow możemy osiągnąć przy pomocy filtrów, jednak z reguły tworzą one nową warstwę, której… no właśnie – której dodatkowo nie możemy zgrupować z warstwą podstawową.

Smart defaults — z początku bardzo mi brakowało czegoś w rodzaju smart defaults, znane z Photoshopa. Załóżmy, że kopiuję dany fragment strony i chcę go wkleić jako nowy obrazek (na przykład w procesie cięcia layoutu). GIMP proponuje mi utworzenie nowego pliku o rozmiarach poprzednio utworzonego, a nie wartości ze schowka, co trochę wkurza. Nie mniej jednak później odkryłem skrót Ctrl+Shift+V, który załatwia wszystko za mnie — tworzy obrazek o danym rozmiarze i wkleja w niego zawartość schowka.

Interfejs — największą chyba bolączką ludzi przesiadających się z dowolnego innego pakietu graficznego jest interfejs — wielookienkowy, stosunkowo niewygodny na początku, nie mniej jednak można się przyzwyczaić, lub w skrajnej frustracji zainstalować GIMPshopa

Podsumowanie

Podsumowując, GIMP po przyzwyczajeniu się do dziwnego z początku interfejsu, co zwykle zajmuje ładną chwilę, niejedno brzydkie słowo skierowane w kierunku monitora, a także okresy dominującej frustracji, jest całkiem wystarczającym edytorem graficznym dla grafika zajmującego się tworzeniem stron internetowych. Zdecydowanie największym bublem jest narzędzie do edycji tekstu, które potrafi doprowadzić do szewskiej pasji (tworzenie kilku warstw tylko dlatego, że część tekstu ma być inną czcionką lub w innym kolorze nie jest fajne). Sporym dla mnie brakiem jest też brak możliwości grupowania warstw, co czyni pracę żmudną i niewygodną przy powtarzających się blokach grafiki. Nie mniej jednak do projektowania i cięcia prostych layoutów wystarcza w zupełności.

Front-end development, a sprawa polska

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.

Divitis

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:

Bezsensowny Javascript

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.