Transkrypcja gawędy o Transportoidzie

Niniejsza blogonotka zawiera tekstowy zapis gawędy o Transportoidzie, będącej tematem poprzedniej blogonotki. Podczas gawędy opowiedziałem o aplikacji mobilnej, którą rozwijałem wraz z niewielkim zespołem w latach 2010-2014.

Transkrypcja pozwoli zapoznać się z gawędą wszystkim, którzy nie mogą obejrzeć trzygodzinnego nagrania wideo (albo szybciej czytają, niż słuchają). Aby tekst lepiej się czytało, w treści gawędy dokonałem niewielkich modyfikacji i skrótów.

Znaczniki czasowe w tytułach rozdziałów prowadzą do odpowiednich fragmentów nagrania na Youtube.

[0:00:00] Wstęp

Dzień dobry! Nazywam się Tomek Zieliński i jestem autorem bloga Informatyk Zakładowy. Stąd zna mnie wielu z was, jednak 10-12 lat temu byłem bardziej znany jako autor programu „Transportoid”. Dzisiejsza gawęda będzie traktowała właśnie o nim – będę długo i z głębokim wzruszeniem opowiadał wszystko co pamiętam o tym projekcie, który rozpoczął się w roku 2010; a kiedy się skończył – tego już dowiecie się z gawędy.

Czym był Transportoid? Był rozkładem jazdy komunikacji miejskiej na komórki. Na początku na telefony z systemem Android, potem doszedł do tego Windows Phone. W programie dostępne były rozkłady dla przeszło 50 polskich miast. Na początku, w lutym 2010, Transportoida zacząłem robić sam. Kilka miesięcy później dołączył do mnie Piotrek Owcarz, który zajął się generowaniem plików z rozkładami jazdy. A rok później do zespołu dołączył Tomek Przybylski, który zajął się programowaniem Transportoida dla systemu Windows Phone.

Skąd taka nazwa? Cóż, nazwa była owocem krótkotrwałej mody na to, aby nazwy programów na Androida w jakiś sposób nawiązywały do słowa „droid”. Moda trwała bardzo krótko, no ale – stety czy niestety – Transportoid został ochrzczony właśnie wtedy i ta nazwa została z nim do końca.

Dlaczego w ogóle zacząłem robić taki program? Na przełomie lat 90-tych i „zerowych” korzystałem z takiego przenośnego komputerka marki Palm. Starsi widzowie mogą to jeszcze pamiętać – istniała wtedy taka kategoria urządzeń jak palmtopy. One nie miały zazwyczaj łączności z Internetem, ani w ogóle żadnej łączności bezprzewodowej. Jednym z ciekawszych programów, które wtedy istniały, był program „Przewodas”, który był mobilnym rozkładem jazdy na Palma. Można było wgrać ten program przez kabel, dodać plik z rozkładami jazdy i korzystać sobie w każdym miejscu o każdym czasie. Rozkłady można było sprawdzić np. będąc na uczelni – by sprawdzić o której godzinie będzie najbliższy autobus w stronę domu. Czy trzeba się spieszyć? Może iść wolniej? Było to bardzo wygodne i w tamtych czasach dość niespodziewane, no bo tak naprawdę nie było żadnego innego sposobu żeby mieć przy sobie rozkład jazdy komunikacji miejskiej, dla całego miasta.

Przez kilka miesięcy byłem autorem plików z rozkładami dla Wrocławia. Nie będę teraz o tym mówił, bo mam nadzieję, że o „Przewodasie” uda mi się opublikować osobny wpis na blogu. Na razie odnotuję tylko, że było to silne źródło inspiracji, bo wiedziałem, jak wygodny jest rozkład jazdy noszony zawsze przy sobie. Ponieważ byłem już trochę wkręcony w temat rozkładów jazdy i wyszukiwania połączeń, to moja praca magisterska dotyczyła właśnie tego tematu – jak zaimplementować wyszukiwanie połączeń w sieci komunikacji miejskiej, zwłaszcza w ujęciu grafowym (przystanki są węzłami, a połączenia między nimi – krawędziami grafu).

W tej swojej pracy magisterskiej zgłębiałem temat optymalizacji wyszukiwania czyli sprawienia, żeby optymalne połączenia znaleźć w jak najkrótszym czasie – eliminując po drodze jak najwięcej ścieżek czy też jak najwięcej tych obliczeń, które nie doprowadzą nas do sukcesu. Praca magisterska powstała, obroniłem ją, a te algorytmy, które wtedy zaimplementowałem, były później pomocą właśnie w Transportoidzie.

Trzecim źródłem inspiracji było to, że – nie planując tego wcześniej – zatrudniłem się w firmie Trapeze, producenta sprzętu i oprogramowania do zarządzania całą flotą i siecią komunikacji publicznej. Sprzęt ten był montowany w autobusach, tramwajach, pociągach, dostarczano także cyfrowy system informacji pasażerskiej, czyli wyświetlacze z odjazdami, znane z przystanków. Ja pracowałem właśnie przy pisaniu oprogramowania, które jeździło w pojazdach komunikacji publicznej i które było instalowane w wyświetlaczach na przystankach.

Tutaj widzimy zdjęcie z delegacji do Rostocku – ponieważ nie byliśmy w stanie klientowi pomóc zdalnie, musiałem pojechać do w delegację do Niemiec, żeby przeprowadzić diagnostykę na miejscu i stamtąd właśnie pochodzi to zdjęcie, na którym siedzę z laptopem podłączonym do złącza debugowego w komputerze pokładowym i sprawdzam, co działa niezgodnie z oczekiwaniami.

Wracając do Transportoida – już wtedy było wiadomo, że mobilna komunikacja, mobilny Internet to będzie przyszłość. Oczywiście w tamtym czasie technologia nie była jeszcze gotowa. Na przykład na starych telefonach z klawiaturą – takich typowych starych Nokiach – pod koniec lat 90-tych pojawiła się możliwość uruchamiania apletów, napisanych w Java 2 Micro Edition (J2ME). I tam teoretycznie można by próbować umieścić takie rozkłady, tylko że ten malutki ekranik, obsługiwany kursorami, nie był wystarczająco wygodny. Program, który miałby tam prezentować rozkłady, wymagał jednak za dużo klikania, poza tym instalacja takich rzeczy nie była prosta, taki zwykły typowy użytkownik nie poradziłby sobie.

W 2007 r. pojawił się pierwszy iPhone. No i od razu było wiadomo, że to będzie rewolucja, jednak był on bardzo drogi. W Polsce mało kto mógł sobie na niego pozwolić. Było wiadomo, że w relatywnie niedługim czasie pojawi się konkurencyjny system produkowany przez Google, czyli Android. Osobna linia urządzeń została też wypuszczona przez firmę Palm, znaną wcześniej z produkcji palmtopów. Na rynku był jeszcze Blackberry i miał się całkiem dobrze.

Jak każdy pasjonat komputerów i urządzeń mobilnych, chciałem mieć smartfona. Nie bardzo mogłem sobie wówczas pozwolić na taki wydatek, dlatego wpadłem na inny pomysł. Zaproponowałem w Instytucje Informatyki Uniwersytetu Wrocławskiego, że mogę przygotować kurs programowania smartfonów – o ile uczelnia zapewni urządzenia. Wiedziałem, że wówczas dostanę do dyspozycji smartfona i będę mógł się nim pobawić, zobaczyć jak to jest używać takiego urządzenia na co dzień. Okazało się, że trafiłem na bardzo dobry moment, bo uczelnia była w stanie złożyć grant o środki unijne na zwiększanie atrakcyjności programu studiów, albo coś w tym stylu. O pieniądze na przygotowanie wykładu oraz na zakup urządzeń, kilku czy kilkunastu telefonów dla mnie i studentów uczęszczających na zajęcia.

Oczywiście cała papierologia trwała parę miesięcy, ale pod koniec roku 2009 dostałem w swoje ręce urządzenie HTC Hero – jeden z pierwszych telefonów komórkowych z Androidem, jakie były dostępne w Polsce. Mam dziś taki telefon ze sobą, ponieważ wiele lat później kupiłem go sobie. HTC Hero wygląda tak. Nie jest to duże urządzenie a jeśli porównamy go do współczesnego Samsunga Galaxy S20 to widzimy, że HTC Hero ma ekran o mniej więcej takiej wysokości, jak Galaxy szerokości. Taka była technologia, wszystkie telefony w tamtym czasie miały ekrany o mniej więcej takiej rozdzielczości. Co ciekawe – w Androidach ekrany zaczęły rosnąć szybciej, niż w iPhone’ach.

[0:14:50] Powstaje Transportoid

Tak więc dostałem w swoje ręce telefon z Androidem i zacząłem szykować kurs, który rozpoczął się semestr później – odbyły się dwie edycje kursu programowania smartfonów mojego autorstwa. A podczas przygotowań narodził się Transportoid. Było to drugi program jaki w życiu napisałem na Androida, bo wiedziałem że rozkład jazdy komunikacji miejskiej na pewno przyda się wielu ludziom. I że na taki program na pewno od razu pojawi się popyt.

Zacząłem uczyć się programowania Androida w grudniu 2009 r., a już w lutym 2010 r. pojawiła się pierwsza publiczna wersja beta Transportoida. Zawierała proste funkcje – pokazywanie rozkładów według przystanków, według tras poszczególnych linii, oraz obsługę ulubionych pozycji z jednej i drugiej listy.

Liczba funkcji szybko rosła. Wiadomo, że gdy program jest nowy i mały, to zmiany są bardzo wyraźne. Gdy tylko gotowa była wersja, która działała w miarę dobrze, zwróciłem się do potencjalnych użytkowników, by sobie ten program potestowali. Na początku dostępne były rozkłady dla Wrocławia i Warszawy. Generowałem bazy danych z rozkładami obu tych metropolii. Ale program przygotowany był w taki sposób, by mógł obsługiwać wiele różnych plików, z wieloma różnymi rozkładami. I o dostarczanie rozkładów dla nowych miast, poprosiłem wolontariuszy. Działo się to na forum internetowym Android.com.pl.

Poprosiłem, by skontaktowały się ze mną osoby zainteresowane publikacją rozkładów dla innych miast. Przygotowałem szczegółową instrukcję, jaki format danych jest konsumowany przez Transportoida. Był to plik ZIP, w którym był zestaw plików zawierających rozkłady dla poszczególnych linii. Dostarczyłem specyfikację i ostrzegłem, żeby nikt nie próbował przypisywać takich danych ręcznie, bo przy pierwszej aktualizacji rozkładu cała taka praca poszłaby na marne. Chodziło o to, aby za temat wzięli się ludzie potrafiący programować, by rozkłady z plików albo stron internetowych automatycznie przetworzyć na format Transportoida.

Zgłosiło się kilku chętnych, z kilku różnych miast. Zacząłem dostawać takie pliki. Okazywało się, że te moje opisy niekoniecznie były tak precyzyjne jak sądziłem więc rozkłady miewały błędy. Poprawiłem specyfikację i dostarczyłem wolontariuszom programik, w którym mogli przetestować poprawność pliku przed wysyłką. Przygotowałem też automat, dzięki któremu mogli wysyłać na serwer poprawne pliki, bez mojej ręcznej pracy. Oczywiście przy wgrywaniu na serwer te pliki były sprawdzane ponownie, by nie narazić użytkowników na pobieranie błędnych rozkładów.

Po Warszawie i Wrocławiu pojawiło się kilka innych miast, większych i mniejszych. Ja wziąłem się za rozwój kolejnych funkcji, no np. jedną z rzeczy które pojawiły się w miarę szybko były przypisy do odjazdów. Takie, jak widzimy na obrazku po lewej, np. informacja, który kurs zjeżdża do zajezdni. Pojawiła się mapa. W tych miastach, gdzie znaliśmy współrzędne przystanków, można było narysować przebieg kursu na mapie. Telefony miały wbudowany kompas, więc można było wyświetlić strzałeczki pokazujące, gdzie znajdują się które przystanki. Oczywiście, gdy użytkownik się obracał, strzałeczki się animowały.

Jak mówiłem, rozwój był bardzo szybki. W tamtych czasach w Android Markecie (dziś sklep Google Play) od wrzucenia nowej wersji programu przez programistę do wystawienia jej dla użytkowników mijała może minuta. Dzięki temu w przypadku dostrzeżenia jakichkolwiek błędów byłem w stanie reagować bardzo szybko – i naprawiać błędy niemal na poczekaniu. Wdrożyłem sobie zasadę wspomnianą później przez twórcę Facebooka – move fast and break things, czyli naginaj do przodu nawet jeśli po drodze jakieś rzeczy będziesz psuł. Jeśli coś się zepsuje, no to od razu trzeba naprawić i cisnąć dalej.

I dokładnie tak było – pamiętam sytuację, gdy przygotowałem pierwszą wersję korzystającą z kompasu. Przy wyjściu z programu subskrypcja powiadomień z kompasu pozostawała aktywna, co oznaczało, że kompas działał cały czas w tle, zżerał baterię a ta wyczerpywała się w parę godzin. Ale gdy tylko użytkownicy dali mi znać, że taki problem występuje, domyśliłem się o co chodzi, przygotowałem poprawkę i tak naprawdę po paru godzinach dostępna już była poprawiona wersja. A wszyscy, którzy przegapili tę wersję, nie doświadczyli problemu, bo była ona dostępna tylko przez parę godzin.

Warto wspomnieć o tym, że od samego zarania Androida popularne były tzw. nieoficjalne ROM-y, czyli oprogramowanie systemowe przygotowane przez entuzjastów dla im podobnych power-userów, użytkowników szukających różnych zaawansowanych funkcji nieobecnych w oprogramowaniu dostarczanym przez producenta. Najbardziej znanym był wówczas Cyanogenmod, który potem na skutek różnych awantur przekształcił się w system o nazwie Lineage.

Z alternatywnymi ROM-ami było trochę problemów. Instalowało je może 5% użytkowników Transportoida ale generowali oni lekko licząc 50% zgłoszeń błędów. Było to uciążliwe, gdy ktoś zgłaszał błąd, traciłem czas na korespondencję i śledzenie usterki a na końcu okazywało się, że to nie był błąd Transportoida, tylko błąd w nieoficjalnym ROM-ie z powodu którego program nie realizował poprawnie jakiejś funkcji.

Dodatkowym problemem z custom ROM-ami było to, że one mogły np. wyglądać troszkę inaczej, np. taki widget tutaj do wybierania godziny na telefonach HTC był trochę większy, niż na wszystkich telefonach Sony czy Samsunga. No i to sprawiało, że zaprojektowanie interfejsu, który będzie wyglądał dobrze na wszystkich telefonach, było problematyczne. Nie wiedziałem jak duży będzie taki akurat wybierak na różnych systemach. Ciężko było projektować z zapasem. No a jeśli zdarzały się właśnie takie formy niezgodności, no to potem użytkownicy byli niezadowoleni, przesyłali screenshoty, że tutaj np. coś się nie mieści, że ten wybierak najeżdża na przyciski „sobota” i „niedziela”. Potem Google nauczył się takim problemom zapobiegać, wymagać od producentów telefonów aby kontrolki ekranowe nie były modyfikowane.

Transportoid zaczął rozwijać się całkiem szybko między innymi dlatego, że jako autor nie musiałem zajmować się bazami danych z rozkładami. Robili je wolontariusze – na początku dla Krakowa, Opola, Rybnika. Potem szybko pojawiły się jeszcze inne miasta, ale względnie szybko pojawił się też problem, którego nie przewidziałem. Wolontariuszom generowanie nowych wersji rozkładów nudziło się. A rozkłady zmieniały się cały czas i użytkownicy mieliby pretensje do mnie, że rozkłady dla jakiegoś miasta są nieaktualne.

Gdy wolontariusze zaczęli się pomału wykruszać, zauważyłem że jest taki jeden Piotrek, który najpierw dostarczał bazy z rozkładami dla Krakowa a potem zauważył, że rozkłady w bardzo podobnej formie są publikowane jeszcze w paru innych miastach – i zaczął dostarczać rozkłady także dla tych miast. Ja z kolei spostrzegłem, że te rozkłady były naprawdę dobrej jakości, dostarczane regularnie. No i gdy zaczęliśmy korespondować to okazało się, że Piotrek ma trochę czasu i może zająć się generowaniem rozkładów dla tych miast, które są porzucane przez innych wolontariuszy.

Współpraca od razu układała się na tyle dobrze, że już w maju 2010 założyliśmy z Piotrkiem Owcarzem swego rodzaju spółkę autorską i zaczęliśmy rozwijać Transportoida wspólnie. Ja nadal pisałem nowe funkcje w programie, on przygotowywał rozkłady dla coraz większej liczby miast. No i tak miało być przez najbliższe 4 lata. Potem dołączył jeszcze Tomek Przybylski, o nim później.

[0:29:37] Gościnnie – Piotr Owcarz

Udało mi się namówić Piotrka na to, żeby sam powiedział parę słów o tym, jak zaczęła się jego przygoda z Transportoidem i jak to potem leciało.

Tomasz Zieliński: Cześć Piotrek!

Piotr Owcarz: Cześć wszystkim!

Tomasz Zieliński: co sprawiło że w maju 2010 zdecydowałeś się dołączyć do projektu Transportoid, jako dostawca rozkładów dla najpierw kilku a potem wszystkich kilkudziesięciu miast?

Piotr Owcarz: byłem wtedy świeżo po przeprowadzce do Krakowa. I no był to chyba brak zajęcia. Starałem się sobie znaleźć jakieś hobby. Wtedy kupiłem sobie pierwszy smartfon z Androidem, był to Samsung Galaxy 1. Był to jeden z pierwszych Androidów. Ciężko to chodziło strasznie, ze względu na szybkość Internetu i w ogóle możliwości Androida w tamtym czasie, no ale miał za to taką fajną zaletę, że można było wgrywać swoje customowe ROM-y. Chodziłem po różnych forach XDA i android.com.pl no i właśnie na tym forum znalazłem Twój post o Transportoidzie, że szukasz chętnych do scrapowania rozkładów.

To było coś co wydawało mi się że znam, bo robiłem podobny projekt na zaliczenie na studiach. Więc no postanowiłem spróbować swoich sił – no i na początku zacząłem od Krakowa. Mimo tego, że Kraków już był dodany, miał swojego opiekuna – ale pomyślałem, że mojemu miastu przyda się backup. Zacząłem robić też inne miasta no i zauważyłem, że przewoźnicy w innych miastach używają podobnych systemów do generowania rozkładów, więc opracowałem coś na wzór szablonów, w których dodanie nowego miasta, które jest podobne do istniejącego, wymagało tylko obsłużenia różnic. No i tak właśnie lawinowo zacząłem dodawać nowe miasta do projektu. Wtedy musieliśmy sformalizować naszą współpracę. I w ten sposób zaczęliśmy podbijać miliardowy rynek apek od rozkładów jazdy.

Tomasz Zieliński: opowiedz, jak wyglądała typowa sesja pracy z rozkładami. Po dniu pracy siadałeś do prywatnego komputera i co dalej?

Piotr Owcarz: nie było to po pracy, to było rano. Po przebudzeniu się siadałem do komputera i sprawdzałem logi konwertera, który działał przez noc. Patrzyłem które miasta się wysypały, próbowałem je na szybko gdzieś tam sfixować. No bo przecież poprawność była kluczowa. Ludzie jechali do pracy, potrzebowali aktualnych rozkładów jazdy. Więc byłoby trochę nie fair, gdyby ktoś – korzystając z naszych rozkładów – poszedł na autobus, który już odjechał. Tak więc to działo się raczej rano a dopiero wieczorem po pracy siadałem do maili, do raportów z błędami. No i starałem się właśnie robić dodatkowe jakieś rzeczy, dodawać nowe miasta, odpisywać na te maile. Na początku puszczałem jeszcze konwerter w nocy na moim PC, ale to było zanim przenieśliśmy go na serwer i wreszcie można było uruchomić konwerter w cronie.

Tomasz Zieliński: gdy kończyły się wakacje albo nadchodziło Boże Narodzenie liczba zmian do wprowadzenia musiała gwałtownie rosnąć. Była szansa zdążyć ze wszystkim? Jak wyrozumiali byli wówczas użytkownicy?

Piotr Owcarz: te okresy były najbardziej wymagające pod względem obsługi rozkładów, głownie dlatego że przewoźnicy wprowadzali abstrakcyjne opisy kursów i zmiany organizacji. Nie było tu żadnego standardu. Praktycznie każde miasto to robiło, a skrypty nie radziły sobie z przetwarzaniem opisów w języku naturalnym. Bo dla przykładu święto 1-szego listopada można było zapisać na kilkanaście sposobów. Datą, datą skróconą, datą pełną, z kropkami, kreskami, ukośnikami, miesiąc słownie, pierwszy listopada, słownie: wszystkich Świętych. Ż kropka Św. Kropka, Święto zmarłych, Św kropka zm. Kropka, oraz Święto Zmarłych oraz dzień zaduszny. Oczywiście także wszystkiego rodzaju skróty, z kropkami, kreskami, ukośnikami – to wszystko jako np. nowa kolumna podczas gdy rozkłady zawsze miały trzy kolumny: powszednie / soboty / niedziele. No albo np. jako przypis do odjazdów, a w przypisach znowu proza odnośnie Wszystkich Świętych.

Oczywiście były miasta w których po kilku razach była powtarzalność, szczególnie te większe. Ale w małych miastach zmiany były wprowadzone przez przewoźnika ręcznie, również z literówkami. Albo np. hitem były wprowadzane rozkłady specjalne na jeden dzień w postaci PDF. Tak więc nie, nie było szans zdążyć ze wszystkim. Duże miasta miały poprawki wcześniej, w miarę możliwości. A gdy możliwości nie było, to nie zostawało nic innego, niż przeprosić użytkowników w odpowiedzi na zgłoszenia.

Tomasz Zieliński: Co było największym wyzwaniem podczas generowania rozkładów? Czy wyścig na liczbę obsługiwanych miast miał w ogóle sens?

Piotr Owcarz: chyba walka o poprawność rozkładu, bo jeśli użytkownik kilka razy przejedzie się na niepoprawnym rozkładzie, to zrezygnuje z aplikacji. A z poprawnością było ciężko ze względu na jakość publikowanych rozkładów. Były miasta, które chętnie z nami współpracowały, mogliśmy przekazać sugestie jak ulepszyć rozkłady, jak odciążyć ich infrastrukturę. Tu mogę wymienić pana Piotra z PKM Białystok – ale byli też ludzie którzy jawnie robili nam na złość. Chodzi oczywiście o MPK Kraków. Wyścig na liczbę miał sens. Bo np. mieszkańcy Nysy czy Chojnic to nie wiem czy do dziś mają rozkłady w jakiejś aplikacji – a u nas były. Inna sprawa że 30 największych miast stanowiło 98% użytkowników, więc pozostałe 30 miast to była bardziej działalność przeciwko wykluczeniu cyfrowemu.

Tomasz Zieliński: mi zdarzały się okresy, w których skupiałem się na czymś innym, niż rozwój programu. Twoja wachta nie kończyła się nigdy. A przychody ze sprzedaży wersji premium były bardzo skromne. Co sprawiło że wytrwałeś w naszym zespole autorskim, aż 4 lata?

Piotr Owcarz: sprawiało mi to satysfakcję przez długi czas. Nigdy nie spodziewaliśmy się wysokich przychodów, część oddawaliśmy też na działalność charytatywną, więc pieniądze na pewno nie były motorem projektu. Ja byłem dumny z tego co stworzyłem, że rozwijam swoje umiejętności, że uczestniczę w czymś większym, że stworzyliśmy aplikację, która tylko przy okazji zarabiała na utrzymanie. Bo przecież część płatna była dobrowolna, nie było w niej też reklam. Więc aplikacja miała dość grubą warstwę ideologiczną, ale dlaczego skończył się zapał? Trochę z wypalenia, trochę z powodu oporu przewoźników, no ale chyba kluczem były plany na rozbudowę. Było tego dużo, choć była konieczna. Trochę nas to przytłoczyło, powinniśmy byli lepiej to rozplanować i zaplanować postępy mniejszymi kroczkami. No i wejście w poważniejszą komercjalizację, większy nakład pracy, który trzeba było pogodzić z pracą zawodową – albo i nie… więc trzeba było podjąć jakieś decyzje i to chyba mnie osobiście zniechęciło do kontynuowania projektu. Ale przez 4 lata dawałem radę.

Tomasz Zieliński: bardzo dziękuję za podzielenie się wspomnieniami. Na razie!

[0:39:55] Rozkłady i nasz autorski format danych

Dziękuję Piotrkowi za wypowiedź, pociągnę trochę temat danych rozkładowych i tego w jaki sposób były generowane. Ci którzy korzystają z jakichś rozkładów, które są albo na przystankach, albo gdzieś w rozkładach internetowych, no to najczęściej korzystają z arkuszy, które można nazwać taką postacią „słupkową”. Tzn. widzimy zestaw odjazdów danej linii, z danego przystanku czy też z danego słupka – o tej terminologii jeszcze powiem.

Jest to bardzo czytelne dla człowieka, tzn. widzimy kiedy będzie najbliższy pojazd. Czy musimy długo czekać, kiedy był poprzedni. Jest to bardzo intuicyjne, natomiast sprawia trochę problemów, gdy chcemy wyszukiwać połączenia. No bo gdy mamy do czynienia ze słupkami czy też z rozkładami słupkowymi dla kolejnych dwóch przystanków, no to nie jest wcale oczywiste, które odjazdy z tych poszczególnych przystanków składają się na kurs poszczególnych pojazdów.

Gdy patrzymy na te rozkłady, które tutaj są na ekranie, to można domniemywać – i jest to pewnie prawda – że odległość tych przystanków to jest jedna minuta jazdy i że kurs o 14:39 dojedzie na następny przystanek o 14:40. Gdyby się okazało, że odległość wynosi 21 minut, taki odjazd o 14:39 dojedzie na 15:00. Przypadek na ekranie jest bardzo prosty, ale w wielu miastach są np. rozkłady z różnymi wariantami, gdzie np. co trzeci kurs jakiejś linii ma pętlę gdzie indziej, jedzie kilka dodatkowych przystanków. Albo w godzinach szczytu autobus jakiejś linii ma odrobinkę wydłużoną trasę, bo robi jeszcze kółko po osiedlu i tych przystanków w tych paru kursach jest po drodze więcej.

I to już się robi problem, gdy postać słupkowa jest jedynym co mamy. Pierwsza wersja naszego formatu danych potrafiła reprezentować tylko dane pochodzące z postaci słupkowej. I przez to nie byliśmy np. w stanie wyszukać tych połączeń, które mogły być zrealizowane przez pojazdy albo wjeżdżające na trasę z zajezdni, albo zjeżdżające do zajezdni. No bo nawet jeśli przewoźnik publikował takie dane, no to nie mieliśmy sposobu żeby zawrzeć je w programie. I było wiadomo, że ten problem będzie narastał, zwłaszcza w dużych miastach, które mają skomplikowane rozkłady. Razem z Piotrkiem zaczęliśmy pracować nad lepszym formatem, który korzystałby z danych w postaci kursowej.

Tutaj nie mamy już do czynienia z arkuszami rozkładów dla poszczególnych słupków, tylko patrzymy na kursy – przejazdy poszczególnych pojazdów po kolejnych przystankach. Oto fragment jakiegoś przykładowego rozkładu w Google’owym formacie GTFS – widzimy, że tutaj kurs o symbolu 22NB9AM podróżuje kolejno przez przystanki oznaczone symbolami A, B, C, D, E, F i mamy podane czasy przyjazdu, czasy odjazdu. I dzięki takiej postaci rozkładów, jesteśmy już w stanie bez problemu obsłużyć i różne warianty i jakieś wydłużenia trasy i przejazdy wydłużone o ileś przystanków. Bo każdy kurs jest opisany z osobna.

Aby móc użyć takiego formatu w naszych rozkładach w Transportoidzie, musieliśmy zaprojektować z Piotrkiem odpowiedni format, nazwaliśmy go TR2. Działo się to w roku 2013 czyli to jest troszkę skok do przodu względem tej opowieści, która i tak nie będzie całkiem chronologiczna. TR2 to jedyny taki złożony format danych, który zaprojektowałem, ale muszę powiedzieć z perspektywy czasu, że udało się to bardzo fajnie – między innymi dzięki pracy zespołowej. Ja pisałem specyfikację formatu, z pełnym opisem tego w jaki sposób wyobrażam sobie kompresję czy też kodowanie danych. Piotrek czytał tę moją specyfikację i zadawał pytania albo wskazywał przypadki problematyczne. No i gdy w ten sposób wspólnie dopracowaliśmy specyfikację, wówczas Piotrek wziął i napisał w Pythonie encoder. Czyli taką pakowaczkę rozkładów do tego nowego formatu. I dzięki temu ja mogłem napisać dekoder w Javie, ówczesnym języku programowania Androida. Mieliśmy taki system w którym on coś kodował, ja dekodowałem, dzięki czemu odkryliśmy kolejny zestaw przypadków brzegowych – ale dzięki temu że robiły to dwie osoby, to o wiele łatwiej i szybciej było takie usterki dostrzec.

Potem Piotrek, żeby ułatwić sobie pracę, stworzył opis gramatyki, dzięki czemu mógł sobie oglądać te pliki z rozkładami w hex-edytorze implementującym taką gramatykę – od razu było łatwiej debugować kolejne odnajdywane problemy. A ja napisałem – tym razem w C# – weryfikator, czyli program, który wczytywał pliki w formacie TR2 i sprawdzał wszystkie kryteria, wszystkie więzy spójności, czy wygenerowany rozkład ma wszystko jak należy. I gdy taki zestaw narzędzi był w użyciu, to ten format w bardzo szybkim czasie był już przetestowany i zwalidowany. Dzięki rozkładom w formacie TR2 byliśmy w stanie zaoferować użytkownikom nowe funkcje.

Na ekranie widać oglądaczkę do plików z rozkładami – można było wskazać linie, wybrać wzorzec, zobaczyć konkretne przejazdy, a jeśli w rozkładach były jakieś usterki, to można było szybko zdiagnozować ich źródło. Ten format miał też w sobie masę różnych optymalizacji. Po 2 latach pracy z formatem TR1 dobrze wiedzieliśmy, które fragmenty algorytmów wyszukiwania stanowią wąskie gardło, trwają za długo. Część z tych problemów byliśmy w stanie rozwiązać od razu w formacie danych.

Na etapie generowania plików z rozkładami wykonywaliśmy wiele różnych obliczeń, które skutkowały szybszą pracą aplikacji na telefonie. Przykład – dla każdego przystanku generowaliśmy listę przystanków, które mogą zostać z niego osiągnięte bez przesiadki. Była też druga lista, z przystankami z których można dojechać do tego wskazanego. Gdy takie dane są już obecne w pliku z rozkładami, nie trzeba ich obliczać na telefonie. W tamtych czasach procesory w komórkach naprawdę nie były za szybkie – a ilość pamięci była bardzo niewielka. Więc im więcej rzeczy dało się tutaj zaoszczędzić, tym lepiej.

Byliśmy w stanie wdrożyć wiele mechanizmów, które zapobiegały problemom – np. Piotrek przygotował mechanizm, który porównywał nową wersję rozkładów z rozkładami poprzednimi i wstrzymywał publikację, jeśli nowa wersja była znacznie mniejsza albo znacznie większa od poprzedniej. Taka różnica oznaczała usterkę, nie chcemy takiej aktualizacji dostarczać użytkownikom. W formacie TR2 zawarta była suma kontrolna, więc byliśmy w stanie natychmiast wykryć, że plik jest niekompletny lub został pobrany z błędem.

Optymalizacji było więcej, zainteresowałyby raczej programistów. Wiele tablic z danymi było bardzo rzadkich, tzn. miały prawie same zera i nieliczne jedynki, więc zaimplementowałem kodowanie run length encoding, zapisujące jak najdłuższe ciągi zer w jak najbardziej efektywny sposób. Inną optymalizacją było to, że jeśli wszystkie różnice czy też odległości między przystankami na trasie wynosiły 3 minuty lub mniej, to pakowaliśmy do jednego bajtu po 4 takie przejazdy. Jeśli wszystkie odległości na danej linii były mniejsze od 15 minut, to pakowaliśmy po dwa odjazdy do bajtu. A jeśli dwa kursy, nawet różnych linii, miały takie same wzorce tych różnic, to taki wzorzec pojawiał się w pliku tylko jeden raz, żeby oszczędzać miejsce – dzięki temu cały rozkład dla Warszawy mieścił się w 800 kilobajtach.

Jak wcześniej mówiłem, wyszukiwanie połączeń – przynajmniej na telefonach – wymagało kombinowania. Rozkłady jazdy dla większych miast były za duże, żeby zmieścić się na raz w pamięci komórki. To oznaczało, że proces wyszukiwania połączeń musiał być rozbity na mniejsze, bardziej zoptymalizowane etapy. Pierwszym etapem było sprawdzenie jakie trasy są możliwe – które kombinacje linii i przesiadek pozwolą na dotarcie z punktu A do punktu B.

Nie wszystkie optymalizacje były możliwe. Czy trasa bezpośrednia, bez przesiadek, zawsze będzie szybsza niż trasa z przesiadkami? Nie. Były sytuacje, gdy bezpośrednie połączenie miało po drodze pętlę wokół osiedla, natomiast w wariancie z przesiadką dało się zrobić tak, że wsiadamy w pierwszą linię a w miejscu, gdzie ona zbacza z najprostszej trasy, przesiadamy się i ciśniemy dalej inną linią prosto.

Gdy już podczas wyszukiwania połączeń wiedzieliśmy, które linie i miejsca przesiadek będą brane pod uwagę, mogliśmy doczytać informacje o godzinach odjazdów. To już był etap, w którym dało się wyznaczyć najszybszą trasę. Wyszukiwanie z dwiema przesiadkami było w Transportoidzie możliwe tylko w tych miastach, które miały rozkłady w formacie TR2.

Oczywiście było dużo problemów – czy też wyzwań – związanych z tym, że obsługiwaliśmy dużo miast. Jednym z takich trudniejszych wyzwań były, była zmienność nazw przystanków. Jeśli użytkownik dodał sobie do ulubionych np. przystanek Operetka, a potem Operetka zmieniła się w Teatr Muzyczny, to musieliśmy podczas generowania rozkładów wykryć, że mimo zmiany nazwy chodzi o ten sam przystanek. Musieliśmy jakoś przechować na serwerze taki „wieczny” identyfikator, by prawidłowo mogła działać funkcja ulubionych przystanków.

Trochę mieszam tutaj te terminy – przystanek, węzeł, słupek. W naszej terminologii słupek był miejscem zatrzymywania pojazdów, dosłownie słupkiem z rozkładami i znakiem drogowym. Czyli np. po dwóch stronach ulicy występowały dwa słupki, po jednym w każdą stronę. Jeśli słupki mają swoje numery, jak w Warszawie, mogliśmy je podpowiadać np. podczas przesiadek. Ale niektórzy przewoźnicy tego nie odróżniali – wówczas operowaliśmy na poziomie węzłów, całego miejsca znanego zazwyczaj pod jedną nazwą.

Podobnie problemem było to np. że w niektórych miastach, np. we Wrocławiu, są linie dookólne, tramwaj linii zero, który jeździ dookoła miasta, po trasie stanowiącej pętlę. Tam musieliśmy z kolei zadbać o to żeby ta pętla – publikowana w formacie dwóch połówek – była scalona w jedną trasę, w obie strony. Dzięki temu wyszukiwanie połączeń działało lepiej.

Niełatwe było też czytelne prezentowane tras alternatywnych. Gdybyśmy chcieli w jakiś czytelny sposób prezentować linie z opcjonalnym wariantem w środku trasy, to ciężko było o zrobienie tego na malutkim ekraniku komórki. Przypomnijmy że wówczas ekrany miały 3.5 cala przekątnej. I zmieszczenie zestawu informacji na tak małym ekranie było sporym wyzwaniem.

[1:02:02] Dalszy rozwój programu

Program rozwijał się. Gdy popatrzymy na statystyki pobrań z pierwszego roku istnienia, możemy zauważyć, że – mimo relatywnie niewielkiej liczby użytkowników smartfonów w tamtym czasie w Polsce – mamy tutaj bardzo ostry skok w górę. Jeśli tam w lutym czy w marcu mieliśmy do czynienia z 20 pobraniami dziennie, to pod koniec roku było ich już dziesięć razy więcej. Zdarzało się ponad 250 pobrań dziennie. Problem leżał w tej małej czerwonej części wykresu na dole. To sprzedaż funkcji premium, o której więcej powiem za chwilę. Widzimy że ona nie rośnie. I gdybym tak naprawdę na serio myślał o stworzeniu biznesu z Transportoida już wtedy, to powinienem bardziej to sobie wziąć do serca, sprawdzić czemu tak jest i coś próbować z tym zrobić.

Nic nie zrobiłem, póki co byłem bardziej zajawiony na to, żeby było więcej miast, żeby były nowe funkcje w programie. Pomysłów nie brakowało. Więc owszem, takie statystyki robiłem na własne potrzeby czy też na potrzeby podsumowań na stronie. Ale nie podejmowałem żadnych akcji w chwili, gdy przydałoby się zastanowić, czemu jest tak a nie inaczej.

Dwa razy udało mi się we Wrocławiu spotkać na ulicy użytkowników programu, w obu przypadkach były to użytkowniczki. Pamiętam pierwszy przypadek – stałem na czerwonym świetle przy przejściu dla pieszych i zobaczyłem, że dziewczyna która stoi obok, coś przegląda na komórce i to był właśnie Transportoid. Idąc na przystanek sprawdzała sobie rozkłady. Jakie to było fajne uczucie – spotkać użytkownika, który używa twojego programu! Nic wtedy nie powiedziałem, ale pamiętam swoją ekscytację, że to naprawdę się dzieje.

Zdarzyło się to jeszcze drugi raz – na mieście zauważyłem jakąś inną dziewczynę która też korzystała z Transportoida – wtedy odważyłem się zagadać. Nie pamiętam co dokładnie powiedziałem, pamiętam że spuściła mnie na drzewo w 2-3 słowach. No cóż. Ja to zapamiętałem jako sytuację, w której ktoś używa mojego programu. Ona to pewnie zapamiętała jako najbardziej żenujący podryw świata – „na programistę”. Tak więc spotkałem użytkowników Transportoida dwa razy. I zamknijmy ten temat.

Jeśli chodzi o programowanie Transportoida, to można powiedzieć że pod górkę było w obie strony, czyli stare ciężkie czasy, których dzisiejsze dzieci już nie zrozumieją. Ale tak było! Transportoid był jednym z pierwszych programów, które były opublikowane na polskim rynku. Android zadebiutował w Europie w roku 2009, a już na początku 2010 Transportoid był i działał. I to oznaczało, że no trzeba go było pisać tymi narzędziami, w tych technologiach które wtedy były dostępne. Brakowało dobrych narzędzi – bo Eclipse, który służył do programowania Androida w tamtym czasie, to nie było dobre narzędzie. Był przeraźliwie wolny i niewygodny – zwłaszcza w porównaniu do Android Studio, czyli pochodną edytora IntelliJ. Jak to wszystko wtedy zaczęło śmigać! Naprawdę, niebo a ziemia.

Brakowało w tamtych czasach szybkiego emulatora. Ten, który był, emulował programowo procesor urządzenia mobilnego, co sprawiało, że prędkość wynosiła może 10-20% prędkości rzeczywistego urządzenia. Minęło wiele lat zanim pojawiły się emulatory z wirtualizacją i akceleracją sprzętową z prawdziwego zdarzenia.

Podczas tworzenia Transportoida szybciej było debugować na prawdziwym urządzeniu, tylko że wtedy czas kompilacji i wrzucenia nowej paczki na telefon, to też była istotna przerwa w pracy. Brakowało bibliotek, które rozwiązywałyby popularne problemy – np. wyświetlanie grafiki albo pobieranie plików z sieci. Oczywiście, jakąś część podstawowych funkcji dostarczał SDK Androida, ale było to zupełnie nieporównywalne do tych bibliotek, które pojawiły się już kilka lat później.

Podobnie – brakowało dobrych wytycznych projektowania interfejsu użytkownika. Jakieś były, niezbyt dobre, ogólnie Android na początku przez pierwsze lata był bardzo brzydki. Dopiero Android 5 wprowadził Material Design, nowy zestaw kontrolek i kompletny zestaw wzorców projektowych. Dopiero wtedy spójność platformy się poprawiła no i te programy zrobiły się troszkę ładniejsze, bo wcześniej wszystko było ciemne i nieładne.

To może teraz parę słów o jakości Androida z punktu widzenia programisty. Wiadomo – był nowy. Błędów była cała masa. No, ale można się było spodziewać, że w kolejnych wersjach systemu będą one systematycznie poprawiane i że sytuacja się poprawi. Niestety, okazuje się że w Google to tak to nie działa. Dziesiątki błędów, które pojawiły się w pierwszych wersjach Androida, żyły w nim potem przez ponad dekadę. Niektóre są z nami do dziś. Oczywiście gdy mieliśmy do czynienia z jakimś opensource’owym kawałkiem kodu, to dało się zrobić jakieś obejście tzn. dało się zaimplementować własną funkcję, która robiła coś w sposób poprawny, ale nie zawsze było to możliwe.

Biblioteka programistyczna Google Maps to komponent, który jest dostarczany przez Google bez kodu źródłowego. Nie dało się naprawić błędów, które tam występowały. Jeden z nich to usterka, na którą natrafiłem w roku 2013. Jeśli skorzystamy z funkcji rysowania wypełnionego wielokąta na mapie, to czasem przy pewnym poziomie powiększenia taki wielokąt traci wypełnienie. Przeskakujemy do roku 2022, ten błąd dalej jest aktywny i nadal występuje. Przez 8 lat nikt z Google go nie poprawił, mimo że to jest błąd, który pojawia się nawet w produktach Google.

Przez długi czas nie wiedziałem co może być przyczyną takiego stanu rzeczy – aż trafiłem na taki cytat pracowników Google, w którym opisywali, że jedyne, co decyduje o awansach, to wydanie czegoś nowego na rynek. Że nikt nigdy nie dostał tam awansu za to utrzymanie jakości, albo naprawianie czy utrzymanie produktu w dobrym stanie. Kultura organizacyjna sprawiała, że tam pracownicy nadali nawet nazwę takiemu cyklowi nazwę LPA czyli launch promo abandon – odpal, awansuj i porzuć. I najwyraźniej tak to działa po dziś dzień.

Tworzyłem program, który czasem u kogoś się zawieszał. I ja – jako autor – musiałem się dowiedzieć co nie działa. Oczywiście ciężko było korespondować z użytkownikami którzy zgłaszali jakiś błąd – zwłaszcza gdy pojawił się on tylko raz. Ludzie spoza IT nie mają też nawyku opisywania błędów w formie kroków prowadzących do odtworzenia problemu. Zwykli ludzie bardziej pisali raczej „coś kliknąłem, coś wyskoczyło a potem przestało działać”. Wiedziałem że coś im nie działa, ale nie wiedziałem co.

Nie istniały jeszcze gotowe komponenty, które pozwalałyby na zdalne zgłaszanie błędów. Parę lat później pojawił się Crashlytics – usługa pozwalająca dowiedzieć się, ilu osobom i w którym fragmencie kodu program przestawał działać. Ja zaimplementowałem raportowanie błędów w sposób troszkę bardziej prymitywny. Gdy program się zawieszał, ostatkiem sił zapisywał do pliku wszystkie okoliczności błędu. I potem gdy użytkownik uruchamiał Transportoida jeszcze raz, to program pytał, czy może wysłać mailem raport błędu.

Dostawałem raport w którym były następujące informacje: kiedy błąd wystąpił, na jakim urządzeniu, na którym modelu, na której wersji Androida, czy to był oryginalny ROM czy jakiś customowy (do takich zgłoszeń przywiązywałem mniej uwagi). Miałem też listę pokazującą co użytkownik robił i kiedy w co klikał. No i był też stacktrace czyli wskazanie nieprawidłowej operacji. Dzięki temu byłem w stanie te błędy identyfikować i poprawiać.

Gdy zauważałem, że po wydaniu nowej wersji błędów pojawia się więcej, trzeba było znaleźć przyczynę. Zmniejszenie dziennego urobku oznaczało, że poprawki działają. Trzeba też pamiętać, że sam system Android był w tamtych czasach bardziej zawodny no i zdarzały się błędy spowodowane usterką w oprogramowaniu jednego producenta albo konkretnego modelu telefonu.

Jeśli chodzi o liczbę miast, jaką obsługiwał Transportoid – przekroczyła ona 50. Nie bójmy się tego powiedzieć – było ich za dużo. To nie miało uzasadnienia ekonomicznego, wyścig był raczej o pietruszkę tzn. o miano programu, który ma tych rozkładów najwięcej. Była pewna satysfakcja, że mamy najwięcej miast, ale w niektórych nie było ani jednego aktywnego abonamentu. Czyli nie było ani jednego płacącego użytkownika z danego miasta. Wystarczy spojrzeć, że po dziś dzień Jakdojade nie ma tylu miast. Oni przeanalizowali, co im się opłaca, a co nie.

Jeśli chodzi o społeczność, to można powiedzieć że taka społeczność się pojawiła. Nie było to spójne grono ludzi, ale użytkownicy, którzy np. pisali regularnie na forum android.com.pl i tam komentowali nowe funkcje. Mogliśmy ich zapytać – jako tych naszych power userów – o opinię na jakiś temat. Podobnie, korespondencja mailowa dotycząca nowych funkcji i błędów miała miejsce bardzo często. I bardzo wiele osób pisało z konkretnymi życzeniami, czy wręcz żądaniami, że życzą sobie, żeby jakaś funkcja została zaimplementowana, no i tutaj udało się rozwiązać ten problem, że każdy jest przywiązany do swojego pomysłu i uważa że jego pomysł powinien być zrealizowany jako pierwszy.

Udało się to rozbroić za pomocą webowej aplikacji UserVoice czyli głos użytkownika. To tam odsyłałem ludzi z pomysłami i prosiłem by sprawdzili, czy taki pomysł nie został już zgłoszony – wówczas wystarczy samo zagłosowanie. Tak tworzyła się lista pożądanych funkcji i lista pożądanych miast, na które głosowali użytkownicy. A my z Piotrkiem wiedzieliśmy na co jest popyt i które funkcje interesują największą grupę użytkowników.

Nawet przy pomysłach całkiem od czapy nie musiałem odpisywać człowiekowi, że sorry, ale pomysł nie jest dobry i na pewno go nie zaimplementujemy. Mogłem mu napisać, aby wrzucił pomysł pod głosowanie i zobaczymy, ile osób go poprze. Gdy okazywało się, że tam po 3 miesiącach były 2 głosy, losy pomysłu były przesądzone. Setki głosów oznaczały, że to jest coś, nad czym warto się pochylić.

Mieliśmy też do czynienia z crowdfundingiem. Pod koniec 2011 roku, gdy planowaliśmy z Piotrkiem i Tomkiem Przybylskim, w których obszarach moglibyśmy zainwestować pieniądze, żeby przyspieszyć rozwój programu, no to wyszło, że to mógłby być po pierwsze zakup sprzętu (telefon z 2 rdzeniowym procesorem), po drugie zaś – wynajęcie programisty do pomocy. Albo edytor map i przystanków. Albo nowa strona. Skracając nieco opowieść – nasz crowdfunding na platformie PolakPotrafi nie udał się. Z tej naszej społeczności około 100 osób wsparło projekt datkiem finansowym, co oznacza, że w modelu „wszystko albo nic” dostaliśmy owo „nic”, środki zostały zwrócone darczyńcom.

Rzeczą, która może nie jest jedyną na świecie, ale na pewno jest bardzo unikalna, była pudełkowa wersja Transportoida. Nie słyszałem o żadnym innym programie na Androida sprzedawanym w pudełku. Pomysł był następujący – gdy ktoś chciałby mieć taką niecodzienną rzecz, egzemplarz kolekcjonerski, to mógł sobie kupić go na Allegro z osobistymi podziękowaniami wewnątrz. Do tego był jeszcze złoty abonament. Na pojedynczej takiej sztuce mieliśmy znacznie większą marżę – przy kosztach rzędu kilkunastu zł i cenie sprzedaży chyba 50 zł. Oczywiście, gdy przeliczyć te złotówki na czas, który był potrzebny na realizację tego takiego przedsięwzięcia, to już tak dobrze nie było, ale… zrobiliśmy coś takiego, było to ciekawym pomysłem, pierwszy nakład kilkudziesięciu sztuk sprzedał się w całości. No i nie było kolejnego, bo było widać, że to jednak nie ma sensu.

Możecie spytać, co to był złoty abonament. Więc złoty abonament to był abonament na funkcje premium, który dawał dokładnie to samo co zwykły abonament – i chyba na taki sam okres. Natomiast był w programie wyświetlany na „złotej” blaszce, czyli na tle obrazka, który wyglądał dużo ładniej. Zwykły abonament, to był zwykły biały napis.

Tak wyglądała obwoluta tej wersji pudełkowej. I nie wiem, czy ktoś zwrócił uwagę, ale ten autobusik, który tutaj jest, on wygląda trochę inaczej niż ten autobus, który był na pierwszym slajdzie prezentacji. Z ikonką historia jest taka – ileś osób zwróciło mi niezależnie uwagę, że ktoś nam gwizdnął ikonę, bo w Android Markecie jest inny program z rozkładami, z innego kraju, z taką samą ikonką. Tymczasem nasz autobusik to była darmowa ikona, którą na całkowitym legalu pobrałem i używałem kiedy tworzyłem pierwszą wersję Transportoida. Ikonka była ładna, na licencji Creative Commons, więc można ją było wziąć i używać.

Aby jednak takie sytuacje się skończyły i żeby bardziej się jednak wyróżnić, zamówiliśmy nową ikonkę. W roku 2013 nastąpił delikatny rebranding. Nowa ikona była trochę prostsza kolorystycznie, nie udawała przezroczystości, więc nie trzeba się było tutaj martwić co będzie np. widoczne za tymi oknami w środku. Jednocześnie autobus stał się mniej autobusem rejsowym, a bardziej autobusem miejskim. No i cóż, trzeba było do niej przywyknąć. Zaletą było to, że ta ikonka była już kupiona na własność, zrobiona na zamówienie, na wyłączność. I oprócz tego, że była podobna do tej poprzedniej, no to dała nam też np. warianty w szarościach i biało-czarne.

Ciekawostki dostawaliśmy od użytkowników np. po lewej stronie mamy Transportoida działającego na BlackBerry, bo gdy ta platforma umierała i bankrutowała, to rzutem na taśmę twórcy tego systemu zaimplementowali zgodność z Androidem. Działały nawet mapy, a to nie było łatwe osiągniecie! W każdym razie ekran był kwadratowy i od któregoś z użytkowników dostaliśmy parę zrzutów ekranu z tam uruchomionego Transportoida.

Po prawej stronie widać zdjęcie smartwatcha Sony z tamtych czasów, czyli z roku 2013-14. Można w nim było umieścić widżet, jaki normalnie trafiał na pulpit. I to sprawiło, że można było mieć na takim smartwatchu właśnie rozkłady jazdy z Transportoida. Super sprawa, niestety nigdy nie zobaczyłem takiego zegarka na żywo.

[1:31:36] Windows Phone

Wszystko, co do tej pory mówiłem, dotyczyło Transportoida dla systemu Android. Nie była to jedyna edycja tego programu. W 2010 r. Microsoft wydał na rynek urządzenia z własnym mobilnym systemem operacyjnym. Był to Windows Phone 7, który potem wraz z upływem czasu zmienił się w Windows Phone. Była to nieudana – jak już dziś wiemy – próba wejścia giganta z Redmond na obcy dla siebie rynek smartfonów, zdominowany już wtedy przez iPhone’a i Androida.

Wiadomo było, że Android nigdzie się nie wybiera, bo był dostępny na szerokiej gamie tanich urządzeń. Wiadomo było, że iPhone również na pewno na rynku pozostanie – użytkownicy Apple pokochali iOS. Nie było jednak wiadomo czy jest miejsce na jeszcze jeden system operacyjny. Oprócz Windows Phone próbował na nim zaistnieć Palm Pre z systemem PalmOS. Dziś wiemy, że tego miejsca nie było, ale w 2010-11 tego wiedzieć nie mogliśmy – tym bardziej, że Microsoft odpalił całą siłę swego marketingu i działu sprzedaży.

Na rynku PC system Windows dominuje. W przypadku oprogramowania biurowego Office miażdży jakąkolwiek konkurencję. Można się było spodziewać, że także na rynku mobilnym Microsoft wykroi dla siebie co najmniej zauważalny kawałek tortu. W roku 2011 pracowałem w Microsofcie i miałem możliwość zdobycia za darmo słuchawki z tym systemem operacyjnym. Pracowałem w jednym zespole z Tomkiem Przybylskim, który wyraził zainteresowanie napisaniem Transportoida dla Windows Phone.

Wiedziałem, że jeśli na tym rynku pojawimy się z Transportoidem odpowiednio szybko, to może uda się zdobyć pozycję dominującą, jaką program miał już na Androidzie. No a rozszerzenie tej marki na nowy system operacyjny sprawi, że program będzie postrzegany jako coś poważniejszego, niż tylko program na samego Androida. Tomek dołączył do naszego zespołu, był jego trzecim członkiem.

Jeśli chodzi o programowanie, Windows Phone miał trochę unikalnych wyzwań. Wzorce projektowe interfejsu użytkownika zakładały, że gęstość informacji na ekranie będzie mała. Że będzie dużo przestrzeni, dużo przerw, czy pustych miejsc, by nie przeładować użytkownika informacjami. Stało to w kontrze do mobilnego rozkładu jazdy, który musi pokazać tych informacji na ekranie jak najwięcej. Innym problemem było np. to, że nie było tam SQLite czyli bazy danych, z której mogli korzystać programiści Androida i iOS. Do dyspozycji był jedynie LINQ to SQL, który był – lekko licząc – z 10 razy wolniejszy od SQLite. Stanowiło to duży problem.

Niespodzianką było też dla nas, że wersja premium – gdy została wydana – na Windows Phone sprzedawała się znacznie gorzej. Różnica była 4-5 krotna, przy zachowaniu proporcji liczby użytkowników na Androidzie i na Windows Phone. Z nieznanych nam przyczyn, użytkownicy byli znacznie mniej chętni do płacenia. Czy wynikało to z faktu, że płatność musiała być dokonywana poza oficjalnym sklepem? Nie wiadomo. Na Windows Phone nie było możliwości uiszczania opłaty abonamentowej wewnątrz aplikacji. Tak czy owak, Transportoid był dość popularny, utrzymywał się na pierwszym ekranie aplikacji popularnych w Polsce. Co najmniej dwa razy trafił na oficjalną, microsoftową listę najlepszych polskich aplikacji.

[1:37:52] Gościnnie – Tomasz Przybylski

Najlepiej będzie, jeśli o przygodach z programowaniem Windows Phone opowie Tomek Przybylski. Zapraszam na jego gościnne wystąpienie!

Tomasz Zieliński: część Tomek, pierwsze pytanie jest oczywiste: co sprawiło że zdecydowałeś się dołączyć do zespołu i przygotować Transportoida dla Windows Phone 7?

Tomasz Przybylski: część Tomasz, dzięki za zaproszenie do gawędy. Tak w skrócie, to zaciekawiłeś mnie projektem, więc zdecydowałem się dołączyć do zespołu. Przed samym Transportoidem dużo eksperymentowałem z platformą na Windows Phone, ale nie miałem na koncie żadnej skończonej aplikacji, jedynie kilka rozpoczętych pomysłów. Dołączenie do zespołu dało mi też dodatkowe motywacje, aby w końcu zająć się jakimś konkretnym projektem od samego początku aż do końca. Sam projekt zapowiadał się ciekawie od strony i technologii, jak również też mógł być potencjalnie używany przez sporą listę użytkowników jako aplikacja na co dzień.

Tomasz Zieliński: jakie największe problemy napotkałeś przy implementacji programu? Pamiętam, że od samego początku mieliśmy problem z wydajnością bazy danych.

Tomasz Przybylski: Tak, zdecydowanie mieliśmy sporo różnych problemów, największym była słaba wydajność bazy danych. Na platformie Windows Phone dostępny był SQL Serwer CE, który był dostępne przez LINQ to SQL. Taka kombinacja była bardzo wolna. Było to tyle uciążliwe, że import nowej bazy danych nie mógł się wykonać w tle, więc użytkownik musiał poczekać nawet kilka minut na przetworzenie pliku. Trudno było coś przyspieszyć. Metodą prób i błędów dzieliłem aktualizacje na paczki, wychodziło, że dla pewnej liczby zmian zapis jest najszybszy, więc po prostu stosowałem taki rozmiar.

Kolejny problem występował podczas przewijania długich list. List view po prostu nie nadążał z renderowaniem szablonów elementów, więc lista przewijała się pusta. Trzeba było poczekać, aż wątek renderujący szczegóły listy zacznie rysować detale elementów. Przejście na inną kontrolkę, tzw. long list, trochę pomagało, ale to też nie było dokładnie to. Było też dużo różnych innych mniejszych problemów np. mapy, na których rysowaliśmy przystanki i linie – był problem z wydajnością, gdy należało wyświetlić większą ilość etykiet.

Tomasz Zieliński: w czasach o których mówimy, publikacja nowej wersji programów Android Market trwała kilka minut. Microsoft podążył jednak śladami Apple i każda nowa wersja – zanim trafiła do użytkowników – musiała przejść przegląd. Czy było to dużym problemem?

Tomasz Przybylski: tak, to był zdecydowanie kolejny problem. Na publikacje w sklepie trzeba było poczekać co najmniej kilka dni. W przypadku jakichś większych świąt kolejki do przeglądu aplikacji były dużo dłuższe – Microsoft informował wcześniej o terminach, w których gwarantuje, że aplikacja przejdzie review. O ile jeszcze w przypadku dostarczania jakichś nowych funkcji dla aplikacji, taki długi czas oczekiwania na publikację był uciążliwy, to w przypadku jakichś poważnych awarii było to nie do pomyślenia.

Pamiętam, jak przy jednej aktualizacji udało mi się popełnić usterkę, z powodu której aplikacja wywalała się przy samym starcie. U mnie – na środowisku developerskim – oczywiście wszystko działało w porządku. Zaś na urządzeniach użytkowników, posiadających już jakieś wcześniejsze dane, aplikacja nie startowała. Sam błąd zaobserwowałem dość szybko, po przychodzących automatycznych zgłoszeniach crash’y z urządzeń użytkowników. Poprawka też nie była dużym problemem – godzinka-dwie i była gotowa. Niestety, największy problem dotyczył oczekiwania na przegląd aplikacji. Jeśli ktoś z użytkowników zaktualizował się do tej pechowej wersji, był odcięty od aplikacji przez tydzień albo więcej. Więc faktycznie – to duży problem.

Tomasz Zieliński: wytyczne dotyczące wyglądu interfejsu użytkownika w Windows Phone sugerował używanie dużych napisów, pozostawianie pustych przestrzeni, tymczasem rozkłady jazdy to dużo danych, które trzeba upakować dość ciasno. Jak godziłeś te sprzeczne wymagania?

Tomasz Przybylski: Microsoft na samym początku opisał dokładnie reguły obsługi dotyczące wielkości, fontów, marginesów, kolorów, reakcji na klawisze, które trzeba było spełnić. W tamtych czasach Microsoft kładł duży nacisk, aby aplikacje reprezentowały wysoki poziom a cały ekosystem Windows Phone wyglądał bardzo spójnie. Tak więc były wytyczne dotyczące użycia pamięci i procesora, sprawdzano czas startu aplikacji. W przypadku wyglądu – na szczęście – udawało się dojść do jakiegoś kompromisu. Problemem też często był sam język polski. Nasze słowa są jednak dłuższe, więc angielska wersja Transportoida miała łatwiej. Momentami również ciężko było pogodzić interfejs ze świata Andorid z tym co było zalecane na platformie Windows Phone. Ale tutaj ostatecznie trzeba było się zgodzić na wytyczne z Microsoftu.

Tomasz Zieliński: Windows Phone zadebiutował w roku 2010 i nie zdobył istotnego udziału w rynku smartfonów. Już ok. 2013 jasne było, że platforma ta jest skazana na porażkę. Dlaczego? Przecież Microsoft zainwestował wielkie kwoty w reklamę i promocję.

Tomasz Przybylski: Niestety, Windows Phone ostatecznie nie przyjął się. Trudno wskazać jakąś konkretną przyczynę, bo pewnie to był miks wielu różnych czynników i zdarzeń. Mimo rewelacyjnego środowiska developerskiego czyli Visual Studio, dość często brakowało przydatnych komponentów do budowania aplikacji. Samo API było dość ograniczone i mocno pilnowało, aby aplikacja nie narozrabiała i nie obciążała urządzenia. Dużo trudniej było również zarobić na aplikacjach. Rynek był mały, sklep miał często problemy z działaniem. Nie było też możliwości płacenia w aplikacji i trzeba było dostarczać wtedy własne rozwiązanie, tak właśnie zrobiliśmy w przypadku Transportoida.

Nawet, gdy deweloper wypuszczał darmową aplikację licząc, że zarobi na reklamach – to kolejny problem był taki, że brakowało reklam do wyświetlenia, więc nie było możliwości zarobku. Z punktu widzenia zwykłego użytkownika podstawowym problemem był brak odpowiedników aplikacji z Androida lub iOS. Przykład – na skutek różnych przepychanek między Microsoftem a Google, zniknęła podstawowa aplikacja YouTube. Trzeba było ratować się jakąś aplikacją third party, która ostatecznie i tak po jakimś czasie przestała działać. Na platformie brakowało wsparcia dla usług Google.

Dla takich pasjonatów jak ja, każda kolejna wersja systemu operacyjnego wymagała nowego urządzenia. Pamiętam, jak z niecierpliwością czekałem, aż Microsoft wypuści listę słuchawek, które dostaną aktualizację do nowej wersji. Zazwyczaj kończyło się tym, że trzeba było kupić nowy telefon. Po takich kilku numerach spadał zapał do posiadania telefonów z Windows Phone.

Tomasz Zieliński: przejrzałeś pewnie stary kod źródłowy – co ciekawego tam znalazłeś, o czym już zdążyłeś zapomnieć?

Tomasz Przybylski: tak, to była ciekawa przygoda, przejrzeć ponownie kod źródłowy, historię wszystkich commitów. Fajnie było patrzeć, jak próbowałem sobie poradzić z niektórymi problemami – dość często metodą prób i błędów. Po takim długim czasie pojawiły się nowe pomysły, z jakimś problemem można było zmierzyć się z całkiem innej strony jak np. z tą nieszczęsną bazą danych. Być może mielibyśmy możliwość przygotowania bazy SQL i zamiast wysyłać pliki TR2 na urządzenie, może przesyłanie pliku bazy danych już tutaj by dużo pomogło i rozwiązało problemy z importem?

Tomasz Zieliński: Tomek, dziękuję bardzo za Twój czas i podzielenie się swoimi wspomnieniami.

Tomasz Przybylski: dziękuję za rozmowę, część!

[1:47:36] Aktywizm społeczny

Nie planując tego, stałem się swego rodzaju aktywistą społecznym walczącym o prawa obywatelskie odbiorców rozkładów jazdy. Brzmi to śmiesznie, ale rozkłady jazdy komunikacji publicznej należą do kategorii tzw. „informacji publicznej”. Informacja publiczna to pojęcie zdefiniowane w prawie – jest to jest taka kategoria danych, które jakiś urząd albo jakaś jednostka administracji publicznej musi udostępniać na żądanie każdemu chętnemu. A taki chętny nie musi w żaden sposób uzasadniać swojego żądania.

Wynika to z tego, że spora część tych danych stanowiących informacją publiczną to coś, za wyprodukowanie czego już jako społeczeństwo zapłaciliśmy. No więc takie dane powinny służyć wszystkim – w szczególności osobom, które mają jakiś pomysł co z tym zrobić. Mamy jeszcze taki termin jak „ponowne wykorzystanie informacji publicznej” – czyli wyrażona wprost w przepisach zgoda na to, że te zastosowania informacji publicznej jakie komuś przyjdą do głowy mogą być zrealizowane bez pytania kogokolwiek o zgodę. Bez proszenia. W sytuacji, gdy rozkłady jazdy komunikacji publicznej są informacją publiczną to mogę je sobie wziąć i zrobić co z nimi, co zechcę. I nie muszę nikogo pytać o zgodę.

W moim przypadku było to oczywiście publikowanie rozkładów jazdy w aplikacji Transportoid. Jeśli chodzi o dostęp do danych źródłowych – czyli do rozkładów danych w formacie kursowym, a nie słupkowym – napotykaliśmy na problemy. Nieliczne miasta udostępniały takie dane od lat ‘90, np. Wrocław wystawiał dane rozkładowe w formacie XML. Każdy chętny mógł sobie ściągnąć całą paczkę w której miał pełne informacje rozkładowe. W niektórych miastach osoby lub instytucje dysponujące rozkładami oczekiwały jakiejś formy umowy. I to zazwyczaj była, nie bójmy się tego słowa, taka dupokrytka, która miała stanowić podstawę do udostępniania danych. My stwierdzaliśmy że nie będziemy wysuwać jakichkolwiek roszczeń jeśli te dane będą nieprawidłowe, druga strona mówiła, że nie będzie oczekiwać jakichkolwiek pieniędzy. No i po podpisaniu takiej umowy dostawaliśmy paczkę z rozkładami, a czy to był format słupkowy czy kursowy no to już zależało od konkretnego przypadku.

Tak czy owak możliwość pobrania całej takiej paczki za jednym zamachem była o wiele lepsza niż konieczność scrape’owania czyli ściągania dziesiątek tysięcy stron co noc tylko po to, by sprawdzić, czy coś się zmieniło w rozkładach. Były też miasta które chciałyby nam coś dać, ale nie miały jak, bo np. transport publiczny zarządzany był w aplikacji do której nie dokupili modułu eksportu danych, więc jedyne czym dysponowali, to zaszyfrowana kopia bezpieczeństwa bazy danych programu.

Gdy prosiłem o dane źródłowe, to trzeba było często sprawdzać jak zorganizowany jest transport publiczny w danym mieście. Czasem firma typu MPK to był tylko przewoźnik, który realizował przejazdy według zlecenia, a rozkłady układano w urzędzie miasta. W innych miastach było tak, że np. urząd miasta zlecał organizacje transportu i realizację założonej liczby wozokilometrów – a konkretne trasy i przystanki były zarządzane przez organizatora transportu.

Pośród wszystkich miast i przewoźników wyróżniał się specyficzny przypadek miasta Krakowa. Było tak, że Kraków wystawiał te wszystkie swoje rozkłady w paczce, na serwerze FTP, ale mógł je dostać tylko ten kto za nie zapłacił – była to cena rzędu 3 czy 4 tys. zł rocznie. To były pieniądze w ogóle nie przystające do tego, ile w tamtym czasie Transportoid zarabiał, więc zwróciłem się do urzędu miasta, który organizował w Krakowie transport, o udostępnienie tych rozkładów w trybie dostępu do informacji publicznej. Moje żądanie nie zostało rozpatrzone jak należy, tzn. urząd pozostał w bezczynności. W takiej sytuacji złożyłem do sądu administracyjnego dwie skargi, odbyły się 2 rozprawy, obie te sprawy wygrałem. Nie muszę o tym dokładnie opowiadać bo mogę przywołać materiały wideo z tamtego czasu – byłem w telewizji! Zobaczmy, co też było tamtego dnia w TV na temat tej mojej sprawy.

TVP: Czy MPK ogranicza dostęp do swoich rozkładów jazdy? Tak twierdzi autor aplikacji na telefony komórkowe z dokładnymi rozkładami jazdy komunikacji miejskiej. Informatyk pozwał przedsiębiorstwo do sądu, bo firma nie chciała mu udostępnić źródłowych baz danych. Teoretycznie wszystko jest jasne i dostępne. W końcu pasażerowie by korzystać z komunikacji miejskiej muszą znać rozkłady jazdy. Te widzą na przystankach, są też dostępne w internecie. By stworzyć aplikację z rozkładami na komórkę – to jednak za mało.

Tomasz Zieliński: potrzebuję dokładnego źródła, strony internetowe z których obecnie ściągam te rozkłady nie są takim źródłem bo nie zawierają wszystkich informacji, a część danych, których tam nie ma, nie da się zrekonstruować w inny sposób.

TVP: Tomasz Zieliński powołując się na prawo do publicznej informacji poprosił więc MPK o udostępnienie źródłowych baz danych. Uzyskał odpowiedź podobną do tej jaką my uzyskaliśmy dzisiaj.

MPK: udostępniamy w tym momencie w wystarczający sposób informacje w stosunku do tego w jaki sposób nakazują to robić przepisy prawa.

TVP: sąd, do którego zwrócił się ze skargą informatyk miał w tej sprawie inne zdanie.

WSA w Krakowie: zobowiązuje MPK S.A. w Krakowie do wydania w terminie 14 dni aktu lub podjęcia czynności w sprawie z wniosku Tomasza Zielińskiego

TVP: wyrok, co ciekawe, sprawy nie kończy, bo sąd uznał jedynie że MPK zbyło informatyka, zamiast przekazać mu konkretną uzasadnioną decyzje.

MPK: sąd zobowiązał MPK żeby taką decyzje wydało, nie przesądzając rzeczywiście co do treści tych decyzji

TVP: ta, wciąż może więc być odmowna.

Tomasz Zieliński: to jest jedyne miasto, które stara się utrudnić swoim pasażerom dostęp do dokładnych danych o kursowaniu pojazdów komunikacji miejskiej. Jest to dla mnie zupełnie niezrozumiałe.

TVP: z darmowej aplikacji Tomasza Zielińskiego korzysta 200 tys. osób w 59 polskich miastach, tylko krakowianie mają w telefonach niepełne dane. Informatyk już zapowiedział, że ewentualną odmowną decyzję MPK natychmiast ponownie zaskarży. Rafał Nowak-Bończa, Kronika.

Jakie były rezultaty tych dwóch wygranych? Nie było wspaniale. Na pewno dużą korzyścią było to, że w jednym z wyroków zostało wprost powiedziane: „nie ulega wątpliwości, że rozkłady jazdy są informacją publiczną”. To wcześniej nigdzie nie wybrzmiało, a w jednym z wyroków się pojawiło – więc to była ta dobra informacja.

Niestety – jeśli chodzi o samą praktykę przekazywania rozkładów przez MPK Kraków, mimo korzystnego wyroku, nic się nie zmieniło. Zacząłem dostawać te rozkłady jazdy, tylko że z ustawowym, 2-tygodniowym opóźnieniem. Gdy składałem w poniedziałek pierwszego wniosek o paczkę z rozkładami, to czternastego czy też piętnastego dostawałem taką paczkę – już nieaktualną. Miałem nadzieję, że zmęczę przeciwnika, tzn. zacząłem po kilka razy w tygodniu składać wnioski o dostęp do informacji publicznej, ale niestety wszystkie te wnioski były realizowane z 2-tygodniowym opóźnieniem, co sprawiało, że – w mieście wielkości Krakowa – otrzymywane dane zawsze były nieaktualne.

Do końca prowadzenia Transportoida nie udało nam się pozyskać z Krakowa danych w formacie kursowym, które pozwalałyby na wyszukiwanie połączeń z 2 przesiadkami. Jedyne co mieliśmy do dyspozycji to scrape’owane co noc rozkłady jazdy w formacie słupkowym.

O tej batalii pisałem długo i często – bo ta cała wymiana pism trwała miesiące. I o tym się zrobiło głośno – krajowe serwisy zajmujące się prawem odnotowały te moje starania. Były też efekty uboczne takiego bycia aktywistą, których się nie spodziewałem.

Teraz będzie taka trochę dygresja. Każdy z nas zna tego pana. To jest nigeryjski książę, który proponuje nam udział w wyprowadzeniu lewych pieniędzy – kwot sięgających milionów dolarów – z jego rodzinnego kraju. Albo on, albo wdowa po nim. Dość powiedzieć że nigeryjski scam, czyli nigeryjski przekręt, to forma wyłudzenia pieniędzy. Aby te miliony dolarów z konta nigeryjskiego księcia mogły być wytransferowane na nasze konto, no to okazuje się że tam trzeba zapłacić jakieś łapówki, trzeba temu nigeryjskiemu księciu najpierw przelać trochę kasy. A jak trochę przelejemy to się okazuje, że OK, ale trzeba jeszcze docisnąć, żeby już tym razem poszło. W ten sposób ludzie na całym świecie tracą naprawdę duże pieniądze.

Ja poczułem się bardzo podobnie, gdy któregoś dnia dostałem takiego e-maila, w którym pewien Richard zaprasza mnie do Brukseli na jakieś warsztaty. To jest prawdziwy screenshoot, mail był napisany na niebiesko. Było też napisane, że mnie zapraszają na jakiś panel dyskusyjny – i w sumie brakowało mi tylko informacji, gdzie mam wysłać pieniądze. Ale gdy sprawdziłem nagłówki i nazwiska, to okazało się, że faktycznie jest taki człowiek, pracuje w tym miejscu o którym mówi i że faktycznie takie wydarzenie będzie się odbywać – a ja nie dość, że nie muszę płacić żadnych pieniędzy, to jeszcze Komisja Europejska zapewni mi przelot, 5-gwiazdkowy hotel i dwudniowy pobyt w Brukseli na tymże właśnie warsztacie.

Potem skontaktował się ze mną asystent Richarda, ustalił szczegóły podróży itd. – i okazało się, że właśnie zostałem zaproszony na warsztaty poświęcone ponownemu wykorzystaniu informacji publicznej. Bo o tej mojej sprawie zrobiło się na tyle głośno, że wystąpiłem na panelu dyskusyjnym w Parlamencie Europejskim, gdzie opowiedziałem o swoim przypadku. I wiecie co? Ja nigdy jeszcze nie czułem się bardziej nie na miejscu, niż tam w Brukseli. Bo na tym panelu dyskusyjnym, w którym brałem udział, to paneliści przedstawiali się jakoś tak: nazywam się Hose Jakiśtam pełnomocnik rządu hiszpańskiego ds. czegośtam, od otwierania danych powiedzmy. Jakiś kolejny człowiek przedstawia się i mówi: tutaj John Jakiśtam, główny doradca prezydenta Obamy ds. czegośtam. No i doszło do mnie, więc mówię, Tomasz Zieliński – programista.

To było dziwaczne doświadczenie, Bruksela to nie jest za bardzo miejsce dla mnie. Ale jak chcieli posłuchać, co miałem do powiedzenia, to oczywiście opowiedziałem, na czym polegał mój konkretny problem z Transportoidem i ponownym wykorzystaniem informacji publicznej. Postulowałem wprowadzenie mechanizmów polegających na tym, że jeśli dana jednostka publiczna ma informacje w określonym formacie, to żeby zmusić ją do podzielenia się nimi. Żeby ten krakowski FTP był za darmo.

Dość powiedzieć, że moja agenda w Brukseli nie przebiła się na tyle, by ten problem natychmiast się rozwiązał. To trwało jeszcze lata, ale koniec końców krakowski MPK z tych czy innych powodów zaczął udostępniać rozkłady i w tej chwili możemy sobie pobrać GTFS (rozkłady krakowskie w formacie Google) za darmo. Aktualne. Gdyby ktoś teraz chciał je ponownie wykorzystać w jakimś celu to wreszcie może.

Nagrody. Transportoid otrzymał parę branżowych nagród. Niektóre były śmieszne, niektóre całkiem serio i miło było je dostawać. W styczniu 2011 r. na portalu pdaclub.pl Transportoid został określony najlepszym programem dla Androida w roku 2010. No konkurencja nie była strasznie duża, ale wygrać i tak było fajnie. Z kolei marcu 2012 na konferencji branżowej Transportoid został wyróżniony w kategorii Windows Phone 7. Tu mam tę laurkę. Zasługi powinien odebrać Tomek Przybylski, ponieważ to on programował tą wersję. I to było – można powiedzieć – serio.

Natomiast w 2013 portal android.com.pl przyznał mi tytuł najlepszego programisty Androida. Nigdy się nie uważałem za najlepszego programistę a już zwłaszcza najlepszego programistę Androida w sytuacji, kiedy w Polsce były już studia gamedev’owe które robiły całkiem fajne gry na tą platformę. I tam pracowali o wiele lepsi programiści ode mnie. Jeśli mogę się z czymś zgodzić, to tak, w 2012 r. robiłem sporo hałasu w związku z tą sprawą z MPK Kraków. I można było sporo w wielu miejscach się na mnie natknąć i na pewno szum, który robiłem, był głośny – więc otrzymałem nagrodę najlepszego programisty. To było troszkę śmieszne.

W marcu 2013 była jeszcze jakaś inna nagroda – chyba za promowanie ponownego wykorzystania informacji publicznej. Pojechałem do Warszawy, wygłosiłem jakąś prelekcję, przy okazji odebrałem nagrodę. Transportoid pojawiał się w prasie, zarówno papierowej (w tamtych czasach była jeszcze prasa papierowa) jak internetowej. Udzielenie wywiadu nie było dużym wysiłkiem, a zawsze to jakaś promocja projektu…

W zasadzie od samego początku zarabiania na Transportoidzie podjęliśmy z Piotrkiem decyzję, że będziemy część zysków czy też część przychodów przekazywać na dobroczynność. Wybór padł na Polską Akcję Humanitarną i kampanię poprawiająca poziom dostępu do wody pitnej. Pamiętam, że na początku przez jakiś czas przekazywaliśmy tam 20% przychodów, ale gdy się okazało, że czasem nie było żadnego zysku i musielibyśmy dopłacać – zmieniliśmy to na 20% zysku.

W ciągu całego okresu pracy nad programem było to w sumie ładnych kilkanaście tysięcy złotych. Co roku braliśmy udział w Wielkiej Orkiestrze Świątecznej Pomocy – sprzedawaliśmy jakieś takie lepsze abonamenty. Kilkuletnie albo wręcz wieczyste – i to za naprawdę spoko pieniądze. Braliśmy też udział w aukcjach charytatywnych. Fajnie było się przydać, wspomóc Polską Akcję Humanitarną czy Wielką Orkiestrę, to nadawało takiego jakiegoś sensu tej naszej zabawie.

[2:11:59] Pieniądze

Przyszedł czas, aby porozmawiać o pieniądzach, bo parę razy wspomniałem już o wersji premium i o sprzedaży abonamentów. Transportoid należał do kategorii freemium czyli oprogramowania, które jest dostępne za darmo, ale część funkcji wymaga uiszczenia opłaty. Wszyscy, którzy sprzedają oprogramowanie w tym modelu, zmagają się z dylematem: ile dać za darmo. Wiadomo, że jeśli damy zbyt dużo, to użytkownicy nie będą chcieli płacić, bo i tak już mają wszystko, czego im potrzeba. Jeśli z kolei damy za mało, to użytkownicy będą wkurzeni, że zostali zwabieni gratisem a doi się ich o wiele za mocno.

Nie udało nam się chyba jakoś za dobrze tego zbalansować. Transportoid w darmowej wersji nie zarabiał dostatecznie dużo. Mogliśmy troszkę bardziej cisnąć darmowych użytkowników, aby jednak za Transportoida płacili. Tym bardziej że był bardzo tani – abonament za funkcje premium kosztował 10 zł rocznie. Dodajmy że niektórzy użytkownicy całkowicie kwestionowali to, że chcemy dostać pieniądze za naszą pracę. Spotykaliśmy komentarze w stylu „za pazerność zawsze będę dawał jedną gwiazdkę” oraz „trzeba było robić reklamę”.

Reklam bannerowych ani pop-up nigdy w Transportoidzie nie było. Zawsze z Piotrkiem i z Tomkiem uważaliśmy, że takie coś nie jest fair w stosunku do użytkowników i że psuje jakość samej aplikacji. Uważaliśmy, że jeśli będziemy dostarczać produkt dostatecznie dobry, to użytkownicy będą nam chcieli za niego zapłacić. Co było w wersji płatnej?

W wersji dla Androida płatne było wyszukiwanie połączeń z dwiema przesiadkami. Przypominam, że dwie przesiadki były dostępne tylko w kilku miastach, w których mieliśmy format danych TR2, budowany z rozkładów kursowych. We wszystkich pozostałych miastach to nie było zachętą do kupna, bo tam w ogóle nie było takiej opcji. W Windows Phone funkcją premium było już szukanie połączeń z jedną przesiadką – ale akurat na tej platformie wszystko sprzedawało się znacznie słabiej niż na Androidzie, więc nie wygląda, żeby zachęta pomogła.

Inną funkcją premium, kierowaną do użytkowników bardziej zaawansowanych i szukających wygody, były widżety, czyli możliwość umieszczenia rozkładów na pulpicie. Ciekawostka – widżety są funkcją premium również w dzisiejszym androidowym Jakdojade. Trzecią funkcją premium, która też miała zachęcać do kupna abonamentu była funkcja grup przystanków. Użytkownicy mogli pod jedną nazwą zgromadzić zestaw przystanków np. „dom”, „praca”, albo „szkoła”. Można było zdefiniować piesze odległości od np. domu do otaczających go przystanków – a potem w funkcji wyszukiwania połączeń szukać połączenia z „domu” do „pracy” we wszystkich możliwych wariantach połączeń. Funkcja była całkiem fajna a przy tym unikalna, nie miał jej żaden inny program.

Gdy startowaliśmy na początku roku 2010, w Android Markecie w ogóle nie było płatnych aplikacji. Gdy pojawiły się pod koniec roku, to sprzedawać mogli tylko mieszkańcy kilkunastu najważniejszych dla Google krajów – m.in. Stanów Zjednoczonych, Kanady, Wielkiej Brytanii, Australii, Niemiec czy Włoch. W Polsce dopiero w maju 2012 r. pojawiła się możliwość założenia konta sprzedawcy i przyjmowania pieniędzy za sprzedawane aplikacje. To oznacza, że przez 2 lata musieliśmy sobie radzić inaczej.

Naszym sposobem obejścia problemu było sprzedawanie plików. Użytkownik kupował funkcję premium, potwierdzeniem tego zakupu był podpisany cyfrowo plik zawierający informację, komu przysługuje abonament i jak długo jest on ważny. Sprzedawaliśmy dostęp na kilka różnych sposobów. Pierwszym była biblioteka PayPal, oprócz tego przyjmowaliśmy też pieniądze poprzez Przelewy24 oraz Allegro. A gdy użytkownicy pytali, która metoda płatności jest dla nas najbardziej korzystna, to były to Przelewy24. Tam prowizja wynosiła 2.5% kwoty, w PayPal około 10% a w Android Markecie było aż 30% prowizji.

Abonament był tani. Nawet dziesięć lat temu kwota jednego biletu jednorazowego kwartalnie – czyli 10 zł rocznie – to było bardzo mało. I tutaj ciekawostka – niektórzy mieli podejście „płacę i wymagam”, nabierali przekonania, że od chwili zakupu będą rządzić całym developmentem i domagali się, aby natychmiast zacząć prace nad jakąś funkcją, którą oni akurat uważali za najważniejszą… Dość powiedzieć, że z tych 10 zł mi, jako programiście, zostawało w kieszeni jakieś 2 zł. Jeden klient był wart 2 zł rocznie. I teraz biorąc pod uwagę nawet ówczesne stawki rzędu – powiedzmy – 120 zł za godzinę (dzisiaj to jest znacznie więcej), dwa złote to jest koszt jednej minuty pracy. To oznacza, że jeśli ktoś zapłacił 10 zł i zaczynał stawiać żądania, to jedyną sensowną akcją było natychmiast oddać mu pieniądze. Żeby przestał być klientem, by stracił poczucie, że ma prawo stawiać żądania. Wszyscy wychodzili na zero a uciążliwy klient przestawał być klientem. Oczywiście – nadal miał do dyspozycji plik z abonamentem, ale znów – implementacja osobnego mechanizmu na kilku takich pieniaczy rocznie, by im jakoś odbierać te uprawnienia, w ogóle by się nie opłacała.

Gdy mówimy o opłacalności i o liczbie sprzedanych abonamentów, przypominam obrazek ze statystykami pierwszego roku dystrybucji. Liczba pobrań rosła, liczba klientów płacących za wersję premium nie rosła. I to było problemem. Za chwilkę pokażę rozpiskę, jak wyglądał typowy miesiąc w ujęciu finansowym.

Wspomnę jeszcze, że w 2011 r. wziąłem udział w konkursie dla startupów „LabStar”. Po tych wszystkich latach złość, którą wtedy miałem, już minęła i lepiej rozumiem sytuację jaka wtedy miała miejsce. Ale wówczas byłem troszkę zirytowany tym, że mimo przejścia przez eliminacje i wejścia z Transportoidem do finału, tak naprawdę jedyne, co Wirtualna Polska miała wtedy do zaoferowania, to wzięcie projektu pod swoje skrzydła i zatrudnienie mnie. Lub jakiś taki równoważny deal, który miał polegać na tym, że albo wp.pl stanie się właścicielem Transportoida, albo wiodącym udziałowcem, albo przynajmniej będzie cisnąć swoje własne reklamy w tym projekcie. Żadna z tych ofert mi nie odpowiadała. Okazało się do tego, że obiecywana nagroda pocieszenia, którą miała być jakaś promocją warta dziesiątki czy setki tysięcy zł, tak naprawdę odpowiadała reklamom Google wartym jakieś 200 zł. Spore rozczarowanie.

Dziś jednak lepiej rozumiem, że gdyby ktoś chciał wyłożyć jakieś pieniądze, to i tak widział, iż nawet po 10-krotnym wzroście przychodów Transportoid nadal byłby mikroskopijnym projekcikiem. Wartością, którą Transportoid miał wtedy, była duża liczba użytkowników i to, że za jego pomocą można było trafić z reklamami do wielu ludzi. Ale akurat reklam nie chciałem wstawiać do programu, więc nic z tego nie wynikło.

Gdy jakiś czas później zaczęliśmy się rozglądać na rynku różnych funduszy inwestycyjnych, modnych wówczas business angels albo seed investments, to szybko okazało się, że każdy z takich funduszy wymagał zawarcia w umowach klauzul drag along albo tag along. To by oznaczało, że taki inwestor, który wszedł z nami w jakąś spółkę, mógłby sprzedać swoje udziały a my musielibyśmy się dołączyć do takiej sprzedaży albo zaoferować wyższą cenę. W sytuacji, gdy w życiu prywatnym mielibyśmy pewnie problemy, żeby zmobilizować od tak dowolną kwotę pięciocyfrową, to de facto w dzień po założeniu spółki mogliśmy przestać być udziałowcami. Było jasne, że nie jest to transakcja na równych prawach dla obu stron i no – long story short – z poszukiwania inwestora dla Transportoida nic nie wyszło.

Rzeczą która wyszła – choć nie przyniosła istotnych pieniędzy – była funkcja kupowania biletów wprost z aplikacji. Taka np. aplikacja Jakdojade dorobiła się tego wiele, wiele lat później. Inna sprawa, że Jakdojade ma pewnie bezpośrednie umowy z przewoźnikami – my współpracowaliśmy z mPay i SkyCash. Płatność w aplikacji mPay wyglądała tak na obrazku, sprzedaż biletu była realizowana poprzez kody USSD. Transportoid mocno tu pomagał, bo dzięki niemu nie trzeba było pamiętać tych kodów. Użytkownik, który chciał kupić bilet, mógł to zrobić dosłownie trzema kliknięciami. W tamtych czasach było całkiem fajne.

Drugą integracją był SkyCash, w którym użytkownik mógł wybrać bilet a my robiliśmy tzw. głębokie linkowanie, czyli przekierowanie do aplikacji SkyCash, od razu do ekranu zakupu tego biletu. Nie pamiętam już w tej chwili dokładnych pieniędzy, ale obie te firmy operowały na bardzo małych prowizjach – 4% wartości biletu albo coś koło tego. Gdy bilet kosztował 2 zł, to stanowiło to raptem parę groszy. Wydaje mi się, że w umowach z mPay i SkyCash dostawaliśmy większość jeśli nie całość tej prowizji. To się sumowało do jakichś 200 zł miesięcznie. W szczycie popularności sprzedawaliśmy tą drogą parę tysięcy biletów przekładających się na kilkaset zł. Ale jak na e-commerce mobilny w tamtych czasach, to było całkiem nieźle. A Jakdojade miało to o wiele, wiele później więc była satysfakcja z tego, że mamy funkcje lubianą przez użytkowników, której konkurencja nie ma.

Dwa razy pojawiły się też w Transportoidzie dedykowane reklamy usług taksówkowych. To był chyba Taxity oraz iTaxi. Nie były to tradycyjne reklamy, tylko przyciski, które pozwalały w obsługiwanych miastach przejść do aplikacji reklamodawcy, który w ten sposób zwiększał świadomość istnienia swojej marki i usług.

Wszyscy pewnie są ciekawi jak wyglądał podział pieniędzy. Więc jeśli chodzi o Windows Phone, to tutaj mieliśmy współpracę z Tomkiem ustaloną na trochę innych zasadach. Jeśli natomiast chodzi o przychody z Transportoida na Androidzie, to z Piotrkiem dzieliliśmy się w taki sposób, że po mojej stronie były koszty wynikające z prowadzenia działalności gospodarczej, a resztę dzieliliśmy po równo, przekazując stosowny procent na dobroczynność. Przy typowym przychodzie wynoszącym 2500 zł dostawaliśmy na rękę po jakieś 500 zł. A biorąc pod uwagę, ile godzin spędzaliśmy nad Transportoidem, to pensja stróża nocnego byłaby znacznie lepsza, niż nasza startupowa „pensja” developera.

Tutaj mamy wykresik pokazujący ile przychodów przynosił Transportoid, widać, że w szczytowym momencie to było trochę ponad 3000 zł miesięcznie. Zaznaczyłem też, ile to było na osobę. Ta kwota oscylowała najczęściej w okolicach 500 zł przy czym często oglądała owe 500 od dołu. Więc to nie były duże pieniądze, żeby nie powiedzieć całkiem małe. I tak naprawdę relatywnie szybko widzieliśmy, że to nie zarabia jak powinno. Że użytkowników jest dużo, pobrań były setki tysięcy, ale pieniędzy z tego nie ma. Ale ciągle było na tyle fajne, że ten projekt ciągnęliśmy dalej.

[2:35:51] Zmierzch projektu

Od pewnego czasu wiedzieliśmy, że zmierzch nadchodzi. Świadomość ta narastała aż do momentu, gdy było wiadomo, że coś trzeba z tym zrobić. Przede wszystkim czuliśmy wypalenie. To był projekt po godzinach, który pochłaniał naprawdę dużo pracy. Wiadomo, że gdy ma się dzieci i inne takie obowiązki, to ciężko jest wyciąć dostatecznie dużo czasu, by robić jakiś realny postęp. Każdy z nas miał za dużo ról do obsadzenia. Wydaje mi się, że tutaj szczególnie ja byłem dotknięty, bo jako lider tego projektu naprawdę dużo różnych rzeczy miałem po swojej stronie – wsparcie użytkowników, organizację umów, developerkę programu, koordynację współpracy z klientami i zleceniobiorcami.

Support użytkowników był głównym problemem, tych maili było bardzo dużo. Mieliśmy bazę wiedzy, do której mogliśmy odsyłać ludzi, ale siadając do komputera przez pierwszą godzinę tylko odpisywałem na e-maile, a dopiero potem próbowałem napisać jakiś kawałek nowego kodu, zanim zasnąłem. Tempo tego developmentu było bardzo powolne. Nie motywowało nas, że sprzedaż nie rosła a w pewnym momencie zaczęła maleć.

U Piotrka problem był taki, że on obsługiwał te rozkłady samotnie. Dziesiątki miast. A pamiętajmy, że najwięcej do zrobienia było wtedy, gdy rozkłady się zmieniały, czyli w okolicach ferii, albo Wielkanocy czy Bożego Narodzenia – i tak naprawdę najwięcej zgłoszeń od użytkowników Piotrek miał w okolicach Bożego Narodzenia i Nowego Roku. To zjadało czas prywatny, po tych paru latach człowiek zadawał sobie pytanie, czy warto. I okazywało się z czasem, że coraz mniej.

Tym bardziej że mieliśmy już wtedy konkurencję. Wspomniałem nazwę serwisu Jakdojade. Ta usługa w wersji webowej istniała już od ładnych paru lat i można zaryzykować twierdzenie, że troszkę się z wejściem na mobilki spóźnili. Wersja androidowa pojawiła się dopiero pod koniec roku 2011. Byłem przekonany że wcześniejszy start da nam sporą przewagę – tymczasem mobilne Jakdojade wyprzedziło Transportoida w kwartał. To było dla mnie szokiem a morale poleciało mocno w dół.

[2:41:24] Gościnnie – Bartosz Burek (Jakdojade)

Jeśli chcecie dowiedzieć się jak to wyglądało od drugiej strony, czyli od strony Jakdojade, to mamy kolejnego, ostatniego już gościa, którym jest Bartosz Burek z Jakdojade, który opowie nam o tym dlaczego tak późno weszli na mobilki i czy byli zaskoczeni że tak dobrze sobie tam poradzili. Zapraszam!

Tomasz Zieliński: cześć Bartek! Miło gościć Cię w gawędzie! Pierwsze pytanie: serwis Jakdojade wystartował w roku 2008, smartfony zaczęły zdobywać popularność w roku 2009. Ale aplikacja mobilna Jakdojade została wydana dopiero w drugiej połowie 2011 r. Jakie było wasze spojrzenie na rynek mobilny w Polsce, skąd takie opóźnienie? Świadomie czekaliście na większą penetrację rynku smartfonami czy powody były inne?

Bartosz Burek (prezes zarządu, współwłaściciel Jakdojade): Dedykowana aplikacja Jakdojade na system Android została wydana dopiero w drugiej połowie roku 2011, zaś na system iOS na początku roku 2012. Co ciekawe, projekt Jakdojade zaczynał jako aplikacja na telefon, w postaci takiej aplikacji JAVA’owej – to były lata 2006-2007. Oczywiście wtedy to nie był smartfony, więc startując z naszym projektem już na poważnie – jako firma – zrobiliśmy stronę dostępną przez komputery. A także dosyć szybko wydaliśmy lekką stronę mobilną, dla użytkowników komórek. I faktycznie, w roku 2009 rynek smartfonów zyskiwał na znaczeniu. Aplikacje mobilne powstawały, zyskiwały na popularności, ale trochę to trwało. Rozwijała się także technologia HTML 5 i tutaj naprawdę zwlekaliśmy trochę, patrzyliśmy co się będzie działo na rynku. Czy jednak te mobilne strony lekkie będą górą czy aplikacje mobilne.

Skoro już mieliśmy lekką stronę mobilną, no trochę po prostu czekaliśmy i patrzyliśmy co będzie się działo i już pod koniec 2010 r. – może trochę za późno… ale pod koniec 2010 r. podjęliśmy decyzje o tym, że musimy mieć dedykowane aplikacje na Androida i na iOS. Tak, wtedy rozpoczęliśmy prace i jak zauważyłeś, pod koniec roku 2011 wydaliśmy aplikację na Androida i później także na iOS. Czyli z małym poślizgiem aplikacje startowały, ale było to myślę na tyle wcześnie, że zagospodarowaliśmy tę część rynku dosyć mocno.

Tomasz Zieliński: liczba instalacji androidowego Jakdojade wyprzedziła liczbę instalacji Transportoida w ciągu trzech miesięcy. Trzeba jednak pamiętać, że Transportoida tworzyło wówczas wieczorami dwóch hobbystów, to razem mniej niż jeden etat. Ile osób pracowało w 2011 r. w waszej firmie? Produkcję aplikacji mobilnych zleciliście na zewnątrz, czy od początku budowaliście kompetencje wewnątrz firmy?

Bartosz Burek: w 2011 r. w Jakdojade pracowało 5 osób. Kompetencje wewnętrzne, to było to na co stawialiśmy od samego początku – uważając, że nad produktem trzeba będzie cały czas pracować. I wydawało nam się, że dużo tańsze jest rozwijanie tych kompetencji wewnętrznych niż zlecanie tworzenia aplikacji do np. software house.

Tomasz Zieliński: w roku 2014 kontaktowałem się z Tobą w sprawie możliwości odkupienia Transportoida. Jednak nasze rozmowy nie doszły do etapu negocjacji ceny. Sprzedaliśmy potem projekt jedynemu chętnemu za kilkanaście tysięcy złotych. Czy z dzisiejszej perspektywy uważasz, że zakup i wchłonięcie marki Transportoid mogłoby wówczas przynieść jakieś korzyści dla Jakdojade? A może od zawsze mieliście swój harmonogram i plany niezależne od działań mniejszej konkurencji?

Bartosz Burek: Zawsze tworzyliśmy plany i strategie rozwoju produktu na kilka lat do przodu. No i tutaj oczywiście patrzyliśmy na rynek, ale, ale… tak jak tutaj pytasz, niezależnie od działań mniejszej konkurencji. Mieliśmy nasze plany rozwojowe, aczkolwiek – jak pokazuje przykład strony mobilnej versus aplikacje mobilne – na przestrzeni lat te plany ulegały zmianie, jeżeli rynek czy sytuacja tego wymagała. Natomiast no ja szczerze powiem – nie widziałem tutaj korzyści z przejęcia Twojej aplikacji i Twojej marki. Nie widziałem tego efektu synergii. Dlatego nie podszedłem w ogóle do negocjacji ceny.

Tomasz Zieliński: wersja premium mobilnego Jakdojade usuwa reklamy i dodaje widżety z rozkładami, kosztując 15 zł rocznie. Jaki procent użytkowników kupuje wersję premium? Czy te mniej-więcej 10 zł przychodu netto to więcej czy mniej niż przynoszą reklamy wyświetlane rocznie typowemu użytkownikowi?

Bartosz Burek: sztandarową zaletą naszej wersji premium jest to, że nie ma ona reklam. Taką wersję stworzyliśmy dobrych kilka lat temu idąc za głosami użytkowników, że chętnie zapłacą za wersję premium, by nie widzieć reklam. Użytkowników premium jest stosunkowo niedużo, około 2% instalacji. I na użytkownikach premium zarabiamy więcej niż na reklamach, jednostkowo w przeliczeniu użytkownik premium a użytkownik reklamowy. To użytkownik premium przynosi nam więcej pieniędzy.

Tomasz Zieliński: po premierze wyszukiwarki połączeń komunikacji publicznej w Google Maps wiele osób wróżyło Jakdojade i podobnym aplikacjom szybką marginalizację i śmierć. Nic takiego nie nastąpiło. Jak sądzisz, czy zagrożenie było realne? A może wejście tak wielkiego gracza było dla was korzystne? Wymusiło przecież na przewoźnikach dostawy rozkładów w formacie GTFS.

Bartosz Burek: Współpracując z przewoźnikami wykorzystywaliśmy format, który mieli, który publikowali. Wejście tego dużego gracza i wymuszenie na przewoźnikach tworzenia GTFS nie miało dla nas większego znaczenia, aczkolwiek GTFS jest może trochę prostszy w utrzymaniu. Natomiast oczywiście wejście Google Maps z usługą planowania podróży komunikacją miejską było dla nas niepokojące. Aczkolwiek wejście konkurenta zawsze jest czymś dobrym. I tutaj to jeszcze bardziej nas mobilizowało i motywowało żeby Jakdojade było lepsze nawet niż taki duży gracz.

No i tutaj oczywiście tworzenie bardzo przyjaznego i bardzo użytecznego rozwiązania to jest jedna rzecz, ale bardzo też od samego początku stawialiśmy na to, żeby nasze rozkłady i nasza wyszukiwarka była zawsze aktualna – no i mieliśmy przykłady, że Google Maps niestety tej aktualności nie ma. Szczególnie w takich momentach dużych zmian czyli przykładowo wejścia w życie rozkładów wakacyjnych czy świątecznych, czy przy okazji np. wdrażania linii cmentarnych przy okazji Wszystkich Świętych, to my tutaj działając regionalnie jesteśmy dużo bardziej skupieni, by dostarczać te rozkłady dokładnie i pokazywać wszystkie połączenia tak jak one faktycznie funkcjonują a nie tak jak funkcjonują powiedzmy w takim normalnym trybie.

Tomasz Zieliński: Bartek, bardzo dziękuję za poświęcony czas i podzielenie się opiniami o rynku na którym działacie z powodzeniem już od kilkunastu lat.

Bartek był ostatnim gościem naszej gawędy, pomału będziemy zmierzać w stronę końca. Gdy mówimy o zmierzchu projektu, który prowadziliśmy razem z Piotrkiem i z Tomkiem to zwraca uwagę, że Transportoid nie miał wersji na iOS. Przyczyna była bardzo prosta – nie mieliśmy dostatecznie dużo pieniędzy, by opłacić produkcję takiej wersji. Tym bardziej, że nie byłoby to zlecenie jednorazowe, tylko raczej kasa, którą trzeba byłoby pompować regularnie, żeby dowozić kolejne funkcje. Nie znalazł się też nikt, kto chciałby hobbystycznie dołączyć do naszego zespołu, robiąc aplikację na iOS.

Jednocześnie już w latach 2012-13 było widać, że Windows Phone nie zażarł, że mimo całej machiny marketingowej Microsoftu – to nie zadziałało. Najpierw bardzo szybko tracił na znaczeniu, potem Microsoft przestał w niego inwestować co oznaczało że słuchawki, które były na rynku, stanęły w miejscu. Użytkownicy też wiedzieli, że system nie ma przyszłości i szybko zmieniali swoje telefony na Androida albo iOS. Było widać, że tylko te dwa systemy przeżyją w jakiejś dłuższej perspektywie.

Nie da się ukryć, że w naszej apce narastał dług technologiczny. Dopiero w 2013 r. wprowadziliśmy format TR2, który dawał lepsze i szybsze wyszukiwanie. To było ponad rok po tym, gdy na Androidzie pojawiła się aplikacja Jakdojade. Każdy, kto potrzebował lepszego wyszukiwania, sprawdzał Jakdojade i tam już zostawał. Funkcje powiązane z formatem TR2 były dobre, ale przybyły późno.

Tak samo redesign, czyli pozbycie się czarnego, brzydkiego schematu graficznego, z którym Transportoid startował. To był późny rok 2013. Wcześniej wielu użytkowników pisało, że program lubią ale czemu jest taki brzydki i czy da się coś z tym zrobić. No a gdy w końcu dało się, to co usłyszeliśmy? To, co zawsze się pojawia przy redesignach, czyli seria maili pod hasłem „wolałem jak było kiedyś”. Nie dało się wiele z tym zrobić, wtedy nie było jeszcze takich mechanizmów, które pozwalałyby swobodnie przełączać między trybem białym i czarnym.

Jeszcze większym przedsięwzięciem byłoby zaimplementowanie informacji czasu rzeczywistego, z prawdziwymi pozycjami pojazdów i czasem oczekiwania. To wymagałoby już porządnego zaplecza serwerowego i wiedzieliśmy dobrze, że takie zadanie było potężne. Obserwowaliśmy, jak pomału się to pojawiało w Jakdojade, które dysponowało wieloosobowym zespołem pracującym na pełen etat. A tutaj to były ciągle dwie albo trzy osoby po godzinach. Było niestety wiadomo, że tego nie pociągniemy, bo to jest za duży temat.

Gdy już było widać, że ten nasz projekt ma się ku końcowi, że nie jesteśmy w stanie obrócić trendu ani zarabiać konkretnych pieniędzy – zrobiliśmy burzę mózgów, co da się z tym projektem zrobić. Jaki skręt, jaki pivot możemy tutaj wykręcić, żeby Transportoid istniał dalej, ale żeby tym razem zarobił na swój rozwój i utrzymanie. Pojawił się pomysł, żeby zrobić wersję przeglądarkową i w oparciu o nią tutaj spróbować zbudować jakiś biznes.

Względnie szybko udało mi się za pomocą GWT i web workerów przenieść kod odpowiedzialny za wyszukiwanie połączeń z wersji androidowej do przeglądarki. I to działało naprawdę super fajnie i super szybko. Było widać, że na tej bazie można by zrobić takie Jakdojade, tylko działające szybciej. Mieliśmy pomysł, żeby na bazie tego zrobić komplet oprogramowania „mobilki i przeglądarka” i sprzedawać przewoźnikom jako zestaw w modelu white label. Czyli już bez marki Transportoid, ale za to jako projekt, który będzie działał dalej, brandowany pod konkretnych klientów albo działający w webkioskach (systemy informacyjne z ekranem dotykowym, znane z galerii handlowych).

Próba ta była całkowicie nieudana. Nie udało się przekształcić technologii Transportoida na produkt który ktoś chciałby kupić. Gdy po latach patrzyłem na fantastyczną aplikację Transit, w którą ktoś zainwestował duże pieniądze i która faktycznie jest używana przez wielu organizatorów transportu na całym świecie, to widać także jej twórcy zmagają się z problemami dotyczącymi finansowania rozwoju i zwrotu z inwestycji. Być może to jest rynek, który na całym świecie utrzyma raptem paru dostawców usług. A praca kilku amatorów nie dawała takiemu potencjalnemu klientowi nadziei na to, że się na tym rynku utrzymamy i że nasz produkt będzie potem przez sensowny czas supportowany. Więc trudno się dziwić że chętnych nie było.

Pojawiały się pytania, czemu nie zrobiliśmy z Transportoida projektu Open Source. Bardzo popularne było u wielu osób przekonanie, że przy takim modelu rozwoju soft kwitnie a wszystkie problemy znikają. Cóż, nie mieliśmy kolejki programistów czekających na szansę udziału w projekcie.

[3:00:54] Sprzedaż Transportoida

Gdy nie udało nam się zbudować żadnego produktu na bazie Transportoida, wystawiliśmy program na sprzedaż. Ogłoszenie pojawiło się w czerwcu 2014. Zainteresowana była jedynie interaktywna agencja Mobiem z Warszawy, której w sierpniu 2014 r. sprzedaliśmy cały projekt. Firma zapłaciła za całość 15 tys. zł., czyli po równym podziale na trzy osoby zainkasowaliśmy po 5000 zł brutto. To były ostatnie pieniądze jakie przyniósł Transportoid.

Ja do tego programu już nie powróciłem, Bałem się, że zainstaluję Transportoida, okaże się, że ma nieaktualne rozkłady, albo coś mu źle działa, i będzie mi smutno. Chciałem sobie tego uczucia oszczędzić, więc po tym, gdy Transportoida sprzedaliśmy, nigdy go już nie zainstalowałem.

I to koniec opowieści. Temat Transportoida uważam za wyczerpany.

---

Jeśli nie chcesz przegapić kolejnej gawędy, zapisz się na newsletter. Do usłyszenia!