پیشرفت درس آفلاین چگونه با وب هماهنگ می‌شود؟ راهنمای وضعیت‌ها در اپ فاکسیمون
تفاوت پیشرفت محلی و ثبت‌شده، دو دستگاه و تغییر نسخه را بشناسید؛ چارچوب پذیرش اپ آفلاینِ در حال توسعه با جدول آزمون و شرط انتشار.
وقتی بخشی از یک دوره را بدون اینترنت می‌بینیم، سابقهٔ آن ابتدا باید جایی روی همان دستگاه حفظ شود و بعد، در شرایط مجاز، با سامانه هماهنگ شود. همین فاصله میان «روی گوشی انجام شده» و «در حساب ثبت شده» منشأ بسیاری از ابهام‌هاست. ممکن است هنرجو در دستگاه محلی ادامهٔ درس را ببیند ولی در مرورگر هنوز وضعیت قبلی نمایش داده شود. این تفاوت الزاماً به معنی پاک‌شدن پیشرفت نیست؛ اما بدون توضیح روشن، کاربر نمی‌تواند بفهمد باید منتظر بماند، اتصال را بررسی کند یا مشکل را گزارش دهد. راهنمای خوب باید این وضعیت‌ها و قدم بعدی هرکدام را از هم جدا کند.
اپ دریافت محافظت‌شدهٔ آفلاین فاکسیمون در زمان نگارش در حال توسعه است. این مقاله، چارچوب کامل فهم و آزمون وضعیت‌ها را پیش از عرضه فراهم می‌کند و تا تأیید رفتار نسخهٔ منتشرشده، راهنمای قطعی رابط آن برنامه محسوب نمی‌شود. نام دکمه، زمان همگام‌سازی، پشتیبانی آزمون آفلاین یا قانون حل تعارضی که هنوز تأیید نشده، در اینجا به‌عنوان امکان فعال وعده داده نمی‌شود. سناریوهای عددیِ مقاله فرضی‌اند و برای طراحی انتظار و بررسی محصول به کار می‌روند. هنگام عرضه، جدول آزمون باید با نتیجهٔ واقعی، نسخه و تاریخ تکمیل شود.
تماشا، محل ادامه و تکمیل درس سه وضعیت متفاوت‌اند
«تا دقیقهٔ دهم رسیده‌ام» می‌تواند به محل ادامهٔ پخش اشاره کند، نه اینکه تمام ده دقیقه را بدون پرش دیده باشم. «درس کامل شده» نیز ممکن است مطابق قاعدهٔ دوره به شرط دیگری وابسته باشد. اگر این معناها مخلوط شوند، هم گزارش مدرس و هم انتظار هنرجو آسیب می‌بیند. پیش از عرضهٔ مسیر آفلاین، باید تعریف هر وضعیت روشن شود: محل پیشنهادی ادامه، میزان تماشای ثبت‌شده، تکمیل آموزشی و نتیجهٔ ارزیابی یک چیز نیستند. حتی در نسخهٔ آنلاین نیز بهتر است دربارهٔ معنای عددها و نشان‌ها سؤال کنیم، نه اینکه از ظاهر مشابه آن‌ها نتیجهٔ یکسان بگیریم.
برای مثال فرضی، فیلمی بیست‌دقیقه‌ای را در نظر بگیرید. هنرجو هفت دقیقهٔ آغاز را می‌بیند، به دقیقهٔ پانزدهم می‌رود و پس از یک دقیقه توقف می‌کند. محل آخر پخش شانزده است، ولی از این عدد نمی‌توان شانزده دقیقه یادگیری یا حتی شانزده دقیقه تماشا نتیجه گرفت. اگر سامانه در دستگاه دیگر از آخرین محل ادامه می‌دهد، این فقط یکی از رفتارهای مرتبط با تجربهٔ کاربر است. گزارش آموزشی باید با تعریف خود خوانده شود. ترکیب آفلاین و وب نباید این تفاوت معنایی را پشت یک درصد ظاهراً دقیق پنهان کند.
وضعیت محلی یعنی چه و چه چیزی را ثابت نمی‌کند
وضعیت محلی، اطلاعاتی است که دستگاه برای ادامهٔ تجربهٔ همان کاربر نگه می‌دارد. این اطلاعات می‌تواند به آخرین محل مشاهده یا اقدام دیگری مربوط باشد، اما وجود آن به‌تنهایی اثبات نمی‌کند سرور هم همان داده را دریافت و پذیرفته است. برای یک محصول آفلاین، این جدایی طبیعی است؛ دستگاه در زمان قطع شبکه راهی برای ارسال خبر تازه ندارد. مسئلهٔ طراحی این است که کاربر بداند وضعیت نمایش‌داده‌شده مربوط به کجاست و آیا کاری از طرف او لازم است یا نه. تجربهٔ مناسب، کاربر را مجبور به حدس‌زدن از روی تفاوت دو صفحه نمی‌کند.
در راهنمای رسمی معماری آفلاین Android، منابع محلی و شبکه و لزوم رسیدگی به تفاوت زمانی آن‌ها توضیح داده می‌شود. این یک اصل معماری عمومی است و وجود آن در مستندات، قابلیت خاص فاکسیمون را اثبات نمی‌کند. برداشت عملی ما برای آموزش آن است که وضعیتِ هنوز هماهنگ‌نشده باید از دادهٔ تأییدشده متمایز و قابل فهم باشد. یک مدیر آموزشگاه هنگام پذیرش برنامه، باید این تفاوت را در قطع واقعی اتصال ببیند؛ نمایش آزمایشی روی شبکهٔ پایدار برای سنجش تجربهٔ آفلاین کافی نیست.
درصد دریافت فایل، درصد مطالعهٔ درس نیست
کاربر ممکن است همهٔ ویدیوهای یک فصل را برای سفر دریافت کند و هنوز هیچ‌کدام را ندیده باشد. در مقابل، ممکن است در وب بیشترِ فصل را مرور کرده باشد، ولی روی گوشی فقط یک درس دریافت شده باشد. بنابراین وضعیت دریافت و وضعیت مطالعه باید در فهم کاربر از هم جدا بمانند. اگر هر دو با یک عدد یا رنگ مشابه نمایش داده می‌شوند، لازم است معنای آن‌ها روشن باشد. در آزمون پذیرش، این دو وضعیت متقاطع را بسازید و از یک کاربر آزمایشی بخواهید توضیح دهد کدام فیلم آمادهٔ پخش و کدام درس واقعاً شروع شده است.
این تمایز در گزارش مدرس هم اهمیت دارد. گزارش موفق دریافت، فقط دربارهٔ رسیدن محتوای لازم به دستگاه خبر می‌دهد. از آن نمی‌توان مشارکت آموزشی، زمان مطالعه یا تسلط به موضوع نتیجه گرفت. اگر دادهٔ دریافت برای پشتیبانی جمع می‌شود، هدف و سطح دسترسی آن باید متناسب باشد. مدرس نیز برای پیگیری یادگیری، به شاهدهای مرتبط مانند تمرین و پرسش نیاز دارد. در راهنمای نهایی محصول، جای هر وضعیت و توضیح آن را با تصویر واقعی نشان دهید تا کاربر مجبور نباشد از شکل نوار یا محل عدد، نوع پیشرفت را حدس بزند.
ثبت روی سرور با ظاهرشدن در همهٔ دستگاه‌ها فرق دارد
ممکن است یک اقدام به سرور برسد اما دستگاه دوم هنوز نمای قدیمی داشته باشد. در این حالت، مشکل احتمالی با حالتی که ارسال اصلاً انجام نشده یکی نیست. کاربر نیازی به دانستن جزئیات زیرساخت ندارد، ولی باید بتواند با یک مسیر ساده وضعیت را بررسی کند. پیش از عرضه، لازم است روشن شود کدام نما معیار تأیید ثبت است، چه عملی برای تازه‌کردن وضعیت مجاز است و چه زمانی انتظارِ طولانی غیرعادی محسوب می‌شود. اگر این قاعده مشخص نباشد، پشتیبان ممکن است به هر اختلافی توصیهٔ حذف و نصب بدهد و شواهد مفید را از بین ببرد.
در آزمون فرضی، اپ یک وضعیت را پس از اتصال ارسال می‌کند و صفحهٔ وب از قبل باز مانده است. برای تشخیص علت اختلاف، زمان اقدام، زمان اتصال و زمان بازدید دوباره از وب را جدا ثبت کنید. بدون این سه زمان، جملهٔ «پیشرفت از بین رفت» دقیق نیست. شاید داده حفظ شده و فقط نمای دوم به‌روز نشده باشد؛ شاید ارسال خطا خورده باشد؛ شاید حساب‌ها متفاوت باشند. هر احتمال، قدم بررسی جدا می‌خواهد. نتیجه را با آنچه واقعاً مشاهده شده بنویسید و از تبدیل یک اختلاف نمایش به ادعای قطعیِ از دست رفتن داده پرهیز کنید.
نخست یک دستگاه و یک درس را آزمایش کنید
برای شروع، حسابی آزمایشی با یک درس کوتاه و محتوای غیرحساس انتخاب کنید. ابتدا در اتصال پایدار، وضعیت آغاز را ثبت کنید. اگر نسخهٔ عرضه‌شده دریافت آفلاین را پشتیبانی می‌کند، محتوا را از مسیر مستند همان نسخه آماده کنید و کامل‌بودن آن را بررسی کنید. سپس اتصال را به شکل عادی قطع کنید، بخشی مشخص را ببینید و برنامه را مطابق راهنمای محصول ببندید و دوباره باز کنید. هدف این مرحله، بررسی حفظ وضعیت در همان دستگاه است؛ هنوز دستگاه دوم یا تغییر حساب را وارد نکنید تا علت نتیجه قابل تشخیص بماند.
در برگهٔ آزمون بنویسید چه چیزی انتظار دارید: بازگشت به محل ادامه، نمایش وضعیت محلی یا پیام نیاز به اتصال. انتظار باید از رفتار تأییدشدهٔ محصول بیاید؛ اگر قاعده هنوز تعیین نشده، نتیجه را «نیازمند تعیین محصول» ثبت کنید. عددهایی مانند دقیقهٔ چهارم یا پنجم در این نمونه فقط نقطهٔ مشاهده‌اند و نباید به شرط تکمیل درس تبدیل شوند. کاربر می‌تواند بخشی را برای فهم بهتر دوباره ببیند یا عامدانه به عقب برگردد. سامانهٔ آموزشی باید این رفتار عادی را با تصورِ پیشرفتِ همیشه رو به جلو اشتباه نگیرد.
زمان برگشت اتصال، اقدام‌ها را با ترتیب ثبت کنید
پس از اجرای سناریوی یک‌دستگاهی، شبکه را دوباره وصل کنید و فقط رفتار معمول و مستند را انجام دهید. ابتدا یادداشت کنید آیا برنامه اتصال را تشخیص داده و آیا وضعیت قابل فهمی نشان می‌دهد. سپس حساب را در مرورگر باز کنید و نتیجه را با وضعیت آغاز مقایسه کنید. اگر با درخواست مجازِ تازه‌سازی اختلاف برطرف شد، آن را دقیق ثبت کنید؛ اگر نه، همان شواهد برای بررسی بعدی نگه داشته شود. بازکردن و بستن مکرر، تغییر حساب و پاک‌کردن داده‌ها در این مرحله تشخیص علت را دشوار می‌کند.
زمان رسیدن شبکه با زمان پذیرفته‌شدن همهٔ داده‌ها الزاماً برابر نیست. اتصال ممکن است برای چند لحظه برقرار و دوباره قطع شود، یا دستگاه فقط به شبکه‌ای وصل شود که دسترسی واقعی به خدمت ندارد. در برنامهٔ پذیرش باید شرایط آزمون روشن باشد: اینترنت پایدارِ مجاز، حساب معتبر و دسترسی فعال به دوره. اگر یکی از این‌ها برقرار نیست، آن را جدا یادداشت کنید. این دقت، برای سرزنش هنرجو نیست؛ کمک می‌کند تیم بداند با مسئلهٔ اتصال روبه‌رو است یا با رفتار همگام‌سازی در شرایطی که باید کار می‌کرده است.
دو دستگاه می‌توانند دو تاریخچهٔ معتبر داشته باشند
فرض کنید هنرجو صبح روی گوشی بدون شبکه تا بخش ششم پیش رفته و عصر، پیش از اتصال گوشی، در مرورگر بخش سوم را مرور کرده است. هر دو اقدام می‌توانند عمدی و متعلق به همان فرد باشند. یک عددِ تنها برای آخرین محل، الزاماً تمام معنای این دو مسیر را منتقل نمی‌کند. پیش از انتشار، محصول باید مشخص کند در چنین تعارضی چه چیزی حفظ می‌شود و تجربهٔ ادامه چگونه انتخاب می‌شود. این مقاله قانون مشخصی را به نسخهٔ آینده نسبت نمی‌دهد؛ مسئله، پرسشی است که باید در آزمون پذیرش پاسخ واقعی پیدا کند.
از دید هنرجو، مهم است بداند مرورِ بخشی قدیمی نباید بی‌توضیح به‌عنوان از دست رفتن همهٔ سابقه تجربه شود. از دید مدرس نیز نباید صرف آخرین محل پخش، به‌عنوان زمان تماشای کل تعبیر شود. برای آزمون، دو مسیر را با دادهٔ ساختگی و زمان‌های ثبت‌شده اجرا کنید؛ یک‌بار ابتدا گوشی و بار دیگر ابتدا مرورگر را به خدمت متصل کنید. مقایسهٔ این دو ترتیب می‌تواند تفاوت رفتار را آشکار کند. نتیجهٔ خوب، تکرارپذیر و قابل توضیح است؛ پذیرفتن نتیجه فقط به دلیل اینکه در یک اجرا دلخواه بوده، معیار کافی نیست.
تکرار ارسال نباید معنی یک اقدام را عوض کند
در اتصال ناپایدار ممکن است دستگاه بداند اقدامی را فرستاده، اما پاسخ نهایی را دریافت نکرده باشد. از دید کاربر، زدن دوبارهٔ یک دکمه یا بازکردن دوبارهٔ برنامه نباید به پیامد نامفهوم منجر شود. برای مسیرهای حساس‌تر مثل ارسال تکلیف یا ثبت پاسخ، لازم است رفتار تکرار روشن باشد. آیا اقدام قبلی شناخته می‌شود، تلاش تازه ساخته می‌شود یا پیام تصمیم لازم است؟ این‌ها انتخاب‌های محصول‌اند و باید مطابق نوع فعالیت بررسی شوند. نباید قاعدهٔ مناسبِ محل ادامهٔ ویدیو را خودکار به ارسال نهایی یک آزمون تعمیم داد.
یک سناریوی آموزشی برای پذیرش چنین است: اتصال پس از آغاز ارسالِ اقدام آزمایشی قطع می‌شود؛ کاربر وضعیت را می‌بیند؛ سپس اتصال برمی‌گردد و اقدام از مسیر مجاز دوباره بررسی می‌شود. انتظارِ ثبت‌شده باید بگوید چه نتیجه‌ای از نظر آموزشی درست است و کاربر چه تأییدی می‌بیند. در فایل همراه، ستون نتیجه عمداً خالی است تا رفتار عرضه‌شده ثبت شود. عدد یا نشانهٔ ساختگیِ قبولی به این سناریو اضافه نکنید. آزمونِ تکرار باید با حساب و دادهٔ متعلق به خود مجموعه انجام شود و به‌صورت ایجاد تلاش‌های بی‌حساب در دورهٔ واقعی هنرجویان اجرا نشود.
پیشرفت ویدیو را از پاسخ آزمون جدا نگه دارید
دیدن درس، نوشتن یادداشت، تحویل تمرین و ارسال پاسخ آزمون از نظر آموزشی و فنی یکسان نیستند. برای مثال، ادامهٔ ویدیو ممکن است قابل برگشت و مرور باشد، اما ارسال نهایی پاسخ می‌تواند قواعد زمان و تعداد تلاش داشته باشد. اگر برنامه‌ای اجازهٔ دیدن فیلم بدون شبکه می‌دهد، از این واقعیت نباید پشتیبانی همهٔ این فعالیت‌ها در حالت آفلاین را نتیجه گرفت. راهنمای دوره باید فهرست روشنی از کارهای ممکن و کارهای نیازمند اتصال داشته باشد. همین تفکیک مانع می‌شود هنرجو در آخرین لحظه انتظار ارسالِ ناممکن پیدا کند.
در سناریوی فرضیِ دورهٔ زبان، هنرجو می‌تواند فیلم نمونه را مرور کند و پاسخ تمرین را روی برگهٔ شخصی بنویسد، اما سامانه ممکن است برای ثبت رسمی پاسخ به اتصال نیاز داشته باشد. تا رفتار نسخهٔ محصول تأیید نشده، این وضعیت فقط یک مثال از مرزبندی است، نه اعلام قابلیت. مدرس باید زمان تحویل را با فرصت واقعیِ اتصال هماهنگ کند و راه جایگزین مجاز را پیشاپیش توضیح دهد. جایگزین نباید به گرفتن رمز دیگری، ارسال پاسخ در گروه عمومی یا تغییر غیرمجاز وضعیت پایگاه داده متکی باشد. مسیرِ موقت هم باید مسئول و شاهد روشن داشته باشد.
دسترسی معتبر، شرطی جدا از حفظ سابقه است
ممکن است سابقهٔ مطالعه محفوظ باشد اما مجوز فعلیِ مشاهدهٔ محتوا پایان یافته باشد. این دو موضوع را نباید در پیام خطا یکی کرد. هنرجو باید بتواند بفهمد مشکل از نبود سابقه نیست، بلکه ادامهٔ پخش به بررسی یا تمدید دسترسی نیاز دارد. از سوی دیگر، داشتن فایل و سابقهٔ قدیمی، اجازهٔ دائمیِ مشاهده ایجاد نمی‌کند. دوره و شرایط ثبت‌نام باید تعیین کنند دسترسی چه زمانی معتبر است. سیاست آفلاین نیز باید توضیح دهد کدام بررسی محلی و کدام تصمیم پس از ارتباط با سرور انجام می‌شود.
در حالت قطع کامل، فرمان تازهٔ سرور فوراً به دستگاه نمی‌رسد. بنابراین نباید هماهنگیِ لحظه‌ایِ پایان مجوز را در نبود هر نوع ارتباط وعده داد. در برنامهٔ پذیرش، انقضای محلی، نخستین اتصال پس از تغییر دسترسی و متن پیام مرتبط را جدا بررسی کنید. این بخش به راهنمای امنیت ویدیوی آفلاین مربوط است، اما تمرکز اینجا معنای وضعیت مطالعه است. صاحب دوره لازم است بداند آیا سابقه برای رسیدگی مجاز باقی می‌ماند و چگونه می‌توان بدون افشای دادهٔ خصوصی، درخواست کاربر را پیگیری کرد.
حساب و آموزشگاه درست را پیش از عیب‌یابی بررسی کنید
در سامانه‌ای که کاربر می‌تواند به محتوای چند مجموعه دسترسی داشته باشد، نام مشابه درس ممکن است گمراه‌کننده باشد. نخست مطمئن شوید روی هر دو دستگاه، همان حساب، همان آموزشگاه و همان دوره بررسی می‌شود. بهتر است شناسهٔ درس یا یک نشانهٔ غیرحساس و واضح در برگهٔ آزمون وجود داشته باشد. دو ویدیوی هم‌نام الزاماً یک دارایی نیستند و پیشرفت یکی نباید به دیگری نسبت داده شود. این کنترلِ ساده پیش از هر اقدام پرهزینه، احتمال پیگیریِ اشتباه و درخواست اطلاعات غیرلازم را کم می‌کند.
پشتیبان می‌تواند از کاربر بخواهد نام نمایشی دوره، زمان تقریبی مشکل و نسخهٔ برنامه را اعلام کند؛ نباید رمز ورود، کد یک‌بارمصرف یا کلید فایل را درخواست کند. اگر تصویر صفحه فرستاده می‌شود، اطلاعات شخصی و جزئیات دورهٔ دیگر در آن آشکار نباشد. در دستگاه مشترک هم پس از تغییر حساب باید وضعیتِ همان حساب فعلی مشخص باشد. آزمون این مرز را با دو حساب ساختگی اجرا کنید. درست‌بودن تجربهٔ یک کاربر روی دستگاه شخصی، به‌تنهایی جداسازی حساب‌ها را در استفادهٔ مشترک اثبات نمی‌کند.
حذف فایل محلی لزوماً حذف سابقه نیست
کاربر ممکن است برای آزادکردن فضا، نسخهٔ دریافت‌شده را پاک کند ولی انتظار داشته باشد سابقهٔ مطالعه در حسابش بماند. ممکن است خروج حساب یا حذف برنامه رفتار دیگری داشته باشد. تا راهنمای رسمی نسخهٔ عرضه‌شده این مرزها را روشن نکرده، نباید به کاربر وعدهٔ حفظ همهٔ وضعیت‌ها در هر نوع پاک‌سازی داد. در متن محصول باید بین حذف فایل رسانه، حذف دادهٔ محلی برنامه و حذف حساب تمایز وجود داشته باشد. یک عبارت عمومی مانند «پاک‌کردن کش» اگر آثارش مشخص نباشد، برای بازیابی مشکل آفلاین کافی نیست.
پیش از هر پاک‌سازی که احتمال حذف وضعیتِ هنوز ارسال‌نشده دارد، از مسیر مجاز وضعیت ثبت‌شده را بررسی کنید و راهنمای فعلی را بخوانید. در آزمون پذیرش، نخست یک درس ساختگی با سابقهٔ معلوم بسازید، سپس هر نوع حذف را جدا اجرا کنید و نتیجه را بنویسید. این آزمایش را روی حساب واقعیِ دارای تلاش یا تکلیف مهم انجام ندهید. هدف، شناخت قرارداد محصول است، نه کشف آن از طریق از دست دادن کار کاربر. پیام تأییدِ هر اقدام نیز باید اثرِ مهمش را پیش از انجام، با زبان قابل فهم بیان کند.
اصلاح ویدیو، تفسیرِ محل ادامه را تغییر می‌دهد
اگر مدرس از ابتدای فیلم بخشی را حذف کند، دقیقهٔ دهم نسخهٔ تازه ممکن است همان موضوعِ دقیقهٔ دهم نسخهٔ قبلی نباشد. بنابراین همگام‌سازی یک عددِ زمان بدون توجه به نسخه، همیشه تجربهٔ درستِ ادامه را نمی‌سازد. هنگام تغییر مهم محتوا، لازم است سیاست محصول و دوره دربارهٔ سابقهٔ پیشین روشن باشد. شاید پیام اصلاح و پیشنهاد شروع یک بخش مناسب‌تر از پرش خام به زمان قدیمی باشد. انتخاب نهایی باید با نسخهٔ واقعی و هدف آموزش هماهنگ شود و در آزمون پذیرش جای مستقل داشته باشد.
برای مثال فرضی، مدرس توضیح مقدمه را کوتاه می‌کند و دو دقیقه از اول درس کم می‌شود. هنرجویی که قبلاً تا دقیقهٔ هشت رفته، پس از دریافت نسخهٔ تازه باید بفهمد آیا جای ادامه بر اساس فصل، زمان یا تصمیم دیگری تعیین می‌شود. این مقاله به اپ آینده قاعدهٔ معینی نسبت نمی‌دهد؛ از تیم محصول انتظار داریم قاعده را مشخص و قابل آزمون کند. برای ادارهٔ نسخهٔ خود محتوا، راهنمای به‌روزرسانی دوره مکمل است. آن راهنما دربارهٔ تغییرات مدرس است؛ اینجا اثر همان تغییر بر سابقهٔ یادگیرنده را بررسی می‌کنیم.
بسته‌شدن برنامه را با حساب آزمایشی بررسی کنید
پایان مطالعه همیشه با زدن دکمه‌ای مشخص اتفاق نمی‌افتد. تماس تلفنی، جابه‌جایی به برنامهٔ دیگر یا تمام‌شدن باتری می‌تواند مسیر را قطع کند. پیش از عرضه باید معلوم شود کدام وضعیتِ مهم پس از بازگشت حفظ می‌شود و چه چیزی هنوز در انتظار ثبت است. سناریوها را روی دادهٔ ساختگی و در محدودهٔ آزمون مجاز اجرا کنید؛ قطع ناگهانی یا پاک‌سازی روی تکلیف مهم کاربر واقعی ابزار مناسبی برای کشف رفتار محصول نیست. انتظار هر وضعیت را پیش از اجرا بنویسید و اگر وابستگی به سیستم‌عامل یا محدودیت مشخصی وجود دارد، آن را در راهنما اعلام کنید.
جدول آزمون را پیش از مشاهدهٔ نتیجه آماده کنید
در جدول سناریوهای همگام‌سازی، وضعیت آغاز، اقدام، نوع اتصال و انتظار نیازمند تأیید کنار هم آمده‌اند. پیش از اجرا، ستون انتظار را بر اساس قرارداد محصول کامل کنید و پس از اجرا فقط آنچه دیده‌اید ثبت کنید. اگر انتظار هنوز مشخص نشده، آن سناریو آمادهٔ تأیید نیست. ثبت هم‌زمانِ انتظار و نتیجه پس از مشاهده، احتمال قبول‌کردن هر رفتار اتفاقی را بالا می‌برد. برای همهٔ سناریوها نسخهٔ برنامه، دستگاه و زمان ثبت لازم است تا نتیجه بعداً قابل تفسیر بماند.
آزمون‌ها را به ترتیب ساده تا پیچیده اجرا کنید: یک دستگاه، اتصال دوباره، دو دستگاه، ارسال تکراری، تغییر دسترسی و تغییر محتوا. اگر مرحلهٔ ساده شکست خورد، ادامهٔ سناریوهای پیچیده بدون ثبت و رسیدگی می‌تواند دادهٔ مبهم تولید کند. بعضی خطاها فقط در ترکیب وضعیت‌ها دیده می‌شوند، اما رسیدن به آن ترکیب باید کنترل‌شده باشد. در گزارش نهایی، «آزمون نشده» را از «قبول» جدا کنید و فهرست دستگاه‌های آزموده را واقعی بنویسید. نتیجهٔ شبیه‌ساز یا یک گوشی Android نباید تأیید iOS یا همهٔ دستگاه‌ها نامیده شود.
یک گزارش خطای مفید چگونه نوشته می‌شود
به‌جای «اپ پیشرفت را پاک کرد»، بنویسید از چه وضعیتی شروع کرده‌اید، چه اقدام مشخصی انجام شده و نتیجه در هر دستگاه چه بوده است. برای نمونهٔ فرضی: «حساب آزمایشی الف، درس نمونهٔ دوم، گوشی بدون شبکه تا بخش چهارم مرور شد؛ پس از اتصال پایدار، در وب همچنان بخش دوم نمایش داده شد؛ تازه‌سازی مجاز انجام شد و وضعیت تغییر نکرد». این گزارش هنوز علت را معلوم نمی‌کند، ولی برای بررسی قابل استفاده است. اشاره به زمان و نسخه کمک می‌کند تیم پشتیبانی شواهد مرتبط را پیدا کند و از حدس‌های پراکنده دور بماند.
گزارش را با دادهٔ کمینه بسازید. نام کامل هنرجو، متن خصوصی پرسش، توکن نشست یا تصویر مدارک خرید معمولاً برای نخستین تشخیص اختلافِ وضعیت لازم نیست. اگر بررسی تخصصی اطلاعات دیگری می‌خواهد، باید از مسیر امن و با دسترسی مناسب انجام شود. تا روشن‌شدن مسئله، کاربر را به ایجاد چند حساب تازه یا تکرار نامحدود یک تلاش حساس هدایت نکنید. اگر راه موقت وجود دارد، اثر و محدودیت آن را توضیح دهید و پس از رفع مشکل، نتیجهٔ نهایی را با همان سناریوی اصلی دوباره بررسی کنید.
گزارش مدرس باید تأخیر اتصال را قابل تفسیر کند
مدرس نباید صرف ندیدن یک وضعیت تازه در وب، نتیجه بگیرد هنرجو مطالعه نکرده است. اگر دوره مسیر آفلاین دارد، زمان آخرین اتصال یا وضعیت ثبتِ داده، در حدی که محصول به‌طور معتبر ارائه می‌کند، به تفسیر گزارش کمک می‌کند. در نبود چنین داده‌ای، از قضاوت قطعی پرهیز کنید و فرصت توضیح بدهید. همچنین تماشا و فهم درس را از هم جدا نگه دارید. یک سؤال کاربردی، تمرین یا گفت‌وگوی کوتاه می‌تواند شاهد بهتری دربارهٔ یادگیری بدهد تا خیره‌شدن به درصدی که تعریف و تازگی آن مشخص نیست.
در برنامهٔ دوره، زمان مورد انتظار برای اتصال و ثبت نتیجه را از پیش اعلام کنید؛ این زمان باید با شرایط واقعی مخاطبان سازگار باشد. اگر هنرجو در سفر است یا چند روز شبکه ندارد، لازم است بداند چه چیزی را می‌تواند انجام دهد و چه چیزی تا اتصال در انتظار می‌ماند. قاعدهٔ روشن به معنای معافیت نامحدود از تکلیف نیست؛ هدف آن است که تعهد آموزشی بر اساس چیزی قابل انجام و قابل مشاهده تعریف شود. سامانه و برنامهٔ آموزشی باید همدیگر را پشتیبانی کنند، نه اینکه هرکدام فرض متفاوتی دربارهٔ کار دیگری داشته باشند.
پیش از عرضه چه چیزی باید قطعی شود
برای تبدیل این چارچوب به راهنمای نهایی اپ فاکسیمون، چند پاسخ لازم است: کدام فعالیت آفلاین پشتیبانی می‌شود، مرجع نمایش هر وضعیت چیست، تعارض دو دستگاه چگونه توضیح داده می‌شود و کدام مسیر بازیابی برای کاربر مجاز است. سپس باید تصاویر واقعی، متن پیام‌ها و نتیجهٔ آزمون روی دستگاه‌های پشتیبانی‌شده جایگزین توضیح‌های کلی شوند. تا آن زمان، افزودن نام دکمهٔ فرضی یا عبارتِ «همهٔ پیشرفت‌ها خودکار و فوری منتقل می‌شوند» فقط انتظار نادرست می‌سازد. آماده‌بودن متن آموزشی با آماده‌بودن قابلیت محصول یکسان نیست.
برای تصمیم دربارهٔ شیوهٔ تحویل دوره، مقایسهٔ آنلاین و دانلود محافظت‌شده و پیلار حفاظت ویدیو را کنار این مطلب بخوانید. هنگام بررسی مدیریت دورهٔ فاکسیمون، نیاز خود را با سناریوی مشخص بیان کنید: یک هنرجو، دو دستگاه، مدت قطعی و نوع فعالیت. این اطلاعات، معیار پذیرش می‌سازد. راهنمای نهایی زمانی قابل انتشار است که هر وضعیت و اقدامِ وعده‌داده‌شده در نسخهٔ عرضه‌شده واقعاً آزموده شده باشد و کاربر بداند نتیجهٔ هر قدم را از کجا تشخیص دهد.
منابع و بررسی بیشتر
- معماری آفلاین و منابع محلی و شبکه در Android، مرجع عمومی؛ بررسی در ۳۱ اکتبر ۲۰۲۶.
- رویدادهای پلیر Media3، برای تفکیک وضعیت‌های پخش؛ این مرجع قرارداد اپ فاکسیمون نیست.
- دریافت رسانه در Android Media3، برای شناخت تفاوت دریافت رسانه و سایر قابلیت‌های یک برنامه.