หลักการ สถานการณ์ และความเหมาะสม
แอปติดตามบนมือถือเป็นช่องทางเข้าถึงข้อมูลและเหตุการณ์ ไม่ใช่แหล่งความจริงของกระบวนการ ต้องแสดงเวลาเกิดเหตุ เวลาได้รับ และอายุข้อมูล เหมาะกับการติดตามนอกห้องควบคุม แต่ไม่ควรใช้ push notification เป็นกลไกป้องกันอันตรายเพียงอย่างเดียว
สำหรับผู้อ่านทั่วไป มือถือคล้ายสมุดส่งเวรที่ปรับปรุงข้อมูลได้ ไม่ใช่ผู้เฝ้าเครื่องที่เห็นทุกอย่างตลอดเวลา tag คือชื่อข้อมูลที่ผูกกับอุปกรณ์ ส่วน stale หมายถึงข้อมูลเก่าเกินช่วงที่เหมาะกับการตัดสินใจ ตัวเลขล่าสุดอาจยังดูปกติทั้งที่สถานการณ์เปลี่ยนไปแล้ว การออกแบบจึงควรทำให้คนเห็นอายุข้อมูลก่อนเห็นสีสถานะและเข้าใจว่าการเปิดอ่านข้อความต่างจากการยืนยันหน้างาน
ในเชิงวิธีควรแยกวงจรเหตุเป็นเกิดเหตุ รับผิดชอบ ตรวจสอบ และปิดเหตุ พร้อมหลักฐานแต่ละขั้น การลดการแจ้งเตือนช่วยให้ผู้ใช้ไม่ล้าแต่เสี่ยงซ่อนเหตุสำคัญ จึงต้องตกลงระดับความรุนแรงและผู้รับเวรกับเจ้าของกระบวนการ การเข้าถึงนอกสถานที่ยังต้องจำกัดตามบทบาท ไม่ให้ความสะดวกของหน้าจอกลายเป็นสิทธิ์ดูข้อมูลทุกโรงงานหรือสิทธิ์สั่งการที่ไม่เคยประเมิน
เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน
ตัวอย่างเชิงออกแบบ
ตัวอย่างเชิงออกแบบ: ผู้ดูแลเห็นค่าระดับถังล่าสุดพร้อมป้ายข้อมูลล้าสมัยเมื่อเครือข่ายขาด สามารถรับทราบเหตุและส่งต่อเวรได้ การรับทราบในแอปหมายถึงมีคนเห็นข้อความ ไม่ได้หมายความว่าแก้เหตุแล้ว
สถานการณ์สมมติ: ข้อมูลระดับมาจากเวลา 09:00 แต่มือถือได้รับเวลา 09:05 ผู้ใช้ต้องเห็นว่าข้อมูลมีอายุห้านาที ไม่ใช่ค่าที่วัดตอนเปิดจอ หากความสดที่งานกำหนดไว้สั้นกว่านั้น ควรเลือกติดต่อผู้ควบคุมในพื้นที่แทนการตัดสินใจจากตัวเลขค้าง เกณฑ์อายุเป็นสิ่งที่ต้องออกแบบเฉพาะงาน ไม่ใช่เวลาที่บทความรับประกัน
เมื่อส่งต่อเวร ผู้รับใหม่ควรเห็นเหตุที่ยังเปิด ผู้ที่กำลังตรวจ และบันทึกการติดต่อ ผู้รับเดิมไม่ควรปิดเหตุเพียงเพื่อให้รายการหายจากจอ หากเสนอฟังก์ชันส่งต่อในอนาคต ต้องทดสอบกรณีทั้งสองคนตอบพร้อมกันและคนหนึ่งออฟไลน์ เพื่อไม่ให้เหตุไม่มีเจ้าของหรือถูกปิดซ้ำโดยไม่มีผลตรวจ
ข้อมูลนำเข้าและเงื่อนไขเริ่มต้น
ระบุรายการ tag บทบาทผู้ใช้ ขอบเขตสถานที่ ช่องทางแจ้งเตือน และนโยบายอุปกรณ์ส่วนตัว เตรียมบัญชีทดสอบสำหรับผู้ดู ผู้รับทราบ และผู้อนุมัติแยกกัน
ข้อมูลเหตุควรมีรหัสที่ไม่เปลี่ยนเมื่อส่งซ้ำ เวลาแหล่งกำเนิด และชื่อสถานที่ที่คนเข้าใจ บัญชีทดสอบต้องไม่มีข้อมูลบุคคลจริงเกินจำเป็นและมีขอบเขตสิทธิ์เหมือนบทบาทที่ต้องตรวจ
ผลบนจอควรแยกสถานะข้อมูลกับสถานะการดำเนินงาน เช่น อ่านไม่ได้แต่มีคนรับตรวจแล้ว พร้อมแสดงว่าเครือข่ายขาด ไม่ใช้คำว่าเรียบร้อยคำเดียวครอบคลุมทั้งการส่งข้อความและการแก้เหตุ
ขั้นตอนทดลองและเชื่อมงาน
- 1ออกแบบ API แบบอ่านอย่างเดียวก่อนและตรวจสิทธิ์ถึงระดับทรัพยากร
- 2แสดงเวลา คุณภาพข้อมูล และสถานะ offline โดยไม่แสดงค่าค้างเป็นค่าปัจจุบัน
- 3ทดสอบการรับทราบ การส่งต่อเวร การออกจากระบบ และการเพิกถอนอุปกรณ์
การประเมินและเกณฑ์ตรวจรับ
วัดเวลาจากเหตุถึงจอจริงแยกจากเวลาส่ง push ตรวจข้อความซ้ำ ขาดหาย และมาถึงผิดลำดับในเครือข่ายสลับสัญญาณ การตรวจรับควรครอบคลุมสิทธิ์ข้อมูลและสถานะ stale มากกว่าความลื่นไหลของหน้าจออย่างเดียว
ทดสอบด้วยเหตุจำลองเมื่อจอล็อก แอปอยู่เบื้องหลัง และผู้ใช้เปลี่ยนเครือข่าย ตรวจว่าข้อความที่มาช้าไม่ทำให้เหตุเก่าดูเหมือนเพิ่งเกิด รวมการส่งต่อหลังเปลี่ยนเวรด้วย
ให้ผู้ใช้ทดลองอธิบายจากจอว่าอะไรยังไม่รู้และต้องติดต่อใคร ถ้าตีความสีเขียวเป็นการยืนยันว่าหน้างานปลอดภัย ต้องแก้ภาษาหรือการจัดวางก่อนรับงาน แม้การเชื่อมข้อมูลทางเทคนิคจะผ่านแล้ว
เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน
กรณีล้มเหลวและข้อจำกัด
ระบบปฏิบัติการอาจพักแอป ปิดแจ้งเตือน หรือจำกัดงานเบื้องหลัง มือถือที่สูญหายและภาพหน้าจอเป็นความเสี่ยงข้อมูล คำสั่งควบคุมระยะไกลหากมีต้องผ่านการประเมินแยก ไม่อนุมานว่าการมีแอปหมายถึงสั่งเครื่องจักรได้
การเก็บข้อมูลออฟไลน์ช่วยอ่านย้อนหลังแต่เพิ่มข้อมูลบนอุปกรณ์ส่วนตัว ควรกำหนดอายุเก็บ การออกจากบัญชี และขั้นตอนเครื่องหายร่วมกับผู้รับผิดชอบข้อมูล ไม่ติดตามตำแหน่งผู้ใช้โดยไม่มีวัตถุประสงค์จำเป็น
ผู้ใช้บางคนไม่มีสัญญาณหรือไม่สามารถใช้มือถือขณะทำงาน ต้องมีช่องทางส่งเวรและรับเหตุอื่นที่เหมาะสม การเสนอการแจ้งเตือนหลายช่องทางเป็นแนวคิดออกแบบ ไม่ใช่คำยืนยันว่ามีบริการพร้อมใช้หรือรับประกันการถึงทุกครั้ง
รายการตรวจสอบก่อนใช้งาน
- ข้อมูลเก่ามีเวลาและคำเตือนชัดเจนหรือไม่
- เพิกถอน session ของเครื่องที่หายได้หรือไม่
- แยกการรับทราบจากการปิดเหตุแล้วหรือไม่