đŸȘŽ Simen skriver

Samtalekort som app

05. mai 202411 minutter Ă„ lese

Er du klar for det her? For dette kommer til Ă„ eskalere fort. Eller. SĂ„ fort som du klarer Ă„ lese, eller skumme gjennom innholdet, men mot slutten skal du fĂ„ se noe temmelig kult đŸ€“

Bakgrunn

For en 7-8 Ă„r siden lagde jeg, og min hyggete kollega Hallvar, et produkt som heter Samtalekort. En liten boks med 25 spĂžrsmĂ„l, som du fint kan ha i lomma, i veska, eller i sekken, sĂ„ du alltid er klar for Ă„ ta en samtale til et nytt nivĂ„. Om du befinner deg i en knipe av en samtale kan du alltids snu det til noe spennende ved Ă„ stille et spĂžrsmĂ„l som f. eks “Kan du huske noe som du syns var skummelt i Ăžyeblikket, men som du er glad du gjorde?”.

Sosialt sett kan det hÞres ut som en rar ting Ä gjÞre, nettopp Ä trekke fram en pakke med kort dersom praten plutselig gÄr trÄtt. SÄ det krever sÄklart litt innpakking. Personlig pleier jeg Ä vinkle det inn pÄ denne mÄten:

Du, nÄ kom jeg pÄ en ting. Det blir vel fort vekk en digresjon, for det har vel egentlig ikke sÄ mye Ä gjÞre med det vi nettopp snakka om, men det hadde vÊrt interessant Ä fÄ din vinkling pÄ det.

For jeg snakka med noen nÄ nylig om erfaringer som virker skumle i Þyeblikket, men som du er glad for at du gjorde, nÄr du ser tilbake pÄ det. Kan du komme pÄ et eller flere sÄnne Þyeblikk for din del?

Digresjon

Om det her er fÞrste gang du hÞrer om samtalekorta er det fullt mulig Ä kjÞpe en pakke samtalekort altsÄ. Bare send meg en mail pÄ strombraaten@gmail.com eller en melding pÄ 99458511 sÄ finner vi ut av frakt og vippsing derfra.

Men! Det var ikke poenget. Jeg skulle snakke om utfordringa med samtalekorta i sin nÄvÊrende form.

Utfordringa

Utfordringa er at nÄr du har vÊrt gjennom de 25 spÞrsmÄla er det ikke like fristende Ä bruke dem igjen og igjen, og igjen. Det er absolutt interessant Ä stille spÞrsmÄla til nye folk, for Ä se hva de ville svart, men etterhvert blir det Þnskelig med noe nytt.

Terskelen er altsÄ hÞy for Ä sette i gang en ny produksjonsrunde, bare for kunne Ä gi ut flere spÞrsmÄl.

Designet kan for all del gjenbrukes, og sÄnn sett er det bare Ä levere nye spÞrsmÄl til trykk, men det stopper jo ikke der. For spÞrsmÄla mÄ puttes inn i esken, og esken i seg sjÞl mÄ brettes og limes, og bestÄr av to ulike deler (som en fyrstikkeske), og knyttes sammen med et klistremerke. Det er altsÄ en omfattende jobb med Ä montere det.

I tillegg til at det er viktig for meg at det ikke ser slurvete ut. NĂ„r jeg fĂžrst gjĂžr noe vil jeg ikke at det skal vĂŠre halvhjerta, men heller “helhjerta”. Det betyr at en ny produksjonsrunde innebĂŠrer ogsĂ„ en kvalitetssjekk av hver eneste pakke, hvor jeg da mĂ„ se etter:

  1. Er klistremerket skeivt plassert pÄ esken? Er det midtstilt?
  2. Er det noen feil i selve trykkjobben? Har blekket “blþdd” noen steder? Har arket blitt “flisete” etter kniven som har avrunda hjþrnene?
  3. Er esken for stram i hylsteret, eller sklir det inn og ut pÄ en Þnskelig mÄte?

BĂ„de trykkinga, og monteringa er noe som kan gjennomfĂžres av andre, men selve kommunikasjonen med de ulike partene, logistikken det medfĂžrer, og ikke minst kvalitetssjekkinga – Ă„ vurdere hva som er godt nok, og ikke – det arbeidet faller i sĂ„ fall pĂ„ meg. Med mindre jeg lĂŠrer opp noen andre til Ă„ stille samme krav som meg. Alt i alt utgjĂžr det en hĂžy terskel for Ă„ oppdatere Samtalekorta med nye spĂžrsmĂ„l.

Da hadde det vĂŠrt lettere med en app som jeg kunne oppdatere med nye spĂžrsmĂ„l i ny og ne. SpĂžrsmĂ„let da er heller – hvordan lager jeg en app?

Hvordan lager jeg en app?

NĂ„r du skal lage en mobil-app havner du umiddelbart pĂ„ spĂžrsmĂ„let – native eller ikke-native? For iOS har sitt “native”-sprĂ„k som heter Swift. Mens Android har Kotlin og Java, som sitt native-sprĂ„k.

NĂ„ er jeg ute pĂ„ tynn is, men nĂ„r vi snakker om at et kodesprĂ„k er “native” for en plattform, betyr det at sprĂ„ket er spesiallagd og stĂžttet direkte av den plattformleverandĂžren det gjelder. SprĂ„k som React Native og Flutter er derimot “plattformuavhengige rammeverk”, som det kalles, som da vil fungere pĂ„ bĂ„de iPhone og Android, men som legger et mellomlag mellom koden din og plattformens native kode. Hvis jeg har forstĂ„tt riktig sĂ„ kan det mellomlaget gĂ„ utover ytelsen og tilgangen til plattformens funksjoner, sammenligna med native kode.

Jeg skal ikke gÄ dypt pÄ forskjellene her, for jeg kan Êrlig talt ikke nok om det. Men underveis hÞrte jeg med noen kollegaer av meg, som alle hadde gode argumenter for hvorfor jeg burde velge det ene eller andre.

Jeg liker sÄklart tanken av Ä slÄ to fluer i en smekk, altsÄ gjÞre appen tilgjengelig for bÄde iPhone- og Android-folk, som man oppnÄr ved Ä skrive det i Flutter eller React Native. Og jeg utforska begge de mulighetene (litt iallefall), men jeg har et veldig tynt kunnskapsgrunnlag Ä bygge videre pÄ. Noen er kjent med React fra tidligere nettside-prosjekter, men for meg virka alt fremmed uansett. Derfor var det en kommentar fra Mikael som festa seg hos meg:

For noen uten veldig mye kodeerfaring tror jeg faktisk Swift UI og verktÞyene som kommer med der er ganske bra. Gitt at en vil fokusere pÄ iOS. Godt sprÄk, dedikerte komponenter som gjÞr at det ser iOS ut med en gang.

Det er godt mulig jeg plutselig endrer kurs, men for Þyeblikket prÞver jeg Ä lÊre meg Swift, som da er Apple sitt native-sprÄk for iPhone.

Fordeler jeg har merka meg

Enn sÄ lenge er det noen fordeler som jeg har merka meg:

  1. Du kan jobbe mer visuelt om du vil, ved Ă„ “drag-and-droppe” inn de ulike elementene du trenger, ogsĂ„ fĂ„r du se koden de er bygd opp av. Som er en litt annerledes tilnĂŠrming for Ă„ lĂŠre seg grammatikken, eller syntaksen til kodesprĂ„ket.
  2. Du har et lett-tilgjengelig bibliotek av elementer, hvor selve dokumentasjonen er bygd inn i programmet du bruker (som en nybegynner for meg er det digg Ä slippe Ä sÞke opp absolutt alt, men Ä heller fÄ det servert i konteksten av selve arbeidet)
  3. Det finnes gode lĂŠringsressurser

Hva skal appen gjĂžre

For Ä forstÄ hva jeg ville oppnÄ har jeg begynt Ä lage noen lister for funksjonaliteten jeg ser for meg.

Funksjonalitet

MĂ„ ha

  • En samling med spĂžrsmĂ„l
  • Mulighet til Ă„ navigere seg fra et spĂžrsmĂ„l til et annet

Vil gjerne ha

  • Offline-tilgang til alle spĂžrsmĂ„lene, uten Ă„ vĂŠre avhengig av internett for Ă„ vise spĂžrsmĂ„lene
  • Hjelp til Ă„ stille gode oppfĂžlgingsspĂžrsmĂ„l, eller introdusere spĂžrsmĂ„let til Ă„ starte med

Kan ha

  • Mulighet til Ă„ lagre/spare pĂ„ de spĂžrsmĂ„lene du liker best?
  • En listevisning over dine favorittspĂžrsmĂ„l?
  • En intro-skjerm til Samtalekort?
  • Dele spĂžrsmĂ„l med andre?
  • Aktivere offline/flymodus som et eget “samtalemodus”? Trigge en snarvei som setter pĂ„ ikke-forstyrr?
  • Lys og mĂžrk modus

SpÞrsmÄl jeg har

Lagring av data

I hvor stor grad trenger jeg Ä tenke pÄ databaser? Og mÄ det vÊre eksternt, eller kan spÞrsmÄlene lagres lokalt pÄ telefonen til sluttbrukeren, som en del av appen man laster ned?

Hvis jeg kun skal lagre spÞrsmÄl, altsÄ bare tekst, er det egentlig behov for Ä sette meg inn i hvordan jeg knytter det til en database? Jeg kjenner sÄvidt til Firebase og Supabase, men det Þker jo fort kompleksiteten hvis jeg mÄ dykke ned i det der og.

Omfanget av arbeidet

Hvordan kan jeg snevre inn omfanget for Ä gjÞre det lettest mulig for meg sjÞl? Sagt pÄ en annen mÄte: Hva slags funksjonalitet burde jeg vente med for Ä ikke gjÞre det unÞdvendig komplekst til Ä starte med?

Offline

Offline-fokuset er viktig for meg. Nettopp fordi den fysiske og taktile egenskap med korta flytter oppmerksomheten din vekk fra telefonen. Vekk fra alle distraksjoner som kan dukke opp.

Om du skal kunne lese spÞrsmÄla pÄ telefonen burde jeg ogsÄ legge til rette for Ä unngÄ distraksjoner, sÄ langt det lar seg gjÞre.

SpÞrsmÄlet mitt da handler egentlig om hvorfor trenger en app tilgang til internett i det hele tatt? Hva slags handlinger er det som krever det?

Spotify f. Eks er avhengig av Ä laste inn sanger som ikke er lokalt lagra pÄ din telefon. Notat-appen din derimot har sannsynligvis lagra notatene dine lokalt, men synkroniserer det med skyen (og sÞrger dermed for at du har en backup) nÄr du er pÄ nett igjen.

Men er det noe spesielt man mÄ tenke over, nÄr man vil tilrettelegge for en app som funker vel sÄ bra uten tilgang til internett som med?

NĂ„r du fĂžrst har lasta ned en app (fra app store) sĂ„ vil den vel “by default” vĂŠre tilgjengelig offline. Derimot sĂ„ antar jeg at det kan bli behov for Ă„ sikkerhetskopiere valgene man har tatt. Som f. eks hvis du har lagra dine favorittspĂžrsmĂ„l. Da er jo det informasjon som lagres i appen, men for Ă„ sĂžrge for at du ikke mister din liste, i tilfelle noe skulle skje, sĂ„ bĂžr man kanskje lagre en backup i skyen?

Begrensninger

Jeg har lyst til Ä bruke dette som en mÄte Ä lÊre meg mer om bÊrekraftig app-utvikling, og hva det kan vÊre. Derfor vil jeg legge noen begrensninger pÄ meg sjÞl, som f. eks:

  • PrĂžve Ă„ unngĂ„ bruk av bilder eller film, for Ă„ redusere den totale filstĂžrrelsen
    • Dette kan pĂ„virke behovet for ikoner i grensesnittet, sĂ„ jeg mĂ„ vurdere hvor kantete jeg skal vĂŠre her
  • Fokusere hovedsakelig pĂ„ tekst og grafikk som “produseres” gjennom koden
  • Offline-tilgjengeligheten vil nok ogsĂ„ vĂŠre en begrensning, men det kan hende det blir et framtidig mĂ„l, avhengig av hva jeg finner ut om arbeidsmengde for Ă„ fĂ„ det til pĂ„ en god mĂ„te

En liten start

NĂ„r du holder korta i handa blir det fort en liten “vifte”, hvor flere kort ligger over hverandre. En mulig tilnĂŠrming er Ă„ gjenskape det digitalt, sĂ„nn at jeg kan spille videre pĂ„ en naturlig mĂ„te Ă„ bytte kort pĂ„. Nettopp ved Ă„ bruke scrolle-bevegelsen med tommelen for Ă„ flytte det Ăžverste kortet bakerst i bunken.

NĂ„ skal det sies at ulempa med Ă„ vise en kladd fra Figma er at det fort ser laaangt mer “ferdig” ut enn det egentlig er. SĂ„ du fĂ„r ta det her med en solid klype salt.

Riktignok sĂ„ tror jeg at jeg skulle klart Ă„ gjenskape designet i Swift nĂ„, fra et visuelt stĂ„sted, men jeg har ikke lĂŠrt meg nok ennĂ„ til Ă„ vite hvordan jeg navigerer fra ett skjermbilde til et annet 😅

Dette er en av flere tilnĂŠrminger jeg kunne tenke meg Ă„ utforske.

Interaksjonen

Tanken er at du kan trykke pĂ„ et kort for Ă„ fĂ„ opp den “detaljerte visninga”, som ogsĂ„ kan gi merverdi (sammenligna med de fysiske korta) i form av oppfĂžlgingsspĂžrsmĂ„l, i tillegg til hjelp med Ă„ introdusere spĂžrsmĂ„let. Om du vil teste en enkel prototype av det kan du sjekke ut den linken her, som da Ă„pner Figma i nettleseren din.

Interaksjonen med kortstokken kunne i teorien vért noe a’la det Anton Kosarchyn har lagd her:

Alternativt kunne jeg gjort noe mer Tinder-lignende, som dette eksempelet fra Sam Atmore:

Tilbake til virkeligheten

NĂ„ drĂžmmer jeg sĂ„klart. FĂžrst vil jeg se om jeg kan lĂŠre meg det som trengs for Ă„ fĂ„ den grunnleggende “mĂ„ ha”-funksjonaliteten pĂ„ plass.

Om det var noen av spĂžrsmĂ„lene ovenfor som du kan hjelpe meg med Ă„ forstĂ„ bedre sĂ„ hadde jeg satt veldig pris pĂ„ en forklaring. Alt det her er nytt for meg, sĂ„ alle rĂ„d tas i mot med takk og digitale high-fives 👋

Bonus

LĂŠringsressurser for Ă„ lage iPhone-apper

  1. E-bĂžkene til Mark Moeykens som viser skjermbilder av koden, med forklaringer og illustrasjoner av alt du trenger Ă„ vite er gull verdt!
  2. Kursene til Chris Ching (Code with Chris) er pedagogisk lagt opp, og forbausende lett Ä fÞlge med pÄ, selv for nybegynnere

Andre notater som linker tilbake hit

  • Fant ingen notater som linker tilbake

Notatkart