Як створити сторінку змін: записи, теги, RSS і «Що нового»

Сторінка змін — це датований список того, що змінилося у вашому продукті, від найновішого до старішого, написаний для людей, які ним користуються. Щоб створити її, потрібні записи з датою, зрозумілою назвою, коротким поясненням і тегом (Нове, Покращено, Виправлено), сторінка зі списком цих записів, окрема URL-адреса для кожного запису і, бажано, RSS-стрічка та спосіб повідомити користувачам, що є щось нове. Це одна з найпростіших речей, які можна створити, а головне рішення — де житимуть записи: як файли на вашому сайті чи в базі даних із адміністративною сторінкою.

Чому журнал змін варто мати

Журнал змін показує клієнтам і потенційним клієнтам, що продукт підтримується. Він дає службі підтримки й продажам посилання, яке можна надіслати, коли хтось питає: «Чи вже це вміє робити?». Це також місце, щоб замкнути цикл зворотного зв'язку: коли запропонована функція випущена, саме на запис у журналі змін ви вказуєте людям. Якщо ви ведете портал відгуків клієнтів, посилайте запити, які вже реалізовано, безпосередньо на їхні записи.

Журнал змін — це не внутрішня історія комітів. «Refactored billing service» нічого не говорить користувачеві. «Тепер на рахунках відображається номер ПДВ вашої компанії» — говорить.

Що потрібно сторінці

Вміст кожного запису

Сторінки

• Головна журналу змін: від найновішого, з фільтрами за тегами та простою пагінацією або кнопкою «завантажити ще».
• Сторінка запису: один запис за URL-адресою, щоб його можна було посилати й ділитися ним.
• RSS- або Atom-стрічка: дозволяє людям і інструментам стежити за оновленнями без електронної пошти.
• Адміністративна сторінка (лише у версії з базою даних): написання, перегляд, планування й публікація записів.

Додатки всередині застосунку

• Значок «Що нового»: крапка біля пункту меню, коли є записи, які користувач ще не бачив. Зберігайте дату останнього відкритого запису для кожного користувача або в браузері.
• Дайджест електронною поштою: підсумок, який надсилається користувачам, що погодилися його отримувати. Для цього потрібен провайдер надсилання; див. як надсилати листи з вашого застосунку.

Головне рішення: файли чи база даних

Записи як файли на сайті

Кожен запис — це файл Markdown у проєкті. Публікація запису означає додавання файлу й повторне розгортання. Це найпростіший і найнадійніший підхід: немає бази даних, немає адміністративного входу, нічого захищати, а сторінки можна попередньо відрендерити, тож вони завантажуються швидко й легко читаються пошуковими системами.

Це підходить командам, у яких люди, що пишуть записи, почуваються комфортно, звертаючись до конструктора на базі ШІ або редагуючи файл.

Записи в базі даних з адміністративною сторінкою

Записи живуть у таблиці, а приватна адміністративна сторінка дозволяє будь-кому в команді писати, переглядати, планувати й публікувати. Це підходить командам, де оновлення пишуть маркетинг або підтримка, або коли потрібна публікація за розкладом чи записи для окремих аудиторій (наприклад, показувати функції для корпоративних клієнтів лише їм).

Ціна — більше роботи зі створення й супроводу: адміністративний вхід, завантаження зображень і гарантія того, що публічні сторінки залишаються доступними для пошукових систем, чого може не бути у сторінки, яка завантажує записи лише в браузері.

Як писати записи, які читають

• Починайте з користі. «Експорт звітів в Excel» краще, ніж «Новий модуль експорту».
• Вкажіть, кому це доступно. Усі тарифи, лише Pro, розгортається цього тижня.
• Покажіть це. Один скріншот або короткий кліп.
• Групуйте дрібні виправлення. Щотижневий запис «Виправлення та покращення» з пунктами не дасть сторінці переповнитися.
• Чесно пишіть про видалення. Якщо щось зникає, вкажіть, коли і що використовувати натомість.

Перший запит, який працює

Додай публічний журнал змін на наш сайт за адресою /changelog. Кожен запис — це файл Markdown із назвою, датою, тегом (Нове, Покращено або Виправлено), необов'язковим зображенням на обкладинку та текстом. Головна сторінка показує записи від найновішого з датою, тегом і першим абзацом, має кнопки фільтра за тегами та показує по 10 записів на сторінці. Кожен запис має власну сторінку за адресою /changelog/<slug> з належним заголовком і описом для пошукових систем. Додай RSS-стрічку за адресою /changelog/rss.xml. Створи три приклади записів. Відповідай наявному дизайну сайту, зберігай читабельність на телефонах і попередньо рендери сторінки, щоб вони завантажувалися швидко.

Для версії з базою даних замініть перше речення на: «Зберігай записи в базі даних зі статусом чернетки/опублікованого та датою публікації й додай захищену паролем адміністративну сторінку, щоб писати, переглядати й публікувати їх».

Кроки побудови

1. Вирішіть, файли чи база даних, за таблицею вище.
2. Створіть головну сторінку і сторінки записів з кількома прикладами.
3. Додайте теги та фільтри.
4. Додайте RSS-стрічку і посилання на неї зі сторінки.
5. Додайте заголовки сторінок, описи та запис у карті сайту для кожного запису. Основи описано в нашому посібнику SEO для сайтів, створених за допомогою ШІ.
6. Адміністративна сторінка і вхід, якщо ви обрали шлях з базою даних.
7. Значок «Що нового» у вашому застосунку.
8. Напишіть справжні записи за останні кілька місяців, щоб сторінка не запускалася порожньою.

Типові помилки

• Копіювання повідомлень комітів. Пишіть для користувачів, а не для розробників.
• Одна величезна сторінка без URL для кожного запису. Ніхто не може послатися на конкретну зміну, а пошукові системи бачать одну сторінку замість багатьох.
• Оновлення припиняються через місяць. Журнал змін, оновлений востаннє рік тому, натякає на покинутий продукт. Встановіть ритм, який зможете витримувати.
• Завантаження записів лише в браузері. Пошукові системи та попередній перегляд посилань можуть побачити порожню сторінку. Попередньо рендеріть або рендерте на сервері.
• Змішування інцидентів. Збої належать до сторінки статусу, а не до журналу змін.

Коли краще готовий інструмент для журналу змін

Існують хостингові інструменти для журналу змін і оновлень продукту, а деякі постачаються разом із дошками відгуків або віджетами в застосунку. Вони варті своєї ціни, якщо ви хочете спливаючі вікна в застосунку, таргетинг аудиторії та аналітику без власної розробки або якщо ваша команда вже платить за інструмент, який це включає. Програмне забезпечення для блогу чи центру довідки також може мати для цього відповідний формат.

Створювати власний має сенс, коли ви хочете, щоб журнал змін був на вашому домені, у вашому дизайні й повністю індексувався, а для простого списку датованих записів це не потребує багато роботи.

Створення в Mythex

В Mythex ви можете попросити агента додати журнал змін до наявного проєкту або створити його як окремий невеликий сайт і побачити його в живому попередньому перегляді під час створення. Версія на основі файлів не потребує бази даних. Якщо ви обираєте версію з адміністративною панеллю, агент додає окрему базу даних Postgres, коли записи потрібно зберігати (або введіть /database), а скріншоти зберігаються у файловому сховищі проєкту. Вхід в адміністративну частину додається за вашим власним підходом до автентифікації (рецепт входу).

Нові застосунки Mythex часто є односторінковими застосунками з рендерингом на клієнті, а рецепт SEO зазначає, що для пошуку вони слабші, тож попросіть статичні або попередньо відрендерені сторінки журналу змін, якщо хочете, щоб записи знаходили в пошуку. Той самий рецепт охоплює заголовки, описи та карти сайтів. Як відправну точку з вбудованим журналом змін див. шаблон центру знань про продукт.

Запитання