Hogyan építs változásnapló-oldalt: bejegyzések, címkék, RSS és „Újdonságok”

A változásnapló-oldal a termékben történt változások dátumozott listája, a legújabbal elöl, a termék felhasználóinak írva. Megépítéséhez kellenek bejegyzések dátummal, világos címmel, rövid magyarázattal és címkével (Új, Javított, Hibajavítás), egy oldal, amely listázza őket, bejegyzésenként külön URL, és ideális esetben RSS-hírcsatorna és mód arra, hogy értesítsd a felhasználókat az újdonságról. Ez az egyik legegyszerűbb dolog, amit építhetsz, és a fő döntés az, hol élnek a bejegyzések: fájlokként a weboldaladban, vagy adatbázisban admin oldallal.

Miért érdemes változásnaplót vezetni

A változásnapló megmutatja a vásárlóknak és az érdeklődőknek, hogy a termék karban van tartva. Linket ad a support és az értékesítés kezébe, ha valaki azt kérdezi: „tud már X-et?”. Visszacsatolási hurkot is zár: amikor egy kért funkció megjelenik, a változásnapló-bejegyzés az, amire rámutathatsz. Ha ügyfél-visszajelző portált építesz, a megvalósult kéréseket közvetlenül a bejegyzéseikhez kösd.

A változásnapló nem a belső commit-történet. A „Billing szolgáltatás refaktorálása” semmit nem jelent a felhasználónak. A „A számlákon mostantól megjelenik a cég adószáma” viszont igen.

Mire van szüksége az oldalnak

Tartalom bejegyzésenként

Oldalak

• Változásnapló-főoldal: a legújabbal elöl, címkeszűrőkkel és egyszerű lapozással vagy „további betöltése” gombbal.
• Bejegyzésoldal: bejegyzésenként egy URL, hogy linkelhető és megosztható legyen.
• RSS vagy Atom hírcsatorna: lehetővé teszi, hogy az emberek és az eszközök e-mail nélkül kövessék a frissítéseket.
• Admin oldal (csak az adatbázisos változatban): bejegyzések írása, előnézete, ütemezése és közzététele.

Az appon belüli kiegészítők

• „Újdonságok” jelvény: egy pötty a menüpont mellett, ha van olyan bejegyzés, amelyet a felhasználó még nem látott. Tárold el a legutóbb megnyitott bejegyzés dátumát felhasználónként vagy a böngészőben.
• E-mail-összefoglaló: egy összefoglaló, amelyet a feliratkozott felhasználóknak küldesz. Ehhez e-mail-küldő szolgáltató kell; lásd: hogyan küldj e-maileket az appodból.

A fő döntés: fájlok vagy adatbázis

Bejegyzések fájlokként a weboldalban

Minden bejegyzés egy Markdown-fájl a projektben. Bejegyzés közzététele azt jelenti, hogy fájlt adsz hozzá, és újratelepítesz. Ez a legegyszerűbb és legmegbízhatóbb megközelítés: nincs adatbázis, nincs admin bejelentkezés, nincs mit biztosítani, és az oldalak előre renderelhetők, így gyorsan töltődnek és a keresőmotorok könnyen olvassák őket.

Olyan csapatoknak való, ahol a bejegyzéseket író emberek kényelmesen kérnek az AI-építőtől, vagy szerkesztenek fájlt.

Bejegyzések adatbázisban admin oldallal

A bejegyzések egy táblában élnek, és egy privát admin oldalon bárki a csapatból írhat, előnézhet, ütemezhet és publikálhat. Olyan csapatoknak való, ahol a marketing vagy a support ír frissítéseket, vagy ahol ütemezett közzététel vagy közönségenkénti bejegyzések kellenek (például csak a vállalati ügyfelek lássák a vállalati funkciókat).

Az ára több építés és karbantartás: admin bejelentkezés, képfeltöltés, és annak biztosítása, hogy a nyilvános oldalakat a keresőmotorok továbbra is olvashassák, amit egy csak böngészőben betöltött bejegyzéseket megjelenítő oldal nem biztos, hogy garantál.

Olvasható bejegyzések írása

• Az előnyt tedd az elejére. Az „Riportok exportálása Excelbe” jobb, mint az „Új exportmodul”.
• Mondd meg, kinek szól. Minden csomag, csak Pro, a héten bevezetve.
• Mutasd meg. Egy képernyőkép vagy rövid videó.
• Csoportosítsd a kisebb javításokat. Egy heti „Javítások és fejlesztések” bejegyzés felsorolásokkal megakadályozza, hogy az oldal elárasztódjon.
• Légy őszinte az eltávolításokról. Ha valami megszűnik, mondd meg, mikor és mi a helyette használható.

Példa első prompt

Adj nyilvános változásnaplót a weboldalunkhoz a /changelog címen. Minden bejegyzés egy Markdown-fájl címmel, dátummal, címkével (Új, Javított vagy Hibajavítás), opcionális borítóképpel és törzzsel. A főoldal a bejegyzéseket a legújabbal elöl listázza, a dátummal, címkével és az első bekezdéssel, címkeszűrő gombokkal, oldalanként 10 bejegyzéssel. Minden bejegyzésnek saját oldala van a /changelog/<slug> címen, megfelelő oldalcímmel és leírással a keresőmotoroknak. Adj RSS-hírcsatornát a /changelog/rss.xml címen. Készíts három mintabejegyzést. Igazodjon a meglévő weboldal dizájnjához, legyen olvasható telefonon, és rendereld előre az oldalakat, hogy gyorsan töltődjenek.

Az adatbázisos változathoz az első mondatot cseréld erre: „Tárold a bejegyzéseket adatbázisban vázlat/közzétett állapottal és közzétételi dátummal, és adj hozzá jelszóval védett admin oldalt a bejegyzések írásához, előnézetéhez és közzétételéhez.”

Építési lépések

1. Döntsd el a fájlokat vagy az adatbázist a fenti táblázat alapján.
2. Építsd meg a főoldalt és a bejegyzésoldalakat néhány mintabejegyzéssel.
3. Adj hozzá címkéket és szűrőket.
4. Add hozzá az RSS-hírcsatornát, és linkeld az oldalról.
5. Adj oldalcímeket, leírásokat és sitemap-bejegyzést minden bejegyzéshez. Az AI-val épített weboldalak SEO-ja útmutató az alapokat fedi le.
6. Admin oldal és bejelentkezés, ha az adatbázisos utat választottad.
7. „Újdonságok” jelvény az appodban.
8. Írj valódi bejegyzéseket az elmúlt néhány hónapra, hogy az oldal ne üresen induljon.

Gyakori hibák

• Commit-üzenetek másolása. Felhasználóknak írj, nem fejlesztőknek.
• Egyetlen óriási oldal bejegyzésenkénti URL nélkül. Senki nem tud linkelni egy konkrét változásra, a keresőmotorok pedig egy oldalt látnak sok helyett.
• A frissítések egy hónap után leállnak. Egy egy évvel ezelőtt frissített változásnapló elhagyott terméket sugall. Olyan ritmust állíts be, amelyet tartani tudsz.
• Bejegyzések csak a böngészőben való betöltése. A keresőmotorok és a linkelőnézetek üres oldalt láthatnak. Renderelj előre vagy szerveroldalon.
• Incidensek keverése. A kiesések a státuszoldalra tartoznak, nem a változásnaplóba.

Mikor a hosztolt változásnapló-eszköz a jobb választás

Vannak hosztolt változásnapló- és termékfrissítő eszközök, némelyik visszajelző táblákkal vagy app-widgetekkel együtt. Akkor érdemes őket használni, ha felugró ablakot az appban, közönségcélzást és elemzést szeretnél építés nélkül, vagy ha a csapatod már fizet olyan eszközt, amely ezt tartalmazza. A blog- vagy súgóközpont-szoftverednek is lehet már megfelelő formátuma.

Saját változásnaplót akkor építs, ha a saját domainen, a saját dizájnoddal és teljesen indexelhetően szeretnéd, ami egy dátumozott bejegyzések egyszerű listájánál nem sok munka.

Építés a Mythexszel

A Mythexben kérheted az ügynöktől, hogy adjon változásnaplót egy meglévő projekthez, vagy önálló kis oldalként építse meg, és az élő előnézetben látod, ahogy készül. A fájlalapú változat nem igényel adatbázist. Ha az admin változatot választod, az ügynök dedikált Postgres-adatbázist ad hozzá, amikor a bejegyzéseket menteni kell (vagy gépeld be a /database parancsot), a képernyőképek pedig a projekt fájltárhelyére kerülnek. Az admin bejelentkezést saját hitelesítési megoldásoddal kell hozzáadni (bejelentkezés-hozzáadási recept).

Az új Mythex-appok gyakran kliensoldalon renderelt egyoldalas appok, amelyek a SEO-recept szerint kereséshez gyengébbek, ezért ha azt akarod, hogy a bejegyzéseket megtalálják a keresőben, kérj statikus vagy előre renderelt változásnapló-oldalakat. Ugyanez a recept fedi le a címeket, leírásokat és sitemapeket. Kezdéshez beépített változásnaplóval rendelkező sablonért nézd meg a termékismereti központ sablont.

Kérdések