Efter det sidste ikke 100% succesrige eksperiment med at gennemskue hvor brugeren er på en rute prøver jeg lidt flere ting. Næste forsøg har været at tage med i betragtning hvilken retning brugeren bevæger sig i. Det virker faktisk ret fornuftigt på de eksempler jeg har afprøvet.
Ruten jeg prøver her går fra København til Aalborg og i eksemplet fra sidst hvor der er forvirring omkring Vejle, hvis du bevæger dig i den rigtige retning kan den nu finde ud af at du er på vej fra Vejle mod Hedensted osse selv om du faktisk er tættere på en linje mellem Brejning og Vejle.
Omvendt hvis du bevæger dig i den modsatte retning af ruten er den om muligt mere forvirret end før. Sådan må det lissom være. Og i øvrigt hvis du sidder i et tog der kører den forkerte retning på skinnerne har du større problemer end at din app er forvirret.
Det løser dog ikke alting. Omkring Århus er der stadig et problem, dog et mindre nu end før.
Jeg arbejder videre med at lave så man kan finde ud af hvor langt man er nået på en tur. Jeg har designet et første bud på hvordan man kan vise det i app'en,
Derudover leger jeg stadig med hvordan jeg rent praktisk skal afgøre hvor på ruten en bruger er når det eneste jeg ved er deres nuværende position. For at få et indtryk har jeg lavet en side hvor jeg kan tegne en rute ind på google maps og så beregne hvor på ruten systemet ville mene man er hvis man stod der hvor musen er. Det er lidt nemmere (og billigere!) end faktisk at rejse rundt i landet.
Udfordringen er at app'en ofte ikke ved præcis hvor en bus eller tog kører undervejs, den ved kun hvor de skal fra og til. Det vil sige at givet hvor brugeren er lige nu, som kan være langt væk fra den lige linje mellem sidste og næste stop, skal systemet give et bud på hvor langt de er mellem de to. Den tilgang jeg fandt på for et par uger siden virker sådan set okay langt hen ad vejen, når ruten ikke afviger alt for drastisk fra linjen mellem de to stop:
Men – kæden hopper desværre tit af. F.eks her kan man se at jernbanen fra Vejle til Hedensted faktisk kommer tættere på en lige linje fra Brejning til Vejle end fra Vejle til Hedensted, så på vejen fra Vejle til Hedensted vil systemet misforstå og tror du er mellem Brejning og Vejle. Ikke optimalt.
Endnu mere grelt er det i Århus hvor toget kører ind og ud af byen samme vej, så forvirringen er total.
Der er forskellige måder man kan håndtere det og jeg er ikke helt i mål med hvordan. En mulighed er at kigge ikke bare på hvor du er men hvilken retning du bevæger dig. Så kan man kende forskel på om du er på vej ind i eller ud af Århus, osse selv om sporene de to veje går lige ved siden af hinanden. En anden mulighed er at huske hvor du har været så hvis du lige har været i Brejning og Vejle er du nok ikke på vej tilbage men videre til Hedensted. En tredje mulighed er at tage med i betragtning hvor det er meningen toget skal være efter køreplanen men det er farligt for de kan både være for tidligt og for sent.
I sidste ende bliver det nok en kombination af tilgange. Plus i nogle tilfælde har man faktisk en mere præcis beskrivelse af ruten så man ikke skal gætte helt så meget.
]]>Jeg har brugt det meste af denne uge på at lave den nye måde at søge efter ruter på. Jeg kunne genbruge det meste af det jeg allerede havde lavet til den gamle måde men skulle bare strikke det sammen på en ny måde. Jeg tror jeg er det meste af vejen med det nu men det skal finpudses før det er helt klart. Forhåbentlig kan det komme ud med en opdatering næste uge.
Her er en demo af hvad det kan nu.
I slutning af forrige uge blev jeg færdig (ahem, "færdig") med forbedringer til blinde brugere. Det sendte jeg afsted til afprøvning af nogle rigtige blinde brugere og resultatet var klart: det fungerer ikke super godt. Eller, det fungerer fint når jeg bruger app'en på min test maskine men anderledes og ringere når jeg gør det på min egen telefon og når mine test personer bruger den. Suk.
Samtidig viser det sig at det ikke kun er seende brugere der lige skal vænne sig til den måde man søger efter ruter men også blinde. Problemet er specielt at det er det allerførste nye brugere skal så det skal altså bare køre som smurt i olie. Og det gør det ikke. Så jeg er resigneret til at jeg kommer til at lave det om igen-igen, det bliver altså tredje forsøg. Jeg har i god ide om hvordan jeg gerne vil lave om og det burde forenkle det både i koden, for seende brugere og for blinde. Det er bare noget der kommer til at sluge noget tid.
Efter jeg var blevet "færdig" med forbedringerne forrige uge men før jeg vidste at det ikke fungerede var jeg hoppet med begge ben ud i nogle ret omfattende ændringer og dem har jeg arbejdet videre på indtil nu. Det er lidt langhåret at forklare hvad de består i men kort fortalt skrev jeg lang det meste af app'en om fra at være specifikt til android til at være lavet i C++ så det kunne bruges både på android og iOS. Der er dog stadig nogle få lommer af kode tilbage til android og en af dem er den kode der arbejder med bogmærker, hvilket betyder at C++ koden ikke kan få adgang til dem – de lever udenfor dens verden. Til noget af det næste jeg skal lave har C++ koden brug for at have den adgang så jeg har skullet flytte bogmærkerne fra android til C++. Det har så trukket forskellige andre ting med sig som har gjort strukturen meget enklere og mere generel, hvilket er super, men det har bare taget lidt tid. Det nærmer sig enden nu dog.
En ting der pludselig blev nem at lave var at vise hvor på en tur fra og til stoppene lå. Jeg har nu lavet det sådan at det bliver tegnet når man ser en tur, det er markeret hvor man skal stå på og af. Jeg ved ikke om det var det allervigtigste jeg kunne have lavet men når informationen nu var grydeklar alligevel tog det ikke lang tid at lave.
Jeg er lidt i tvivl om hvad det næste bliver jeg tager hul på men det kunne godt blive den nye måde at søge efter ruter.
]]>Jeg arbejder stadig det meste af tiden med at gøre app'en nemmere at bruge for blinde men er langsomt begyndt at kigge lidt fremad på nogle nye ideer. En af de ting jeg tænker måske at kigge på lidt senere på året er at få app'en til at kunne følge med i hvor langt du er på en rejse.
Jeg er ved den absolutte begyndelse af at finde ud af hvordan det skal fungere og der hvor jeg er startet er med at kigge på: hvis jeg kender din position og ved hvor en rute går hvordan finder jeg så ud af hvor på ruten det svarer til? Den tilgang jeg har forsøgt mig med i dag virker okay lovende. Jeg deler ruten ind i linjer mellem hvert par af stop der kommer efter hinanden og du finder ud af hvilke stop du er mellem ved at finde det linjesegment der er tættest på dig og så tage stoppene i hver ende.
Jeg har afprøvet det ved lave et lille program der kan tage et billede hvor der er indtegnet nogle linjesegmenter i forskellige farver og så tegner den de områder der hører til hver segment.
Der er lang vej igen men det ligner et sted at starte. Næste trin er at finde ud af: okay du er mellem de her to stop – men hvor meget af vejen mellem dem har du tilbagelagt?
]]>Bare en kort opfølgning: det er med i næste opdatering at man får vist de nærmeste transportformer først når man søger på ruter. Her er hvordan rækkefølgen er i Kastrup, Aarhus C, Frederikshavn og Ystad:
$ atb query_grid --type agencies --radius 50 55.070895 14.920060 +----+---------+------------------+ | id | dist_km | name | +----+---------+------------------+ | 0 | 0 | Bornholms Trafik | | 28 | 0 | Rute700 | | 9 | 15 | Mols-Linien | +----+---------+------------------+ $ atb query_grid --type route_types --radius 50 55.070895 14.920060 +----+---------+-------+ | id | dist_km | name | +----+---------+-------+ | 3 | 0 | BUS | | 4 | 15 | FERRY | +----+---------+-------+
$ atb query_grid --type agencies --radius 50 57.724226 10.598802 +----+---------+------+ | id | dist_km | name | +----+---------+------+ | 3 | 0 | NT | +----+---------+------+ $ atb query_grid --type route_types --radius 50 57.724226 10.598802 +----+---------+-------+ | id | dist_km | name | +----+---------+-------+ | 2 | 0 | TRAIN | | 3 | 0 | BUS | | 4 | 35.3553 | FERRY | +----+---------+-------+
$ atb query_grid --type agencies --radius 50 56.154194 10.214894 +----+---------+-------------+ | id | dist_km | name | +----+---------+-------------+ | 1 | 0 | DSB | | 3 | 0 | NT | | 7 | 0 | Midttrafik | | 10 | 0 | Arriva tog | | 6 | 29.1548 | Rejseplanen | | 25 | 32.0156 | Samsø Bus | | 19 | 50 | Sydtrafik | +----+---------+-------------+ $ atb query_grid --type route_types --radius 50 56.154194 10.214894 +----+---------+-------+ | id | dist_km | name | +----+---------+-------+ | 2 | 0 | TRAIN | | 3 | 0 | BUS | | 5 | 0 | TRAM | | 4 | 29.1548 | FERRY | +----+---------+-------+
$ atb query_grid --type agencies --radius 50 55.673477 12.521350 +----+---------+-------------------------------+ | id | dist_km | name | +----+---------+-------------------------------+ | 1 | 0 | DSB | | 4 | 0 | Movia | | 13 | 0 | DSB S-tog | | 14 | 0 | Metroselskabet | | 28 | 5 | Rute700 | | 17 | 5 | Gråhundbus | | 12 | 10 | Movia | | 23 | 28.2843 | Öresundståg | | 22 | 40.3113 | Sporvejsmuseet Skjoldenæsholm | | 6 | 41.2311 | Rejseplanen | +----+---------+-------------------------------+ $ atb query_grid --type route_types --radius 50 55.673477 12.521350 +----+---------+---------+ | id | dist_km | name | +----+---------+---------+ | 1 | 0 | METRO | | 2 | 0 | TRAIN | | 3 | 0 | BUS | | 6 | 0 | S_TRAIN | | 4 | 5 | FERRY | +----+---------+---------+
Denne uge har jeg arbejdet på at gøre A til B nemmere at bruge for blinde. Det lyder måske langhåret men jeg fik en masse feedback sidste uge jeg går ud fra og det der skal laves om er ikke så omfattende som jeg havde frygtet. Det der er langhåret ved det er at selv hvis du ved hvordan du gerne vil have din app til at fungere er TalkBack på android uhyggeligt tungt at danse med.
Som en afveksling når jeg bliver frustreret er jeg begyndt at arbejde på noget jeg længe gerne har villet lave. Der er flere steder jeg viser lister af ting hvor det der er relevant afhænger af hvor du befinder dig i landet. F.eks transportformer: hvis du er i København er det typisk relevant at se metro, det er det ikke hvis du er i Århus. Tilsvarende er det typisk relevant at se letbanen hvis du er i Århus men ikke i København. Tilsvarende med trafikselskaber: hvis du er i Aalborg er det typisk mere relevant at se NT end Fynbus. Og så videre. Så jeg vil gerne kunne ordne listerne baseret på hvor du er.
For at kunne det har jeg brug for at vide hvad der er relevant forskellige steder i landet og kunne slå op, givet et bestemt sted brugeren befinder sig: hvad er relevant lige her. Min løsning er i store træk at lave nogle små, meget grove, kort som giver hvad der findes forskellige steder. Her er kortene for hvilke transportformer der findes, der er et for hver type:
De er, i rækkefølge, metro, tog, bus, færge, letbane, og s-tog. Tilsvarende gemmer jeg kort der giver hvilke trafikselskaber der er i hvilke dele af landet, her er et udsnit:
De er Samsø Bus, Arriva, Sydtrafik, DSB, og Movia.
Hvis jeg kan finde ud af at få det til at spille i forhold til at bede om den nuværende position (det er altid langhåret på grund af tilladelser og den slags) vil transportformer blive vist i rækkefølge i forhold til hvor man befinder sig. Trafikselskaberne bliver ikke brugt endnu men det kommer på længere sigt.
]]>I forbindelse med at jeg har arbejdet på at finde naboerne til et stop har jeg osse indført noget der hedder "klynger" af stop. En klynge er nogle stop i nærheden af hinanden der hedder det samme. Det er næsten altid par af stop, et på hver side af vejen, men ikke altid. Den største klynge er Slagelse St. (Ndr.Stationsvej) hvor der er 17 stop lige ved siden af hinanden der alle hedder det samme:
Problemet før var at når man søgte efter et stop fik man ofte flere og fordi de hedder det samme er det ikke til at hitte ud af hvilket der er det rigtige. Efter den næste opdatering bliver stop i den samme klynge ikke vist individuelt men kun en gang. Her er et eksempel på før og efter:
Det burde gøre det lidt nemmere at finde det man leder efter.
]]>Jeg er gået i gang med at lave nogle nye funktioner i app'en. En stor del af arbejdet handler ikke om at tilføje noget som sådan men at få de funktioner der allerede er der til at virke mere hensigtsmæssigt. Men der er osse nogle nye ting man kommer til at kunne.
En ting jeg allerede har arbejdet med men som fortjener at blive gjort endnu bedre er at tage med i betragtning når man kan gå mellem stop. Lige nu er app'en ret striks omkring hvilket stop mener og kigger ikke altid på stop i nærheden. Det er jeg i gang med at gøre den lidt mere afslappet omkring.
For at kunne gøre det har app'en brug for at vide hvilke stop der er i nærheden af hinanden. Jeg kalder det at stoppene er naboer. Til det jeg skal lave er det nyttigt at vide for et givet stop, hvilke andre stop er der indenfor sådan rimelig gå afstand. Lige nu bruger jeg 1,25 km som radius – det er det man kan gå på et kvarter hvis man går 5 km/t. Der er i omegnen af 30.000 stop i Danmark og mange af dem, specielt inde i byerne, har mange naboer indenfor 1,25 km. Rekorden er Sankt Markus Allé & Vodroffsvej på Frederiksberg der har 149 andre stop indenfor 1,25 km. I alt er der 4,7 millioner "naboskaber", altså par af stop der er naboer. Jeg vil gerne gemme listen af naboer for hvert stop som en del af app'en for den er ret tung at beregne men 4,7 millioner er alt for meget – det ville fylde mere end hele resten af køreplanerne. Det jeg har arbejdet på denne uge er at løse det problem: hvordan gemmer jeg naboskaberne mellem stop uden at det fylder for meget.
Den løsning jeg er endt med at lave udnytter at når stop er i nærheden af hinanden har de gerne de samme andre stop som naboer. Det kan godt være Sankt Markus Allé & Vodroffsvej har 149 naboer og Danas Plads har 144 men fordi de ligger lige klods op og ned af hinanden er langt de fleste af de naboer de samme for de to. Måske 130 af dem er naboer til begge stop. Hvis jeg gemte en særskilt liste af naboer for hver af de to stop ville der være 293 i alt (149 + 144) men hvis jeg laver en liste med de 130 naboer de har til fælles og deler den mellem de to fylder det kun 163 tal (130 + 19 + 14). 19 er det antal stop Sankt Markus Allé & Vodroffsvej har ud over de 130 de begge har og 14 er det samme for Danas Plads. Det er en pladsbesparelse på næsten 50%.
Det har krævet lidt snilde at få til at virke og specielt at få systemet til selv at kunne genkende hvornår det er en god ide at dele naboer mellem flere stop. Men nu fungerer det og sparer så meget plads at det er realistisk at gemme nabo-listerne sammen med køreplanerne. Stoppet lige udenfor mit kontor bruger f.eks 3 delte nabo-lister som andre stop i nærheden osse henviser til.
Hvert screenshot viser en af de delte lister. De mørke stop er dem der indgår i listen, de lyse er andre stop der henviser til den liste. Her er et andet eksempel, det er et tilfældigt stop i Roskilde der osse bruger 3 delte nabo-lister
Meget af tiden når jeg arbejder på algoritmer går det op i meget abstrakte begreber: tal, afstande, afbildninger, scorings-funktioner, osv, ting der når jeg arbejder med dem ligger fjernt fra det praktiske problem jeg er i gang med at løse. Men når det så virker er det virkelig interessant at tage de løsninger algoritmen finder på og kigge på dem på et kort. Jeg kan ikke forklare præcis hvorfor der er tre delte nabo-lister lige der i Roskilde men det ser da meget fornuftigt ud.
]]>I løbet af sidste uge har jeg lavet forskellige små-ændringer til app'en. Blandt andet ikonet som jeg nævnte tidligere. Den mest synlige ændring er nok at man ikke længere kan vælge til/fra på et google maps kort. Man kan næsten det samme men den nye måde at søge på google maps er blevet lidt mere skrabet. Her er hvordan det så ud før:
En af de ting man opdager når man laver en app er at man til en vis grad skal løbe for at stå stille. Google ændrer f.eks løbende kravene til android apps, de opfinder nye ting og fjerner gamle ting. Nogen gange er det noget man skal forholde sig til og bruge tid på bare for at ens app kan blive ved med at køre. Det er det samme med Apple og iPhone apps.
Det nyeste tiltag er at app ikoner skal fungere anderledes på android. Hvor det i gamle dage bare var et billede i en bestemt størrelse skal det nu være mere kompliceret. Det er for at de kan vise dit ikon med forskellige former, runde, firkantede, rund-oval, hvad ved jeg. Og animere dem på fancy vis. Det ser sådan set meget fedt ud men det kræver at jeg laver et nyt ikon i deres nye format. Så har jeg samtidig benyttet lejligheden til at ændre det en smule. Ikke meget, bare en anelse.
Typisk er brugeren interesseret i at udvikleren ved så lidt som muligt om dem. Omvendt har udvikleren lyst til at vide så meget de overhovedet kan. Samtidig kræver loven at hvis udvikleren gemmer så detaljerede data om brugere at de er personhenførbare så skal brugeren have en masse rettigheder over dem. Så hvad gør man?
De fleste apps og websites "løser" problemet ved i det store hele at ignorere punkt 1 og 4 og gå all in på punkt 2 og 3. At ignorere punkt 1 har ikke de store konsekvenser, antallet af folk der som mig er villige til ikke at bruge en app fordi den overvåger dem er forsvindende lille. Man skulle tro at punkt 4 var sværere at ignorere men det er næsten lige så nemt: det er der første gang du bruger app'en hvor du trykker godkend til at langt juridisk dokument du ikke har læst, og så må de gøre hvad de vil med dine data. (Eller, jeg tror faktisk ikke et øjeblik på at det holder i retten men det gør ingen praktisk forskel så længe ingen trækker virksomheder i retten over det.)
Allerhelst ville jeg slet ikke at samle brugerstatistik men efter det meste af et år uden det må jeg bare indse at det er virkelig svært at leve uden. Det billede jeg har haft i baghovedet da jeg designede det var: nogen steder er der sådan nogen standere ved siden af cykelstierne der tæller hvor mange cyklister der er kørt forbi. Systemet ved ikke at det er mig der er kørt forbi, det eneste den holder styr på er at en eller anden er. Fra et privacy synspunkt er det helt fint med mig og jeg mener ikke det er urimeligt at opsamle den slags. Det jeg har forsøgt er at opsamle statistik i app'en i samme ånd.
Helt konkret den måde det virker er at app'en holder styr på hvilke dage du bruger den, og hvilke uger, måneder, og år. Det er bare internt i app'en, det bliver i første omgang ikke sendt nogen steder. Så f.eks hvis du har brugt app'en torsdag, lørdag, og søndag sidste uge ville den internt, på din telefon, have noteret at du brugte den sådan her:
Hvor mange gange du bruger den, om det er 1 eller 100, er ligemeget.
På et tidspunkt den følgende uge, lad os sige det er den 8. maj i dette tilfælde, kigger app'en igennem det den har noteret og ser om der er noget omkring perioder der er overstået. I så fald sender den en besked med den information tilbage til en server jeg har sat op. I dette tilfælde ville den sende de 5 første elementer på listen fordi den 8. maj er vi forbi de dage og vi er inde i den næste uge og måned. Det sidste element kan ikke sendes endnu fordi vi stadig er i året 2019. Den besked der bliver sendt indeholder intet om hvem det drejer sig om, kun en at en eller anden ukendt bruger derude der brugte app'en i de angivne perioder.
Serveren har en tæller for hver periode og den holder styr på hvor mange har brugt app'en mindst en gang for hver givet dag, uge, måned, osv. Og altså ikke per bruger, men samlet for alle brugere. Når serveren modtager en ny besked løber den igennem og lægger 1 til for hver periode der er nævnt. Det er alt hvad den gemmer, derefter smider den beskeden væk.
Det vil sige at jeg kan ikke følge nogen brugere individuelt det eneste jeg kan se er hvor mange brugere der har været indenfor en given periode. Præcis ligesom cykel tælleren bare holder styr på hvor mange der er cyklet forbi. Med tiden kommer jeg til at tilføje flere ting der bliver noteret, f.eks hvis jeg tilføjer en ny funktion vil jeg gerne vide hvor mange der har brugt den indenfor en given periode. Og jeg kan osse inddele data med noget ekstra information f.eks android version. Det svarer til hvis cykel tælleren ikke kun talte hvor mange der var passeret men delte dem op i to grupper, de der kørte over og de der kørte under 25 km/t. Det giver lidt mere information men princippet er det samme, der bliver aldrig gemt information for specifikke brugere men kun et samlet tal for alle brugere. Brugerne bliver bare underopdelt, f.eks efter android version.
Den måde jeg ser resultaterne er med et værktøj jeg osse lavede sidste uge, wot:
Det skal læses som: den 2., 4., og 5., maj var der i alt 1 bruger der brugte app'en, det var der osse ugen der startede 29. april (dvs sidste uge). Og sidste uge var der en bruger der havde android 27 installeret der brugte app'en. (Jeg har testet koden på min egen telefon sidste uge så brugeren er i alle tilfælde mig selv.)$ wot stats ls --- start_activity / day --- 2019-05-02 1 2019-05-04 1 2019-05-05 1 --- start_activity / week --- 2019-04-29 1 --- start_activity_by_version:27 / week --- 2019-04-29 1
Jeg er tilbage efter ferie. Eller, jeg kom faktisk tilbage sidste uge.
Jeg havde besluttet mig for at når jeg kom tilbage efter påsken ville jeg have taget stilling til hvordan jeg skulle fortsætte projektet. Det havde jeg sådan set osse: jeg tænkte, jeg kan ikke stoppe her jeg bliver nødt til som et minimum at blive færdig med iPhone udgaven. Derfor er jeg gået i gang med designe brugergrænsefladen til iOS, hvilket har været meget sjovt at komme i gang med. Jeg har allerede det basale system til at virke der og at se hvordan det kommer til at se ud osse begynder det at ligne noget der kan blive til noget. Her er bogmærker skærmen sammenholdt med mit design til Android.
De sidste par uger har jeg været syg og uarbejdsdygtig og de næste par holder jeg ferie. Så projektet har stået stille og der er ikke det store at fortælle, bliver det nok heller ikke før måske efter påske.
I mellemtiden er her et billede af kontorhunden der tager en slapper under mit skrivebord.
Nu skrev jeg i sidste post om at jeg ville arbejde på at strømline det arbejde jeg skal gøre når der kommer nye køreplaner for at app'en bliver opdateret. Måske er det et godt tidspunkt at beskrive hvordan det ser ud, helt lavpraktisk, når jeg opdaterer køreplanerne i dag.
Jeg får køreplanerne fra rejseplanen, de kommer som en stor zip fil. Når der er en ny udgave sender de en mail ud og det er første trin for mig – jeg opdager at der er kommet en mail fra dem,
I mailen er der et link direkte til zip filen men det link bruger jeg aldrig. For lang tid siden lavede jeg en proces der en gang imellem automatisk henter filen fra rejseplanen og hvis den har ændret sig siden sidst gemmer den en kopi. Det kom sig af at jeg var på ferie og jeg så mailen fra rejseplanen men kunne ikke (og havde ikke lyst til) at sidde og rode med at hente filer. Så nu ved jeg altid at processen gør det for mig. Den gemmer filen i google cloud, og der ligger den klar.
Som der står i detaljerne, de nye køreplaner ligger i en fil der hedder 20190314_20190605_v00.zip som er 33.4MB stor. Navnet er ikke det rejseplanen kalder den, det er et internt navn den er blevet tildelt fordi køreplanerne i filen løber fra 14. marts (20190314) til 5. juni (20190605) og det er den første fil vi har set der gør det (v00).
For at kunne bruge køreplanerne i A til B skal de processeres og transformeres og komprimeres ret omfattende. Det har jeg et script der gør. Det står osse for at hente filen fra google cloud, jeg skal ikke downloade den manuelt men bare checke at den findes og se hvad den hedder. Jeg skriver detaljerne af hvad scriptet skal gøre i en konfigurationsfil, hvoraf det meste typisk er det samme som sidste opdatering, og så starter jeg det. Så står det og tygger et kvarters, tyve minutters tid og efterlader en fil i det specielle format A til B bruger, som indeholder køreplanerne. Filen er typisk omkring 10% af størrelsen på den fil jeg hentede fra rejseplanen, hvilket er en stor del af pointen.
Her er hvordan en kørsel af scriptet ser ud, med store dele af ventetiden klippet ud
Når jeg har filen med køreplanerne skal jeg bygge en ny udgave af android app'en som køreplanerne bliver "bagt" ind i. Det ligner meget den proces jeg brugte til at lave køreplans filen: ændre nogle konfigurationsfiler og køre et script. Så bliver app'en bygget. Det tager måske 5 min.
Derefter skal jeg opdatere app'en i google play. Det vil man typisk gøre på deres hjemmeside, plus det er nødvendigt at lave ændringer et par andre steder. Jeg gjorde det manuelt til at starte med men blev ved med at lave fejl, jeg glemte altid et eller andet. Nu har jeg pakket hele operationen sammen så et script gør det, jeg skal bare – du gættede det – ændre en konfigurationsfil og så køre scriptet, så laver det opdateringen.
Hele processen med at bygge til android og publicere på google play ser sådan her ud,
Første forsøg på at opdatere på google play fejler på grund at netværket i min lejlighed. (Jeg skal have ringet til stofa og klaget igen).
På google play udgives A til B i tre forskellige "spor": internt, beta, og produktion. Produktion er den udgave langt de fleste har. Beta er den eksperimentelle udgave der kommer ud til nogle folk jeg kender, venner og familie. Internt er en udgave det kun er mig selv der ser. Opdateringer starter som interne, så får jeg opdateringen på min telefon og kan prøve om den virker. Hvis jeg mener den gør det forfremmer jeg den til beta, så er der lidt flere folk der får den. Efter lidt tid der, hvis alt stadig ser ud til at virke, forfremmer jeg koden helt til produktion og så kommer den ud til alle.
Stort set med det samme jeg har kørt scriptet ovenfor og det har udgivet opdateringen på det interne spor kan jeg se den på min telefon,
Så leger jeg lidt rundt med den og når det bare er en opdatering af køreplaner og ikke en rigtig kodeændring er der stort set aldrig problemer så under normale omstændigheder ville jeg hurtigt forfremme opdateringen. Desværre var dette et eksempel på at der er forskel på "aldrig" og "stort set aldrig" for faktisk er der problemer med opdateringen,
I sidste uge blev jeg færdig med den nye hjemmeside. Jeg er faktisk helt godt tilfreds efterhånden.
Det tog noget tid at få videoen til at fungere som jeg gerne vil have den til men jeg synes jeg er endt med noget der fungerer selv når man ser siden på en telefon, og det var målet. En del af udfordringen var osse at få det lavet så det giver mening hvad der foregår på skærmen og jeg ved ikke om det jeg har lavet er perfekt, men jeg tror det er godt nok.
Jeg lagde sidste hånd på hjemmesiden fredag eftermiddag og så tænkte jeg, jeg poster om app'en på reddit på mandag. Jeg har tidligere postet på r/Aarhus og jeg syntes jeg fik noget mega godt feedback. Plus det virkede som om folk syntes det var relevant. Derfor tænkte jeg, hvis jeg nu poster på r/Denmark er det sikkert fint og jeg havde allerede nogle halvhøje forventninger til at det ville blive godt modtaget. At poste på reddit i det hele taget ligger i forlængelse af min ide om at gå direkte til potentielle brugere.
For at springe direkte til moralen, min post var oppe nogle få minutter så endte den sådan her
Så, det var en skuffelse. Som i, ligge vågen om natten, har ikke arbejdet siden, har mest lyst til at opgive projektet niveau skuffelse.
Det har ikke noget med det der skete på reddit som sådan. Det er mere at jeg er enig – det jeg postede var spam og selvpromovering. Jeg troede oprigtigt det var noget der ville være nyttigt for folk men hvor meget af det spam jeg modtager, og som jeg synes er mega irriterende, er fra folk der lige så oprigtigt mener det de sender vil være nyttigt for mig? I hvert fald en del er jeg sikker på. Den slags, og en masse andet af samme skuffe, har jeg grublet meget over de sidste par dage.
Jeg er stadig ikke færdig med at gruble men i hvert fald en smule af min motivation for at fortsætte er kommet tilbage. Min tanke lige nu er at jeg holder resten af ugen fri og laver alt andet end at arbejde (og at skrive dagbog tæller åbenbart ikke som arbejde). Når jeg så kommer tilbage næste uge går jeg i gang med at arbejde på automatisk opdatering, det vil sige at køreplanerne bliver opdateret i app'en helt automatisk når der kommer nye uden at jeg behøver gøre andet end måske trykke godkend et eller andet sted. Det skal jeg have lavet under alle omstændigheder og det er en forudsætning for at jeg kan holde op med at arbejde aktivt på projektet. Når det så er på plads ser jeg hvordan jeg har det og tager stilling til om projektet er slut. Hvis jeg kender mig selv ret er det ikke, men det vil vise sig til den tid.
I mellemtiden forsøger jeg mig med lidt mere selvpromovering og hvis jeg finder noget positiv respons og måske endda nogle nye brugere vil det gøre det meget nemmere at fortsætte. Hvis ikke er det selvfølgelig surt men det vil osse være nyttig input.
]]>Det slog mig i begyndelsen af denne uge at der faktisk er lang vej fra at høre/læse om hvad A til B kan og så have en fornemmelse for hvordan den er at bruge i praksis. Det er et stort spring. Det er et problem for hvis ikke du har en fornemmelse af at det her er bedre hvorfor så installere den?
For at gøre det spring mindre fik jeg lyst til at lægge noget video ind på siden på atilb.dk som kan given en ide om hvordan den her app virker. Jeg er nok faldet lidt bagud med hvordan man laver hjemmesider så det viste sig at være et lidt omfattende projekt men det nærmer sig noget jeg synes virker okay. Der er mange trin undervejs.
Her er det sidste trin af udviklingen: jeg polerer en af de nye elementer i den nye hjemmeside med udviklingsværktøjerne i chrome. Det er mest farver, skrifttyper, marginer, den slags.
Den kode der tegner hjemmesiden arbejder jeg på i PyCharm. Det er den overordnede struktur.
Der er en smule grafik arbejde oveni. F.eks bliver videoen vist med omridset af en telefon nedenunder og noget halvgennemsigtig reflektion ovenpå. Det endte jeg at tegne i Inkscape.
Som et led i at få bedre kontakt til brugerne vil jeg gerne, ud over bare at være på twitter, facebook, osv, gøre noget gennem selve app'en. Men det er svært. Jeg vil ikke, ikke, lave den sædvanlige pop-up med "din mening er vigtig for os" for jeg synes selv de er irriterende. Men samtidig er brugernes mening vigtig for mig, det er lidt det der er pointen. Så spørgsmålet er om det at jeg gerne vil i kontakt med mine brugere er grundlæggende irriterende uanset hvordan jeg griber det an? Eller om det er okay og kan være ikke-irriterende hvis jeg gør det på den rigtige måde? Det er ikke noget jeg har et godt svar på, jeg tror det må komme an på et forsøg.
Her er mit design indtil videre:
Jeg har indtil videre fokuseret på det tekniske, først at få app'en til at fungere overhovedet og på det sidste på at få den til at være mere poleret og nemmere at bruge. Det med at få en masse brugere har jeg tænkt, det gør jeg noget ved når det tekniske er godt nok. Og ved du hvad, det kan man simpelthen se på hvor mange brugere jeg har:
Det svæver omkring 100 og har gjort det længe. Jeg er faktisk meget glad for mine 100 brugere, det er en overraskende stor procentdel af dem jeg har markedsført app'en overfor og det er ret stabilt – det er ikke sådan at folk forsvinder igen når de først er begyndt at bruge app'en. Men det er bare overhovedet ikke nok at bygge en forretning på.
Det har jeg så overvejet grundigt og lagt en plan med konkrete trin til at nå over 10.000 brugere over de næste 2 måneder. Eller, det er så komplet løgn. Det jeg i virkeligheden har gjort er at arbejde videre på det tekniske, fuld af skyldfølelse over ikke at arbejde på at få flere brugere, ligget vågen om natten og grublet og grublet og overvejet bare at opgive hele projektet fordi det fører ingen vegne, og holdt op med rigtig at svare når folk spørger hvordan det går med app'en fordi jeg synes det går skod.
Men det er osse bare sådan jeg typisk har det i januar/februar. Hvis ikke det er det ene jeg hopper ned i et sort hul over så er det det andet. Og så lidt senere kommer jeg op af hullet igen og det hele bliver mere konstruktivt og mindre selvpineri.
En del af problemet er at jeg faktisk har gjort lidt forskellige tiltag for at få flere brugere og det har bare ingen effekt haft overhovedet. Fælles for de ting jeg har gjort dog er at det ikke har været min målgruppe direkte men indirekte gennem f.eks medier, grupper der repræsenterer brugere af kollektiv trafik, osv. Det tror jeg har været en fejl. Jeg skal have fat i potentielle brugere direkte.
Baseret på den ide har jeg nu, og det er ikke løgn denne gang, en konkret plan for at få flere brugere. Den involverer i første omgang at A til B nu er til at finde på facebook, twitter, og instagram (som @HerErATilB alle tre steder). Derudover har jeg pustet nyt liv i atilb.dk:
Eller, det vil sige en meget meget lille del af A til B. Og, det vil sige på en iPhone simulator.
Det ser måske ikke ud af så meget men "E Main St / S Irving St" er navnet på et stoppested fra et test dataset jeg har, og jeg er nået langt nok til at jeg kan lave en iPhone app der indeholder det data set og den samme kode som på android der kan finde ud af at læse fra det.
At vise navnet på et stoppested er selvfølgelig ikke nær nok så nu skal jeg i gang med det næste trin: finde ud af hvordan man laver brugergrænseflader på iOS. Jeg ser mængder af instruktionsvideoer om den slags i øjeblikket og så snart de har dækket det jeg skal bruge går jeg i gang med at lave det.
Der skal nok blive en iPhone app ud af det her tænker jeg.
Nøglen til overhovedet at komme så langt er at jeg har opgivet min gamle mac og købt en ny. Eller, jeg siger ny, det er en brugt en fra 2013 som var på januar-tilbud. En sprit ny mac er grotesk dyr og i øvrigt er jeg bitter over at jeg overhovedet skal købe en for at kunne lave en iPhone app. Ingen krævede at jeg købte en ny computer for at lave android udgaven. Men den er rigtig hurtig, det er pludselig en fornøjelse at arbejde i XCode.
]]>
Over de sidste par uger har jeg ramt ind i lidt forskellige uhensigtsmæssigheder ved app'en som jeg besluttede mig for at forsøge at fixe denne uge. Nogle af dem ordnede jeg i går, et par stykker i dag, og nogle af dem har vist sig ikke at være noget jeg kan fixe.
Et problem har været at tidligere når man fik vist afgange mellem to stop hvor man skulle gå i en eller begge ender så viste den ikke afstanden man skulle gå. Det har jeg lavet om nu, og jeg benyttede mig af lejligheden til at rydde lidt op i hvordan afgange bliver vist i det hele taget.
Her er efter:
Og her som det var før:
Det er ikke specielt gennemgribende men en forbedring. Et specielt smertespunkt tidligere er at jeg skrev 40m et sted i betydningen "der er 40 meter" og lige ved siden af kunne der stå 40m i betydningen "om 40 minutter". For klarheds skyld står der nu altid 40 min når det er tid, 40m når det er afstand.
Et andet problem jeg opdagede er at de fleste (alle?) færger pludseligt mangler. Det viser sig at det gør de osse på rejseplanen og google maps – så der er et underliggende problem med rejseplanen. Det kan jeg ikke gøre så meget ved, andet end at gøre dem opmærksomme på, hvilket jeg har gjort.
]]>Jeg er tilbage på kontoret efter juleferien.
Mit store dilemma har været: jeg havde en deadline der hed at jeg skulle nå at lave tre nye funktioner inden juleferien, og derefter ville jeg gå over til at arbejde på iOS udgaven. Jeg nåede kun de to funktioner så spørgsmålet er: skal jeg blive ved og lave den tredje funktion eller skal jeg lade den ligge og gå direkte til iOS. Hvad er vigtigst?
Jeg er stadig ikke helt sikker. Den tredje funktion er "mine steder" og den vil være virkelig nyttig for alle brugere men specielt for blinde, hvilket er den vigtigste grund til at jeg har svært ved at udskyde den. Samtidig er det jeg hører 75% af tiden når jeg demonstrerer app'en "det ser super nyttigt ud, sig til når det virker til iPhone".
Min kompromis er at indtil videre arbejder jeg på begge ting samtidig. Jeg arbejder langsomt videre på "mine steder" (og har snydt og arbejdet lidt på det i ferien osse) men samtidig bruger jeg en masse tid på at sætte mig ind i hvordan man laver apps til iOS med timevis af instruktionsvideoer. Jeg har aldrig lavet en iOS app så jeg starter helt fra bunden. Før jul gik jeg osse selv over til at bruge en iPhone. Det er ret smertefuldt – jeg var for nærig til at købe en ny så jeg har en brugt 6'er jeg købte sidste år og den er super langsom og batteriet er skod. Men af samme grund er den perfekt at udvikle på. Hvis jeg kan få det til at køre godt på den kan jeg regne med at det kører godt på andre slags iPhones osse.
Jeg har længe ikke været super tilfreds med den introduktion man får vist første gang man åbner A til B. En ting er at jeg selv synes den slags introduktioner er lidt irriterende, men oveni synes jeg måske ikke jeg har eksekveret det specielt godt. Det ligner lidt noget rod. Det er et problem fordi det er den allerførste ting nye brugere ser – og en god oplevelse første gang du bruger en app er mega super vigtigt.
Jeg havde en ide til en bedre måde at gøre det og besluttede mig for at give det et forsøg i dag. Det viste sig at være meget nemmere end jeg havde frygtet at lave, og det fungerer mere eller mindre præcis som jeg gerne ville have det til.
Siden sidste opdatering har jeg arbejdet på at få den nye måde at søge efter køreplaner færdig. Jeg har haft det meste klar siden sidste uge men har slåsset med nogle detaljer som bare ikke ville helt på plads. Det mener jeg de er nu så med forbehold for uforudsete omstændigheder kommer der en opdatering ud med den nye søgning i dag.
Jeg er opmærksom på lidt forskellige mangler skarpe hjørner der trænger til at blive pudset men det er relativt småting. Det er meget bedre end det der er nu, selv med de små mangler der er, og det er det der gør forskellen.
Nu kommer den næste fase så: se hvad feedback der kommer.
Det går fremad med den nye måde at søge efter køreplaner. Det basale er på plads og brugergrænsefladen opfører sig i det store hele rigtigt. Som noget nyt har jeg tilføjet en måde at vælge steder med google maps.
Tanken lige nu er at den side du ser i demoen er den første, hvor man kan angive relativt groft hvilken køreplan man er interesseret i. Når man har udfyldt den afgører app'en om det er nok til bare at vise en bestemt køreplan. Hvis ikke kommer man ind på en side to hvor man skal vælge f.eks hvis der er flere stop i den by du rejser fra, hvilket stop vil du se. Og hvis der er flere ruter, f.eks IC, ICL, og RE, får du mulighed for at vælge nogle af dem fra.
De sidste par uger har jeg brugt det meste af tiden på forskellige petitesser, hvis jeg skal være helt ærlig. Det er lissom min motivation har taget et dyk, hvilket den plejer omkring nu så det er ikke så overraskende.
Det går stadig fremad med den nye måde at søge efter køreplaner på men der er bare meget arbejde i det, så det går ret langsomt. Den måde jeg har designet det på er meget enkel – der er tre tekstfelter der skal udfyldes: transportform, fra, og til – men der sker en enorm masse bag kulisserne. Jeg vil gerne have at man kan udfylde dem i hvilken som helst rækkefølge, og har man udfyldt noget skal det tages i betragtning i hvilke muligheder der bliver vist for de andre.
F.eks, hvis du allerede har valgt at din transportform er tog og du er ved at vælge hvor du skal til skal den kun vise steder man kan komme til med tog. Og den modsatte vej: hvis du har valgt at du vil til Silkeborg og nu vil vælge transportform skal den kun vise bus og tog, for det er de eneste måder at komme til Silkeborg. Plus, og det er den mest langhårede, hvis du har valgt hvor du skal fra og skal vælge hvor du vil til skal du kun se steder du faktisk kan komme til derfra. Gang så det med at der er flere forskellige slags steder man kan komme fra og til: et bestemt stoppested (f.eks specifikt Dokk1 letbanestation), et stednavn (f.eks hele Silkeborg) og din nuværende position, som er et sæt geografiske koordinater. Det er mange forskellige mulige kombinationer. Det er dem jeg arbejder mig, langsomt, igennem de her dage.
Nåja og så, bare for afvekslingen, fandt jeg min oldgamle mac frem. Jeg kan nu bygge al C++ koden på den og kun en enkelt test der fejler, som er en ligegyldig en. Det er allerførste skridt i retning af at lave en iPhone version. Eller, okay at skrive det hele om i C++ til at starte med var vel rimeligvis det første skridt så reelt er jeg gået mange skridt i den retning allerede, men du ved hvad jeg mener.