یک نمایشگر سند میتواند از نظر فنی کارا باشد اما در صفحهنمایش باریک غیرقابل استفاده به نظر برسد. نوارهای ابزار متراکم، کنترلهای ریز، پنلهای جانبی بزرگنماییشده و کانتینرهای با ابعاد ثابت به سرعت یک پیشنمایش ساده را به تجربهای ناامیدکننده تبدیل میکنند.
برای برنامههای مبتنی بر Windows با ASP.NET و .NET، Doconut یک SDK نمایش سند توکار برای اسناد تجاری، فایلهای PDF، نقشههای CAD، فایلهای ایمیل و تصاویر فراهم میکند. برنامه شما همچنان کنترل چیدمان اطراف، احراز هویت، مجوزدهی، ذخیرهسازی و جریان کاری سند را در دست دارد.
این راهنما بر تجربه اطراف تمرکز دارد: چگونگی اختصاص فضای کافی به نمایشگر توکار، راحت کردن استفاده از کنترلهای برنامه، مدیریت تغییرات جهتگیری، و تست اسناد واقعی بدون تکیه بر کد منبع SDK که تأیید نشده است.
طراحی واکنشگرا از خارج نمایشگر شروع میشود
نمایشگر تنها میتواند از فضایی استفاده کند که چیدمان والد آن فراهم میکند. اگر برنامه آن را داخل یک کارت باریک قرار دهد، عرض ثابت دسکتاپ به آن بدهد یا با پنلهای مداوم متعدد احاطه کند، ناحیه سند همچنان فشرده خواهد ماند.
با سه سؤال شروع کنید:
- وظیفه اصلی در این صفحه چیست؟
- کدام کنترلهای برنامه باید هنگام خواندن قابل مشاهده بمانند؟
- کدام پنلهای ثانویه میتوانند جمع شوند یا پشت یک دکمه مخفی شوند؟
برای صفحهای اختصاصی به سند، نمایشگر معمولاً باید عنصر غالب باشد. متادیتا، نظرات، تأییدها و اقدامات جریان کاری میتوانند در دسترس بمانند بدون اینکه فضای دائمی از سند را اشغال کنند.
طرحبندی را بر اساس فضای موجود برنامهریزی کنید
رفتار واکنشگرا باید بر اساس فضای موجود برای مؤلفه باشد، نه بر پایه فرضیات درباره نام یک دستگاه خاص.
چیدمان عریض
در یک نمای عریض، صفحه ممکن است نمایش دهد:
- یک تصویر کوچک سند یا پنل ناوبری
- بوم اصلی سند
- پنل جریان کاری ثانویه برای نظرات یا متادیتا
- یک مجموعه کامل از اقدامات برنامه
هنگامی که یک پنل ثانویه به حالت کشو تبدیل میشود، رفتار دیالوگ، مدیریت فوکوس و برچسبگذاری قابل دسترس مورد نیاز سیستم طراحی خود را اضافه کنید.
کنترلهای برنامه را برای لمس مناسب کنید
کنترلهای اطراف نمایشگر باید بدون نیاز به حرکت دقیق اشارهگر، به راحتی فعال شوند.
راهنماییهای عملی شامل موارد زیر است:
- به کنترلهای تعاملی یک ناحیه هدف حدود ۴۴ در ۴۴ پیکسل CSS اختصاص دهید.
- فضای کافی بین اقدامات مخرب و مکرراً استفادهشده باقی بگذارید.
- به شناور شدن (hover) برای نمایش اطلاعات اساسی تکیه نکنید.
- نشانگرهای فوکوس را برای کاربران کیبورد قابل مشاهده نگه دارید.
- نامهای قابل دسترس برای دکمههای فقطآیکون فراهم کنید.
- از قرار دادن کنترلهای حیاتی در نزدیکی نواحی حرکات مرورگر یا سیستم خودداری کنید.
استایلهای داخلی Doconut را با سلکتورهای حدسی یا متغیرهای CSS غیرمستند بازنویسی نکنید. از منابع رسمی برای نسخه نصبشده SDK استفاده کنید و قوانین واکنشگرای خود را بر روی کانتینرها و کنترلهای متعلق به برنامه اعمال کنید.
پنلهای جانبی را بهعنوان فضای کاری اختیاری در نظر بگیرید
تصاویر کوچک، نتایج جستجو، حاشیهنویسیها، متادیتا و تاریخچه جریان کاری ارزشمند هستند، اما نباید همزمان همه با سند رقابت کنند.
در چیدمانهای فشرده:
- پنل جانبی را فقط زمانی باز کنید که کاربر درخواست دهد.
- پس از بسته شدن، فوکوس را به دکمهای که آن را باز کرده بود بازگردانید.
- در پنلهای مودال در صورت لزوم، فوکوس را درون آنها محصور کنید.
- به پنل یک عنوان واضح و عمل بستن بدهید.
- موقعیت فعلی سند را هنگام باز یا بسته شدن پنل حفظ کنید.
اگر نمایشگر پنلهای خود را فراهم میکند، رفتار واکنشگرای مستند شده آنها را پیش از افزودن یک سیستم ناوبری سطح برنامه دوم در اطرافشان تست کنید.
فضای کاری سند را سریع نگه دارید
طراحی واکنشگرا فقط بصری نیست. اسناد بزرگ میتوانند محدودیتهای حافظه، پهنای باند و رندرینگ را آشکار کنند، بهویژه وقتی صفحه شامل داشبوردهای پیچیده یا انیمیشنها باشد.
کاهش کارهای رقابتی
در حین خواندن کاربر، انیمیشنهای تزئینی را متوقف کنید، از اثرات پرهزینه اطراف نمایشگر پرهیز کنید و ناظرها یا شنوندگان رویدادهای غیرضروری را حذف کنید.
فضای چیدمان را رزرو کنید
به میزبان نمایشگر قبل از بارگذاری، ارتفاع ثابت بدهید. این کار از جابجاییهای بزرگ چیدمان جلوگیری میکند و احتمال فشار اشتباه کاربر بر کنترل را کاهش میدهد.
ویژگیهای ثانویه را بهصورت عمدی بارگذاری کنید
نظرات، تاریخچه حسابرسی و پنلهای متادیتای بزرگ همیشه نیازی به بارگذاری همراه با صفحه اول سند ندارند. آنها را تا زمانی که کاربر پنل مرتبط را باز کند به تعویق بیندازید، بهشرطی که با جریان کاری شما همخوانی داشته باشد.
فایلهای نماینده را تست کنید
از PDFهای طولانی، صفحات گسترده عریض، نقشههای CAD دقیق، تصاویر بزرگ و اسنادی با فونتهای نامعمول استفاده کنید. یک فایل نمونه کوچک نمیتواند محدودیتهای تجربه تولید را نشان دهد.
کنترل دسترسی را بر روی سرور نگه دارید
ارائه واکنشگرا مسئولیتهای امنیتی برنامه را تغییر نمیدهد. هر درخواست سند باید همچنان از احراز هویت و مجوزدهی خاص سند عبور کند.
برای برنامههای ASP.NET Core، مکانیزمهای استانداردی مانند میدلویر احراز هویت، سیاستها، ادعاها، ویژگی [Authorize] و مجوزدهی مبتنی بر منبع میتوانند مسیر سرور که سند را بازیابی میکند، محافظت کنند.
- از شناسههای سند تولید شده توسط سرور استفاده کنید.
- اطمینان حاصل کنید کاربر فعلی میتواند به سند درخواستشده دسترسی داشته باشد.
- اعتبارهای ذخیرهسازی و مسیرهای بدون محدودیت را از سمت کلاینت دور نگه دارید.
- خطاهای نمایش دادهشده در صفحه نمایشگر را پاکسازی کنید.
- قواعد نگهداری صریح را بر فایلهای اصلی و موقت اعمال کنید.
- از ثبت محتوای سند، اسرار یا URLهای دسترسی حساس خودداری کنید.
پنهان کردن اقدامات دانلود، چاپ یا منوی زمینه میتواند از جریان کاری مورد نظر پشتیبانی کند، اما جایگزین مجوزدهی سمت سرور نمیشود و نمیتواند از تمام انواع ضبط پس از نمایش محتوا جلوگیری کند.
یکپارچهسازی Doconut در تجربه واکنشگرا
Doconut لایه نمایش سند توکار را فراهم میکند، در حالی که برنامه پوسته واکنشگرای و جریان کاری تجاری را تأمین میکند.
یک توالی پیادهسازی معقول به شرح زیر است:
- قالبها و ویژگیهای مورد نیاز نمایشگر را تأیید کنید.
- پکیج Doconut پشتیبانیشده را برای برنامه .NET خود یکپارچه کنید.
- دسترس به سند را با مجوزدهی سمت سرور محافظت کنید.
- نمایشگر را در یک کانتینر میزبان سیال و متعلق به برنامه قرار دهید.
- وضعیتهای فشرده برای نوارهای ابزار برنامه و پنلهای ثانویه طراحی کنید.
- تغییر اندازه، جهتگیری، فوکوس، بارگذاری و رفتار خطا را تست کنید.
- نتیجه را با اسناد مشابه تولید و جلسات همزمان اعتبارسنجی کنید.
برای اطلاعات فعلی محصول، به صفحه محصول Doconut Viewer مراجعه کنید. برای دستورالعملهای نصب و یکپارچهسازی نسخه‑خاص، به صفحه رسمی دانلود و مستندات مراجعه کنید و از کپی کردن مثالهای SDK بدون مستندات در پستهای شخص ثالث خودداری کنید.
چکلیست بازبینی نمایشگر واکنشگرا
چیدمان
- نمایشگر بزرگترین سهم مفید صفحه را دریافت میکند.
- عرضهای ثابت اسکرول افقی را تحمیل نمیکنند.
- پنلهای ثانویه بهصورت تمیز جمع میشوند.
- چیدمان هنگام محدود بودن ارتفاع نمای صفحه قابل استفاده باقی میماند.
- وضعیتهای بارگذاری و خطا فضای مناسب را رزرو میکنند.
تعامل
- کنترلهای برنامه اندازه هدف راحتی دارند.
- اقدامات اساسی به شناور شدن (hover) وابسته نیستند.
- کنترلهای فقطآیکون نامهای قابل دسترسی دارند.
- فوکوس قابل مشاهده باقی میماند و ترتیب منطقی را دنبال میکند.
- کشوها و دیالوگها فوکوس را بهدرستی باز میگردانند.
اسناد
- PDFهای بزرگ قابل ناوبری باقی میمانند.
- صفحات گسترده عریض میتوانند بدون خراب کردن چیدمان صفحه بررسی شوند.
- نقشههای دقیق فضای زوم و پان قابل استفاده را حفظ میکنند.
- نامهای فایل طولانی و پیامهای خطا overflow نمیشوند.
- تغییر اندازه چیدمان بهطور غیرضروری سند را دوباره بارگذاری نمیکند.
امنیت و عملیات
- سرور هر درخواست سند را مجوز میدهد.
- جزئیات ذخیرهسازی خصوصی میمانند.
- نگهداری فایل و دادههای موقت مستند شده است.
- خطاها و لاگها اطلاعات حساس را حذف میکنند.
- محدودیتهای منابع و رفتار جلسات همزمان تست میشوند.
سوالات متداول
آیا برنامه باید صفحات نمایشگر جداگانهای برای تلفنها و دسکتاپها داشته باشد؟
معمولاً نه. یک صفحه واکنشگرا واحد نگهداری آسانتری دارد. چیدمان را بر اساس فضای موجود تغییر دهید و کنترلهای ثانویه را بهصورت تدریجی نمایش دهید.
آیا برنامه میتواند CSS داخلی نمایشگر را بازنویسی کند؟
از سلکتورها و متغیرهای غیرمستند خودداری کنید. کانتینر میزبان و کنترلهای برنامه خود را استایل کنید. فقط از نقاط سفارشیسازی مستند شده برای نسخه Doconut که استفاده میکنید، بهره ببرید.
آیا دکمههای دانلود و چاپ در چیدمانهای فشرده باید مخفی شوند؟
این تصمیم محصول است نه یک مرز امنیتی. اگر یک عمل مجاز باشد اما جا نگیرد، آن را در یک منوی overflow قابل دسترس قرار دهید. اگر مجاز نباشد، این سیاست را در سرور اعمال کنید.
چگونه باید اسناد بزرگ تست شوند؟
یک مجموعه تست پاکسازیشده بسازید که شمارش صفحات واقعی، اندازه فایلها، فونتها، نقشهها و صفحات گسترده را بازتاب دهد. پس از تغییرات SDK، .NET، Windows Server یا چیدمان، این مجموعه را تکرار کنید.
نتیجهگیری
یک تجربه قوی سند موبایلی با یک کانتینر سیال، چیدمان سند-محور، کنترلهای راحت، پنلهای جانبی اختیاری، رفتار پیشبینیشده در تغییر اندازه و مجوزدهی سمت سرور آغاز میشود.
Doconut میتواند قابلیت نمایش را داخل برنامه .NET مبتنی بر Windows شما فراهم کند. تیم شما سپس میتواند بر روی پوسته واکنشگرای برنامه، قوانین امنیتی و جریان کاری که نمایشگر را بهعنوان بخشی طبیعی از محصول حس میکند، تمرکز کند.