How to describe organizational culture has long been a topic of much debate. Evaluating whether an organizational culture should be altered has been so as well. This article explores if combining two recognized cultural frameworks is worthwhile when describing and evaluating organizational cultures.

What is culture?


The existence of culture is impossible to dispute, yet the nature of culture is almost impossible to describe. It “permeates all aspects of any society. It acts as the basic fabric that binds people together.” (M. J. Martin, 2006). It is invisible yet tangible.

It is difficult to measure culture without first describing what we are to measure. Therefore, the following definitions of culture—although they may differ from your own—function as a vocabulary for interpretation of our measurement frameworks.

Culture does not exist within one individual. It occurs in the interactions and integrations between us. Putnam defines culture as the combination of pattern of thought, emotions, and actions. They are the atomic composition of “The way we do things around here.” (M. J. Martin, 2006), which on the molecular level entails:

how an organisation uses its resources

how it structures itself

who the people are

how it processes and completes work (M. J. Martin, 2006)

On a more abstract level organisational culture can be exemplified as “[the way] an organisation responds to its challenges, whether these are explicit (such as a crisis) or implicit (such as a latent problem or opportunity)” (R. Westrum, 2004). Therefore, given this definition, it naturally resonates that “Culture eats strategy for breakfast.” (P. Drucker). After all, strategy only make up one or two bullets on the list.

Equipped with these definitions we hypothesise that a combination of the well-established OCAI framework, Westrum’s typology of organisational cultures (a cornerstone in The State of DevOps report), and the standard Employee Net Promoter Scores would each provide unique perspectives of an organisation’s culture, and therefore could be adequately merged. This article explores this hypothesis.

What is OCAI?

OCAI (Organizational Culture Assessment Instrument) is a recognized culture framework, used to classify an organizational culture. This is achieved through the use of two dimensions, one describing whether the organisation is internally or externally focused, and the other describing whether an organisation is characterised by stability or flexibility. By combining these dimensions, four culture archetypes appear. The OCAI framework says nothing about the value of these organisational cultures. In other words, evaluating whether a culture change is desirable is entirely up to the decision makers.

The four culture archetypes are:

Clan: A friendly and person-oriented culture. Personal development is prioritized and a high degree of flexibility is employed to find optimal solutions for the autonomous coworkers. It is seen as important to have a good working environment, characterised by unity and support.

Adhocracy: A dynamic, visionary and creative culture where employees are encouraged to try new things. Developing new solutions and employing new technology is energizing. The future is explored, rather than planned for!

Market: A results oriented and competitive culture with an emphasis on getting the job done and achieving defined targets. The importance of clear goals, known by the entire organization is recognized. Measuring the activities performed is seen as important, and healthy competition is seen as a tool to stimulate and energise the organisation.

Hierarchy: A highly formalised and structured organisation. Procedures guide which and how activities are to be done. People and cases are to be treated correctly, and in a predictable fashion, guided by clear rules and structure.

To classify an organisational culture a questionnaire consisting of questions within six categories is used.

What is Westrum’s typology of organisational culture?

The DORA State of DevOps research programme is a rigorous and recognised study in the capabilities that drive higher organisational performance through software. The findings in the report is often used as a guiding tool in organisational striving to become more agile and lean through implementing DevOps, and the study found that optimal information flow is predicative of higher performance.

R. Westrum summarises that the most critical characteristic in how an organisation responds to its challenges is how information flows within it.

This is further described in his The Three Cultures Model: 

The Three Cultures Model postulates that moving towards a more generative culture is desirable for an organization. Hence, The Three Cultures Model answers a question the OCAI framework does not. 

What is eNPS?

eNPS is a popular measure of employee satisfaction.

It is computed based on a survey of the employees in an organisation consisting of only one question: “How likely is it that you would recommend your organization as a place to work on a scale of one to ten?” The responses are then sorted into three categories:

Promoters: Replies with scores 9 or 10

Passives: Score 7 or 8

Detractors: Score 6 or below

The score equals the percentage of promoters among the respondents less the percentage of detractors among the respondents, multiplied by 100. Hence, the final score will be a number between -100 and +100. There are no industry standards on what qualifies as a “good score”, however, as long as the score is above 0 your organisation is in theory an attractive place to work.

Our method

We hypothesised that by combining The Three Cultures Model and OCAI we would end up with a framework for describing organisational culture that would be more valuable than the stand-alone frameworks individually. This hypothesis is supported by the fact that OCAI classifies cultures by type, whereas The Three Cultures Model classify cultures by value. In other words, they answer different questions and therefore highlights different aspects of organisational culture.

To test the hypothesis we built and distributed a survey consisting of the questions pertaining to both of the frameworks. Using this data, multiple regression analysis were employed to test whether the results from The Three Cultures Model could predict the OCAI results for the respondents. Our hypothesis was that no such prediction would be possible, as the two frameworks supposedly measure different things. However, if we were to find that the OCAI results could be predicted by The Three Cultures Model, it would indicate that combining the models would not be worthwhile.

What we found

The results came in according to our hypothesis: Knowing how an organisational culture scored on The Three Cultures Model did not tell us anything about the score of the same culture on the OCAI framework.

We therefore proceeded to describe the culture types that would emerge by combining the two frameworks:

The survey also included the eNPS question. This data indicated that more generative cultures are correspond with more satisfied employees, in line with what one would probably believe to begin with. This underpins R. Westrum's claim that having a more generative organisational culture is favourable.

Measuring the impact of change

While the OCAI-framework postulates that all four culture archetypes are in principle equal, the Westrum topology distinguishes cultures by value for the organization. All else equal, it would always be preferable for an organisation to have a generative organizational culture instead of a pathological culture.

Before initiating a change towards a more generative culture, however, decision makers not only need to accept that such a culture is indeed desirable. Decision makers also need to form an opinion on the extent to which such a culture is valuable, as change is most likely not going to be cost free.

The value of changing an organisational culture is manifested by the set of desirable activities that are made more likely because of the cultural change. The crux of valuing a particular culture is therefore identifying these activities, evaluating the impact that culture has on how, or if, these activities are performed and evaluating the effect of these activities.

When identifying the set of activities made more likely by a generative culture, it becomes clear that there is a large overlap between the characteristics of agile organizations and the characteristics of generative organisational cultures. Common characteristics include cooperation, free flow of information between teams and individuals, empowered employees actively taking responsibility, exploration of new ideas and learning from mistakes. The large overlap indicates that measuring the value of agility and the value of more generative organisational cultures are two sides of the same coin. Organisations cannot become more agile without also adopting a more generative culture. This is underpinned by other research, as e.g. McKinsey states that “The importance of investing in culture and change on the journey to agility cannot be overstated.“

Several studies show that agile organizations perform better as a consequence of possessing these characteristics. These studies are generally comparing the financial results of agile companies, as measured by the degree to which they possess agile characteristics, to non-agile companies.

In order words, to get an idea of the financial impact of adopting a more generative culture, we used these studies as a starting point, and modelled the profitability of a company as a function of several moderating variables. Specifically, the model includes the following:

Baseline effects: The potential for increased profitability (by adopting a more generative organisational culture) must be inversely proportional to how generative the culture is to begin with.

Scope: The potential for increased profitability by adopting a more generative organisational culture must increase if the more generative culture is adopted for a large share of the company.

Financial size: The larger the organization is, financially, the larger the potential for increasing profits through cultural change.

Share of impact explained by culture: As discussed above, we argue that a large part of the business impact of agility can be explained by the cultural aspect. In the model this share is set to 100%. A sensitivity analysis can easily be made by the reader, as this variable affects the estimated value proportionately (e.g. set the variable to 80% instead of 100%, and the estimated value decreases by 20%).

The most important assumption, however, is the assumption that successfully adopting a generative culture for the whole organization increases the yearly profits by 25% if the culture is pathological to begin with. This estimate is in line with previous research, and is driven by both cost savings and revenue increases.

Research indicates that the cost savings primarily stem from reducing the administrative costs associated with control and command-activities. Revenue increases, on the other hand, is most likely driven by a combination of a reduction of churn and an increase in customer acquisition (improving customer satisfaction and faster adaptation to competitor moves), as well as better decision making capabilities with regards to innovation and product development as a consequence of the improved information flow.



Relevant resources

Drypp podcast about this article (in Norwegian): Hvordan kan OCAI og Westrum kombineres for å kvantifisere kultur? by Drypp fra Bekk

M. J. Martin, 2006 — “That’s the Way We Do Things Around Here”: An Overview of Organizational Culture 

R. Westrum, 2004 — A Typology of Organisational Cultures

Why Does Culture 'Eat Strategy For Breakfast'?

Culture and agility

The 12 Stages Of The Agile Transformation Journey

The 6 essential pillars of a successful agile transformation

Financial impact of organizational agility

Organisational agility drives financial performance

Driving impact with enterprise agility―just get moving

Enterprise agility: Buzz or business impact?

What is Business Agility





Combining OCAI and The Three Cultures Model 

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Er godt eksekvert fossefall bedre enn dårlig eksekvert smidig? (Del 3 av 6)

Have you ever thought about how many mouse clicks you perform each day? 5000? 10,000? I started to think about that when each click started to get uncomfortable. This led me to think: is it possible to remove the clicking altogether? And yes! It is! The solution I found was creating the program ClickRelief.

Tired of fish 

My first year as a software engineer was a rough one. I gradually developed something that could be categorized as repetitive strain injury (RSI); every keystroke and mouse click resulted in pain getting worse by every touch. This led me into creating a speech-to-text system to decrease my keyboard usage. However, there was one problem - the clicking. For a period I said "click" or "fish" (which was the word I actually used) for every click. Saying "fish" 5000 times a day makes your voice (and mind) a bit shaky. So I thought about other ways to initiate a click, like stepping on a foot pedal or using my knuckle or elbow. But just finding another muscle in the body to perform a click did not seem like a passable approach when already diagnosed with repetitive strain injury. Using an eye tracker system also crossed my mind but this felt like overengineering and would be inefficient. Hence I wondered if I could find a way to remove this clicking entirely. Would that be possible?

Creating ClickRelief

First, let’s take a step back and think about what we use the mouse for. Most people would agree that performing a click at a specific point on the screen is the main usage of the mouse. Some might also use it as a reading marker or something to move around as they think. So it’s also about habits. For me, I found this statement to be true most of the time:

(*) “When I start moving the mouse, the goal is eventually a click"

I was looking for an application that relieved my pain related to clicking, ideally removing it altogether. Having the above statement in mind (*), I wanted a program which executed a mouse click after the mouse movement was done. Moreover, I wanted to somehow be able to initiate a double click without clicking. Unfortunately, browsing the web did not result in any programs that met my needs. Therefore, I decided to create one myself and the result was "ClickRelief". At time of writing, I’ve been using ClickRelief daily for five years. The program has been of high value to me, and I’m hoping others can make use of it as well. Read on to see how it works!

Single click

When ClickRelief is running, all you must do to perform a single left click is to move the mouse pointer to where you want to click and stop there. The premise for the application is that when you start moving the mouse, the goal is eventually a click. If this is not true, the program should not be running, more on that later.





Double click

To perform a double click, the mouse pointer must do a “detour-move” in the vertical-direction. The mouse pointer must reach the final point by going past it and come back.



The video demonstrates how double clicks can be performed using ClickRelief. We see that double clicks can be performed either by going past the final point on the way up and come back, or passing it on the way down and then go up. When the pointer does not take such a detour, a single click is performed.

You might ask; what decides if a mouse movement is infact a detour-move? For instance, if you move the pointer just a few pixels up and down, will a double click be executed? Well, that depends on a setting in ClickRelief. ClickRelief has a number (dY) that sets the minimum height of the detour-move. If this number is set to 50 pixels, you need to move the mouse 50 pixels up and down for it to execute a double click. A smaller move will just result in a single click. A good way to avoid unintended double clicks is to fine tune dY to the right number of pixels.

Right click and scrolling?

ClickRelief does not have any way to right click or scroll. I've thought about various movement that can trigger a right click, but I always conclude that it will be a bit trigger happy getting more right clicks than intended. I reached the same conclusion about scrolling. Thus the question was - how could one perform right click and scroll without the use of fingers? I learned that foot pedals can a good solution for this. I use three foot pedals to relief me from right clicking and scrolling, in addition to the pedal that starts/stops ClickRelief. 

In my experience, foot pedals work well for these actions since they are not performed that frequently. I would not recommend using a foot pedal for the more frequent left clicking (just imagine the amount of work required by your foot in that case).

Start/stop

You'll probably not always want to have ClickRelief running. For instance, the “hover”-action will never be possible while ClickRelief is running. To easily start and stop the clicking, press the hotkey Ctrl+Shift+Alt+M, or find the start/stop button in the ClickRelief program. Many computer mouses have the feature to bind buttons to hotkeys. If you bind one such button to the ClickRelief on/off hotkey, the program can easily be switched on and off. Alternatively, you can use foot pedals as shown above. I have bound one pedal to the on/off hotkey, that’s one less button to click.



What about dragging the mouse?

There is no movement to trigger this in ClickRelief. However, if you are holding down the left mouse button, ClickRelief detects it and will disable itself. In other words, you can perform drag and drop in the same way as you normally do without thinking about ClickRelief running in the background. I rarely find myself in the need of doing drag and drop, so I don’t mind doing it manually.

Mouse movement habits

Using ClickRelief for the first time can lead to some unintended clicks. To get the most out of the program, it can be wise to review your mouse movement habits. Two challenges you  can experience when using ClickRelief are:

Executing a double click when a single click is intended

Executing a click when you don’t want to click

To mitigate these, a strategy can be to decide where you want to click before you start moving the mouse. Having made this decision, the task is just to move the pointer to that place, without taking a detour, and stop there (single click executed). Deciding the click-point beforehand will reduce the times where you have the mouse pointer on the run without knowing where to stop. In my experience, for most of the pixels on the screen, if you click them nothing happens since they’re not buttons. So, if the mouse pointer is on the run, just figure out the closest point where nothing bad happens and rest the pointer there. A final note is that unintended double clicks can also be mitigated by fine tuning the double click height (dY) as described earlier.

Want to try ClickRelief?

I’ve been using ClickRelief daily for several years. It has been invaluable to me and I’m hoping that others can find it helpful as well. Even though it's well tested, the application has room for improvement, and it would be interesting to get some feedback from other users. If you want to try ClickRelief, please don’t hesitate to sign up here and you will receive a copy. 

ClickRelief - click without clicking!

I Bekk snakker vi mye om viktigheten av å jobbe kontinuerlig i tverrfaglig team og hvilken verdi det gir produktene vi jobber med. Denne artikkelen handler om det motsatte, da en interaksjonsdesigner og jeg som visuell designer, kom inn på prosjekt for å jobbe med en ny funksjonalitet alene, og utviklerne på teamet var satt til å jobbe med forvaltningsoppgaver. 




Samtidig gjorde denne erfaringen det mulig å få med kunden til å snu den organisatoriske skuten mot en tverrfaglig og kontinuerlig leveranse. Vi ønsker å dele hvordan vi jobbet i de ulike prosessene, hvilken effekt de har hatt på motivasjonen i teamet og hvilken verdi det har gitt produktet og brukerne. Det skal sies at vi i skrivende stund står midt i endringen, og vi holder fortsatt på å justere og iterere på de forbedringene vi har iverksatt.






Litt om kunden og systemet.

Systemet er et digitaliseringsprosjekt som automatiserer behandling av oppgjør. Dette blir brukt av ca 30 brukere som sitter spredt rundt i hele Norge. Disse brukerne er gruppert inn i 4 regioner: Nord, Sør, Øst, Vest. Og for hver region finnes det en spesifikk bruker som er utnevnt til representant (og kalles heretter: representanter). Ansvaret til representantene er å forankre endringsønsker som kommer fra brukerne til produktteamet og å være brukernes talerør.






Tidligere fossefallsprosess, hindringer og feilskjær.


Etter å ha reflektert rundt denne erfaringen er det noen deler av arbeidsmetodikken som utpeker seg som bidragsytere til at det som skulle bli en suksess, ble et feilskjær.


Jeg vil starte med organisasjonsstrukturen og kulturen hos kunde(se modell 1). Den la noen føringer på hvordan informasjonsflyten gikk fra brukerne, som første ledd, til utvikler og designer, som siste ledd. Informasjonsflyten hadde likhetstrekk med en formell hviskelek. Når et endringsønske oppsto formidlet en bruker dette til sin regionale representant. Deretter gjenga representanten dette ønsket videre i et ukentlig møte med kunden, som igjen videreformidlet dette til oss i et neste mulige møte. Ved spørsmål til endringsønskene, gikk feedback-loopen tilbake til brukerne i de samme stegene via de samme møtene.



En annen ting som utpeker seg er at design og utvikling jobbet med helt ulike oppgaver. Designoppgavene var nyutvikling av systemet og utviklerne jobbet med forvaltningsoppgaver, men vi hadde jevnlige, men i grunn for få, møter hvor vi kunne diskutere og revidere nyutviklingsarbeidet. Ved at vi jobbet på ulike oppgaver var ansvaret rundt det å lage det riktige produktet også kjempestort. I perioden hvor designerne jobbet med utarbeidelsen av designet til ny funksjonalitet var ansvaret kun på våre skuldre, og utviklerne fikk både den massive overleveringen i tillegg til ansvaret på sine skuldre i etterkant. Det var mye ansvar i ulike perioder for begge, og stafettpinne konseptet ga ikke trygghet for noen av oss. Fordi utviklerne ikke var tett nok på arbeidet med å utforme designet fant de noen uoppdagede tekniske utfordringer i det de skulle i gang med implementasjon, og utviklerne satt med flere spørsmål til en designressurs som ikke var tilgjengelig på det tidspunktet. Usikkerheten om at de løste faktiske behov gjorde at implementasjon av designendringene ble utsatt.


En tredje faktor er at vi ikke fikk deploye til produksjon selv. Så når et endringsønske endelig hadde nådd frem til oss, blitt tolket og bearbeidet, designet, utviklet og testet, måtte den gjennom nok et ledd før den faktisk ble tilgjengelig for brukerne.


Resultatet av disse faktorene var lang delay fra endringsønsker til realisering av behov, og i noen tilfeller ble ikke funksjonaliteten brukerne trengte implementert i det hele tatt.




Det vi lærte av feilskjæret:

Direkte kontakt med brukerne minimerer risiko og tidsbruk

Det er viktig å finne ut i prosjektoppstarten hvem som har mandat til å kunne endre kurs på prosjektet, eller som produktteamet må ta hensyn til, og inkludere alle i prosessen

Vi må ha tydelige mål helt fra starten av, og sammen bli enige om hva det riktige produktet vi skal lage er, og hvorfor

Viktigheten av å forventningsstyre omfang og scope ned oppgaver slik at designer også er tilgjengelig i implementasjonstiden

Designrelaterte oppgaver må inn i prosjekttavlen og være en del av teamet

Det er stor sjanse for at designet må etterjusteres på grunn av tekniske avhengigheter

Design og utviklingsressurser må være tilgjengelig om brukergrensesnittet skal endres på

Alle fagområdene skal være representert og har ansvar for nyutvikling og justering av systemet

Design er ferskvare som fort går ut på dato






Starten på prosessendringene.


Vi har gjennom årene på prosjektet opparbeidet oss mye tillit hos kunden og vi har tatt ansvar utover egen rolle på prosjektet. Dette har bidratt til at vi har hatt god oversikt over historikken, vi har kunnet samle erfaring rundt suksesser og feilskjær, og vi har hatt kunden med på laget. I år startet jeg igjen på prosjektet sammen med en interaksjonsdesigner med mål om å jobbe med forbedring av arbeidsprosessen i teamet. Det var tydelig at vi måtte gjøre noen endringer (se model 1), og vi ønsket å jobbe mer kontinuerlig og ha designer tilgjengelig i implementasjonsperiodene. Sammen med interaksjonsdesigneren planla og fasiliterte vi workshops for å sette nye mål, revidere samarbeidet med interessenter og brukere, og forbedre produktutviklingsprosessen. Videre jobber vi med å følge opp prosessendringene som teamet ble enige om i retroer, og med å skaffe brukerinnsikt og designe forbedringer på selve grensesnittet ut fra de nye målene.




De store effektene

Resultatet av denne endringen er først og fremst at vi er blitt et produktteam (kunde og bekkere), vi får ut små og verdifulle endringer ut i produksjon, og vi har anledning til å iterere på dem sammen.





Vi er ikke helt i mål med informasjonsflyten et endringsønske tar, men produktteamet tar oftere direkte kontakt med brukerne for å diskutere dem. Vi jobber også med å få opprettet et brukerforum i slack, hvor vi kan stille kjappe spørsmål, dele små endringer og hvor de kan dele erfaringer på tvers av kontorer og regioner. I dag kaller vi inn til digitale møter via mail, og erfaringsmessig er feedback-loopen for lang og det tar unødvendig mye tid å organisere.


Vi har opprettet en ny kanban-tavle med fokus på mål som gjør at vi har en tydeligere plan enn hva vi hadde tidligere. Brukerne, representantene, kunden og bekkere jobber mot det samme målet, og det gjør det både lettere å samarbeide og det er mye mer motiverende når alle tar del i retningen produktet skal ta. Det er givende å se at vi leverer verdi til brukerne sammen, og dette igjen styrker samholdet i teamet. Alle fagområder er inkludert i de ulike møtepunktene og kommunikasjonsverktøyene, og det har gjort utviklerne og designer(ne) tryggere i kundemøter når vi vet at hvert fagfelt er representert. Ikke minst tar vi del i prioriteringsmøtene med kunde og representantene. Hver måned har vi også retroer, ett med produktteamet og ett hvor vi også har med representantene. I produktteam-retroen går vi også gjennom prosesstiltak og følger opp dem.


Vi deployer selv! Nå har vi mulighet til å rulle ut nye endringer når vi vil, samt trekke de tilbake. Ulempen med færre deploys er at vi kan glemme hva som ble lagt ut og sjansen er større for å ikke kunne klare å rette opp i eventuelle feil som oppstår. Når vi har raske deploys kan vi legge ut endringer når vi (utviklere og designere) er klare, og være mer på hugget til å fikse ting.


Utviklingsteamet har også i denne perioden jobbet med et felles designbibliotek og satt designet i system. Selve designet har også utviklet seg og tilnærmet seg i større grad hvordan komponenter bygges i kode. Ved at jeg har hatt et tett samarbeid med utviklerne har vi sammen funnet bedre måter å bygge designet på. Verdien av dette er at utviklerne og designerne nå snakker det samme språket, og det blir enklere å forutse noen av de tekniske avhengighetene og vi får en felles forståelse av prinsippene til designet og koden.


→ Neste nye på listen er teambuilding i februar med produktteamet og de regionale representantene, og det gleder vi oss til.




Stor takk for bidrag til artikkelen av Håkon Teigen Lund, Niklas Molnes Hole, Maia Elisabeth Sirnes og Ingrid Hjulstad!

Fra fossefall til kontinuerlig leveranse

Want to add those nice-looking link previews you get when you share a link on Medium or Twitter? Then this article is for you!

The concept of unfurling links – that is, showing a link with a preview image, the title of the page and a short description – is becoming a pretty popular feature on lots of sites these days. But how can you add it to your Sanity blog?

In this article, we will show you a quick and easy way to add this neat little feature in no time at all!

Create a custom block type

First, we need to add a new custom type to our document schema. It's pretty straight forward - with a single URL prop:

Next, you need to add this to your block type field (like the content field of your blog post type):



You can now add links to your content - but they won't show up like they should just yet.

Adding OpenGraph Ninja

Unfurling URLs is pretty straight forward. You make a request to the page, parse the response, and select some of the metadata tags. Some pages add something called "open graph" metadata, which makes these previews even better!

We could implement this ourselves, but let's just use a small service that does this for us - OpenGraph Ninja. Hei

Full disclosure – I made and maintain OpenGraph Ninja – so I'm obviously super biased over how great this tool is. But give it a try before you discard it completely!

OpenGraph Ninja even comes with a handy ready-made React library, which makes using this service a breeze. Let's start using it right inside of Sanity!

Navigate to your studio, and install the OpenGraph Ninja dependency:



Next, let's add a preview component to our unfurl schema definition!

That's a few changes, so let's go through them one by one. First we import the PreviewLink component and its required CSS styles. You can of course write your own styles if you want, but let's leave that as an exercise to the reader.

Oh, and note that you have to add ?raw to the end of the style import - that's a Sanity-specific thing you can read more about here.

We've also added a preview section, where we pass in the preview component, and pass in the url as a prop. Now we get a real nice-looking preview in our editor, too!

Showing it to our users

Unfortunately, even with all this work, our users won't know a thing – so let's add some support for our new custom unfurler.

Now, this next part depends on what kind of technology you're using on your end. In this guide, we'll assume you're using the @sanity/block-content-to-react package. Let's visit your imaginary features/PortableText.jsx file:



All we're really adding here, is the way we deserialize the unfurledUrl content type. We're using the same preview component here, but you might want to create your own implementation with the provided usePreviewData hook instead.

Either way, the result is sure to look amazing. Here's a link to bekk.christmas:

Improve your own links!

Now you've seen the quick and easy way to implement unfurling of links. We cheated a bit, by using a (free) service and its provided React SDK, but you can implement something pretty similar yourself if you have the time.

This article was actually written while implementing this functionality for this website, so rest assured it's built on real world experience!

I hope you enjoyed this article - and if you did, give opengraph.ninja a chance!

9-Dec

Today's posts

Combining OCAI and The Three Cultures Model

Brannfakkel - Er godt eksekvert fossefall bedre enn dårlig eksekvert smidig? (Del 3 av 6)

ClickRelief - click without clicking!

Fra fossefall til kontinuerlig leveranse

Implementing unfurling URLs in Sanity