Guides

Sådan bygger du en changelog-side: poster, tags, RSS og „Nyt“

En changelog-side er en dateret liste over, hvad der er ændret i dit produkt, nyeste først, skrevet til de mennesker, der bruger det. For at bygge en har du brug for poster med en dato, en klar titel, en kort forklaring og et tag (Nyt, Forbedret, Rettet), en side, der lister dem, en separat URL pr. post og helst et RSS-feed og en måde at fortælle brugerne, at noget er nyt. Det er en af de enkleste ting, du kan bygge, og den vigtigste beslutning er, hvor posterne ligger: som filer på din side eller i en database med en admin-side.

Hvorfor en changelog er værd at have

En changelog viser kunder og potentielle kunder, at produktet bliver vedligeholdt. Den giver support og salg et link at sende, når nogen spørger „kan den gøre X endnu?“. Den er også et sted at lukke feedback-løkken: når en efterspurgt funktion udgives, er det changelog-posten, du peger folk hen på. Hvis du kører et kundefeedbackportal, så link udgivne forespørgsler direkte til deres poster.

En changelog er ikke din interne commit-historik. „Refaktoreret faktureringstjeneste“ betyder intet for en bruger. „Fakturaer viser nu din virksomheds momsnummer“ gør.

Hvad siden har brug for

Indhold for hver post

FeltBemærkninger
TitelHvad der ændrede sig, set fra brugerens perspektiv
DatoUdgivelsesdato, vist på siden
TagNyt, Forbedret, Rettet (og måske Fjernet eller Sikkerhed)
BrødtekstEt par sætninger eller punkter; hvordan man bruger det, hvem der får det
Billede eller videoValgfrit; et skærmbillede hjælper mere end et afsnit
SlugPostens URL, som /changelog/invoice-vat-numbers
StatusKladde eller udgivet, plus en planlagt udgivelsesdato, hvis nødvendigt

Sider

  • Changelog-indeks: nyeste først, med tagfiltre og enkel paginering eller „indlæs flere“.
  • Postside: én post pr. URL, så den kan linkes og deles.
  • RSS- eller Atom-feed: lader folk og værktøjer følge opdateringer uden e-mail.
  • Admin-side (kun i databaseversionen): skriv, forhåndsvis, planlæg og udgiv poster.

Ekstra funktioner i appen

  • „Nyt“-mærke: en prik på et menupunkt, når der er poster, brugeren ikke har set. Gem datoen for den sidste post, de åbnede, pr. bruger eller i browseren.
  • E-mailoversigt: en oversigt sendt til brugere, der har tilmeldt sig. Det kræver en udbyder til udsendelse; se sådan sender du e-mails fra din app.

Den vigtigste beslutning: filer eller database

Poster som filer på siden

Hver post er en Markdown-fil i projektet. At udgive en post betyder at tilføje en fil og lave en ny udrulning. Det er den enkleste og mest robuste tilgang: ingen database, ingen admin-login, intet at sikre, og siderne kan præ-renderes, så de indlæses hurtigt og er nemme for søgemaskiner at læse.

Den passer til teams, hvor de, der skriver poster, er trygge ved at bede en AI-builder om hjælp eller redigere en fil.

Poster i en database med en admin-side

Poster ligger i en tabel, og en privat admin-side lader alle i teamet skrive, forhåndsvise, planlægge og udgive. Det passer til teams, hvor marketing eller support skriver opdateringer, eller hvor du vil have planlagt udgivelse eller poster pr. målgruppe (fx kun at vise virksomhedsfunktioner til virksomhedskunder).

Omkostningen er mere at bygge og vedligeholde: et admin-login, billedupload og at sikre, at de offentlige sider stadig kan læses af søgemaskiner, hvilket en side, der kun indlæser poster i browseren, måske ikke kan.

FilerDatabase + admin
Hvem kan udgiveEnhver, der redigerer projektetAlle med et admin-login
OpsætningMinimalLogin, lagring, admin-grænseflade
SEONemt (præ-renderede sider)Kræver omhu, så siderne renderes på serveren eller præ-renderes
PlanlægningUdgiv når du udrullerKan planlægges efter dato
HostingomkostningStatiskKræver en kørende app og database

At skrive poster, folk læser

  • Start med fordelen. „Eksporter rapporter til Excel“ slår „Nyt eksportmodul“.
  • Sig, hvem der får det. Alle planer, kun Pro, rulles ud denne uge.
  • Vis det. Ét skærmbillede eller en kort klip.
  • Saml små rettelser. En ugentlig post „Rettelser og forbedringer“ med punkter forhindrer, at siden oversvømmes.
  • Vær ærlig om fjernelser. Hvis noget udfases, så sig hvornår og hvad man skal bruge i stedet.

En første prompt, der virker

Tilføj en offentlig changelog til vores side på /changelog. Hver post er en Markdown-fil med en titel, dato, tag (Nyt, Forbedret eller Rettet), valgfrit coverbillede og brødtekst. Indekssiden lister poster, nyeste først, med dato, tag og første afsnit, har tagfilterknapper og viser 10 poster pr. side. Hver post har sin egen side på /changelog/<slug> med en ordentlig sidetitel og beskrivelse til søgemaskiner. Tilføj et RSS-feed på /changelog/rss.xml. Opret tre eksempelposter. Tilpas det eksisterende sidedesign, hold det læsbart på telefoner, og præ-render siderne, så de indlæses hurtigt.

Til databaseversionen erstatter du den første sætning med „Gem poster i en database med kladde/udgivet-status og en udgivelsesdato, og tilføj en adgangskodebeskyttet admin-side til at skrive, forhåndsvise og udgive dem.“

Byggetrin

  1. Beslut filer eller database ud fra tabellen ovenfor.
  2. Byg indeks- og postsiderne med nogle få eksempelposter.
  3. Tilføj tags og filtre.
  4. Tilføj RSS-feedet og link til det fra siden.
  5. Tilføj sidetitler, beskrivelser og en sitemap-post for hver post. Vores guide til SEO for AI-byggede hjemmesider dækker grundlaget.
  6. Admin-side og login, hvis du valgte databaseruten.
  7. „Nyt“-mærke i din app.
  8. Skriv rigtige poster for de sidste par måneder, så siden ikke lanceres tom.

Almindelige fejl

  • At kopiere commit-beskeder. Skriv til brugere, ikke udviklere.
  • Én stor side uden poster-URL'er. Ingen kan linke til en bestemt ændring, og søgemaskiner ser én side i stedet for mange.
  • Opdateringer stopper efter en måned. En changelog, der sidst blev opdateret for et år siden, antyder et forladt produkt. Sæt en rytme, du kan holde.
  • Indlæsning af poster kun i browseren. Søgemaskiner og linkeksempler ser måske en tom side. Præ-render eller render på serveren.
  • At blande driftsforstyrrelser ind. Nedbrud hører hjemme på en statusside, ikke i changelog'en.

Hvornår et hostet changelog-værktøj er det bedre valg

Der findes hostede changelog- og produktopdateringsværktøjer, og nogle følger med feedback-boards eller widgets i appen. De er værd at bruge, hvis du vil have pop-ups i appen, målgruppemålretning og analyse uden selv at bygge det, eller hvis dit team allerede betaler for et værktøj, der inkluderer en. Din blog- eller hjælpecenter-software har måske også et passende format.

At bygge din egen giver mening, når du vil have changelog'en på dit eget domæne, i dit eget design og fuldt indekserbar, hvilket for en simpel liste med daterede opslag ikke er meget arbejde.

At bygge det med Mythex

På Mythex kan du bede agenten om at tilføje en changelog til et eksisterende projekt eller bygge den som et lille selvstændigt site, og se den i live-forhåndsvisningen, mens den bygges. Filversionen kræver ingen database. Hvis du vælger admin-versionen, tilføjer agenten en dedikeret Postgres-database, når poster skal gemmes (eller skriv /database), og skærmbilleder lægges i projektets filslager. Admin-login tilføjer du selv med din egen auth-tilgang (opskrift på tilføjelse af login).

Nye Mythex-apps er ofte klientrenderede single-page apps, hvilket SEO-opskriften bemærker er svagere til søgning, så bed om statiske eller præ-renderede changelog-sider, hvis du vil have poster fundet i søgning. Den samme opskrift dækker titler, beskrivelser og sitemaps. Til en startskabelon med en indbygget changelog, se produktvidensbase-skabelonen.

Spørgsmål

Hvad bør en changelog-post indeholde?

En dato, en kort titel, der siger, hvad der ændrede sig for brugeren, et par sætninger eller punkter, der forklarer det, et tag som Nyt, Forbedret eller Rettet, og eventuelt et skærmbillede og et link til mere detaljeret information.

Har en changelog brug for en database?

Ikke nødvendigvis. Hvis en eller to personer udgiver opdateringer, kan poster ligge som Markdown-filer på siden og blive udgivet ved hver udrulning. Brug en database, når ikke-tekniske personer skal skrive og planlægge poster fra en admin-side.

Hvor ofte bør jeg opdatere en changelog?

Når noget, brugerne ville bemærke, har ændret sig. Mange små produkter samler ændringer ugentligt eller hver anden uge; det vigtige er en stabil rytme, så siden virker levende.

Er en changelog god til SEO?

Den kan hjælpe lidt: hver post er en crawlbar side om en funktion, og en regelmæssigt opdateret side signalerer et aktivt produkt. Giv hver post sin egen URL og en beskrivende titel.

Mythex · Pricing · Byg hvad som helst med AI · Skabeloner til websites og apps · Mythex sammenlignet · Ordliste for app-bygning med AI · Gratis værktøjer til app-bygning med AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)