Etter innføringen av GDPR satt EU seg i førersetet for regulering av digitale rettigheter knyttet til personopplysningen. Nå kommer en ny forordning som tar sikte på å gjøre det samme innen bruk av kunstig intelligens.

Fredag 8.desember tok EU ett nytt viktig steg i prosessen med å formelt vedta den etter hvert mye diskuterte EU Artificial Intelligence Act, gjerne omtalt som EU AI Act. 

Forordningen ble påbegynt allerede i 2021, i god tid før verden for alvor fikk øynene opp for AI/LLM, og tar mål om å innføre en rekke regler som vil ivareta borgernes rettigheter og verdier i møtet med en stadig økende bruk av kunstig intelligens. Ikke ulikt hvordan EU sørget for innføringen av GDPR, men da med bruken av personopplysninger. 

Man kan trygt si at 2023 har vært banebrytende med tanke på å bringe kunstig intelligens fra forskningsmiljøene og inn i et hvert styrerom og ledergruppe i omtrent hele verden. Fra å være noe alle kjente til, men ikke selv benyttet, har banebrytende løsninger som ChatGPT, DALL-E, Midjourney og nå senest Gemini fra Google, banet veien for at kunstig intelligens nå er på alles lepper.

Med denne enorme fremveksten av kunstig intelligens er det lett å se for seg scenarier eller bruksområder hvor løsningene kan brukes til å skape uante, eller bevisste, løsninger som ikke hensyntar våre verdier eller rettigheter.

Hva innebærer den nye forordningen?

Denne artikkelen går ikke i dybden på hele forordningen, men i likhet med GDPR vil også den nye forordningen innføre strenge bøter dersom man bryter reglene, og det legges opp til flere nye krav til dokumentering og rapportering. Et sentralt punkt er risikovurdering og klassifisering av den enkelte tjeneste eller løsning.

Avhengig av hvor stor risiko bruken utgjør vil man måtte oppfylle en rekke krav innenfor fire ulike nivåer definert av EU, som vist i figuren under.



Nedenfor forklares nivåene kort, men det anbefales å lese gjennom EUs egne eksempler og tekst for utfyllende eksempler og forklaring. Teksten er enn så lenge kun på engelsk.

Uakseptabel risiko

Slike systemer vil ikke være tillatt under den nye forordningen. Ett eksempel EU selv trekker frem her er sosial scoring av innbyggere fra deres egne myndigheter eller leker med stemmeassistanse som oppmuntrer til farlig oppførsel

Høy risiko

Dette kan være løsninger som blant annet omfatter kritisk infrastruktur (transport), AI for CV-sortering, kredittscoring for å innvilge lån etc (se EUs egen liste for utfyllende eksempler). Løsninger definert med høy risiko vil være underlagt strenge forpliktelser før de kan selges eller brukes i markedet.

Eksempler er:

Tilstrekkelige risikovurderinger

Høy kvalitet på datasettene som benyttes

Logging for å skape sporbarhet i avgjørelser

Detaljert dokumentasjon

Begrenset risiko

Applikasjoner og løsninger med begrenset risiko vil måtte informere om dette slik at man som bruker selv vet at man interagerer med kunstig intelligens. Ett åpenbart eksempel her er chatbots

Minimal risiko

Forordningen legger opp til fri bruk av løsninger som defineres innen denne kategorien, eksempelet som trekkes frem her er spam filtre med kunstig intelligens. Som EU skriver selv «The vast majority of AI systems currently used in the EU fall into this category.»

Hva skjer videre?

Digitaliseringsdirektoratet skriver at det enda er uklart når forordningen vil vedtas, men straks den vedtas vil den bli gjeldende for EU-land to år etter vedtakstidspunktet. 

Selv om det potensielt er en stund til forordningen trer i kraft bør selskaper og organisasjoner som benytter seg av kunstig intelligens allerede nå starte kartleggingen av de nye reglene.

Som ved andre av EUs nye regelverk har det vært heftig debatt mellom flere av EUs medlemsland underveis og det blir spennende å følge forordningen videre.

Verdens første regulering av kunstig intelligens

Have you ever felt frustrated managing the state of your application? Common challenges include unnecessary re-renders,  prop-drilling, or a lot of boilerplate to manage even simple states. Jotai provides an elegant and simple solution to a lot of these challenges, building a easy, boilerplate-free and global state using atoms. 

Why jotai?

Jotai has only been around since 2021, but is already seing a lot of traction. It is simple, light-weight, and integrates nicely with React state and other frameworks, making it very flexible. The use of TypeScript syntax is an added bonus. 

Best of all is that the state is global and easily accessed and updated, and a component will only re-render when a state it subscribes to is updated. This is huge compared to React context, which will re-render every component that subscribes to it. 

Readers familiar with Recoil will see some similarities with the use of atoms. However, as Recoil has slowed its development (only one release in the past year) and still does not have a stable release, Jotai is preferable to use with its continuous development and community support. 

State management with Jotai is of particular advantage with client heavy projects, shared state across sibling components, and where re-renders are expensive. In the following sections, I will go through some of the most common functionality I have used so far, but check out the documentation for a more comprehensive overview. 

Getting startet

To install, simply add Jotai to you project. 

Primitive atoms

Jotai uses atoms with a bottom-up approach to build state. Primitive atoms are the simplest type, and can store any data you like (eg numbers, string, objects, arrays), much like Reacts useState. 

To create an atom, simply create a variable to be an atom with a default value. Types can be added if wanted. 

To give an example, lets say we want to build a site where users can evaluate different books. First, we would create an atom with a default value. Then, to use the atom, we can simply import it directly into a component with useAtom. This hook can now be used in the same way as for useState, except the atom can be accessed from any component you want. 

There are three different options for accessing an atom in a component:

Atom with storage

If you  need to store a state in LocalStorage, Jotai will provide an easy option using atomWithStorage. Provide a unique key and a default value to initialise the atom. If the value exists in storage, it will be returned, and if not, the default value will be provided. Every time an atomWithStorage is updated, the value is automatically updated in the local storage as well.

Atom with reset

Sometimes a state needs to be reset to the default value. In some cases it is simple enough to apply useSetValue and reset the default, however, for larger objects it would be preferable to use atomWithReset. Lets say our book site has some filter categories that can be selected, with an option to reset all choices. 

The atom can be reset to default in two ways; either with useResetAtom, or the standard setting function with RESET as the value. 



Derived atoms

Derived atoms can be used to get and/or set other atoms, with the options of altering or combining their values. Examples can be filtering a state based on some criteria, calculating the length of an array, changing casing of a string, or applying a discount to a price. 

Derived atoms have a read and write option, either of which can be null if not needed. A derived atoms cannot read or write to itself, but only from/to other atoms. 

Read-only atom

For our book site, lets say we  want to only show the books with a good score. A derived atom can do this for you, by adding a filter to the booksAtom: 

In the same way, a derived atom (lets call it filteredBooksAtom) can combine the bookFiltersAtom with the booksAtom to only return books with the selected filters. The advantage is that each time either atom is updated, the filteredBooksAtom will also update its value, and all the components reading it will be reloaded.  

Read and write atom

Read and write atom can be used to set one or several other atoms. Examples include resetting several atoms to their default at the same time, or setting a discount to a price atom. It is also possible to set timeouts. For our book site, we might want to give some holiday cheer every time a button is clicked (eg for adding a new book). A user would then receive a message that would disappear after a specified or default time. 



This sums up some of the main uses of Jotai. Checkout the documentation for further uses, and enjoy an easier way of managing your state! 

Jotai: Build Your State with Atom Precision

Det er lett å blande mellom kontrollerte og ukontrollerte komponenter i React, men hva er egentlig forskjellen og hvilken burde man bruke?

Har du noen gang opplevd å få denne meldingen?

Warning: A component is changing an uncontrolled input to be controlled. This is likely caused by the value changing from undefined to a defined value, which should not happen.

Da er du ikke alene. React har nemlig to forskjellige måter å håndtere tilstand i skjemaelementer og det er lett å plutselig ta i bruk begge uten å være klar over det. Så hva er forskjellen?



Controlled

En kontrollert komponent er når du selv håndterer tilstanden til komponenten i React ved bruk av for eksempel useState. På denne måten har man selv kontroll på hvor og hvordan man velger å lagre tilstanden og hva man vil gjøre med den etterpå. Det er denne måten React selv anbefaller at man håndterer tilstand på skjemaelemeneter.

Så når man skal lagre verdien senere er det bare å sende med state videre.

Ønsker man å ha en en startverdi på en kontrollert komponent er det altså bare å sette denne som verdien av value.



Fordelen med kontrollerte komponenter er at man har full kontroll på dataflyt og det er lett å bearbeide data, reagere på endringer og validere underveis. Ulempen kan være at det blir mye mer kode og tilstandshåndtering som skal til når man har mange skjemaelementer.



Uncontrolled

Når en komponent ikke er kontrollert betyr det at vi etterlater tilstandshåndteringern til den faktiske DOM-en, utenfor React og dens Virtual DOM.

For å hente verdien av skjemaelementet da må vi koble oss på selve DOM-elementet under React sin kopi. Dette gjør man med å lage en referanse som man sender til komponentet med ref.  Når man skal lagre verdien senere er det bare å hente nåværende verdi gjennom referansen vi har laget

Man skal altså ikke sende inn value inn til en ukontrollert komponent  for da blir den kontrollert. Hvis man ønsker å ha en startverdi kan man gjøre dette ved bruk av defaultValue.

Siden referanser peker på verdier utenfor Virtual DOM-en så reagerer ikke React på endringer i referanseverdien og komponenter vil ikke re-rendre. Det betyr for eksempel at en useEffect vil ikke utløses av en endring i referanseverdien selv om du har den som en avhengighet.

Fordelen med ukontrollerte komponenter er at man slipper å håndtere mange tilstander hvis man har mange skjemaelementer. Ulempen derimot er at man mister muligheten til å bearbeide, validere og reagere på verdiendringer som på mange måter er en av React sine styrker.

Alternativt kan man også forbipassere React helt ved hjelp av en <form>. Da trenger man heller ikke sende referanser inn til skjemaelementene og verdiene sendes videre som en helt vanlig HTML form-submit.



A component is changing

Så hvordan får man meldingen jeg skrev innledningsvis? Den får man hvis man endrer en komponent fra ukontrollert til kontrollert. Dette kan skje av mange grunner, men den vanligste er kanskje at man ikke har noen startverdi på komponenten.

Da vil komponenten være ukontrollert ved første render siden verdien er undefined, men så fort man har endret på verdien og value får en verdi så endres komponenten fra en ukontrollert til en kontrollert komponent.

En annen vanlig feil som er lett å gjøre er å sende med defaultValue selv om komponenten er kontrollert. Da vil man få denne meldingen

Warning: Controlled contains an input of type undefined with both value and defaultValue props. Input elements must be either controlled or uncontrolled (specify either the value prop, or the defaultValue prop, but not both).

Det er altså lett å gjøre feil, og det er heller ingen stor fare. Det er derfor dette er markert som en advarsel og ikke som en feil. Det gjelder bare å ha tunga rett i munn og være konsekvent på hvilken form av tilstandshåndtering man vil ha.

Ta kontroll på skjemaelementet!

I sommer lanserte Bekk ny visuell identitet. På mange måter representerer profilen et brudd med 23 års historie. Eller: Den representerer et skifte. Rett nok uten å kvitte oss med røttene, men profilen peker mer framover enn tilbake.

Det er en tid for alt. Og av og til er forandring et poeng i seg selv. Og selv om Bekk er et selskap som er i kontinuerlig endring, og profilen utvikles i takt med endringene, er det fra tid til annen behov for å ta større grep. Sist vi gjorde en større endring var i 2018. På vei ut av pandemien var det igjen riktig å gjøre nye grep.

Til grunn for oppdraget lå problemstillinger ut over det rent visuelle. Det var et mål å kommunisere tydeligere hva vi gjør. Det var også et mål å gi tjenesteområdet for forretningsrådgivning, Bekk Management Consulting, en tydelig posisjon som ett av to brede tjenesteområder i Bekk. Ikke minst var det et mål å utfordre selskapets logo – et navnetrekk og symbol som har stått mer eller mindre uendret siden oppstarten av Bekk våren 2000.

Første uttak: bekk.no

Vi la til grunn for arbeidet at bekk.no skulle være første uttak. Vi lot nettsidene være et slags origo, et startpunkt for ny profil, og at erfaringene vi gjorde her ble tatt inn i arbeidet med andre andre uttak og flater.

Målet med nettsidene var å vekte «marked» og kunder noe tyngre enn i tidligere versjoner av bekk.no, hvor nettsidene nesten alene var rettet mot rekruttering. Med andre ord, litt mer fokus på tjenester, erfaring og fag enn selskapskultur.



Grunnelementene

I arbeidet med konseptutviklingen av Bekk sin visuelle profil var det viktig for oss å ikke glemme hvor Bekk kommer fra, og hva som er og har vært identiteten vår i alle år. Navnet Bekk spiller på vann. Det handler om det organiske, en kraft som vokser, tilpasser og endrer seg. Vi kaller oss selv «bekkere», og uttrykket «Mange bekker små» har gått i gangene helt siden starten. Og det med god grunn. Det viser til at våre bidrag i fellesskap blir til noe stort og viktig, og at det vi får til sammen gir størst kraft.

Disse grunnleggende tankene som har fulgt Bekk sin identitet gjennom historien, ble selve kjernen for konseptutviklingen av den nye profilen. Ideen om å utforske de andre grunnelementene, i tillegg til vann, ble ganske tidlig etablert som fundament for vår nye identitet.

Ild, jord og luft sammen med vann skaper en helhet og et uendelig mulighetsrom. Det ene elementet påvirker det andre, og når de settes sammen skapes det nye og fantastiske ting. På samme måte som vi skaper utrolige ting i et fellesskap, gjør de fire elementene det også. I alle elementene ligger det et spekter av ulike teksturer, farger og kompleksitet. Rett og slett masse å ta av for inspirasjon til å skape en fleksibel identitet som representerer oss.



En naturlig palett

Den tidligere fargepaletten til Bekk inkluderte en variasjon av kraftige og kontrastfylte farger som har fungert godt i diverse kontekster, men fargene klarte aldri å innta en tydelig rolle i den overordnede visuelle identiteten da de ikke ble brukt konsekvent.

Et av målene for den nye profilen var derfor å skape en palett der farger får en mer fremtredende plass, slik at de blir sentrale og identitetsskapende elementer i Bekk sin merkevare.

I arbeidet med Bekk sin identitet var det som nevnt viktig å bevare historien og kulturen vår, også i utviklingen av fargeprofilen. Vi har beholdt kontrasten mellom det lyse og det mørke, som har vært et kjennetegn ved merkevaren til Bekk i mange år, beveget oss mot et lysere uttrykk generelt for å ikke oppfattes så strenge og mystiske som vi tidvis har gjort. 

Når det gjelder fargetonene, ønsket vi å dra paletten i retning mot det naturlige slik at fargene representerer de fire elementene på en balansert og tiltalende måte. I Bekk verdsetter vi mangfold og de mange kontrastene som skaper liv i miljøet vårt. Dette er grunnlaget for en fargepalett med tydelig kontrast mellom det varme og det kalde, der fargene i sin helhet fungerer godt i lag og utfyller hverandre.

De kalde tonene

Digital produktutvikling er kjernevirksomheten i Bekk. De kalde tonene i fargepaletten, inspirert av vann og jord som handler om å bruke følelser og sanseinntrykk til å forstå og skape noe, representerer derfor hovedtyngden i Bekk; teknologi, design og ledelse.

De varme tonene

I motsetning til vann og jord, har vi ild og luft som handler om intuisjon, analytiske evner og et pågangsmot med høy energi. Derfor er det naturlig at de varme fargene representerer den mer strategiske delen av selskapet, Bekk Management Consulting.

En liten dose rebell

For å gi fargepaletten en ekstra dimensjon, la vi til en sterk aksentfarge som representerer den rebelske og energiske personligheten til oss bekkere. Rebellfargen er et uttrykk for at bekkere ikke redde for å utfordre det etablerte, og har et fagmiljø med mye kok og bråk som engasjerer folk.



En strammere typografi

Når det gjelder typografien i den visuelle identiteten, søkte vi et uttrykk som kunne stramme opp og sette litt rammer til den ellers organiske profilen. Typografien skulle også svare på stikkord som tidløs og moderne og fremstå som seriøs, men med et glimt i øyet.

Fra før bestod identiteten til Bekk av to komplementære typesnitt (FF Din & Newzald). Dette var utfordrende å bruke og resulterte i et fragmentert uttrykk. Intensjonen var derfor å finne én font, men med et bredt mulighetsrom.

Etter en omfattende runde med inspirasjon og innsikt, utarbeidet vi en bruttoliste på 6-7 ulike fonter som vi testet mot hverandre. Majoriteten av valgene falt på typiske Swiss-inspirerte fonter der vi vurderte lesbarhet, kontrast og særegenhet som sentrale kriterier. Noen fonter hadde utfordringer på mindre flater, mens andre hadde færre vekter og varianter å spille på. 

GT America

Valget falt til slutt på GT America laget av GrilliType – en allsidig font som kombinerer gotisk amerikansk og europeisk grotesk stil.

Med hele 84 stiler, fordelt på 7 vekter og 6 ulike snitt, måtte vi gjøre et grovutvalg på hvilke stiler som skulle være sentrale for Bekk sin identitet. Typesnittet som dominerer i det nye uttrykket til Bekk er Standard-snittet. Vi bruker også Expanded-varianten som et kontrasterende uttrykk til det vanlige typesnittet slik at vi kan gi enkelte elementer mer slagkraft og tillate oss å ta mer plass.

Tilpasninger for særegenhet

Vi gjorde en rekke modifiseringer av fonten for å få det riktige uttrykket for Bekk sin identitet. Fonten kommer blant annet med både kvadratiske og sirkulære detaljer på tegn og bokstaver. Vi bestemte oss for å bruke den sirkulære tilnærmingen for å få et mykere uttrykk. Fonten har også noen alternative bokstaver, hvor vi gikk for den groteske varianten som er mer Swiss-inspirert og åpen, spesielt på mindre skjermstørrelser, sammenlignet med den gotiske varianten som er mer lukket.



Hva med logoen?

Med ny fargepalett og typografi var de mest sentrale elementene i Bekk sin nye visuelle profil satt. Likevel gjenstod et viktig element som fortsatt var urørt: Bekk-logoen.

Bekk sin logo har stått stødig gjennom alle år og har holdt seg mer eller mindre uforandret, nettopp fordi den har den har fått så god posisjon i markedet. Likevel har den vært gjenstand for diskusjon hver eneste gang det har blitt gjort et løft på profilen. Og denne gangen, hvor vi gjorde en ganske omfattende rebranding av profilen på flere plan, var det tydelig at logoen også måtte tilpasses for å reflektere den nye identiteten til Bekk og fremstå relevant i dagens marked.



De ulike retningene

I arbeidet med ulike logoretninger, ble den nye typografien i profilen et naturlig utgangspunkt.

Den første retningen bygget på tankene og verdiene i den opprinnelige logoen, men tilpasset det nye konseptet og grunnelementet vann. I denne retningen ble bokstavene i logoen påvirket av vannets bevegelse og transformert på samme måte som vannoverflaten påvirker objekter som ligger under. Til tross for at denne logoretningen stod godt til konseptet, klarte vi aldri å finne en form som fungerte godt som en logo.

Med de konseptuelle tankene rundt vann, bevegelse og påvirkning oppstod en ny idé: hva om ordet «Bekk» ikke ble påvirket av vannet, men faktisk var vannet og kilden til påvirkning? I denne retningen tok vi bort all kluss med bokstavformene, og forenklet uttrykket til ren typografi der bruken av bokstavene definerer formen.

Den første skissen til det nye logokonseptet.



Et dynamisk logokonsept

Med utgangspunkt i den andre logoretningen, ble det skisset utallige versjoner av ‘Bekk’ strømmende nedover i to, tre, fire eller fem linjer. Vi testet mange ulike varianter, og fikk en idé om at dette kunne transformeres til andre ord. Teknologi, for eksempel. Når de første testene av dette ble laget, falt brikkene på plass. Her var det noe. Og det var det. Det gikk fra å være en enkel logo til et helt konsept.

Vi trengte likevel et tydelig logomerke, og bestemte oss for å begrense oss til en variant på tre eller fire linjer. Etter å ha utforsket utallige kombinasjoner av dette, innførte vi noen retningslinjer for å forenkle prosessen for utvelgelse. 

Med bakgrunn i flere møter og gode diskusjoner med ledergruppen, landet vi til slutt på en variant på tre linjer for å få et tydelig logomerke som ikke ser ut som grafikk. For å sikre at logoen kunne transformeres til andre ord, valgte vi å plassere hovedlogoen visuelt lenger unna dette uttrykket. I tillegg så blir det mindre elementer å dekode når det er færre visuelle punkter å forholde seg til. Den er enklere å huske, med andre ord.

Det unike ved dette logokonseptet er fleksibiliteten som ligger i det. Hvordan logoen tar form, flyter nedover og tilpasser seg. Akkurat som vannet. Logoen representerer et levende og organisk selskap som kontinuerlig tilpasser seg omgivelsene, men også påvirker dem.

Det er en tid for alt. Og denne gangen var det behov for større grep av fornyelse i Bekk sin identitet. Den nye profilen til Bekk er langt ifra ferdig: den er i sin spede begynnelse. Dynamisk og i kontinuerlig utvikling, akkurat slik vi liker å jobbe.

En stor takk til alle som har bidratt i arbeidet på hver sin unike måte med brennende engasjement og verdifulle diskusjoner: Jon Sindre, Ingeborg, Robert, Lukas, Marlin, Anders, Erik, Holger, Ole Magnus, Bjørn-Ivar, Mats og Reidar.

I kulissene av Bekk sin nye identitet

The role as software security developer is a relatively new role, and has its origins from Bekk’s security initiative. But how does a software security developer differ from a “regular” software developer?

As a part of Bekk’s security initiative, I have had the pleasure of stepping into the role as a software security developer. Bekk envision the role to fill the gap between traditional software development and hardcore penetration testing/GRC work, and the role is therefore perfect for people who want to work in the intersection between traditional software development and cybersecurity. This does not exclusively involve bringing security into the development process, as it is already done to a very high extent in most teams. A security developer is more of a bridge builder between the security work done at management level and the security work done by the product teams, with the goal of highlighting ownership for the solutions for product teams.

"How does a normal day look like?"

Every day brings a new challenge. In our team, we work with security at the operational, tactical, and strategic levels. The goal is to create a bridge between the security work of developers and the security work of management. In my case, the work has varied from regular backend development, securing APIs with OAuth2/OIDC, and pen-testing other products in the organization. The team’s vision is also that by developing an app for the customer, we build up first-hand experience of which processes can quickly lead to security vulnerabilities. Therefore, my work also involves mitigating these pain points in the development process as well as establishing security best-practices.

"How do you stay up-to-date with all that is happening in security?"

Keeping up with everything is a challenge, as the security space is constantly changing with new vulnerabilities, exploits of zero-days, and other security breaches. The best tip is to participate in a larger community where competence and experiences are shared.

“How did you become a security developer?”

I pursued a master’s degree in information security, and I experience job opportunities as extremes. One either works exclusively in development or exclusively in security, in roles such as penetration tester or within GRC (Governance Risk and Compliance). I chose to become a developer because I like the creative part of the job, but was determined not to let go of security. I was quickly introduced to Bekk’s security initiative, and it was through this that I got the opportunity to step into the role as security developer for one of Bekk’s clients.

“What security tools do you use and in what way does it secure the product you are working with?”

I have had the opportunity to work with several different tools. Earlier this fall, another team member and I conducted a low-key pen-test of another product in the organization. This was done to highlight basic vulnerabilities to the product team and to make pen-testing more tangible for them. The most important tool used here was Burp Suite, a network proxy that allows you to run automated scans, perform manual tests, and gives you access to several handy extensions, e.g. Active Scan++ and Turbo Intruder.
Our team is also developing an internal application that we want to secure. We do this through several different scanning tools such as GitHub’s Dependabot and CodeQL, imagescan with Trivvy, and scanning of running applications through Sysdig. This gives us insight into the attack surface at the various stages from code to running application.
In addition, we have recently used Istio, an open-source service-mesh, to secure our API endpoints at the platform level instead of the application level.
The last, but by far the most valuable tool we use every day is the security community at Bekk. When we get stuck or wonder how similar problems can be solved, there is a sense of assurance in being able to lean on a collective of people who are genuinely interested in security.

Taking my background into consideration, I feel lucky to have gotten the role as a security developer. It allows me to combine two fields that I find exciting and fun. Security may seem scary, but what I experience separates those who work in security from others is whether they let fear scare them or just jump in anyway.

A day in the life of a software security developer

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?

Hanna

24 år gammel

Fra Oslo

Studerte design på Arkitektur- og designhøgskolen i Oslo

Jobbet som designer i snart 5 måneder



Jeg vokste opp i en familie hvor alle jobbet som IT-konsulenter. Allerede som syvåring var jeg lei all teknologi-praten ved middagsbordet. Jeg erklærte tidlig at å ende opp med en jobb som dem var det SISTE jeg ønsket. Tiden min ble heller brukt på dans, drama, tegning og andre kreative hobbyer.

Likevel (kanskje uunngåelig?) skulle teknologiinterressen også dukke opp hos meg. Ved en blanding av tilfeldigheter og noen veloverveide valg, kombinerte jeg teknologien med kreativiteten og endte opp som interaksjonsdesigner. Og til den yngre Hannas fortvilelse: IT-konsulent.





Hva gjør jeg?

Jeg jobber på to prosjekter hos Norsk Gjenvinning. De er ganske forskjellige, noe som gjør jobbhverdagen variert og morsom.

“Engage” er navnet på prosjektet jeg har vært med på fra start. Det er en web-app som har som mål å hjelpe kundene til Norsk Gjenvinning å forstå sin egen avfallsdata. Dette prøver vi å få til ved å gjøre avfallsdata spennende. Make trash great again!

Jeg har vært med på å bygge opp selve konseptet og nå jobber jeg mer på detaljnivå før lansering. Mer konkret driver jeg med datavisualisering, grafer og tabeller. Jeg prøver mitt beste å koke ned store komplekse datasett til små, håndterbare visualiseringer som er forståelige for mannen i gata.

I mitt andre prosjekt jobber jeg med ruteopptimalisering! Her designer jeg verktøyet som kjørelederne i Norsk Gjenvinning bruker for å planlegge, følge opp, navigere og kommunisere med alle søppelbilsjåfører.

Det jeg liker best i dette prosjektet er den tette kontakten jeg har med brukerne, kjørelederne. I praksis designer jeg sammen med dem. Til slutt vil dette produktet bli deres arbeidsplass, noe som gjør det utrolig viktig og givende!


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

Du kan aldri si i fra for tidlig! I løpet av de første månedene på oppdrag har jeg lært viktigheten av å hele tiden kunne gi tilbakemelding. På den måten kan man forbedre måten man driver prosess og jobber sammen. Og jo før man sier i fra, jo fortere kan man forbedre situasjonen.


Hva eller hvem inspirerer deg?

Akkurat nå inspireres jeg veldig av de flinke utviklerne jeg får samarbeide med. Det er kult å se hvordan de takler tekniske problemer og samarbeider for å nå frem til løsninger. I tillegg: at de klarer å holde ut med store tekniske problemer (som virker sykt vanskelige for meg hehe) over lengre tid, imponerer meg!

Designdrypp med: Hanna Sendstad

SwiftUI, Apple's preferred UI toolkit, promises seamless integration across all Apple platforms, including of course iOS and macOS. This article delves into some challenges of using SwiftUI in a cross-platform context and suggests practical ideas for solutions.

SwiftUI’s declarative syntax enables developers to write concise and readable code. A simple SwiftUI view, such as the one below, demonstrates its elegance:

This code renders a basic text view, but how it appears can vary significantly between platforms and the underlying frameworks will differ. On iOS and iPadOS the SwiftUI renders using UIKit, while on macOS AppKit is used. All transparent for the developer, some of the time.

Common Challenges in Cross-Platform SwiftUI

Layout and User Interface Adaptation

The primary challenge in in cross-platform development is ensuring that our UI looks great on all devices. Thus responsive design is key and in SwiftUI ResponsiveView is a powerful responsive tool.


The goal of ResponsiveView is to adapt its content based on the current environment, such as device type or screen size. This is particularly useful in a cross-platform context where we might want different layouts or functionalities on an iPhone, iPad, and Mac.

First, we’ll define a ResponsiveView that changes its layout based on the device being used. For simplicity, let's consider a layout that switches between a vertical stack (VStack) for iPhones and a horizontal stack (HStack) for iPads and Macs.



We can now use ResponsiveView in our SwiftUI views. Here's an example where we create a simple view with two text elements that will be arranged differently depending on the device:

In this example, on an iPhone, the texts will be stacked vertically, while on an iPad or Mac, they will be aligned horizontally.

We can further enhance ResponsiveView to respond not just to device types but also to other environment properties like size classes. This allows for even more granular control over the layout and presentation based on the current context:



This enhancement uses the horizontalSizeClass to determine the layout, providing a more responsive design that adapts to various screen sizes and orientations.

Platform-Specific Features and Capabilities

Each Apple platform has unique features. For instance, macOS supports menu bars, while iPhones offer haptic feedback. To complicate things further, SwiftUI on iOS is based on UIKit while the older AppKit is used on macOS. As such, APIs will differ even when offering the equivalent functionality. Using conditional compilation, as shown below, we can tailor experiences for each platform:


Xcode will even highlight the code path of the current compilation target.

However, as shown in the screenshot above, spreading these compiler directives across our code base can be messy and steal focus from what really matters: the business logic of our app. Luckily Swift’s system for extensions og typealiases comes to the rescue.

Consider the common functionality of copying content to the plattforms pasteboard. macOS use NSPasteboard from AppKit, while iOS uses UIPasteboard. First we create a common typealias for both platforms:



Then we write an extension on CommonPasteboard:

Thus the functionality of coping text will be the same on both platforms:

Performance Optimization

Performance can vary across devices. Profiling SwiftUI apps on each target platform is essential to identify and resolve platform-specific performance bottlenecks.

Testing on real devices is also crucial. While simulators are useful, they can't perfectly replicate the performance and user experience of actual hardware. A watch is not a Mac and vise verca.

Working with Previews

SwiftUI's preview feature allows us to see near real-time UI changes as we change the views of our app. A lot can be said about working effectively with previews, but in a cross-platform context the important part is to validate how our views look on different platforms.

Luckily SwiftUI has com a long way in this regard. By using PreviewProvider and .previewDevice() we can see how our app looks on multiple devices at the same time.

Consider this app:



As shown in the screenshot above, this view and prewiew will show the app on an iPhone. But what if we want to see the app on an iPad simultaneously? That’s easy! Replace the #Preview-code with:





Conclusion

Cross-platform development in SwiftUI has great potential for code re-use and simple techniques go along way towards creating a maintainable code base for apps targeting multiple Apple platforms. With the help of responsive design and flexible previews, only the app’s functionality remains and how hard can that be?*

* It’s the hardest part.



20-Dec