"I couldn't find a funny quote about navigating structured content." - Kristoffer Æsøy (2023)

The structure we all know and... love?

A common sight for anyone who’s worked with Sanity is the structure of their Studio. This is the map of all the content that exists in your content lake. What you see is what you… have! The thing about maps is that they get harder to read the bigger the area they try to cover. The same is true about navigating your content lake in Sanity! Maybe you’re looking for a movie you put in but you can’t really remember the title, just that it was a thriller. 🎃

We start off by taking a look at what Sanity gives us out-of-the-box:

The first step to making it easier to navigate is to ditch the default. To its credit, it shows you all the content that is available in your content lake. But, the documents for each type are all in one long list, which can be a nightmare to navigate if you have a lot of documents 😖. Also, it just looks kinda boring... snore! 💤

Adding som ✨style✨

To ease us into it, we can recreate the default structure we saw in the image above, but make it a bit more hip and fresh 😎. Let's spice it up a bit by adding an icon to each of our lists of document types. Cuz, people like looking at pictures, you know?

To do this we need to get down to business with the Structure builder API, which handles all things studio structure. If you want a custom structure you'll need to create a StructureResolver function, which is a function that accepts Sanity's structure builder class, commonly referred to as S. 

Using this builder class you can chain ⛓️ its methods to customize your studio's structure! We begin by defining the root of the structure as a list, where each of our document types are separate entries that we can add a title and a icon to by chaining methods onto the listItem method.

When we want something to be displayed in a new pane we use the child method, and inside it we can create a new list that simply displays all our documents. There exists a documentTypeList that only shows the documents matching the type you give it, which is super convenient.

Here it is:

Having defined our custom structure, we need to tell our Sanity project to use this when we are in the studio. The structure is set using Sanity's deskTool plugin, which is already included in the config when we create a new project! Replacing the default one with ours is super simple, its just about setting the structure field:

And voilá, let's check out how our Studio looks like with our new custom structure:

Filters, turning our Studio into the 'gram

Already looking a lot better! Now, we have what we need to solve the actual issue at hand. How can we more easily navigate all the different movies we have? Let's assume that we have three genres of movies: comedy, drama and thriller. We can create filters that separate our movies into those three genres!

The filter method can be applied to any type of list you can find in the structure builder class. It accepts a GROQ query to filter documents, which you will be familiar with since it's the same tool use we in our frontends to fetch content from Sanity.

An important thing to note is that when you apply a filter to a documentTypeList you actually end up overriding the method's default filter, meaning that you'll have to filter by the document type in your query as well. Now it doesn't make much sense to use that method anymore right? Therefore we can replace it with the more generic documentList and filter that instead!

This is how we make our filters for movie genres: 

Cool! It's time to take a look at how it turned out in the studio:

Magnifique, now we can more easily find our movies when we know their genre and how sweet aren't those icon! Chef's kiss. 🤌

♻️ Recycling ♻️ our filters

Okay, we have filters for our movies, but maybe we wanna add some filters to our books and shows as well. 🤔 Perhaps all of them share the exact same genres, and then we would end up creating the exact same filters for all of them by just replacing the document type we filter by... 😅 I don't know about you, but I think the single filter above makes the structure file a lot less readable, and adding more of almost identical code wouldn't really be of any help. Maybe we can create some kind of function that accepts a type, and creates the genre filters for us!

Again, if we want to create a function that can access the structure builder API methods, we need it to accept S, the structure builder class. Then we can also accept the type we want to filter by making it able to filter any document type by genre, even though it only makes sense to do so if a type has a genre field 😄.

Let's look at our final structure file now that we have created a custom function to filter our document types based on genre:

Talk about a clean structure huh? Now it's super obvious that we are using the same approach to create our genre filters for each of our document types. If someone is curious as to how those filters are created they can just check that function in isolation, and change it to apply an update to all our document types at once.

All that remains is to check if it worked:

Boom, there we have it! 🤩

You're good to go 🤙

And that's all folks! Now you've been introduced to all the building blocks you'll need to create helpful, reusable filters for your Sanity Studio. You can take this much farther but this is a great step in improving the navigation of your studio, and writing more DRY code!

Thanks for your time, and good luck finding the structure that works for you 👋

Creating the map of your Sanity Studio

I've tried out FusionCache and really liked it so I wrote this article to show you how to use their failsafe caching mechanism.

I've been working on an application that relies on data from an external service to work. We used to cache the data with IMemoryCache but had some problems as the external service was a bit unreliable. The data we were using was crucial for our application to make sense and so if the external service shut down for some reason so would our application. We tried caching for longer, but then again you don't want outdated data to stick around for too long.



When we found FusionCashe we realized that it solved all of our problems 🤩



FusionCache lets you do failsafe caching, meaning that if it receives an error it will continue to use the old data for as long as you want while retrying the request.



Here is an example of how we have used it in our code base

This means that we cache for 6 hours at a time before refreshing our cache. If our external service is unavailable it will keep the old data for up to 7 days while retrying fetching data every 5 minutes.



FusionCache also have many more features that might suite your needs. I highly recommend checking it out. Check out the link below

Failsafe caching in dotnet with ZiggyCreatures Fushion Cashe

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





Hvem er jeg?

Navn: Loritha Isabel Juario

Alder: 36 år

Fra: Sarpsborg

Studerte Reklame og merkevarebygging på NKF, hoppet av da jeg kom inn på Art Direction ved "gamle" Westerdals, og fylte på med ett år Interaksjonsdesign og brukervennlighet i ettertid.

Jobbet som designer i 11 år

Det er ganske tilfeldig at jeg ble designer, jeg hadde ikke klart for meg hva jeg var dyktig i, eller likte å gjøre. Jeg gikk idrett på vgs med mindre imponerende karaktersnitt da jeg var ferdig. Endte opp på friluftsliv folkehøyskole for å finne meg sjæl, og deretter endte opp med å studere Art Direction. Mange tror kanskje det er langt unna det jeg gjør i dag ved å være konsulent i IT-bransjen. Men Art Direction handler om konseptutvikling, strategi og hvordan jobbe i team for å bygge noe, og det er nettopp det jeg jobber med. 

Hva gjør jeg?

Hva jobber du med for tiden? 

Jeg jobber i et mega stort team man kan beskrive som et lite AS, som prøver å bygge ny saksbehandlingsløsning for ytelsen dagpenger i NAV. Ved siden av jobb er jeg i et masterløp som heter Digitalisering og ledelse på UiO.


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

Overtid er sjeldent verdt det

Begynn på et personlig prosjekt utenfor jobb og følg utviklingen

Dra på så mange utenlandskonferanser arbeidsgiveren din tillater

Hva eller hvem inspirerer deg?

Akkurat nå er det å være student i et erfaringsbasert masterløp veldig inspirerende. Jeg blir super engasjert av å diskutere med medstudenter fra ulike bransjer med mange års erfaring, og ikke minst høre dyktige professorer snakke om faget sitt. Men inspirasjon for meg kommer ikke så ofte fra et faglig ståsted. Jeg sluker sportsdokumentarer med eksepsjonelle prestasjoner; hæsjtagg Jordan, eller hører på begavede musikkprodusenter hæsjtagg Metro Boomin, eller ser på insane god fiction hæsjtagg Christopher Nolan. Dyktige folk er generelt en inspirasjonskilde for meg. 

Designdrypp med: Loritha Isabel Juario

Figma was intended to accelerate the process from idea to implementation, but are we actually slowing it down? Let's review that approach.

In this article, I start from the assumption that you are a designer, and using a design system, not building it. You also work in a team with developers and a product manager, and you and your team practice agile methodologies.

Design work: your responsibility as a designer

Traditionally, a designer's responsibility and role is ensuring the usability of the service or system built by their team. Yet, a less apparent aspect of this role involves striving for commercial viability. Whether in public or private sector, there should always be a means to measure the outcomes of an investment. Viability work is very challenging, if not the most. As design work is important in both innovation and maintenance, this work has to align with the intent of investment. In another way: make sure you get bang for the bucks.

That is why it’s important what you do, and how you do it. So let’s look at how you use Figma.

The true essence of Figma

Figma is a popular platform used by the designer or a team when designing digital products. The sketches and mockups within Figma serve only as a groundwork and platform for discussion for you, your team, and the product manager. The sketches aren't conclusive at all. Production is.

Production is the software that exists in the real world, and hopefully valuable for users. Investing time in aligning your sketches with production is unnecessary. Considering fixing your sketches post-production highlights that Figma lags behind. And revisiting old aspects is similar to what developers term as debt. Sketches are sketches, not technical debt. They don't require tidying up because they are only a shared understanding and common ground at a specific time, place, and focus. Nor is it documentation or an "experience transfer" to someone else. Continuously tidying up sketches is an endless task that keeps you occupied but doesn't contribute to adding real value.

The implementation of a new feature occurs within the scope of production, with your team. My most significant advice is to communicate with your team every day. Ensure you’re on the same Figma page ;-) As long as you do, your sketches are totally fine not being picture-production-perfect. Do you struggle with messy sketches that don’t resemble those on Dribbble? Excellent! That's an indication of using Figma as intended. It merely represents and materializes current thoughts and ideas, a canvas for ideation. Spending excessive time refining sketches and redesigning Figma prototypes to match production indicates misdirected efforts. Strive to create great and beautiful design, but remember: do the work that needs doing.

I would recommend reading an insightful article by my colleague, Ragnhild Liven, who shares a similar perspective on prototypes: kill it.

Your work's fidelity matters

By now, you might be thinking: "but this does not apply to me." Maybe it doesn’t, or maybe it does, and you just don’t want to admit it.

Fidelity in design often refers to the accuracy to an original or intended design. It can include the level of detail, accuracy, or fidelity to the original concept. I believe that the need for fidelity matters in relation to how closely you work with your team, how "agile you are," and the self-evident platitude: it depends. Of course. Designing a system for critical operations within e.g. health, taxes, or military operations have different requirements. So, this does not apply to all.

However, if you are working in a well functional team and have this mindset, you want to be working within that bottom-left area.

The Figma paradox

Figma was designed to facilitate the swift design of digital products and solutions, and undoubtedly, it accomplishes this goal. However, as Figma evolves, I observe tendencies toward unnecessary complexity, at least among its users. Figma incorporates features previously exclusive to code, such as styling, variables, variants, components, and tokens. Don't misunderstand; this incorporation is fantastic and bridges the gap between code and design. Yet, it often tempts users to delve into unnecessary details where they really shouldn’t. This behaviour isn't due to the system compelling us, but rather because we find it challenging to resist. This is common with all tools.

Realistic, functional prototypes aren’t viable unless Figma is transitioning to a no-code platform that pushes high-fidelity sketches directly to production. It’s essential to maintain the right level of complexity, allowing sketches to be a common ground for the team, and serving the purpose as food for thought.

The Figma Paradox

Digitale tjenester er ikke så miljøvennlige som vi liker å tro. Selvsagt er det en fordel at vi erstatter prosesser som tidligere baserte seg på papir som ble sendt frem og tilbake med et digitalt system, men det er ikke utslippsfritt av den grunn. Vi har skrevet tidligere om hvordan IT-bransjen står for like store utslipp som flybransjen, og med veksten i bruk av kunstig intelligens tyder alt på at utslippene vil vokse videre.

Å gripe fatt på en så stor utfordring som å stanse klimakrisen kan føles umulig. Men heldigvis gjør mange bekker små en stor å. Hvis alle gjør litt vil det få mye å si i det store bildet. Så her er tre enkle ting du kan gjøre for å gjøre nettsiden din mer miljøvennlig!

1. Reduser bildestørrelsen

En av de største årsakene til utslipp er overføring av store datamengder. For de fleste nettsider er det bildene som utgjør størstedelen av data som må overføres til brukeren. Men alt for ofte har vi ikke optimalisert størrelsen på disse bildene. Vi har enten bare beholdt størrelsen på bildet som vi fikk tilsendt, eller vi har redusert det til en størrelse vi tror er riktig.

Den raskeste måten å finne riktig størrelse på bildet er rett og slett å prøve seg litt frem. Reduser størrelsen på bildet med 50% og se om du synes kvaliteten fortsatt er bra nok. Fortsett med det helt til du når grensen for hva som er bra nok. Husk å teste på både mobil og store skjermer.

Hvis du vil gå et hakk lenger avgjør du hvilken størrelse bilde du skal sende til brukeren basert på størrelsen på skjermen deres. Her finnes det til og med innebygget støtte i img-tagen. Du kan angi en rekke bildeURLer i srcset-attributtet og la nettleseren velge riktig bilde basert på skjermstørrelse eller pixeltetthet.

2. Ikke last inn innhold før det trengs

Det er lett å tenke at det beste for brukeren er at vi leverer alt innhold til dem med en gang sånn at det er tilgjengelig hvis de trenger det. Men det fører både til at vi bruker mye tid og energi på å overføre data som aldri vil blir brukt, og en tregere opplevelse for brukeren.

I stedet bør du sette opp nettsiden din slik at data overføres når de trengs. For javascript bør du bruke code splitting som deler opp javascript-koden din i flere filer som kan lastes når det er behov for dem. Dette støttes av både Webpack, ParcelJS og de fleste moderne systemer som pakker kode for web.

Har du video på nettsiden din bør du ikke automatisk spille den av, og vente med å laste den til brukeren faktisk har vist at de ønsker å se den.

3. Bruk standardfonter

Det finnes mange kule fonter der ute, og å bruke en spesiell font kan få merkevaren din til å skille seg ut. Men i mange tilfeller trenger vi ikke noen spesiell font, vi klarer oss helt fint med de fontene som er installert på maskinen til brukeren. Ved å bruke gode gamle Arial, Helvetica, Times New Roman eller en annen standardfont slipper brukeren å laste ned en ekstra font bare for å vise nettsiden din. Kanskje blir nettsiden din nesten akkurat like fin!

7-Dec

Today's posts

Creating the map of your Sanity Studio

Failsafe caching in dotnet with ZiggyCreatures Fushion Cashe

Designdrypp med: Loritha Isabel Juario

The Figma Paradox

3 enkle ting som gjør nettsiden din mer miljøvennlig