Hvorfor vi forenklet Sanity-skjemaet: En redaktør-først-filosofi

Hvis du noen gang har administrert innhold i et tradisjonelt CMS, kjenner du følelsen av frykt når du åpner en sideredigerer. Dusinvis av felter, endeløse faner og mystiske avkrysningsbokser som ødelegger oppsettet hvis du klikker på dem feil. Utviklere bygger ofte disse systemene med de beste intensjoner, og tilbyr maksimal fleksibilitet. Men for redaktører er denne "fleksibiliteten" faktisk en byrde.

Paradokset med valg

Når utviklere lager skjemaer, er instinktet ofte å eksponere hver mulige CSS-egenskap som et felt. "Hva om de vil at bakgrunnen skal være blå? Eller rød? Eller en gradient? La oss legge til en fargevelger! Og en padding-slider! Og en margin-input!"

Dette fører til to store problemer:

1. Inkonsekvens: Merkeidentiteten din løses opp ettersom hver side ser litt forskjellig ut.

2. Kognitiv belastning: Redaktører bruker mer tid på å designe siden enn å skrive innholdet.

NextMedal-tilnærmingen: Beslutninsreduksjon

I dette prosjektet har vi tatt en radikalt annen tilnærming. Vi tror at skjemaet skal veilede redaktøren, ikke overvelde dem. Vi fokuserer på semantisk betydning fremfor visuell justering.

1. Semantiske komponenter, ikke visuelle primitiver

I stedet for en generisk "Boks"-komponent med 50 stilalternativer, tilbyr vi formålsbyggede moduler som "Callout" eller "Hero".

Her er hvor enkelt vårt Callout-skjema er. Legg merke til hvordan vi begrenser rik tekst-alternativene til nøyaktig det som gir mening for en callout—ingen tilfeldige fontstørrelser eller farger.

export default defineType({
  name: 'callout',
  title: 'Callout',
  type: 'object',
  fields: [
    defineField({
      name: 'content',
      title: 'Content',
      type: 'array',
      of: [
        {
          type: 'block',
          // We strictly limit styles to keep the design consistent
          styles: [
            { title: 'Normal', value: 'normal' },
            { title: 'Heading 2', value: 'h2' },
          ],
          marks: {
            decorators: [
              { title: 'Strong', value: 'strong' },
              { title: 'Emphasis', value: 'em' },
            ],
          },
        },
      ],
    }),
    defineField({
      name: 'ctas',
      title: 'Call-to-actions',
      type: 'array',
      of: [{ type: 'cta' }],
    }),
  ],
});

2. Smarte standarder og kollapsede kompleksitet

Vi vet at du noen ganger trenger avanserte alternativer. Men de skal ikke rote til hovedvisningen. Vi bruker fieldsets for å skjule avansert konfigurasjon som standard, og holder fokuset på innholdsskaping.

fieldsets: [
  {
    name: 'advanced',
    title: 'Advanced Options',
    options: { collapsible: true, collapsed: true }, // Hidden by default
  },
],
fields: [
  // ... core fields ...
  {
    ...createUidField(),
    fieldset: 'advanced', // Only visible if you need it
  },
],

3. Guardrails for designsystemintegritet

Vi bruker validering for å forhindre ødelagte oppsett før de skjer. For eksempel, i vår Hero-komponent, håndhever vi at du bare kan ha én "Primary"-knapp, noe som sikrer at brukerens oppmerksomhet rettes riktig.

defineField({
  name: 'ctas',
  validation: (Rule) =>
    Rule.max(2).custom((ctas) => {
      const primaryCount = ctas.filter(c => c.style === 'primary').length;
      if (primaryCount > 1) return 'Only one Primary button is allowed';
      return true;
    }),
})

Resultatet: Lykkeligere redaktører

Ved å ta bort byrden av designvalg, gir vi redaktører mulighet til å gjøre det de gjør best: skape flott innhold. De kan publisere raskere, vel vitende om at systemet vil håndtere presentasjonen perfekt hver gang.

Dette handler ikke bare om kode; det handler om respekt for brukeren. Et godt skjema er et empatisk skjema.