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