في منتصف 2018 ، فكرت Sports.ru في الانتقال إلى محرر نصوص WYSIWYG جديد لمشاركات المستخدم. منذ يونيو 2019 ، أصبح المحرر في الوضع التجريبي. خلال هذا الوقت ، قمنا بحل العديد من المشاكل المرتبطة بكل من تصميم بنية الخدمة بأكملها وتنفيذ المحرر نفسه في المتصفح بناءً على مكتبة ProseMirror ، وقررنا مشاركة تجربتنا.
جدول المحتويات
1. مقدمة1.1. لماذا تحتاج WYSIWYG1.2. وصف المهمة التي واجهها المطورون2. كيفية اختيار الأداة3. ما حدث3.1. بنية الخدمة3.2. ما هي التحديات4. نتائج اختبار بيتا1 المقدمة
1.1. لماذا تحتاج إلى WYSIWYG
Sports.ru هي وسائل الإعلام حول الرياضة مع جمهور 20 مليون مستخدم شهريا. اختلافاتنا الرئيسية من وسائل الإعلام الكلاسيكية هي المجتمع و UGC . محتوى المستخدم - التصنيفات والتعليقات والدردشات والمنشورات - لا يكمل القيمة التحريرية فحسب ، بل يخلق أيضًا منصة للمستخدمين للتفاعل مع بعضهم البعض. كل شهر ، يكتب مستخدمونا ما يقرب من 10 آلاف مشاركة. يتم إرسال أفضلها إلى الصفحة الرئيسية للموقع مع الصفحات التحريرية ، المرسلة إلى تطبيقات الهاتف المحمول ، والشبكات الاجتماعية. يمثل محتوى المستخدم حوالي 40 ٪ من جميع القراءات على صفحات Sports.ru.نريد أن نكون المنصة الأكثر ملاءمة لمؤلفي الرياضة للمساعدة في إنشاء المحتوى وتقديمه للجمهور المهتم. 10 سنوات استخدمنا محرر TinyMCE- وفي النهاية أصبحت قديمة ، ولم تعد تناسب الفريق والمستخدمين الذين اعتادوا على المحررين الحديثين.
تين. 1. واجهة المحرر القديم المبنية على TinyMCEمن مؤلفي المدونات يتم تلقيها بانتظام حول الشكاوى التالية:- كتبت لفترة طويلة ، ثم أغلقت علامة التبويب عن طريق الخطأ ، واختفى كل شيء ؛
- كتابة نصوص طويلة أمر غير مريح ؛
- من المزعج أنه لإدراج كل صورة ، يجب عليك أولاً تحميلها على استضافة الصورة.
كان لدى الفريق أيضًا شكاوى خاصة به:- في TinyMCE لا يمكنك تحميل الصور مباشرة من ملف ، يمكنك فقط إرفاق روابط إلى الصور ، وبسبب حقيقة أن المستخدمين لم يتمكنوا من تحميل الصور إلى تخزيننا ، إذا ماتت الروابط الخاصة بهم ، فلن نتمكن من القيام بأي شيء حيال ذلك ؛
- احتمالات تحرير النص وتنسيقه غير متوازنة. من ناحية ، لم تكن هناك أنماط كافية ، على سبيل المثال ، للرؤوس الداخلية في النص. من ناحية أخرى ، كان من الممكن استخدام الأدوات المتاحة في أي مجموعة. ونتيجة لذلك ، بدت المشاركات غير موحدة (في Sports.ru ، بدأ العمل على تنفيذ نظام التصميم ويجب أن تبدو مشاركات المستخدم وفقًا لها) ؛
- يتم إنشاء المحتوى وتخزينه بتنسيق HTML ، لذلك من الصعب إدارة الأنماط في التدوينات على عملاء مختلفين ، وإجراء تغييرات على تخطيط المنشورات فقط.
فيما يلي قصة حول كيفية حل مشكلة إنشاء محرر جديد في الواجهة الأمامية. صحيح ، سيكون هناك أيضًا شيء ما حول المنتج والتصميم والأجزاء الخلفية ، لأنه بدون ذلك سيكون من الصعب فهم سبب اتخاذ قرار معين في الواجهة الأمامية.1.2. وصف المهمة التي تواجه المطورين
باختصار ، الأطروحة التي اعتمدنا عليها في البداية: التدوين على Sports.ru هو ألم. من حيث المبدأ ، سيكون من الممكن عدم إنشاء محرر جديد ، ولكن ببساطة إضافة الحفظ التلقائي والقدرة على تحميل الصور إلى وحدة التخزين الخاصة بك - وستختفي معظم الشكاوى من المستخدمين والموظفين. لكنني ما زلت أرغب في عدم دعم الأداة على التقنيات القديمة ، ولكن لإنشاء محرر حديث جديد يمكننا تطويره وتوسيع نطاقه بسهولة.بالإضافة إلى الواجهة غير المريحة ، كانت إحدى المشكلات الفنية الرئيسية للمحرر القديم هي أن محتوى المنشور تم حفظه على الفور كسلسلة HTML ، والتغييرات في مظهر المنشور تتطلب تدخل مطوري الخلفية ، أو تم تنفيذها في وقت التشغيل على العميل (على سبيل المثال ، وضع الوحدات الإعلانية في نص الرسالة). كانت مهمتنا ، من بين أمور أخرى ، هي فصل البيانات عن العرض التقديمي ، وبالتالي ، ترك التصميم والواجهة في رمز العميل ، والعمل مع البيانات في رمز الخادم.كنموذج يحتذى به ، أخذنا Medium ، وأحيانًا نتجسس على أفكار من Google Doc . بالإضافة إلى حل المشكلات التي تم تحديدها بالفعل ، قررنا إضافة العديد من الميزات الجديدة التي ستجعل استخدام المحرر أكثر راحة:- WYSIWYG, .. what you see is what you get (. « , », ), , . , ;
- ( , , , , ; , ) .
في الوقت نفسه ، لا ينبغي أن يكون المحرر نفسه مرتبطًا بميزات Sports.ru ، لأن Sports.ru ، على الرغم من أن المشروع الرئيسي في شركتنا ، لا يزال ليس الوحيد. وتقوم الشركة أيضًا بتطوير وسائل الإعلام الرياضية الدولية Tribuna ، وهي شبكة اجتماعية لمحبي المراهنات Betting Insider ، وقد أطلقت مؤخرًا استوديو إنتاج خاص بها يعمل في مشاريع إعلانية. يعد تطوير محرر عبر الإنترنت مكلفًا بما يكفي لعدم رغبتك في إعادة استخدام هذا الرمز على موقع آخر بتنسيقات وأنماط مختلفة ، مع مجموعة أدوات خاصة به للتحرير والتنسيق.لدينا الكثير من المحتوى النصي ، وقبل البدء في العمل على إنشاء محرر رسائل جديد ، فكرنا في كيفية تخزين هذا المحتوى. لم يمنحنا TinyMCE خيارًا ويجب تخزين المحتوى فقط بتنسيق HTML ، والذي ، كما ذكر أعلاه ، لا يناسب الفريق. ونتيجة لذلك ، توصلنا إلى تنسيقنا الخاص لتخزين البيانات النصية التي تلبي متطلباتنا ، وأطلقنا عليها اسم الهيكل المنظم.الجسم المنظم عبارة عن مجموعة من الكائنات التي تعكس بنية المحتوى. في هذه الحالة ، يتم تقسيم المحتوى إلى عناصر تكون كتل مستقلة ، على سبيل المثال ، فقرة ، قائمة ، صورة. يخزن العنصر معلومات حول نوعه وخصائصه. على سبيل المثال ، يصف قالب الترجمة العنوان في النص ، ويجب أن يحتوي على النص وحقول المستوى. وبالتالي ، يحتوي النص على نص هذا العنوان ، ويحتوي المستوى على المستوى (من 1 إلى 4). قد يبدو الهيكل المنظم ، الذي يتكون من رأس واحد من المستوى الثاني ، على سبيل المثال ، كما يلي:const structuredBody = [
{
type: 'subtitle',
value: {
text: ' ',
level: 2,
},
},
];
أتاح لنا الانتقال إلى الهيئة المنظمة أن نبدأ عملية فصل منطق الأعمال والبيانات وعرضها. في النهاية ، نريد أن يقوم الخادم والعملاء بتبادل البيانات فقط. وكيف ولماذا لعرض هذه البيانات للمستخدم النهائي ، سيحدد كل عميل بشكل مستقل.يتم تخزين المحتوى بتنسيق formatd body في JSON ، وللتحقق من محتوياته ، أنشأنا مخطط JSON يسمى مخطط الجسم المهيكل. يصف هذا الرسم البياني جميع العناصر الصالحة وخصائصها. وبالتالي ، يمكننا التأكد من أنه عندما تكون هناك حاجة إلى هيكل منظم ، يتم استخدام مجموعة واحدة من المفاتيح والقيم.علاوة على ذلك ، يسمح للفرق المختلفة باستخدام نفس الخدمات لمعالجة المحتوى بهذا التنسيق. على سبيل المثال ، خدمة لتوليد HTML من نص منظم لعرض المحتوى أو محرر لإنشاء المحتوى. هذا يقلل بشكل كبير من تكلفة تطوير ودعم كامل الخدمات المتعلقة بإنشاء وعرض المحتوى.كان من المفترض أن المحرر الجديد يجب أن يقبل محتوى المدخلات والمخرجات بشكل حصري بتنسيق الهيكل المنظم. وهنا كان من الضروري مراعاة النقطة الدقيقة: منذ أن تم حفظ المشاركات على الفور في HTML ، تم نقل سلسلة HTML من قاعدة البيانات إلى العميل لعرضها (فيما يلي ، من قبل العميل نعني المستعرض حصريًا ، ما لم يتم تحديد خلاف ذلك). نريد الآن تخزين محتوى جميع المشاركات في النص المهيكل ، ولكن يمكن للعملاء معالجة HTML فقط. لذا ، جنبًا إلى جنب مع مهمة الانتقال إلى محرر جديد ، فإن مهمة تنفيذ طريقة جديدة للعملاء لعرض المنشورات للقراءة مباشرة من النص المهيكل مستمرة في نفس الوقت. قررنا أنه من الأفضل تناول جزء من الفيل ، لذا عليك أولاً التخلي عن TinyMCE تمامًا ، وعندها فقط تأخذ منطق عرض المشاركات للقراءة. علاوة على ذلك،لم تتمكن جميع المنشورات القديمة من ترجمة المحتوى إلى تنسيق جديد ، مما يعني أنه سيتم تخزين هذه المنشورات دائمًا بتنسيق HTML فقط ومن الضروري أن تحتفظ أيضًا بالقدرة على القراءة.الإجمالي: سيتم تخزين جزء من المنشورات (كل الجديدة والقديمة التي تم نقلها بنجاح إلى التنسيق الجديد) بتنسيقين - HTML والهيكل المنظم - حتى يتم تنفيذ منطق العرض الجديد للقراءة ، والباقي (معظم القديم والقديم جدًا) المشاركات) ستظل بتنسيق HTML فقط.2. كيفية اختيار أداة
كان علينا أن ندرك القدرة على تحرير وإنشاء مشاركة على العميل ، مع مراعاة الميزات والقيود المذكورة أعلاه. كما هو الحال دائمًا ، يمكنك اتخاذ حل جاهز ، أو يمكنك التوصل إلى حل خاص بك.بادئ ذي بدء ، قمنا بفحص المكتبات الجاهزة لإنشاء محررات WYSIWYG وما إذا كانت مناسبة لنا. استقرنا على Slate و Draft.js و ProseMirror .بالإضافة إلى تخزين المحتوى في بنية بيانات ، كانت اللحظة الحاسمة بالنسبة لنا أيضًا هي القدرة على العمل مع Vue أو JS خالص ، لأننا بدأنا بالفعل في نقل الموقع إلى مكدس تكنولوجي جديد باستخدام Vue + Vuex. بالإضافة إلى ذلك ، أود توسيع إمكانيات المكتبة النهائية بمساعدة وحدات جديدة (طرف ثالث أو مكتوب ذاتيًا) إذا لزم الأمر.التبويب. 1. مقارنة المكتبات التي تمت مراجعتها بأهم المعلمات لـ Sports.ru
كما ترى من الجدول ، امتثلت ProseMirror تمامًا لمتطلباتنا ، وبالتالي لم نعد نفكر في فكرة كتابة مكتبتنا الخاصة لتحرير محتوى النص ، ولكننا بدأنا في دراسة هذه المكتبة بمزيد من التفصيل. لا يزال هناك Quill شائعًا إلى حد ما ، والذي لم يدخل في مقارنتنا لمجرد أننا نسينا بصدق ذلك في مرحلة اختيار الأداة. وفقًا لمتطلباتنا الرئيسية ، يمر أيضًا ، لكنه حدث ذلك. لقد تحدثنا بالفعل عن ماهية ProseMirror وكيفية العمل معه في مقال آخر .3. ما حدث
3.1. هندسة الخدمة
محرر المحتوى نفسه على العميل أبعد ما يكون عن الكل. تحتاج إلى وضع المحرر في مشروع موجود ، وعرضه في مكان ما على صفحة الويب ، والنظر أيضًا في التفاعل مع الواجهة الخلفية ، وحل مشكلة دعم محررين في نفس الوقت (لا يمكنك ترك الإصدار القديم على الفور) وتخزين المحتوى بتنسيقين (HTML والمنظم الجسم).يمكن تقسيم جميع هذه المهام إلى تلك المتعلقة بالواجهة الأمامية والخلفية ودمجها. نحن معنيين في المقام الأول بقضايا الواجهة الأمامية والتكامل ، على الرغم من أننا نذكر أيضًا بعض الجوانب المهمة لمهام النهاية الخلفية.يمكن تقسيم خدمات الواجهة الأمامية للمحرر إلى عدة مستويات:- صفحة ويب لإنشاء وتحرير منشور ؛
- Vue-app, . , , Vue, -, , , , .., , , ;
- WYSIWYG- ProseMirror, Vue. , , ;
- SB2HTML – HTML structured body, . , structured body – , . , , , . Sports.ru HTML structured body, - HTML . HTML Node.Js, JS- .
تظهر عملية حفظ البريد في الشكل. 2. يتم نقل محتوى المنشور بتنسيق الهيكل المنظم وبيانات التعريف الخاصة به إلى الواجهة الخلفية. ترسل الواجهة الخلفية المحتوى إلى خدمة SB2HTML ، وتتلقى HTML جاهزًا في الاستجابة ، وتضع كل هذا في قاعدة البيانات وتطلع العميل على أنه تم حفظ المنشور بنجاح ، أو يبلغ عن خطأ.
تين. 2. مخطط لحفظ منشور عند إنشائه أو تحريره في محرر WYSIWYG3.2. ما الصعوبات التي واجهتها؟
كانت هناك العديد من الصعوبات ، نشأت باستمرار وغالبًا في أكثر اللحظات غير المتوقعة.كما قلنا من قبل ، يوجد محرر المحتوى داخل النموذج ، مما يسمح لك بإدخال البيانات الإضافية اللازمة لإنشاء منشور ، مثل العنوان والتعليق التوضيحي وما إلى ذلك. للتعليق التوضيحي ، يجب أن يكون من الممكن تنزيل الصور من ملف وعبر رابط من الإنترنت. ولكن بالنسبة للمحتوى ، نرغب أيضًا في تحميل الصور من ملف وبالرجوع إليها ، وفقًا لنفس القواعد. وهنا نواجه معضلة: من ناحية ، يتم عزل محتوى المنشور عن الشكل الخارجي عند التحرير ويتم تقديمه بواسطة ProseMirror ، ولكن من ناحية أخرى ، أريد أن ألاحظ مبدأ DRYولا تكرر نفس الرمز. قمنا بحل هذا على النحو التالي: وصفنا تحميل الصور كمجموعة من الأساليب في كائن على مستوى نموذج Vue وتمرير هذا الكائن كأحد المعلمات إلى مُنشئ محرر WYSIWYG.يتم تعريف الكيانات التي تصف المحتوى - العقدة والجزء - في نموذج ProseMirror. ومع ذلك ، يتم استخدام الفهارس فقط لمعاملة لتحديد نطاق الأحرف التي يتم تطبيق هذه المعاملة عليها (يتم حساب الفهارس من بداية المستند ومن بداية العقدة الأصل). تعد فهرسة الأحرف واحدة من المفاهيم المركزية لـ ProseMirror ، ولكن عند تحرير النص وتنسيقه ، يكون من الملائم جدًا التفكير في الكيانات من نموذج ProseMirror. ونتيجة لذلك ، من أجل عمل مريح مع المحتوى ، كتبنا مساعدينا لتبسيط التفاعل مع مستند للمعاملات. بعد بداية عملنا ، ظهرت مكتبة tiptap ، وهي مجموعة من المساعدين المماثلين.كانت المشكلة التالية هي أنه في مرحلة إنشاء المخطط ، أدركنا أن لدينا بالفعل تنسيقًا داخليًا معتمدًا لتخزين المحتوى - هيئة منظمة تلبي احتياجاتنا ، ويقوم ProseMirror بتخزين المحتوى بتنسيقه الخاص في قصة. كان التبديل إلى تنسيق ProseMirror صعبًا وغير عملي. وجدنا أنفسنا في موقف حيث تأتي البيانات بتنسيق واحد إلى العميل عبر واجهة برمجة التطبيقات ، ويلزم عرض تنسيق آخر. ينشأ موقف مماثل عندما يكون من الضروري حفظ المحتوى المعدل أو الذي تم إنشاؤه. للقيام بذلك ، قمنا بتطبيق محول يحول التنسيقات ذهابًا وإيابًا. لقد كتبوا اختبارًا بسيطًا له ، والذي يأخذ محتوى منشور واحد بتنسيق الجسم المنظم ، ويترجمه إلى تنسيق ProseMirror ، ثم يعود ويقارن بالفعل النسخة الأصلية مع النسخة المستلمة. اتضح بسرعة وسهولة.في المستقبل ، مع تغير مخطط الوثيقة ، وكقاعدة ، أصبح أكثر تعقيدًا ، أصبح من الواضح أن أدنى تغيير يمكن أن يؤدي إلى أخطاء في المحرر ، ويبدو أن هذا الاختبار يعطي تغطية سيئة للغاية. ونتيجة لذلك ، اضطررت إلى كتابة اختبارات على جميع تركيبات العقد والعلامات التجارية تقريبًا على طريقتين صغيرتين للتحويل. الآن بدون هذه الاختبارات ، من المستحيل تحديد ما إذا كان التغيير التالي في الدائرة سيكسر شيئًا أم لا.ترتبط المشكلة التالية مرة أخرى بالحاجة إلى التوافق العكسي بين التقنيات القديمة والجديدة. يتم تنفيذ محرر WYSIWYG الخاص بنا فقط في المتصفحات (سطح المكتب ، والجوّال قريبًا). وفقًا لذلك ، لتحرير المحتوى على العميل يتم تقديمه في JSON بتنسيق النص المُنظم ، ومع ذلك ، يتم قراءة المشاركات في المتصفحات فقط من HTML. في الوقت نفسه ، تحولت معظم تطبيقات الجوال بالفعل إلى عرض مشاركات المستخدم مباشرة من الهيكل المنظم.بالنسبة لتطبيقات الهاتف المحمول ، كان من الضروري توفير الحالة عندما لا يمكن للعميل معالجة بعض العناصر من الجسم المهيكل. على سبيل المثال ، إذا تمت إضافة عنصر جديد إلى الجسم المهيكل ، يتم تطبيق عرضه فقط في إصدار أحدث من التطبيق. نظرًا لعدم تحديث جميع المستخدمين لتطبيقاتهم في نفس الوقت ، كان من الضروري توفير خطة "B" للإصدارات القديمة: بدلاً من إنشاء HTML من نص منظم ، أدخل جزء HTML جاهزًا للعنصر المطلوب. لم يتم توفير أجزاء HTML لكل عنصر في مخطط الهيكل المنظم ، لأن فكرة هذا الهيكل كانت رفض تخزين البيانات في HTML. ولكن في النهاية ، توصلنا إلى استنتاج مفاده أننا بحاجة إلى مخططين منظمين للهيكل - أحدهما للعرض والآخر للتحرير. الاختلافات بين المخططات هيأن النص المنظم للتحرير يحتوي فقط على محتوى المقالة ، ولعرضه نضيف بعض العناصر الإضافية. على وجه الخصوص ، يتم إنشاء جزء HTML لكل عنصر عندما يتم حفظ منشور في خدمة SB2HTML ويتم إضافته فقط إلى الجسم المهيكل لعرض المنشور. بالإضافة إلى ذلك ، يعرض الهيكل المنظم أيضًا مساحة إعلانية في المحتوى للعرض.عندما نفتح المحتوى للتحرير في متصفح ، لا يمكننا في الأساس العثور على عنصر غير معروف ، لأنه يتم إنشاء جميع المشاركات وعرضها بنفس الطريقة. لكنهم قرروا توقع مثل هذه الحالة للمستقبل أيضًا. للقيام بذلك ، أضفنا عنصر كعب افتراضي إلى مخطط ProseMirror. قمنا بتسمية هذا العنصر غير معتمد. يظهر كعب الروتين بدلاً من عنصر غير معتمد. قمنا بنمطه كمستطيل رمادي مع نص يشير إلى أن هذا العنصر غير معتمد ولا يمكن تحريره. عندما يتم حفظ المنشور ، يظل هذا العنصر دون تغيير في الهيكل المنظم. يمكن للمستخدم تغيير موقعه بالنسبة للعناصر الأخرى ، ولكن لا يمكن تغيير أو تحرير المحتوى الداخلي لعنصر غير معروف. ومع ذلك ، يمكن للمستخدم حذف مثل هذا العنصر ، ثم ، بالطبع ،لن يتم حفظها في المستند النهائي.كانت جميع المشاكل الموضحة مرتبطة بصعوبات تنفيذ محرر WYSIWYG نفسه. ولكن بينما كان موجودًا في الوضع التجريبي ، لم نتمكن من التخلي عن المحرر القديم على TinyMCE واضطررنا إلى دعم كلا المحررين ، مما يوفر التوافق العكسي بينهما. على سبيل المثال ، يمكنك إنشاء منشور في محرر WYSIWYG ، وحفظه ، ثم تحريره في TinyMCE ، وحفظه ، وفتحه مرة أخرى في WYSIWYG ، وما إلى ذلك. نتيجة لذلك ، عند الفتح في WYSIWYG ، رأينا نفس المحتوى كما في الحفظ السابق في TinyMCE. لتطبيق التوافق مع الإصدارات السابقة ، كان من الضروري إرسال محتوى HTML إلى TinyMCE ، والذي تعلمنا بالفعل إنشائه من النص المهيكل وحفظه في قاعدة البيانات أثناء حفظ المنشور. وعند حفظ منشور عبر TinyMCE ، يتم تشغيل المحتوى الذي تم إنشاؤه على الخادم من خلال خدمة HTML2SB ،ونتيجة لذلك ، يمكننا حفظ كل من HTML الجديد والجسم المهيكل.HTML2SB هو عكس ما يفعله SB2HTML ، أي تحويل المحتوى من HTML إلى نص منظم. بترتيب زمني ، ظهرت هذه الخدمة قبل أي شيء آخر ، لأنه قبل إنشاء محرر WYSIWYG ، كانت الطريقة الوحيدة للحصول على محتوى المنشور بتنسيق الهيكل المنظم هي التحليل المباشر من HTML. كان HTML2SB جزءًا من البنية التحتية للواجهة الخلفية حول محرر البريد ، ولكن بعد التخلي عن TinyMCE ، لم تعد هناك حاجة إليه.4. نتائج بيتا
الآن يتوفر WYSIWYG-editor لجميع المستخدمين في الإصدار التجريبي ، وسيصبح قريبًا المحرر الرئيسي لمنشورات Sports.ru. لقد تلقينا بالفعل أداة لإنشاء وتحرير المشاركات التي تلبي معظم متطلباتنا:- أصبحت واجهة المحرر واضحة وموجزة وحديثة ، وأصبحت كتابة المنشورات الطويلة أسهل بكثير ؛
- الآن يمكنك تنزيل الصور من ملف ورابط يتم وضعه على الفور في مستودعنا ؛
- إضافة خيار تضمين عمليات التضمين من الشبكات الاجتماعية الرئيسية ومواقع استضافة الفيديو ؛
- تنظيف أنماط تنسيق النص ؛
- لقد تحولت تطبيقات الجوال بالفعل إلى عرض المشاركات من الجسم المهيكل ويمكنها تعيين أنماطها الخاصة للمحتوى.
بالطبع ، لم يتم تصحيح المحرر بشكل كامل حتى الآن ، نكتشف بشكل دوري أخطاء جديدة. التحديثات التالية قادمة:- الحفظ التلقائي.
- إصدار WYSIWYG للمستخدمين ذوي الحقوق الموسعة (المسؤولون ، المحررين بدوام كامل) ؛
- إنشاء وتحرير المشاركات من متصفحات الجوال ؛
- رسائل حول التحرير الموازي لمستند من قبل العديد من المستخدمين ؛
- النصائح والإلحاق.
- الحاجيات الإحصائية للفرق الرياضية والمباريات والتشكيلات.
في وقت كتابة هذه السطور ، تم بالفعل نشر أكثر من 13000 مشاركة من خلال الإصدار التجريبي من المحرر ، وهو ما يمثل حوالي 20 ٪ من إجمالي عدد نصوص المستخدم على Sports.ru للفترة من يونيو 2019 إلى فبراير 2020 شاملة. حصة المنشورات التي تم إنشاؤها ونشرها من خلال المحرر الجديد تنمو باطراد.
تين. 3. نسبة مشاركات المستخدمين التي تم إنشاؤها ونشرها في المحرر الجديديبدو أن النمو العضوي في حصة مشاركات المستخدمين التي تم إنشاؤها ونشرها من خلال المحرر الجديد هو إشارة إلى أن المستخدمين سعداء بالتحديث ، وهو ما تؤكده أيضًا التعليقات في الإعلان عن إطلاقه في الاختبار التجريبي (يظهر بعضها في الشكل 4). لذلك ، في الأشهر المقبلة ، نخطط لنقل إنشاء المنشورات تمامًا إلى المحرر الجديد ، بحيث نركز فقط على دعمها وتطويرها. بالمناسبة ، ما هي الوظائف التي يمكنك إضافتها إلى محرر WYSIWYG؟
تين. 4. تعليقات المستخدم في منشور مع الإعلان عن تحديث محرر WYSIWYG