أود حقًا أن أرى خيارًا لإضافة رمز مميز إلى رابط “زيارة الموضوع” عندما يتلقى المستخدمون بريدًا إلكترونيًا من ديسكورت، بحيث يتم تسجيل دخولهم تلقائيًا عند النقر على الرابط.
تستخدم العديد من تطبيقات البريد الإلكتروني القائمة على التطبيقات - مثل Gmail - عرض الويب لتحميل الروابط التي تنقر عليها والتي لا تحتوي على ملفات تعريف ارتباط محفوظة، حتى لو كنت قد سجلت الدخول سابقًا. والنتيجة هي أن المستخدمين يُمنعون من الرد إذا لم يكن لديهم بيانات تسجيل الدخول في متناول اليد، وغالبًا ما يتخلون عن الحافز للرد.
أعتقد أنه يمكن حل هذه المشكلة بسهولة إذا توفر خيار لإضافة رمز مميز يقوم بتسجيل دخول المستخدم تلقائيًا، مما يسمح لهم بالرد فورًا عند النقر على الرابط. كما سيكون من المفيد إضافة خيار لتحديد مدة صلاحية الرمز المميز.
إنها بالتأكيد حل إبداعي لمشكلة كنت سأحلها من خلال التوصية بعدم استخدام عرض الويب الخاص بعميل البريد الإلكتروني، أو الرد عبر البريد الإلكتروني.
لا أستخدم أنظمة تسجيل الدخول التابعة لجهات خارجية، لكنني أعتقد أن هذا المفهوم يتعارض إلى حد ما مع طريقة عملها، أليس كذلك؟ إذا نقرت على روابط لمواقع أخرى تتطلب تسجيل الدخول باستخدام حساب على وسائل التواصل الاجتماعي، فكيف يتم التعامل معها في عرض الويب الخاص بعميل البريد الإلكتروني؟ هل تعمل رموز تسجيل الدخول في هذا السيناريو؟
بينما أفهم ما تقصده، أعتقد أنك قد فقدت بالفعل المستخدم العادي الذي ربما لا يفهم حتى الفرق بين عرض الويب وفتح المتصفح Safari على الهاتف المحمول.
تعتمد العديد من المواقع على فكرة مشابهة لـ ‘الرابط السحري’ عند تسجيل الدخول إلى خدمات مثل Slack. فبدلاً من إدخال اسم المستخدم وكلمة المرور، يمكنك طلب رابط سحري يُرسل عبر البريد الإلكتروني. وعند النقر على هذا الرابط، يتم تسجيل الدخول تلقائيًا. والرابط السحري هو عنوان URL مؤمن برموز.
إذا كان بإمكانك إعادة تعيين كلمة المرور عبر رابط يُرسل إلى بريدك الإلكتروني، فما الفرق إذن؟
ما قصدته هو: هل تعمل الروابط السحرية عندما يكون المستخدم قد سجّل باستخدام حساب على وسائل التواصل الاجتماعي؟ أنا لا أعرف. قد تتعارض ميزتك مع العديد من أنظمة تسجيل الدخول، لذا كنت أتوقع استجابة فريق البحث والتطوير.
آسف لأنني لم أتطرق إلى ذلك… مطور رئيسي في ديسكوردس سيكون أكثر معرفة مني، لكن في الأنظمة المماثلة التي عملت عليها، لا ينبغي أن يكون هناك مشكلة. نظام الدخول الموحد (SSO) الخاص بك، سواء كان اجتماعيًا أو غير ذلك، هو في الأساس مجرد تبادل للرموز بين مزود خدمة الدخول الموحد وديسكوردس. لذا سيكون الأمر مشابهًا فعليًا، إلا أنه في هذه الحالة سيكون نظام الدخول الموحد الخاص بك هو بريدك الإلكتروني. تبسيط الأمر قليلًا، لكن بشكل عام أتخيل أنه سيعمل بشكل جيد.
هل هذا الأمر محدد لنظام iOS حاليًا؟ فالبديل الخاص بنظام أندرويد (Chrome Custom Tabs) يشارك ملفات تعريف الارتباط افتراضيًا، لذا فإن هذه المشكلة لا تظهر في نظام أندرويد.
لست متأكدًا تمامًا ولم أتمكن من اختبار الأمر على جهاز أندرويد بعد. لكنني أعتقد أن المسألة تتجاوز هذه الحالة الاستخدامية المحددة. فحتى لو كنت تستخدم سطح المكتب ولم تتفاعل مع المجتمع منذ فترة، فإن هذا الإجراء يشجع على التفاعل لأنه يسجلك تلقائيًا في الدخول عند محاولة الرد.
بشكل عام، قمت بتعطيل الرد عبر البريد الإلكتروني في معظم نسخ Discourse التي نديرها، لأن نتائج تحليل البريد الإلكتروني قد تكون غير متسقة، بينما واجهة الويب الجوال لـ Disqus رائعة للغاية. لذا، عندما يعمل النظام (أي أنك مسجل الدخول بالفعل)، فإن النقر على “زيارة الموضوع” (وقد أضيف حتى زر “رد الآن” يفتح نافذة الرد) يكون سلسًا تقريبًا مثل الضغط على “رد” في عميل البريد الإلكتروني الخاص بك.
