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