این مقاله با کمک هوش مصنوعی تهیه شده است. نمونه‌های UI اختصاصی و فرضی‌اند؛ نتیجهٔ تست کاربری یا عملکرد مشتری ادعا نمی‌شود.
از قرارداد تجربه شروع کنیم
حس نیتیو چیزی نیست که در پایان با چند آیکون و گوشهٔ گرد به محصول اضافه شود. مجموعه‌ای از انتظارهاست دربارهٔ اینکه محصول در محیط یک سیستم‌عامل چگونه پاسخ می‌دهد. کراس‌پلتفرم هم یک روش پیاده‌سازی است، نه یک مدل واحد تعامل. سؤال مفید این است: تیم چه رفتارهایی را متعهد می‌شود تحویل دهد و چطور آن‌ها را نگهداری خواهد کرد؟
قرارداد پیشنهادی ما، ناوبری، ورود اطلاعات، اتصال به سیستم‌عامل، دسترس‌پذیری، چیدمان و عملکرد را پوشش می‌دهد. کد مشترک می‌تواند بسیاری از این تعهدها را برآورده کند؛ دو پیاده‌سازی جداگانهٔ نیتیو هم ممکن است در آن‌ها شکست بخورند. باید مسیر واقعی انجام کار را مقایسه کنیم، نه فقط اسکرین‌شات کارت‌های زیبا را.
معماری را با ظاهر یکی نگیریم
مستندات React Native توضیح می‌دهد که کامپوننت‌های آن می‌توانند ویوهای متناظر اندروید و iOS را ایجاد کنند. [1] مستندات Flutter هم میان سازگاری خودکار با پلتفرم و قراردادهایی که هنوز تصمیم طراحی می‌خواهند تفاوت می‌گذارد. [2] پس همهٔ رابط‌های کراس‌پلتفرم یک نوع مصالحه نیستند.
برای تیم محصول، این یعنی سؤال مشخص بپرسیم: کدام کنترل از رفتار آمادهٔ پلتفرم استفاده می‌کند؟ کدام سفارشی است؟ نگهداری کیبورد، فوکوس و دسترس‌پذیری با چه کسی است؟ بعد از تغییر سیستم‌عامل چه اتفاقی می‌افتد؟ نه باید انتظار داشت فریم‌ورک همهٔ جزئیات را خودکار حل کند، نه باید به‌خاطر یک نمونهٔ بد، کل رویکرد را رد کرد.
ناوبری فقط شکل فلش برگشت نیست
جریان رزروی را تصور کنید که از یک فهرست ذخیره‌شده باز شده است. بعد از دیدن زمان‌ها، کاربر باید بداند برگشت او را به فهرست می‌برد، سطح موقت را می‌بندد یا کل کار را لغو می‌کند. آیکون، آخرین نمود این تصمیم است. تاریخچه، بازگشت فوکوس و حفظ پیش‌نویس هم بخشی از همین تعامل‌اند.
Flutter تفاوت‌هایی در حرکت بین صفحه‌ها و رفتار برگشت در iOS و اندروید مستند کرده است. [2] نمونهٔ این مقاله صرفاً یک نمایش سادهٔ تحت وب از شیوه‌های ارائه است؛ اپ نیتیو یا شبیه‌ساز کامل سیستم‌عامل نیست. کار ثابت می‌ماند و شکل نمایش و رفتار لغو را می‌توان مقایسه کرد.
ارائه با الهام از iOS
یک شیت در امتداد کاری که کاربر در حال انجام آن است.
ارائه با الهام از Android
دیالوگی برای همان انتخاب؛ هدف و وضعیت کار ثابت می‌مانند.
یک کار، دو شیوهٔ ارائه
کنترل‌ها را امتحان کنید. این نمونهٔ تعاملی با دادهٔ فرضی، فقط داخل مرورگر کار می‌کند.
انتخاب زمان بازدید
زمان انتخاب‌شده: 10:30
اپ نیتیو نیست. ژست‌ها، کیبورد و فناوری کمکی باید جداگانه روی دستگاه تست شوند.به جزئیات معمولی دقیق‌تر نگاه کنیم
انتخاب متن، ظاهرشدن کیبورد، ورود رمز و انتخاب تاریخ گاهی از انیمیشن هرو گویاترند. نام طولانی، مقدار پیست‌شده و نشانی راست‌به‌چپ را امتحان کنید. ببینید آیا فرد می‌تواند بدون از دست‌دادن پیشرفت، کیبورد را ببندد، خطا را کنار فیلد ببیند و بعد از بستن دیالوگ به کنترل قبلی برگردد.
محصول می‌تواند بیان بصری متمایز داشته باشد و هم‌زمان اجازه دهد کنترل آشنا، کار آشنایش را انجام دهد. لازم نیست همهٔ اجزا در دو پلتفرم یک شکل باشند. مشخص کنید کجا شخصیت برند مهم‌تر است و کجا پیش‌بینی‌پذیریِ قرارداد پلتفرم کمک بیشتری می‌کند. برای رفتار سفارشیِ ضروری هم دلیل بنویسید.
دسترس‌پذیری را وارد معیار پذیرش کنیم
اسکرین‌شات نشان نمی‌دهد کنترل نام قابل‌فهم دارد یا نه، ترتیب خواندن درست است یا نه و فوکوس چگونه حرکت می‌کند. کل کار را با صفحه‌خوان، متن بزرگ و روش‌های ورودی پشتیبانی‌شده امتحان کنید. وضعیت بعد از خطا را هم تست کنید، نه فقط اولین صفحهٔ بی‌نقص را.
در برنامهٔ تست باید دستگاه‌ها، نسخه‌های سیستم‌عامل و فناوری‌های کمکی واقعاً استفاده‌شده مشخص باشند. برچسب «نیتیو» یا «کراس‌پلتفرم» نتیجهٔ تست دسترس‌پذیری نیست. نمونهٔ تحت وب ما کنترل‌های برچسب‌دار و تغییر وضعیت قابل‌دیدن دارد، اما جای تست اپ واقعی روی دستگاه را نمی‌گیرد.
انتخاب فنی، برنامهٔ نگهداری هم می‌خواهد
در ماتریس تصمیم، APIهای تخصصی، نیاز به رندر سفارشی، مهارت تیم، هماهنگی انتشار و تغییرات آیندهٔ پلتفرم را وارد کنید. فقط درصد کد مشترک را حساب نکنید؛ هزینهٔ استثناها هم مهم است. یک تعامل خاص اگر در هر نسخهٔ سیستم‌عامل نیاز به بازبینی داشته باشد، می‌تواند هزینه‌ساز شود.
برای پرریسک‌ترین کار، یک نمونهٔ فنی کوچک بسازید؛ مثلاً فرم دسترس‌پذیر با شیت، کیبورد و بازیابی ناوبری. قبل از انتخاب برای کل محصول، آن را روی پلتفرم‌های هدف تست کنید. زمان و هزینه باید از همین بررسی بیاید. این مقاله ادعا نمی‌کند یک رویکرد همیشه سریع‌تر، ارزان‌تر یا روان‌تر است.
کیفیت را در سطح کار مرور کنیم
برای هر پیاده‌سازی یک سناریوی پذیرش یکسان داشته باشید: ورود از یک مسیر بیرونی، تغییر مقدار، بستن شیت، اصلاح خطا، خروج و ادامه. مقایسه کنید فرد چقدر می‌تواند قدم بعدی را پیش‌بینی کند و آیا وضعیت درست باقی می‌ماند.
نتیجه باید یک قرارداد تجربهٔ مستند و تیمی باشد که بتواند آن را حفظ کند. کد مشترک وقتی ارزش دارد که این قرارداد را با هزینهٔ قابل‌مدیریت نگه دارد. کار اختصاصیِ پلتفرم هم وقتی ارزش دارد که نیاز مشخص کاربر را حل کند. تصمیم فنی وقتی قوی‌تر است که این بده‌بستان‌ها روشن و آزموده شده باشند.
منابع و یادداشت‌های تحریریه
منابع در ۲۲ اکتبر ۲۰۲۶ بررسی شدند. پیشنهادهای اجرایی و نمونه‌های این مقاله، تفسیر تحریریه‌اند؛ تأیید یا همکاری صاحبان منابع با ما را القا نمی‌کنند.
برای طراحی یک تجربهٔ روشن‌تر، از مسئلهٔ واقعی شروع کنیم.
دربارهٔ پروژه صحبت کنیم
