^
Build for everyone Google

Aplikacje Google’a dla iOS w końcu zaczną wyglądać ładnie

Jaromir Kopp

12 października 2021

Niektórzy z nas nie wyobrażają sobie życia bez przynajmniej kilku usług Google’a. Jednak nawet najwięksi ich zwolennicy coraz częściej narzekali na brzydki i mało intuicyjny interfejs, którego Google trzymał się uparcie oraz kiepską wydajność. Na szczęście w Googlu zrozumieli potrzebę zmian.

Aplikacje Google dla iOS przechodzą na UIKit po dekadzie męczarni z Material Design

Google wycofuje się z niestandardowego UI dla aplikacji iOS Material Design, aby przejść do czystego UIKit.  Tak twierdzi szef projektów Google’a dla platform Apple Jeff Verkoeyen. W serii twittów wyjaśnia on, dlaczego w końcu zapadła decyzja o „zakonserwowaniu” i odłożeniu na bok bardzo nienaturalnego w środowisku iOS interfejsu Material Design oraz tłumaczy, z jakich powodów powstało to dziwactwo niemal 10 lat temu.

Potwierdza się powiedzenie użyte w jednej z pradawnych reklam: „Co jest do wszystkiego, to jest do niczego”. A ja dodam od siebie, że wszystkie próby ujednolicania na siłę wyglądu aplikacji pomiędzy platformami i – co gorsza – robienie to za pomocą niestandardowych metod, to zło równie wielkie jak używanie narzędzi do tworzenia aplikacji na kilka platform naraz. Oczywiście te same aplikacje powinny być podobne w użytkowaniu, ale nie kosztem spójności z interfejsem danej platformy i wydajności. Zrozumieli to w Google, może kiedyś zrozumieją i w Microsofcie. 

A oto jak swoją decyzję tłumaczy Jeff Verkoeyen (ważne, aby dotarło to do projektantów aplikacji Apple w Microsofcie):

Od 2012 roku i premiery Google Maps iOS, mój zespół wspiera tworzenie i utrzymanie wspólnych komponentów UI w Google. Początkowo było to związane z potrzebą wypełnienia luk w języku projektowym UIKit.

Po drodze problemy, które chcieliśmy rozwiązać, przerodziły się z wypełniania luk w UIKit w niwelowanie różnic między językami projektowania na różnych platformach. Powstał Material, a wiele z naszych bibliotek udostępniliśmy jako Material Components for iOS (MDC).

Ale w miarę jak kontynuowaliśmy naszą pogoń za międzyplatformowym parytetem pikseli, nasze komponenty iOS powoli oddalały się od fundamentów platformy Apple, ponieważ te fundamenty również zmieniały się z roku na rok.

Minęło już prawie dziesięć lat, odkąd wyruszyliśmy w tę podróż, a wiele luk, które wypełniał MDC, zostało od tego czasu wypełnionych przez UIKit — często w sposób, który skutkuje znacznie ściślejszą integracją z systemem operacyjnym niż to, co możemy rozsądnie osiągnąć za pomocą niestandardowych rozwiązań.

Dlatego na początku tego roku mój zespół rozpoczął dogłębną analizę tego, co oznacza budowanie charakterystycznego doświadczenia Google na platformach Apple, poprzez krytyczną ocenę przestrzeni „użyteczności” i kluczowych momentów dla marki oraz elementów niezbędnych do osiągnięcia obu tych celów.

Czy przełącznik naprawdę musi być zbudowany niestandardowo, zgodnie z ogólnym systemem projektowania? Czy też może wystarczy po prostu użyć rozwiązania systemowego i iść dalej?

Ta ewolucja naszego podejścia do projektowania dla platform Apple pozwoliła nam połączyć to, co najlepsze w UIKit z najważniejszymi cechami języka projektowego Google.

Rezultat? Wiele niestandardowych komponentów po prostu nie jest już potrzebnych. A tym, które są, poświęcamy teraz więcej uwagi i skupienia.

Paski aplikacji stają się kontrolkami UINavigationControllers. Standardowe kontrolki potrzebują tylko lekkiego brandingu. Listy mogą być zgodne z nowoczesnymi interfejsami API UITableView i widokami kolekcji opartymi na listach. Menu są po prostu UIMenus.

Uproszczenie, ale wciąż pozwalające na wyróżnienie tam, gdzie ma to znaczenie.

Jest to część powodu, dla którego publiczne repo MDC jest w trybie konserwacji. Wraz z wprowadzeniem SwiftUI i znaczących ulepszeń UIKit w iOS 14+, nigdy nie było łatwiej zbudować wspaniałe doświadczenie z marką przy użyciu niewielkiej ilości kodu.

A najlepszy kod to często brak kodu.

Czas, który oszczędzamy, nie budując kodu na zamówienie, przeznaczamy na dopracowywanie szczegółów UX, które sprawiają, że produkty na platformach Apple czują się naprawdę dobrze. Parafrazując Lucasa Pope’a, „pływamy w morzu drobnych rzeczy”, a ja nie mógłbym być bardziej podekscytowany tym nowym kierunkiem.

To wszystko to dopiero początek wielkiej zmiany dla mojego zespołu. Jest wiele rzeczy, które musimy jeszcze dopracować i szukamy projektantów, którzy pomogą nam nadać temu kształt w trakcie dalszego rozwoju.

Jeżeli propozycja podana na końcu Was interesuje, to więcej informacji znajdziecie na stronie ofert pracy w Google.

Jaromir Kopp

Użytkownik komputerów Apple od 1991 roku. Dziennikarz technologiczny, programista i deweloper HomeKit. Propagator przyjaznej i dostępnej technologii. Lubi programować w Swift i czystym C. Tworzy rozwiązania FileMaker. Prowadzi zajęcia z IT i programowania dla dzieci oraz młodzieży, szkoli też seniorów. Współautor serii książek o macOS wydanych przez ProstePoradniki.pl. Projektuje, programuje oraz samodzielnie wykonuje prototypy urządzeń Smart Home. Jeździ rowerem.
Komentarze (2)
L

2 komentarze

  1. mil

    Skoro „te same aplikacje powinny być podobne w użytkowaniu, ale nie kosztem spójności z interfejsem danej platformy i wydajności” to czemu Apple Music na Androidzie wygląda jak aplikacja z iOS, a iTunes dla Windowsa jak Apple Music na macOS? No i iTunes działa słabo.

    • Cicho...

      W punkt 🙂

      Na tym serwisie jednak krytyka jest tylko jednostronna.