Com crear una pàgina de canvis: entrades, etiquetes, RSS i «Novetats»

Una pàgina de canvis és una llista datada de tot el que ha canviat al teu producte, les més recents primer, escrita per a les persones que l'utilitzen. Per construir-ne una necessites entrades amb data, un títol clar, una explicació curta i una etiqueta (Nou, Millorat, Corregit), una pàgina que les llisti, una URL separada per a cada entrada i, idealment, un canal RSS i una manera d'avisar els usuaris que hi ha quelcom de nou. És una de les coses més senzilles que pots construir, i la decisió principal és on viuen les entrades: com a fitxers al teu lloc o en una base de dades amb una pàgina d'administració.

Per què val la pena tenir una pàgina de canvis

Una pàgina de canvis mostra als clients i als potencials clients que el producte es manté. Dona a suport i a vendes un enllaç per enviar quan algú pregunta «fa X ja?». També és un lloc per tancar el cicle de la retroalimentació: quan una funcionalitat sol·licitada arriba, l'entrada de la pàgina de canvis és el que els indiques. Si gestiones un portal de retroalimentació de clients, enllaça les sol·licituds ja implementades directament amb les seves entrades.

Una pàgina de canvis no és el teu historial interior de commits. «Refactoritzat el servei de facturació» no significa res per a un usuari. «Les factures ara mostren el número d'IVA de la teva empresa» sí.

Què necessita la pàgina

Contingut de cada entrada

Pàgines

• Índex de la pàgina de canvis: les més recents primer, amb filtres per etiqueta i paginació senzilla o «carrega'n més».
• Pàgina d'entrada: una entrada per URL, perquè es pugui enllaçar i compartir.
• Canal RSS o Atom: permet que la gent i les eines segueixin les actualitzacions sense correu.
• Pàgina d'administració (només a la versió amb base de dades): escriure, previsualitzar, programar i publicar entrades.

Extres dins de l'app

• Indicador de «novetats»: un punt en un element del menú quan hi ha entrades que l'usuari no ha vist. Desa la data de l'última entrada que ha obert, per usuari o al navegador.
• Resum per correu: un resum enviat als usuaris que s'hi han subscrit. Això necessita un proveïdor d'enviament; consulta com enviar correus des de la teva app.

La decisió principal: fitxers o base de dades

Entrades com a fitxers al lloc

Cada entrada és un fitxer Markdown al projecte. Publicar una entrada vol dir afegir un fitxer i tornar a desplegar. És l'enfocament més simple i robust: sense base de dades, sense inici de sessió d'administració, res a protegir, i les pàgines es poden pre-renderitzar perquè carreguin ràpid i els motors de cerca les llegeixin fàcilment.

Encaixa amb equips on les persones que escriuen les entrades estan còmodes demanant-ho a un constructor d'IA o editant un fitxer.

Entrades en una base de dades amb una pàgina d'administració

Les entrades viuen en una taula, i una pàgina d'administració privada permet a qualsevol de l'equip escriure, previsualitzar, programar i publicar. Encaixa amb equips on màrqueting o suport escriu les actualitzacions, o quan vols publicació programada o entrades per audiència (per exemple, mostrar les funcionalitats empresarials només als clients empresarials).

El cost és més construcció i manteniment: un inici de sessió d'administració, pujada d'imatges, i assegurar que les pàgines públiques continuen sent llegibles pels motors de cerca, cosa que una pàgina que només carrega les entrades al navegador potser no garanteix.

Escriure entrades que la gent llegeix

• Comença pel benefici. «Exporta informes a Excel» és millor que «Nou mòdul d'exportació».
• Digues a qui arriba. Tots els plans, només Pro, desplegant-se aquesta setmana.
• Mostra-ho. Una captura de pantalla o un clip curt.
• Agrupa les correccions petites. Una entrada setmanal de «Correccions i millores» amb punts evita que la pàgina s'inundi.
• Sigues honrat amb les eliminacions. Si alguna cosa desapareix, digues quan i què usar en el seu lloc.

Un primer prompt que funciona

Afegeix un registre públic de canvis al nostre lloc a /changelog. Cada entrada és un fitxer Markdown amb un títol, una data, una etiqueta (Nou, Millorat o Corregit), una imatge de portada opcional i el cos. La pàgina índex llista les entrades més recents primer amb la data, l'etiqueta i el primer paràgraf, té botons de filtre per etiqueta i mostra 10 entrades per pàgina. Cada entrada té la seva pròpia pàgina a /changelog/<slug> amb un títol de pàgina i una descripció adequats per als motors de cerca. Afegeix un canal RSS a /changelog/rss.xml. Crea tres entrades d'exemple. Segueix el disseny del lloc existent, mantén-ho llegible als telèfons i pre-renderitza les pàgines perquè carreguin ràpid.

Per a la versió amb base de dades, canvia la primera frase per «Guarda les entrades en una base de dades amb estat d'esborrany/publicada i una data de publicació, i afegeix una pàgina d'administració protegida amb contrasenya per escriure, previsualitzar i publicar-les».

Passos de construcció

1. Decideix entre fitxers o base de dades amb la taula de dalt.
2. Construeix la pàgina d'índex i les d'entrada amb unes quantes entrades d'exemple.
3. Afegeix etiquetes i filtres.
4. Afegeix el canal RSS i enllaça'l des de la pàgina.
5. Afegeix títols de pàgina, descripcions i una entrada al mapa del lloc per a cada entrada. La nostra guia sobre SEO per a llocs web creats amb IA cobreix els fonaments.
6. Pàgina d'administració i inici de sessió, si has triat la via de la base de dades.
7. Indicador de «novetats» a la teva app.
8. Escriu entrades reals dels últims mesos perquè la pàgina no es llanci buida.

Errors habituals

• Copiar els missatges de commit. Escriu per als usuaris, no per als desenvolupadors.
• Una pàgina gegant sense URL per entrada. Ningú pot enllaçar un canvi concret, i els motors de cerca veuen una pàgina en lloc de moltes.
• Les actualitzacions s'aturen al cap d'un mes. Una pàgina de canvis que no s'actualitza en un any suggereix un producte abandonat. Fixa un ritme que puguis mantenir.
• Carregar les entrades només al navegador. Els motors de cerca i les vistes prèvies d'enllaços poden veure una pàgina buida. Pre-renderitza-les o renderitza-les al servidor.
• Barrejar-hi incidències. Les interrupcions pertanyen a una pàgina d'estat, no a la pàgina de canvis.

Quan és millor una eina de canvis allotjada

Hi ha eines de canvis i d'actualitzacions de producte allotjades, i algunes vénen incloses amb taulers de retroalimentació o widgets dins de l'app. Valen la pena si vols un avís emergent dins de l'app, segmentació d'audiència i analítica sense construir-ho tu, o si el teu equip ja paga una eina que en inclou una. El teu programari de blog o de centre d'ajuda també pot tenir un format adequat ja fet.

Construir-ne una de pròpia té sentit quan vols la pàgina de canvis al teu propi domini, amb el teu propi disseny i totalment indexable, cosa que per a una llista simple de publicacions datades no és gaire feina.

Construir-ho amb Mythex

A Mythex pots demanar a l'agent que afegeixi una pàgina de canvis a un projecte existent o que la construeixi com un petit lloc propi, i veure-la a la vista prèvia en directe mentre es construeix. La versió basada en fitxers no necessita base de dades. Si tries la versió amb administració, l'agent afegeix una base de dades Postgres dedicada quan les entrades han de desar-se (o escriu /database), i les captures de pantalla es guarden a l'emmagatzematge de fitxers del projecte. L'inici de sessió d'administració és quelcom que afegeixes amb el teu propi enfocament d'autenticació (recepta d'inici de sessió).

Les noves apps de Mythex sovint són aplicacions d'una sola pàgina renderitzades al client, que la recepta de SEO indica que són més febles per a la cerca, així que demana pàgines de canvis estàtiques o pre-renderitzades si vols que les entrades es trobin a la cerca. La mateixa recepta cobreix títols, descripcions i mapes del lloc. Per a un punt de partida amb una pàgina de canvis integrada, consulta la plantilla centre de coneixement del producte.

Preguntes