لینک معرفی پروژه ممکن است در پیام‌رسان، نتیجهٔ جست‌وجو یا یک گفت‌وگوی کوتاه باز شود. در این موقعیت، مخاطب معمولاً توضیح همراه ندارد و باید با همان صفحه بفهمد چه چیزی پیش روی اوست. اگر نمایش دیر شروع شود یا کنترل‌ها نامفهوم باشند، کیفیت رندر به‌تنهایی نمی‌تواند تجربه را نجات دهد.

گزارش ۲۰۲۵ NAR می‌گوید ۶۹٪ خریداران مورد بررسی در آمریکا از موبایل یا تبلت به‌عنوان ابزار جست‌وجوی خانه استفاده کرده‌اند. این آمار برآورد مخاطب ایرانی اکسی‌واک نیست، اما نشان می‌دهد بررسی تجربهٔ دستگاه همراه در این حوزه موضوع قابل توجهی است. منبع: جدول ۳–۲، صفحهٔ ۵۲. برای پروژهٔ خودتان، تصمیم نهایی باید بر پایهٔ دستگاه‌ها و رفتار مخاطبان واقعی باشد.

اولین صفحه باید چه چیزی نشان دهد؟

پیش از آماده‌شدن کامل صحنهٔ سه‌بعدی، نام پروژه، توضیح کوتاه و مسیر شروع را نمایش دهید. کاربر نباید با یک صفحهٔ خالی روبه‌رو شود. اگر بارگذاری ادامه دارد، وضعیت آن را روشن نشان دهید و راه بازگشت یا دیدن اطلاعات اصلی را حفظ کنید. نوشتن درصد پیشرفت فقط وقتی مفید است که واقعاً با فرایند بارگذاری مرتبط باشد.

همهٔ تصاویر و فضاها لزوماً نباید در اولین لحظه دریافت شوند. می‌توان متناسب با طراحی، بعضی بخش‌ها را هنگام نیاز بارگذاری کرد. البته این کار باید با آزمون همراه باشد تا جابه‌جایی بعدی به توقف‌های طولانی منجر نشود. اندازهٔ فایل تنها معیار نیست؛ آماده‌سازی مدل و پردازش آن روی دستگاه نیز زمان می‌برد.

کنترل لمسی را مستقل آزمایش کنید

کنترلی که با ماوس طبیعی به نظر می‌رسد ممکن است روی صفحهٔ کوچک گیج‌کننده باشد. حرکت دوربین نباید به‌سادگی با پیمایش متن اشتباه شود. دکمه‌های انتخاب طبقه، بازگشت و بستن پنجره را در جای قابل پیش‌بینی قرار دهید و برچسب کوتاه داشته باشید. آموزش اولیه باید مختصر باشد و پس از خواندن، محتوای اصلی را نپوشاند.

  • آیا با یک دست می‌توان مسیر اصلی را طی کرد؟
  • آیا بستن پنجرهٔ پلان آسان است و کاربر به همان موقعیت برمی‌گردد؟
  • آیا متن فارسی و عددهای واحد بدون بزرگ‌نمایی اجباری خوانده می‌شوند؟
  • آیا جهت عمودی و افقی گوشی رفتار قابل فهمی دارند؟
  • آیا بعد از بازگشت از یک برنامهٔ دیگر، صفحه همچنان قابل استفاده است؟

سرعت را با چه معیارهایی بسنجیم؟

راهنمای Web Vitals گوگل، برای وضعیت خوب، LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱ را در صدک ۷۵ بازدیدها مطرح می‌کند. این معیارها به بارگذاری محتوای اصلی، پاسخ‌گویی و پایداری چیدمان مربوط‌اند. منبع: Web Vitals. یک آزمون آزمایشگاهی، جای دادهٔ واقعی کاربران را نمی‌گیرد.

برای تجربهٔ سه‌بعدی، در کنار این معیارها زمان آماده‌شدن تعامل و روان‌بودن مسیر اصلی را هم بررسی کنید. ممکن است متن صفحه زود دیده شود، اما مدل هنوز قابل کنترل نباشد. هدف آزمون فقط کسب یک نمره نیست؛ باید بدانید کاربر از لحظهٔ بازکردن لینک تا انتخاب فضای موردنظر چه توقف‌هایی دارد.

مدل و تصاویر چه اثری دارند؟

تعداد اجزای مدل، اندازهٔ بافت‌ها و شیوهٔ رندر بر مصرف منابع اثر می‌گذارند. توصیه‌های رسمی MDN برای WebGL شامل توجه به محدودیت حافظه و تفاوت دستگاه‌هاست. منبع: WebGL best practices. نسخهٔ مناسب وب را با وظیفهٔ کاربر تنظیم کنید؛ جزئیاتی که در فاصلهٔ نمایش دیده نمی‌شوند، ممکن است هزینهٔ پردازش داشته باشند بی‌آنکه اطلاعات مفیدی اضافه کنند.

تصاویر ثابت را هم با اندازهٔ نمایش متناسب کنید و برای آن‌ها ابعاد مشخص داشته باشید تا هنگام بارگذاری، چیدمان جابه‌جا نشود. تصاویر رندر را از پلان‌های نوشتاری جدا ارزیابی کنید؛ فشرده‌سازی زیاد ممکن است خط‌های ظریف و اعداد پلان را ناخوانا کند. نسخهٔ کوچک باید سریع باشد و نسخهٔ قابل خواندن نیز در دسترس بماند.

اگر نمایش سه‌بعدی اجرا نشد چه؟

اطلاعات ضروری پروژه را فقط داخل صحنهٔ سه‌بعدی قرار ندهید. توضیح متنی، پلان یا تصاویر اصلی و راه تماس باید مسیر جایگزین داشته باشند. راهنمای دسترس‌پذیری W3C بر فراهم‌کردن جایگزین متنی مناسب برای محتوای غیرمتنی تأکید می‌کند. منبع: توضیح معیار ۱٫۱٫۱ WCAG. وجود متن جایگزین، به‌تنهایی به معنای انطباق کامل یک تور با همهٔ معیارهای دسترس‌پذیری نیست.

پیام خطا باید به اقدام کمک کند: برگشت به تصاویر پروژه، تلاش دوباره یا تماس برای دریافت اطلاعات. یک پیام فنی مبهم دربارهٔ موتور رندر، برای بیشتر بازدیدکنندگان راه‌حل نیست. مسیر فرم نیز باید بدون وابستگی به موفقیت نمایش مدل قابل استفاده باشد.

آزمون تحویل در یک مسیر واقعی

  1. لینک را در مرورگر معمول گوشی و با اینترنت همراه باز کنید.
  2. یک طبقه یا فضای مشخص را بدون راهنمای شفاهی پیدا کنید.
  3. پلان را بخوانید، به نمای قبل برگردید و جهت گوشی را تغییر دهید.
  4. مدتی برنامه را ترک کنید و دوباره به آن برگردید.
  5. مسیر اطلاعات جایگزین و فرم تماس را امتحان کنید.
  6. دستگاه، مرورگر، شرایط شبکه و مشکل مشاهده‌شده را ثبت کنید.

این آزمون را فقط به یک گوشی محدود نکنید؛ چند دستگاه نمایندهٔ مخاطب انتخاب کنید. برای شروع می‌توانید نمونهٔ اکسی‌واک را مرور کنید و در شرح درخواست برآورد، دستگاه‌های هدف و معیار تحویل را بنویسید.

منابع و یادداشت تحریریه

  1. NAR — 2025 Home Buyers and Sellers Generational Trends، جدول ۳–۲؛ ابزارهای جست‌وجو در آمریکا
  2. Google / web.dev — Web Vitals؛ معیارها و صدک ۷۵
  3. MDN — WebGL best practices؛ سازگاری و مدیریت منابع
  4. W3C WAI — Understanding SC 1.1.1: Non-text Content

منابع در ۱۳ نوامبر ۲۰۲۶ بررسی شدند. چک‌لیست‌ها و مثال‌های بدون ارجاع، پیشنهادهای تحریریه‌اند؛ مثال‌ها گزارش عملکرد یک مشتری یا تضمین نتیجه نیستند.

سؤال یا نکته‌ای برای اصلاح این مطلب دارید؟

با تحریریه در میان بگذارید