الإجابة المختصرة: أذونات التطبيق أخطر لحظة في تجربة المستخدم، لأن قرارها شبه نهائي: من رفض إذن الموقع أو الإشعارات لن يعود غالبًا لتفعيله، والنظامان يقيّدان إعادة السؤال. والقاعدة التي تختصر كل شيء: لا تطلب إذنًا قبل أن يفهم المستخدم لماذا. اطلبه داخل المهمة التي يحتاجه فيها، بنص يشرح الفائدة له لا لك، وبعد شاشة تمهيدية تسمح بـ«لاحقًا». وكل إذن لا يستعمله تطبيقك يجب أن يُحذف — فوجوده وحده يخفض ثقة المستخدم وقد يوقفك في المراجعة.
لماذا الرفض شبه نهائي؟
حين يرفض المستخدم نافذة النظام، لا تستطيع إظهارها مجددًا في أغلب الحالات. الطريق الوحيد بعدها أن يذهب هو إلى إعدادات الجهاز، ويبحث عن تطبيقك، ويفعّل الإذن يدويًا.
وهذا لا يحدث عمليًا. لا لأن المستخدم عنيد، بل لأنه لا يعرف أن هذا سبب المشكلة أصلًا. هو يرى ميزة لا تعمل، فيستنتج أن التطبيق سيئ.
ولهذا فإن نافذة الإذن ليست خطوة تقنية بل قرار تصميمي يستحق تفكيرًا أكثر مما يُعطى له عادة.
القاعدة 1: مهّد قبل نافذة النظام
قبل استدعاء نافذة النظام، اعرض شاشة أو رسالة من صنعك تشرح: ماذا سنطلب، ولماذا، وماذا يخسر إن رفض.
الفرق الجوهري: شاشتك أنت تحوي زر «لاحقًا» — ومن ضغطه تستطيع سؤاله مرة أخرى بعد أيام. أما من رفض نافذة النظام فقد أُغلق البابُ.
مثال عملي: «لنعرض المطاعم القريبة منك، نحتاج إذن الموقع. تستطيع أيضًا إدخال العنوان يدويًا». هذه الجملة ترفع الموافقة، وتترك بديلًا لمن رفض.
القاعدة 2: اطلب داخل المهمة لا قبلها
الإذن يُطلب في اللحظة التي يصير فيها ضروريًا:
الكاميرا: عند الضغط على «أرفق صورة»، لا عند فتح التطبيق. الموقع: عند «ابحث بالقرب مني»، لا في شاشة الترحيب. الإشعارات: بعد أول طلب أو حجز، حين يصير الإشعار مفيدًا له فعلًا. وتفصيلها في إشعارات التطبيق. جهات الاتصال: عند «ادعُ صديقًا»، وبعد أن يكون قد قرّر الدعوة.
والقاعدة العامة: إن كان المستخدم قد ضغط زرًا يحتاج الإذن، فهو مستعدّ لمنحه. وإن لم يضغط شيئًا، فأنت تطلب من غريب مفتاح بيته.
القاعدة 3: اكتب النص كأنك تخاطب إنسانًا
النص الذي يظهر في نافذة النظام تكتبه أنت، وهو أهم جملة في التطبيق كله.
السيئ: «يحتاج التطبيق إلى الوصول إلى الموقع». الجيد: «لعرض الفروع الأقرب إليك وحساب وقت التوصيل».
والفرق أن الأول يصف طلبًا، والثاني يصف فائدة. اكتب ماذا يستفيد المستخدم، لا ماذا يحتاج نظامك.
وانتبه للعربية: النص المترجم آليًا في نافذة الإذن يفضح التطبيق في أخطر لحظة.
القاعدة 4: احذف كل إذن لا تستعمله
مراجعة سريعة قبل كل إصدار: ما الأذونات المعلنة في ملف التطبيق؟ وأيها يُستعمل فعلًا؟
الأذونات الزائدة تأتي عادةً من ثلاثة مصادر: مكتبة خارجية أضافتها تلقائيًا، وميزة أُلغيت ولم يُحذف إذنها، ونسخ لصق من مشروع سابق.
وأثرها مضاعف: المستخدم يرى قائمة أذونات مخيفة في المتجر، والمراجع يسأل عن مبررها، وأنت تتحمّل إعلانًا ببيانات لا تجمعها أصلًا.
القاعدة 5: اطلب الأقل لا الأوسع
كثير من الأذونات لها درجات، والفريق يطلب الأوسع «تحسّبًا».
الموقع: «أثناء الاستخدام» يكفي لأغلب التطبيقات. أما «في الخلفية» فيحتاج مبررًا قويًا ويُراجَع بصرامة، ويُخيف المستخدمين بحق.
الصور: أغلب الأنظمة تتيح اختيار صورة محددة بلا منح وصول للمعرض كله. استخدم المنتقي المحدود.
الرسائل النصية: لا تطلب قراءة الرسائل لتعبئة رمز التحقق؛ استخدم الواجهة المخصّصة التي تقرأ رسالة واحدة بصيغة متفق عليها.
والقاعدة: كل توسيع في الإذن يجب أن يقابله سبب تكتبه في سطر واحد. إن عجزت عن كتابته، فلا تطلبه.
القاعدة 6: اجعل التطبيق يعمل بلا الإذن
هذا الفرق بين تطبيق محترف وآخر هشّ. ماذا يحدث حين يرفض المستخدم؟
السيئ: شاشة فارغة، أو رسالة «يجب تفعيل الإذن»، أو تطبيق يعلق.
الجيد: مسار بديل. رفض الموقع؟ اسمح بإدخال العنوان. رفض الكاميرا؟ اسمح باختيار صورة من الملفات. رفض الإشعارات؟ اعرض الحالة داخل التطبيق بوضوح.
والمكسب المزدوج: المستخدم يكمل مهمته، ويرى أن تطبيقك يحترم قراره — وكثيرون يمنحون الإذن لاحقًا حين يفهمون قيمته بالتجربة.
القاعدة 7: تعامل مع «رفض دائم» بلطف
بعد رفضين، يعتبر النظام القرار دائمًا ولا يعرض النافذة مجددًا. وهنا يخطئ كثيرون فيعرضون رسالة إلحاح متكرّرة.
الصحيح: رسالة واحدة هادئة في السياق تشرح ما لا يعمل وكيف يفعّله من الإعدادات، مع زر يفتح إعدادات التطبيق مباشرة. مرة واحدة، لا في كل زيارة.
القاعدة 8: راجع الأذونات مع كل ترقية للنظام
الأنظمة تغيّر قواعد الأذونات باستمرار: إذن ينقسم إلى اثنين، أو يصير مؤقتًا، أو يتطلب مبررًا جديدًا.
والنتيجة إن أهملت: ميزة تتوقف عن العمل بعد ترقية نظام المستخدم، بلا أن يتغيّر شيء في كودك. وهذا من أشيع أسباب الأعطال المفاجئة، وهو جزء مما تشتريه صيانة التطبيق بعد الإطلاق.
جدول: الإذن ومتى يُطلب
| الإذن | متى تطلبه | البديل عند الرفض | |—|—|—| | الموقع (أثناء الاستخدام) | عند البحث القريب | إدخال العنوان يدويًا | | الموقع (في الخلفية) | لتتبّع رحلة فعلية فقط | تحديث يدوي للحالة | | الكاميرا | عند التقاط صورة | اختيار من الملفات | | الصور | عند إرفاق صورة | منتقي صورة واحدة | | الإشعارات | بعد أول عملية ناجحة | حالة ظاهرة داخل التطبيق | | جهات الاتصال | عند دعوة صديق | مشاركة رابط | | الميكروفون | عند بدء تسجيل | كتابة نصية | | الملفات | عند رفع مستند | التصوير بدل الرفع |
جدول: نصوص أذونات قبل وبعد
| الإذن | نص ضعيف | نص أفضل | |—|—|—| | الموقع | يحتاج التطبيق موقعك | لعرض أقرب فرع وحساب وقت الوصول | | الكاميرا | السماح بالوصول للكاميرا | لتصوير المستند وإرفاقه بطلبك | | الإشعارات | تفعيل الإشعارات | لنخبرك فور خروج طلبك | | جهات الاتصال | الوصول لجهات الاتصال | لاختيار من تدعوه بلا كتابة رقمه |
الفرق بين إعلان الإذن وطلبه
خلط تقني يقع فيه فرق كثيرة، ونتيجته أذونات تظهر للمستخدم بلا سبب:
الإعلان يحدث في ملف إعدادات التطبيق، ويعني أن التطبيق قد يستخدم هذه القدرة. وهو ما يظهر في صفحة المتجر تحت «الأذونات».
الطلب يحدث في وقت التشغيل، وهو نافذة النظام التي يراها المستخدم.
والمشكلة: إذن معلن ولا يُطلب أبدًا يبقى ظاهرًا في المتجر ويثير الشك بلا فائدة. وإذن يُطلب بلا إعلان يفشل صامتًا في بعض الحالات.
راجع الملفين معًا قبل كل إصدار: قائمة المعلن، وقائمة المطلوب فعلًا في الكود. أي فرق بينهما خطأ يستحق التصحيح.
حالة عملية: تطبيق توصيل
لنطبّق القواعد على مثال ملموس فيه ثلاثة أذونات حساسة:
الموقع أثناء الاستخدام — يُطلب عند الضغط على «توصيل إلى موقعي»، بنص: «لتحديد عنوانك بدقة وحساب وقت الوصول». والبديل عند الرفض: إدخال العنوان يدويًا مع اختيار الحي من قائمة.
الإشعارات — تُطلب بعد إتمام أول طلب لا قبله، بنص: «لنخبرك حين يخرج طلبك». والبديل: شريط حالة ظاهر في الشاشة الرئيسية يعرض حالة الطلب الحالي.
الكاميرا — تُطلب فقط للمندوب عند تصوير إثبات التسليم، ولا تُطلب من العميل أبدًا. وهذه نقطة مهمة: التطبيق الواحد قد يحوي دورين بأذونات مختلفة تمامًا، والخلط بينهما يجعل العميل يرى طلبات لا تخصّه.
والنتيجة العملية لهذا الترتيب: المستخدم لا يواجه أي نافذة إذن قبل أن يفهم التطبيق، وكل نافذة تظهر له تأتي بعد فعل قام به هو.
ماذا يرى المستخدم في المتجر؟
صفحة تطبيقك في المتجر تعرض ملخّصًا للأذونات ولما تجمعه من بيانات. وكثيرون يقرؤونه فعلًا قبل التنزيل، خصوصًا في التطبيقات المالية والصحية.
اجعله قصيرًا ومفهومًا: كل إذن زائد يطيل القائمة ويثير سؤالًا. وكل نوع بيانات تعلنه يظهر هناك.
واشرح الغريب منها في وصف التطبيق نفسه بسطر واحد. الشفافية المسبقة تمنع مراجعات سلبية تتّهمك بما لم تفعله.
أسئلة شائعة
كم نسبة الموافقة الطبيعية؟
تتفاوت كثيرًا بين الأذونات والأسواق، لكن الفارق الأكبر يصنعه موضع الطلب لا نوع التطبيق. الطلب في السياق يضاعف الموافقة مقارنة بالطلب عند الفتح الأول، وهذا أهم من أي رقم مرجعي.
هل أطلب كل الأذونات دفعة واحدة؟
لا. سلسلة نوافذ متتالية عند الفتح هي أسوأ نمط ممكن، وتؤدي إلى رفض جماعي.
تطبيقنا يحتاج الموقع في الخلفية فعلًا، ماذا نفعل؟
اشرح السبب بوضوح داخل التطبيق قبل الطلب، واكتب مبررًا مفصّلًا للمتجرين، وأظهر مؤشرًا مرئيًا أثناء التتبع. الشفافية هنا شرط قبول لا لباقة.
هل يمكن معرفة من رفض الإذن؟
تستطيع تسجيل حدث بلا بيانات شخصية: «طُلب الإذن» و«مُنح» أو «رُفض». وهذا من أنفع الأحداث في تحليلات التطبيق لأنه يقيس أثر كل تعديل على النص أو التوقيت.
هل الأذونات تختلف بين النظامين؟
نعم في التفاصيل: أسماء الأذونات، ودرجاتها، وسلوك الرفض المتكرر. لكن المبدأ واحد — السياق أولًا، والنص الصادق ثانيًا، والبديل ثالثًا.
ماذا عن التتبع الإعلاني؟
يخضع لإذن منفصل، ومعدّل رفضه مرتفع جدًا. لا تبنِ نموذج عملك على افتراض موافقة الأغلبية عليه.
ماذا لو رفض المستخدم إذنًا لا يعمل التطبيق بدونه إطلاقًا؟
هذه حالة نادرة وتستحق مراجعة التصميم قبل مراجعة النص. وإن كانت حتمية فعلًا — تطبيق كاميرا مثلًا — فاشرح بوضوح تام، واعرض زر فتح الإعدادات، ولا تُظهر شاشة فارغة بلا تفسير.
هل تختلف قواعد الأذونات للأجهزة اللوحية؟
المبدأ واحد، لكن السياق يختلف: الجهاز اللوحي غالبًا مشترك بين أفراد الأسرة، وهذا يجعل أذونات مثل الموقع وجهات الاتصال أكثر حساسية في نظر المستخدم.
هل أذكر الأذونات في وصف المتجر؟
مفيد أن تشرح في الوصف لماذا يحتاج تطبيقك إذنًا يبدو غريبًا. هذا يقلّل الشك ويقلّل المراجعات السلبية التي تتّهمك بالتجسّس.
كيف تختبر مسارات الأذونات؟
الاختبار هنا يُهمَل لأن المطوّر منح كل الأذونات على جهازه منذ شهور، فلا يرى ما يراه المستخدم الجديد أبدًا.
اختبر الحالات الخمس على جهاز نظيف:
منح الإذن فور الطلب. المسار السعيد، وهو الوحيد الذي يُختبر عادةً.
رفض الإذن مرة. هل يظهر المسار البديل؟ هل رسالة الشرح واضحة؟
رفض الإذن نهائيًا. هل يعمل التطبيق؟ هل يوجد زر يفتح الإعدادات؟
منح الإذن ثم سحبه من الإعدادات. حالة يقع فيها التطبيق كثيرًا: كان يعمل ثم انكسر بلا سبب ظاهر في الكود.
ترقية النظام بعد المنح. بعض الترقيات تعيد ضبط أذونات معيّنة أو تحوّلها إلى «مرة واحدة فقط».
والطريقة العملية: أعد ضبط أذونات التطبيق من إعدادات الجهاز قبل كل جولة اختبار. هذا يوفّر عليك اكتشاف العطل من شكوى مستخدم.
الأذونات ترجمة لثقافة الفريق
الطريقة التي تطلب بها الأذونات تكشف كيف ينظر فريقك إلى المستخدم: هل هو مصدر بيانات أم إنسان يقرّر؟
والفرق يظهر في تفاصيل صغيرة: نص يشرح بدل نص يطلب، ومسار بديل بدل شاشة مسدودة، وإذن يُحذف لأنه غير مستعمل بدل إذن يُترك «تحسّبًا».
وهذه التفاصيل يلاحظها المستخدمون وإن لم يسمّوها، وتتراكم في انطباع اسمه الثقة — وهو ما يصعب كسبه ويسهل فقده.
الخلاصة: الإذن ليس شرطًا تقنيًا بل طلب ثقة. ومن يطلبه في اللحظة الأولى بلا شرح يطلب ثقة لم يكسبها بعد، فيُرفض ولا يُتاح له سؤال ثانٍ. أما من يبني تطبيقه ليعمل بلا الإذن، ثم يطلبه في سياق واضح بنص صادق، فيحصل عليه من أغلب من طلبه منهم — ويحتفظ بالباقين مستخدمين لا مغادرين. وهذا الترتيب جزء من كل واجهة نبنيها في شركة تصميم تطبيقات الجوال.