งานพื้นหลังพร้อมการอัพเดตความคืบหน้า: รูปแบบ UI ที่ใช้ได้จริง

ทำไมผู้ใช้ถึงติดขัดเมื่อมีงานทำเบื้องหลัง

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

งานเบื้องหลังที่ดีเกี่ยวกับความมั่นใจ ผู้ใช้ต้องการสามอย่าง:

• สถานะที่ชัดเจน (รอคิว, กำลังทำงาน, เสร็จ)
• ความรู้สึกเรื่องเวลา (แม้เป็นประมาณการคร่าว ๆ)
• การกระทำถัดไปที่ชัดเจน (รอ, ทำงานต่อ, ยกเลิก, หรือกลับมาทีหลัง)

ถ้าไม่มีสิ่งเหล่านี้ งานอาจกำลังทำงานได้ดี แต่ประสบการณ์จะรู้สึกพัง

ความเข้าใจผิดที่พบบ่อยคือการปฏิบัติงานขอเว็บที่ช้าเหมือนงานพื้นหลังจริง ๆ การเรียกที่ช้าคือการเรียกเว็บเดียวที่ทำให้ผู้ใช้รอ งานพื้นหลังต่างออกไป: คุณเริ่มงาน คืนการยืนยันทันที และการประมวลผลหนักเกิดขึ้นที่อื่นขณะที่ UI ใช้งานได้ต่อ

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

องค์ประกอบหลัก: งาน คิว เวิร์กเกอร์ และสถานะ

เมื่อคนพูดถึงงานพื้นหลังพร้อมการอัพเดตความคืบหน้า พวกเขามักหมายถึงสี่ส่วนที่ทำงานร่วมกัน

งาน (job) คือหน่วยงาน: "นำเข้า CSV นี้", "สร้างรายงานนี้" หรือ "ส่งอีเมล 5,000 ฉบับ" คิวคือแถวรอที่งานนั่งจนกว่าจะมีการประมวลผล เวิร์กเกอร์ดึงงานจากคิวและทำงาน (ทีละงานหรือขนาน)

สำหรับ UI ส่วนสำคัญที่สุดคือ สถานะวงจรชีวิตของงาน เก็บสถานะให้น้อยและคาดเดาได้:

• รอคิว (Queued): รับแล้ว รอเวิร์กเกอร์
• กำลังทำงาน (Running): กำลังประมวลผล
• เสร็จ (Done): เสร็จสมบูรณ์
• ล้มเหลว (Failed): หยุดด้วยข้อผิดพลาด

ทุกงานต้องมี job ID (อ้างอิงที่ไม่ซ้ำ) เมื่อผู้ใช้คลิกปุ่ม ให้คืน ID นั้นทันทีและแสดงแถว "งานเริ่มแล้ว" ในพาเนลงาน

จากนั้นคุณต้องมีวิธีถามว่า "เกิดอะไรขึ้นตอนนี้?" นั่นมักเป็น endpoint สถานะ (หรือเมธอดอ่านใด ๆ) ที่รับ job ID แล้วคืนสถานะพร้อมรายละเอียดความคืบหน้า UI ใช้มันเพื่อแสดงเปอร์เซ็นต์ เส้นตอนปัจจุบัน และข้อความใด ๆ

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

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

ถ้าคุณสร้างบนแพลตฟอร์มอย่าง AppMaster ให้ปฏิบัติต่อที่เก็บสถานะเหมือนโมเดลข้อมูลอื่น: UI อ่านด้วย job ID และเวิร์กเกอร์อัพเดตเมื่อมันเดินงาน

เลือกรูปแบบคิวให้ตรงกับปริมาณงานของคุณ

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

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

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

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

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

ออกแบบโมเดลความคืบหน้าที่คุณสามารถแสดงใน UI ได้จริง

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

สคีมาสถานะง่าย ๆ ที่งานส่วนใหญ่รองรับได้มีลักษณะดังนี้:

• state: queued, running, succeeded, failed, canceled
• percent: 0–100 เมื่อวัดได้
• message: ประโยคสั้น ๆ ที่ผู้ใช้เข้าใจ
• timestamps: created, started, last_updated, finished
• result_summary: จำนวนเช่น processed, skipped, errors

ต่อไป กำหนดความหมายของ "ความคืบหน้า"

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

กฎปฏิบัติ:

• ใช้ เปอร์เซ็นต์ เมื่อคุณรายงานได้ว่า "X ของ Y"
• ใช้ ขั้นตอน เมื่อระยะเวลาไม่แน่นอน (เช่น ตรวจสอบไฟล์, นำเข้า, สร้างดัชนี, สรุป)
• ใช้ ความคืบหน้าไม่แน่นอน (indeterminate) เมื่อไม่สามารถใช้ทั้งสองได้ แต่ให้ข้อความสดใหม่

เก็บผลลัพธ์บางส่วนในขณะที่งานรัน นั่นทำให้ UI แสดงอะไรที่มีประโยชน์ได้ก่อนงานจะเสร็จ เช่น นับข้อผิดพลาดสดหรือพรีวิวสิ่งที่เปลี่ยน สำหรับการนำเข้า CSV คุณอาจบันทึก rows_read, rows_created, rows_updated, rows_rejected พร้อมข้อความผิดพลาดล่าสุดไม่กี่รายการ

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

วิธีส่งอัพเดตความคืบหน้า: โพลลิง พุช และแบบผสม

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

โพลลิงคือวิธีง่ายสุด: UI ถามสถานะทุก N วินาที ค่าเริ่มต้นที่ดีคือ 2–5 วินาทีขณะที่ผู้ใช้กำลังดู แล้วค่อยถอยช้าลงเมื่อเวลาเพิ่มขึ้น ถ้างานครบรอบนานกว่า 1 นาที ให้ย้ายเป็น 10–30 วินาที ถ้าแท็บอยู่เบื้องหลัง ให้ชะลอมากขึ้น

พุช (WebSockets, server-sent events, หรือการแจ้งเตือนมือถือ) ช่วยเมื่อความคืบหน้าเปลี่ยนเร็วหรือผู้ใช้ต้องการความทันท่วงที พุชเหมาะกับความทันที แต่คุณยังต้องมีการสำรองเมื่อการเชื่อมต่อหลุด

แนวทางผสมมักดีที่สุด: โพลลิงเร็วช่วงต้น (เพื่อให้ UI เห็นการเปลี่ยนจากรอคิวเป็นกำลังทำงานเร็ว) แล้วชะลอลงเมื่อการทำงานนิ่ง ถ้าเพิ่มพุชไว้ ให้มีโพลลิงช้าเป็นตาข่ายนิรภัย

เมื่ออัพเดตหยุด ให้จัดเป็นสถานะชั้นหนึ่ง แสดง "อัพเดตล่าสุดเมื่อ 2 นาทีที่แล้ว" และเสนอปุ่มรีเฟรช ฝั่งแบ็กเอนด์ให้มาร์กงานเป็น stale ถ้าไม่มี heartbeat

รูปแบบ UI สำหรับงานระยะยาวที่ชัดเจน

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

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

ใช้คำเรียบง่ายและมีประโยชน์ข้างตัวชี้วัดความคืบหน้า เช่น "นำเข้า 3,200 แถว (1,140 ประมวลผลแล้ว)" แทนที่จะเขียนว่า "กำลังประมวลผล" เพิ่มประโยคสั้น ๆ ที่ตอบว่า: ฉันออกไปได้ไหม และจะเกิดอะไรขึ้น เช่น: "คุณปิดหน้าต่างนี้ได้ เราจะนำเข้าเบื้องหลังและแจ้งเมื่อเสร็จแล้ว"

ตำแหน่งที่ความคืบหน้าปรากฏควรตรงกับบริบทผู้ใช้:

• ม็อดอล เหมาะเมื่องานบล็อกขั้นตอนถัดไป (เช่น สร้าง PDF ใบแจ้งหนี้ที่ต้องใช้ตอนนี้)
• โทสต์ เหมาะกับงานเร็วที่ไม่ควรกวน
• ความคืบหน้าแบบอินไลน์ในแถวตาราง เหมาะกับงานต่อรายการ

สำหรับงานนานกว่า 1 นาที ให้เพิ่มหน้า Jobs (หรือพาเนล Activity) เพื่อให้ผู้คนหางานได้ภายหลัง

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

รายงาน "เสร็จแต่มีข้อผิดพลาด" โดยไม่ทำให้ผู้ใช้สับสน

"เสร็จ" ไม่จำเป็นต้องเป็นชัยชนะเสมอไป เมื่องานพื้นหลังประมวลผล 9,500 ระเบียนแล้วล้มเหลว 120 รายการ ผู้ใช้ต้องเข้าใจว่าเกิดอะไรขึ้นโดยไม่ต้องอ่านล็อก

ปฏิบัติต่อความสำเร็จบางส่วนเป็นผลลัพธ์จริง ในบรรทัดสถานะหลัก แสดงทั้งสองด้านชัดเจน: "นำเข้า 9,380 จาก 9,500. ล้มเหลว 120" นั่นรักษาความเชื่อถือเพราะระบบซื่อสัตย์ และยืนยันว่างานถูกบันทึก

จากนั้นแสดงสรุปข้อผิดพลาดเล็ก ๆ ที่ผู้ใช้สามารถจัดการได้: "ฟิลด์บังคับหาย (63)" และ "รูปแบบวันที่ไม่ถูกต้อง (41)" ในสถานะสุดท้าย "เสร็จพร้อมปัญหา" มักชัดกว่า "ล้มเหลว" เพราะไม่สื่อว่าทุกอย่างล้มเหลว

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

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

ยกเลิกและลองใหม่ที่ผู้ใช้เชื่อถือได้

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

โดยปกติจะมีสองโหมดยกเลิกที่ถูกต้อง:

• "หยุดทันที": เวิร์กเกอร์ตรวจแฟลกยกเลิกบ่อยและยุติเร็ว
• "หยุดหลังขั้นตอนนี้": ขั้นตอนปัจจุบันเสร็จแล้ว งานจะหยุดก่อนเริ่มขั้นตอนถัดไป

ใน UI ให้แสดงสถานะกลางเช่น "กำลังร้องขอการยกเลิก" เพื่อผู้ใช้จะไม่คลิกซ้ำ

ทำให้การยกเลิกปลอดภัยโดยออกแบบงานให้ทำซ้ำได้ หากงานเขียนข้อมูล ให้ใช้การดำเนินการที่ idempotent และทำความสะอาดเมื่อจำเป็น ตัวอย่าง เช่น หากการนำเข้า CSV สร้างเรคอร์ด ให้เก็บ job-run ID เพื่อดูสิ่งที่เปลี่ยนในการรัน #123

การลองใหม่ต้องชัดเจนเหมือนกัน การลองรันเดิมอาจสมเหตุสมผลเมื่อมันสามารถต่อได้ การสร้าง job ใหม่ปลอดภัยกว่าเมื่อคุณต้องการการรันที่สะอาดพร้อม timestamp และ audit trail ใหม่ อธิบายชัดเจนว่าจะเกิดอะไรขึ้นและอะไรจะไม่เกิดขึ้น

แนวป้องกันที่ช่วยให้ยกเลิกและลองใหม่คาดเดาได้:

• จำกัดจำนวนครั้งของ retry และแสดงจำนวน
• ห้าม Retry ขณะที่งานกำลังรันเพื่อป้องกันการรันซ้อน
• ขอการยืนยันเมื่อการลองใหม่อาจทำให้เกิด side effects ซ้ำ (อีเมล, การชำระเงิน, การส่งออก)
• แสดงข้อผิดพลาดล่าสุดและขั้นตอนสำเร็จล่าสุดในพาเนลรายละเอียด

ทีละขั้นตอน: โฟลว์จากการคลิกถึงการจบงาน

โฟลว์ที่ดีเริ่มด้วยกฎข้อเดียว: UI ไม่ควรรอการทำงานเอง มันควรรอเพียง job ID

โฟลว์ (จากคลิกผู้ใช้ถึงสถานะสุดท้าย)

1. ผู้ใช้เริ่มงาน, API คืนค่าเร็ว. เมื่อผู้ใช้คลิก Import หรือ Generate report เซิร์ฟเวอร์สร้างเรคอร์ดงานและคืน job ID ทันที

2. ใส่งานในคิวและตั้งสถานะแรก. ใส่ job ID ลงคิวและตั้งสถานะเป็นรอคิวพร้อม progress 0% ให้ UI มีสิ่งที่แสดงได้แม้ก่อนเวิร์กเกอร์จะดึงงาน

3. เวิร์กเกอร์รันและรายงานความคืบหน้า. เมื่อเวิร์กเกอร์เริ่ม ให้ตั้งสถานะเป็นกำลังทำงาน เก็บเวลาเริ่ม และอัพเดตความคืบหน้าเป็นช่วงเล็ก ๆ ซื่อสัตย์ หากไม่สามารถวัดเปอร์เซ็นต์ได้ ให้แสดงขั้นตอนเช่น Parsing, Validating, Saving

4. UI ทำให้ผู้ใช้มีทิศทาง. UI โพลหรือสมัครรับอัพเดตและเรนเดอร์สถานะชัดเจน แสดงข้อความสั้น ๆ (กำลังทำอะไร) และเฉพาะการกระทำที่สมเหตุสมผลในตอนนั้น

5. สรุปด้วยผลลัพธ์ที่ทนทาน. เมื่อเสร็จ ให้เก็บเวลา finish, เอาต์พุต (ref ดาวน์โหลด, ID ที่สร้าง, สรุปจำนวน), และรายละเอียดข้อผิดพลาด รองรับสถานะเสร็จพร้อมข้อผิดพลาดเป็นผลลัพธ์หนึ่ง ไม่ใช่ความสำเร็จที่คลุมเครือ

กฎการยกเลิกและลองใหม่

การยกเลิกควรชัดเจน: คำขอยกเลิกแจ้งไปยังระบบแล้วเวิร์กเกอร์รับทราบและมาร์กสถานะเป็นยกเลิก การลองใหม่ควรสร้าง job ID ใหม่ เก็บของเดิมเป็นประวัติ และอธิบายว่าจะรันอะไรอีกครั้ง

ตัวอย่างสถานการณ์: นำเข้า CSV พร้อมความคืบหน้าและความล้มเหลวบางส่วน

จุดที่พบบ่อยที่งานพื้นหลังสำคัญคือการนำเข้า CSV นึกภาพ CRM ที่คนฝ่ายขายอัพโหลด customers.csv จำนวน 8,420 แถว

ทันทีที่อัพโหลด UI ควรเปลี่ยนจาก "ฉันคลิกปุ่ม" เป็น "มีงานแล้ว คุณกลับได้" การ์ดงานง่าย ๆ ในหน้า Imports จะได้ผลดี:

• อัพโหลดรับแล้ว: "ไฟล์ได้รับแล้ว กำลังตรวจคอลัมน์..."
• รอคิว: "รอเวิร์กเกอร์ว่าง (รออยู่ 2 งาน)"
• กำลังทำงาน: "นำเข้าลูกค้า: 3,180 จาก 8,420 ประมวลผลแล้ว (38%)"
• สรุป: "บันทึกผลและสร้างรายงาน..."

ขณะรัน ให้แสดงตัวเลขความคืบหน้าหนึ่งค่าที่ผู้ใช้เชื่อถือได้ (แถวที่ประมวลผล) และบรรทัดสถานะสั้น ๆ (กำลังทำอะไร) หากผู้ใช้ไปหน้าต่างอื่น ให้เก็บงานไว้ในพื้นที่ Recent jobs

เมื่อเพิ่มความล้มเหลวบางส่วน เมื่อจบงาน อย่าขึ้นแบนเนอร์ "ล้มเหลว" ที่น่ากลัวถ้าส่วนใหญ่เรียบร้อย ให้ใช้ "เสร็จพร้อมปัญหา" พร้อมแยกสัดส่วนชัดเจน:

นำเข้า 8,102 ลูกค้า. ข้าม 318 แถว.

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

การลองใหม่ควรรู้สึกปลอดภัยและชัดเจน การกระทำหลักอาจเป็น Retry failed rows ที่สร้างงานใหม่เพียงแถว 318 ที่ข้ามหลังจากผู้ใช้แก้ไข CSV เก็บงานเดิมให้อ่านได้เพื่อให้ประวัติยังคงจริง

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

ข้อผิดพลาดที่พบบ่อยซึ่งทำให้ความคืบหน้าและการลองใหม่สับสน

วิธีเร็วที่สุดที่จะเสียความเชื่อถือคือแสดงตัวเลขที่ไม่จริง แถบความคืบหน้าที่ติดที่ 0% สองนาทีแล้วกระโดดเป็น 90% ให้ความรู้สึกว่าเดาได้ ถ้าคุณไม่รู้เปอร์เซ็นต์ที่แท้จริง ให้แสดงขั้นตอน (Queued, Processing, Finalizing) หรือ "X จาก Y รายการประมวลผลแล้ว"

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

UX ของการลองใหม่พังเมื่อผู้ใช้สามารถเริ่มงานเดียวกันหลายครั้ง หากปุ่ม Import CSV ยังคงใช้งานได้ คนคลิกสองครั้งและสร้างข้อมูลซ้ำ การลองใหม่จะไม่ชัดเจนเพราะไม่รู้ว่าควรแก้ที่การรันไหน

ข้อผิดพลาดที่เห็นบ่อย:

• เปอร์เซ็นต์ปลอมที่ไม่ตรงกับงานจริง
• ข้อผิดพลาดเชิงเทคนิคแสดงให้ผู้ใช้เห็น (stack traces, codes)
• ไม่มีการจัดการ timeout, ซ้ำ หรือ idempotency
• การลองใหม่ที่สร้างงานใหม่โดยไม่อธิบายว่าจะเกิดอะไรขึ้น
• การยกเลิกที่เปลี่ยนแค่ UI แต่ไม่กระทบพฤติกรรมเวิร์กเกอร์

รายละเอียดเล็ก ๆ ที่สำคัญ: แยกข้อความสำหรับผู้ใช้กับรายละเอียดสำหรับนักพัฒนา แสดง "12 แถวตรวจสอบไม่ผ่าน" ให้ผู้ใช้ และเก็บ trace ทางเทคนิคไว้ในล็อก

เช็คลิสต์ด่วนก่อนส่งงานพื้นหลังให้ผู้ใช้

ก่อนปล่อย ให้ตรวจดูส่วนที่ผู้ใช้สังเกตเห็น: ความชัดเจน ความเชื่อถือ และการกู้คืน

ทุกงานควรแสดง snapshot ที่คุณสามารถเอาไปแสดงที่ไหนก็ได้: สถานะ (queued, running, succeeded, failed, canceled), ความคืบหน้า (0–100 หรือขั้นตอน), ข้อความสั้น, timestamps (created, started, finished), และ pointer ผลลัพธ์ (ที่ออกหรือรายงานอยู่ที่ไหน)

ทำให้สถานะ UI ชัดเจนและสอดคล้อง ผู้ใช้ต้องมีที่เดียวที่เชื่อถือได้ในการหางานปัจจุบันและงานในอดีต รวมถึงป้ายชัดเมื่อพวกเขากลับมา ("เสร็จเมื่อวานนี้", "กำลังรัน") พาเนล Recent jobs มักช่วยป้องกันการคลิกซ้ำและงานซ้ำ

กำหนดกฎการยกเลิกและลองใหม่เป็นคำง่าย ๆ ตัดสินใจว่า Cancel หมายถึงอะไรสำหรับแต่ละงาน, ยอมให้ retry หรือไม่, และจะใช้ข้อมูลเดิมอย่างไร (อินพุตเดิม, job ID ใหม่) แล้วทดสอบกรณีขอบเช่น ยกเลิกก่อนเสร็จ

ปฏิบัติต่อความล้มเหลวบางส่วนเป็นผลลัพธ์จริง แสดงสรุปสั้น ๆ ("นำเข้า 97, ข้าม 3") และให้รายงานที่ผู้ใช้สามารถใช้แก้ไขได้ทันที

วางแผนการกู้คืน งานควรรอดจากการรีสตาร์ท และงานที่ค้างควร timeout เป็นสถานะชัดเจนพร้อมคำแนะนำ ("ลองอีกครั้ง" หรือ "ติดต่อซัพพอร์ตพร้อม job ID")

ขั้นตอนถัดไป: ทำเวิร์กโฟลว์หนึ่งอย่างแล้วขยายจากตรงนั้น

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

หน้าประวัติงานง่าย ๆ มักเป็นการปรับปรุงคุณภาพครั้งใหญ่ มันให้ที่ให้ผู้คนกลับมาดู แทนที่จะจ้องสปินเนอร์

เลือกวิธีส่งความคืบหน้าแบบหนึ่งก่อน โพลลิงใช้ได้สำหรับเวอร์ชันหนึ่ง ตั้งอินเทอร์วอลให้พอรักษาแบ็กเอนด์แต่ยังรู้สึกมีชีวิต

ลำดับการสร้างที่ปฏิบัติได้เพื่อหลีกเลี่ยงการเขียนซ้ำ:

• ลงมือสร้างสถานะงานและการเปลี่ยนสถานะก่อน (queued, running, succeeded, failed, finished-with-errors)
• เพิ่มหน้าประวัติงานพร้อมตัวกรองพื้นฐาน (24 ชั่วโมงล่าสุด, เฉพาะงานของฉัน)
• เพิ่มตัวเลขความคืบหน้าเมื่อคุณมั่นใจว่าจะทำให้มันซื่อสัตย์
• เพิ่มปุ่มยกเลิกหลังจากที่คุณรับประกันการทำความสะอาดที่สม่ำเสมอ
• เพิ่ม Retry หลังจากมั่นใจว่างานเป็น idempotent

ถ้าคุณสร้างโดยไม่เขียนโค้ด แพลตฟอร์ม no-code เช่น AppMaster ช่วยโดยให้คุณออกแบบตารางสถานะงาน (PostgreSQL) และอัพเดตจากเวิร์กโฟลว์ แล้วเรนเดอร์สถานะนั้นทั้งเว็บและมือถือ สำหรับทีมที่ต้องการที่เดียวในการสร้าง backend, UI, และลอจิกพื้นหลัง AppMaster (appmaster.io) ถูกออกแบบมาสำหรับแอปเต็มรูปแบบ ไม่ใช่แค่ฟอร์มหรือหน้า