หน้าเขียนข้อความหรือฟอร์มที่ใช้เวลานานมักมีการเก็บ draft ใน browser เพื่อให้กลับมาเปิดต่อได้ หากเผลอปิดแท็บหรือเน็ตหลุด วิธีนี้ช่วยลดงานที่คนต้องกรอกซ้ำ แต่คำว่าบันทึกแล้วบนหน้าจอยังต้องบอกให้ชัดว่าอยู่ที่ใด
ถ้าข้อมูลถูกเก็บเพียงในเครื่องหนึ่ง คนเปิดจากอีกเครื่องก็อาจยังไม่เห็น และถ้า browser ล้างพื้นที่ของไซต์ ข้อมูลที่ยังไม่ส่งต่อก็อาจไม่อยู่ให้กู้จาก server การเก็บในเครื่องจึงมีบทบาทต่างจากการยืนยันว่าบริการรับฉบับนั้นไว้แล้ว
ก่อนทำป้าย autosave จึงควรนิยามเส้นทางของ draft ครับ ว่าแต่ละจังหวะเก็บถึงชั้นไหนและยังมีข้อมูลใดที่ผู้ใช้ต้องรับรู้ว่ายังไม่ sync
ข้อมูลที่เก็บจากเว็บไซต์มีขอบเขตตาม origin ซึ่งเกี่ยวข้องกับ scheme host และ port ตามกลไกของเว็บ หากย้ายจาก HTTP ไป HTTPS เปลี่ยน host หรือเปิดสภาพแวดล้อมอีก port ก็ไม่ควรคาดว่าจะเห็นข้อมูลจากพื้นที่เดิมผ่าน API เดียวกันเอง
โปรไฟล์ browser กับอุปกรณ์คนละเครื่องก็เป็นอีกบริบทที่แยกกัน การเห็น draft ใน Chrome เครื่องหนึ่งจึงไม่ได้ยืนยันว่าอีก browser หรือโทรศัพท์มีสำเนาฉบับเดียวกันแล้ว เว้นแต่แอปมีการส่งและรับข้อมูลระหว่างกันตามที่ออกแบบ
เมื่อมีผู้ใช้หลายบัญชีบน origin เดียวกัน แอปยังต้องแยกขอบเขตเจ้าของ draft ไม่เก็บด้วย document ID อย่างเดียวแล้วเปิดให้บัญชีถัดไปเห็นตาม key เดิม การจำกัดตาม origin ไม่ได้จัดสิทธิ์ระดับบัญชีของผลิตภัณฑ์ให้เอง
Web Storage อย่าง localStorage เหมาะกับข้อมูล key-value แบบข้อความตามขอบเขตของ API ส่วน IndexedDB รองรับข้อมูลมีโครงสร้างกับการทำงานผ่าน transaction เหมาะให้พิจารณาเมื่อมีรายการหรือข้อมูลที่ต้องจัดการมากขึ้น แต่ก็มีขั้นตอนและอายุ transaction ที่ต้องใช้ให้ถูก
การมี transaction ใน IndexedDB ยังอยู่ในขอบเขตข้อมูลฝั่ง browser ไม่ได้ทำให้การเขียนที่ server อยู่ใน transaction เดียวกันด้วย หากกดส่งแล้วเน็ตขาดหลัง server บันทึก ต้องมีวิธีตามผลการส่งแยกเหมือนงานเครือข่ายอื่น
สำหรับ draft ควรมีข้อมูลประกอบพอแยกรุ่น เช่น เจ้าของรายการ ฉบับที่แก้ เวลาที่บันทึกในเครื่อง และสถานะการส่ง ไม่พึ่งเพียงข้อความล่าสุดโดยไม่รู้ว่ามันอ้างข้อมูลจาก server รุ่นใดอยู่ เพราะจะตัดสินการชนกันเมื่อกลับมาออนไลน์ได้ยาก
พื้นที่จัดเก็บมีขอบเขตและนโยบายของ browser การเขียนอาจไม่ผ่าน เช่น ถึงโควตาที่ใช้ได้หรือมีเงื่อนไขจำกัดในบริบทนั้น แอปจึงต้องตรวจผลและจัดการข้อผิดพลาด ไม่ขึ้นข้อความว่าบันทึกในเครื่องแล้วตั้งแต่ก่อนขั้นเขียนยืนยันสำเร็จ
โควตาไม่ได้เป็นตัวเลขเดียวที่ใช้กับทุก API ทุก browser และทุกเครื่อง จึงควรอ่านข้อกำหนดที่เกี่ยวข้องและตรวจในสภาพที่ต้องรองรับ หากใช้ข้อมูลประมาณพื้นที่จาก API ก็ต้องเข้าใจว่ามันเป็นข้อมูลสำหรับประเมิน ไม่ใช่การจอง byte ทั้งหมดไว้ให้แอปแน่นอนแล้ว
เมื่อมีข้อผิดพลาดควรรักษาข้อความที่คนกำลังกรอกไว้ในหน้าจอ และบอกว่าเก็บอัตโนมัติไม่สำเร็จพร้อมทางที่ทำต่อได้ตามผลิตภัณฑ์ เช่น ส่งออกฉบับหรือเชื่อมต่อเพื่อส่งขึ้นบริการ ไม่ลบเนื้อหาเดิมเพื่อคืนพื้นที่ก่อนมีสำเนาที่ตรวจแล้ว
ข้อมูลของ origin โดยทั่วไปอยู่ภายใต้นโยบาย best-effort ของ browser ซึ่งอาจถูกเก็บกวาดเมื่อมีแรงกดดันด้านพื้นที่หรือเงื่อนไขที่ browser กำหนด และผู้ใช้ยังสามารถล้างข้อมูลไซต์ได้เองด้วย การเก็บผ่าน API สำเร็จจึงต้องอ่านภายใต้บริบทนี้
แอปอาจขอ persistent storage ผ่านกลไกที่รองรับ แต่ผลขึ้นกับการอนุญาตและนโยบายของ browser ต้องตรวจผลที่ได้ ไม่ถือว่าเพียงเรียก persist แล้วข้อมูลได้รับการคุ้มครองตามที่ต้องการทุกครั้ง
แม้ได้รับ persistence ก็ยังไม่ได้สร้างสำเนาไว้อีกเครื่องหรือทำให้ข้อมูลรอดจากการที่ผู้ใช้ตั้งใจล้าง การวางทางส่งข้อมูลหรือสำรองสำหรับสิ่งสำคัญจึงต้องเป็นอีกส่วนของแอป ไม่ใช้คำว่าถาวรบนหน้าจอโดยไม่อธิบายขอบเขตของเครื่องที่เก็บ
โหมด private หรือ incognito อาจมีนโยบายพื้นที่ต่างออกไป และข้อมูลโดยทั่วไปถูกนำออกเมื่อจบโหมดนั้น จึงควรทดสอบพฤติกรรมที่ผลิตภัณฑ์ต้องรองรับ ไม่อนุมานจากการเปิดหน้าในโปรไฟล์ปกติแล้วเก็บอยู่ได้
คำว่าล้าง cache ในภาษาคนใช้ก็อาจหมายถึงการเลือกชุดข้อมูลต่างกันในหน้าตั้งค่าของแต่ละ browser จึงไม่ควรสัญญาว่าการล้างแบบที่ผู้ใช้เรียกนั้นจะรักษา draft ไว้เสมอ ควรระบุว่าฉบับในเครื่องมีทางส่งขึ้นหรือส่งออกอย่างไรเมื่อจำเป็น
หากเปลี่ยนโดเมนของแอปหรือรุ่นโครงสร้างข้อมูล ต้องมีแผนตรวจข้อมูลเก่ากับทางย้ายที่ทำได้ตามขอบเขต origin และสิทธิ์ ไม่เปิดไซต์ใหม่แล้วรายงานว่าข้อมูลเดิมหายจากฐาน ทั้งที่มันอาจยังอยู่คนละพื้นที่ในเครื่อง
อย่างน้อยควรแยกสิ่งที่คนกำลังแก้ในหน่วยความจำ สิ่งที่เขียนลงเครื่องแล้ว และสิ่งที่บริการยืนยันรับไว้ แต่ละขั้นมีความหมายต่อการปิดหน้าและเปิดจากอีกเครื่องต่างกัน การแสดงว่ารอส่งพร้อมเวลาบันทึกในเครื่องช่วยให้คนตัดสินใจได้ตรงกว่าเครื่องหมายถูกอันเดียว
เมื่อกลับมาออนไลน์ ต้องตรวจความขัดแย้งกับฉบับปัจจุบันของ server ด้วย ไม่ส่ง draft เก่าทับการแก้จากอีกเครื่องโดยอัตโนมัติเพียงเพราะคิวในเครื่องเพิ่งทำงาน การรักษาตัวอ้างอิงรุ่นกับตัวตนคำขอช่วยให้แยกการส่งซ้ำออกจากการแก้ใหม่ได้ตามสัญญา
ชุดทดลองควรมีพื้นที่เขียนไม่ผ่าน การปิดเปิดหน้า ล้างข้อมูลในโปรไฟล์ทดลอง และการแก้จากสองเครื่อง พร้อมดูว่าหน้าจอบอกขอบเขตการบันทึกตรงกับสิ่งที่อ่านกลับได้จริงหรือไม่ การตรวจควรใช้ข้อมูลทดสอบและรักษาทางกู้ก่อนทำเหตุการณ์ที่ลบข้อมูลของชุดทดลองนั้น
Browser storage ช่วยรักษางานระหว่างใช้งานได้ แต่ต้องดู origin การเขียนสำเร็จและนโยบายการเก็บร่วมกัน เมื่อแยกฉบับในเครื่องออกจากฉบับที่บริการรับแล้ว พร้อมทางส่งออกและจัดการความขัดแย้ง เราจะทำ autosave ที่คนเข้าใจสถานะจริง และลดการสูญเสียงานจากคำว่าบันทึกที่ยืนยันเกินสิ่งที่ระบบทำได้