Internet to niesamowita platforma, która dociera do użytkowników na całym świecie – na praktycznie każdym urządzeniu. Są łatwe w użyciu i łatwe do udostępniania. Nie musisz niczego instalować. A przede wszystkim jest to otwarty ekosystem, na którym każdy może korzystać.
Niektórych aplikacji nie da się dziś stworzyć i wdrożyć w otwartej sieci. Jest to tzw. luka w aplikacji. Różnica między tym, co jest możliwe w internecie a możliwością reklamy natywnej. Chcemy ją wypełnić. Uważamy, że aplikacje internetowe powinny mieć wszystkie możliwości aplikacji natywnych.
Jak planujemy zaprojektować i wdrożyć te nowe funkcje?
![Schemat procesu zarządzania możliwościami.](https://developer.chrome.com/static/blog/capabilities/image/capabilities-process-diag-c1802cf1209bb.jpg?authuser=7&hl=pl)
Opracowaliśmy ten proces, aby umożliwić projektowanie i rozwijanie nowych funkcji platform internetowych, które zaspokajają potrzeby deweloperów, w sposób otwarty, a przede wszystkim – w sposób zgodny z istniejącym procesem standardów. Nie różni się on od sposobu, w jaki rozwijamy wszystkie pozostałe funkcje platform internetowych, ale kładziemy nacisk na opinie deweloperów.
Opinie deweloperów są dla nas kluczowe, ponieważ dzięki nim możemy oferować właściwe funkcje, ale później może być trudno zmienić przebieg tego procesu. Dlatego zaczynamy prosić o opinię. Jeśli pojawią się praktyczne informacje techniczne i opinie o przypadku użycia, łatwiej jest wprowadzić poprawki lub nawet zatrzymać tworzenie rozwiązań bez konieczności dostarczania źle przemyślanych lub słabo wdrożonych funkcji. Funkcje opracowywane w WICG nie są gotowe, a Twoje opinie mogą mieć duży wpływ na ich rozwój.
Warto zwrócić uwagę, że wiele pomysłów nigdy nie udaje się ukończyć etapu wyjaśniającego ani testowego źródła. Celem tego procesu jest wysłanie odpowiedniej funkcji. Oznacza to, że musimy się szybko uczyć i szybko się doskonalić. Jeśli nie przekazujesz funkcji, która nie zaspokaja potrzeb dewelopera, jest to dopuszczalne. Aby to umożliwić, zastosowaliśmy taki proces (chociaż często ze względu na opinie często zmienia się kolejność kroków):
Określanie potrzeb dewelopera
Najpierw trzeba określić i poznać potrzeby deweloperów. Co chce osiągnąć deweloper? Kto by tego używał? Jak teraz to robią? Jakie problemy i niepokoje eliminują dzięki tej nowej funkcji. Zazwyczaj deweloperzy zgłaszają te prośby jako prośby o dodanie funkcji, często w odpowiedzi na błędy zgłaszane na stronie bugs.chromium.org.
Tworzenie wyjaśnienia
Gdy zidentyfikujesz potrzebę zastosowania nowych funkcji, utwórz narzędzie objaśniające, czyli dokument projektowy, który wyjaśnia problem, wraz z przykładowym kodem pokazującym, jak może działać interfejs API. Jest to dokument na żywo, który będzie się intensywnie powtarzał w miarę ewoluowania nowych możliwości.
Zbieraj opinie i powtarzaj informacje o wyjaśnieniu.
Gdy wyjaśnienie będzie już na tyle zrozumiałe, nadszedł czas na jego opublikowanie, pozyskanie opinii i wprowadzanie poprawek. To okazja do potwierdzenia, że nowe funkcje spełniają potrzeby deweloperów i działają w sposób, jakiego oczekują. W ten sposób można też uzyskać wsparcie opinii publicznej i sprawdzić, czy ta funkcja naprawdę jest potrzebna.
Przenoszenie projektu do specyfikacji i ulepszanie
Gdy wyjaśnienie będzie gotowe, projekt przechodzi w formalną specyfikację, a w ramach współpracy z programistami i innymi dostawcami przeglądarek będziemy w stanie iterować i udoskonalać projekt.
Następnie, gdy projekt się stabilizuje, zwykle poeksperymentujemy z implementacją w ramach testu origin. Testowanie origin pozwala wypróbować nowe funkcje na rzeczywistych użytkownikach i przekazać opinię o ich wdrożeniu. Takie opinie pomagają nam kształtować i weryfikować projekt, co pozwala nam uzyskać pewność, że wszystko jest w porządku, zanim stanie się normą.
Wyślij
Na koniec, po zakończeniu testowania origin, sfinalizowaniu specyfikacji i wykonaniu wszystkich innych czynności, nadszedł czas, aby wprowadzić wersję stabilną.
Projektuj z myślą o bezpieczeństwie, prywatności i zaufaniu użytkowników
Niektóre z tych funkcji mogą na początku wydawać się przerażające, zwłaszcza w świetle sposobu, w jaki działają w wersji natywnej. Jednak internet z natury jest bezpieczniejszy niż reklama natywna, więc otwarcie strony nie powinno być straszne.
Domyślnie nie należy przyznawać żadnych uprawnień dostępu. Zamiast tego polegaj na modelu uprawnień, który daje użytkownikowi pełną kontrolę i można go łatwo odwoływać. Musi też w jasny sposób informować o tym, kiedy i w jaki sposób są używane te interfejsy API. Opisaliśmy w nich niektóre proces myślowy w sekcji Kontrolowanie dostępu do zaawansowanych funkcji platformy internetowej.