reinmar@jabber.wroc.pl

Uwaga: wyszedł mi "odrobinkę" przydługi wstęp. Zabieganych zapraszam od razu do konkretów.

CSS rady nie daje

Nie da się ukryć że frontend developerzy (czy inaczej "ci od cięcia grafiki" :) łatwego życia nie mają. Pierwsza sprawa to niedoskonałości samych języków (CSS, xHTML, Javascript+DOM), druga to różnice i bugi (zwane inaczej ficzerami) w obsłudze przez przeglądarki. Każdy z tych języków na szczęście się rozwija (CSS3, HTML5, ECMAScript 5), a implementacja standardów jest, nawet w Internet Explorerze, sukcesywnie polepszana. Trwa to jednak strasznie długo, dlatego warto pokombinować samemu.

Ostatnio opisałem plugin do edytorów tekstów dzięki któremu można przyspieszyć pisanie HTMLa. Dzisiaj pod lupę chciałbym wziąć CSS. Osobiście na tempo pisania listy właściwości nie narzekam - mam własny zestaw snippetów, który umila mi życie. Inaczej ma się sprawa w stosunku do selektorów. Już w niedużym projekcie potrafią się zrobić cuda typu:

#content .news_list .item .title {...}
#content .news_list .item .date {...}
#content .news_list .item .date .day {...}

Albo:

.s1 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#FA0; }
/*gdzieś kawałek dalej:*/
.s2 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#C14; }

Gdzie wypada to połączyć do pary selektorów i dla każdego z osobna jeszcze kolor ustawić. Niestety to najprostszy przypadek z tej rodziny, czasami trzeba znaleźć części wspólne dla kilku reguł po kilkunaście właściwości, albo olać wszystko.

Dalej można wymieniać:

• Powtarzające się wartości kolorów, rozmiarów, marginesów, itd. Zmiana jednej wymaga zmiany pozostałych, bo np. tekst ma mieć ten sam kolor w nagłówkach newsów co gdzieś w sidebarze i górnym menu. I jak pozapamiętywać te wszystkie kluczowe wartości, żeby później nie szukać co to był za kod tego pomarańczowego, który używam do podkreśleń?
• Obliczenia - dopełnianie się marginesów, paddingów i borderów, kolor lekko ciemniejszy, kolor lekko jaśniejszy. Ja zawsze do cięcia siadałem z kartką A4, która już po kilku godzinach była zapisana do pełna wartościami i obliczeniami.

• -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;

Co więcej - to są problemy które pojawiają się już na etapie stron o średniej wielkości i kodowania w pojedynkę. W przypadku sporych serwisów (długo i wieloetapowo rozwijanych) i większego zespołu potrafią urosnąć do &*$#$%. To jest jak rzeźba w gównie. Trzeba przepisać cały ten bajzel. Sam ostatnio tak opisałem jeden commit do bazy.

Wysyp wspomagaczy

Jakiś czas temu dostałem od kogoś link do LESS CSS - parsera/kompilatora (nie wiem jak to nazwać) rozszerzającego możliwości CSSa o kilka interesujących rzeczy typu: zmienne, obliczenia, reguły zagnieżdżone, itd. O temacie jednak zapomniałem (mało ostatnio koduję) i przypomniał mi kilka dni temu o nim Occulkot, który podrzucił mi Sassa. Obydwa kompilatory napisane są w Rubym. Zrobiłem mały research i znalazłem jeszcze podobne cudo, tyle że w Pythonie - Clever CSS.

Po krótkim wczytywaniu się w przykłady zdecydowałem się na LESSa. Dodaje do CSSa trochę mniej ficzerów, ale przynajmniej nie zmienia jego składni (plik CSS jest poprawnym plikiem LESS) i nie wymusza na mnie jedynego, właściwego formatowania kodu (Sass i Clever CSS mają składnię czerpiącą z języków w jakich zostały napisane - odpowiednio Ruby i Python - wymagają więc wcięć).

Polecam przeczytać Haml-sass, czyli tragedia w dwóch aktach. Przy okazji tej lektury ja również odradzam Hamla, który jest w teorii cudownym (zen i te sprawy) systemem szablonów HTMLa. Tylko, że kompletnie to nieczytelne, brzydkie i bez sensu.

Instalacja

Po tym przydługim wstępie (chciałem usunąć, ale żal jak się już napisało) przejdźmy do konkretów.

Instalacja, dla posiadających gema (ci nieposiadający najlepiej niech go zainstalują), jest banalna:

$ sudo gem install less

Ewentualnie jeśli ktoś koduje w Railsach, to może go zainteresować ten plugin.Najprostszym sposobem skorzystania z LESSa jest jednak przy pomocy konsoli:

$ lessc style.less

Wykonanie tego polecenia spowoduje utworzenie pliku style.css zawierającego wynik działania kompilatora.

Ficzery

Zmienne

Kompilując taki kod:

@brand_color: #4D926F;
 
#header {
  color: @brand_color;
}
h2 {
  color: @brand_color;
}

Otrzymamy:

#header, h2 { color: #4d926f; }

Jak widać, poza podstawieniem zmiennej, LESS połączył też reguły o tej samej liście właściwości. To informacja dla miłośników oszczędzania na bajtach transferu :).

Wielokrotne wykorzystanie reguł

CSSowe DRY :).

.rounded_corners (@radius: 5px) {
  -moz-border-radius: @radius;
  -webkit-border-radius: @radius;
  border-radius: @radius;
}
 
h1 .stronger {
	font-weight:bold;
	font-size:1.1em;
}
 
#header {
  .rounded_corners;
  h1 .stronger;
}
 
#footer {
  .rounded_corners(10px);
}

Po kompilacji:

h1 .stronger {
  font-weight: bold;
  font-size: 1.1em;
}
#header {
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;
  font-weight: bold;
  font-size: 1.1em;
}
#footer {
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
  border-radius: 10px;
}
 

Przy czym definicja reguły musi wystąpić przed jej użyciem. Przykład z wykorzystaniem h1 .stronger nie ma uzasadnienia w praktyce (jest w zasadzie błędny), ale chciałem tylko pokazać, że można wykorzystywać ponownie dowolne reguły.

Zagnieżdżone reguły

To chyba mój ulubieniec. Dzięki temu rozszerzeniu unikniemy pisania co chwilę mega długich selektorów. Dziwię się w ogóle, że nie ma tego w oficjalnym CSSie.

#header {
  color: red;
  a {
    font-weight: bold;
    text-decoration: none;
  }
 
  > p {
	  color: blue;
  }
}

Po kompilacji:

#header { color: red; }
#header a {
  font-weight: bold;
  text-decoration: none;
}
#header > p { color: blue; }

Obliczenia

Chyba nie muszę tłumaczyć.

@the-border: 1px;
@base-color: #111;
 
#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}
 
#footer { 
  color: (@base-color + #111) * 2; 
}

Po kompilacji:

#header {
  color: #333333;
  border-left: 1px;
  border-right: 2px;
}
#footer { color: #444444; }

To by było na tyle. Jeśli kogoś temat zainteresował to zapraszam do specyfikacji, gdzie autor omawia jeszcze kilka dodatków.

W każdym razie - cztery małe ficzery, a jak cieszą, prawda? :)

Praca z LESSem

Zastanawiałem się tylko jak usprawnić kompilację po wprowadzeniu zmian do pliku LESS. Najfajniej gdyby udało mi się w moim VIMie podłączyć wykonanie $ lessc pod operację zapisania, ale to nie na moje umiejętności. Mcv zaproponował mi takiego Makefile'a:

%.css: %.less
	lessc $<

Wykonujemy go uruchamiając: $ make plik1.css plik2.css. To już powinno mi się udać podpiąć w VIMie pod zapis pliku. Ewentualnie można spróbować tak:

all: *.css
 
%.css: %.less
	lessc $<

Co zadziała automatycznie dla wszystkich istniejących już plików CSS po wykonaniu prostego $ make. Przy czym, jeśli się mylę, to proszę mnie poprawić, bo nigdy żadnego makefile'a sam nie napisałem.

EDIT: w komentarzach pojawiły się rozwiązania mojego problemu.

Snippety do htmla? Nieeee. Zobaczcie Zen Coding. W skrócie działa to tak. Wpisuję w edytorze CSSową składnią:

div#content>h1+p

Wciskam jakąś kombinację klawiszy i dostaję:

<div id="content">
<h1></h1>
<p></p>
</div>

Sprytne, nie? :) Ale to jeszcze mało. Spróbujcie tego:

div#top>h1>a[title=Do strony głównej]{Moja strona}<ul#menu>li.pos$*3>a

<div id="top">
    <h1>
        <a href="" title="Do strony głównej">Moja strona</a>
    </h1>
    <ul id="menu">
        <li class="pos1">
            <a href=""></a>
        </li>
        <li class="pos2">
            <a href=""></a>
        </li>
        <li class="pos3">
            <a href=""></a>
        </li>
    </ul>
</div>

Chyba nie muszę mówić jak bardzo taka pomoc przyspiesza pracę. Napisanie z palca kodu z drugiego przykładu zajęłoby mi przypuszczalnie więcej niż 2 minuty. Gdybym użył snippetów (do których przy HTMLu nie mogę się przyzwyczaić) może skróciłbym ten czas dwukrotnie. Zaś używając wynalazku Zen Coding całość naklepałem w 20s (i to nie mając wprawy). Tak więc gorąco polecam.

Gdyby ktoś szukał wtyczki do VIMa, to powstał plugin, którego twórca zainspirował się Zen Codingiem.

Tym razem będzie krótko i o życiu.

Do niedawna mój przykładowy dzień wyglądał tak:

1. 8:30-9:00 pobudka
2. 10:00 pojawiam się w pracy (albo zasiadam do niej w domu)
3. 16:00-17:00 kończę robotę (tak - to nie 8h; pracuję na 1/2 etatu, a w pracy jestem 3dni/tyg.)
4. 18:00 po godzinnym staniu w korkach jestem w domu
5. 19:00 zjadłem, odpocząłem, mogę zabrać się do pracy i biegania
6. 2:00 damn - pora iść spać - nie za dużo tego czasu miałem

Dało się tak żyć w lecie. Teraz niestety prawie całą moją dobę było ciemno za oknem, co zaczęło dodatkowo działać depresyjnie. Do tego stałem sobie codziennie w pięknych koreczkach tracąc dodatkowe godziny doby i denerwując się, co działa demotywująco.

Zmiana

Całkiem przez przypadek założyłem się z siostrą, że wyjdę z domu przed nią (czyli przed ok. 8:00). Budziki nastawiłem już od 6:20, bo potrzebuję minimum pięciu żeby się obudzić. Fartem - złapał mnie już pierwszy i... pierwszy raz od... uh - roku? dwóch? wyszedłem z domu o 6:50. I mój dzień wyglądał tak:

1. 7:10 w pracy - korków jeszcze nie było
2. 15:00 wychodzę - zrobiłem całe 8h, więc jeden z 3 dni roboczych będę miał luźny. Dodatkowo widziałem wschód słońca, skończyłem jak ciągle było jasno na dworze
3. 15:20 w domu - koreczków nie było, wróciłem ekspresowo
4. 16:20 kończę bieganie - wreszcie udało mi się pobiegać przy świetle dziennym
5. 17:20 zabieram się do pracy, nauki, itd.
6. 1:00 już zasypiam, żeby następnego dnia powtórzyć historię

I tak żyłem przez kilka dni. Efekt niesamowity. Zrobiłem rzeczy, które wcześniej zajęłyby mi kilka tygodni. Dodatkowo psychika lepiej znosi zimę, bo nie przesypiam połowy dnia. No i w jeden z 3 dni pracuję tylko 4h.

Co dalej?

Co prawda dzisiaj (co widać po godzinie) idę spać późno, ale to wypadek przy pracy. Zamierzam i tak wstać o 7:00, bo najważniejsze, to wyrobić sobie nawyk. Dobranoc i życzcie mi powodzenia :)

W zeszły czwartek (tj. 12 listopada) odbyła się Wrocławska część WUD Tour, na której miałem przyjemność być. Nawiasem mówiąc była to pierwsza konferencja poświęcona usability, na którą dotarłem, bo naście poprzednich albo przegapiłem, albo z przyczyn niezależnych dotrzeć nie mogłem. Tym razem też nie było idealnie, bo po kilku pierwszych prezentacjach musiałem udać się na zajęcia.

W skrócie co widziałem

• Wprowadzenie do tematyki usability - nic szczególnego, ani tym bardziej zaskakującego - raczej dla tych, którzy pomylili salę i potrzebowali wprowadzenia od zera.
• Akcelerator Designu - prezentacja pracowników Urzędu Miasta Wrocławia dotycząca inicjatywy mającej na celu promowanie idei wzornictwa przemysłowego i użyteczności wśród przedsiębiorców (itd., itd.). Temat póki co mnie nie prawie nie dotyczący, więc było trochę nudno. Sytuację poprawił dopiero trzeci z prowadzących będący z pochodzenia Włochem, który swoją łamaną polszczyzną bardzo zgrabnie przedstawił nam pewnego włoskiego designera. Kto był ten wie o czym mówię ;D
• Co chcą zobaczyć klienci sklepów elektronicznych? - O tej prezentacji za chwilę. W skrócie powiem tylko, że była całkiem ciekawa i tak "politechnikowo" przedstawiona :P
• Możliwość używania - drugi biegun względem poprzedniej ekipy (prosta graficznie prezentacja, ale ładnie opracowana typograficznie versus prezentacja "specyfikacyjna" :). Prelekcja przeprowadzona przez Krzysztofa Kubaska - pracownika ASP i projektanta wzornictwa zawodu, dotycząca łączenia użyteczności z designem. Krzysztof z powodzeniem pokazywał, że te dwie rzeczy mogą iść ze sobą w parze i współpraca designera z inżynierem jest jedną z podstaw dobrego produktu. Przy okazji pokazał kilka przykładów zabawnie zaprojektowanych przedmiotów codziennego użytku, jak np. widelec w kształcie samolotu (leci samolocik... AM! :P), czy kubków z dziobami/pyskami zwierząt. Krzysztof zrobił dobre wrażenie i myślę, że taki był główny cel tej prezentacji. Według mojej spiskowej teorii - śmiech -> dobre wrażenie -> więcej klientów ;). Zwróciłem też uwagę, że specjalistów od usability uważa za informatyków. Ciekawe :)

Później niestety musiałem już sobie iść. Najciekawsze prelekcje opuściłem i czekam z niecierpliwością na video z konferencji.

Czy użytkownik jest złym projektantem?

Wracając do prelekcji dotyczącej sklepów internetowych. Marcin Kuliński przedstawił nam narzędzie służące do badania preferencji użytkowników dotyczących rozmieszczenia elementów interfejsów (w tym przypadku sklepów internetowych). Narzędzie to składało się z dwóch części - pierwszej - bardzo prostej, pozwalajacej za pomocą drag&dropa zaprojektować z dostępnych elementów własny interfejs. Druga służyła do przeglądania wyników tego badania. Nie pamiętam wszystkich funkcji tego narzędzia, ale na pewno można było filtrować badanych, porównywać wyniki dla grup, itd.

Drugą część prezentacji prowadziła Katarzyna Jach, która przedstawiła wyniki badań na grupie, jeśli dobrze pamiętam, 500 studentów IZetu. Zostali oni zapytani gdzie umieściliby przedstawione im elementy interfejsu. Dla każdego z predefioniowanych elementów serwisu (logo, kategorie, zdjęcie produktu, itd) zobaczyliśmy "mapę cieplną" gdzie badani widzieli tę funkcjonalność. Wyników nie pamiętam i nie udało mi się ich znaleźć. Dotarłem tylko do screenów i dema aplikacji nazwanej pieszczotliwie microSzu.

Na zakończenie z sali padły dwa pytania. Jedno dotyczyło tego po co powstała ten system skoro można przeprowadzić testy A/B przy pomocy Google Website Optimizera (który jest bezpłatny, w przeciwieństwie do microSzu). Dla mnie odpowiedź jest oczywista (a pytanie bez sensu) - testy A/B pozwalają nam jedynie udoskonalać istniejącą już stronę i tylko element po elemencie. Wcześniej trzeba przecież tę stronę zaprojektować, czyli między innymi rozmieścić na niej elementy interfejsu. Badanie przeprowadzone przez microSzu pozwala nam na optymalne dla użytkowników zaprojektowanie strony. No właśnie - czy na pewno optymalne?

Tego dotyczyło kolejne pytanie, a w zasadzie stwierdzenie - "użytkownik nie jest dobrym projektantem". W pierwszym momencie stwierdziłem, że i to pytanie jest bez sensu. Nie dajemy przecież użytkownikowi projektować, tylko badamy jego preferencje. To przecież część UCD. Później (między innymi po przeczytaniu relacji Agnieszki Matysiak-Szóstek, której prelekcji nie widziałem, czego bardzo żałuję) zacząłem się zastanawiać, czy na pewno mam rację. W końcu badanie polegało nie tylko na odpowiedzi na pytanie gdzie szukałaby Pani/Pan listy kategorii?, ale na zaprojektowaniu całej strony na raz, czyli zmierzeniu się np. z problemem - ten róg mam już zajęty, gdzie ja teraz ciapnę to to?.

Myślę, że właśnie w treści pytania i zadaniu do wykonania leży cały problem. Gdyby udało się uzyskać od badanego wszystkie informacje, bez zmierzenia go z problemem całej strony jednocześnie, to uzyskane dane byłyby bardzo przydatne. Możnaby stworzyć proste wytyczne, w którym miejscu (bądź miejscach) możemy umieścić dany element by był łatwo znajdowalny (jeśli chodzi o region, bo pozostają użyte nazwy, czy kolor/wielkość/etc.) przez użytkownika. I nie musi to od razu ograniczać inwencji i talentu projektanta, który może zawsze zaryzykować jakąś zmianę względem szablonu. To jest tylko propozycja, a czy skorzystam, to zależy np. od ilości czasu jaką mogę projektowaniu poświęcić.

Tak przynajmniej myślę ja u początków mojej przygody z użytecznością :)