في الأشهر الأخيرة، كانت هناك عدة طلبات عبر مجموعة متنوعة من مجموعات Discourse لتحسين تحليل البريد الوارد. وعند صياغتها كقصص مستخدم، يمكن تصنيف هذه الطلبات بشكل عام على النحو التالي:
- “أرغب في إمكانية استخدام نفس ميزات HTML عند الرد عبر البريد الإلكتروني كما أفعل عند النشر على الموقع.”
- “أرغب في إمكانية عرض وبحث الرسائل من قائمة البريد الخاصة بنا.”
- “أرغب في أن يكون المحتوى المنشأ عبر البريد الإلكتروني، سواء عبر الرد عبر البريد أو الاستيراد الجماعي، منسقًا بشكل جميل ومُحلَّل بدقة بشكل متسق.”
سأقوم بربط أمثلة حقيقية لهذه الطلبات أدناه، ولكن الأهم الآن هو فهم أن كل واحدة من هذه الطلبات الثلاثة “المختلفة” تطلب في الواقع نفس الشيء الجوهري — تحليلًا أكثر دقة للبريد الوارد.
قبل بضعة أشهر، أرسلت بريدًا إلكترونيًا إلى @sam بشأن تمكين Discourse من استخدام واجهة برمجة تطبيقات تحليل البريد الإلكتروني التجارية التي تقدمها شركتنا. واقترح سام إنشاء منشور استكشافي هنا لشرح الفوائد التي سيوفرها دمج واجهتنا البرمجية مقارنة بحل تحليل البريد الوارد الحالي في Discourse، وكيف يمكن دمج واجهتنا البرمجية كإضافة.
سأتناول كلا الموضوعين بالتفصيل، بدءًا من حالة حل تحليل البريد الحالي في Discourse. وبالنسبة لمن لم يقضِ السنوات القليلة الماضية في التفكير في تحليل البريد، سأدرج أيضًا بعض الخلفية حول المشكلة.
هذا المنشور طويل جدًا، ولكن لا تتردد في التنقل فيه. إليك ما سيتم تغطيته:
- الحالة الحالية لتحليل البريد في Discourse
- فوائد تحليل البريد الأفضل
- شخصيات المستخدمين المعنيين
- واجهة FWD:Everyone لتحليل البريد الإلكتروني
أ. إزالة التواقيع والردود
ب. تطبيع ترميز HTML
ج. دعم اللغات
د. التنسيق باستخدام CSS - التكامل المقترح
- اختبار الواجهة البرمجية
الحالة الحالية لتحليل البريد في Discourse
يحتوي Discourse بالفعل على ميزة الرد عبر البريد الإلكتروني التي تحول ردود البريد الإلكتروني من المستخدمين إلى مشاركات جديدة في المنتدى ضمن موضوع معين. تعمل هذه الميزة على النحو التالي:
- يتلقى المستخدم إشعارًا عبر البريد الإلكتروني يحتوي على مشاركة جديدة في موضوع في المنتدى يتابعه.
- يرد المستخدم على هذا البريد الإلكتروني.
- يتم تحويل هذا الرد عبر البريد الإلكتروني إلى مشاركة جديدة في موضوع المنتدى ذي الصلة.
من الناحية المفاهيمية، هذه ميزة لا تقدر بثمن؛ فهي سير العمل المفضل للكثير من الناس، وهي ضرورية للعديد من المجتمعات القائمة على قوائم البريد التي تفكر في الهجرة إلى Discourse.
المشكلة تكمن في أنه عند تحويل هذه الردود عبر البريد الإلكتروني إلى مشاركات في المنتدى، غالبًا ما يتم عرضها بتنسيق مفقود أو غير صحيح، أو حتى نصوص مفقودة. وهذا أمر بالغ الخطورة، لأسباب سأستكشفها أدناه.
تشمل المشاكل الشائعة:
- نقاط التعداد النقطي لا يتم عرضها بشكل صحيح
- غياب أسطر جديدة بين النصوص
- أسطر جديدة زائدة بين النصوص
- النص الذي كتبه المستخدم محذوف بالكامل
وعندما أقول إن هذه المشاكل شائعة، لا أعني أنها تحدث أحيانًا عند إرسال رسائل البريد الإلكتروني بلغات أجنبية باستخدام عملاء بريد غامضين. بل أعني أنها تحدث بشكل شائع عند إرسال رسائل رد أساسية عبر البريد من Gmail وOutlook باللغة الإنجليزية.
إليك مثالين حقيقيين لمستخدمين يشتكون من هذه المشاكل، وكلاهما من قائمة البريد [Python-Dev]:
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
(يستخدم Prettyfwd واجهة FWD:Everyone لتحليل البريد الإلكتروني.)
على الرغم من أنني لم أجرب استيراد محتوى من قوائم بريدية موجودة باستخدام Discourse، إلا أنني أستطيع القول من خبرتي أنه مهما كان معدل الخطأ في الرد عبر البريد الإلكتروني، فإن معدل الخطأ عند عرض خيوط البريد الإلكتروني بالكامل سيكون على الأقل أكبر بعشر مرات. ويرجع ذلك إلى التعقيد المتزايد عند إزالة التواقيع والردود، ومراعاة الردود المضمنة، والتعامل مع ترميز متداخل بعمق، وما إلى ذلك.
كمثال حقيقي، تشير هذه المراجعة بعد الهجرة من Mailman إلى Discourse التي كتبتها تانيا لاتنر (رئيسة مؤسسة LLVM) إلى هذه المشاكل في قسم المخاوف التقنية:
سألت، وتبين أن الشيء المحدد الذي يزعجهم هو النسبة العالية من رسائل البريد الإلكتروني التي تفتقر إلى المحتوى بسبب القص المبكر. وبما أن المناقشات السابقة والوثائق من السنوات الـ 19 الماضية لأرشيف قائمة البريد لا تقدر بثمن، فإنهم يشعرون بأنهم لن يتمكنوا من إيقاف خدمة Mailman حتى يتم حل هذه المشكلة بالكامل.
إذن، كيف نعرف ما إذا كانت الحالة الحالية لتحليل البريد في Discourse “جيدة بما يكفي”؟ أقترح هذا كاختبار ثلاثي الأجزاء:
- يجب أن يثق المستخدمون تمامًا في أنه إذا استخدموا ميزة الرد عبر البريد الإلكتروني، فسيتم تحليل محتواهم بدقة وسيبدو تمامًا كما لو كانوا قد نشروه عبر واجهة الويب.
- يجب أن يثق مسؤولو المنتدى في أنه إذا سمحوا بالرد عبر البريد الإلكتروني، فلن ينشئوا عملًا إضافيًا وشكاوى.
- يجب أن يثق موظفو Discourse في الميزة لدرجة الترويج لها بنشاط كطريقة من الدرجة الأولى للمشاركة.
ما لم نستطع القول بثقة تامة بأن كل من هذه الشروط يتم استيفاؤه، حتى لو كانت ميزة الرد عبر البريد الإلكتروني موجودة، فلن تتحقق الغالبية العظمى من الفوائد المحتملة أبدًا.
هذا ما يحدث حاليًا.
أي، سأصف كود تحليل البريد الحالي كحل 80-20، ولكن في سياق لا يكون فيه حل 80-20 منطقيًا حقًا؛ والمشكلة هي أنه حتى لو كان، على سبيل المثال، 80% من رسائل البريد الإلكتروني تُحلَّل بشكل صحيح، فمن غير المرجح أن تحصل حتى على 10% من الفوائد المحتملة.
لذلك، على الرغم من أن الرد عبر البريد الإلكتروني (والاستيراد الجماعي للبريد) موجود بالفعل، إلا أن المستخدمين في النهاية لا يحصلون على التجربة التي يبحثون عنها، ويتم إنشاء عمل إضافي للمحررين والموظفين، وتفقد المجتمعات محتوى قيمًا ونموًا للمستخدمين، وما إلى ذلك.
فوائد تحليل البريد الأفضل
البرمجيات الاجتماعية تنجح فقط بالقدر الذي تحقق فيه الاحتياجات البشرية.
تشمل الأسباب التي تدفع الناس للنشر في منتديات الويب الرغبة في مشاركة المعرفة مع الآخرين، والرغبة في التأثير على آرائهم، والرغبة في أن يُنظر إليهم على أنهم أذكياء بشكل عام، ولديهم خبرة في المجال، ويقدمون مساهمات قيمة في العالم الحقيقي، وما إلى ذلك.
وعندما يتعلق الأمر بالاتصال القائم على النص، فإن احتمالية تحقيق هذه النتائج لا تعتمد فقط على ما يُقال، بل أيضًا على الطباعة التي يُقال بها.
ولهذا السبب توجد كتب كاملة حول المسافات البيضاء في شكسبير. وهو جزء من سبب أخذ نيويورك تايمز على محمل الجد أكثر من نيويورك بوست. وهو جزء كبير من سبب فوز فيسبوك على ماي سبيس.[1]
عندما ينتهي الأمر بالنص الذي كتبه المستخدم بشكل سيئ التنسيق دون أي خطأ منه، فإن الاحتياجات البشرية التي تدفع الناس لاستخدام البرمجيات الاجتماعية لم تعد تُلبَّى. في الواقع، يحدث العكس؛ يُجعل المستخدمون يبدون غباءً.
حتى أولئك الذين لا يستخدمون ميزة الرد عبر البريد الإلكتروني يفقدون السلطة والاحترام إذا انتهت مشاركات أخرى في الموضوع (وفي المنتدى الأكبر) إلى أن تبدو مثل حريق في سلة المهملات.
شخصيات المستخدمين المعنيين
بينما يستفيد الجميع عندما يتم عرض المشاركات بشكل متسق مع طباعة جمالية، فإن شخصيات المستخدمين الذين قد يستفيدون بشكل خاص من تحليل البريد الوارد الأفضل يشملون:
- الأشخاص الذين هم حاليًا أعضاء في قوائم بريدية مثل [Python-Dev] و[Django-Dev]، الذين يفهمون تمامًا فوائد Discourse ويسعدون برؤية مجتمعاتهم تنتقل إلى Discourse، ولكن فقط إذا كانوا قادرين على الاستمرار في المشاركة بطريقة لا يمكن تمييزها عن GNU Mailman أو Google Groups، وما إلى ذلك. إليك مثال حقيقي على هذا النوع من الطلبات: https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- أعضاء المجتمعات القائمة على البريد الإلكتروني الذين سيكونون عمومًا سعداء بالهجرة إلى Discourse، ولكنهم سيكونون أكثر حماسًا للقيام بذلك إذا كان محتواهم الموجود منذ عقود قابلاً للبحث بسهولة من داخل نفس المنصة.
- المستخدمون العاديون الذين يتحققون من المنتديات بشكل متقطع. على سبيل المثال، في Growing Fruit، أنا مشترك عبر البريد الإلكتروني في جميع المواضيع المتعلقة بزراعة البباباوات في أمريكا الشمالية. خلال الصيف والخريف أزور ذلك المنتدى عدة مرات في اليوم لقراءة التدفق المستمر للمشاركات الجديدة في هذه المواضيع، ولكن خارج هذه الأشهر، فإن إشعارات البريد الإلكتروني في هذه المواضيع هي ما يبقيني متفاعلًا.
- الأشخاص الذين يستخدمون الويب فقط بشكل متقطع. غالبًا ما يُفترض أنه إذا لم يستخدم الناس الويب بانتظام، فإن ذلك مرتبط بطريقة ما بالفجوة الرقمية، ولكن في كثير من الأحيان هذا ليس هو الحال. هناك الكثير من الأشخاص الأذكياء والتقنيين للغاية، ولكنهم معزولون عن الحاجة لاستخدام الويب بشكل منتظم بسبب كونهم في قمة مجالاتهم. مثال حقيقي هنا هو شخص مثل دونالد كنوث، الذي لا يستخدم الويب بانتظام على الرغم من كونه أحد أبرز علماء الكمبيوتر الأحياء. كل مجال لديه أشخاص مثله، وجعلهم يشاركون معرفتهم لا يقدر بثمن. من خبرتي، هؤلاء الأشخاص غير مرجح أن يصبحوا مساهمين منتظمين في أي منتدى، ولكن إذا أخبرهم شخص ما بأن هناك موضوعًا يناقشه الناس يثير اهتمامهم، فسوف يشتركون غالبًا عبر البريد الإلكتروني ويساهمون في تلك المواضيع المحددة.
الصورة الكبيرة هي أن تحسين تحليل البريد الوارد يجب أن لا يزيد فقط من تفاعل الأشخاص الذين هم بالفعل مساهمون نشطون منتظمون في Discourse، بل يجب أيضًا فتح المجال للعديد من المجتمعات التي تود الهجرة إلى المنصة، وجلب محتوى قيم للغاية من الأشخاص الذين لن يساهمون لولا ذلك.
واجهة FWD:Everyone لتحليل البريد الإلكتروني
تقوم واجهة FWD:Everyone لتحليل البريد الإلكتروني بشيءين:
- إزالة التواقيع والردود بدقة من كل رسالة بريد إلكتروني، مع السماح بالردود المضمنة على النصوص المقتبسة.
- أخذ ترميز HTML المعقد للغاية الذي تولده عملاء البريد الإلكتروني، وتطبيع هذا الترميز إلى حوالي 12 وسم HTML يُسمح بها عادةً في مواقع المحتوى الذي ينشئه المستخدم — مع الحفاظ على نية المؤلف إلى أقصى حد ممكن.
سأشرح كلا الأمرين بتفصيل أكبر، ولكن أولاً إليك فيديو قمت بإعداده يشرح المشكلة من خلال عرض خيوط البريد الإلكتروني الحقيقية: https://www.youtube.com/watch?v=nPb3NQlz6V4
إزالة التواقيع والردود
تعمل واجهة FWD:Everyone لتحليل البريد الإلكتروني على رسائل البريد الإلكتروني النصية ورسائل HTML بدقة متساوية. تستخدم الواجهة بشكل تفضيلي جزء الرسالة HTML عند توفره، لأن:
- ميزات تنسيق HTML (مثل التظليل، المائل، الاقتباسات، مقتطفات الكود، وما إلى ذلك) التي يختارها المؤلف للاستخدام هي جزء أساسي من رسالة المؤلف، بنفس أهمية النص نفسه.
- عندما تقوم عملاء البريد الإلكتروني بتحويل نسخة الرسالة HTML إلى النسخة النصية، فإنهم غالبًا ما يفعلون ذلك بشكل غير صحيح. على سبيل المثال، لن يحاول عملاء البريد الإلكتروني غالبًا عرض ميزات HTML مثل القوائم النقطية في النص العادي، بل غالبًا ما يكون النص داخل عناصر تنسيق HTML مفقودًا بالكامل.
بالطبع، يفضل بعض المستخدمين إرسال رسائل بريد نصية فقط؛ لذلك، يجب إزالة التواقيع والردود من رسائل البريد النصية فقط بدقة متساوية.
تقوم واجهة FWD:Everyone لتحليل البريد الإلكتروني بذلك، بما في ذلك التعامل بشكل صحيح مع الردود المضمنة في رسائل البريد النصية ورسائل HTML.
من حيث الدقة، هناك نوعان من الأخطاء التي يمكن أن تحدث في أي مكتبة لتحليل البريد عند إزالة التواقيع والردود:
- إيجابيات كاذبة — عندما يتم استبعاد نص من المفترض تضمينه في الرسالة بشكل غير صحيح.
- سلبيات كاذبة — عندما يتم تضمين نص لا ينبغي تضمينه في الرسالة بشكل غير صحيح.
من الصعب إعطاء إحصائيات دقيقة حول الدقة لأن مجتمعات Discourse (بالحرف الصغير) تستخدم البريد الإلكتروني بطرق مختلفة جدًا. ولكن مقارنة بحل تحليل Discourse الحالي، قد يكون التوقع الواقعي:
- 100 مرة أقل من الإيجابيات الكاذبة عند إزالة التواقيع والردود
- 10 مرات أقل من السلبيات الكاذبة عند إزالة الردود
- 1-10 مرات أقل من السلبيات الكاذبة عند إزالة التواقيع — ربما أفضل، ولكن ليس بعشر مرات أفضل بالكامل.
للتوضيح، الإيجابيات الكاذبة أسوأ بشكل عام من السلبيات الكاذبة لأنها تمثل بشكل خاطئ ما كتبه الشخص. ولكن السلبيات الكاذبة سيئة أيضًا لأنها تجعل الناشر (وكل شخص آخر في المنتدى) يبدو غير محترف في أحسن الأحوال، وغبياً تمامًا في أسوأ الأحوال.
النهج الذي تتخذه FWD:Everyone هو تجنب أي حيل لإزالة التواقيع قد تؤدي إلى إيجابيات كاذبة؛ ثم يتم موازنة الزيادة الظاهرة في السلبيات الكاذبة التي قد تؤدي إليها ببذل الكثير من العمل لجعل الخوارزمية تعمل بطريقة شرعية، دون الحاجة إلى اختصار الطريق.
السبب الرئيسي للصورة الكبيرة هو أن واجهة FWD:Everyone لتحليل البريد الإلكتروني ستكون عمومًا أكثر دقة بكثير من حل Discourse الحالي هو أن واجهتنا البرمجية صُممت لتحليل خيوط البريد الإلكتروني بالكامل، وهي مشكلة أصعب بكثير من تحليل مشاركات الرد عبر البريد الإلكتروني الفردية. والنتيجة النهائية هي أن منتجنا مصمم بشكل مفرط، على الأقل مقارنة باحتياجات Discourse وبالأعمال السابقة الموجودة.
تطبيع ترميز HTML
لكي تبدو الردود المقدمة عبر البريد الإلكتروني (وخيوط البريد المستوردة) مثل أي محتوى آخر ينشئه المستخدم، يجب عرضها في النهاية باستخدام نفس مجموعة فرعية من HTML المسموح بها عندما يرد المستخدمون عبر الموقع.
هذا معقد بشكل مدهش.
يتم ترميز الرسائل المكونة في عملاء البريد الإلكتروني مثل Gmail وOutlook باستخدام مزيج من حوالي 50 وسم HTML، وحوالي 25 سمة HTML، وحوالي 175 نمط CSS. علاوة على ذلك، غالبًا ما يكون هذا الترميز معقدًا بشكل كبير؛ قد تتوقع أن يبدو فقرة من النص كالتالي:
<p>Some text!</p>
ولكن بدلاً من ذلك، غالبًا ما يتم ترميز الفقرات البسيطة باستخدام مجموعات عميقة التداخل وغير منطقية تمامًا من divs وspans والجداول والقوائم، وما إلى ذلك. هذا هو المصدر الرئيسي للتعقيد في كل من إزالة الردود وتطبيع الترميز.
على أي حال، بعد التحليل، يتم عرض كل رسالة باستخدام الترميز التالي فقط:
عناصر الكتلة المسموح بها: <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
العناصر المضمنة المسموح بها: <code>, <a>, <b>, <i>, <u>, <s>, <span>
ملاحظات:
- السمات الوحيدة المسموح بها (ما عدا في وسوم
<a>) هي'style'و'dir'. - النمط المضمن الوحيد المسموح به هو
'font-weight'. - يمكن أن تحتوي وسوم
<a>أيضًا على سمات'href','rel','title', و'target'. - تُستخدم عناصر
<span>فقط في حالات محدودة لضمان تسلسل أوزان الخطوط بشكل صحيح. وبالتالي، تُستخدم دائمًا مع'font-weight'مضمن. - في المستقبل، سيتم استخدام وسم
<img>أيضًا لعرض الصور المضمنة.
يسمح عرض المشاركات في هذه المجموعة الفرعية المحدودة من HTML بأي منشور مقدم عبر البريد الإلكتروني ليتم عرضه بسهولة باستخدام نفس الطباعة تمامًا مثل المنشورات المقدمة عبر واجهة الويب.
يتم كل ذلك مع الحفاظ على نية المؤلف إلى أقصى حد ممكن، مع ضمان عدم قدرتهم على فعل أشياء مثل إضافة عشرات الأسطر الجديدة غير الضرورية بين الفقرات.
انظر أيضًا: قسم «تنسيق CSS» أدناه.
دعم اللغات
يحتوي EmailReplyTrimmer حاليًا على دعم كامل أو جزئي لـ 13 لغة:
الإنجليزية، النرويجية، الفرنسية، الألمانية، البرتغالية، الإسبانية، الإيطالية، الهولندية، السويدية، الصينية، الروسية، البولندية، الأوكرانية
في المقابل، تدعم واجهة FWD:Everyone لتحليل البريد الإلكتروني حاليًا أكثر من 30 لغة، بما في ذلك كل لغة يدعمها Discourse حاليًا:
الإنجليزية، الإسبانية، البرتغالية، الكتالونية، الهولندية، الفرنسية، الألمانية، الإيطالية، النرويجية، الدنماركية، السويدية، الفنلندية، الروسية، البولندية، الأوكرانية، التركية، التشيكية، الرومانية، المجرية، العبرية، العربية، الفارسية، الصينية، اليابانية، الكورية، الهندية، الإندونيسية، التايلاندية، الفلبينية، الأفريقانية
تدعم واجهة FWD:Everyone لتحليل البريد الإلكتروني اللغات التي تُكتب من اليمين إلى اليسار (RTL) بشكل كامل. وهذا يعني أنه لن يتم تدفق النص بشكل صحيح من اليمين إلى اليسار في لغات مثل العربية فحسب، بل سيتم أيضًا تطبيق السمات المناسبة على ترميز HTML بحيث تظهر ميزات مثل النقاط النقطية على الجانب الصحيح من الصفحة.
في بعض الأحيان، قد تعمل الواجهة أيضًا في لغات إضافية اعتمادًا على عميل البريد الإلكتروني المستخدم، ولكن مجموعة اللغات المدعومة رسميًا تم اختبارها على الأقل للعمل مع Gmail وOutlook وApple Mail. يتم اختبار عملاء البريد الإلكتروني الأقل شعبية بشكل صريح في اللغات التي يكون فيها استخدامها الأكثر شيوعًا. وبما أن الواجهة تم اختبارها ضد آلاف خيوط البريد من قوائم البريد العامة، فهناك عدد لا يحصى من الإصلاحات للسلوك غير المنتظم في العالم الحقيقي ذي الأصل المجهول.
ملاحظة: إن دعم مجموعة واسعة من اللغات مهم لأكثر من مجرد عرض النص بتلك اللغات. من الشائع جدًا أن يكتب الناس نصًا باللغة الإنجليزية، ولكن يكون عميل البريد الإلكتروني الخاص بهم مهيأً لاستخدام، على سبيل المثال، العبرية. لذا في حالات مثل هذه، يتطلب تحليل رد باللغة الإنجليزية بشكل صحيح ليس فقط دعم العبرية بشكل كامل، بل دعم اللغات التي تُكتب من اليمين إلى اليسار بشكل عام.
يساعد دعم اللغات من مجموعة واسعة من العائلات اللغوية أيضًا في ضمان معالجة وتخزين unicode بشكل صحيح، بدلاً من طرق قد تسبب مشاكل في المستقبل مع إضافة دعم المزيد من اللغات غير الغربية.
تنسيق CSS
كما ذُكر أعلاه، تكمن قوة واجهتنا البرمجية في قدرتها على تطبيع ترميز HTML بطريقة مدروسة ومنطقية. صُمم هذا التطبيع لتحسين النص من حيث القراءة وإمكانية الوصول، مع الحفاظ على نية المؤلف الأصلية إلى أقصى حد ممكن.
وبالتالي، يظهر كل نص فقط داخل عناصر مضمنة أو كتلة (لا يوجد نص عائم حر)، وتظهر جميع العناصر المضمنة فقط داخل عناصر كتلة. هذا يسهل تنسيق النص، على سبيل المثال لضمان أن يكون للعناصر المختلفة القدر الصحيح من المسافات البيضاء بينها.
كمثال على مدى قيمة هذا، تسمح عملاء البريد الإلكتروني للمستخدمين بفعل أشياء سخيفة مثل إدراج قائمة نقطية مباشرة قبل أو بعد سطر من النص، دون أي فاصل سطر بينهما. قد يبدو الكود (المبسط للغاية) الذي يولده عميل البريد الإلكتروني عند القيام بذلك كالتالي:
<div>
Some text
<div> </div>
<span> • A bullet point</span>
<div> </div>
Some more text
</div>
ستقوم واجهة FWD:Everyone لتحليل البريد الإلكتروني بعد ذلك بتطبيع الترميز أعلاه ليبدو كالتالي:
<p>Some text</p>
<ul>
<li>A bullet point</li>
</ul>
<p>Some more text</p>
هذا الترميز المطبعي سهل الفهم والتنسيق، وبصريًا توجد الآن أيضًا أسطر جديدة قبل وبعد القائمة النقطية. تجعل هذه التسهيلات النص أجمل وأسهل في القراءة، مع الحفاظ على نية المؤلف. تضمن هذه الأنواع من التسهيلات للمستخدم أن المحتوى الرائع المقدم عبر البريد الإلكتروني يمنح باستمرار المكانة الاجتماعية، بدلاً من تقويضها.
يضمن أيضًا الترميز المبسط والمطبعي الذي تولده واجهتنا البرمجية أنه عند التفكير في كيفية تنسيق النص، يحتاج المصممون والمطورون فقط إلى التفكير في المخرج الذي تسمح به الواجهة، بدلاً من كيفية تنسيق البريد الإلكتروني الأصلي. وبما أن المخرج المسموح به من الواجهة مطابق عمليًا لما يسمح به عميل الويب في Discourse، فإن هذا يجب أن يكون قريبًا من حل جاهز للاستخدام.
التكامل المقترح
سيتم دمج وظيفة الرد عبر البريد الإلكتروني مع Discourse كإضافة، والتي يمكن بعد ذلك تمكينها افتراضيًا لجميع مثيلات Discourse المستضافة.
سيتم استخدام كود تحليل البريد الحالي لمثيلات Discourse التي لا تحتوي على هذه الإضافة مفعلة.
بالإضافة إلى ذلك، في حال أصبحت واجهة FWD:Everyone لتحليل البريد الإلكتروني غير متاحة مؤقتًا، فسيتم معالجة أي رسائل واردة باستخدام كود تحليل البريد الحالي. ثم بمجرد عودة الواجهة إلى العمل، يمكن إعادة معالجة أي رسائل لم يتم تحريرها عبر واجهة الويب منذ النشر بواسطة الواجهة.
يمكن أيضًا توفير الإضافة لمثيلات Discourse المستضافة ذاتيًا لتمكينها اختياريًا.
بالنسبة للمجموعات التي تهاجر من قوائم بريدية موجودة إلى Discourse، يمكن أيضًا تحليل كل خيط بريد إلكتروني في قائمة البريد عبر الواجهة، ولكن من المرجح أن يتم دمج ذلك في سكريبتات وعمليات الهجرة الحالية في Discourse بدلاً من القيام بذلك عبر إضافة.[2]
اختبار الواجهة البرمجية
الواجهة البرمجية متاحة بالكامل لأي شخص للاختبار، وإن كان ذلك مع حد معدل منخفض جدًا للمستخدمين غير الموثقين.
بالنسبة لأولئك الذين لديهم حسابات Gmail، أسهل طرق اختبار الواجهة هي:
- الذهاب إلى https://www.prettyfwd.com، وتثبيت إضافة G Suite.
- الذهاب إلى https://api-demo.fwdeveryone.com، واستخدام OAuth من جانب العميل للعب بالواجهة البرمجية
الاختلافات الرئيسية بين هاتين الأداتين القائمتين على الويب والواجهة البرمجية الفعلية هي أن الأولى:
- لن تعالج الخيوط التي تحتوي على رسائل منسقة باستخدام جداول HTML
- لن تقوم بإزالة الردود في الرسالة الأولى في خيط. (على سبيل المثال، إذا كان الخيط يحتوي على أكثر من 100 رسالة، يقوم Gmail بتقسيمه إلى خيوط متعددة.)
للاختبار المباشر للواجهة عبر الكود، هناك سكريبتات بداية لكل من Python وRuby:
وهنا الوثائق ذات الصلة، بما في ذلك المشاكل المعروفة وخريطة طريق المنتج:
[1] Viewing American class divisions through Facebook and MySpace.
[2] عند استيراد محتوى بشكل جماعي من قائمة بريدية موجودة، يستحق الأمر إجراء فحص سريع للعقل على بعض الخيوط للتأكد من أنها تُحلَّل بشكل صحيح. ستمتلك بعض المجموعات دقة شبه مثالية كما هي، ولكن قد تستفيد مجموعات أخرى بشكل كبير من بضع ساعات من العمل الوقائي. على سبيل المثال، تتطلب بعض برمجيات قوائم البريد القليل من الكود المخصص لكل قائمة لإزالة أي نص مضاف إلى أسفل كل رسالة، بينما يمكن القيام بذلك بطريقة يمكن التنبؤ بها تعمل لأي قائمة مستضافة على تلك المنصة. بسبب مشاكل محتملة مثل هذه، يجب تشغيل عملية الاستيراد الجماعي بشكل تفضيلي كجزء من هجرة تحت الإشراف بدلاً من القيام بذلك عبر إضافة.