Wieki temu Paul Kinlan zaproponował nowy standard internetowy: Web Intents. Osobiście czułem, że może to być jedna z większych rewolucji w historii Sieci. I co? I wyszło jak zawsze – czyli w sumie nie wyszło…

Web Intents – czyli co?

W największym skrócie: Web Intents miały być sposobem na komunikowanie się między stronami, ale także między stronami i aplikacjami natywnymi. Cały pomysł składał się z dwóch niezależnych części:

  • możliwości “ogłoszenia się” przez odwiedzaną stronę jako oferującą obsługę danej intencji (np. Photopea mogłaby się ogłosić jako usługa obsługująca intencję “edytuj” dla obrazków),
  • możliwości stworzenia nowej intencji w odpowiedzi na działanie użytkownika (np. Facebook mógłby umieścić przy zdjęciach przycisk “Edytuj”, który tworzyłby intencję “edytuj”, dzięki czemu użytkownik mógłby edytować obrazek choćby we wspomnianej Photopei albo w GIMP-ie, który ma zainstalowany).

Wciąż istnieją oryginalne przykłady działania, pokazujące wykorzystanie obydwu części standardu.

Krótka lekcja historii

Gdzieś na samym początku 2011 roku znaleźć można pierwsze wzmianki o Web Intents na listach mailingowych W3C. W listopadzie tego samego roku powstaje odrębna lista wyłącznie na potrzeby Web Intents. Z kolei ostatni mail zostaje rozesłany 5 lat później i ogłasza zamknięcie Web Intents Task Force. To i tak jedynie symboliczne zatrzaśnięcie wieka trumny, bo o śmierci inicjatywy wiedziano od dawna.

W W3C główne prace nad standardami toczą się w tzw. grupach. W obrębie tych grup od czasu do czasu powoływane są tzw. Task Forces – tymczasowe podzespoły oddelegowane do pracy nad konkretnym problemem.

Jednak pomysł na umożliwienie sensownej komunikacji między aplikacjami natywnymi a Siecią nie umarł razem z Web Intents. Wprost z nich powstały dwa inne pomysły: Web Wishes oraz Web Activities. Paul Kinlan również później próbował reanimować pomysł, ale bezskutecznie (mimo że zaproponowane przez niego rozwiązanie działa!). Niemniej Web Intents dały podwaliny pod dwa inne projekty Google’a: Ballistę i wreszcie Fugu.

Ballista była projektem, z którego powstały Web Share (wraz z Web Share Target) oraz File Handling. Rzeczy te następnie stały się częścią projektu Fugu i obecnie są albo uznanymi standardami (Web Share i Web Share Target), albo mają eksperymentalne implementacje w Chrome (File Handling). Można zatem powiedzieć, że Web Intents weszły do przeglądarek tylnym wejściem…

Nowy model interakcji z użytkownikiem

…tyle że nie. Owszem, wspomniane standardy pozwalają robić większość z tego, co oferowały kiedyś Web Intents. Ba, jakby połączyć Web Share i Web Share Target, to po przymrużeniu oczu takie jakby Web Intents z tego. Oto mogę podzielić się obrazkiem z inną stroną, która niby udaje, że pozwala się ze sobą dzielić, a tak naprawdę jest edytorem grafiki. Tym sposobem można emulować intencję “edytuj”. Ba, jak się do tego dorzuci File Handling, to nawet da się edytować obrazki z pulpitu w Photopei!

Tylko że Web Share Target wymaga zmian w manifeście, w sumie nie wiadomo, kiedy przeglądarka może daną stronę w ogóle uznać za odbierającą rzeczy, którymi dzieli się użytkownik, File Handling wymaga instalacji aplikacji webowej, czyli ta musi być PWA, do tego obydwa API są całkowicie różne (navigator.share vs launchQueue.setConsumer), a tak już poza wszystkim: dzielenie się obrazkiem z edytorem grafiki?!

W przypadku Web Intents mieliśmy do czynienia z tak naprawdę nowym modelem interakcji z użytkownikiem. Użytkownik, klikając na przycisk, nie odpalał już ściśle określonej akcji. Użytkownik wyrażał intencję, np. wyrażał intencję zedytowania obrazka. I to, w jaki sposób to zrobi, zależało już wyłącznie od niego. A sama intencja pozwalała lepiej się porozumiewać pomiędzy aplikacjami i stronami. Bo podzielenie się obrazkiem z edytorem grafiki to jednak nie to samo, co poinformowanie tego edytora, że chcemy ten obrazek edytować.

Dodatkowo komunikacja była dwustronna. Aplikacja, w której wyraziliśmy intencję edycji obrazka, powinna wszak zedytowany obrazek otrzymać z powrotem. W przypadku Web Share komunikacja jest jednostronna – bo i po co strona ma czekać, aż ktoś podzieli się linkiem do niej na Twitterze? W przypadku jednak części intencji taka dwustronność komunikacji okazuje się niezbędna.

Jakby jeszcze było tego mało, Web Share działa głównie na urządzeniach mobilnych. W Chrome i Firefoksie na desktopach to API nie działa – tym samym stając się jeszcze mniej sensowną alternatywą dla pierwotnej propozycji.

Obecne propozycje są bardzo fragmentaryczne i nie oferują jednego, spójnego rozwiązania, które pozwalałoby jednym API obsługiwać wszystkie przypadki. Co więcej, traci się zmianę sposobu myślenia, jaką narzucały Web Intents. A właśnie ta zmiana sposobu myślenia, skupiona wokół prostego konceptu intencji, była tak rewolucyjna. Bo pod względem technologicznym, jak widać, da się to zrobić.

Naiwniak

Swego czasu bardzo kibicowałem Web Intents. Naprawdę wierzyłem, że są w stanie w wielu miejscach wyprzeć rozwiązania oparte choćby na OAuth 2.0. Bo po co mam przekazywać edytorowi grafiki moje imię i nazwisko wraz z mailem, skoro chcę tak naprawdę jedynie zedytować obrazek? Jak bardzo życzeniowe to było myślenie w świecie, w którym Sieć jest zdominowana przez monopolistów

Pomijając jednak względy etyczno-biznesowe, być może na Web Intents jest już za późno także z technicznych powodów. Od 2011, kiedy się pojawiły, Sieć jako platforma mocno napuchła. Próba pogodzenia wszystkich funkcji przeglądarek w jednym, wspólnym modelu interakcji z użytkownikiem brzmi jak najczarniejszy koszmar każdego developera dłubiącego w Blinku czy WebKicie. To, co jeszcze w 2011 było – z wielkimi trudnościami – możliwe, dzisiaj wydaje się mrzonką. Być może dlatego, zamiast jednego, spójnego modelu, dostajemy skrawki poszczególnych rozwiązań.

A być może po prostu nie ma drugiego Paula Kinlana, który byłby wystarczająco szalony, żeby wejść drugi raz do tej samej rzeki.