Tech Platform: car-mechanic-huntington.co.uk

#car-mechanic-huntington.co.uk, profesjonalna strona dla warsztatu samochodowego

Projekt strony car-mechanic-huntington.co.uk powstał po to, żeby przedstawić ofertę warsztatu samochodowego i ułatwić umówienie wizyty. Odbiorcami są właściciele samochodów z okolicy, osoby szukające diagnostyki konkretnego problemu oraz firmy utrzymujące kilka aut w ruchu. Wdrożenie oddaliśmy w 2012 roku i zajęło ono około sześciu tygodni.

Warto od razu zaznaczyć, w jakim momencie ta strona powstawała, bo bez tego część decyzji wygląda na oczywistą, a wtedy taka nie była. W 2012 roku układ responsywny nie był domyślnym sposobem budowania stron, tylko osobną pozycją w zakresie prac. Nie było jeszcze ani flexboksa w powszechnym użyciu, ani siatki CSS, więc kolumny układało się na pływających blokach, a punkty przełamania dobierało do konkretnych szerokości ekranów telefonów, które ludzie wtedy trzymali w kieszeni. Stąd wzięła się siatka z frameworka Bootstrap: nie z mody, tylko z tego, że alternatywą było napisanie tego samego od zera i utrzymywanie tego przez lata samodzielnie.

#Termin w warsztacie nie jest polem formularza

Najciekawsza część tego projektu nie leży w wyglądzie, tylko w rezerwacji. Formularz z listą dat wygląda jak zwykły formularz kontaktowy i zachowuje się zupełnie inaczej, bo operuje na zasobie, którego jest skończona ilość.

Warsztat nie ma kalendarza w sensie kalendarza spotkań. Ma stanowiska i ma mechaników, a termin jest kombinacją jednego i drugiego na określony czas. Wymiana oleju zajmuje inną część dnia niż diagnostyka usterki elektrycznej, więc slot nie jest równy slotowi. Model danych, który zapisuje rezerwację jako datę i godzinę, przewraca się przy pierwszym dniu, w którym dwie osoby chcą przyjechać o ósmej rano, a stanowisko jest jedno.

Z tego wynika rozstrzygnięcie, które wygląda na drobiazg, a jest sednem całego modułu. Dostępność pokazana w przeglądarce jest zdjęciem stanu sprzed chwili, a nie stanem bieżącym. Między wyświetleniem listy terminów a kliknięciem przycisku mija czasem kilkanaście minut, bo klient w międzyczasie sprawdza, czy da się wziąć wolne. Dlatego sprawdzenie dostępności musi wykonać się jeszcze raz po stronie serwera, w momencie zapisu, i musi zostać wykonane w sposób, który nie pozwala dwóm żądaniom przejść przez tę samą wolną godzinę. Interfejs, który tylko ukrywa zajęte pozycje na liście, wygląda poprawnie i pozwala na podwójną rezerwację przy pierwszym zbiegu okoliczności.

Druga konsekwencja dotyczy pamięci podręcznej. Strona warsztatu jest w większości treścią statyczną: opis usług, cennik opisowy, dojazd, godziny otwarcia. Taką treść wolno trzymać w cache długo. Widok z dostępnymi terminami jest dokładnie odwrotnością tego, bo jego jedyną wartością jest aktualność. Konfiguracja, która obejmuje cache całą witryną bez wyjątku, potrafi tydzień po starcie oddawać terminy zajęte dwa dni wcześniej, i nikt tego nie zauważy do telefonu od klienta stojącego przed zamkniętą bramą. Widok rezerwacji jest więc wyłączony z buforowania wprost, a nie przypadkiem.

#Kluczowe funkcjonalności i użyte technologie

Zakres, który wyszedł z analizy wymagań, obejmował kilka obszarów.

Układ responsywny był wtedy decyzją, a nie standardem. Ruch mobilny w branży usług lokalnych ma tę właściwość, że rośnie szybciej niż w innych kategoriach, bo pytanie o warsztat pada zwykle w drodze albo na parkingu, a nie przy biurku. Priorytetem na wąskim ekranie były więc numer telefonu, adres i dojazd, a dopiero potem opis oferty.

Moduł rezerwacji łączy kalendarz z bazą i wystawia dostępność przez własne punkty końcowe interfejsu, opisane wyżej. Warto dodać, dlaczego punkty własne, a nie gotowa wtyczka rezerwacyjna. Wtyczki tego rodzaju modelują wizytę u fryzjera albo u lekarza, czyli jedną osobę i jeden fotel. Warsztat ma dwie osie naraz i zmienny czas trwania usługi, a przerobienie cudzego modelu tak, żeby przyjął tę drugą oś, kosztuje więcej niż napisanie własnego zapisu rezerwacji.

Integracja z serwisami społecznościowymi pobiera wpisy i opinie i pokazuje je na stronie. To jest miejsce, w którym strona uzależnia się od cudzego serwera, więc zachowanie przy jego niedostępności trzeba było rozstrzygnąć od razu. Odpowiedź jest buforowana, a gdy źródło nie odpowiada, sekcja pokazuje ostatnią znaną treść albo nie pokazuje się wcale. Pusty prostokąt z komunikatem o błędzie na stronie warsztatu czyta się jak awaria całej witryny, a nie jak chwilowy problem zewnętrznego interfejsu.

Optymalizacja pod wyszukiwarki opierała się na znacznikach semantycznych HTML5, uporządkowanych metadanych i danych strukturalnych opisujących firmę lokalną. Przy usłudze lokalnej najważniejsze są trzy rzeczy podane maszynowo: nazwa, adres i telefon w jednej, niezmiennej postaci, godziny otwarcia oraz obszar obsługiwany. Rozjazd między adresem na stronie a adresem w wizytówkach zewnętrznych jest typowym błędem, który potrafi żyć latami, bo dla człowieka czytającego stronę wygląda niewinnie.

System zarządzania treścią stoi na WordPressie, co przy takim kliencie ma konkretne uzasadnienie. Warsztat nie ma redakcji. Zmiany wprowadza właściciel albo osoba z biura, między jednym a drugim zleceniem, więc edycja musi być możliwa bez wiedzy technicznej i bez ryzyka, że zmiana godzin otwarcia zepsuje układ strony.

Moduł kontaktowy zawiera formularz, mapę i dojazd. O mapie niżej, bo to osobny problem.

#Wyzwania i rozwiązania programistyczne

Pierwszym wyzwaniem była sama rezerwacja, opisana wyżej, a w niej zapis, który nie pozwala dwóm klientom zająć tego samego terminu.

Drugim była prędkość ładowania. Praca poszła w trzy miejsca: kompresję zdjęć, buforowanie treści, które zmieniają się rzadko, oraz ograniczenie liczby plików stylów i skryptów. To ostatnie miało w 2012 roku wagę, której dziś nie ma, bo przeglądarki łączyły się z serwerem po protokole otwierającym osobne połączenie na plik i utrzymującym limit równoległych pobrań. Sklejenie dziesięciu arkuszy w jeden nie było wtedy kosmetyką, tylko usunięciem dziewięciu rund komunikacji z serwerem.

Trzecim wyzwaniem była migracja treści. Klient miał wcześniejszą wersję strony i część materiałów istniała już tylko jako zarchiwizowane kopie, które odtworzyliśmy korzystając z Web Archive. Przy takiej migracji łatwo przenieść teksty i przeoczyć rzecz ważniejszą, czyli adresy. Strona, która żyła kilka lat, ma linki w wizytówkach lokalnych, w katalogach branżowych i w wiadomościach wysłanych klientom, a te linki są poza naszą kontrolą i nikt ich nie poprawi. Każdemu staremu adresowi trzeba więc przypisać nowy i zrobić to przekierowaniem trwałym, a nie zbiorczym odesłaniem wszystkiego na stronę główną. Zbiorcze odesłanie wygląda w przeglądarce dobrze, bo nie pokazuje błędu, i jednocześnie kasuje całą wartość, jaką stary adres zdążył zebrać.

Czwartym wyzwaniem były moduły dopasowujące treść do odwiedzającego. Każdy taki moduł stoi w sprzeczności z buforowaniem strony, bo cache opłaca się dokładnie dlatego, że wielu osobom oddaje ten sam dokument. Rozwiązanie polega na rozdzieleniu: szkielet strony i opis oferty są wspólne i buforowane, a fragmenty zależne od odwiedzającego dociągają się osobno po załadowaniu. Bez tego rozdzielenia każda personalizacja unieważnia pamięć podręczną całego serwisu i trzeba wybrać jedno z dwojga.

#Mapa, czyli najdroższy element strony kontaktowej

Mapa dojazdu zasługuje na osobny akapit, bo jest elementem, który klient zamawia jednym zdaniem, a który kosztuje więcej niż cała reszta strony kontaktowej razem wzięta.

Osadzona mapa to obcy skrypt, obce style i seria zapytań o kafelki obrazu, wszystko z serwera, na który nie mamy wpływu. Na stronie warsztatu ten jeden komponent bywa cięższy niż komplet treści. Do tego uruchamia się u każdego odwiedzającego, także u tego, który wszedł po numer telefonu i wyjdzie po dziesięciu sekundach.

Rozstrzygnięcie polega na tym, żeby mapa nie ładowała się razem ze stroną. Domyślnie widoczny jest statyczny obraz z zaznaczonym punktem i adresem obok, a pełna mapa uruchamia się dopiero, gdy ktoś jej dotknie. Osoba, która potrzebowała adresu, dostaje go natychmiast, a osoba, która chce poprowadzić trasę, klika raz więcej i dostaje pełne narzędzie. Kolejność jest tu odwrotna do tej, którą podpowiada intuicja, bo zwykle zakłada się, że cięższa wersja ma być domyślna.

#Narzędzia i technologie

WordPress jako system zarządzania treścią, PHP i MySQL po stronie serwera, HTML5, CSS3 i JavaScript w warstwie prezentacji, siatka i komponenty z frameworka Bootstrap dla układu responsywnego.

Do tego dochodzą narzędzia utrzymaniowe: kopie zapasowe wykonywane automatycznie, wersjonowanie kodu oraz monitorowanie widoczności w wyszukiwarce. Kopie zapasowe zasługują na to samo zastrzeżenie, które powtarzam przy każdym projekcie: kopia, której nikt nigdy nie odtworzył, jest plikiem, a nie zabezpieczeniem. Odtworzenie trzeba wykonać przynajmniej raz, na osobnym środowisku, bo braki w kopii ujawniają się wyłącznie przy odtwarzaniu, a wtedy zwykle jest już powód, żeby się spieszyć.

Osobna uwaga dotyczy wtyczek. Wtyczki funkcjonalne są w tym projekcie użyte tam, gdzie mają sens, natomiast bezpieczeństwo nie opiera się na wtyczce. Wtyczka bezpieczeństwa jest kodem działającym wewnątrz aplikacji, którą ma chronić, więc uruchamia się dopiero wtedy, gdy żądanie już do tej aplikacji doszło. Filtrowanie ruchu przed aplikacją, aktualny silnik, ograniczony dostęp do panelu i sprawna kopia zapasowa dają więcej niż panel z licznikiem zablokowanych prób.

#Widoczność lokalna i granica tego, co mogę obiecać

Warsztat samochodowy konkuruje w promieniu kilkunastu kilometrów, a nie w internecie jako takim. To zmienia sens całej pracy nad wyszukiwarką, bo nie chodzi o frazę ogólną, tylko o to, żeby strona odpowiadała na pytanie zadane z konkretnego miejsca i w konkretnej sprawie.

Trzy rzeczy robi się tu po stronie kodu. Pierwsza to dane strukturalne opisujące firmę lokalną, w których nazwa, adres, telefon, godziny otwarcia i zakres usług są podane maszynowo, a nie tylko wypisane w stopce. Druga to spójność tych danych ze wszystkim, co firma ma poza własną stroną, bo rozbieżny zapis adresu jest dla systemu zewnętrznego sygnałem, że to mogą być dwie różne firmy. Trzecia to osobne strony dla osobnych usług, zamiast jednej strony z listą wszystkiego, bo pytanie zadawane przez człowieka dotyczy jednej rzeczy naraz.

Jest też granica, której nie przekraczam w opisie takiego wdrożenia. Nie podaję, na której pozycji strona się znalazła ani o ile wzrosła liczba zapytań, ponieważ pomiary z 2012 roku nie są dziś dostępne, a liczba podana bez możliwości sprawdzenia jest tylko liczbą. Zastąpienie jej oceną w rodzaju “znaczna poprawa widoczności” nie jest wersją ostrożniejszą, tylko tą samą rzeczą pozbawioną jednostki. Zostaje więc opis tego, co zostało zrobione, i milczenie tam, gdzie brakuje dowodu.

#Wsparcie i utrzymanie strony na WordPress

Utrzymanie obejmuje naprawę usterek, instalowanie aktualizacji silnika, motywu i wtyczek, przegląd logów, tworzenie kopii zapasowych zgodnie z ustaloną polityką oraz drobne zmiany w treści i wyglądzie.

Przy stronie z modułem rezerwacji dochodzi obowiązek, którego nie ma w zwykłej witrynie informacyjnej. Aktualizacja, która dotyka warstwy formularzy albo obsługi dat, musi zostać sprawdzona na kopii produkcji, z realnym zestawem rezerwacji, a nie na czystej instalacji. Powód jest prozaiczny: na pustej instalacji kalendarz zawsze jest wolny, więc żaden test nie dotknie tej ścieżki, na której moduł faktycznie może się zepsuć, czyli kolizji terminów i przypadków brzegowych na granicy dnia roboczego.

Warto też powiedzieć wprost, czego utrzymanie nie obejmuje. Nie obejmuje gwarancji, że aktualizacja nigdy niczego nie zepsuje, bo takiej gwarancji nie da żadna strona zbudowana z komponentów rozwijanych przez niezależne zespoły. Obejmuje natomiast to, że zmiana jest wykonywana najpierw poza produkcją, a wycofanie jej jest przygotowane wcześniej, a nie wymyślane w trakcie.

#Podsumowanie i wstępna analiza wymagań klienta

Planowanie zaczęło się od zestawu pytań, na które trzeba było odpowiedzieć, zanim cokolwiek powstało.

Pierwsze dotyczyło celu i odbiorcy: prezentacja usług warsztatu i ułatwienie kontaktu osobom szukającym naprawy albo diagnostyki. Drugie dotyczyło listy wymagań, która po stronie klienta już istniała i zawierała rezerwację terminów, powiązanie z serwisami społecznościowymi i dopasowanie treści do odwiedzającego. Trzecie dotyczyło szczegółów integracji z istniejącą bazą danych. Czwarte dotyczyło harmonogramu, który pozwolił wdrażać kolejne funkcje etapami, zamiast czekać z uruchomieniem na komplet. Piąte dotyczyło przykładów, których klient podał kilka, wskazując w nich czytelny interfejs i przejrzystą prezentację oferty. Szóste dotyczyło tego, co z poprzedniej wersji strony przenieść, a co napisać od nowa. Siódme dotyczyło ograniczeń budżetowych i możliwości rozłożenia zakresu w czasie.

Z tych odpowiedzi wynikła kolejność prac. Najpierw rzeczy, po które ludzie przychodzą na stronę warsztatu, czyli oferta, dojazd i kontakt. Potem rezerwacja, która jest najbardziej złożonym elementem i jednocześnie jedynym, który realnie zmienia sposób pracy biura. Na końcu integracje zewnętrzne, bo są najmniej krytyczne i najłatwiej je dołożyć po starcie.

Co z tego wdrożenia przenosi się dalej, to sposób pracy: sprawdzanie dostępności zasobu po stronie serwera w momencie zapisu, wyłączenie widoków zależnych od czasu z pamięci podręcznej, odroczenie ciężkich komponentów zewnętrznych do momentu, w którym ktoś ich potrzebuje, oraz mapowanie starych adresów pojedynczo przy migracji. Nie przenosi się model treści tego projektu ani jego integracje, bo powstały pod jeden warsztat i pod brief z kategorii Strony www. Kolejne wdrożenie zaczyna się od analizy zakresu, a wycena idzie po niej.