Buzz, najnowsze dziecko Google
Kilka dni temu Google uruchomiło swoją nową usługę, Google Buzz. Wygląda to jak połączenie Twittera i Facebookowego streama z inboksem Gmailowym. Na początku byłem bardzo sceptyczny (interfejs jest... hm, bardzo wczesno-web2.0-owy), jednak po kilku dniach korzystania muszę przyznać, że jestem wręcz zachwycony. Nie jestem i nie byłem heavy userem Twittera (serwis zaczyna być użyteczny dopiero kiedy stworzymy sobie sensowną sieć followersów, a większość moich znajomych co najwyżej dubluje na Twitterze swoje wpisy z Blipa). Nie przepadam za Facebookiem (to ma akurat związek z traumą po implementowaniu FacebookConnect). Co mi się podoba w Google Buzz i czym się różni od konkurentów?
Znajomi z Gmaila
Dużą uciążliwością przy rozpoczynaniu przygody z dowolną aplikacją społecznościową jest odtworzenie swojej sieci kontaktów. W Buzzie nie mamy tego problemu, ponieważ nasza sieć jest automatycznie budowana na podstawie naszych kontaktów Gmailowych. Co więcej, wydaje mi się, że znajomi, z którymi zdarzyło mi się korespondować mejlowo dostarczają nieco bardziej wartościowej treści niż nieco przypadkowi ludzie poznani w innych serwisach. (O bardzo złych stronach automatycznego tworzenia listy followersów piszę poniżej.)
Magiczne sortowanie
Smutna prawda jest taka, że zarówno Twitter, jak i Blip zawiera troszkę więcej szumu niż jestem w stanie sensownie zasymilować. Ludzie informujący o tym, że idą spać, że są głodni, że zaraz będą mogli wyjść z pracy -- w zasadzie to mi nie przeszkadza, choć nieco utrudnia realizację głównego celu dla którego korzystam z wszelkich mikroblogów: odnajdywanie ciekawych linków. Google obiecuje, że buźnięcia będą sortowane przy pomocy algorytmu, który odfiltruje buźnięcia które mnie najprawdopodobniej zupełnie nie zainteresują. Podobna funkcjonalność w Google Readerze działa zadziwiająco dobrze, więc jestem pełen nadziei.
Integracja z Google Readerem
Choć słyszy się głosy, że RSS-y są passé, wciąż korzystam bardzo mocno z Google Readera. Dotyczasowe możliwości share'owania i dyskusji na temat postów były bardzo ograniczone. Od kiedy mamy Buzza, sytuacja robi się dużo ciekawsza.
Brak limitów długości
Tak, wreszcie będę mógł napisać "jeżeli" zamiast "jeśli" bez poczucia, że właśnie zmarnowałem jedną literkę.
Problemy
Prywatność
Pod jednym względem Buzz jest dla Google aplikacją wyjątkową, i to nie w znaczeniu pozytywnym. Jest to pierwszy przypadek, kiedy wypuścili nowy produkt i zamiast zachwytów nad funkcjonalnością w Internecie rozpętała się istna burza na temat tego, jak fatalnie Google potratkowało prywatność swoich użytkowników. Niestety, zarzuty są jak najbardziej słuszne. Po pierwsze, bardzo trudno było zrezygnować z Buzza (w Internecie można znaleźć wiele komentarzy użytkowników, którzy klikali "nie, nie chcę używać buzza" tylko po to aby chwilę później znaleźć zakładkę "buzz" w swoim inboksie). Po drugie, automatyczne tworzenie listy followersów na podstawie kontaktów, z którymi najczęściej korespondowaliśmy może, być wygodne dla mnie, ale bardzo niedobre dla niektórych ludzi.
Na przykład, bardzo niezadowolony był prawnik, którego obowiązkiem jest zachowanie w tajemnicy tożsamości jego klientów (tutaj, komentarz zatytułowany "Breach of Trust"). Publikowanie listy klientów na profilu Google nie mieści się w standardowej definicji chronienia tożsamości.
Jeszcze bardziej niezadowolona była autorka feministycznego bloga Fugitivus. Osoby z którymi najczęściej koresponduje to jej matka, chłopak... i były mąż, który się nad nią znęcał i od którego uciekła (tytuł bloga, Fugitivus, nawiązuje do miana, którym określano zbiegłego niewolnika). Trudno więc się dziwić, że fakt, że były mąż miał nagle dostęp do listy jej znajomych i czytanych przez nią blogów nie wzbudził jej radości. Swoje uczucia (zdecydowanie negatywne) wyraziła w bardzo bezpośredniej notce zatytułowanej Fuck you, Google!. I to niestety okazało się kolejną pułapką, bo notka (bardzo dobrze napisana) jest bardzo powszechnie cytowana w Internecie i zdobyła dużo większą popularność, niż autorka kiedykolwiek sobie życzyła. Obecnie blog jest dostępny jedynie po podaniu hasła (co stwierdzam z przykrością, bo niektóre wpisy były naprawdę niezłe).
Na obronę Google trzeba powiedzieć, że kiedy burza się rozpętała, bardzo szybko zareagowało na zarzuty użytkowników. Obecnie kontakty nie są automatycznie dodawane do listy followersów, a jedynie sugerowane, dużo łatwiejsza do znalezienia jest opcja niepublikowania swojej listy kontaktów. Tym niemniej, niesmak na jakiś czas pozostanie...
Niedoszlifowany interfejs
Po kilku dniach używania widzę kilka problemów z punktu widzenia użwalności. Po pierwsze, nie do końca dobrze rozwiązane jest to, kiedy dany obiekt jest "przeczytany". Na przykład, oczekiwałbym, że kiedy przeczytam nowy komentarz w zakładce Buzz, nie będzie pojawiał się jako nieprzeczytany w inboksie. Tak samo, komentarze i wpisy są edytowalne, ale nie kiedy dodaliśmy je z poziomu Readera. Oczywiście, serwis działa dopiero od kilku dni, więc
Brak natywnej aplikacji dla iPhone
Jednym z efektów słynnej kłótni między Google i Apple o Google Voice jest to, że Google jest dużo mniej entuzjastyczne wobec tworzenia aplikacji natywnych na iPhone'a i postawiło na aplikacje webowe korzystające z dobrodziejstw HTML5. Tak samo jest w przypadku Buzza. Mnie jako użytkownika iPhone'a wcale to nie cieszy, ponieważ tego typu aplikacje są dość ograniczone w porównaniu do natywnych. Choćby dlatego, że nie ma łatwego sposobu dodania zdjęcia do buźnięcia, co byłoby bardzo fajne w połączeniu z geolokalizacją. Na szczęście, nie wątpię, że kiedy tylko Google opublikuje odpowiednie API, w AppStore pojawi się bardzo dużo aplikacji do Buzza.
Nie ma rebuźnięć
Twittnięcia to jest jedynie 160 znaków, więc ręczne retweetowanie nigdy nie stanowiło zbyt dużego problemu. Tym niemniej, wprowadzenie tej funkcjonalnosci w Twitterze było dużym krokiem naprzód. Buźnięcia są dużo bardziej skomplikowanymi obiektami niż twitnięcia. Zawierają więcej tekstu, zdjęcia i, co najważniejsze, dyskusję. Reshare'owanie linku w Readerze albo wklejenie go jako własnego buźnięcia działa dużo gorzej niż dopisanie RT @któstam w Twitterze. Liczę na to, że bardzo niedługo pojawi się funkcjonalność umożliwiająca rebuzowanie wpisów naszych znajomych (z dyskusją i wszystkim).
Wnioski
Google Buzz jako aplikacja bardzo mi się bardzo podoba i życzę mu jak największej popularności (co przełożyłoby się na lepsze treści w moim inboksie). Pewnym cieniem na produkcie kładzie się niestety skandal związany z domyślnym nieposzanowaniem pufności danych użytkowników (szczególnie, że cała sprawa nie była bardzo trudna do przewidzenia). Gdyby nie ta wpadka, zapewne byśmy w tej chwili więcej czytali na temat tego, jaki produkt jest wspaniały, niż jak bardzo niebezpieczny dla naszej prywatności.
Czego brakuje Flakerowi i Blipowi?
Jednym z ważnych czynników dzięki którym jest możliwy tak dynamiczny rozwój Twittera jest jego otwarte API. Dzięki niemu nad zwiększeniem atrakcyjności platformy pracują nie tylko programiści Twittera, ale również masa entuzjastów -- zarówno hobbystów, jak i ludzi myślących o zarobieniu pieniędzy na szale mikrobloggingowym. Dzięki API mogła powstać np. gra Spymaster, w której twitterowa sieć społeczna jest bardzo istotnym elementem.
Nasze rodzime twitteroidy, Blip i Flaker, również udostępniają swoje API. Są one bardzo sensownie zaprojektowane, nie jest też trudne napisanie dla nich odpowiednich bibliotek klienckich (sam jestem autorem klienta Flakera dla języka Python). Do Blipa istnieje już całkiem sporo dodatków (sporo można ich obejrzeć na bliplabs.pl. Dla Flakera jest ich trochę mniej, lecz po pierwsze jest to mniej popularny serwis, po drugie część funkcjonalności, które w Blipie trzeba implementować za pomocą dodatków jest już tam dostępna na starcie (np. publikacja notek na podstawie RSS-ów).
Niestety, w obecnej chwili nie mogą powstać dodatki do Blipa na miarę Spymastera, a na przeszkodzie stoją względy albo techniczne, albo etyczne, w zależności od tego jak na to patrzeć. O co chodzi?
Niebezpieczna autoryzacja
Jedynym sposobem, w jaki można dokonać autoryzacji przy pomocy API Blipa (co umożliwia nam dodawanie wpisów, wysyłanie wiadomości prywatnych, itp.) jest poprzez podanie swojego loginu i hasła. Sprawia to, że by móc skorzystać z dodatku korzystającego z tych funkcji muszę dać mu pełną kontrolę nad swoim kontem. I nie chodzi już tylko o to, że dodatek może zacząć wysyłać spam za pomocą mojego konta. Bardziej niepokojące jest to, że może bez mojej wiedzy i zgody zmienić hasło, kradnąc tym samym moją blipową tożsamość (przynajmniej dopóki nie zresetuję sobie hasła przy pomocy odpowiedniego formularza). Straty wizerunkowe spowodowane przez takie zdarzenie mogą być nie do odrobienia... Co gorsza, nie będę miał sposobu aby przekonać się, która aplikacja jest winna całemu zamieszaniu.
Oczywiście, daleki jestem od oskarżania autorów dodatków o złą wolę. Tym niemniej, jeżeli aplikacja nie ma pytać użytkownika o hasło za każdym razem, kiedy z niej korzysta, musi przechować je w swojej bazie danych. To z kolei świadczy albo o braku szacunku dla danych swoich użytkowników, albo o braku elementarnej wiedzy na temat bezpieczeństwa. Trzymając niezaszyfrowane hasła w bazie sprawiamy, że dowolny napastnik który uzyska dostęp do bazy może przejąć nad nimi kontrolę. Nie musi się w tym celu włamywać na serwer produkcyjny -- jak najbardziej wystarczą niezbyt stare kopie zapasowe. Warto o tym pamiętać: podając w dowolnym serwisie login i hasło do innego serwisu zachowujemy się nieodpowiedzialnie i narażamy się na kradzież swojej cyfrowej tożsamości.
Twórcy Flakera traktują bezpieczeństwo swoich użytkowników nieco poważniej i przy okazji powstania dodatku Reimess wprowadzili możliwość użycia do autoryzacji tzw. kodu API. Jest to ciąg alfanumeryczny wygenerowany przy pomocy jakiejś kryptograficznej funkcji skrótu, który co więcej umożliwia autoryzację jedynie przy pomocy API (czyli nie daje np. możliwości zmiany hasła).
Niestety, rozwiązanie przyjęte przez Netguru ma kilka bardzo poważnych wad. Po pierwsze, po wygenerowaniu nowego kodu stary traci ważność. Nie mogę odciąć dostępu tylko jednej aplikacji: muszę wszystkim. Po drugie, rozwiązanie to jest zupełnie bez sensu pod względem usability. Aby móc go zastosować, autor dodatku musi wysłać wysłać użtkownika pod inny URL i poprosić, aby przekopiował do formularza ciąg znaków. Ilu użytkowników będzie chciało bawić się w takie ceregiele? Niestety, niewielu. Dla tych kilku bystrych paranoików nie warto pisać aplikacji.
By użyć nieco bardziej mniej technicznej metafory: gdyby Blip wydawał kartę kredytowe, aby zapłacić rachunek w restauracji musiałbym dać kelnerowi równoważną kopię swojej karty i odpowiedni PIN. Gdyby to Flaker wydawał karty kredytowe, nie dawałbym kelnerowi karty matki, a kartę z limitem i PIN. Wszystkie karty dla kelnerów byłyby identyczne i miały taki sam PIN, ale aby zapłacić za każdym razem musiałbym składać podanie. Ze znaczkiem skarbowym, na odpowiednim druczku i dwiema pieczątkami.
Prosto, a jednak bezpiecznie: OAuth
Czy istnieje zatem jakiś sposób, aby umożliwić aplikacjom zewnętrznym dostęp do konta użytkownika, tak aby to było używalne, a jednocześnie bezpieczne? Tak! Umożliwia to stworzony na potrzeby Twittera w 2006 roku protokół, OAuth.
OAuth jest bardzo prosty w obsłudze z punktu widzenia użytkownika. Kiedy aplikacja zewnętrzna (zwana konsumentem) chce uzyskać dostęp do danych użytkownika na innym serwisie (dostawcy), wysyła go pod specjalny adres internetowy, kontrolowany przez dostawcę. Tam użytkownik jest proszony o zalogowanie się (jeżeli nie był wcześniej zalogowany) i informowany o tym, że taki a taki serwis chce uzyskać dostęp do jego danych. Jeśli się zgadza, jest z powrotem przekierowywany do serwisu konsumenta, który otrzymuje specjalny kod dostępu. Odtąd może go używać do wykonywana różnych czynności w imieniu użytkownika. Każdy konsument ma osobny kod dostępu, jest więc możliwe odcięcia jednego serwisu bez żadnego wpływu na pozostałe. W bardziej zaawansowanych scenariuszach jest możliwe np. wydanie kodu dostępu który będzie ważny tylko przez określony czas, np. przez 2 godziny.
Typowym przykładem podawanym aby zademonstrować możliwości OAuth jest następująca sytuacja: Alicja wróciła z wakacji i wrzuciła swoje zdjęcia na serwis FooPhoto. Niestety, jej babcia nie umie korzystać z komputera, a Alicji bardzo zależy na tym, aby staruszka miała szanse je obejrzeć. W związku z tym wchodzi na stronę BarPrint. BarPrint prosi o dostęp do plików na FooPhoto przy pomocy OAuth. Alicja jest wysyłana na odpowiednią stronę, gdzie wybiera, które pliki mają być udostępnione BarPrint na najbliższe dwie godziny. Następnie FooPhoto przekierowuje Alicję z powrotem na BarPrint, gdzie wybiera sobie format i rodzaj papieru, na którym mają zostać wydrukowane.
OAuth jest coraz bardziej popularny. Wspierają go Twitter, Yammer, Google, Yahoo, Netflix... Z polskich serwisów od sierpnia 2008 roku wspiera go, uwaga-uwaga... Gadu-Gadu, czyli właściciel Blipa! Tym bardziej dziwi kulawe pod względem bezpieczeństwa API. No ale cóż, 2 lata (GG przejęło Blipa 11 czerwca 2007 roku, jeśli wierzyć Wikipedii) to najwyraźniej za mało na zintegrowanie bazy kodu Blipa i GG...
Oczywiście, OAuth nie jest protokołem pozbawionym wad. Odpowiednie skonfigurowanie konsumenta OAuth nie jest niestety zupełnie trywialne od strony technicznej. Zrobienie tego dla Netfliksa zajęło mi niemal 5 dni, ale było to nie bez związku z tym, że w kilku sytuacjach Netflix nieco nagina protokół do swoich potrzeb (choć to akurat temat na inną notkę). W kwietniu tego roku znaleziono niewielką lukę w protokole (ciekawie opisano to tutaj - linka podrzucił mi Ols). Mimo tej luki protokół wciąż jest o niebo bezpieczniejszy niż alternatywa, czyli wysyłanie gołego hasła.
Co dalej?
Obecna sytuacja strasznie mnie frustruje. Mam kilka pomysłów na wykorzystanie API zarówno Blipa jak i Flakera (np. marzy mi się integracja komentarzy na Gryziemy z Flakerem). Niestety, nie realizuję ich, ponieważ API Blipa nie jest bezpieczne, a token zbyt niewygodny w obsłudze. Jeśli Blip do tej pory nie ma OAuth, to chyba nie ma co się łudzić, że jego obsługa zostanie dodana w najbliższym czasie. Flaker jednak wciąż dość szybko się rozwija. Nie tracę więc nadziei, że chłopaki i dziewczyny z Netguru jakoś niedługo pójdą po rozum do głowy i zastąpią swoje rozwiązanie na pół gwizdka sensownym standardem.
Do dyskusji zapraszam najchętniej na flakerze.
Czy SMO będzie nowym SEO?
Koncepcja SMO, czyli Social Media Optimization, od jakiegoś czasu pojawia się w kontekście alternatywy dla dobrze znanego SEO. Choć nie jest wcale taka nowa (pojęcie ukuto w 2006 roku), polski Google wyrzuca 772 strony na zapytanie „social media optimization”. Zatrważająco mało.
SMO is the new black
Idea leżąca u podstaw SMO jest następująca: ludzie nie trafiają na interesujące ich treści w Internecie przez wyszukiwarki. Z wyszukiwarek trafiają raczej na rzeczy przypadkowe, natomiast o stronach, które okazują się dla nich naprawdę wartościowe, dowiadują się dzięki poleceniu przez innych ludzi.
Coś jest na rzeczy. Gdy analizuję np. zawartość swojego Google Readera, okazuje się, że większość moich RSS-ów wylądowała tam dzięki poleceniu znajomych, flakom i blipom, czy linkom w blogrollach na wcześniej już odwiedzanych blogach.
Jeśli spojrzeć właśnie z tej perspektywy na to, jak ludzie docierają do ciekawych dla nich stron, można wnioskować, że to nie optymalizacja strony dla wyszukiwarek, rozumiana na rynku głównie jako link building, jest najlepszym sposobem docierania do potencjalnych klientów. Właściciel internetowego biznesu powinien raczej skupić się na optymalizacji strony dla mediów społecznych, czyli serwisów społecznościowych, blogów, mash-upów.
Całkiem stary eksperyment (z 2007 roku, czyli sprzed boomu na Twittera) przeprowadzony przez marketingexperiments.com pokazuje, że dobrze przeprowadzona kampania SMO daje dużo większy zwrot z inwestycji niż podobnego kosztu kampania AdWords. Kampania SMO prowadzona przez 12 miesięcy przyniosła w tym eksperymencie 93 000 wizyt. Miesięczna kampania AdWords — 2057. Co więcej, koszt wizyty z linku w AdWords wyniósł 15 razy więcej niż koszt wizyty z kampanii SMO.
Jak robić social media optimization?
Co to właściwie znaczy: optymalizować stronę dla mediów społecznych?
- Ułatwiaj dodawanie strony do serwisów społecznościowych i mash-upów zamieszczając przyciski Facebook, Blip, Flaker, Wykop, Delicious i wiele podobnych.
- Używaj ładnych adresów URL czyli takich, z których można wywnioskować, jaka jest zawartość strony. Klasycznie złymi przykładami są URLe na stronach Onetu czy Gazety.pl, składające się z nic nie mówiących cyfr i przecinków, które co więcej utrudniają wklejanie linków na forach dyskusyjnych.
- Taguj w sensowny sposób zawartość swojej strony.
- Używaj licencji sprzyjającej cytowaniu strony, np. Creative Commons i wyraźnie zaznaczaj, że jej używasz.
- Używaj kanału RSS i propaguj go przez RSS-autodiscovery.
- Zamieść na stronie widget swojego konta w serwisach mikrobloggingowych lub co najmniej — zachętę do obserwowania twojego profilu.
- Uczestnicz w dyskusjach wewnątrz innych społeczności. I nie chodzi tylko o dyskusje na temat tego, co oferuje twoja strona. Po prostu, udzielaj się w społeczności, bądź dla niej wartościowy i zacznij być rozpoznawany. Doskonale robi to Viren Bhandari ze skarpetkowo.pl, który poprzez Flakera rekrutuje testerów swoich skarpetek. Dzięki temu, że Viren nie jest monotematycznym geekiem skarpet i potrafi rozmawiać tez na inne tematy, jest chętnie obserwowany przez innych flakerowiczów, którzy prędzej czy później trafią na stronę jego sklepu.
- Bloguj i komentuj inne blogi. Większość sklepów internetowych zmienia ofertę co kilka miesięcy, powodując tym samym, że odwiedzający traca motywację do częstych odwiedzin. Rozwiązaniem tego problemu może być blog sklepu czy firmy, który zatrzymuje czytelników na dłużej pod szyldem konkretnej marki. Znów, blog nie musi być wyłącznie na temat oferowanego produktu. Np. blog e-lady, zrobiony przez agencję JanMedia to na pierwszy rzut oka typowy babski blog „o życiu”, choć promuje sklep internetowy z bielizną E-Lady.
Jak widać, SMO to żadna magia, a jedynie dość zdroworozsądkowe zasady myślenia o tym, jak przyciągnąć potencjalnego klienta pod swój adres www. Jednak w Polsce ten sposób myślenia jest wciąż jeszcze w powijakach. Brak komunikacji z klientami na twitteroidach jak Blip czy Flaker to zapewne pochodna małej popularności serwisów mikrobloggingowych. W większości e-sklepów, których właściciele płacą za pozycjonowanie i SEO, brak podstawowych przycisków dodawania do mash-upów i serwisów social bookmarking pod ofertami produktów. To wynika pewnie ze słabej świadomości właścicieli e-commerce'ów, że coś takiego, jak social bookmarking czy mash-up w ogóle istnieje i generuje jakikolwiek ruch.
W ojczyźnie Naszej-Klasy intuicyjnie robione SMO na ogół sprowadza się do zakładania kont sklepów na N-K, na przykład takich, jak to zjawisko. Dlatego sądzę, że na rodzimym rynku SMO jeszcze długo nie wejdzie specjalistom od SEO w drogę.