يقدم هذا المقال إرشادات تصميم حول كيفية إنشاء تجربة مستخدم رائعة لتطبيقات الويب التقدمية PWAs على كلًا من الشبكات البطيئة وغير المتصلة.
يمكن أن تتأثر جودة اتصال الشبكة بشكل عام بعدة عوامل مثل:
- تغطية ضعيفة من المزود.
- ظروف طقس شديدة.
- انقطاع التيار الكهربائي.
- الدخول في مناطق ميتة الاتصال دائمًا dead zones مثل البنايات ذات الجدران المانعة لاتصالات الشبكة.
- الدخول في مناطق ميتة الاتصال مؤقتًا مثل السفر في قطار وعبور نفق.
- اتصالات الإنترنت المقيدة زمنيًا time-boxed مثل الاتصالات الموجودة في المطارات أو الفنادق.
- الممارسات الثقافية التي تتطلب وصولًا محدودًا أو معدومًا للإنترنت في أوقات أو أيام محددة.
هدفك هو تقديم تجربة مستخدم جيدة في وضع عدم الاتصال تقلل من تأثير التغيُّر في حالة التطبيق عندما يستعيد المستخدم اتصاله بالشبكة.
حدد ما تريد إظهاره للمستخدمين في حالة ضعف الاتصال بالشبكة
اطرح على نفسك أولًا السؤال التالي: كيف سيبدو نجاح وفشل اتصال الشبكة في تطبيقك؟ الاتصال الناجح هو التجربة العادية لتطبيقك بوجود اتصال بالشبكة، بينما يُمثِّل فشل الاتصال كيفية تصرف تطبيقك في حالة عدم الاتصال بالشبكة أو الاتصال البطيئ بها.
عند التفكير في نجاح أو فشل اتصال الشبكة، عليك أن تسأل نفسك أسئلة حول تجربة المستخدم UX المهمة هذه:
- ما هي المدة التي تنتظرها لتحديد نجاح أو فشل الاتصال؟
- ماذا يمكنك أن تفعل أثناء تحديد نجاح أو فشل الاتصال؟
- ماذا تفعل في حال فشل الاتصال؟
- كيف تبلِّغ المستخدم بما ورد أعلاه (أنه في مرحلة انتظار تحديد حالة التطبيق، أو أن اتصاله فشل أو أن اتصالة استُعيد)؟
بلغ المستخدمين عن حالتهم الحالية وعن تغيُّر حالة التطبيق
أخبر المستخدم بالإجراءات التي لا يزال بإمكانه القيام بها عندما يكون في حالة فشل الاتصال، وأيضًا أخبره بحالة التطبيق الحالية، مثلًا ممكن أن يقول الإشعار:
اقتباسيبدو أن اتصال الشبكة لديك غير مستقر. لا تقلق! ستُرسل الرسائل عند استعادة الاتصال.
بلّغ المستخدم بوضوح عند حدوث تغيُّر في حالة التطبيق في أسرع وقت ممكن.
استخدام تطبيق Google I/O مربع إشعار لإخبار المستخدم عندما يكون في حالة عدم اتصال بالشبكة، إذ يقول الإشعار "أنت بلا اتصال، تغييراتك في My Schedule ستُحفظ لوقت لاحق".
بلِّغ المستخدمين عندما يتحسن اتصال الشبكة لديهم أو يعود
يعتمد كيفية إبلاغك المستخدم بتحسُّن اتصال الشبكة على تطبيقك، فالتطبيقات مثل تطبيق حالة الطقس الذي يعطي الأولوية للمعلومات الآنية، يجب أن يُحدَّث تلقائيًا عند استعادة الاتصال، وإشعار المستخدم في مثل هكذا تطبيقات يجب أن يتم في أقرب وقت ممكن.
يوصَى بإِعلام المستخدم أنه قد تم تحديث تطبيق الويب في الخلفية، وذلك باستخدام تلميح مرئي عبر تنبيه أو أي وسيلة إشعارات تؤدي الغرض.
أحد الأمثلة على استخدام هذه التجربة هو متصفح Chrome Status التي تُظهر ملاحظة للمستخدم عند تحديث التطبيق في الخلفية.
تحتاج بعض التطبيقات مثل تطبيق الطقس إلى تحديث تلقائي، لأن البيانات القديمة ليست مفيدة مع تقلبات الطقس المستمرة.
يتيح تطبيق ana (أنا) للمستخدم معرفة وقت تحديث المحتوى عبر مربع إشعار في أعلى الشاشة.
يمكنك تخصيص مساحة ثابتة تُظهر من خلالها آخر مرة تم فيها تحديث التطبيق، سيكون هذا مفيدًا لتطبيق تحويل العملات مثلًا.
تطبيق Material mony يُظهر آخر تحديث للتطبيق.
وينبّه المستخدم عند تحديث التطبيق.
يمكن أن تعرض تطبيقات مثل تطبيقات الأخبار إشعارًا بسيطًا بالنقر للتحديث، لإعلام المستخدم بالمحتوى الجديد، فقد يتسبب التحديث التلقائي في فقدان المستخدمين لمكان تصفحهم.
صحيفة الانترنت Tailpiece تُنزّل آخر الأخبار تلقائيًا.
وتسمح للمستخدمين بالتحديث يدويًا حتى لا يفقدوا مكان تصفحهم في المقال.
تحديث واجهة المستخدم UI لتعكس الحالة السياقية الحالية
لكل بِت bit من واجهة المستخدم سياقُه ووظائفه الخاصة التي تتغير بناءً على كونها تتطلب اتصالًا ناجحًا بالشبكة أو لا، أحد الأمثلة على ذلك هو مواقع التجارة الإلكترونية التي يمكن تصفحها في وضع عدم الاتصال، فوقتها يُعطَّل زر الشراء إلى حين استعادة الاتصال.
يمكن أن تتضمن الأشكال الأخرى للحالات السياقية، البيانات، مثلًا يتيح التطبيق المالي Robinhood للمستخدمين شراء الأسهم، ويَستخدِم الألوان والرسومات لإعلام المستخدم عندما يكون السوق مفتوحًا، وعند إغلاق السوق تتحول الواجهة بالكامل إلى اللون الأبيض ثم تتحول إلى اللون الرمادي، أيضًا عندما تزيد قيمة السهم أو تنقص، يتحول كل عنصر واجهة مستخدم للسهم إلى اللون الأخضر أو الأحمر حسب حالته.
توضيح للمستخدم نموذج العرض الخاص بوضع عدم الاتصال
يعد وضع عدم الاتصال بالشبكة نموذج عرض جديد لجميع المستخدمين، كون نموذج العرض في الوضع المتصل بالشبكة هو الأساسي والمعروض دائمًا لديهم، لذا تحتاج إلى تعليم المستخدمين التغيّرات التي ستحدث عندما لا يكون لديهم اتصال بالشبكة، أبلغهم بالمكان الذي يتم فيه حفظ البيانات الكبيرة وامنحهم الإعدادات لتغيير سلوك التخزين الافتراضي، وتأكد من استخدام عدة مكونات لتصميم واجهة المستخدم مثل اللغة الغنية بالمعلومات والرموز والإشعارات واللون والصور لتوصيل نموذج العرض بدلاً من الاعتماد على خيار تصميم واحد لذلك.
تقديم تجربة افتراضية لوضع عدم الاتصال
إذا كان تطبيقك لا يتطلب بيانات كثيرة في عمله، فخزِّن البيانات التي يعتمد تطبيقك عليها مؤقتًا افتراضيًا، إذ إن المستخدمين يمكن أن يشعروا بالإحباط أكثر فأكثر إذا لم يكونوا قادرين على الوصول إلى بياناتهم إلا في وضع الاتصال بالشبكة. حاول أن تجعل التجربة مستقرة قدر الإمكان، فالاتصال غير المستقر سيجعل تطبيقك يبدو أنه غير جدير بالثقة، على عكس التطبيقات التي تقلل من تأثير فشل الاتصال بالشبكة التي تبدو خلَّابة بالنسبة للمستخدم.
يمكن لمواقع الأخبار الاستفادة من التنزيل التلقائي والحفظ التلقائي لآخر الأخبار بحيث يُتاح للمستخدم قراءة أخبار اليوم دون الاتصال بالشبكة، ولو على الأقل تنزيل النص بدون صور الخبر، أيضًا يمكن لتلك المواقع التكيُّف مع سلوك المستخدم، مثلًا إذا كان قسم الرياضة هو ما يشاهده المستخدم عادةً، تجعل تلك المواقع تنزيل أخبار هذا القسم هو الأولوية.
إذا كان الجهاز غير متصل بالشبكة، فسيُشعر Tailpiece المستخدم بذلك.
ويُعرِّف المستخدم أنه لا يزال بإمكانه استخدام التطبيق جزئيًا على الأقل.
عندما يتعلق الأمر بالإبلاغ عن حالة أحد التطبيقات، فإن قول "الشبكة معطلة" يرسل رسالة مفادها أن شبكة التطبيق تواجه مشكلات، بينما توضح عبارة "أنت غير متصل" للمستخدم أن المشكلة من طرفه.
إبلاغ المستخدم عندما يكون التطبيق جاهزًا للاستخدام دون اتصال بالشبكة
يجب أن توضِّح للمستخدمين عند تحميلهم تطبيقك لأول مرة، ما إذا كان بالإمكان استخدام التطبيق في وضع عدم الاتصال أم لا، يمكنك القيام بذلك باستخدام وِدجِت widget يوفر ملاحظات موجزة حول عملية ما، من خلال رسالة أسفل الشاشة مثلًا عند مزامنة قسم أو تنزيل ملف.
فكر مرة أخرى في اللغة التي تستخدمها وتأكد من أنها مناسبة لجمهورك، إذ يُسيئ مثلًا الجمهور غير التقني عمومًا فهم مصطلح "غير متصل"، لذا استخدم لغة قائمة على الإجراء action-based تساعد جمهورك على فهمها والاندماج معها.
يظهر تطبيق Google I/O إشعارًا مفاده: اكتمل التخزين المؤقت، وستعمل الزيارات المستقبلية في وضع عدم الاتصال.
يتضمن موقع Chrome Platform Status معلومات حول المساحة المشغولة بالتخزين المؤقت.
اجعل "التخزين في وضع عدم الاتصال" جزءًا واضحًا من واجهة التطبيقات كثيفة البيانات
إذا كان أحد تطبيقاتك يستخدم بيانات كثيرة، فتأكد من وجود مفتاح تبديل switch لاضافة عنصر ما للاستخدام دون اتصال save for offline بدلاً من التنزيل التلقائي له، وتأكد أن ذلك المفتاح غير محجوب من عناصر واجهة المستخدم الأخرى وأنه واضح للمستخدم.
أحد الأمثلة على ذلك هو مشغل الموسيقى الذي يحتاج ملفات ذات بيانات كبيرة، قد يرغب مستخدم هذا التطبيق في استخدام المشغل دون اتصال بالشبكة، فهنا تنزيل الموسيقى لاستخدامها لاحقًا يتطلب تخطيط مسبق من المستخدم كون الملفات ستحجز مساحة تخزين كبيرة، ووقتها يكون اطلاع المستخدم حول هذا الأمر لازمًا أثناء تهيئته للتطبيق.
توضيح ما هو متاح حاليا
كن واضحًا فيما يتعلق بالخيار الذي تقدمه، قد تحتاج إلى إظهار نافذة معينة أو إعداد ما يعرض مثلًا "المكتبة غير المتصلة بالشبكة" offline library أو فهرس المحتوى content index، الذي يمكن للمستخدم من خلاله رؤية ما خزّنه في هاتفه بسهولة. أيضًا تأكد أن الإعدادات موجزة وكن واضحًا بشأن مكان تخزين البيانات ومن يمكنه الوصول إليها.
إظهار التكلفة الفعلية للإجراء
يساوي العديد من المستخدمين قدرة التطبيق في وضع عدم الاتصال بقدرته على "التنزيل"، وغالبًا ما يستغل المستخدمون في البلدان ذات التغطية الضعيفة وقت الاتصال بالشبكة لحفظ محتوى التطبيق للاستخدام دون اتصال.
قد يتجنب مستخدمو الباقات المحدودة ذات الكلفة المرتفعة للاتصال بالإنترنت تنزيل ملفات كبيرة خوفًا من زيادة التكلفة، لذا يلزمك أيضًا عرض تكلفة تحميل الملفات أو تكلفة أداء المهام بشكل عام في تطبيقك، مثلًا عندما يكتشف تطبيق الموسيقى المذكور كمثال في فقرة سابقة أن المستخدم في خطة البيانات المدفوعة data plan، يعرِض حجم الملف المُشغَّل، ويتيح للمستخدم رؤية تكلفة تحميله.
ساعد في منع التجارب الساخرة
غالبًا ما ينجز المستخدمون تجربة ما ساخرة في التطبيق دون أن يدركوا ذلك، مثلًا قبل انتشار تطبيقات مشاركة الملفات المعتمدة على السحابة cloud-based، كان من الشائع أن يحفظ المستخدمون الملفات الكبيرة ويرفقوها برسائل البريد الإلكتروني ليواصلوا تحريرها من جهازٍ مختلف. من المهم عدم الإنجرار إلى تجربتهم الساخرة تلك، بل النظر إلى ما يحاولون تحقيقه منها، بمعنى، بدلاً من التفكير في كيفية جعل إرفاق ملف كبير أسهل، حُل مشكلة مشاركة الملفات الكبيرة عبر أجهزة متعددة باستخدام التخزين السحابي.
اجعل العمليات قابلة للنقل من جهاز لآخر
عند إنشاء تطبيقات لشبكات غير مستقرة الاتصال، حاول إجراء المزامنة بمجرد أن يتحسن الاتصال حتى تكون تجربة المستخدم قابلة للنقل من جهاز لآخر، مثلًا تخيل أن تطبيق سفر ما يفقد اتصال الشبكة في منتصف مهمة الحجز، وعند استعادة الاتصال، تتيح عملية تزامُن بيانات التطبيق مع حسابات المستخدمين لهم مواصلة الحجز على حواسيبهم المكتبية. ينزعج المستخدمين للغاية من التطبيقات غير القادرة على نقل تجاربهم بين الأجهزة.
أيضًا بلّغ المستخدمين بالحالة الحالية لبياناتهم، مثلًا يمكنك إظهار ما إذا تم مزامنة التطبيق أم لا، أعلمهم بكل المستجدات في حالة التطبيق لكن حاول ألا تثقل عليهم بالرسائل والإشعارات.
إنشاء تجارب تصميم متكاملة
تجارب التصميم المتكاملة inclusive تشمل تصميمًا ذا مغزى، ولغة بسيطة، وأيقونات معيارية، وتمثيلات هادفة، ستساعد المستخدم لإكمال مهمته في التطبيق بسلاسة وبساطة دون أي إعاقة.
استخدم لغة بسيطة وموجزة
تجربة المستخدم الجيدة لا تتعلق فقط بواجهة مصممة جيدًا، بل تتضمن المسار الذي يسلكه المستخدم بالإضافة إلى الألفاظ المستخدمة في التطبيق.
تجنب المصطلحات التقنية عند شرح حالة التطبيق أو مكونات واجهة المستخدم، وضع في اعتبارك أن عبارة "التطبيق غير متصل" قد لا تنقل للمستخدم الحالة الحالية للتطبيق.
تجنب المصطلحات غير المفهومة للمستخدمين غير التقنيين مثل: "عامل الخدمة".
استخدم اللغة الواضحة التي تصف الإجراء مثل: "تنزيل".
استخدم طرق تصميم متعددة لتسهيل تجربة المستخدم
استخدم اللغة واللون والمكونات المرئية لإظهار تغيُّر حالة التطبيق أو وضعه الحالي، فقد لا يلاحظ المستخدم حالة التطبيق إذا عُرضت باستخدام اللون فقط.
استخدام واجهة مستخدم رمادية لتمثيل وضع عدم الاتصال هو بديهة المصممين، لكن في الويب، يمكن أن يُفهم من هذه الواجهة أن العنصر محمّل، كما أن عناصر واجهة المستخدم الرمادية مثل عناصر الإدخال في النماذج تعني أيضًا أن العنصر معطل، بالتالي استخدام اللون فقط لتصوير الحالة يمكن أن يسبب لبسًا في فهمها. لمنع هذا اللبس، عبِّر عن حالات المستخدم المختلفة بعدة طرق، مثلًا باستخدام كلًا من الألوان والتسميات والأيقونات ومكونات واجهة المستخدم الواضحة وغيرها.
لا تستخدم اللون كوسيلة وحيدة لوصف الحالة، كما في الصورة التالية مستخدَم اللون الأحمر فقط للدلالة على تجاوز النص المكتوب للعدد المسموح به من الحروف.
بل استخدم مزيجًا من عناصر التصميم لتوصيل المعنى، مثل اللغة الواضحة بالإضافة للون، لاحظ عند استخدم التعبير اللفظي الموضح للخطأ "تجاوزْت الحد الأقصى لعدد الأحرف" مع اللون المعبّر لإزالة اللبس بشأن سبب الخطأ.
استخدم أيقونات بليغة
تأكد من إيصال المعلومات للمستخدم بشكل صحيح وذلك باستخدام تسميات نصية ذات معنى مع الأيقونات، إذ يمكن أن يسبب استخدام الأيقونات لوحدها لبسًا.
قد يسيء المستخدمون فهم بعض الأيقونة المستخدمة في التطبيقات، مثلًا يعد استخدام أيقونة القرص المرن لحفظ البيانات أمرًا منطقيًا بالنسبة للجيل الأكبر سنًا، لكن قد تسبب هذه الأيقونة لبسًا للمستخدمين الأصغر سنًا الذين لم يروا قرصًا مرنًا في حياتهم، وبالمثل فإن أيقونة القائمة التي تشبه البرغر hamburger menu قد تشوِّش المستخدمين عند عرضها دون تسمية.
أيقونة الحفظ دون اتصال التي على شكل التنزيل النموذجي -أو ربما إذا كان الإجراء يتضمن مزامنة- قد تكون على شكل أيقونة مزامنة، لذا عند تقديم أحد الأيقونات المتعلقة بوضع عدم الاتصال، حاول أن توفر معها تسمية نصية ووصف.
قد تفسَّر بعض الإجراءات على أنها حفظ دون اتصال بدلاً من إظهار حالة الشبكة، لذا فكر في الإجراء الذي تحاول الإبلاغ عنه بدلاً من عرض أيقونات مجردة (ذات طابع عام) للمستخدم، كأن يكون شكل أيقونة حفظ البيانات أو تنزيلها قائمًا على الإجراء action-based أي يدل على طبيعة استخدامها بالضبط.
يمكن أن يعني وضع عدم الاتصال عددًا من الأشياء اعتمادًا على السياق، مثل التنزيل، والتصدير، والتثبيت، وما إلى ذلك. لمزيد من المعرفة، راجع مجموعة أيقونات التصميم Material Design.
استخدم عناصر نائبة في التخطيط ريثما يجهز المحتوى
مخطط الهيكل skeleton layout للتطبيق هو عناصر نائبة توضع في هيكل التطبيق الرئيسي ريثما يُحمّل المحتوى الفعلي، يمكنك استخدامه لتوضّح للمستخدم أن محتوى الصفحة على وشك التحميل.
ضع في اعتبارك أيضًا استخدام واجهة التحميل المسبق preloader UI، مع رسالة نصية تخبر المستخدم أنه يجري تحميل التطبيق الآن، يمكنك أيضًا تحريك محتوى ما أو وضع شريط حالة أو حلقات دوارة لإشعار المستخدم أن التطبيق حي وجاري تحميل محتواه، بالتالي إقناع المستخدم بعدم إعادة طلب عنوان التطبيق أو تحديثه.
وضع عناصر نائبة في هيكل التطبيق الرئيسي مكان المحتوى ريثما تُحمّل مع عرض إشعار يخبر المستخدم بمعدل التنزيل.
ثم وضع المحتوى مكان تلك العناصر النائبة متى ما انتهت عملية التحميل وأصبح المحتوى جاهزًا للعرض.
لا تعيق المحتوى
عندما يشغِّل المستخدم إجراء مثل إضافة عنصر جديد، فإن التطبيق يتصل بالخادم لمزامنة العنصر الجديد، وللدلالة على ذلك فإنه يعرض عنصر تدخُّلي للتحميل يغطي الشاشة بأكملها (غالبًا أيقونة التحميل الدائرية تتدخل وسط الصفحة وتحجب تنفيذ اي عملية ريثما ينتهي التحميل لتختفي بعدها). قد يعمل هذا بشكل جيد إذا كان لدى المستخدم اتصال شبكة ثابت، لكن إذا كان اتصال الشبكة غير مستقر، فلا يمكن للمستخدمين التخلص من عنصر التحميل الذي يغطي الشاشة أثناء تحميل بياناتهم، فكأن الواجهة تمنعهم من القيام بأي شيء في التطبيق وتعيق ظهور محتواه. هذه ليست تجربة جيدة، بل يجب أن يتجنب تطبيقك التعامل مع طلبات الشبكة التي تعيق ظهور في وضع الاتصال غير المستقر، والسماح بدلًا من ذلك للمستخدمين بالاستمرار في تصفح تطبيقك ومهام قائمة الانتظار التي ستُنفَّذ وتُزامَن بمجرد تحسُّن الاتصال.
أظهر حالة الإجراءات من خلال تزويد المستخدمين برد فعل، مثلًا إذا كان أحد مستخدمي تطبيق مستنداتك يُحرِّر مستند عند انقطاع الاتصال، ففكر في تغيير تصميم رد الفعل بحيث يكون مختلفًا بشكل مُلاحَظ عما كان عليه قبل انقطاع الاتصال، لكن حافظ على إظهار أنه قد تم حفظ ملفه وستتم مزامنته عندما يُستعاد الاتصال بالشبكة، فذلك سيؤدي إلى إعلام المستخدم بمختلف الحالات المتاحة وطمأنته بأن قد تم تخزين مهمته أو إجراءه، كما لهذا فائدة إضافية تتمثل في زيادة ثقة المستخدم في استخدام تطبيقك.
صمم لجميع طبقات المستخدمين
تعد الأجهزة منخفضة الجودة في بعض المناطق أمرًا شائعًا، وكذلك اتصال الشبكة غير المستقر، الذي بالنسبة للعديد من المستخدمين، لا يمكنه تحمّل نقل البيانات، لذا تحتاج في مثل هكذا حالات إلى كسب ثقة المستخدم من خلال الشفافية والاقتصاد في التعامل مع البيانات، وذلك بأن تفكِّر في طرق لمساعدة مستخدمي الاتصالات الضعيفة وطرق لتبسيط الواجهة بهدف تسريع إنجاز المهام. حاول دائمًا سؤال المستخدمين قبل تنزيل محتوى ضخم من البيانات.
اعرض خيارات النطاق الترددي المنخفض low bandwidth للمستخدمين ذوي اتصال الشبكة الضعيف، أي قدِّم أصولًا قليلةً للتطبيق إذا كان اتصال الشبكة بطيئ. أيضًا وفِّر ميزة للاختيار ما بين الأصول عالية الجودة و منخفضة الجودة.
الخلاصة
يعد إعلام المستخدم بحالة التطبيق وبياناته مفتاحًا لتجربة المستخدم غير المتصلة بالشبكة. حاول إنشاء ارتباطات بأشياء مألوفة، مثلًا اجعل تجربة مشاهدة البيانات دون اتصال نفس التجربة المألوفة التنزيل للاستخدام لاحقًا.
تذكر هذه الإرشادات عند تصميم تجربة المستخدم للشبكات غير المستقرة:
- فكر في كيفية التصميم في حالة نجاح الاتصال بالشبكة وحالة فشل الاتصال وأيضًا عدم استقراره.
- إذا كانت تكلفة نقل أو تخزين البيانات مرتفعة في تطبيقك، يجب مراعاة إعلام المستخدم بذلك.
- بالنسبة لمعظم المستخدمين على مستوى العالم، فإن البيئة الفنية لاتصال الشبكة (مثلًا مكان المستخدم بالنسبة للموجِّه أو الرواتر) تكاد تكون متنقلة بحتًا.
- الأجهزة القديمة ذات الأداء المنخفض، بالإضافة لسعة تخزين وذاكرة وقدرة معالجة محدودة، وشاشات صغيرة بجودة قليلة، فتأكد أن يكون مراعاة الأداء على مثل هذه الأجهزة جزء من تصميمك.
- اسمح للمستخدمين بتصفح تطبيقك عندما يكونوا في وضع عدم اتصال.
- أعلِم المستخدمين بوضعهم الحالي وتَغيُّر حالتهم.
- حاول توفير وضع عدم الاتصال افتراضيًا إذا كان تطبيقك لا يحتاج بيانات كثيرة.
- إذا كان تطبيقك يعالج كمية كبيرة من البيانات، فأعلِم المستخدمين حول كيفية تنزيل البيانات للاستخدام دون اتصال.
- اجعل المستخدم قادر على التنقل بين الأجهزة مع المحافظة على نفس التجارب بينها لنفس التطبيق.
- استخدم كلًا من اللغة والأيقونات والتمثيل والكتابة واللون للتعبير عن الأفكار للمستخدم.
- قدم تشجيع وتطمين وردود أفعال لمساعدة المستخدم في فهم حالات التطبيق المختلفة.
ترجمة -وبتصرف- للمقال Offline UX design guidelines من موقع web.dev.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.