ตัวดูเอกสารอาจทำงานได้เทคนิคแล้วแต่ยังรู้สึกใช้งานยากบนหน้าจอแคบ แถบเครื่องมือที่แน่น ควบคุมขนาดเล็ก แผงด้านข้างที่ใหญ่เกินไป และคอนเทนเนอร์ที่มีขนาดคงที่สามารถทำให้การพรีวิวง่าย ๆ กลายเป็นประสบการณ์ที่ทำให้หงุดหงิดได้อย่างรวดเร็ว
สำหรับแอปพลิเคชัน ASP.NET และ .NET บน Windows, Doconut ให้ SDK การดูเอกสารแบบฝังสำหรับเอกสารธุรกิจ ไฟล์ PDF แบบ CAD, ไฟล์อีเมล และรูปภาพ แอปของคุณยังคงควบคุมการจัดวางโดยรอบ การตรวจสอบสิทธิ์ การอนุญาต การจัดเก็บ และเวิร์กโฟลว์ของเอกสาร
คู่มือนี้มุ่งเน้นที่ประสบการณ์โดยรอบ: วิธีให้ตัวดูฝังมีพื้นที่เพียงพอ ทำให้การควบคุมของแอปใช้งานสบาย จัดการการเปลี่ยนแปลงแนวตั้ง และทดสอบเอกสารที่สมจริงโดยไม่ต้องพึ่งพาโค้ดต้นฉบับของ SDK ที่ไม่ได้รับการตรวจสอบ
การออกแบบตอบสนองเริ่มจากภายนอกตัวดู
ตัวดูสามารถใช้พื้นที่ที่เลเอาต์แม่ให้ได้เท่านั้น หากแอปวางไว้ในการ์ดแคบ ให้ความกว้างแบบเดสก์ท็อปคงที่ หรือห้อมล้อมด้วยหลายแผงที่คงที่ พื้นที่เอกสารจะยังคงแคบคับคั่ง
เริ่มด้วยสามคำถาม:
- งานหลักบนหน้านี้คืออะไร?
- ควบคุมของแอปใดต้องคงมองเห็นได้ขณะอ่าน?
- แผงรองใดที่สามารถยุบหรือซ่อนหลังปุ่มได้?
สำหรับหน้าที่เน้นเอกสารโดยเฉพาะ ตัวดูควรเป็นองค์ประกอบที่โดดเด่น Metadata, ความคิดเห็น, การอนุมัติ และการกระทำของเวิร์กโฟลว์สามารถคงอยู่ได้โดยไม่ต้องใช้พื้นที่ถาวรจากเอกสาร
วางแผนเค้าโครงตามพื้นที่ที่มี
พฤติกรรมตอบสนองควรอิงตามพื้นที่ที่คอมโพเนนต์มี ไม่ใช่สมมติฐานเกี่ยวกับชื่ออุปกรณ์เฉพาะ
เค้าโครงกว้าง
บนวิวพอร์ตกว้าง หน้าอาจแสดง:
- แถบภาพย่อหรือแผงนำทางของเอกสาร
- พื้นที่แคนวาสเอกสารหลัก
- แผงเวิร์กโฟลว์รองสำหรับความคิดเห็นหรือเมตาดาต้า
- ชุดเต็มของการกระทำของแอปพลิเคชัน
เมื่อแผงรองกลายเป็นดรอว์เวอร์ ให้เพิ่มพฤติกรรมของไดอะล็อก การจัดการโฟกัส และการตั้งชื่อที่เข้าถึงได้ตามระบบการออกแบบของคุณ
ทำให้การควบคุมของแอปเป็นมิตรต่อการสัมผัส
การควบคุมรอบตัวดูควรใช้งานสบายโดยไม่ต้องเคลื่อนเมาส์อย่างแม่นยำ
แนวทางปฏิบัติรวมถึง:
- ให้ควบคุมที่โต้ตอบได้มีพื้นที่เป้าหมายประมาณ 44 × 44 พิกเซล CSS
- เว้นระยะห่างเพียงพอระหว่างการกระทำที่ทำลายและการกระทำที่ใช้บ่อย
- อย่าพึ่งพา hover เพื่อเปิดเผยข้อมูลสำคัญ
- รักษาตัวบ่งชี้โฟกัสให้มองเห็นได้สำหรับผู้ใช้คีย์บอร์ด
- ให้ชื่อที่เข้าถึงได้สำหรับปุ่มที่มีไอคอนอย่างเดียว
- หลีกเลี่ยงการวางควบคุมสำคัญใกล้พื้นที่ท่าทางของเบราว์เซอร์หรือระบบ
ห้ามเขียนทับสไตล์ภายในของ Doconut ด้วยตัวเลือกที่คาดเดาหรือ CSS ตัวแปรที่ไม่ได้รับการบันทึก ใช้ทรัพยากรอย่างเป็นทางการสำหรับเวอร์ชัน SDK ที่ติดตั้ง และใช้กฎตอบสนองของคุณกับคอนเทนเนอร์และควบคุมที่เป็นของแอปพลิเคชันเท่านั้น
ปฏิบัติเช่นแผงด้านข้างเป็นพื้นที่ทำงานเสริม
ภาพย่อ, ผลลัพธ์การค้นหา, คำอธิบาย, เมตาดาต้า, และประวัติเวิร์กโฟลว์เป็นสิ่งมีค่า แต่ไม่ควรแข่งขันกับเอกสารทั้งหมดพร้อมกัน
บนเค้าโครงกะทัดรัด:
- เปิดแผงด้านข้างเฉพาะเมื่อผู้ใช้ร้องขอ
- คืนโฟกัสให้กับปุ่มที่เปิดแผงหลังจากปิด
- จับโฟกัสไว้ภายในแผงโมดัลเมื่อจำเป็น
- ให้แผงมีชื่อชัดเจนและปุ่มปิด
- รักษาตำแหน่งปัจจุบันของเอกสารเมื่อแผงเปิดหรือปิด
หากตัวดูมีแผงของตนเอง ให้ทดสอบพฤติกรรมตอบสนองที่ระบุไว้ก่อนเพิ่มระบบนำทางระดับแอปพลิเคชันที่สองเข้ามา
ทำให้พื้นที่ทำงานเอกสารเร็วขึ้น
การออกแบบตอบสนองไม่ใช่แค่ด้านภาพ เอกสารขนาดใหญ่สามารถทำให้เกิดข้อจำกัดด้านหน่วยความจำ แบนด์วิดท์ และการเรนเดอร์ โดยเฉพาะเมื่อหน้ามีแดชบอร์ดหรือแอนิเมชันซับซ้อนร่วมด้วย
ลดงานที่แข่งขันกัน
หยุดแอนิเมชันตกแต่งขณะผู้ใช้กำลังอ่าน หลีกเลี่ยงเอฟเฟกต์ที่ใช้ทรัพยากรสูงรอบตัวดู และลบผู้สังเกตหรือผู้ฟังเหตุการณ์ที่ไม่จำเป็นออก
จองพื้นที่เค้าโครงไว้ล่วงหน้า
กำหนดความสูงคงที่ให้กับโฮสต์ของตัวดูก่อนโหลด สิ่งนี้จะป้องกันการเปลี่ยนแปลงเค้าโครงใหญ่และลดโอกาสที่ผู้ใช้จะกดควบคุมผิด
โหลดฟีเจอร์รองอย่างตั้งใจ
ความคิดเห็น, ประวัติการตรวจสอบ, และแผงเมตาดาต้าขนาดใหญ่ไม่จำเป็นต้องโหลดพร้อมหน้าหนึ่งของเอกสาร ให้เรียกโหลดเมื่อผู้ใช้เปิดแผงที่เกี่ยวข้องตามเวิร์กโฟลว์ของคุณ
ทดสอบไฟล์ตัวอย่างที่เป็นตัวแทน
ใช้ PDF ยาว, สเปรดชีตกว้าง, ภาพวาด CAD รายละเอียด, รูปภาพขนาดใหญ่, และเอกสารที่มีฟอนต์แปลกไฟล์ตัวอย่างขนาดเล็กไม่สามารถเปิดเผยขีดจำกัดของประสบการณ์การผลิตได้
รักษาการควบคุมการเข้าถึงบนเซิร์ฟเวอร์
การนำเสนอแบบตอบสนองไม่ได้เปลี่ยนความรับผิดชอบด้านความปลอดภัยของแอปพลิเคชัน ทุกคำขอเอกสารยังคงต้องผ่านการตรวจสอบสิทธิ์และการอนุญาตเฉพาะเอกสาร
สำหรับแอปพลิเคชัน ASP.NET Core กลไกมาตรฐานเช่น มิดเดิลแวร์การตรวจสอบสิทธิ์, นโยบาย, คลาม, แอตทริบิวต์ [Authorize] และการอนุญาตแบบทรัพยากรสามารถปกป้องเส้นทางเซิร์ฟเวอร์ที่ให้บริการเอกสารได้
แอปพลิเคชันควร:
- ใช้ตัวระบุเอกสารที่สร้างโดยเซิร์ฟเวอร์
- ตรวจสอบว่าผู้ใช้ปัจจุบันสามารถเข้าถึงเอกสารที่ร้องขอได้
- เก็บข้อมูลรับรองการจัดเก็บและเส้นทางที่ไม่จำกัดไว้ห่างจากไคลเอนต์
- ทำความสะอาดข้อผิดพลาดที่แสดงในหน้าตัวดู
- ใช้กฎการเก็บรักษาอย่างชัดเจนกับไฟล์ต้นฉบับและไฟล์ชั่วคราว
- หลีกเลี่ยงการบันทึกเนื้อหาเอกสาร, ความลับ, หรือ URL การเข้าถึงที่สำคัญ
การซ่อนการดาวน์โหลด, การพิมพ์, หรือการกระทำเมนูบริบทอาจสนับสนุนเวิร์กโฟลว์ที่ตั้งใจไว้ แต่ไม่ได้แทนที่การอนุญาตบนเซิร์ฟเวอร์และไม่สามารถป้องกันการจับภาพทุกรูปแบบหลังจากเนื้อหาแสดงผลแล้วได้
การรวม Doconut เข้ากับประสบการณ์ตอบสนอง
Doconut จัดเตรียมชั้นการดูเอกสารแบบฝัง ในขณะที่แอปพลิเคชันจัดหาชั้นเชลล์ตอบสนองและเวิร์กโฟลว์ธุรกิจ
ลำดับการดำเนินการที่สมเหตุสมผลคือ:
- ยืนยันรูปแบบและคุณลักษณะของตัวดูที่ต้องการ
- รวมแพคเกจ Doconut ที่รองรับสำหรับแอป .NET ของคุณ
- ปกป้องการแก้ไขเอกสารด้วยการอนุญาตบนเซิร์ฟเวอร์
- วางตัวดูในคอนเทนเนอร์โฮสต์ที่เป็นของแอปและยืดหยุ่น
- ออกแบบสถานะกะทัดรัดสำหรับแถบเครื่องมือแอปและแผงรอง
- ทดสอบการปรับขนาด, การเปลี่ยนแนว, โฟกัส, การโหลด, และพฤติกรรมข้อผิดพลาด
- ตรวจสอบผลลัพธ์ด้วยเอกสารแบบผลิตจริงและเซสชันพร้อมกัน
ดูรายละเอียดผลิตภัณฑ์ Doconut Viewer สำหรับข้อมูลผลิตภัณฑ์ล่าสุด ใช้หน้า ดาวน์โหลดและเอกสารอย่างเป็นทางการ สำหรับการติดตั้งและคำแนะนำการรวมตามเวอร์ชัน แทนการคัดลอกตัวอย่าง SDK ที่ไม่ได้รับการบันทึกจากโพสต์ของบุคคลที่สาม
รายการตรวจสอบตัวดูตอบสนอง
เค้าโครง
- ตัวดูได้รับส่วนแบ่งพื้นที่ที่ใช้ได้มากที่สุดของหน้า
- ความกว้างคงที่ไม่ทำให้ต้องเลื่อนแนวนอน
- แผงรองยุบได้อย่างเรียบร้อย
- เค้าโครงยังคงใช้งานได้เมื่อความสูงของวิวพอร์ตจำกัด
- สถานะการโหลดและข้อผิดพลาดจองพื้นที่ที่เหมาะสม
การโต้ตอบ
- ควบคุมแอปมีขนาดเป้าหมายที่สบายต่อการสัมผัส
- การกระทำสำคัญไม่พึ่งพา hover
- ควบคุมที่เป็นไอคอนอย่างเดียวมีชื่อที่เข้าถึงได้
- โฟกัสมองเห็นได้และตามลำดับที่เป็นตรรกะ
- ดรอว์เวอร์และไดอะล็อกคืนโฟกัสอย่างถูกต้อง
เอกสาร
- PDF ขนาดใหญ่ยังคงนำทางได้
- สเปรดชีตกว้างสามารถตรวจสอบได้โดยไม่ทำให้เค้าโครงหน้าเสียหาย
- ภาพวาดละเอียดยังคงมีการซูมและแพนที่ใช้งานได้
- ชื่อไฟล์ยาวและข้อความข้อผิดพลาดไม่ล้นออกนอกพื้นที่
- การเปลี่ยนขนาดเค้าโครงไม่ทำให้เอกสารรีสตาร์ทโดยไม่จำเป็น
ความปลอดภัยและการดำเนินงาน
- เซิร์ฟเวอร์อนุญาตทุกคำขอเอกสาร
- รายละเอียดการจัดเก็บยังคงเป็นส่วนตัว
- การเก็บรักษาไฟล์และข้อมูลชั่วคราวได้รับการบันทึกไว้
- ข้อผิดพลาดและบันทึกไม่มีข้อมูลที่ละเอียดอ่อน
- ขีดจำกัดของทรัพยากรและพฤติกรรมเซสชันพร้อมกันได้รับการทดสอบ
คำถามที่พบบ่อย
แอปควรมีหน้าตัวดูแยกสำหรับโทรศัพท์และเดสก์ท็อปหรือไม่?
โดยทั่วไป ไม่จำเป็น หน้าตอบสนองเดียวง่ายต่อการบำรุงรักษา ปรับเค้าโครงตามพื้นที่ที่มีและค่อยๆ เปิดเผยควบคุมรองตามลำดับ
แอปสามารถเขียนทับ CSS ภายในของตัวดูได้หรือไม่?
หลีกเลี่ยงตัวเลือกและตัวแปรที่ไม่ได้รับการบันทึก สไตล์คอนเทนเนอร์โฮสต์และควบคุมของแอปของคุณเอง ใช้จุดปรับแต่งที่ระบุไว้สำหรับเวอร์ชัน Doconut ที่คุณใช้งานเท่านั้น
ควรซ่อนปุ่มดาวน์โหลดและพิมพ์บนเค้าโครงกะทัดรัดหรือไม่?
เป็นการตัดสินใจของผลิตภัณฑ์ ไม่ใช่ขอบเขตความปลอดภัย หากการกระทำได้รับอนุญาตแต่ไม่พอดี ให้วางไว้ในเมนู overflow ที่เข้าถึงได้ หากไม่ได้รับอนุญาต ให้บังคับใช้นโยบายบนเซิร์ฟเวอร์
ควรทดสอบเอกสารขนาดใหญ่อย่างไร?
สร้างชุดทดสอบที่ทำความสะอาดซึ่งสะท้อนจำนวนหน้า, ขนาดไฟล์, ฟอนต์, ภาพวาด, และสเปรดชีตจริง ทำซ้ำการทดสอบหลังจากอัปเดต SDK, .NET, Windows Server หรือการเปลี่ยนแปลงเค้าโครง
สรุป
ประสบการณ์การดูเอกสารบนมือถือที่แข็งแกร่งเริ่มจากคอนเทนเนอร์ที่ยืดหยุ่น, เค้าโครงที่ให้ความสำคัญกับเอกสาร, ควบคุมที่สบาย, แผงด้านข้างเสริม, พฤติกรรมการปรับขนาดที่คาดเดาได้, และการอนุญาตบนเซิร์ฟเวอร์
Doconut สามารถให้ความสามารถในการดูเอกสารภายในแอปพลิเคชัน .NET บน Windows ของคุณ ทีมของคุณจึงสามารถมุ่งเน้นที่เชลล์แอปตอบสนอง, กฎความปลอดภัย, และเวิร์กโฟลว์ที่ทำให้ตัวดูรู้สึกเป็นส่วนธรรมชาติของผลิตภัณฑ์.