هل يجب أن يهتز تطبيق العمل بعد كل لمسة؟

لا يحتاج تطبيق العمل إلى الاهتزاز بعد كل لمسة. اختر تفاعلات محددة تساعد فيها الاستجابة اللمسية المستخدم على فهم ما حدث، مع إبقاء المهمة واضحة عندما لا يشعر بأي اهتزاز. ابدأ بمعنى الإشارة، لا بطلب جعل التطبيق أكثر حيوية فقط.

يتناول هذا الدليل التغذية الراجعة أثناء استخدام تطبيق Android. أما تنبيهات الرسائل الواردة والتذكيرات في الخلفية فتحتاج إلى متطلبات مستقلة. النبضة التي يشعر بها الشخص في يده لا تثبت أن زميلا تلقى إشعارا، ولا أن الخادم قبل المعاملة.

ما الذي تؤكده النبضة؟

في قائمة فحص ميدانية، قد ترافق الإشارة اختيار إجابة على الجهاز. وعند إرسال طلب، توجد لحظات مختلفة: الضغط على الزر، وبدء المعالجة، ثم تأكيد النتيجة. لا ينبغي التعامل معها على أنها حدث واحد.

اكتب بجانب كل تفاعل مختار معنى الإشارة. إذا كانت تعني «تم الضغط»، فلا تعرض معها عبارة تؤكد حفظ الطلب قبل التحقق منه. يجب أن تظل المعالجة ونتيجتها واضحتين على الشاشة. هذه متطلبات عملية للمشروع، وليست قواعد معاملات يفرضها Android على نشاطك.

تجنب أيضا استخدام النبضة نفسها لقبول إدخال ورفضه من دون تفسير واضح آخر. لا ينبغي أن يضطر الموظفون إلى حفظ شيفرة اهتزاز غير موثقة حتى ينجزوا عملهم.

خفف الإشارات في الأعمال المتكررة

توصي إرشادات Android بأن تكون التأثيرات المصاحبة للأحداث المتكررة، مثل التمرير أو تحريك مؤشر تحديد النص، خفيفة جدا. وتوصي بالاتساق أيضا: إذا كانت التفاعلات المتشابهة تتضمن استجابة لمسية، فينبغي تطبيق التأثير نفسه عليها.

لذلك راجع سلسلة عمل واقعية، لا زرا استعراضيا واحدا. قد يكون التأثير لطيفا في أول تجربة ثم يصبح مزعجا أثناء جرد طويل. اسأل المختبر إن كانت الإشارة توضح المهمة أم تزاحمها.

يمكن تنظيم المقترحات إلى اختيار عادي، وتأكيد مقصود، ونتيجة مهمة. هذا تقسيم يساعد على مناقشة المشروع، وليس تصنيفا إلزاميا للمنصة. احذف التأثيرات التي لا تحمل معنى مفيدا قبل طلب تأثيرات أكثر تعقيدا.

خطط لغياب الاهتزاز

تحذر وثائق Android من أن التأثيرات اللمسية الغنية تدعمها أجهزة أقل، ولذلك تحتاج إلى استراتيجية بديلة. لا تعتبر العرض على هاتف مرتفع المواصفات دليلا على أن كل هاتف مدعوم سيقدم الإحساس نفسه.

اطلب من المطور توضيح التأثيرات المناسبة للأفعال، وما يحدث على الأجهزة المشمولة فعليا بالدعم. لا يجب أن يقلد البديل كل تفاصيل التأثير المعقد. المهم أن تشرح الشاشة الفعل ونتيجته عندما تغيب الإشارة أو تختلف.

يجب مثلا أن تبقى إجابة الفحص المحددة واضحة بصريا. وعند فشل الحفظ، يحتاج المستخدم إلى تفسير مقروء وخطوة لمعالجة المشكلة. لا تستبدل غياب الاهتزاز بصوت أعلى تلقائيا؛ ملاءمة الصوت لبيئة العمل قرار مستقل.

اختبر الفهم، لا الإحساس وحده

استخدم سجلات تجريبية بدلا من معاملات عملاء حقيقية. نفذ سلسلة معتادة من المهام، ثم كررها عندما تكون الاستجابة اللمسية غير متاحة أو معطلة من الإعدادات المناسبة. قارن النتائج الظاهرة. يجب ألا تعتمد معرفة الخطوة التالية على الشعور بالاهتزاز.

أضف حالة فشل في الإرسال وأخرى تتأخر فيها الاستجابة. اسأل المختبر عما فهمه من النبضة قبل شرح معناها. إذا فهم نبضة الضغط على أنها نجاح الحفظ، فعدّل توقيتها أو الرسالة المصاحبة. اختبر الضغط المتكرر أيضا، حتى لا تشجع الاستجابة المستخدم على إعادة الإرسال بينما المعالجة مستمرة.

سجل طراز الجهاز وإصدار النظام والأفعال المختبرة والسلوك المشاهد. هذه مراجعة قبول خاصة بالمشروع، وليست شهادة شاملة لإمكانية الوصول. عند التخطيط إلى تطبيق مخصص للعمل، أدرج قائمة صغيرة بالتفاعلات المفيدة بجانب سير العمل الأساسي، بدلا من اشتراط الاهتزاز في كل موضع.

المصدر وحدود الاستفادة منه

تدعم صفحة Android Developers: Haptics design principles، التي روجعت في 26 أكتوبر 2026، إرشادات الاتساق وتكرار التأثيرات والحاجة إلى بديل حسب الجهاز. أمثلة العمل وخطوات القبول توصيات عملية. لا يتضمن الدليل ادعاء عن سلوك iPhone، أو ضمانا شاملا لإمكانية الوصول، أو زعما بأن تطبيقك خضع لاختبار فعلي.