Julen står for døren, men det er ikke bare gaver vi pakker inn. I årevis har kanskje ditt verktøyvalg for å pakke inn elementer falt på border. Men hva om jeg fortalte deg at det finnes en mer fleksibel og layout-vennlig egenskap enn dette? Denne guiden vil utforske hvordan box-shadow kan brukes som et alternativ til tradisjonelle borders, og hvordan dette kan hjelpe oss å unngå layout-problemer.

Innpakning med border

La oss først ta en titt på den tradisjonelle måten å pakke inn elementer. Ta en titt på gaven under treet:

Her er en liten utfordring, så ikke scroll for raskt ned til løsningen. Hva tror du skjer hvis du hovrer over den?



Ikke overraskende, blir selvfølgelig borderen større. Men det fører også til et layout-shift — det at border blir større, fører til at knappen blir større, og den dytter på elementene rundt. Dette er ofte en uønsket effekt. Om du har  knappen i et skjema, ønsker du ikke at resten av ønskelista di skal forskyves.

Jeg skal først foreslå noen veier rundt dette, og så vil jeg foreslå en alternativ løsning med box-shadow.

Unngå layout-shift med fiksert høyde og bredde

Årsaken til layout-shift er at border er en del av et elements faktiske størrelse. Så om et element blir større, vil det også flytte på elementer rundt.

I skjemaelementer, inkludert button, er border og padding bakt inn i et elements størrelse via CSS-deklarasjonen box-sizing: border-box. Dette gjør det enklere å styre størrelsen på et element, og er også noe vi kan bruke for å unngå layout-shift med border.

En løsning for å unngå layout-shift er å definere en stor nok høyde og bredde til at den forstørrede grensen ikke overskrider størrelsen den allerede har:

Om medberegnet border-width ikke er større enn høyden og bredden som er satt, vil det ikke føre til layout-shift:

Unngå layout-shift ved å kalkulere padding

En annen løsning for å unngå layout-shift er å kalkulere padding med hensyn til border-width. Så når border-width øker, vil vi også minske padding, så knappens størrelse forblir den samme:

Resultatet ser slik ut, her en knapp med og uten transition:

Som dere ser, ser det ut til å fungere fint uten transition. Men om du ser nøye på pakken med transition, er det som om innholdet prøver å hoppe ut.  Årsaken er at padding endrer størrelse på en annen rate enn border-width.

Konklusjonen er at det er mulig å kalkulere med padding, men bare hvis du ikke skal bruke transition — eller ønsker å lage en stilig effekt.

Bruk skyggelegging som border

Siden border har noen utfordringer ved seg, kan vi heller se til et annet verktøy. Box-shadow er en annen tilnærming for å pakke inn et element. Det oppfører seg annerledes enn en border, og har dermed flere fordeler når det kommer til endringer. Først og fremst påvirker ikke box-shadow et element sin størrelse, som fører til at vi ikke trenger å ta hensyn til å kalkulere høyde eller padding.

Å bruke box-shadow som en border kan se slik ut, hvor vi henheldsvis bruker en ytre- eller en indre skygge:

Legg merke til at når vi har en indre skygge uten interaktivitet, ligner den på en grense satt med border. sMen den ytre skyggen legger seg utenpå elementets størrelse, som er ulikt border. Vi kan velge om vi skal ha en ytre- eller indre grense med inset-verdien. 

box-shadow-egenskapen lar deg styre hvor spredd skyggen er, men når vi bruker det som en grense,  bryr vi oss kun om 3 verdier: om border skal være utenfor elementet, grense-bredde og fargen (henholdsvis inset, 4px og green):

Du kan fint bruke box-shadow alene for å style en grense, men det kan også være nyttig å vite at du kan kombinere box-shadow og border. 

Siden border har visse stiler som ikke følger med i box-shadow, kan det hende du vil ha en viss border-style når den er i ro, men en ytre grense ved hover:

Bør jeg alltid bruke box-shadow over border?

Både border og box-sizing har god støtte på tvers av enheter, men det kan være visse nettleserversjoner og enheter som overstyrer box-shadow. Jeg har opplevd at Safari 15 på iPhone har fjernet box-shadow, men det har blitt løst ved å ikke tillate overstyring via CSS-egenskapen appearance. Noen epost-klienter rapporterer problemer med box-shadow, så også her bør du teste om stylingresultatet ditt er som forventet.

Konklusjonen er altså at du bør starte med border. Om du også trenger dynamiske størrelser på avgrensningen, benytt box-shadow. Du kan bruke den i kombinasjon eller alene. Men sørg for å teste om resultatet er som forventet på tvers av enheter og nettlesere.

Avsluttende ord

Jeg tror de fleste av oss har brukt border for å sette en grense. Det fungerer godt så lenge størrelsen forblir den samme, men med en gang størrelsen er dynamisk, kan det hende du bør se til andre løsninger. Dette løser box-shadow på en god måte, og er et verktøy du bør vurdere neste gang du skal ha en dynamisk grense.

Pakk inn elementene dine med box-shadow istedenfor border

Christmas is at the door, but not only presents are being wrapped. For years your tool of choice for wrapping elements has been border. But what if I told you there exists an even more flexible and layout friendly property than this? 

In this guide we will explore how box-shadow can be used as an alternative to traditional borders, and how it can solve our layout problems.

Wrapping with border

First, lets have a look at wrapping elements with the border property. Have a look beneath the tree:

Here's a challenge for you, so don't scroll further down too fast. Take a look at the following code. What do you think happens if you hover the button?

Here's the result:

Not surprising, the border of course got bigger. But it also caused a layout shift. When the border gets bigger, also the button gets bigger, and pushes elements around. This is often an unwanted effect. If you have a button in a form, you don't want the rest of the elements getting pushed when focusing a button.

I will first reveal some ways around this with border, and then suggest another solution using box-shadow. 

Avoid layout shift using fixed height and width

The cause of the layout shift is that the border is a part of the element's actual size. So if an element is bigger, logically it will also move other elements around. 

In form elements, including button, border and padding is baked into the element's size. This is through the CSS-declaration box-sizing: border-box.  This makes it much simpler to control the size of an element, and it also something we can exploit to avoid layout shifts with border.

One solution is to define a big enough height and width, so the increased border size does not exceed the size it already has:

If the included border-width is not greater than the height and width that have been set, it will not lead to a layout shift:

Avoid layout shift by calculating the padding

Another solution to avoid layout shift is to calculate padding with regard to border-width. As the border-width increases, we also decrease the padding, so the button's size remains the same:

The result looks like this, here a button with and without transition:

As you can see, it seems to work fine without transition. But if you look closely at the package with transition, it's as if the content is trying to jump out. The reason is that padding changes size at a different rate than border-width.

The conclusion is that it is possible to calculate with padding, but only if you are not going to use transition — or want to create a stylish effect.

Use shadows as a border

Since borders have some challenges, we can rather look to another tool. Box-shadow is another approach to wrapping an element. It behaves differently than a border, and thus has more advantages when it comes to changes. First of all, the box-shadow does not affect an element's size, which means that we do not need to take account of calculating height or padding.

Using box-shadow as a border can look like this, where we use either an outer or an inner shadow:

Notice that when we have an inner shadow without interactivity, it looks like a border set with border. Whilst the outer shadow is placed outside the element's size, which is different from border.

We can choose whether to have an outer or inner border with the inset value. The box-shadow property allows you to control how spread the shadow is, but when we use it as a border, we only care about 3 values: whether the border should be outside the element, the border size and the color (inset, 4px and green, respectively):

You can just fine only use box-shadow alone to style a border, but it can also be useful to know that you can combine box-shadow and border.

Since border have certain styles that are not included in box-shadow, you may want a certain border-style when it is at rest, but an outer border using box-shadow on hover:

Should I always use box-shadow over border?

Both border and box-sizing have good cross-device support, but there may be certain browser versions and devices that override box-shadow. I have experienced that Safari 15 on the iPhone has removed the box-shadow, but this has been resolved by not allowing overriding via the appearance CSS property. Some e-mail clients report problems with box-shadow, so also this should be checked whether your styling result is as expected.

The conclusion is that you should start with borders. If you also need dynamic sizes for the border, use box-shadow. You can use it in combination or alone. But make sure to test whether the result is as expected across devices and browsers.

Final words

I think most of us have used border to wrap our elements. It works well as long as the size remains the same, but once the size is dynamic, you may want to look at other solutions. box-shadow solves this in a good good way, and is a tool you should consider the next time you need a dynamic border.

Wrap your elements with box-shadow instead of border

Designsystem sprer seg som ild i tørt gress blant digitale tjenesteleverandører, og med det dukker faguttrykket design tokens opp i stadig nye møterom. Det er ikke helt rett frem å skjønne hva det er, og hvorfor man bør bruke tid (og penger) på det.

Oppsummert kan man si at design tokens er definerte variabler som påvirker hvordan komponenter og brukergrensesnittet blir satt sammen. De gir et felles språk i tverrfaglige team. Digitale tjenester blir mer enhetlig med det samme “materialutvalget”. Og det gjør de digitale tjenestene fleksible og mulig å endre på en effektiv måte. Men om du ikke er helt overbevist enda, er det bare å fortsette å lese.👇





Hva er design tokens?

I Aksel, designsystemet til NAV, er design tokens forklart på følgende måte:

Design tokens er små byggeklosser bestående av designattributter som farger, typografi, størrelser, avstander, former osv. De er ikke begrenset til en spesifikk teknologi eller et designverktøy, men er fleksible variabler som kan benyttes av alle.

Altså er design tokens et utvalg av “visuelle formateringsegenskaper” som man definerer slik at man slipper å ta stilling til de samme valgene hver gang man skal lage noe nytt. Og siden alt ikke skal bli likt må man ha litt å velge mellom innen farger, typografi, størrelser, avstander, former osv. Dermed får man variasjon i det man lager, men også en funksjonell og visuell sammenheng. Det vil si at man i en digital løsning bestemmer seg for blant annet hvilke formspråk man skal ha og hvilken fontstørrelser man skal kunne velge mellom slik at man slipper å ta stilling til dette på nytt hver gang.

Design tokens og husbygging

Man kan sammenlikne det å utvikle et digitalt brukergrensesnitt med å bygge et hus. Hvis du skal bygge et hus gjør du materialvalg for å få det huset du ønsker deg. Huset skal bli seende ut slik du ønsker og følge standarder innen universell utforming og brannsikring. Du bestemmer materialer, utforming og farger. Du velger for eksempel lecablokker i stedet for murstein, pipe i metall i stedet for mur. Dette er design tokens. Bevisste og satte føringer for å få det uttrykket og kvaliteten du ønsker.

Så, basert på disse materialvalgene lager du bestanddelene du skal bygge huset med: innvendig og utvendig panel, material og form blir til dører og vinduer, karmer, tak, pipe osv. Dette er komponentene.



Materialutvalget (design tokens) styrer hvordan bestanddelene (komponentene) ser ut og hvordan det settes sammen i totalen, og til slutt skaper det huset (brukergrensesnittet) du vil ha. Så, hvis du ønsker deg et funkishus får du asymmetriske vinduer med metallbeslag, ikke kvadratiske vinduer med sprosser. Hvis naboene dine bruker samme design tokens som deg vil huset deres likne på ditt selv om de har behov for annen funksjonalitet som flere etasjer og dobbelgarasje.

Design tokens former komponenter

Når man bygger komponenter, for eksempel en handlingsknapp, tar man mange valg for å sikre at knappen står i stil med resten av grensesnittet og er universell utformet. Disse valgene kan defineres og settes i system.



Farge på tekst og bakgrunn skal tilfredsstille krav til universell utforming. Størrelse på font skal være i tråd med andre knapper og tekster i grensesnittet. Form og uttrykk skal løses på en måte som gjør at de som trykker på knappen skal skjønne at det er en knapp. Ved å forhåndsdefinere disse variablene, slipper man å gjøre disse vurderingene på nytt hver gang man skal designe en knapp. Det er dette som er design tokens.



Det fine med design tokens er at de gjelder på tvers av komponenter. En knapp og et søkefelt baseres på det samme settet av design tokens. Det betyr ikke at de må bruke den samme fontstørrelsen, men at de velger fontstørrelse innenfor det samme utvalget. Dette gjør det tekstlige hierarkiet tydeligere.

Design tokens og komponenter former brukergrensesnitt



Så, design tokens er fleksible variabler som man bruker når man lager komponenter slik som knappen nevnt over. Disse variablene må man ta hensyn til når man lager det totale brukergrensesnittet også. Så når man setter denne knappen sammen med andre komponenter på en bakgrunn, bruker man de samme satte verdiene for farger, avstander, tekst, luft osv. Dermed sørger design tokens for riktig utforming av både enkeltkomponenter og det sammensatte grensesnittet.

Hvilken verdi har design tokens?

Mer enhetlig uttrykk og klar avsender

Når man har et definert utvalg å velge mellom er det noe underliggende gjenkjennbart i grensesnittene man lager, selv om funksjonaliteten er ulik. En utbygger som bruker samme design tokens på flere hus vil bygge hus som har mange likhetstrekk, men som oppfyller ulike behov. I digital produktutvikling, når flere utviklingsteam bygger løsninger med samme avsender men som møter ulike behov, vil løsningene være kjente for brukeren uten å være identiske når de bruker det samme settet av design tokens.



Mer fleksibelt og robust for endring

De fleksible variablene som utgjør design tokens defineres i en navnestruktur. Hvis denne er løst riktig vil man lage et robust og fleksibelt system som gir rom for endring på en svært effektiv måte. Ved å innføre en trestruktur i navngivingen av variablene er det mulig å gjøre endringer i flere nivåer og med ulikt omfang. En navnestruktur kan for eksempel bygges opp med en raw value, core token, alias token og semantic token. Raw value er en konkret verdi, for eksempel en hex-kode for farge, core token oversetter raw value til et litt mer beskrivende navn, alias token definerer core token i et hierarki av tilsvarende verdier (eks en bakgrunnsfarge sier noe om hvor den plasseres når det brukes sammen med en tekstfarge), og semantic token sier noe om i hvilken kontekst verdien er brukt. Dette gjør det mulig å gjøre endringer på kontekstuelt nivå, hierarkisk nivå og i konkrete verdier.



For eksempel, hvis man har definert en hovedfarge for bakgrunn (eks. primary.background.color) kan man velge at den verdien ikke lenger skal peke på blue-700, men heller pink-300. Da vil alle komponenter som bruker primary.background.color, det være seg knapper, søkefelt, tabeller, gå fra å være blå til å blir rosa. Altså kan man endre en større del av løsningen ved å gjøre én justering ett sted.

Enklere kommunikasjon og samarbeid



Siden design tokens har en egen navnestruktur gir det et felles språk. Verdier i utvalgene får egne beskrivende navn, og det blir lettere å kommunisere internt i et utviklingsteam på tvers av fagfelt. Med et definert utvalg av egenskaper for grensesnittet, og en felles definisjon av dette er det lettere å unngå misforståelser og man kommer raskere til en felles forståelse.

…



Tusen takk for til Marlin Vanebo Hjallum for alltid lærerik sparring 🙌

Hva er design tokens? Og hvilken verdi har det?

Hils på OPRA - et hobbyprosjekt som gir bedre kjøpekraft til folk som jobber i operative yrker.

Hobbyprosjekter er en utrolig fin måte å lære seg produktutvikling på for utviklere. Ikke bare lar det oss ta fullt ansvar for selve produktet, men man blir tvunget til å ta stilling til ting som vekst, sluttbrukere og tilbakemeldinger. Også er det veldig gøy da, det skal sies.

Jeg har – sammen med et par andre venner – jobbet med et hobbyprosjekt som vi kaller OPRA – kort for Operativ Rabatt. Det er en tjeneste som fremforhandler og tilgjengeliggjør ekstra gode rabatter for en kritisk del av samfunnet vårt – operative.

Om “operativt personell” er et nytt uttrykk for deg, så er det helt okei. Operativt personell er folk som jobber i forsvaret, politiet, brannvesenet og ambulansetjenesten. Det er folk i den frivillige redningstjenesten. Det er rett og slett folk som gjør en helt fantastisk og kjempeviktig jobb for samfunnet, slik at oss andre kan sove trygt om natten.

Ulempen med å jobbe i mange av disse yrkene er at de er veldig dårlig betalt i forhold til innsatsen – og risikoen – som legges inn. Derfor tenkte vi at å øke kjøpekraften deres, gjennom gode rabatter på ting man trenger, var en fantastisk måte å gjøre de yrkene mer attraktive for de beste folka blant oss.

Hva er OPRA

OPRA er en nettside (og snart en app) som gjør det enkelt å finne og bruke en rekke forskjellige rabatter. Vi fremforhandler rabattene selv med møter med forskjellige bedrifter, eller så får vi tilgang til rabatter gjennom såkalte affilatenettverk vi samarbeider med. Den forhandlingen går overraskende enkelt – folk er nemlig veldig villige til å strekke seg litt lenger for å tilby tjenestene og varene sine til denne brukergruppen.

Per i dag har vi over 100 rabatter som folk kan bruke. Og det er ikke bare tullerabatter heller – vi snakker alt mellom 10 til 40 prosent rabatt på kjente merkevarer! Og det hjelper på bunnlinja i familier som ellers kanskje ikke kan påspandere seg altfor mye.

For å bli medlem må du laste opp et bevis på at du er kvalifisert for å delta i OPRA. Teamet undersøker dokumentasjonen som lastes opp, og så godkjenner vi (eller en sjelden gang underkjenner) søknaden. Så er du logget inn og har tilgang til kjempegode rabatter – helt gratis.

Hvordan vi jobber

OPRA er drevet av meg, Eric og Sissel – to som jobber i nettopp disse operative yrkene. Eric er helikopterpilot for redningstjenesten i Stavanger, og Sissel jobber på AMK-sentralen (de som tar telefonen når du ringer 112). Sammen er vi en skikkelig fin gjeng som har fått til dette med arbeidsfordeing.

Eric og Sissel fremforhandler rabatter, og jobber aktivt ut mot interesseorganisasjoner som fagforbund og arbeidsgivere for å onboarde nye brukere. Jeg utvikler løsningene våre, og passer på at alle. Og sammen godkjenner vi brukere, svarer på henvendelser og tenker ut strategi for både å vokse, ekspandere til nye markeder og lage det beste produktet vi kan.

Arbeidet tar endel tid, men ikke mer enn at det passer inn i en hektisk hverdag, med både jobb, familie og fritidsaktiviteter. Vi har lagt stor vekt på at vi skal ha det gøy med dette prosjektet, og at det ikke skal spise mer av fritiden vår enn vi er komfortable med.

Penger og sånn

OPRA har hatt to forskjellige forretningsmodeller opp gjennom. Da vi startet kostet det 30 kroner måneden å være medlem. Det dekket alle utgiftene våre, og ga oss et lite overskudd. Det overskuddet brukte vi til å dele ut det vi kalte OPRAs takknemlighetspris. Denne prisen består av en statuett vi har laget, samt 25.000 kroner. Den blir delt ut et par ganger i året til nominerte operative som har gjort en ekstraordinær innsats. Du kan lese mer om hvem som har vunnet her.

Målet med OPRA var ikke å tjene masse penger, men å tilby bedre kjøpekraft til folk som fortjener det. Derfor gikk vi i år vekk fra en betalt modell, og over til å tilby denne tjenesten gratis ut mot sluttbrukerne. Istedenfor tjener vi penger gjennom såkalte affiliate-avtaler, der vi får betalt noen prosent av hva brukerne våre bruker penger på. Kjøper noen en TV for 5000 kroner, tjener vi for eksempel 150 kroner.

Det skal sies at betalingsmodellen vår var ganske mye mer innbringende enn denne affiliate-løsningen, men det betaler fortsatt nok til at vi kan dekke kostnadene våre, og spare opp litt penger til OPRAs takknemlighetsfond. Og om vi blir skikkelig populære en dag, kan det jo hende at det blir litt penger igjen til oss som bruker fritiden vår på det her.

Teknologi, da?

OPRA består av to tjenester – opra.no og en (straks ferdigstilt) mobilapp.

OPRA.no er basert på Next.js, Chakra UI og Firebase. Disse tre teknologiene ble valgt rett og slett fordi det var de teknologiene jeg kunne best da jeg startet arbeidet, og vi hadde et stort behov for å få noe ut til brukerne våre raskest mulig. Det har vist seg å være gode valg vi fortsatt er komfortable med i dag – selv om det innfører noen begrensninger man ellers ikke ville hatt.

Appen vi jobber med nå er basert på React Native og Firebase, og er i stor grad en mobil-implementering av det samme vi har på nettsiden vår – pluss noen ekstra features som push-varsler og andre finurligheter.

Status

Status per i dag er at OPRA er en høyt elsket organisasjon blant operative. Vi har over 17.000 aktive medlemmer, med over 30.000 sidevisninger hver eneste måned. Vi har avtaler med en rekke forskjellige interesseorganisasjoner og får massevis av henvendelser fra folk som ønsker å tilby rabatter til folka våre.

Vi har planer om å ekspandere til andre land også – men det tar vi som et mål for 2024. Det haster liksom ikke altfor mye heller, men det er jo gøyalt å legge strategier for.

Om du kjenner noen som jobber i operative yrker, så kan du jo tipse dem om OPRA – kanskje de ikke har hørt om oss enda?

Hobbyprosjekt: OPRA

This guide outlines the steps needed to inform Google of each new page in your Sanity CMS and dynamically boost your site's visibility and ranking in the search results.

Have you ever spent all your time perfecting every pixel on your website? Well, stop doing that - for now, at least. First things first, make Google happy. Why? Because when Google is happy, your website steers clear of the valley of death known as page 2 of the search results. This way, potential customers are far more likely to find and visit your website, increasing the likelihood that your business will succeed.

There are several techniques that can enhance Google's affinity for your website. These include setting a distinctive <title> for each page, ensuring that all pages feature a unique and comprehensive meta-description, and, of course, setting the correct language in your HTML. These practices form the foundation of how Google indexes and prioritizes your website. However, there's another essential element known as sitemaps. Sitemaps are XML documents widely employed by almost every commercial website. You can easily check this by adding '/sitemap.xml' to the end of any website's URL. Doing so reveals a list of all the sub-pages on that website, and this is actively utilized by Google during its website crawl to discover new information for potential inclusion in its search results.

It's essential to generate a sitemap dynamically based on the data in, for example, your Sanity CMS. This ensures that Google is promptly notified, by your sitemap, whenever your website has a new page that Google hasn't disovered before. This should help boost both the visibility and the ranking of your new page.

Now that we understand the significance of sitemaps for a commercially successful website, let's explore how to dynamically create them in Remix using Sanity's 'slugs'.

Step 1: Begin by crafting a function to retrieve all slugs from Sanity. In our example below, there are three distinct types of data: productions, liveshows, and talents. The slugs associated with each category serve as unique URLs on the website.

Step 2: Establish a new route on your website by creating the file "routes/sitemap[.]xml.tsx”. This particular route will dynamically produce and distribute an XML document, housing the URLs obtained through the function you created in the previous step:

Step 3: Inform Google of your sitemap's existence through the Google Search Console. You can let Google know that you've crafted a sitemap for your domain by simply adding it on this page. This step not only notifies Google but also allows you to track how frequently the search engine reviews the sitemap for any new updates. In my experience, this tends to happen about once a week.

That's all there is to it! Now, whenever you add a new entry to your Sanity CMS, its corresponding slug will be fetched dynamically and showcased in your sitemap. Google will now surely give you a little extra love!

5-Dec

Today's posts

Pakk inn elementene dine med box-shadow istedenfor border

Wrap your elements with box-shadow instead of border

Hva er design tokens? Og hvilken verdi har det?

Hobbyprosjekt: OPRA

Help Google Help You - Dynamic Sitemaps with Remix and Sanity