نحوه ساخت صفحه‌ی تغییرات: ورودی‌ها، برچسب‌ها، RSS و «چه چیزی جدید است»
صفحه‌ی تغییرات فهرستی تاریخ‌دار از چیزهایی است که در محصولتان عوض شده، جدیدترین اول، و برای کسانی نوشته می‌شود که از آن استفاده می‌کنند. برای ساختنش به ورودی‌هایی با تاریخ، عنوانی روشن، توضیح کوتاه و یک برچسب (جدید، بهبود یافته، رفع‌شده)، صفحه‌ای که آن‌ها را فهرست کند، یک URL جدا برای هر ورودی، و در حالت ایده‌آل یک فید RSS و راهی برای اطلاع دادن به کاربران که چیز جدیدی وجود دارد، نیاز دارید. این یکی از ساده‌ترین چیزهایی است که می‌توانید بسازید، و تصمیم اصلی این است که ورودی‌ها کجا زندگی کنند: به‌صورت فایل در سایتتان، یا در یک دیتابیس با یک صفحه‌ی مدیریت.
چرا صفحه‌ی تغییرات ارزش دارد
صفحه‌ی تغییرات به مشتریان و مشتریان احتمالی نشان می‌دهد که محصول نگهداری می‌شود. به پشتیبانی و فروش یک لینک می‌دهد تا وقتی کسی می‌پرسد «آیا هنوز X را دارد؟» آن را بفرستند. همچنین جایی است که حلقه‌ی بازخورد را می‌بندید: وقتی یک قابلیت درخواست‌شده منتشر می‌شود، ورودی تغییرات چیزی است که به مردم نشانش می‌دهید. اگر یک پورتال بازخورد مشتری دارید، درخواست‌های منتشرشده را مستقیم به ورودی‌هایشان لینک دهید.
صفحه‌ی تغییرات تاریخچه‌ی داخلی کامیت‌های شما نیست. «سرویس صورت‌حساب بازنویسی شد» برای کاربر معنایی ندارد. «صورت‌حساب‌ها اکنون شماره‌ی مالیات بر ارزش افزوده‌ی شرکت شما را نشان می‌دهند» معنا دارد.
صفحه به چه چیزی نیاز دارد
محتوای هر ورودی
| فیلد | یادداشت |
|---|---|
| عنوان | چه چیزی تغییر کرده، از دید کاربر |
| تاریخ | تاریخ انتشار، که روی صفحه نشان داده می‌شود |
| برچسب | جدید، بهبود یافته، رفع‌شده (و شاید حذف‌شده یا امنیتی) |
| متن | چند جمله یا بولت؛ چطور استفاده شود، چه کسی به آن دسترسی دارد |
| تصویر یا ویدیو | اختیاری؛ یک اسکرین‌شات بیشتر از یک پاراگراف کمک می‌کند |
| اسلاگ | URL ورودی، مثل /changelog/invoice-vat-numbers |
| وضعیت | پیش‌نویس یا منتشرشده، به‌علاوه‌ی تاریخ انتشار زمان‌بندی‌شده در صورت نیاز |
صفحات
- فهرست تغییرات: جدیدترین اول، با فیلترهای برچسب و صفحه‌بندی ساده یا «بارگذاری بیشتر».
- صفحه‌ی ورودی: یک ورودی برای هر URL، تا بتوان آن را لینک داد و به اشتراک گذاشت.
- فید RSS یا Atom: به مردم و ابزارها اجازه می‌دهد به‌روزرسانی‌ها را بدون ایمیل دنبال کنند.
- صفحه‌ی مدیریت (فقط در نسخه‌ی دیتابیس): نوشتن، پیش‌نمایش، زمان‌بندی و انتشار ورودی‌ها.
امکانات داخل اپلیکیشن
- نشانگر «چه چیزی جدید است»: یک نقطه کنار یک گزینه‌ی منو وقتی ورودی‌هایی هست که کاربر ندیده است. تاریخ آخرین ورودی‌ای که باز کرده را برای هر کاربر، یا در مرورگر، ذخیره کنید.
- خلاصه‌ی ایمیلی: خلاصه‌ای برای کاربرانی که اعلام تمایل کرده‌اند. این به یک ارائه‌دهنده‌ی ارسال ایمیل نیاز دارد؛ به نحوه‌ی ارسال ایمیل از اپلیکیشن مراجعه کنید.
تصمیم اصلی: فایل یا دیتابیس
ورودی‌ها به‌صورت فایل در سایت
هر ورودی یک فایل Markdown در پروژه است. منتشر کردن یک ورودی یعنی افزودن یک فایل و استقرار دوباره. این ساده‌ترین و مقاوم‌ترین رویکرد است: بدون دیتابیس، بدون ورود مدیریت، چیزی برای ایمن کردن نیست، و صفحات می‌توانند پیش‌رندر شوند تا سریع بارگذاری شوند و موتورهای جستجو به‌راحتی بخوانندشان.
این برای تیم‌هایی مناسب است که کسانی که ورودی می‌نویسند با درخواست از یک سازنده‌ی هوش مصنوعی یا ویرایش یک فایل راحت‌اند.
ورودی‌ها در دیتابیس با یک صفحه‌ی مدیریت
ورودی‌ها در یک جدول زندگی می‌کنند و یک صفحه‌ی خصوصی مدیریت به هر کسی در تیم اجازه می‌دهد بنویسد، پیش‌نمایش ببیند، زمان‌بندی کند و منتشر کند. این برای تیم‌هایی مناسب است که بازاریابی یا پشتیبانی به‌روزرسانی‌ها را می‌نویسند، یا وقتی می‌خواهید انتشار زمان‌بندی‌شده یا ورودی‌های مخصوص هر مخاطب داشته باشید (برای مثال نشان دادن قابلیت‌های سازمانی فقط به مشتریان سازمانی).
هزینه‌اش ساخت و نگهداری بیشتر است: ورود مدیریت، آپلود تصویر، و مطمئن شدن از اینکه صفحات عمومی هنوز برای موتورهای جستجو قابل خواندن‌اند؛ چیزی که یک صفحه‌ای که ورودی‌ها را فقط در مرورگر بارگذاری می‌کند ممکن است نداشته باشد.
| فایل‌ها | دیتابیس + مدیریت | |
|---|---|---|
| چه کسی می‌تواند منتشر کند | هر کسی که پروژه را ویرایش می‌کند | هر کسی با ورود مدیریت |
| راه‌اندازی | حداقلی | ورود، ذخیره‌سازی، رابط مدیریت |
| سئو | آسان (صفحات پیش‌رندرشده) | نیاز به دقت دارد تا صفحات روی سرور یا از پیش رندر شوند |
| زمان‌بندی | هنگام استقرار منتشر کنید | می‌توان بر اساس تاریخ زمان‌بندی کرد |
| هزینه‌ی میزبانی | ایستا | نیاز به یک اپلیکیشن و دیتابیس در حال اجرا |
نوشتن ورودی‌هایی که مردم می‌خوانند
- با مزیت شروع کنید. «خروجی گرفتن گزارش‌ها به Excel» بهتر از «ماژول جدید خروجی» است.
- بگویید چه کسی به آن دسترسی دارد. همه‌ی پلن‌ها، فقط Pro، در حال عرضه‌ی این هفته.
- نشانش دهید. یک اسکرین‌شات یا یک کلیپ کوتاه.
- رفع‌های کوچک را گروه‌بندی کنید. یک ورودی هفتگی با عنوان «رفع‌ها و بهبودها» و بولت‌ها باعث می‌شود صفحه پر نشود.
- درباره‌ی حذف‌ها صادق باشید. اگر چیزی قرار است برود، بگویید چه زمانی و به‌جایش از چه چیزی استفاده شود.
یک پرامپت اولیه که کار می‌کند
یک صفحه‌ی تغییرات عمومی در /changelog به سایتمان اضافه کن. هر ورودی یک فایل Markdown با عنوان، تاریخ، برچسب (جدید، بهبود یافته یا رفع‌شده)، تصویر شاخص اختیاری و متن است. صفحه‌ی فهرست ورودی‌ها را جدیدترین اول با تاریخ، برچسب و اولین پاراگراف نشان می‌دهد، دکمه‌های فیلتر برچسب دارد، و ۱۰ ورودی در هر صفحه نمایش می‌دهد. هر ورودی صفحه‌ی مخصوص خودش را در /changelog/<slug> دارد، با عنوان صفحه و توضیح مناسب برای موتورهای جستجو. یک فید RSS در /changelog/rss.xml اضافه کن. سه ورودی نمونه بساز. با طراحی موجود سایت هماهنگ باشد، روی گوشی خوانا باشد، و صفحات را پیش‌رندر کن تا سریع بارگذاری شوند.
برای نسخه‌ی دیتابیس، جمله‌ی اول را با «ورودی‌ها را در یک دیتابیس با وضعیت پیش‌نویس/منتشرشده و تاریخ انتشار ذخیره کن، و یک صفحه‌ی مدیریت محافظت‌شده با رمز عبور برای نوشتن، پیش‌نمایش و انتشار آن‌ها اضافه کن» جایگزین کنید.
مراحل ساخت
۱. تصمیم بگیرید فایل یا دیتابیس با استفاده از جدول بالا. ۲. ساخت صفحات فهرست و ورودی با چند ورودی نمونه. ۳. افزودن برچسب‌ها و فیلترها. ۴. افزودن فید RSS و لینک دادن آن از صفحه. ۵. افزودن عنوان صفحه، توضیح‌ها و یک مدخل نقشه‌ی سایت برای هر ورودی. راهنمای ما درباره‌ی سئو برای وب‌سایت‌های ساخته‌شده با هوش مصنوعی اصول را پوشش می‌دهد. ۶. صفحه‌ی مدیریت و ورود، اگر مسیر دیتابیس را انتخاب کرده‌اید. ۷. نشانگر «چه چیزی جدید است» در اپلیکیشن شما. ۸. نوشتن ورودی‌های واقعی برای چند ماه گذشته تا صفحه خالی راه‌اندازی نشود.
اشتباهات رایج
- کپی کردن پیام‌های کامیت. برای کاربران بنویسید، نه برای توسعه‌دهندگان.
- یک صفحه‌ی غول‌پیکر بدون URL برای هر ورودی. کسی نمی‌تواند به یک تغییر مشخص لینک دهد، و موتورهای جستجو به‌جای چندین صفحه یک صفحه می‌بینند.
- به‌روزرسانی‌ها بعد از یک ماه متوقف می‌شوند. صفحه‌ای که یک سال پیش به‌روز شده، یک محصول رهاشده را القا می‌کند. ریتمی تعیین کنید که بتوانید حفظش کنید.
- بارگذاری ورودی‌ها فقط در مرورگر. موتورهای جستجو و پیش‌نمایش لینک ممکن است صفحه‌ی خالی ببینند. پیش‌رندر کنید یا روی سرور رندر کنید.
- قاطی کردن خرابی‌ها. قطعی‌ها باید در یک صفحه‌ی وضعیت باشند، نه در صفحه‌ی تغییرات.
کی یک ابزار تغییرات میزبانی‌شده بهتر است
ابزارهای میزبانی‌شده‌ی صفحه‌ی تغییرات و به‌روزرسانی محصول وجود دارند، و بعضی با تابلوهای بازخورد یا ویجت‌های داخل اپلیکیشن همراه‌اند. اگر پاپ‌آپ داخل اپلیکیشن، هدف‌گذاری مخاطب و تحلیل بدون ساختنشان می‌خواهید، یا اگر تیمتان از قبل ابزاری را که شامل آن است پرداخت می‌کند، ارزش دارند. نرم‌افزار وبلاگ یا مرکز راهنمای شما هم ممکن است قالب مناسبی داشته باشد.
ساختن صفحه‌ی اختصاصی وقتی منطقی است که بخواهید صفحه‌ی تغییرات روی دامنه‌ی خودتان، با طراحی خودتان و کاملاً قابل ایندکس باشد، که برای یک فهرست ساده از پست‌های تاریخ‌دار کار زیادی نیست.
ساخت با Mythex
در Mythex می‌توانید از عامل بخواهید یک صفحه‌ی تغییرات به یک پروژه‌ی موجود اضافه کند، یا آن را به‌صورت یک سایت کوچک مستقل بسازد، و همان‌طور که ساخته می‌شود در پیش‌نمایش زنده ببینیدش. نسخه‌ی مبتنی بر فایل به دیتابیس نیاز ندارد. اگر نسخه‌ی مدیریت را انتخاب کنید، عامل وقتی ورودی‌ها باید ذخیره شوند یک دیتابیس اختصاصی Postgres اضافه می‌کند (یا /database را تایپ کنید)، و اسکرین‌شات‌ها در ذخیره‌سازی فایل پروژه قرار می‌گیرند. ورود مدیریت چیزی است که با روش احراز هویت خودتان اضافه می‌کنید (دستور افزودن ورود).
اپلیکیشن‌های جدید Mythex اغلب تک‌صفحه‌ای سمت کلاینت هستند که دستور سئو نشان می‌دهد برای جستجو ضعیف‌ترند، پس اگر می‌خواهید ورودی‌ها در جستجو پیدا شوند، صفحات ایستا یا پیش‌رندرشده‌ی تغییرات را بخواهید. همان دستور عنوان، توضیح و نقشه‌ی سایت را پوشش می‌دهد. برای نقطه‌ی شروع با یک صفحه‌ی تغییرات آماده، قالب مرکز دانش محصول را ببینید.
پرسش‌ها
هر ورودی در صفحه‌ی تغییرات باید چه چیزی داشته باشد؟
یک تاریخ، یک عنوان کوتاه که بگوید برای کاربر چه چیزی تغییر کرده، چند جمله یا نکته‌ی بولت برای توضیح آن، یک برچسب مثل جدید، بهبود یافته یا رفع‌شده، و اختیاری یک تصویر و لینکی به جزئیات بیشتر.
آیا صفحه‌ی تغییرات به دیتابیس نیاز دارد؟
لزوماً نه. اگر یک یا دو نفر به‌روزرسانی‌ها را منتشر می‌کنند، ورودی‌ها می‌توانند به‌صورت فایل Markdown در سایت باشند و با هر استقرار منتشر شوند. از دیتابیس وقتی استفاده کنید که افراد غیرفنی باید از یک صفحه‌ی مدیریت ورودی بنویسند و زمان‌بندی کنند.
چند وقت یک‌بار باید صفحه‌ی تغییرات را به‌روز کنم؟
هر وقت چیزی که کاربران متوجهش می‌شوند تغییر کرد. بسیاری از محصولات کوچک تغییرات را هفتگی یا دو‌هفته‌ای گروه‌بندی می‌کنند؛ مهم این است که ریتمی ثابت داشته باشید تا صفحه زنده به نظر برسد.
آیا صفحه‌ی تغییرات برای سئو خوب است؟
کمی کمک می‌کند: هر ورودی یک صفحه‌ی قابل‌خزیدن درباره‌ی یک قابلیت است، و یک صفحه‌ی به‌روزشده‌ی منظم نشان می‌دهد محصول فعال است. هر ورودی را URL مستقل و عنوان توصیفی بدهید.