Witaj, (dziwny) świecie
Strona główna Google to fascynujące środowisko do kodowania. Wiąże się to z wieloma trudnymi ograniczeniami. Szczególnie ważna jest dla nas szybkość i opóźnienia, konieczność zapewnienia zgodności z różnymi przeglądarkami i działań w różnych okolicznościach.
Chodzi mi o doodle Google – specjalne ilustracje, które czasami zastępują nasze logo. Choć moja przygoda z piórami i pędzlami od dawna ma w sobie ten charakterystyczny smak, często korzystam z interaktywnych narzędzi.
Każdy interaktywny doodle, który napisałem (Pac-Man, Jules Verne, Światowa Targi), i wiele, przy których pracowałem, były w równym stopniu futurystyczne i anachronistyczne: doskonałe możliwości tworzenia pieprzowych funkcji internetowych z najnowocześniejszymi funkcjami internetowymi... i surowego pragmatyzmu w zakresie zgodności z różnymi przeglądarkami.
Z każdego interaktywnego doodla wiele się uczymy, a ostatnia minigra im. Stanisława Lema nie była wyjątkiem. Zawierała 17 tys. wierszy kodu JavaScriptu – po raz pierwszy w historii doodli testowała wiele różnych rzeczy. Dzisiaj przedstawię ten kod – być może znajdziesz tam coś interesującego lub wskażę moje błędy – i omówię trochę o tym.
Wyświetl kod doodle'a Stanisława Lema »
Pamiętaj, że strona główna Google nie jest miejscem prezentacji technicznych. Nasze doodle chcą uczcić określone osoby i wydarzenia. Chcemy to zrobić, korzystając z najlepszej sztuki oraz najlepszych technologii, jakie możemy przywołać. Nigdy nie doceniamy technologii dla samego osiągnięcia technologii. Dlatego trzeba dokładnie przyjrzeć się dostępnemu elementowi powszechnie przyjętego języka HTML5 i sprawdzić, czy pozwala on ulepszyć doodla, nie rozpraszając go ani nie przytłaczając.
Omówmy więc niektóre z nowoczesnych technologii internetowych, które znalazły swoje miejsce w doodle Stanisława Lema.
Grafika za pomocą DOM i kanwy
Canvas to niezwykle wydajne rozwiązanie, które stworzyliśmy z myślą o osiągnięciu tego, co chcemy osiągnąć w tym doodlu. Jednak niektóre starsze przeglądarki, na których nam zależy, nie obsługiwały. I chociaż dosłownie dzielimy biuro z osobą, która stworzyła poza tym doskonałe ekscanvas, zdecydowałam się na inny sposób.
Stworzyłem mechanizm graficzny, który wyodrębnia graficzne podstawowe elementy nazywane „prostokami”, a następnie renderuje je za pomocą płótna lub DOM, jeśli obiekt canvas jest niedostępny.
Takie podejście niesie ze sobą kilka interesujących wyzwań – na przykład przeniesienie lub zmianę obiektu w DOM ma natychmiastowe konsekwencje, podczas gdy w przypadku obszaru roboczego występuje konkretny moment, gdy wszystko jest narysowane w tym samym czasie. (Zdecydowałem się mieć tylko jedno płótno, wyczyścić je i rysować od zera w każdej klatce. Zbyt wiele, dosłownie, ruchomych części z jednej strony, a z drugiej – zbyt wiele, by dzielić je na kilka nakładających się elementów i aktualizować je wybiórczo.
Niestety przejście na obiekty canvas nie jest tak proste, jak zduplikowanie tła CSS za pomocą drawImage(): podczas łączenia elementów za pomocą DOM tracisz wiele rzeczy, które otrzymujesz bezpłatnie, a przede wszystkim nakładanie warstw z z-indexami i zdarzeniami myszy.
Już pozbyłam się z-indeksu, stosując koncepcję „płaszczyzn”.
Doodle definiował pewną liczbę płaszczyzn – od nieba daleko w tle po wskaźnik myszy znajdujący się przed wszystkim. Każdy aktor w doodlu musiał zdecydować, do którego kierowcy należy ten element (możliwość wprowadzenia niewielkich poprawek plus/minus w płaszczyźnie za pomocą funkcji planeCorrection).
W przypadku renderowania za pomocą modelu DOM płaszczyzny są po prostu przekształcane w z-index. Jeśli jednak renderujemy obiekt na płótnie, musimy najpierw uporządkować prostokąty na podstawie ich płaszczyzn. Ponieważ wykonywanie takich czynności jest kosztowne za każdym razem, kolejność jest przeliczana tylko wtedy, gdy użytkownik zostaje dodany lub przenoszony do innej płaszczyzny.
Jeśli chodzi o zdarzenia myszy, też to wyciągnęliśmy... Zarówno w modelu DOM, jak i w obiektach canvas używam dodatkowych, całkowicie przezroczystych elementów DOM o wysokiej wartości z-index, których funkcja to reagowanie tylko na najechanie/położenie kursora myszy oraz na kliknięcia i dotknięcia.
Tym doodlem chcieliśmy zburzyć czwartą ścianę. Powyższy mechanizm umożliwił nam połączenie aktorów opartych na obiektach canvas i DOM. Na przykład eksplozje w finale występują zarówno w obiekcie obiektów we wszechświecie, jak i w DOM dla pozostałej części strony głównej Google. Ptak, zazwyczaj lecący dookoła i przypięty przez naszą postarzaną maskę jak każdy inny aktor, postanawia uniknąć kłopotów podczas strzelania i zatrzymuje się na przycisku „Szczęśliwy traf”. Chodzi o to, żeby ptak zostawił płótno i przekształcił się w element DOM (i na odwrót), co powinno być całkowicie niezrozumiałe dla naszych użytkowników.
liczbę klatek,
Znajomość bieżącej liczby klatek i reagowanie na zbyt wolne (i za szybkie) było bardzo ważnym elementem naszego silnika. Przeglądarki nie podają liczby klatek, więc musimy ją obliczyć sami.
Zacząłem od użycia elementu requestAnimationFrame i wróciłem do starszej wersji setTimeout, jeśli ta pierwsza była niedostępna.
requestAnimationFrame mądrze oszczędza procesor w niektórych sytuacjach – chociaż robimy to sami, co wyjaśniamy poniżej, ale po prostu pozwala nam uzyskać większą liczbę klatek niż setTimeout.
Obliczanie bieżącej liczby klatek jest proste, ale podlega gwałtownym zmianom – np. może ona szybko spadać, gdy inna aplikacja przez jakiś czas przeciąża komputer. Dlatego obliczamy „średnią” liczbę klatek tylko dla każdych 100 pasków fizycznych i na tej podstawie podejmujemy decyzje.
Jakiego rodzaju decyzje?
Jeśli liczba klatek jest większa niż 60 kl./s, ograniczamy ją. Obecnie
requestAnimationFramew niektórych wersjach Firefoksa nie ma górnego limitu liczby klatek, więc nie ma sensu marnować procesora. Pamiętaj, że w rzeczywistości limit ten wynosi 65 klatek na sekundę z powodu błędów zaokrąglania, które powodują, że w innych przeglądarkach ta liczba jest nieco wyższa niż 60 kl./s. Nie chcemy, aby przez pomyłkę ograniczaliśmy tę szybkość.Jeśli liczba klatek jest mniejsza niż 10 kl./s, po prostu spowalniamy silnik, a nie pomijamy klatki. To sugestia przegrania, ale myślałam, że nadmierne pomijanie klatek byłoby bardziej skomplikowane niż wolniejsza (ale spójna) gra. Jest też jeszcze jeden miły skutek uboczny: jeśli system zacznie działać wolniej, użytkownik nie zaczuje niespodziewanego skoku do przodu, bo silnik rozpaczliwie się załatwia. W przypadku Pac-Mana zrobiłem to trochę inaczej, ale minimalna liczba klatek jest lepsza.
Możemy też pomyśleć o uproszczeniu grafiki, gdy liczba klatek na sekundę jest niebezpiecznie niska. Nie robimy tego w przypadku doodla Lema, z wyjątkiem wskaźnika myszy (więcej o tym dowiesz się poniżej), ale hipotetycznie możemy utracić niektóre zbędne animacje, aby doodle wyglądał płynnie nawet na wolniejszych komputerach.
Mamy też pojęcie znacznika fizycznego i znacznika logicznego. Pierwszy pochodzi z requestAnimationFrame/setTimeout. W normalnej rozgrywce współczynnik wynosi 1:1, ale przy przewijaniu do przodu dodajemy więcej wskazówek logicznych dla każdego fizycznego znacznika (do 1:5). Dzięki temu możemy wykonać wszystkie niezbędne obliczenia dla każdego znacznika logicznego, ale tylko ostatni z nich będzie aktualizować elementy na ekranie.
Analiza porównawcza
Można założyć, że (i naprawdę na początku można było stwierdzić, że kanwa będzie szybsza niż DOM, jeśli jest dostępna. Nie zawsze tak jest. Podczas testów okazało się, że Opera w wersjach 10.0–10.1 na komputerach Mac i Firefox w systemie Linux działają szybciej przy przenoszeniu elementów DOM.
W idealnym świecie doodle dyskretnie porównywałby różne techniki graficzne – elementy DOM przesuwały się za pomocą style.left i style.top, rysowały po płótnie, a może nawet elementy DOM przenoszone za pomocą przekształceń CSS3
a następnie przełącz na tę z największą liczbą klatek. Zacząłem pisać kod, ale stwierdziłem, że przynajmniej moja metoda testów porównawczych jest mało wiarygodna i wymaga czasu. Czas, którego nie mamy na stronie głównej – zależy nam na szybkości, więc doodle musi pokazywać się od razu, a rozgrywka zaczyna się zaraz po kliknięciu.
Ostatecznie programowanie w internecie sprowadza się do tego,
co trzeba zrobić. Spojrzeliśmy za ramię, aby sprawdzić, czy nikt nie patrzy, a potem po prostu napisałam kod Opera 10
i Firefox. W następnym życiu wrócę jako tag <marquee>.
Oszczędzanie procesora
Wiesz, że ten znajomy, który odwiedza Twój dom, ogląda finał sezonu Breaking Bad, to dla Ciebie zepsuje, a potem usuwa go z DVR? Nie chcesz być tym gościem, prawda?
Tak więc to najgorsza analogia w historii. Tym nie chcemy, ale naszym doodlem jest nasz przywilej – możliwość otwarcia czyjejś karty przeglądarki to przywilej, a zbieranie cykli procesora lub rozpraszanie użytkownika mogłoby nas zniechęcić. Dlatego, jeśli nikt nie będzie się bawić z doodlem (bez kliknięć, myszy, ruchów myszą ani naciśnięć klawiszy), chcemy, by w końcu uśpił.
Kiedy?
- po 18 sekundach na stronie głównej (gry zręcznościowe nazywane trybem przyciągania);
- po 180 sekundach, jeśli karta jest zaznaczona.
- po 30 sekundach, jeśli karta nie jest zaznaczona (np. użytkownik przeszedł do innego okna, ale być może nadal ogląda doodle w nieaktywnej karcie);
- natychmiast, jeśli karta stanie się niewidoczna (np. użytkownik przeszedł na inną kartę w tym samym oknie – nie ma sensu zmarnować cykli, gdy nikt nas nie zobaczy);
Skąd wiadomo, że karta jest obecnie aktywna? Dopasowujemy się do window.focus i window.blur.
Skąd mamy wiedzieć, że karta jest widoczna? Używamy nowego interfejsu API widoczności strony i reagujemy na odpowiednie zdarzenie.
Powyższe przedziały czasu są dla nas bardziej wybaczalne niż zwykle. Zaadaptowałam je do tego konkretnego doodla, które ma dużo nastrojowych animacji (przede wszystkim nieba i ptaków). W idealnej sytuacji limit czasu zostałby ograniczony do interakcji w grze – np. zaraz po wylądowaniu ptak mógł zapowiedzieć doodle'a, że może iść spać, ale tego nie robiłem pod koniec.
Ponieważ niebo jest zawsze w ruchu, po zasypianiu i pobudce doodle nie tylko się zatrzymuje i budzi – zwalnia, zanim się zatrzyma, i na odwrót przy wznowieniu, zwiększeniu lub zmniejszeniu liczby wskazań logicznych na fizyczne kliknięcie zgodnie z potrzebą.
Przejścia, przekształcenia, zdarzenia
Jedną z zalet języka HTML od zawsze jest to, że można samemu go ulepszać. Jeśli w zwykłej ofercie języków HTML i CSS coś się nie sprawdza, można wykorzystać JavaScript do jego rozszerzania. Niestety często trzeba w tym celu zacząć od zera. Przejścia CSS3 są świetne, ale nie można dodawać ich do nowych typów przejść ani używać ich do innych celów. Kolejny przykład: przekształcenia CSS3 są świetne w przypadku DOM, ale gdy przejdziesz do obszaru roboczego, stajesz się już pewny siebie.
Te i inne problemy sprawiają, że doodle Lem ma własny silnik przejść i przekształcenia. Wbudowane możliwości nie są w porównaniu z CSS3 porównywalne z CSS3, ale bez względu na to, co zrobimy, system działa konsekwentnie i daje nam znacznie większą kontrolę.
Zacząłem od prostego systemu działań (zdarzeń), czyli osi czasu, która uruchamia zdarzenia w przyszłości bez użycia setTimeout. Czas doodla w każdym momencie może odbiegać od czasu fizycznego w miarę jego przyspieszania (przewijania do przodu) lub wolniej (mała liczba klatek lub zasypianie, aby oszczędzać procesor) lub też całkowicie się zatrzymywać (oczekiwanie na zakończenie wczytywania obrazów).
Przejścia to po prostu inny rodzaj działań. Oprócz podstawowych ruchów i obrotu obsługujemy też ruchy względne (np. przesunięcie o 10 pikseli w prawo), niestandardowe elementy, takie jak drżenie, a także animacje obrazu klatki kluczowej.
Obrót odbywa się też ręcznie: obiekty, które należy obracać, mają różne sprite’y dla różnych kątów. Głównym powodem jest to, że zarówno w CSS3, jak i w rotacji canvas wprowadzaliśmy artefakty wizualne, które uważaliśmy za nieakceptowalne. Poza tym artefakty te były różne w zależności od platformy.
Biorąc pod uwagę, że niektóre obracające się obiekty są przyłączone do innych obracających się obiektów (przykładem jest ręka robota połączona z dolnym ramieniem, która jest przyłączona do obracającego się przedramienia), trzeba było też utworzyć źródło transformacji biednego człowieka w postaci przestawień.
Wszystko to wymaga ogromnej pracy, która ostatecznie obejmuje już podstawy do pracy nad HTML5. Czasem jednak natywna obsługa bywa niewystarczająca i przychodzi czas na rewolucję.
Zarządzanie obrazami i sprite’ami
Silnik służy nie tylko do rysowania doodla,
ale także do pracy nad nim. Niektóre parametry debugowania znajdziesz powyżej – pozostałe znajdziesz tutaj: engine.readDebugParams.
Spriting to dobrze znana technika, której również używamy w przypadku doodli. Pozwala nam to oszczędzić bajty i skrócić czas wczytywania, a dodatkowo ułatwia wstępne wczytywanie.
Utrudnia to jednak również tworzenie aplikacji – każda zmiana na zdjęciach
wymagała wykonania sprikserów (w dużej mierze zautomatyzowanej, ale i takiej niewygodnej). Dlatego wyszukiwarka obsługuje nieprzetworzone obrazy na potrzeby programowania i sprite’y na potrzeby środowiska produkcyjnego engine.useSprites – oba te elementy są uwzględnione w kodzie źródłowym.
Umożliwiamy też wstępne wczytywanie obrazów i wstrzymywanie doodla, jeśli nie wczytają się na czas – wraz ze sztucznym paskiem postępu. (Sztuczna inteligencja, bo niestety nawet język HTML5 nie potrafi określić, jaka część pliku graficznego została już wczytana).
W przypadku niektórych scen używamy więcej niż 1 sprite’a, nie za bardzo, aby przyspieszyć wczytywanie przy użyciu połączeń równoległych, ale z powodu ograniczenia do 3/5 mln pikseli w przypadku obrazów w iOS.
Gdzie HTML5 mieści się w tym wszystkim? Powyżej nie ma tu za dużo tego, ale narzędzie, które napisałem do spritingu/przycinania, to zupełnie nowe technologie internetowe: canvas, bloby, a[download]. Jedną z ekscytujących cech języka HTML jest to, że powoli zastępuje on rzeczy, które wcześniej trzeba było robić poza przeglądarką. Jedyną potrzebą, jaką musieliśmy zrobić, była optymalizacja plików PNG.
Zapisuję stan między rozgrywkami
Światy Lem zawsze wydawały się duże, żywe i realistyczne. Jego historie zaczynały się zwykle bez żadnych wyjaśnień. Pierwsza strona zaczynała się w Medias res, a czytelnik musiał szukać sposobu, w jaki radzi sobie z nimi.
„Cyberiada” nie była wyjątkiem, ale chcieliśmy odtworzyć to uczucie, Zaczynamy od tego, by nie wyjaśniać nadmiernie sprawy. Kolejnym istotnym elementem jest randomizacja, która naszym zdaniem odpowiadała mechanicznemu charakterowi wszechświata książki. Mamy wiele funkcji pomocniczych dotyczących losowości, które stosujemy w wielu, wielu miejscach.
Chcieliśmy też zwiększyć możliwość ponownego odtwarzania w inny sposób. Musieliśmy więc wiedzieć, ile razy doodle skończył się rysować. Historycznie poprawnym rozwiązaniem technologicznym jest plik cookie, ale to nie działa na stronie głównej Google – każdy plik cookie zwiększa ładunek każdej strony. I znów, przywiązujemy dużą wagę do szybkości i czasu oczekiwania.
Na szczęście HTML5 zapewnia nam funkcję Web Storage, która jest bardzo prosta w użyciu, dzięki czemu możemy zapisywać i zapamiętywać ogólną liczbę odtworzeń oraz ostatnią scenę odtwarzaną przez użytkownika – z znacznie większą precyzją niż pliki cookie.
Co robimy z tymi informacjami?
- wyświetlamy przycisk przewijania do przodu, który pozwala na przejrzenie przerywników już wcześniej oglądanych.
- podczas finału pokazujemy różne elementy (N).
- nieco zwiększamy trudności poziomu strzelania,
- w trzeciej i kolejnych odcinkach pokazujemy małego smoka z niespodzianką, czyli smoka z innej bajki.
Jest kilka parametrów debugowania, które to umożliwiają:
?doodle-debug&doodle-first-run– udawaj, że to pierwszy bieg?doodle-debug&doodle-second-run– udawaj, że to drugi bieg?doodle-debug&doodle-old-run– udawaj, że to stary bieg
Urządzenia z ekranami dotykowymi
Chcieliśmy, by doodle wyglądał jak u siebie na urządzeniach dotykowych. Najnowocześniejsze urządzenia są na tyle wydajne, że świetnie się bawi, a granie dotykiem jest o wiele przyjemniejsze niż klikanie.
Należy wprowadzić pewne zmiany od razu, aby zwiększyć wygodę użytkowników. Początkowo nasz wskaźnik myszy był jedynym miejscem, które sygnalizowało moment, w którym miała miejsce scena sekwencyjna lub część nieinteraktywna. Później dodaliśmy mały wskaźnik w prawym dolnym rogu, dzięki czemu nie trzeba było polegać tylko na wskaźnikach myszy (ponieważ nie ma ich na urządzeniach dotykowych).
| Normalnie | Popularny | Klikalny | Kliknięto | |
|---|---|---|---|---|
| W toku |  |
 |
 |
 |
| Ostateczna |  v |
 |
 |
 |
Większość czynności wyszła od razu. Jednak szybkie, spontaniczne testy łatwości obsługi dotykowej wykazały dwa problemy: niektóre cele były zbyt trudne do kliknięcia, a szybkie dotknięcia zostały zignorowane, ponieważ właśnie zastąpiliśmy zdarzenia kliknięcia myszą.
Użycie osobnych, klikalnych przezroczystych elementów DOM bardzo tu pomogły, bo można było zmienić ich rozmiar niezależnie od elementów wizualnych. Wprowadziłam dodatkowe 15-pikselowe dopełnienie na urządzeniach dotykowych i używałam go przy tworzeniu klikalnych elementów. (Dodałem też 5-pikselowe dopełnienie pod kątem myszy. Dlatego bardzo ucieszył mnie pan Fitts.
Jeśli chodzi o inny problem, tylko podłączyłem i przetestowałem(-am) odpowiednie moduły obsługi dotykowej i końcowej funkcji, zamiast polegać na kliknięciu myszą.
Używamy też bardziej nowoczesnych właściwości stylów, aby usuwać niektóre funkcje dotykowe, które domyślnie przeglądarki WebKit dodają (kliknij podświetlenie, kliknij objaśnienie).
Jak sprawdzimy, czy dane urządzenie, na którym jest doodle, obsługuje dotyk? Leniwie. Zamiast rozglądać się wcześniej, użyliśmy połączonych IQ, aby odliczyć, że urządzenie obsługuje dotyk...
Dostosowywanie wskaźnika myszy
Jednak nie wszystkie elementy są oparte na dotyku. Jedną z naszych wskazówek było umieszczenie jak największej liczby rzeczy w kosmosie doodla. Mały pasek boczny (przewinięcie do przodu, znak zapytania), etykietka, a nawet wskaźnik myszy.
Jak dostosować wskaźnik myszy? Niektóre przeglądarki umożliwiają zmianę kursora myszy za pomocą linku do dostosowanego pliku graficznego. Nie jest to jednak dobrze obsługiwane i w związku z czym wiąże się z pewnymi ograniczeniami.
Jeśli nie, to co? Dlaczego nie pokazanie wskaźnika myszy jako kolejnego aktora w doodle? To się sprawdza, ale wiąże się z kilkoma zastrzeżeniami, w tym:
- Musisz mieć możliwość usunięcia natywnego wskaźnika myszy
- musisz całkiem dobrze zsynchronizować wskaźnik myszy z „prawdziwym”,
Pierwsze z nich jest trudne. CSS3 pozwala na użycie elementu cursor: none, ale
niektórych przeglądarek go nie obsługują. Musieliśmy też zastosować się do ćwiczeń gimnastycznych: użycie pustego pliku .cur jako kreacji zastępczej, określenie konkretnych zachowań niektórych przeglądarek, a nawet zakodowanie innych na stałe w innych przeglądarkach.
Z perspektywy drugiego jest stosunkowo banalne, ale gdy kursor myszy jest tylko dodatkową częścią doodla, odziedziczy też wszystkie jego problemy. Najważniejszy? Jeśli liczba klatek doodla jest niska, wskaźnik myszy też będzie mieć małą liczbę klatek, co ma poważne konsekwencje. (Osoby, które w przeszłości używały Amigi firmy Commodore, teraz energicznie kiwają;
Jednym z bardziej złożonych rozwiązań tego problemu jest odłączenie wskaźnika myszy od zwykłej pętli aktualizacji. Zrobiliśmy to w alternatywnym świecie, w którym nie muszę spać. Prostsze rozwiązanie tego problemu? Po prostu przywracamy natywny wskaźnik myszy, jeśli krocząca liczba klatek spada poniżej 20 kl./s. (W tym przypadku przydatna jest krocząca liczba klatek. Jeśli zareagujemy na bieżącą liczbę klatek i jeśli spadnie ona około 20 kl./s, niestandardowy wskaźnik myszy będzie ukrywany i wyświetlany przez cały czas. W ten sposób dochodzimy do:
| Zakres liczby klatek | Zachowanie |
|---|---|
| > 10 kl./s | Spowalniaj grę, aby nie pomijać więcej klatek. |
| 10–20 kl./s | Użyj natywnego wskaźnika myszy zamiast wskaźnika niestandardowego. |
| 20–60 kl./s | Normalne działanie. |
| > 60 kl./s | Zmniejszaj głośność, aby liczba klatek nie przekraczała tej wartości. |
Wskaźnik myszy na Macu jest ciemny, a na PC biały. Dlaczego? Bo wojny platformowe wymagają paliwa nawet w fikcyjnych wszechświatach.
Podsumowanie
Nie jest to idealny mechanizm, ale to nie jest dobry mechanizm. Został on stworzony razem z doodlem Lem i jest z nim bardzo charakterystyczny. To prawda. „Przedwczesna optymalizacja to źródło zła”, jak stwierdził Don Knuth, i nie wierzę, że pisanie silnika w oderwaniu od innych, a późniejsze zastosowanie go ma sens, bo praktyka dostarcza teorii w takim samym stopniu, jak teoria. W moim przypadku kod został wyrzucony, kilka jego części przeredagowanych, a wiele popularnych fragmentów dostrzegł w postach, a nie ante faktum. W końcu to, co udało nam się osiągnąć, pozwoliło nam uczcić karierę Stanisława Lema i rysunki Daniela Mróza w najlepszy możliwy sposób.
Mam nadzieję, że udało mi się wyjaśnić niektóre wybory i kompromisy związane z projektowaniem, jakie musieliśmy podjąć – oraz sposób, w jaki używamy HTML5 w konkretnym, rzeczywistym świecie. Teraz pobawmy się kodem źródłowym i daj nam znać, co o nim myślisz.
Zrobiłam to samodzielnie. Poniżej widać, jak to wyglądało na żywo w ostatnich dniach, odliczając czas do wczesnych godzin 23 listopada 2011 roku w Rosji – w pierwszej strefie czasowej, w której widać doodle Lemów. Może i głupkowate, ale tak jak doodle, rzeczy, które wydają się nieistotne, mają głębsze znaczenie. Taki licznik był fajnym „testem obciążeniowym” dla silnika.
To jeden ze sposobów spojrzenia na życie doodla Google – miesiące pracy, testów, 48 godzin pieczenia – wszystko to w coś, w co ludzie grają przez 5 minut. Mamy nadzieję, że te 5 minut miło spędzisz w ciągu tych 5 minut. Baw się dobrze.