pierwszy projekt

Pod koniec ubiegłego roku zdecydowałem się zebrać wszystkie swoje projekty znaków. Taka dokumentacja własnych prac w jednym zbiorze. Wszystkie, bez wybierania i prezentowania ograniczonej ilości, jak w internetowych portfolio się praktykuje. Robiąc taką dokumentację dla siebie nie muszę się krygować, że jakiś projekt słabszy, ani chować pod dywan tego, co powstało a nigdy nie były publikowane, z różnych względów.

Przy okazji tego dokumentowania własnej pracy ze znakiem, przegrzebałem swoje archiwum projektowe, stosy starych umów, szkiców  i notatek, i sam siebie zaskoczyłem. No cóż wiek robi swoje i o niektórych znakach zwyczajnie zapomniałem. Inna sprawa, że te zapomniane były jeszcze z okresu przedkomputerowego, a powiedziałbym nawet z okresu gdy nie specjalnie przykładałem wagę do archiwizowania własnych projektów. Efektem tego była także konieczność odtworzenia niektórych znaków w oparciu o szkice, tym bardziej, że w niektórych wypadkach trudno nawet znaleźć ślad po dawno nie istniejących zleceniodawcach.

W miarę powiększania się zbioru znaków i cofaniu w przeszłość pojawiało się zaskoczenie, nie tyle przypomnieniem sobie znaku co datą jego powstania. Cóż, na starość wszystko wydaje się jak by było niedawno i dopiero rok powstania danego projektu uświadamia upływ czasu.

Podczas wertowania najstarszych zapisków i szkiców pojawiło się pytanie – kiedy był ten pierwszy raz, Pierwsze znakowe przymiarki? Od czego  się to zaczęło?

A zaczęło się nieco dziwnie, od propozycji odświeżenia znaku Zakładu Remontowego Energetyki we Wrocławiu, przy okazji potrzeby zrobienia znaczków firmowych na sztyfcie, tzw. pinów. Pomysł odświeżenia znaku powstał, niestety, na nieco zbyt niskim poziomie decyzyjnym i nigdy nie został zrealizowany, ale projekt powstał.  I był tym pierwszym. Jak dawno temu? Sporo lat upłynęło, bo projekt powstał w roku 1974. Zatem czterdziestka stuknęła, jak by na to nie patrzeć.

Wtedy bawiłem się w ręczne kreślenie znaku (ołówki, cyrkiel, ekierka, grafion i tuszem), teraz odtworzyłem go w wersji elektronicznej, nadając przy okazji zaplanowany kolor czerwony.

Mój pierwszy znak sprawił też kłopot, odnalezienie znaku używanego wtedy przez ZRE Wrocław, dla porównania, okazało się sporym problemem. W moich szpargałach go nie znalazłem, zaś w internecie odnalazłem tylko taki maleńki znaczek  z tamtego okresu. Nie znam niestety autora tego znaku.

Pomysł na zebranie wszystkich znaków, jakie stworzyłem, okazał się więc, przypadkowo, dokumentowaniem mojego 40-lecia pracy ze znakami.

Wycieczka w czasie zaowocowała zbiorem obejmującym 405 znaków (logo, ikon, monogramów, herbów), na 134 stronach  formatu 30×30 cm, podzielonym na dwie części: wiek XX i XXI.

Wydrukuję sobie egzemplarz, będzie pamiątka dla wnuka. Można też będzie sukcesywnie dodawać nowe projekty i mieć wszystko pod ręką, w jednym miejscu.

US Virgin Islands

Walka o turystów powoduje dbałość o własny, lepszy od innych, wizerunek. Po świetnej identyfikacji Wysp Bahama kolejny dobry przykład dają położone na morzu Karaibskim US Virgin Islands, terytorium skonfederowane z USA a obejmujące trzy wyspy St. Croix, St. John, St. Thomas. Warto pamietać że jest jeszcze British Virgin Islands.

Logo promocyjne US Virgin Islands oparto na kulturowej ikonie wysp i zarazem atrakcji turystycznej – tancerzach Mocko Jumbie.

Beverly Nicholson-Doty, komisarz ds. turystyki ujmuje to tak:

„Mocko Jumbie symbolizuje wibracje naszej ludności i naszą kulturę, trzy gwiazdy zaś oddają indywidualnego ducha St. Croix, St. Thomas i St. John”

I dlatego też każda z wysp ma swoją własną wersję kolorystyczną znaku, swojego Mocko Jumbie.

Ciekawie i zachęcająco w nowej identyfikacji wygląda oficjalna strona Departmentu Turystyki U.S. Virgin Islands.

Jedyna nie do końca jasna sprawa to autorstwo znaku – w materiałach oficjalnych widnieje agencja J. Walter Thompson, natomiast projektem chwali się na swojej stronie także studio Iconlogic (The Jumbie United States Virgin Islands).

Źródła: font.cz, underconsideration.com, iconologic.com, gotostcroix.com, wikipedia.org, sunshinedesignz.net

Brak szacunku do cudzej pracy

Odsłona I

Projektując logo mam także do czynienia z wieloma innymi projektami „użycia” tegoż. Jednym z najbardziej niezrozumiałych dla mnie jest projekt layoutu strony klienta. Konkretnie problem jaki pojawia się PO zaprojektowaniu strony. Nie idzie tu o wymyślności i bajery techniczne, trudne do zrealizowania po stronie programisty. Problem stanowi minimalizm moich projektów i oszczędność operowania środkami. Zawsze po stronie programistycznej pojawia się, nie wiedzieć czemu, nieodparta chęć „dosmaczania”. Tu trójwymiarowa ikonka, tam obrotowe logo, menu z klawiszami choć miało ich nie być. Zapędy upiększania projektu wbrew założeniom. Jednocześnie taki spec od kodowania ma problemy z wyrównaniem bloków tekstu w poziomie, równe odległości między obrazkami są tylko w projekcie, jemu jakoś nie chcą wyjść. Słyszę wtedy wyjaśnienia – web rządzi się swoimi prawami. Te „swoje prawa” to w większości strona techniczna, a nie grafika czy kompozycja, tu różnicy nie ma.

Przykłady? Przy jednej tylko stronie koder nie umiał wyrównać w poziomie menu z zawartością środkowego łamu. Nie umiał zrobić identycznych świateł między fotami – dlaczego możesz zobaczyć klikając na mniejsze fotki. Musiał dołożyć swoje ikonki 3D języków, a… co będę wyliczał.. Przy innej powstał problem dodawanych przez kodera, na siłę własnych ozdóbek, zresztą obraził się i w efekcie i tak wepchnął klientowi swoją wersję.

Rozbraja mnie takie stwierdzenie – Za to spotkałem się z layoutami, których realizacja jest nieefektywna – zajmuje za dużo czasu a ostateczny efekt w różnych przeglądarkach jest zbyt nieprzewidywalny. Co ma z tego wynikać? ułatwiać sobie pracę za wszelką cenę?. Ja nie tłumaczę klientowi ze jego praca zabrała mi 2 m-ce choć zakładałem 2 tygodnie. Ma być dobrze zrobione i już, nawet jakby trwało pół roku. Efektywność mierzona kilometrami kodu czy jego prostotą ? A może efektywność jako sprowadzenie projektu na poziom własnych umiejętności, a może efektywność mierzona „czy mi się opłaca? od tego jest kalkulacja przed rozpoczęciem pracy. Chyba że ta kalkulacja idzie takim oto torem myślenia – powiem X, a potem się zobaczy, byle zechciał zamówić. Zastanawiające, w przywołanym cytacie jest hasło nieprzewidywalności – czyżby nie wiedział jaki będzie rezultat końcowy własnej pracy?.

Z perspektywy kodera problemem jest to, że o ile graficy znają się na typografii czy estetyce, to nie mają pojęcia o tym, że strona to medium żywe, które może być uruchomione na dziesiątkach urządzeń, w różnych rozdzielczościach, w przeglądarkach o różnych możliwościach i problemach. I trzeba kod tak opracować, by działał sensownie na wszystkim. Stąd często pojawiają się uproszczenia w stosunku do grafiki wyjściowej. Gdyby to wiedzieli i potrafili koderzy byliby zbędni. Ciekawie jednak brzmi to upraszczanie grafiki w zestawieniu z podanym wyżej przykładem niedorobek w stosunku do projektu. A co do medium żywego każde użycie jakiegoś elementu, lub narzędzia, musi mieć uzasadnienie. Dodawanie kwiatka do kożucha ma sens, co najwyżej, 8 marca. Pchanie gdzie się da flasha, animacja, 3D, i co tam jeszcze kto chce, tylko dlatego ze akurat koder je opanował, i bardzo jest z tego dumny, to zadne uzasadnienie. Gdyby chociaż upraszczał, pół biedy, on na ogół musi dodać, ubarwić, ożywić i to dokładnie nie to i nie tam gdzie należy. Odpuszczając sobie głupoty typu wyrównania, krój czy wielkość świateł. Zdaję sobie sprawę że najłatwiej zatuszować takie rzeczy bajerami, które skutecznie odwracają uwagę. Gorzej że odwracają uwagę nie tylko od jego błędów ale i, co gorsza, od treści oferty klienta. I tak cała para w gwizdek. Pieniądze wydane, efektu brak.

Kolejne hasła obronne, którymi często gęsto szermują koderzy – użyteczność interfejsów i dostępność stron, czego ponoć nie rozumieją graficy, którzy „nie wyrośli na webie”. Tymi co wyrośli są w zdecydowanej większości tzw. graficy komputerowi bez żadnego przygotowania graficznego a jedynie przeszkoleni w obsłudze programów. Jaki to daje efekt? czytam na forach o wyższości jednego programu nad drugim. Takie dyskusje o wyższości ołówka automatycznego nad zwykłym. Nie znajduję za to dyskusji o kompozycji, o myśleniu nad tym co się robi, w jakim celu i co możemy tym uzyskać. W takim ujęciu użyteczność i dostępność jest pustym hasłem,. to co klient chce osiągnąć poprzez stworzoną witrynę miast być na 1 miejscu spada na koniec listy ważności. Użyteczność i dostępność to nie funkcje same dla siebie.

Praca kodera nie jest łatwa. Programista ma określone środowisko, grafik w pewnym stopniu też ma określone środowisko (oczywiście, szersze – musi wiedzieć np jak jego logo będzie wyglądało w druku itp). Dobry koder – nie. To koder nie wie? nie potrafi przewidzieć jak to będzie w sieci? Tragedia. Projektując dla weba ściśle współpracuję z klientem i muszę wiedzieć dokładnie, co i jakimi sposobami chcemy osiągnąć, a koder nie wie.