როგორ ავაშენოთ ცვლილებების გვერდი: ჩანაწერები, თეგები, RSS და „რა არის ახალი“
changelog გვერდი არის თარიღებით დალაგებული სია იმის შესახებ, რაც შენს პროდუქტში შეიცვალა, ყველაზე ახალი პირველი, იმ ადამიანებისთვის დაწერილი, ვინც მას იყენებს. ასაშენებლად გჭირდება ჩანაწერები თარიღით, მკაფიო სათაურით, მოკლე ახსნით და თეგით (New, Improved, Fixed), გვერდი, რომელიც ჩანაწერებს ჩამოთვლის, ცალკე URL თითო ჩანაწერზე და, იდეალურად, RSS feed და გზა იმის სათქმელად, რომ რაღაც ახალია. ეს ერთ-ერთი ყველაზე მარტივი რამაა, რაც შეგიძლია ააშენო, და მთავარი გადაწყვეტილებაა, სად ცხოვრობენ ჩანაწერები: როგორც ფაილები საიტში, თუ მონაცემთა ბაზაში ადმინისტრატორის გვერდით.
რატომ ღირს changelog-ის ქონა
changelog აჩვენებს მომხმარებლებსა და პოტენციურ კლიენტებს, რომ პროდუქტი მხარდაჭერილია. ის support-სა და გაყიდვების გუნდს აძლევს ბმულს, როცა ვინმე კითხულობს „უკვე აკეთებს თუ არა X-ს?“. ის ასევე არის ადგილი უკუკავშირის დასახურად: როცა მოთხოვნილი ფუნქცია გამოვა, changelog-ის ჩანაწერია ის, რასაც ადამიანებს მიუთითებ. თუ მომხმარებლის უკუკავშირის პორტალს მართავ, გამოშვებული მოთხოვნები პირდაპირ მათ ჩანაწერებზე მიუთითე.
changelog არ არის შენი შიდა commit-ისტორია. „Billing სერვისის რეფაქტორინგი“ მომხმარებელს არაფერს ნიშნავს. „ინვოისები ახლა აჩვენებს კომპანიის დღგ-ის ნომერს“ კი ნიშნავს.
რა სჭირდება გვერდს
შინაარსი თითო ჩანაწერზე
| ველი | შენიშვნები |
|---|---|
| სათაური | რა შეიცვალა, მომხმარებლის თვალსაზრისით |
| თარიღი | გამოქვეყნების თარიღი, გვერდზე ნაჩვენები |
| თეგი | New, Improved, Fixed (და შესაძლოა Removed ან Security) |
| ტექსტი | რამდენიმე წინადადება ან პუნქტი; როგორ გამოიყენო, ვისთვის არის |
| სურათი ან ვიდეო | სურვილისამებრ; ეკრანის ანაბეჭდი ბევრად მეტს ამბობს, ვიდრე პარაგრაფი |
| სლაგი | ჩანაწერის URL, მაგალითად /changelog/invoice-vat-numbers |
| სტატუსი | დრაფტი ან გამოქვეყნებული, საჭიროების შემთხვევაში დაგეგმილი გამოქვეყნების თარიღით |
გვერდები
- changelog-ის ინდექსი: ყველაზე ახალი პირველი, თეგების ფილტრებით და მარტივი პაგინაციით ან „მეტის ჩატვირთვით“.
- ჩანაწერის გვერდი: თითო ჩანაწერი თითო URL-ზე, რომ მისი ბმული შეიძლებოდეს გაზიარება.
- RSS ან Atom feed: საშუალებას აძლევს ადამიანებსა და ინსტრუმენტებს განახლებები ელფოსტის გარეშე მოჰყვნენ.
- ადმინისტრატორის გვერდი (მხოლოდ მონაცემთა ბაზის ვერსიაში): ჩანაწერების წერა, წინასწარ ნახვა, დაგეგმვა და გამოქვეყნება.
აპში დამატებითი ელემენტები
- „რა არის ახალი“ ნიშანი: წერტილი მენიუს პუნქტზე, როცა არის ჩანაწერები, რომლებსაც მომხმარებელმა ჯერ არ უნახავს. შეინახე იმ ბოლო ჩანაწერის თარიღი, რომელიც მან გახსნა, თითო მომხმარებლისთვის ან ბრაუზერში.
- ელფოსტის დაიჯესტი: შეჯამება მათთვის, ვინც ითანხმებს. ამას სჭირდება გაგზავნის პროვაიდერი; იხილე როგორ გავაგზავნოთ ელფოსტა აპიდან.
მთავარი გადაწყვეტილება: ფაილები თუ მონაცემთა ბაზა
ჩანაწერები როგორც ფაილები საიტში
თითო ჩანაწერი არის Markdown ფაილი პროექტში. ჩანაწერის გამოქვეყნება ნიშნავს ფაილის დამატებას და ხელახლა დეპლოის. ეს ყველაზე მარტივი და საიმედო მიდგომაა: მონაცემთა ბაზა არ არის, ადმინისტრატორის შესვლა არ არის, დასაცავი არაფერია, და გვერდები შეიძლება წინასწარ დარენდერდეს, რომ სწრაფად ჩაიტვირთოს და საძიებო სისტემისთვის წაკითხვადი იყოს.
ეს შეეფერება გუნდებს, სადაც ჩანაწერებს წერს ადამიანი, რომელიც კომფორტულად გრძნობს თავს AI აშენების ინსტრუმენტთან ან ფაილის რედაქტირებასთან.
ჩანაწერები მონაცემთა ბაზაში ადმინისტრატორის გვერდით
ჩანაწერები ცხრილში ინახება, და პირადი ადმინისტრატორის გვერდი საშუალებას აძლევს გუნდის ნებისმიერ წევრს დაწეროს, წინასწარ ნახოს, დაგეგმოს და გამოაქვეყნოს. ეს შეეფერება გუნდებს, სადაც მარკეტინგი ან support წერს განახლებებს, ან როცა გინდა დაგეგმილი გამოქვეყნება ან აუდიტორიის მიხედვით ჩანაწერები (მაგალითად, საწარმოს ფუნქციები მხოლოდ საწარმოს მომხმარებლებს).
ფასი მეტი აშენებაა და მეტი მოვლა: ადმინისტრატორის შესვლა, სურათების ატვირთვა და იმის უზრუნველყოფა, რომ საჯარო გვერდები მაინც წაკითხვადია საძიებო სისტემებისთვის — გვერდი, რომელიც ჩანაწერებს მხოლოდ ბრაუზერში იტვირთავს, შეიძლება ცარიელი გამოჩნდეს.
| ფაილები | მონაცემთა ბაზა + ადმინისტრატორი | |
|---|---|---|
| ვინ შეუძლია გამოქვეყნება | ვისაც პროექტის რედაქტირება შეუძლია | ვისაც ადმინისტრატორის შესვლა აქვს |
| დაყენება | მინიმალური | შესვლა, საცავი, ადმინისტრატორის ინტერფეისი |
| SEO | მარტივი (წინასწარ დარენდერებული გვერდები) | საჭიროებს ყურადღებას, რომ გვერდები სერვერზე ან წინასწარ დარენდერდეს |
| დაგეგმვა | გამოქვეყნება დეპლოისას | შეიძლება თარიღით დაგეგმვა |
| ჰოსტინგის ღირებულება | სტატიკური | სჭირდება გაშვებული აპი და მონაცემთა ბაზა |
როგორ დავწეროთ ჩანაწერები, რომლებსაც ადამიანები კითხულობენ
- დაიწყე სარგებლით. „ექსპორტი Excel-ში“ უკეთესია, ვიდრე „ახალი ექსპორტის მოდული“.
- თქვი, ვისთვისაა. ყველა გეგმისთვის, მხოლოდ Pro-სთვის, ამ კვირაში ვრცელდება.
- აჩვენე. ერთი ეკრანის ანაბეჭდი ან მოკლე კლიპი.
- დააჯგუფე წვრილი შესწორებები. კვირეული ჩანაწერი „შესწორებები და გაუმჯობესებები“ პუნქტებით ინახავს გვერდს გადატვირთვისგან.
- იყავი გულწრფელი წაშლებზე. თუ რამე მიდის, თქვი როდის და რა გამოიყენო მის ნაცვლად.
მაგალითი პირველი მოთხოვნისა
დაამატე საჯარო changelog ჩვენს საიტზე მისამართზე /changelog. თითო ჩანაწერი არის Markdown ფაილი სათაურით, თარიღით, თეგით (New, Improved ან Fixed), სურვილისამებრ ყდის სურათით და ტექსტით. ინდექსის გვერდი ჩამოთვლის ჩანაწერებს ყველაზე ახალი პირველი, აჩვენებს თარიღს, თეგს და პირველ აბზაცს, აქვს თეგის ფილტრის ღილაკები და თითო გვერდზე 10 ჩანაწერს. თითო ჩანაწერს აქვს საკუთარი გვერდი /changelog/<slug>, სწორი გვერდის სათაურით და აღწერით საძიებო სისტემებისთვის. დაამატე RSS feed მისამართზე /changelog/rss.xml. შექმენი სამი ნიმუში ჩანაწერი. მოერგე არსებულ საიტის დიზაინს, იყოს წაკითხვადი ტელეფონებზე და წინასწარ დარენდერდეს გვერდები, რომ სწრაფად ჩაიტვირთოს.
მონაცემთა ბაზის ვერსიისთვის პირველი წინადადება შეცვალე: „შეინახე ჩანაწერები მონაცემთა ბაზაში დრაფტის/გამოქვეყნებული სტატუსით და გამოქვეყნების თარიღით, და დაამატე პაროლით დაცული ადმინისტრატორის გვერდი ჩანაწერების წერისთვის, წინასწარ ნახვისა და გამოსაქვეყნებლად.“
აშენების ნაბიჯები
- გადაწყვიტე ფაილები თუ მონაცემთა ბაზა ზემოთ მოცემული ცხრილით.
- ააშენე ინდექსისა და ჩანაწერის გვერდები რამდენიმე ნიმუში ჩანაწერით.
- დაამატე თეგები და ფილტრები.
- დაამატე RSS feed და მიუთითე ბმული გვერდზე.
- დაამატე გვერდის სათაურები, აღწერები და sitemap-ის ჩანაწერი თითო ჩანაწერისთვის. ჩვენი გზამკვლევი SEO-ზე AI-ით აშენებული ვებსაიტებისთვის საფუძვლებს ეხება.
- ადმინისტრატორის გვერდი და შესვლა, თუ მონაცემთა ბაზის გზა აირჩიე.
- „რა არის ახალი“ ნიშანი შენს აპში.
- დაწერე რეალური ჩანაწერები ბოლო რამდენიმე თვისთვის, რომ გვერდი ცარიელი არ გაიხსნას.
გავრცელებული შეცდომები
- commit-ების გადმოწერა. წერე მომხმარებლისთვის, არა დეველოპერისთვის.
- ერთი დიდი გვერდი ჩანაწერების URL-ების გარეშე. არავინ ვერ მიუთითებს კონკრეტულ ცვლილებაზე, და საძიებო სისტემები ერთ გვერდს ხედავენ ნაცვლად მრავლისა.
- განახლებები ერთი თვის შემდეგ ჩერდება. ერთი წლის წინ განახლებული changelog მიგვანიშნებს, რომ პროდუქტი მიტოვებულია. დააწესე რიტმი, რომლის შენარჩუნებაც შეგიძლია.
- ჩანაწერების მხოლოდ ბრაუზერში ჩატვირთვა. საძიებო სისტემებმა და ბმულების წინასწარმა ნახვამ შეიძლება ცარიელი გვერდი დაინახოს. წინასწარ დაარენდერე ან სერვერზე დაარენდერე.
- ინციდენტების შერევა. გათიშვები სტატუსის გვერდს ეკუთვნის, და არა changelog-ს.
როდის არის მზა changelog ინსტრუმენტი უკეთესი
არსებობს ჰოსტირებული changelog და პროდუქტის განახლებების ინსტრუმენტები, ზოგი მათგანი უკუკავშირის დაფებთან ან ვიჯეტებთან ერთად მოდის. ისინი ღირს, თუ გინდა აპში ამომხტარი შეტყობინება, აუდიტორიის გამოყოფა და ანალიტიკა აშენების გარეშე, ან თუ შენს გუნდს უკვე აქვს ინსტრუმენტი, რომელიც ამას შეიცავს. შენი ბლოგის ან დახმარების ცენტრის პროგრამულ უზრუნველყოფას შეიძლება უკვე ჰქონდეს შესაფერისი ფორმატი.
საკუთარი აშენება გამართლებულია, როცა changelog შენს დომენზე გინდა, შენი დიზაინით და სრულად ინდექსირებადი; თარიღებით დალაგებული მარტივი სიისთვის ეს დიდ შრომას არ მოითხოვს.
Mythex-ით აშენება
Mythex-ზე შეგიძლია აგენტს სთხოვო changelog-ის დამატება არსებულ პროექტში ან მისი აშენება როგორც საკუთარი პატარა საიტი, და ის ცოცხალ წინასწარ ნახვაში აშენების პროცესში ჩანს. ფაილებზე დაფუძნებულ ვერსიას მონაცემთა ბაზა არ სჭირდება. თუ ადმინისტრატორის ვერსია აირჩიე, აგენტი ამატებს გამოყოფილ Postgres მონაცემთა ბაზას, როცა ჩანაწერების შენახვა დაჭირდება (ან ჩაწერე /database), ხოლო ეკრანის ანაბეჭდები პროექტის ფაილების საცავში ინახება. ადმინისტრატორის შესვლას შენი საკუთარი ავტორიზაციის მიდგომით დაამატებ (შესვლის დამატების რეცეპტი).
ახალი Mythex აპები ხშირად კლიენტზე რენდერდებული ერთგვერდიანი აპებია, რასაც SEO რეცეპტი სუსტად მიიჩნევს საძიებო სისტემისთვის, ამიტომ თუ გინდა, რომ ჩანაწერები ძიებაში ნაპოვნი იყოს, სთხოვე სტატიკური ან წინასწარ დარენდერებული changelog გვერდები. იგივე რეცეპტი მოიცავს სათაურებს, აღწერებსა და sitemap-ებს. დასაწყისისთვის ჩაშენებული changelog-ით იხილე პროდუქტის ცოდნის ცენტრის შაბლონი.
კითხვები
რა უნდა შეიცავდეს changelog-ის ჩანაწერი?
თარიღს, მოკლე სათაურს, რომელიც მომხმარებლისთვის ცვლილებას აღწერს, რამდენიმე წინადადებას ან პუნქტებს, თეგს როგორიცაა New, Improved ან Fixed, და სურვილისამებრ ეკრანის ანაბეჭდს და ბმულს მეტ დეტალზე.
changelog-ს მონაცემთა ბაზა სჭირდება?
აუცილებლად არა. თუ ერთი ან ორი ადამიანი აქვეყნებს განახლებებს, ჩანაწერები შეიძლება საიტში Markdown ფაილებად იყოს და გამოქვეყნდეს ყოველი დეპლოისას. მონაცემთა ბაზა მაშინ გჭირდება, როცა არატექნიკურ ადამიანებს სჭირდებათ ჩანაწერების წერა და დაგეგმვა ადმინისტრატორის გვერდიდან.
რამდენად ხშირად უნდა განვაახლო changelog?
ყოველ ჯერზე, როცა შეიცვლება რამე, რაც მომხმარებელს შეამჩნევს. ბევრი პატარა პროდუქტი ცვლილებებს კვირაში ან ორ კვირაში ერთხელ აჯგუფებს; მთავარია სტაბილური რიტმი, რომ გვერდი ცოცხლად გამოიყურებოდეს.
changelog კარგია SEO-სთვის?
შეიძლება ცოტათი დაგეხმაროს: თითოეული ჩანაწერი ფუნქციის შესახებ საძიებო სისტემისთვის წაკითხვადი გვერდია, ხოლო რეგულარულად განახლებული გვერდი აქტიურ პროდუქტს ასიგნალებს. თითოეულ ჩანაწერს მისი საკუთარი URL და აღწერითი სათაური მიეცი.