I denne artikkelen skriver vi om vår fiktive venn og designkonsulent Oskar, som har vært i et tverrfaglig team i rett under et år. Hvordan går det egentlig med Oskar nå – og kan vi hjelpe ham?

Før vi forteller historien til Oskar, må vi forklare noen begreper og komme med visse antagelser:

Kanban er japansk og betyr “kort” eller “tegn/signal”. Begrepet ble først tatt i bruk av Toyota på 70-tallet for å minimere produksjonskostnader og å ha bedre styring på oppgaver og arbeidsmengde. Det er enkelt og greit et kø-system. I dag brukes det flittig i utvikling av IT-løsninger, og kalles som kjært barn med mange navn: kanban, board, tavle eller lignende.

For at denne artikkelen skal gi mening må vi også komme med antagelsene om at dere som vil få mest ut av den sitter i et tverrfaglig team, jobber etter kanban-prinsippet, har en tavle og har kort vei fra idé til produksjon.

Så, til historien om Oskar og hagen

I denne artikkelen skriver vi om vår fiktive venn og designkonsulent Oskar, som har vært i et tverrfaglig team i rett under et år. Teamet til Oskar er en produkt-trio med utviklere, designer og produkteier, slik Teresa Torres definerer det. Oskar har ikke jobbet med, eller lært om kanban-prinsippet før, og oppdraget han sitter på nå er hans første møte med såkalte “boards”, eller tavle.

Oskar har følt en god stund at han ikke hører helt hjemme i Kanban-boardet til teamet han jobber med. Det er vanskelig for ham å sette fingeren på nøyaktig hva det er, men han opplever at det funker mye bedre for utviklerne enn for ham selv. Dette er noe han ikke er alene om, det er mange designere som føler på det samme. Oskar forteller oss at han ikke vet om gresset er grønnere på noen andre tavler, men vi mener at gresset hans er dårlig vannet og kunne hatt godt et par runder med kalk.

Teamets gartner-system

Oskar sitter i et team som startet å lage en ny løsning fra bunnen av. Teamet hans arvet mye innsiktsarbeid, en enorm prototype i Figma og en uhorvelig mengde brukerhistorier og akseptensekrav i Jira (ett av mange kanban-verktøy). I praksis var det i grove trekk bestemt hva han skulle lage før han begynte å jobbe med produktet.

Kanban-tavla til teamet hans er delt i to: upstream og downstream.





I upstream-tavla er det UX, spesifisering og prioritering som dominerer beitene. Oskar trekker lapper fra produktkøen (andre kaller det backlog) inn i UX-kolonnen og gjør sin magi. Når han har laget noen skisser på hvordan ting kan løses legger han lappene inn i grooming-kolonnen. Her skrives akseptensekrav om for å passe slik skissene har blitt. Når lappene har oppdaterte akseptensekrav legges de til prioritering, og deretter over i ferdig spesifisert-kolonnen, som er utviklerne sin produktkø. Teamet har ukentlige prioriteringsmøter der de ser på utviklerne sin produktkø og legger de viktigste lappene øverst i køen.



Downstream-tavla er utviklernes rike. Oskar synes at dette ligner arbeidsprosessen slik han forventer en produkttavle vil se ut. Lapper legges i “in progress” fra den prioriterte produktkøen ”ferdig spesifisert”, trekkes over i QA (Quality Assurance) når det blir en PR (Pull Request, et begrep utviklerne bruker når de vil legge koden sin inn i den felles produktkoden). Etter det beveger det seg gjennom kolonne etter kolonne med ulike testmiljøer, før lappen endelig blir godkjent og trekkes over i “Done”.

Ugress i teamets hage

Oskar merket ganske tidlig at han følte seg isolert fra resten av teamet på grunn av kanbantavla. Han gjør design-oppgaver i ux-kolonnen på upstream-tavla, produkteier gjør spesifisering av lappene i de andre kolonnene på upstream-tavla, mens utviklerne tar lappene gjennom downstream-tavla. Oskar sitter altså i et team som ikke fungerer slik det skal siden ingen egentlig jobber “sammen”. Teammedlemmene samarbeider, men det er sjeldent at de jobber sammen med samme oppgave, samtidig. 



Vi vil skjerme utviklerne for spesifiseringen av lappene.



Oskar mistenker at han kanskje er den eneste som tydelig merker at tavla stritter litt imot ham. Han er den eneste som jobber på tvers av begge tavlene. Utviklerne på teamet synes at det er deilig å ha downstream-tavla for seg selv, for da slipper de å ta stilling til hva som skal lages og hvorfor. Produkteier har også alt hen aktivt trenger å ta stilling til i upstream-tavla, før lappene legges i downstream-tavla. Ingen andre i produkt-trioen legger merke til at samarbeidet fungerer dårlig siden de andre gruppene har sitt eget arbeid så tilrettelagt for å gjøres uten input fra noen i de andre rollene.

De grønne fingrene jobber ikke smidig

Oskar har også merket at det er gnisninger mellom hvordan han og teamet naturlig ønsker å jobbe, og hvordan tavla legger opp til at de skal jobbe. Både Oskar og utviklerne har en drøm om å jobbe med frontend sammen, en slags par-design der de sammen kommer frem til den beste løsningen. Dessverre har dette bare skjedd to-tre ganger siden teamet begynte å jobbe sammen for snart ett år siden. De gangene Oskar og utviklerne har par-designet noe så har han alltid måtte lage skisser på hva de kom frem til etter at utviklerne implementerte det. Dette skjer fordi tavla deres krever at skisser fra Figma legges i en lapp innen den går til “in progress”-kolonnen. Oskar og utviklerne skulle gjerne ha jobbet smidigere sammen, men da gir tavla dem et etterslep av arbeid som ikke tilfører noen verdi.

På samme måte som å lage skisser på ting som allerede er implementert, bruker teamet unødvendig mye tid på å skrive ned akseptensekrav på hvordan produktet skal fungere. Når Oskar prater med utviklerne om hvordan de kan dekke et behov i produktet, baserer han skissene på det. Etter at Oskar har “levert” skissene sine, skriver produkteier og testleder ned masse detaljerte akseptensekrav om hvordan produktet skal fungere. Oskar har stilt spørsmålstegn ved verdien av dette tidligere, men har fått vite av produkteieren at hen vil ha det for dokumentasjonens skyld. Oskar har ikke all verdens erfaring med å jobbe smidig, men han tenker instinktivt at slik det gjøres nå medfører veldig mye dobbeltarbeid. Han tenker at funksjonaliteten bør komme frem i skissene og gjennom samarbeid i produkttrioen. Akkurat nå jobber teamet som om fasit på hvordan produktet skal se ut og fungere ligger i Jira, ikke i produksjon.

Hva skjer når problemene rotfester seg?

Oskar har merket at han ikke egentlig vet så godt hva utviklerne driver med når teamet har sine daglige stand-up’er. Når man har hver sin tavle så tenker man ikke så mye på hva som skjer på den andre tavla. Han har ikke så godt forhold til hva som implementeres og sendes ut i produksjon akkurat nå, mens utviklerne ikke vet så godt hvilke nye muligheter han utforsker. Dette har ført til at Oskar stadig vekk finner ting i produksjon som ser helt annerledes ut enn slik han lagde det i skissene. Da må han mase på utviklerne om at det er feil og at det må rettes opp i, noe han synes er slitsomt. Oskar har heller ikke lyst til å være en masete person, derfor godtar han noen ganger at ting har blitt litt annerledes enn hva han la opp til i skissene.

For Oskar er det et dyptstikkende problem at han ikke har kontroll på hvordan det endelige produktet ser ut og virker: det undergraver hans rolle som designer. Han synes ikke at han må ha kontroll fordi han vil bestemme, men fordi han har et annet perspektiv og en annen faglig kompetanse enn utviklerne som, i hans team, tar siste avgjørelse på hvordan det som settes i produksjon ser ut.

Når det gjelder stand-up’en selv så føler Oskar at det ikke fungerer slik det skal heller. På de daglige møtene går teamet gjennom kanban-tavla, men Oskar opplever det som at hvert teammedlem sier hva de skal gjøre den dagen. Oskar er veldig enig i det Linda Halvorsen skriver i sin artikkel: “boardet handler om produktet vi lager, ikke om teammedlemmenes arbeid”, noe resten av teamet også er enige i. Allikevel så føler han at de ikke helt får det til i praksis. Oskar tror at dette skyldes den dårlige kommunikasjonen som tavlen legger opp til. Siden ingen på teamet vet hva de andre driver med, blir de mer opptatt av hva de selv gjør. Teamet har forsøkt å bryte ut av denne vanen før, men til ingen nytte. Før de vet ordet av det så er de tilbake til å snakke om hva hver og en driver med, i stedet for å snakke om utviklingen til produktet. Teamet til Oskar opplevde at det tok for mye tid å skulle sette alle andre i teamet inn i hva lappen handler om før de snakker om hva statusen på den er.

Finn frem lukespaden

Hva kan Oskar gjøre for å forbedre prosessen til teamet sitt? Her kommer våre tips:

Samle alt på ett board

Det aller første Oskar burde foreslå som endring er å samle alle kolonnene på én tavle. Husk at forutsetningene for å jobbe godt i team, er å tilpasse verktøyet til hvordan teamet vil jobbe, ikke omvendt. Da vil alle i teamet få en bedre oversikt over hvilke deler av produktet som jobbes med og hva de endringene er. Dersom det blir for mange kolonner i tavlen kan teamet dele tavla opp, men da med hensikt om å være produktkø/backlog, som eksemplifisert under. I tavla under ser du også “temaer”, som er ment som en “foreldre/barn”-relasjon (initiativ, “epic”) som kan si noe om fokusområdet for teamet for en gitt periode.





Siden teamet skal jobbe sammen, bør tavla også vise nettopp det. Det betyr at teamet bør kvitte seg med å ha en egen “UX-kolonne” som kun Oskar bruker. Alt arbeid i tavla representerer arbeid med produktet som lages. Alle lappene og oppgavene som skal gjøres er derfor gruppa sitt felles ansvar å få gjort, uavhengig av fagdisiplin. Mange oppgaver er også tverrfaglige, og da må det ikke være et unaturlig skille i tavla på dette.

Alle bør forstå alt

Et tips for å få alle i teamet på samme side, er å beskrive oppgavene som brukerhistorier. Dette tvinger alle i teamet til å formulere en oppgave slik at alle forstår den, også Oskar som er designer. Designer skal ha like stor forståelse for hvorfor noe prioriteres over noe annet i produktet, og det gjør du ikke med mindre oppgavene er beskrevet på en forståelig måte. I tillegg kan en annen fagdisiplin ha svært nyttige bidrag til løsningen som man ellers ikke nødvendigvis ville fått. Alle tekniske oppgaver kan forklares ved bruk av normalt språk – det har bare ikke vært tradisjon for å gjøre det.

som …bruker/den med behovet… 

ønsker jeg at ...[en konkret implementasjon som skal gjøres]… 

slik at …behov blir oppfylt eller oppgaven til bruker kan gjennomføres…

Produksjon er verdien

Produksjon er ikke bare det vi har laget til nå; det er den verdien vi har skapt, eller forsøker å skape, for brukerne. Det er ikke sikkert det løser riktig behov, men det er det nærmeste forsøket dere har gjort til å realisere verdien. Hvis teamet samles om en felles forståelse for hva som tilfører verdi til brukerne og hva som ikke gjør det, vil det spare Oskar og teamet hans for unødvendig arbeid. Samtidig som det vil gjøre det enklere å jobbe sammen på en mulig løsning, fordi alle blir opptatt av hvilken verdi man oppnår, ikke antallet oppgaver eller størrelsen på løsningen.

Ingenting skal ut i produksjon før teamet er enige

Teamet bør sette klare rutiner for “review”, eller kvalitetssjekk om du vil. Oskar føler at han mister kontrollen på hva som havner i produksjon, mye på grunn av sin rolle som designer. Han har ikke mulighet til å hverken forstå eller påvirke kvaliteten på det som går ut i produksjon hvis han ikke blir involvert. Teamet bør etablere en praksis om at ingen oppgaver som påvirker brukeropplevelsen eller tjenesten utad skal ut i produksjon før Oskar har blitt involvert. Dette er ikke fordi Oskar er sjefen, men han er like mye ansvarlig for verdien som dyttes ut i produksjon. En fantastisk bieffekt er at det forsikrer teamet for store misforståelser og unødvendig opprydding, og den tverrfaglige kompetansen blir benyttet i alle ledd. Det bygger også et bedre team, for folk føler seg involvert. Oskar er jo tross alt der for å sørge for en god og helhetlig brukeropplevelse.

Standup finnes av en grunn.

Standup er en enkel øvelse som har en enkel hensikt: å synliggjøre produktets tilstand for hele teamet. Vi repeterer det Linda Halvorsen sier: “boardet handler om produktet vi lager, ikke om teammedlemmenes arbeid”. Det er ikke alltid teamet trenger eller kan jobbe tett sammen på en oppgave, så daglig standup sørger for å holde teamet samlet rundt ansvar, retning og produksjonsdrift. Teamet bør strebe etter å ha standup (på et eller annet format) hver dag, og så hopper man over oppgaver det ikke har skjedd noe med. Det viktigste er at teamet har oversikt over produktet og hvilken verdi det leverer.



Å jobbe i hagen

Det går ikke an å skrive en slik artikkel og å gi slike tips uten å nevne at det finnes ingen perfekt oppskrift på hvordan et team skal jobbe smidig sammen. Da hadde det ikke vært noe behov for å skrive dette. Dessverre er ingen team, prosesser eller oppskrifter perfekte. Den beste måten et team kan jobbe sammen på avhenger av teammedlemmene, domenet og rammene de jobber med, og produktet de lager sammen. Derfor er det viktigste rådet vi kan gi Oskar og alle dere som leser dette: jobb kontinuerlig med deres egen hage, og finn ugress som kan lukes vekk eller blomster som må vannes.



🌻

En tavle til å bli forKANBANnet av

React server components vinner popularitet og det er avgjørende for komponentbiblioteker å støtte det for å holde tritt. Hvordan støtter du det?

React server components vinner popularitet for deres ytelsesforbedringer, og det er avgjørende for komponentbiblioteker å holde tritt for å forbli aktuelle.

Men her står vi overfor et paradoks: til tross for viktigheten, er det lite veiledning å finne. Selv i Reacts egen dokumentasjon, er omtalen av hvordan biblioteker kan støtte serverkomponenter diskret plassert som et listet punkt under en vilkårlig seksjon. I denne guiden vil jeg lose deg gjennom prosessen i å transformere et eksisterende komponentbibliotek til å også støtte klient- og serverkomponenter.

KRÆSJ

Jeg ble møtt av denne feilmeldingen da jeg skulle importere en Heading fra komponentbiblioteket mitt inn på hjemmesiden min.

Dette syns jeg var overraskende. Heading-komponenten var jo en enkel komponent uten noe klientkode, så det burde slettes ikke være noe klaging på klientkode som kjører på serveren.

Hva har gått galt?

Hva er egentlig problemet?

Resten av komponentbiblioteket ser slik ut: en enkel Heading-komponent, som brukt over. Og en Button som bruker useState, altså en klientkomponent. Derfor har jeg markert Button-filen med “use client”-direktivet, for å sikre at komponenten behandles som en klientkomponent.

Det ser da bra ut, det?

Heading-komponenten trenger ikke “use client”-direktivet, siden det er en serverkomponent. Og om jeg bruker Button, bør det behandles som en klientkomponent, og ikke forårsake noen ubehagelig feilmelding.

Selv med disse tiltakene, er det to årsaker til at feilen fortsatt oppstår:

Den første årsaken er at klientkode kjører på serveren. Det er kanskje overraskende, ettersom på hjemmesiden importerer vi kun serverkomponenten Heading. Den overraskende realiteten er at Heading er i samme chunk som Button, og hele chunken vil prøve å bli kjørt.

Normalt sett hadde ikke det vært noe problem at også Button kjører, siden Button er markert å kjøre på klienten.

Men så kommer vi til andre årsak til feilen, som er hvordan bundlere håndterer koden. De flytter ofte import-setninger til toppen, som kan skyve “use client”-direktivet nedover i filen. Dette direktivet må være øverst for at komponenten skal anerkjennes som klient-spesifikk. Feilplassering fører til at både klient- og serverkomponenter kjøres på serveren, noe som fører til kræsj.

Løsningen

Vi har dermed to årsaker til feilen:

én chunk fører til at klient- og serverkomponenter kjøres på samme sted, og

bundleren flytter på “use client”-direktivet, som fører til feil kategorisering av type komponent.

Løsningen til dette er å splitte opp klient- og serverkomponenter i hver sin chunk. Og å flytte “use client”-direktivet til toppen av filen.

Splitte opp chunken

Ved å splitte opp bundelen er vi sikre på at riktig chunk kjører i riktig miljø. Så vi går fra å ha én index.ts hvor vi importerer alle filer, til å splitte opp importeringen i clientComponents.ts og serverComponents.ts.

Vi må også si ifra til bundleren at vi nå går fra å ha én entry til å ha to. Jeg brukte Vite/Rollup som bundler, men tilsvarende config finnes også i andre bundlere:

Vi må også oppdatere exports i package.json, så konsumere av pakken kan importere komponenter fra riktig entry:



Vi har nå splittet opp kompontenene i ulike chunks, men dette krever en justering for å støtte riktig eksportering av typer.

Sidespor om TypeScript

TypeScript genererer en egen typefil for hver chunk: clientComponents.d.ts og serverComponents.d.ts. Ettersom "types" i package.json kun støtter å referere til én typefil, må vi løse typer for chunkene på en annen måte.

Løsningen er å benytte typesVersions. Feltets intensjon er å sette ulike type-definisjoner avhengig av TypeScript-versjon, men vi kan også bruke det til å peke på hvor man finner type-filen avhengig av modul: 

Vi har splittet opp chunkene og justert typene. Som konsumer av pakken, kan jeg nå importere fra rett filsti for å unngå å bli overfalt av en feilmelding:

MEN vi har bare løst halvparten av problemet. Bruker du en knapp fra clientComponents vil siden kræsje. Vi trenger fortsatt å fikse “use client”-direktivet.

Legg direktivet i toppen av filen

For å legge til “use client”-direktivet i toppen av en fil kan vi bruke et verktøy som er tilgjengelig i mange bundlere: banner.

Banner er ofte brukt til å skrive info om lisens for koden, men vil i vårt tilfelle brukes til å legge “use client”-direktivet på toppen av chunken. Faktisk er det dette komponentbiblioteket Chakra UI bruker for å markere sine komponenter som klientkomponenter.

Vi trenger da å oppdatere bundler-configen. Vi legger til “use client”-direktivet kun for clientComponents-chunken:



Nå kan vi også bruke Button-komponenten uten verken et ekstra “use client”-direktiv eller at siden kræsjer.

Konklusjon

Vi har nå løst to hovedutfordringer for å støtte React Server Components i et bibliotek. Først oppdaget vi hvordan vi kan dele opp komponenter i separate chunks for klient og server, så vi kjører riktig kode i riktig miljø. For det andre, lærte vi hvordan bruken av “banner”-verktøyet i bundlere kan sikre at “use client”-direktivet forblir øverst i filen, som er kritisk for at det oppfører seg som forventet. Ved å følge disse trinnene, kan også du ta i bruk React Server Components for bedre ytelse.

Slik lager du et bibliotek som støtter React Server Components

React server components is winning popularity, and it's crucial for component libraries to support it to stay relevant. How do you support it?

React server components is winning popularity for its performance enhancements, and it's crucial for compont libraries to support it to stay relevant.

But here's the paradox: despite its importante, there's little guidance to find. Even in React's documentation, the information is hidden discretely in an arbitrary section. Here I will guide you through the process in transforming an existing component library into one which supports client- and server components.

CRASH

This is what met me when importing a Heading from my component library onto my own page.

This was surprising to me. The Heading-component was a simple component with no client code, so it certainly shouldn't be nagging about client code running on the server.

What has gone wrong?

What exactly is the problem?

The rest of the component library looks like this: a simple Heading-component, as mentioned about. There's also a Button which uses useState, thus a client component. That's why I've marked the Button-file with the "use client"-directive, to ensure the component is treated as a client component.

This looks all right, doesn't it?

The Heading-component does not need the "use client"-directive, as it is a server component. And if I'm using Button, it should it treated as a client component, and not cause an unpleasant error message.

Regardless of these steps, there are two reasons the error still occurs:

The first reason is that client code is running on the server. It is perhaps surprising, as on the home page we are only importing the server component Heading. The surprising reality is that Heading is in the same chunk as Button, and the whole chunk will try to be run. 

Normally, there would have been no problem for Button to also run, since Button is marked to run on the client. 

But then we come to the second cause of the error, which is how bundlers handle the code. They often move import statements to the top, which can push the "use client" directive down in the file. This directive must be at the top for the component to be recognized as client-specific. Improper placement causes both client and server components to run on the server, leading to crashes.

The solution

Thus we have two causes to the error:

one single chunk causes client and server components to run in the same location, and

the bundler moves the "use client"-directive, which wrongly categorizes the component

The solution to this is to split client and server components into separate chunks. And to move the "use client" directive to the top of the file.

Split the chunk

By splitting up the bundle, we are sure that the right chunk runs in the right environment. So we go from having one index.ts, where we import all files, to splitting the import into clientComponents.ts and serverComponents.ts.

We also have to tell the bundler that we are going from one entry to having two entries. I used Vite/Rollup as a bundler, but equivalent configs exist in other bundlers as well:

We also have to update exports in package.json, so consumers can import the components from the correct entry:

We have now split the components into different chunks, but this requires an adjustment to support the correct export of types.

Note about TypeScript

TypeScript generates a separate type file for each chunk: clientComponents.d.ts  and serverComponents.d.ts. As package.json only supports referencing one type file, we have to solve types for the chunks in another way.

The solution is to use typesVersions. The field's intension is to set differet type files for different TypeScript versions. But we can also use it to point where to find the type file for a specific module:

We have now split up the chunks and adjusted the types. As a consumer of the package, I can now import from the correct file path to avoid being assaulted by an error message:

But we have only solved half the problem. If you use a button from clientComponents, the page will crash. We still need to fix the "use client" directive.

Put the directive at the top

To add the "use client" directive at the top of a file, we can use a tool available in many bundlers: banner.

Banners are often used to write about lisencing, but will in our case be used to add the "use client" directive at the top of the chunk. This is the same method the popular component library Chakra UI uses to mark its components as client components. 

Here we update our bundle config. We only add the "use client" directive to the clientComponents-chunk:

Nå kan vi også bruke Button-komponenten uten verken et ekstra “use client”-direktiv eller at siden kræsjer.

Now we can use the Button component without either an additional "use client" directive or the page crashing.

Conclusion

We have now solved two main challenges to support React Server Components in a library. First, we discovered how to split components into separate chunks for client and server, so we run the right code in the right environment. Second, we learned how using the "banner" tool in bundlers can ensure that the "use client" directive remains at the top of the file, which is critical for it to behave as expected. By following these steps, you can use React Server Components for better performance.

How to support React Server Components in your library

Oneshot er smarttelefonens digitale engangskamera, utviklet for å møte kostnads- og miljøutfordringene assosiert med tradisjonelle engangskameraer. Slik har veien med utviklingen av min app, fra behov til produkt, vært.



Spenningen rundt venteprosessen, en fascinasjon for retro-uttrykket og ta vare på fysiske minner, er noen av grunnene fotobutikkene oppgir som årsak for den populære engangskamera-trenden. Appen jeg har laget, kalt Oneshot, er engangskameraet du alltid har i lomma. Bildene kan du ikke se før et album er fylt opp, med kun ett forsøk på hvert bilde. Fotoalbum kan deles med venner og fysiske kopier kan bestilles.


Problemet med dagens engangskamera er at det er dyrt å fremkalle, lite miljøvennlig og utilgjengelig. Kameraene kastes gjerne etter bruk og noen fotobutikker sender kameraene til utlandet for bildefremkalling. Dette ønsket jeg å gjøre noe med!



Slik Kom Ideen 💡

I løpet av studietiden merket jeg at jeg gjentatte ganger fotograferte de samme motivene for å få det perfekte bildet. Dette endret seg da jeg begynte å bruke polaroide- og engangskameraer. Jeg ble fascinert av ideen om å ta et bilde for så å legge kameraet til side. Mitt fokus skiftet fra å jakte på det perfekte bildet til å heller fange det unike øyeblikket. Det å ta bilder som jeg ikke kunne se før fremkalling var alltid like spennende. Dette resulterte ofte i overraskelser over bilder jeg hadde glemt at jeg tok. Å dele disse øyeblikkene med andre var en glede, og de utvalgte printede bildene ble en integrert del av leilighetens veggdekor.



Men jeg innså at hobbyen min med engangskameraer ble kostbar, med utgifter over 3000 kr for kameraer og fremkalling. Som student i Datateknologi ved NTNU, fant jeg inspirasjon til å utvikle en løsning. Dermed ble appen "Oneshot" til. Navnet speiler appens essens, at hver bruker har kun én sjanse til å ta hvert bilde. Det er historien bak hvert bilde som teller, ikke nødvendigvis det perfekte utseendet. Dette reflekterer engangskameraets sjarm, og viser at skjønnhet ofte ligger i det uperfekte.

Løsningen 📱

Gjennom Spark og Aneobidraget, en støtteordning for entreprenørskap blant studenter, fikk jeg innvilget økonomisk støtte for en printer, masse kvalitets printerpapir, og en Adobe Lightroom lisens for å skape det ultimate retrofilteret. Bildet under er fra min pitch til Aneo.



Oneshot er en app for å ta bilder som hjelper deg å tenke mer over hva du tar bilder av. I likhet med et engangskamera kan du ikke se bildene dine før en forhåndsbestemt albumstørrelse er nådd, noe som gjør at hvert bilde blir mer spesielt. Med appen kan du søke etter og legge til venner, og når vennskapet er etablert, kan man utforske hverandres album. Appen tilbyr å jobbe med flere album samtidig som "Roadtrip" og "Sommer". Mens et tradisjonelt engangskamera med fremkalling og digital kopi koster rundt 482 kr, tilbyr Oneshot et 25-bilders album for kun 69 kr – syv ganger billigere! Bestiller du et album, mottar du bildene i en pakkeløsning inklusiv en remse skoletyggis for enkel opphenging.


Den tekniske løsningen 💻

Applikasjonen er utviklet i React Native Expo og Expo Application Services med Firebase Firestore for lagring av data. Det er utnyttet flere tjenester fra Firebase som Cloud Functions, Remote Config, Crashlytics, Analytics, Hosting, Authentication og Storage.


Oneshot ble utviklet i React Native Expo, ved hjelp av Expo Application Services (EAS). Expo fungerer som et omfattende rammeverk for React Native-applikasjoner, tilbyr verktøy og tjenester for rask oppstarts- og utviklingsprosessen uten krav om manuell konfigurasjon av native kode. Det inneholder også en rekke innebygde APIer og komponenter. EAS forbedrer utviklingsopplevelsen ved å tilby skybaserte tjenester for effektiv bygging, distribusjon og oppdatering av applikasjoner. En stor fordel med EAS er muligheten til å skape og integrere egne native moduler, en funksjon som tidligere ikke var tilgjengelig i Expo på grunn av deres begrensning til forhåndsdefinerte APIer og moduler. Som en nyutdannet utvikler fant jeg at den omfattende konfigurasjonen var en utfordring, noe som ledet meg til å velge Expo. Dette valget angrer jeg ikke på, takket være den omfattende dokumentasjonen og et aktivt community med godt utviklede komponenter fra Expo-teamet. Med integreringen av EAS har jeg også oppnådd betydelig fleksibilitet, noe som har tillatt meg å utvide applikasjonen med komplekse native moduler.



Applikasjonen bruker dokumentdatabasen Firebase Firestore for lagring av data, sammen med en rekke andre Firebase-tjenester som Cloud Functions, Remote Config, Crashlytics, Analytics, Hosting, Authentication, og Storage. Valget om en serverløs applikasjon førte meg til Firebase-økosystemet for å komme raskt igang, men lite visste jeg at dette skulle vise seg å bli en bjørnetjeneste. Nå som det er utviklet et fullverdig sosialt nettverk med massevis av relasjoner ser jeg nå at det kaaaaaanskje hadde vært greit med en relasjonsdatabase 🙃 I tillegg har jeg erfart at Firestore og Firebase generelt har ganske høye priser. Dette krever økonomisk kodeutvikling som minimerer antall CRUD-operasjoner for å holde kostnadene nede.


Planen videre 🌼

Til nå har Oneshot vært populær blant venner og deres nettverk. Jeg er spent på å se om flere ønsker en rimeligere og mer tilgjengelig løsning enn tradisjonelle engangskameraer. Jeg har ikke noen kunnskap om markedsføring så om du leser dette og har noen tips til hvordan hadde jeg satt utrolig stor pris på om du sendte meg en melding! På den tekniske fronten ser jeg for meg å automatisere printeprosessen. Slik at hver gang en bestilling kommer inn, vil den automatisk bli printet og sendt ut. 

Ditt Digitale Engangskamera

Designdrypp er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!

Hvem er jeg?

Navn: Kristin Håberg

Alder: 26 år

Fra: Asker

Studerte Industriell Design på NTNU i Trondheim

Jobbet som designer i 1,5 år




Det var egentlig litt tilfeldig at jeg ble interaksjonsdesigner. Jeg kommer fra en realfagsfamilie, med leger og ingeniører. For meg var tannlege og veterinær de to tingene jeg tenkte jeg skulle bli. Selv om disse yrkene høres ganske annerledes ut enn interaksjonsdesign, så tror jeg at det til slutt handler om det samme. Det som interesserte meg ved både tannlege og veterinær var at man måtte bryne seg på komplekse problemer for å komme frem til riktig løsning for å hjelpe andre. Og det er jo det jeg liker best ved rollen min som interaksjonsdesiger. At jeg må dykke ned i problemer for å løse noe som har en verdi for andre enn meg selv.






Hva gjør jeg?

Du har kanskje fått med deg at Viken skal splittes opp igjen i år? Det skal Troms og Finnmark, Vestfold og Telemark, og Ålesund kommune også. Disse endringene skjer ikke av seg selv, og teamet mitt jobber med nettopp dette; å dele fylker og kommuner i Norge. Det er skikkelig motiverende å jobbe med noe som er så viktig!



Vi jobber med å lage den tekniske løsningen som brukes for å gjennomføre årets (og fremtidens) fylkes- og kommuneendringer. Når det skjer fylkes- og kommuneendringer er det nødvendig å gjøre mange millioner endringer på eiendomsdata. Teamet mitt har da jobbet med å utvikle den tekniske løsningen for å faktisk endre dataen, men vi har også jobbet med å lage et verktøy som fagpersoner skal bruke for å sikre at disse endringene blir riktig. Samtidig har vi også ansvar for å tilby data til de mange eksterne som trenger å forberede egne systemer for endringene.


I teamet mitt innebærer rollen som designer mye. Jeg har måttet bruke designmetodikk og verktøy på en annen måte enn jeg kanskje trodde da jeg begynte. Teamet mitt jobber med et veldig komplekst domene. Det krever mye, kontinuerlig, innsiktsarbeid, både for å forstå hva det er vi egentlig skal lage, og hvordan vi burde lage det. Vi må ta hensyn til at vi berører flere ulike brukergrupper. Den ene gruppen av brukere er fagpersoner som trenger et forståelig og brukervennlig ekspert-verktøy for å sikre at kommuner og fylker endres på riktig måte. Den andre gruppen er brukerne av dataen vi leverer. En stor del av arbeidet er å prioritere behovene hos de ulike- samtidig som vi utvikler en helt ny teknisk løsning som skal levere til en satt frist. Det krever en god prosess og samarbeid med alle involverte. Dagene mine går mye i workshops, fasilitering av møter, fasilitere prosess i teamet, sette gode mål, samle innsikt fra fagpersoner, og kartlegging av behov hos mange ulike eksterne.





Hvilket tips ville jeg gitt meg selv i starten av oppdraget/karrieren?

Alltid still spørsmål- og gjerne vær den som stiller de “dumme spørsmålene". Domenet jeg jobber i er utrolig komplekst og sammensatt, og mange ulike personer med ulike perspektiver og behov er involvert i prosessen. Det betyr mange møter og samtaler for å finne ut hva som må gjøres for å løse problemet. I disse møtene har jeg lært at det alltid lønner seg å stille de “dumme spørsmålene”. Det er ikke forventet å kunne alt- og selv om jeg har sittet hos Kartverket i over et år er det fortsatt utrolig mye jeg ikke kan. Still heller det samme spørsmålet én gang for mye, ofte er det faktisk flere enn meg som lurer på det samme.





Hva eller hvem inspirerer deg?

Jeg blir skikkelig inspirert av folk som klarer å ikke bare forstå komplekse problemer selv, men også gjøre dem forståelige for alle rundt seg. Jeg jobber med mange folk som er skikkelig gode på dette, og det synes jeg er veldig inspirerende- og jeg prøver å lære så mye som mulig av dem!




Designdrypp med: Kristin Håberg

"Hva burde vi lage nå?" Dette er alltid et viktig spørsmål i et produktteam. Opportunity Solution Tree (OST) er en nyttig teknikk for å svare på dette spørsmålet, og den hjelper oss å systematisk utforske teamets løsningsrom.

Hvilken OST er dette?

Opportunity Solution Tree ble popularisert av Teresa Torres som et verktøy for å hjelpe produktteam å finne de beste løsningene for de mest verdifulle mulighetene eller problemene som ligger foran dem. Metoden gjør det enklere å unngå vanlige fallgruver som å hoppe til løsninger for tidlig (byggefella), bruke for lang tid på analyse før eksperimentering (analysefella), eller å bruke for mye tid på å løse feil problem. 


Hvordan skal vi finne det mest verdifulle som teamet kan bidra med nå?



OST er én måte å gjøre dette på, og metoden består av fire hovedkomponenter:

Ambisjon - start med å definere et klart og konkret mål. Dette gir retning for resten av prosessen.

Muligheter eller Problemer (Opportunities) - identifiser en rekke muligheter, problemer eller brukerbehov som kan hjelpe deg å nå målet. Dette trinnet krever forståelse for domenet og brukerne, gjerne fra allerede skaffet innsikt.

Løsninger (Solutions) - generer ulike løsningsideer for hver identifisert mulighet.

Eksperimenter - finn eksperimenter som lar oss teste løsningen for å verifisere at den faktisk fungerer i virkeligheten. Dette blir typisk utviklingsoppgaver.

Disse elementene settes sammen i et tre, og teamet velger den stien i treet de til enhver tid har mest tro på. Eksperimentene utvikles og testes i produksjon. Gir eksperimentene ønsket effekt, fantastisk! Vi er ett steg nærmere suksess. Hvis ikke, prøv et nytt eksperiment. Fortsett slik til ambisjonen er nådd eller tålmodigheten tar slutt.

Praktisk gjennomføring

La oss gå gjennom hvordan OST kan benyttes i et produktteam. Vi antar at teamet er tverrfaglig, i det minste har kompetanse både på utvikling og design, har et produkt som kan endres i produksjon, og at effekter av produktet kan måles (kvalitativt eller aller helst kvantitativt).

Ambisjon

Første steg er at teamet og organisasjonen er enige om en ambisjon. Ambisjonen er effekten vi ønsker fra det vi lager. Dette kan være forretningsverdi (verdi for organisasjonen), brukerverdi (brukerne får brukt produktet til noe nyttig) eller helst begge deler samtidig. Ambisjoner kan selvfølgelig være svært ulike fra sted til sted, men tradisjonelt har vi tre forskjellige arketyper av ambisjoner:


Læringsambisjoner - når vi tar fatt på noe nytt og ikke vet nøyaktig hva vi burde oppnå eller hva som er realistisk.

Hypotesedrevne Ambisjoner - når vi vet godt hva vi ønsker å oppnå, men er usikre på veien dit.

Milepælsambisjoner - når vi vet godt hva vi ønsker å oppnå, og vi har en god idé om hva som må til for å nå den ambisjonen.

Hvilken type ambisjon som gir mening for teamet, kommer an på graden av forståelse og modenheten til teamet og organisasjonen. Milepælsambisjoner passer for godt utforskede problemstillinger, læringsambisjoner når vi er usikre. Hypotesedrevne ambisjoner passer oftest.

Ambisjonen vi velger kan komme fra en eksisterende målstyringsprosess, for eksempel en ambisjon eller en nøkkelindikator fra OKR, men den må uansett ha visse egenskaper:

Den gir mening alene, skaper fokus og gjør det lettere å si nei.

Den har potensialet til å være viktig og levere verdi.

Teamet kan påvirke utfallet av ambisjonen.

Særlig det siste punktet er viktig. Team som har ambisjoner uten å kunne påvirke dem, har dårlige rammevilkår for å kunne lykkes.

Muligheter / problemer og løsninger

Nå er det på tide med minst én workshop med hele teamet og andre interessenter med dyp domenekunnskap. Her er ingen ideer feil; målet er å få opp mange forslag til muligheter og problemer først, deretter løsningsidéer. Teamets tverrfaglighet skal skinne, og alle teamets medlemmer må bidra med sin kompetanse og fantasi.

Miro eller en annen digital tavle er fint for å dokumentere det teamet kommer fram til, men en analog sesjon med post-its er også en klassiker. Bare husk at workshop-deltagerne må føle seg trygge på at deres bidrag blir tatt med videre. Glemte lapper på workshop-gulvet har lav verdi.

Her skal løsningsrommet utforskes, og kunsten er å faktisk tørre å gå dit de gode forslagene er. Glem backloggen, tenk ut av boksen og vær kreativ. Utvelgelse og realitetsorientering kommer etterpå.

Eksperimenter

Dette er det siste steget før faktiske endringer i produktet. Det kan gjennomføres i samme workshop som nevnt over, eller i en egen sesjon. Som før er det grønn sone, men dette steget er hakket vanskeligere: eksperimentene skal faktisk gjennomføres, og resultatene av dem må være målbare (eller i alle fall objektive nok til at vi kan si om de lyktes eller ikke).

Eksperimenter er faktiske endringer i produktet som, hvis de er presise og gjennomføres med suksess, vil muliggjøre løsningen og dermed redusere et problem eller realisere en mulighet på veien mot ambisjonen.

Finn den gyldne sti

Alle punktene settes sammen til et tre, og utvelgelsen kan begynne!

Vi velger én sti å utforske først. Første steg er lett, ambisjonen står allerede fast. Så velger vi én mulighet/problem, én av dets løsninger og ett eksperiment som kan validere løsningen.

Dette valgte eksperimentet er det første teamet skal jobbe med.

Utvelgelsen kan være vanskelig og bør baseres på hele teamets ekspertise. Et produktteam er dog ikke et demokrati, så ikke nødvendigvis la dot-voting eller andre konsensusprosesser bestemme det endelige valget. En god produkt- eller teamleder sørger for at de forskjellige fagfeltene i teamet bidrar med sitt, og sikrer at valget tas basert på kunnskap og faglig intuisjon, og ikke minst, raskt!

For å kunne velge det rette eksperimentet å starte med, er det lurt å vurdere gjennomførbarheten. Kan vi gjennomføre dette eksperimentet med en gang, eller er det noe som hindrer oss? Jo raskere eksperimenter kan verifiseres i produksjon, jo større er muligheten for å lykkes med å skape verdi.

Oppsummering

Opportunity Solution Tree er en kraftig metode for produktteam som ønsker å ta informerte beslutninger basert på brukerinnsikt og data. Den hjelper team å fokusere på de mest verdifulle mulighetene og samtidig verifisere løsninger effektivt og systematisk. Ved å integrere OST med andre metoder som OKR, kan vi sikre at vi både setter de riktige målene og finner de beste måtene å oppnå dem på. Metoden øker synligheten av kompleksiteten i domenet rundt teamet, og gjør det enklere å både kommunisere med organisasjonen og å faktisk levere reell verdi i den virkelige verden.

Prøv OST før jul

Use your keyboard and this three step program to tame some noise using the Rust programming language.

Let’s make some noise with Rust! Yes, literal noise. Whats more poetic than starting this journey with the audio to the source of life caressing your eardrums: streams! (google translate “bekk” to discover a coincidence). We will attempt to take some control and tame the noise with keyboard input, using some digital audio signal processing. Disclaimer: This is written by a Rust beginner, and may not apply all best practices.

📢 Friendly advice: Although the software presented here is safe for your ears. I will still recommend as a precaution to not use headphones/earphones (or at least always start low volume) when playing with audio in programming. I speak from experience as I vividly remember almost tearing up some eardrums 10 years ago. I was testing out the Csound programming language while cluelessly choosing numbers for scaling the output volume. In shock I almost punched myself in my face, as I lunged toward the headphones pounding damaging amplitudes of sine waves into my brain. Lesson learned; speakers that don’t go directly into your ear are safer.

Given that you have already installed the rust toolchain. Let’s start by creating the project, we may call it “noisy”.

cargo new noisy

Part 1: Output some noise from speaker

To handle playing sound from your computer we will use the cpal crate (Cross-Platform I/O Audio Library). And to simplify our way around creating (synthesizing) the noise, we utilize another powerful crate: fundsp. «FunDSP is an audio DSP (digital signal processing) library for audio processing and synthesis.» - this seems promising! Run cargo add fundsp cpal. (dasp (formerly sample) also seems to be a popular crate for audio signal processing, and may be more fitting should you need a more lightweight alternative with focus on separation of concern)

We start by setting up the stream for audio playback in main() and generate some pink noise in the run()function, that we pass on to the write_data() function. write_data() writes the audio - sample by sample - to the output stream.

Run this with cargo run and you should hear some beautiful noise from your speakers.




Part 2: Utilize keyboard input

Noise by itself may become boring after some time. Let’s take some control with the keyboard. We add the crossterm crate to parse keyboard input: cargo add crossterm. The raw mode lets the program read each character as it is typed by the user. We register this in the main function. Secondly, we create a loop in the run() function that listens for keyboard input. For this step pressing any button will play the sound, pressing escape will quit the program. We simulate playing while holding down a button by registering a tone_duration. You may change this variable to your own preference.

Try running this and pressing buttons — this should give you some more control of the wild noise.




Part 3: Make noise pretty

Alright! Now that we have some keyboard events to hook into, let’s take advantage of it. There are a couple of things added here, so let’s break it down. Firstly, we replace the pink noise with an Oscillator (borrowed from the cpal examples) to be able to dynamically change the frequencies. The oscillator generates square waves, from a given frequency. Secondly, we create our own little piano on the keyboard. Registering the keys from A-L to represent an octave from C to C (the tone). Check out the code below.




Congrats! 🎉 Now you have created your very own monophonic synthesizer (monophonic → able to play one note at a time)! Have a look at the fundsp examples for more inspiration to play around with digital signal processing. With future endeavours one could for example simplify the audio generation in this example even more by utilizing more of the tools from the mentioned crates.

Make some noise with Rust!

Løs sjakkoppgaver på Advent of Chess hver dag i advent, og få muligheten til å vinne et sjakkbrett signert av Magnus Carlsen!

Hva er Advent of Chess?

Mitt hobbyprosjekt er enda en julekalender! I Advent of Chess (med et navn sterkt inspirert av Advent of Code) får man én sjakkoppgave hver dag frem til julaften. Som i Advent of Code har man ett døgn på å løse hver oppgave, der løsningen blir publisert når det stenges for besvarelser. Jeg lager kalenderen for Offerspill sjakklubb, og vi kan derfor tilby et sjakkbrett signert av Magnus Carlsen som premie, der hver løste oppgave gir ett lodd i trekningen.

Bak hver luke gjemmer det seg ganske vanskelige sjakkoppgaver, men ingen vanlige sjakkoppgaver der man skal finne beste trekk. Dette for å unngå at man skal kunne jukse ved å bruke en sjakkmotor. Noen oppgaver er selvlagde, noen er nøye utvalgte fra gamle sjakkblader, og flere brukere har sendt inn forslag til sjakkoppgaver de har komponert selv (det høres kanskje pretensiøst ut, men man komponerer sjakkomposisjoner!). Til eksempel så er gårsdagens oppgave fra mars-utgaven av British Chess Magazine fra 1913!



Teknologi

Første versjon av kalenderen oppsto da jeg var med i Bekks kodehjørnet-faggruppe i 2020, en faggruppe der man jobber med egne hobbyprosjekter. Denne versjonen ble lagd som en en kjapp MVP med en React-frontend, Sanity for lagring av oppgavene, og Google Sheets (!) som database for å lagre besvarelser! Dette var ikke en veldig skalerbar løsning, men det funket i starten.

I år bestemte jeg meg for å skrive om nettsiden fra bunnen av. Dette var ikke bare for å forbedre brukeropplevelsen, men også for å tilrettelegge for en rekke funksjoner som skulle gjøre administrering av nettsiden, spesielt håndtering av besvarelser, enklere. Jeg forkastet den gamle kodebasen, og starte et nytt Remix-prosjekt med Tailwind til styling, SQLite med LiteFS som database, hostet på Fly. Kun Sanity ble beholdt. Oppgraderingen viste seg å være helt nødvendig, for antall brukere økte betydelig i år! Her følger et par av funksjonene som ble nødvendig å implementere med økningen i antall brukere.



Automatisk retting av svar

Tidligere måtte alle svarene, som er i fritekst og på ulike formater, rettes manuelt. Dette er en tidkrevende jobb, men det har gått fint tidligere. I år har derimot antall brukere, og dermed også besvarelser, økt såpass at jeg innså rundt 2. desember at jeg måtte få på plass automatisk retting av besvarelser, slik at jeg unngår å bruke hver kveld frem til julaften på manuell retting!

Løsningen ble å sjekke alle innsendte svar mot et regulært uttrykk (regex) som prøver å gjenkjenne riktige svar. Hver oppgave har forskjellige svar, så dette håndteres ved å lagre det regulære uttrykket sammen med oppgaven i Sanity. Dersom den ikke klarer å automatisk verifisere at besvarelsen er korrekt, sendes den til manuell retting. Det skjer heldigvis ikke så ofte lenger – mer enn 90% av svarene sendt inn i går ble rettet automatisk!

Mulighet for å sende inn svar på ny

Kalenderen tillater bare ett svar per oppgave. Dersom det første svaret man sender inn er feil, får man ikke gjort noe med det. Dette har også fungert greit tidligere år, men et annet problem som oppstod med økningen i antall brukere, er at det skal veldig lite til for at én bruker feiltolker en detalj i oppgaveformuleringen, og derfor sender inn feil svar på grunn av det. Jeg trengte en måte å nullstille feil svar dersom det skyldtes at jeg hadde formulert oppgaven unøyaktig. Jeg implementerte derfor muligheten for å nullstille en besvarelse, samtidig som det sendes ut en e-post til brukeren om at formuleringen er endret og de kan prøve på ny.


Det var også flere brukere som spurte om de kunne endre besvarelsen mens den hadde status PENDING, altså mens den venter på manuell retting. Dette fikk jeg også nylig på plass, noe som har hjulpet på å få ned antall henvendelser.



Stjerne til de 10 første!

Alle nye funksjoner har ikke strengt tatt vært nødvendige. Jeg vet for eksempel ikke hvor lurt det var å gi de 10 første som løser hver oppgave en stjerne ved siden av brukernavnet sitt på ledertavlen. Etter dette ble implementert, har det ikke tatt mer enn rundt 4 minutter for topp 10-listen å fylles hver dag, og rundt 200 brukere ser ut til å holde seg våkne til midnatt for å ta fatt på den nye oppgaven med en gang den blir publisert.







Status

Til nå i år har Advent of Chess hatt over 25,000 unike besøkende, 76,000 sidevisninger, 1920 registrerte brukere, og 8167 innsendte besvarelser. Vi i Offerspill sjakklubb opprettet en Discord-kanal for å ta i mot tilbakemeldinger, og der har det vært fullt kjør hele desember.

Og det er selvfølgelig ikke for sent å delta. Lag deg en konto på Advent of Chess og prøv deg på dagens oppgave, så kan du være med i trekningen av et sjakkbrett signert av Magnus Carlsen!

19-Dec

Today's posts