Come creare una pagina changelog: voci, tag, RSS e «Novità»

Una pagina changelog è un elenco datato di ciò che è cambiato nel tuo prodotto, dal più recente, scritto per le persone che lo usano. Per costruirne una servono voci con data, titolo chiaro, breve spiegazione e tag (Nuovo, Migliorato, Corretto), una pagina che le elenca, un URL separato per ogni voce, e idealmente un feed RSS e un modo per far sapere agli utenti che c'è qualcosa di nuovo. È una delle cose più semplici che puoi costruire, e la decisione principale è dove vivono le voci: come file nel sito, oppure in un database con una pagina di amministrazione.

Perché vale la pena avere un changelog

Un changelog mostra a clienti e potenziali clienti che il prodotto è mantenuto. Dà al supporto e alle vendite un link da inviare quando qualcuno chiede «fa già X?». È anche un modo per chiudere il cerchio sui feedback: quando una funzione richiesta viene rilasciata, la voce del changelog è ciò a cui indirizzi le persone. Se gestisci un portale di feedback dei clienti, collega direttamente le richieste completate alle loro voci.

Un changelog non è la cronologia dei commit interni. «Refactoring del servizio di fatturazione» non dice nulla a un utente. «Le fatture ora mostrano il numero di partita IVA della tua azienda» sì.

Di cosa ha bisogno la pagina

Contenuto di ogni voce

Pagine

• Indice del changelog: dal più recente, con filtri per tag e paginazione semplice o «carica altro».
• Pagina della voce: una voce per URL, così può essere collegata e condivisa.
• Feed RSS o Atom: permette alle persone e agli strumenti di seguire gli aggiornamenti senza email.
• Pagina di amministrazione (solo nella versione con database): scrivere, visualizzare in anteprima, programmare e pubblicare le voci.

Extra nell'app

• Badge «Novità»: un puntino su una voce di menu quando ci sono voci che l'utente non ha ancora visto. Memorizza la data dell'ultima voce aperta, per utente o nel browser.
• Riepilogo via email: un sommario inviato agli utenti che hanno scelto di riceverlo. Serve un fornitore di invio; vedi come inviare email dalla tua app.

La decisione principale: file o database

Voci come file nel sito

Ogni voce è un file Markdown nel progetto. Pubblicare una voce significa aggiungere un file e rifare il deploy. È l'approccio più semplice e robusto: nessun database, nessun login di amministrazione, niente da proteggere, e le pagine possono essere pre-renderizzate, quindi si caricano in fretta e sono facili da leggere per i motori di ricerca.

Va bene per i team in cui chi scrive le voci è a suo agio nel chiedere a un app builder AI o nel modificare un file.

Voci in un database con pagina di amministrazione

Le voci vivono in una tabella, e una pagina di amministrazione privata permette a chiunque nel team di scrivere, visualizzare in anteprima, programmare e pubblicare. È adatto ai team in cui marketing o supporto scrivono gli aggiornamenti, o quando vuoi la pubblicazione programmata o voci per pubblico diverso (per esempio, mostrare le funzioni enterprise solo ai clienti enterprise).

Il costo è più lavoro da costruire e da gestire: un login per l'amministrazione, il caricamento di immagini e la garanzia che le pagine pubbliche restino leggibili dai motori di ricerca, cosa che una pagina che carica le voci solo nel browser potrebbe non garantire.

Scrivere voci che le persone leggono

• Parti dal beneficio. «Esporta i report in Excel» batte «Nuovo modulo di esportazione».
• Dichiara a chi è destinata. Tutti i piani, solo Pro, in distribuzione questa settimana.
• Mostrala. Uno screenshot o un breve video.
• Raggruppa le piccole correzioni. Una voce settimanale «Correzioni e miglioramenti» con punti elenco evita che la pagina venga invasa.
• Sii onesto sulle rimozioni. Se una funzione sta per essere eliminata, dì quando e cosa usare al suo posto.

Un primo prompt che funziona

Aggiungi al nostro sito un changelog pubblico su /changelog. Ogni voce è un file Markdown con titolo, data, tag (Nuovo, Migliorato o Corretto), immagine di copertina facoltativa e testo. La pagina indice elenca le voci dalla più recente, con data, tag e primo paragrafo, ha pulsanti di filtro per tag e mostra 10 voci per pagina. Ogni voce ha una pagina propria su /changelog/<slug> con un titolo e una descrizione per i motori di ricerca. Aggiungi un feed RSS su /changelog/rss.xml. Crea tre voci di esempio. Adatta il design del sito esistente, mantieni la leggibilità sul telefono e pre-renderizza le pagine così si caricano in fretta.

Per la versione con database, sostituisci la prima frase con «Memorizza le voci in un database con stato bozza/pubblicata e una data di pubblicazione, e aggiungi una pagina di amministrazione protetta da password per scriverle, visualizzarle in anteprima e pubblicarle».

Passi di costruzione

1. Scegli file o database usando la tabella sopra.
2. Costruisci la pagina indice e le pagine delle voci con alcune voci di esempio.
3. Aggiungi tag e filtri.
4. Aggiungi il feed RSS e collegalo dalla pagina.
5. Aggiungi titoli di pagina, descrizioni e una voce nella sitemap per ogni voce. La nostra guida SEO per siti creati con l'AI copre le basi.
6. Pagina di amministrazione e login, se hai scelto il percorso con database.
7. Badge «Novità» nella tua app.
8. Scrivi voci reali degli ultimi mesi, così la pagina non nasce vuota.

Errori comuni

• Copiare i messaggi di commit. Scrivi per gli utenti, non per gli sviluppatori.
• Un'unica pagina enorme senza URL per voce. Nessuno può collegarsi a una modifica specifica, e i motori di ricerca vedono una pagina invece di tante.
• Gli aggiornamenti si fermano dopo un mese. Un changelog fermo da un anno suggerisce un prodotto abbandonato. Fissa un ritmo che riesci a mantenere.
• Caricare le voci solo nel browser. I motori di ricerca e le anteprime dei link potrebbero vedere una pagina vuota. Pre-renderizza o renderizza sul server.
• Mescolare gli incidenti. Le interruzioni appartengono a una pagina di stato, non al changelog.

Quando uno strumento di changelog ospitato è la scelta migliore

Esistono strumenti ospitati per changelog e aggiornamenti di prodotto, alcuni inclusi in bacheche di feedback o widget in-app. Valgono la pena se vuoi un popup in-app, il targeting per pubblico e le analisi senza costruirli, oppure se il tuo team paga già uno strumento che li include. Anche il software per blog o per il centro assistenza potrebbe avere già un formato adatto.

Costruire il tuo ha senso quando vuoi il changelog sul tuo dominio, nel tuo design, e completamente indicizzabile: per un semplice elenco di post datati non è molto lavoro.

Costruire con Mythex

Su Mythex puoi chiedere all'agente di aggiungere un changelog a un progetto esistente, oppure di costruirlo come piccolo sito a sé, e vederlo nell'anteprima dal vivo mentre viene costruito. La versione basata su file non richiede un database. Se scegli la versione con amministrazione, l'agente aggiunge un database Postgres dedicato quando le voci devono essere salvate (oppure digita /database), e gli screenshot vanno nello storage file del progetto. Il login di amministrazione lo aggiungi tu con l'approccio di autenticazione che preferisci (ricetta per il login).

Le nuove app Mythex sono spesso single-page app renderizzate lato client, che la ricetta SEO indica come meno efficaci per la ricerca, quindi chiedi pagine del changelog statiche o pre-renderizzate se vuoi che le voci vengano trovate nella ricerca. La stessa ricetta copre titoli, descrizioni e sitemap. Per un punto di partenza con un changelog già incluso, vedi il template product knowledge hub.

Domande