ข้ามไปยังเนื้อหาหลัก

คู่มือแนวทางการเขียนคู่มือ

Guides Banner

เพื่อให้มั่นใจว่าเนื้อหาบน ZAP-Docs ของเรามีคุณภาพและสไตล์ที่สม่ำเสมอ เราจึงได้สร้างแนวทางต่างๆ สำหรับใช้เมื่อสร้างหรือแก้ไขเนื้อหาสำหรับเอกสารของเรา คุณ ต้อง ปฏิบัติตามแนวทางของเราอย่างเคร่งครัดเพื่อให้คำแนะนำและคำขอดึง (pull request) ของคุณได้รับการดำเนินการอย่างรวดเร็ว ที่สำคัญกว่านั้นคือจะช่วยให้ผู้อ่านของเราได้รับประสบการณ์ที่ดีและมีคุณภาพสูงอย่างสม่ำเสมอขณะอ่านและทำตามคู่มือ

แนวทางการมีส่วนร่วมเขียนคู่มือของเราแบ่งออกเป็นหัวข้อต่อไปนี้:

  • โครงสร้าง
  • สไตล์
  • การจัดรูปแบบ
  • คำศัพท์

เราแนะนำให้คุณอ่านหัวข้อเหล่านี้อย่างน้อยหนึ่งครั้งก่อนเริ่มเขียนเนื้อหา และยังเป็นแหล่งอ้างอิงที่ดีหากคุณไม่แน่ใจว่าจะจัดการกับบางอย่างอย่างไรในระหว่างกระบวนการสร้าง

โครงสร้าง​

คู่มือทั้งหมดของเราบน ZAP-Docs จะมีโครงสร้างที่ค่อนข้างสม่ำเสมอ เริ่มต้นด้วยบทนำสั้นๆ พร้อมกับข้อกำหนดเบื้องต้นหรือขั้นตอนการเตรียมตัว ตามด้วยเนื้อหาหลักและสรุปสั้นๆ

โครงสร้างอาจมีการปรับเปลี่ยนได้บ้างขึ้นอยู่กับประเภทของคู่มือที่สร้าง ซึ่งสามารถพูดคุยกับทีม ZAP-Docs ได้ในขั้นตอนการเสนอครั้งแรก คุณสามารถดูวิธีใช้หัวข้อผ่านส่วน headers ซึ่งทำผ่าน Markdown แบบดั้งเดิม

โครงสร้างที่เราคาดหวังโดยทั่วไปจะมีหัวข้อต่อไปนี้:

  • ชื่อหน้า (H1) - กำหนดผ่าน title metadata ที่ด้านบนของหน้า
  • บทนำ (H2) - ประโยคสั้นๆ 1-2 ประโยคที่อธิบายหัวข้อของคู่มือและที่สำคัญคืออธิบายวัตถุประสงค์ของคู่มือ
  • การเตรียมตัว (H2) - หัวข้อนี้ ไม่บังคับ ใช้เฉพาะเมื่อมีข้อกำหนดเบื้องต้นหรือขั้นตอนเตรียมตัวที่ต้องทำก่อนผู้อ่านจะทำตามคู่มือ เช่น คุณอาจอ้างอิงคู่มือ SSH Initial Access หากผู้ใช้ต้องล็อกอินเข้าเซิร์ฟเวอร์ก่อน หรืออาจแสดงซอฟต์แวร์และ/หรือฮาร์ดแวร์ที่จำเป็น หรือคำแนะนำการเตรียมซอฟต์แวร์ เช่น ไฟร์วอลล์ เราแนะนำให้คุณดูคู่มือใน เว็บไซต์ ZAP-Docs ว่ามีคู่มือที่ครอบคลุมขั้นตอนเหล่านี้หรือไม่ และถ้ามีให้ลิงก์ไปยังคู่มือนั้น
  • หัวข้อหลัก (H2) - ส่วนหลักแรกของคู่มือ ในหลายกรณีมักจะตั้งชื่อว่า การติดตั้ง ซึ่งจะมีหัวข้อย่อยต่างๆ สำหรับแต่ละขั้นตอน แต่ไม่จำเป็นต้องเป็นเช่นนั้นเสมอไป เช่น คู่มือเชิงข้อมูลอาจมีหัวข้อหลักที่ต่างออกไป
  • ตัวเลือก: หัวข้อย่อย 1 (H3)
  • ตัวเลือก: หัวข้อย่อย 2 (H3)
  • ...
  • ตัวเลือก: หัวข้ออื่นๆ (H2)
  • สรุป (H2) - ส่วนสุดท้ายของคู่มือ ควรปิดคู่มือด้วย 1-3 ประโยค อธิบายว่าผู้อ่านทำอะไรสำเร็จไปแล้ว และแนะนำให้ติดต่อทีมซัพพอร์ตหากยังมีปัญหา
การใช้หัวข้อย่อย (H3 & H4)

คุณควรใช้หัวข้อ H3 เพื่อสร้างหัวข้อย่อยภายในหัวข้อหลัก H2 เพื่อจัดระเบียบเนื้อหาที่ใหญ่ให้เป็นส่วนๆ ที่ชัดเจน ตัวอย่างดูได้จากหัวข้อ หัวข้อหลัก ข้างต้น

คุณยังสามารถใช้หัวข้อ H4 ได้ ซึ่งมีประโยชน์ถ้าคุณต้องการสร้างหัวข้อย่อยอีกระดับโดยไม่แสดงในโครงสร้างด้านขวาของคู่มือ และยังเหมาะสำหรับแบ่งหัวข้อ H3 ให้เล็กลงอีก

ถ้าใช้หัวข้อย่อย ควรมีหัวข้อย่อยอย่างน้อยสองหัวข้อขึ้นไปในหัวข้อหลัก มิฉะนั้นจะไม่สมเหตุสมผลที่จะมีหัวข้อย่อยเพียงหัวข้อเดียว

ในอนาคต เราจะเพิ่มเทมเพลตที่เตรียม Markdown ไว้ล่วงหน้าให้คุณ ซึ่งจะเป็นจุดเริ่มต้นที่ดีสำหรับการสร้างหน้าใหม่ เราจะเพิ่มเร็วๆ นี้

ชื่อเรื่อง​

ชื่อเรื่องควรกระชับและสะท้อนวัตถุประสงค์หลักของคู่มืออย่างชัดเจน คิดถึงสิ่งที่ผู้อ่านจะทำได้เมื่อจบ เช่น การติดตั้งเสร็จ การตั้งค่าบริการ หรือเข้าใจหัวข้อเทคนิคเฉพาะ ผลลัพธ์ควรเห็นได้ชัดจากชื่อเรื่องทันที

ชื่อเรื่องแต่ละเรื่องต้องขึ้นต้นด้วยคำนำหน้าประเภทผลิตภัณฑ์ที่เหมาะสม คำนำหน้านี้ควรตรงกับหมวดหมู่ที่คู่มืออยู่ในแถบด้านข้าง การดูคู่มือที่มีอยู่ในหมวดเดียวกันจะช่วยให้ใช้ชื่อเรื่องสม่ำเสมอ

ตัวอย่างเช่น คู่มือที่เกี่ยวกับผลิตภัณฑ์ VPS ควรมีโครงสร้างชื่อเรื่องแบบนี้: VPS: SteamCMD Linux Setup

ถ้าคู่มือเขียนในลักษณะทั่วไปและใช้ได้กับหลายผลิตภัณฑ์ เช่น การติดตั้งบริการหรือเซิร์ฟเวอร์เกมที่ใช้ได้ทั้ง VPS และ เซิร์ฟเวอร์เฉพาะ ชื่อผลิตภัณฑ์ไม่ควรใส่ในชื่อเรื่อง ในกรณีนี้คู่มือจะเป็นอิสระจากผลิตภัณฑ์และไม่ต้องมีคำนำหน้าผลิตภัณฑ์เฉพาะ

บทนำ​

บทนำของคู่มือควรสั้นและตรงประเด็น โดยทั่วไป 1-2 ประโยค ในเนื้อหาคุณควรอธิบายหัวข้อคร่าวๆ และที่สำคัญคือบอกผู้อ่านว่าคู่มือนี้จะนำเสนออะไรและเป้าหมายสุดท้ายคืออะไร

ตัวอย่างบทนำที่เหมาะสมสำหรับคู่มือเกี่ยวกับ SteamCMD คือ:

  • ประโยคที่ 1: SteamCMD เป็นเครื่องมือสำคัญที่จำเป็นสำหรับการติดตั้งเซิร์ฟเวอร์เฉพาะสำหรับเกมหลากหลาย เช่น Palworld, Enshrouded และอื่นๆ
  • ประโยคที่ 2: ในคู่มือนี้ เราจะสำรวจขั้นตอนการตั้งค่า SteamCMD ครั้งแรกบนเซิร์ฟเวอร์ Linux ของคุณ โดยใช้ Ubuntu เป็นตัวอย่าง แต่กระบวนการนี้ควรคล้ายกันกับดิสทริบิวชันอื่นๆ

จากตัวอย่างนี้ จะเห็นว่าบทนำสรุปหัวข้อที่เกี่ยวข้องและแสดงเป้าหมายโดยรวมให้ผู้อ่านเข้าใจ

การเตรียมตัว​

ส่วนการเตรียมตัวมีประโยชน์ในการชี้แจงข้อกำหนดเบื้องต้นที่ผู้อ่านต้องทำก่อนจะทำตามคู่มือได้ อาจเป็นซอฟต์แวร์หรือฮาร์ดแวร์ที่ต้องใช้ คำแนะนำการเตรียมซอฟต์แวร์ เช่น ไฟร์วอลล์ หรือแนะนำให้ล็อกอินเข้าเซิร์ฟเวอร์ผ่าน SSH หรือ RDP

เราแนะนำให้คุณค้นหาคู่มือใน เว็บไซต์ ZAP-Docs ว่ามีคู่มือที่ครอบคลุมหรือเกี่ยวข้องกับขั้นตอนเตรียมตัวที่คุณจะใส่หรือไม่ ถ้ามีคู่มือ เช่น SSH Initial Access ให้ลิงก์และแจ้งผู้อ่านให้ทำตามก่อนดำเนินการต่อ

ข้อกำหนดเบื้องต้นทั่วไปสำหรับคู่มือ เช่น:

  • ซอฟต์แวร์ที่ต้องใช้ (เช่น Git, Node.js, Python, Docker)
  • คู่มือที่ช่วยให้ผู้อ่านมีความรู้พื้นฐาน (เช่น หน้า ZAP-Docs อื่นๆ)
  • บัญชีผู้ใช้ เช่น API
  • การตั้งค่าที่จำเป็น (เช่น DNS/SSL)

ตัวอย่างสำหรับคู่มือ Reverse Proxy:

เพื่อการตั้งค่า reverse proxy คุณจะต้องมี Linux Server สำหรับโฮสต์ proxy server และควรเชื่อมต่อเข้าเซิร์ฟเวอร์นั้น ใช้คู่มือ [SSH Initial Access](vserver-linux-ssh.md) ของเรา หากต้องการความช่วยเหลือในการทำเช่นนี้ คุณจะต้องมีการเข้าถึงโดเมนที่คุณเป็นเจ้าของ สำหรับแต่ละซับโดเมนที่คุณวางแผนจะใช้ คุณควรสร้างระเบียน DNS แบบ `A` ชี้ไปยังที่อยู่ IP ของ Linux Server ของคุณ

หัวข้อหลัก​

ถึงเวลาที่จะเขียนเนื้อหาหลักของคู่มือ คุณสามารถใช้หัวข้อ H2, H3 และ H4 เพื่อจัดโครงสร้างคู่มืออย่างเหมาะสม โดยใช้ H2 สำหรับส่วนใหญ่และแบ่งย่อยด้วย H3 หรือ H4

ในหลายกรณี โดยเฉพาะคู่มือที่ครอบคลุมการตั้งค่าซอฟต์แวร์ มักจะใช้หัวข้อ การติดตั้ง ซึ่งแบ่งเป็นหัวข้อย่อย H3 หลายหัวข้อ หากคุณยังไม่แน่ใจโครงสร้างที่ถูกต้อง ไม่ต้องกังวล เราจะช่วยคุณวางแผนโครงสร้างคู่มือในขั้นตอนเสนอผลงาน

ในแต่ละส่วน ควรมีประโยคเริ่มต้นและปิดท้ายสั้นๆ เพื่อแจ้งผู้อ่านว่าทำอะไรไปแล้วและจะทำอะไรต่อไป ยกเว้นส่วนสุดท้ายที่ไม่จำเป็นต้องมีประโยคปิด เพราะจะต่อเนื่องไปยังสรุปโดยธรรมชาติ

ตัวอย่างประโยคเหล่านี้:

  • ประโยคเริ่มต้น: ในส่วนนี้ คุณจะผ่านกระบวนการตั้งค่าเพื่อปรับแต่งซอฟต์แวร์ตามที่คุณต้องการ
  • ประโยคปิดท้าย: เมื่อการตั้งค่าพร้อมและบันทึกไฟล์แล้ว ให้ไปยังส่วนถัดไปเพื่อสร้างบัญชีผู้ดูแลและเริ่มใช้งานซอฟต์แวร์

ประโยคเปลี่ยนผ่านเหล่านี้ช่วยให้ผู้อ่านเข้าใจบริบทและทำให้คู่มือไหลลื่น จำไว้ว่าคุณควรใช้ประโยคในรูปแบบบุรุษที่สอง (เช่น "คุณจะสร้าง") แทนบุรุษที่หนึ่งเมื่อเขียนเนื้อหาและประโยคเปลี่ยนผ่าน

สรุป​

ส่วนสุดท้ายคือสรุปคู่มือ ควรปิดคู่มือด้วย 1-3 ประโยค อธิบายว่าผู้อ่านทำอะไรสำเร็จไปแล้ว และแนะนำแหล่งข้อมูลเพิ่มเติมหรือคู่มืออื่นๆ ที่ผู้อ่านสามารถติดตามเพื่อเพิ่มพูนความรู้

ควรลิงก์ไปยังคู่มือ ZAP-Docs ที่มีอยู่ โดยเฉพาะคู่มือที่ต่อเนื่องจากคู่มือของคุณ และแนะนำให้ติดต่อทีมซัพพอร์ตหากผู้อ่านยังมีปัญหา

ตัวอย่างสรุปที่ดี:

คุณได้ตั้งค่าซอฟต์แวร์ให้ทำงานบนเซิร์ฟเวอร์ Linux ของคุณเรียบร้อยแล้ว! เราแนะนำให้ดูคู่มือบริการ Linux ในส่วนนี้เพื่อการติดตั้งบริการเพิ่มเติม

หากมีคำถามหรือขอความช่วยเหลือเพิ่มเติม อย่าลังเลที่จะติดต่อทีมซัพพอร์ตของเรา ซึ่งพร้อมช่วยเหลือคุณทุกวัน! 🙂

สไตล์​

สไตล์การเขียนสำหรับเอกสาร ZAP-Hosting มุ่งเน้นการสร้างคู่มือคุณภาพสูง ใช้งานได้จริง และเข้าถึงง่าย เพื่อรองรับหัวข้อหลากหลายและผู้อ่านทุกระดับประสบการณ์

เชิงเทคนิค & ถูกต้อง​

บทความของเราตั้งเป้าให้ถูกต้องทางเทคนิคและทันสมัยที่สุดเท่าที่จะเป็นไปได้ เราคาดหวังว่าบทความจะไม่เพียงช่วยให้ผู้ใช้บรรลุเป้าหมายสุดท้าย เช่น การเรียนรู้ การสร้าง หรือการตั้งค่าใหม่ แต่ยังช่วยให้เข้าใจสิ่งที่ทำในแต่ละขั้นตอนอย่างชัดเจน ทุกขั้นตอนที่คุณเขียนควรมีจุดประสงค์และคำอธิบาย พร้อมตัวเลือกหรือแฟล็กเพิ่มเติมเมื่อเหมาะสม คุณควรแจ้งผู้อ่านตลอดเวลาว่ากำลังทำอะไรและทำไมต้องทำเช่นนั้น

ผู้เขียนควรตรวจทานและทดสอบคู่มือเพื่อให้แน่ใจว่าทุกอย่างถูกต้องและทำงานตามที่ตั้งใจ ก่อนส่งคำขอดึง ทีมเอกสาร ZAP-Hosting จะอ่านและทดสอบคู่มือของคุณเพื่อให้แน่ใจว่าสม่ำเสมอและถูกต้อง หรือแนะนำปรับปรุงหากพบข้อผิดพลาด

เคล็ดลับ

เราแนะนำให้ผู้เขียนตรวจสอบการสะกดคำและไวยากรณ์ด้วยเครื่องมือตรวจสอบก่อนส่งคำขอดึง เว็บไซต์ที่แนะนำคือ: https://languagetool.org/

ใช้งานได้จริง & มีประโยชน์​

เมื่อผู้อ่านอ่านบทความจบ ควรได้เรียนรู้ สร้าง หรือ ตั้งค่าอะไรบางอย่างตั้งแต่ต้นจนจบ คู่มือของเราตั้งใจรองรับผู้อ่านทุกระดับประสบการณ์ ดังนั้นเนื้อหาของคุณควรครอบคลุมหัวข้ออย่างละเอียด รวมถึงข้อกำหนดเบื้องต้นด้วย ในฐานะผู้เขียน คุณควรส่งผู้อ่านไปยังเว็บไซต์ภายนอกเฉพาะเมื่อไม่มีเอกสารใน ZAP-Docs หรือเพื่อให้ผู้ใช้เก็บข้อมูลเพิ่มเติมที่ไม่จำเป็นสำหรับบทความแต่ช่วยเพิ่มความรู้ทางเทคนิคได้ หลีกเลี่ยงการลิงก์ไปยังเอกสารของคู่แข่ง

เป็นมิตร, เป็นทางการ & ครบถ้วน​

เราคาดหวังว่าเอกสารของเราจะทันสมัยและเป็นมิตร เพื่อให้ผู้อ่านทุกคนเข้าถึงได้ง่าย แต่ยังคงความเป็นทางการตลอดคู่มือ เราต้องการให้โทนการเขียนเหมาะสมกับผู้อ่านทุกระดับประสบการณ์และไม่ว่าจะมีข้อจำกัดทางภาษาอย่างไร

เนื่องจากคู่มือเน้นช่วยผู้อ่านเรียนรู้และบรรลุเป้าหมาย เราคาดหวังให้ผู้เขียนใช้ประโยคบุรุษที่สอง (เช่น "คุณต้อง...") แทนบุรุษที่หนึ่ง (เช่น "ผมคิดว่า...") เพื่อให้ผู้อ่านมีส่วนร่วมและโฟกัสที่ตัวผู้อ่าน

สุดท้าย ผู้เขียนทุกคนต้องปฏิบัติตามจรรยาบรรณของเรา เพื่อให้คู่มือยอมรับทุกคนโดยไม่คำนึงถึงอายุ เชื้อชาติ เพศ ระดับประสบการณ์ สัญชาติ ศาสนา ความเชื่อทางการเมือง รสนิยมทางเพศ สถานะทางสังคม หรือทางเลือกเทคโนโลยี หลีกเลี่ยงภาษาที่อาจก่อให้เกิดความไม่เหมาะสมหรือเนื้อหาที่เกี่ยวข้องกับหัวข้อเหล่านี้

การจัดรูปแบบ​

เอกสารของเราใช้ภาษา Markdown ซึ่งเป็นที่นิยมและใช้งานง่าย ไปดูส่วนต่างๆ ด้านล่างเพื่อเข้าใจวิธีใช้

เคล็ดลับ

สำหรับตัวอย่างและคำอธิบาย Markdown แบบละเอียด ดูได้ที่ Markdown Guide

หัวข้อ​

หัวข้อเป็นตัวเลือกการจัดรูปแบบที่สำคัญที่สุดในการแยกเนื้อหาอย่างชัดเจนและมีตรรกะ ชื่อหลักใช้ H1 แต่คุณไม่ควรใช้ในเนื้อหาโดยตรง ให้ใช้ title metadata ด้านบนของไฟล์แทน

ในคู่มือของเรา ใช้หัวข้อ H2 เพื่อแบ่งส่วนหลักของคู่มือ ตามด้วย H3 เพื่อแบ่งส่วนหลักเป็นหัวข้อย่อย เช่น แบ่งขั้นตอนต่างๆ เพื่อให้ง่ายต่อการทำตาม และยังมี H4 ที่ใช้ไม่บ่อย แต่มีไว้แบ่งหัวข้อย่อยอีกระดับโดยไม่แสดงในโครงสร้างคู่มือ

ข้อมูล

ถ้าใช้หัวข้อย่อย (เช่น H3 ภายใต้ H2) ต้องมีหัวข้อย่อยอย่างน้อยสองหัวข้อในส่วนเดียวกัน มิฉะนั้นถือว่าใช้ผิด

ตัวอย่างการใช้หัวข้อ:

## การติดตั้ง
H2 - ส่วนหลัก

### ดาวน์โหลดไฟล์เกม
H3 - หัวข้อย่อยของ H2

#### ผ่าน SteamCMD
H4 - หัวข้อย่อยของ H3

#### ด้วยตนเองผ่าน GitHub
H4 - หัวข้อย่อยของ H3

### เตรียมการตั้งค่า
H3 - หัวข้อย่อยของ H2

### เริ่มเซิร์ฟเวอร์
H3 - หัวข้อย่อยของ H2

Markdown แบบฝังในบรรทัด​

เราใช้การจัดรูปแบบหลายแบบเพื่อเพิ่มความอ่านง่ายและเหมาะกับผู้อ่านที่มีทักษะทางเทคนิคหลากหลาย อ่านต่อเพื่อเข้าใจการใช้งานแต่ละแบบ

ตัวหนา​

ใช้เน้นข้อมูลสำคัญ เช่น

  • เปลี่ยนบริบทระหว่างขั้นตอน
  • โฮสต์เนม, ข้อมูลล็อกอิน & ชื่อผู้ใช้
  • คำศัพท์สำคัญ

ใช้เครื่องหมายดอกจันคู่ล้อมรอบข้อความ เช่น **hello there** จะได้ hello there

ตัวเอียง​

ใช้แนะนำคำศัพท์เทคนิคใหม่ เช่น วันนี้เราจะตั้งค่า reverse proxy

ใช้เครื่องหมายดอกจันเดี่ยวล้อมรอบข้อความ เช่น *ZAP-Hosting - More POWER!* จะได้ ZAP-Hosting - More Power!

โค้ดฝังในบรรทัด​

ใช้แสดงข้อมูลเทคนิค เช่น URL รายละเอียดเพิ่มเติม เช่น

  • ชื่อไฟล์และเส้นทาง (เช่น C:/User/[your_name]/AppData....test.png)
  • URL (เช่น https://zap-hosting.com)
  • พอร์ต (เช่น :30120)
  • คำสั่ง (เช่น ipconfig)
  • คำสั่ง SQL (เช่น SELECT * FROM servers)
  • ปุ่มกด (เช่น ENTER หรือ CTRL + C)

ตาราง​

ตารางมีประโยชน์เมื่อแสดงข้อมูลซ้ำๆ เช่น คำสั่ง คำอธิบาย และการใช้งานในเกม ตัวอย่าง:

| คำสั่ง      | คำอธิบาย                | การใช้งาน             |
| ----------- | ------------------------ | --------------------- |
| /help       | ส่งคำสั่งช่วยเหลือ      | /help [category]      |
| /stop       | หยุดเซิร์ฟเวอร์          | /stop [true/false]    |

บล็อกโค้ด​

บล็อกโค้ดเหมาะสำหรับคู่มือที่ใช้คำสั่ง สคริปต์ หรือผลลัพธ์เทอร์มินัล

ใช้เครื่องหมาย ``` ล้อมรอบข้อความที่ต้องการ เช่น

function hello(name) {
    console.log(name)
}

var server = "ZAP-Hosting"
hello(server)

การใช้ Admonitions​

Admonitions ใช้เน้นข้อมูลสำคัญในคู่มือ มี 5 ประเภท แต่ละประเภทมีจุดประสงค์ต่างกัน

เมื่อใช้ admonitions ต้องกำหนดชื่อเรื่องชัดเจน เพื่อให้ผู้อ่านเข้าใจบริบทและความสำคัญทันทีโดยไม่ต้องอ่านเนื้อหาทั้งหมด

ไวยากรณ์เหมือนกันหมด แค่เปลี่ยนคำหลักตามประเภท:

:::warning[ชื่อเรื่อง]
	เนื้อหาของคุณที่นี่
:::

หมายเหตุ​

ตัวอย่าง: ข้อมูลเพิ่มเติม

ใช้สำหรับข้อมูลเสริมที่ช่วยผู้อ่านแต่ไม่จำเป็นต้องทำตามคู่มือ

เคล็ดลับ​

ตัวอย่าง: เคล็ดลับเพิ่มประสิทธิภาพ

ใช้แชร์คำแนะนำที่เป็นประโยชน์ วิธีปฏิบัติที่ดีที่สุด หรือการปรับปรุงประสิทธิภาพจากประสบการณ์

ข้อมูล​

ตัวอย่าง: ข้อกำหนดหรือรายละเอียดสำคัญ

ใช้สำหรับข้อมูลบริบทสำคัญที่ผู้อ่านควรทราบก่อนหรือระหว่างกระบวนการ

ระวัง​

ตัวอย่าง: ความเสี่ยงในการตั้งค่า

ใช้เตือนเกี่ยวกับปัญหาหรือข้อผิดพลาดที่อาจเกิดขึ้นขณะทำตามคู่มือ

อันตราย​

ตัวอย่าง: บั๊กที่รู้จักหรือฟีเจอร์เลิกใช้

ใช้สำหรับคำเตือนร้ายแรง เช่น บั๊กที่รู้จัก การกระทำที่ไม่สามารถย้อนกลับได้ ความเสี่ยงด้านความปลอดภัย หรือฟีเจอร์เลิกใช้ที่อาจก่อปัญหาใหญ่

ภาพหน้าจอ​

ภาพหน้าจอช่วยแนะนำผู้อ่านผ่านขั้นตอนด้วยภาพ เราแนะนำให้ใช้เมื่อเหมาะสม โปรดตรวจสอบให้แน่ใจว่าข้อความในภาพเป็นภาษาอังกฤษ เพราะเอกสารของเราเขียนเป็นภาษาอังกฤษและภาพเดียวกันจะใช้ในภาษาอื่นๆ ภาพควรมีความละเอียดสูงพอให้เห็นชัดเจน หลีกเลี่ยงภาพขนาดเล็กหรือครอปหนัก

ใช้ไวยากรณ์นี้เพื่อเพิ่มภาพหน้าจอ โดยแทนที่ your_url ด้วย URL ของภาพ:

![](your_url)

วิธีที่ดีที่สุดคือใช้เว็บไซต์อย่าง Imgur เพื่ออัปโหลดและใช้ภาพ หรือถ้าใช้ GitHub คุณสามารถลากภาพลงในช่องแก้ไขได้เลย ระบบจะอัปโหลดให้อัตโนมัติ

คำศัพท์​

ในเอกสารของเราจะมีคำศัพท์สำคัญหลากหลายคำ เราคาดหวังให้ใช้การสะกดแบบ US-English เพื่อความสม่ำเสมอ ในส่วนนี้เราจะกำหนดคำศัพท์ที่ใช้บ่อยให้เป็นมาตรฐาน

ผลิตภัณฑ์ ZAP-Hosting​

เมื่ออ้างอิงผลิตภัณฑ์ของ ZAP-Hosting ต้องใช้ชื่อที่ถูกต้อง สะกดและใช้ตัวพิมพ์ใหญ่ตามที่ปรากฏบน เว็บไซต์ ZAP-Hosting ในหน้าผลิตภัณฑ์นั้นๆ

แอตทริบิวต์ที่ผู้ใช้กำหนดเอง​

ในคู่มือส่วนใหญ่ ตัวเลือกการตั้งค่าสำหรับผู้ใช้ เช่น ชื่อผู้ใช้ โฮสต์เนม โดเมน ที่อยู่ IP และ URL จะต้องใช้ข้อมูลของผู้อ่านแทนที่ตัวอย่าง

โดยปกติ ให้ใช้รูปแบบ [your_attribute] เพื่อแยกความแตกต่างระหว่างข้อมูลคงที่กับข้อมูลเฉพาะ เช่น ถ้าเป็น IP ให้ใช้ [your_server_ip] หรือถ้าเป็น URL ให้ใช้ http://[your_server_ip]:30120

วิธีนี้ช่วยให้ผู้อ่านรู้ว่าต้องเปลี่ยนข้อมูลไหนตามการตั้งค่าของตัวเอง และควรอธิบายหรือแจ้งให้ผู้อ่านทราบถึงแอตทริบิวต์ที่ต้องเปลี่ยนเมื่อกล่าวถึงครั้งแรกเพื่อความเข้าใจ

ใช้ zaphosting เป็นค่าเริ่มต้นสำหรับโฮสต์เนม ชื่อผู้ใช้ หรือชื่อฐานข้อมูล

ซอฟต์แวร์​

เมื่อกล่าวถึงซอฟต์แวร์ในคู่มือ ต้องใช้การสะกดและตัวพิมพ์ใหญ่ที่ถูกต้องตามชื่อซอฟต์แวร์ หากเว็บไซต์ซอฟต์แวร์ไม่สม่ำเสมอ ให้ใช้รูปแบบเดียวกันตลอดบทความเพื่อความสม่ำเสมอ

ควรลิงก์ไปยังเว็บไซต์ทางการของซอฟต์แวร์เมื่อกล่าวถึงครั้งแรกและถ้ามีเว็บไซต์อย่างเป็นทางการ

การตั้งค่า Cookie