لا يقتصر التصميم المتجاوب على تحدي أدواتنا ونهجنا لتصميم الويب وتطويره فحسب ، بل يجبرنا أيضًا على مراجعة طرق تخطيط وإدارة المحتوى. تتطلب مهام سير العمل الجديدة الأدوات المناسبة. عند التفكير أولاً ، يفتح هذا فرصة لأنظمة إدارة المحتوى الجديدة بالكامل (CMS) ومنصات النشر (وربما سنرى الكثير منها في المستقبل القريب). لكن أي شخص هاجر من CMS إلى آخر يعرف جيداً أن العملية ليست مؤلمة. لذا ، هل يمكننا تكييف CMS مألوف وشائع مثل WordPress لمساعدتنا في إنشاء وإدارة المحتوى التكيفي؟
أولاً ، سنحتاج إلى تصحيح الأمور. ماذا يعني المحتوى التكيفي ، ولماذا نحتاجه في عصر التصميم المتجاوب؟ سنناقش أيضًا ميزات و أدوات WordPress التي يمكن أن تساعدنا في إنشاء منصة نشر مستقبلية. نحن نهدف إلى تحقيق هدف كبير: وجود محتوى يمكن تقديمه بمرونة ، بمجرد إنشائه ، على أجهزة مختلفة وفي ظروف عرض مختلفة. دعونا نرى كيف يمكن أن نصل إلى ما يقرب من ذلك.
في كتابها الأخير استراتيجية المحتوى للجوال و UX واختصاصي استراتيجية المحتوى كارين ماكجران يقدم تفسيراً مفصلاً وجادًا عن سبب احتياجنا إلى نهج جديد لإدارة المحتوى. نحن نذهب إلى أبعد من بناء مواقع سريعة الاستجابة - فنحن نقوم بإنشاء محتوى يمكن نشره على منصات مختلفة والوصول إليه على العديد من الأجهزة. ماذا لو غدا تصبح الثلاجة أداة أساسية لشخص ما لاستهلاك المعلومات؟ هل موقعك على الويب جاهز لحالة الاستخدام هذه؟
نشأ التصميم المتجاوب في الغالب من الحاجة إلى تزويد مستخدمي الجوّال بتجربة ملائمة. بصراحة ، على الرغم من "الجوال" ليست سوى جزء من الصورة. إذا فكرنا بالمستقبل ، يمكننا أن نتوقع بسهولة من المنصات والأجهزة الجديدة الأخرى التي سيظهر عليها المحتوى الخاص بنا: الساعات ، الثلاجات ، نظارات العيون ، روبوتات الحديث - أي شيء يمكن للمرء أن يتخيله. هل يعني هذا أننا بحاجة إلى إنشاء إصدار "روبوت حديث" لموقعنا؟ هذا سيكون الجنون. إذن ما هو الحل؟ الحل هو المحتوى التكييفي - المحتوى الذي يمكن استخدامه بمجرد إنشائه في حالات وسيناريوهات مختلفة. يبدو رائعا ، أليس كذلك؟ كيف يمكننا تحقيق ذلك؟
لم يعد محتوانا يتكون من "صفحات". إنه يتكون من كائنات ، كل منها يجب أن يعتبر حزمة من عناصر محددة مسبقا. بالنسبة لكل مكون هيكلي - جزء - فإن نظام التصميم سيحدد كيفية عرضه في جميع السيناريوهات. يمكن تقديم قطع في وسائط أو تنسيقات بديلة لحالات الاستخدام المختلفة. على سبيل المثال ، إذا كان لدينا فيديو في كائن المحتوى الخاص بنا ، فيمكن أن يكون لدينا نص وصفي أو نص لسيناريوهات حيث لا يمكن عرض الفيديو. أو قد تختلف التعليقات التوضيحية لعنصر ما وفقًا للسيناريو - على سبيل المثال عند مشاركته في الشبكات الاجتماعية ، أو المتضمنة في نتائج البحث ، أو المقدمة على الموقع.
يجب أن نتخذ الخطوة التالية نحو فصل المحتوى عن العرض التقديمي. في الواقع ، هذا هو مبدأ هام لإعادة التصميم وحجر الزاوية في معايير الويب. ولكن علينا أن نذهب أبعد وأن نحرر أنفسنا من عقلية WYSIWYG. "ما تراه" ليس "ما يراه مستخدموك" بعد الآن. هذا هو وهم خطير. يجب ألا نقوم بتعليم النص الخاص بنا بخطوط مائلة أو إدراج صور كـ HTML في حقل "المحتوى" في "صفحة". يجب علينا فقط تضمين إشارة إلى كائن محتوى والسماح لنظام التصميم لدينا بتحديد كيفية تقديم الكائن.
كلما زاد حجم العمل الذي نقوم بتفريغه إلى أدوات البرنامج (بعد كل شيء ، نريد أن يتم عرض المحتوى الخاص بنا على العديد من الأنظمة الأساسية تلقائيًا استنادًا إلى سيناريوهات محددة مسبقًا ، أليس كذلك؟) ، كلما زادت المعلومات التي يجب علينا توفيرها لهذه الأنظمة حول المحتوى. على سبيل المثال ، في الماضي ، كان بإمكاننا أن نكتب باللغة الإنجليزية البسيطة أن مؤلف النص هو John Doe وأن يضع علامة على اسمه بالخط العريض - والآن لا يمكننا ذلك. نحن بحاجة إلى حقل منفصل في CMS لإدخال الاسم ومجموعة من القواعد لكيفية تقديمه في سيناريوهات مختلفة.
نحتاج إلى مصدر واحد للمحتوى ونظام نشر يستند إلى سيناريو يمكن أن يقرر كيفية تقديم المحتوى المطلوب إلى مستخدم وفقًا لبيئته (الجهاز ، دقة الشاشة ، سرعة الاتصال ، إلخ).
هل يمكن تحقيق كل هذه الجوانب باستخدام WordPress؟ يلوم ماكجران WordPress وغيره من برامج المدونات لعدم دعم الناشرين كأداة للمحتوى التكييفي. على وجه التحديد ، لا يزال لدينا محرر WYSIWYG في WordPress ، مع منطقة نصية واحدة لإدخال "المشاركة". لسوء الحظ ، هذه هي الحالة التي تواجه مصممًا باستخدام الإصدار العادي من WordPress. لحسن الحظ ، يعد WordPress أكثر قليلاً من مجرد "برامج التدوين". وقد تطور إلى منصة تطوير ، وهو إطار يمكن لمطوّر البرامج من خلاله أن يزود العملاء بتجربة حديثة وحقيقية في المستقبل.
دعونا نرى الأدوات التي لدينا كمطورين ، وكيفية تنفيذها لتحويل WordPress إلى منصة نشر متكيفة لعملائنا.
بدأت WordPress تحركها نحو كونها نظامًا أساسيًا متكاملًا CMS مع إدخال أنواع منشورات مخصصة وتصنيفات مخصصة. ميزة أخرى قوية لاستخدامها في تركيبة مع هذه هي الحقول المخصصة ما يسمى. يشير هذا الاسم البسيط إلى واجهة المستخدم الرسومية؛ في الواقع ، تمثل هذه الحقول المخصصة مجموعة من البيانات الوصفية التي يمكن ربطها بأي كائن في WordPress. يمنحنا WordPress القدرة على إنشاء واجهة مستخدم قابلة للتخصيص بدرجة كبيرة للبيانات الوصفية وواجهة برمجة تطبيقات مرنة لتخزينها والوصول إليها.
لماذا هذا مفيد؟ مع أنواع المنشورات المخصصة ، لم يتم قفل مفهوم "الصفحة" بعد الآن. يمكننا إنشاء نوع نشر لأي كائن نحتاج إليه (مثل الأخبار والأحداث والشركاء - كل ما نحب) ، ويمكننا تحديد بنية الكائن من خلال هذه المجموعة من البيانات الوصفية. يمكننا أيضًا إنشاء واجهة مستخدم منفصلة لإدارة بيانات التعريف. كل هذا يمنحنا المزيد من هيكلنا. بمجرد أن سمح لنا WordPress بإنشاء بيانات تعريفية من أي نوع ، يمكننا استخدامه لتخزين بدائل لكتل المحتوى المضمنة مثل العناوين والأوصاف. (على سبيل المثال ، قد نرى مكونات SEO التي تسمح باستخدام عنوان ووصف فريد من نوع تحسين محركات البحث لكل كائن محتوى.)
ما هي حدوده؟ ينتقد WordPress كثيرًا لعدم توفير واجهة برمجة تطبيقات لتخزين البيانات الوصفية باستمرار. على وجه التحديد ، يمكن أن يكون لدينا بيانات التعريف للوظائف (وأنواع المنشورات المخصصة) والمستخدمين ، ولكن ليس لبيانات التصنيف (أ البرنامج المساعد مطلوب من أجل هذا). إنشاء واجهة مستخدم مخصصة في شاشة التحرير لمشاركة ليست بالسهولة التي يمكن أن تكون عليها. الوظائف والمعايير المحددة مسبقًا مفقودة (وهذا هو السبب في أن المكونات الإضافية المختلفة تقوم بها بشكل مختلف ، مما يتركنا في حالة من الفوضى ، وليس النظام). لكن التغييرات الحديثة التي تساعد على توحيد وتحسين لوحة تحكم WordPress تمنحنا الأمل.
ميزة أخرى رائعة لـ WordPress هي أنه يسمح بعدة نسخ من محرر النص المنسق في صفحة واحدة. هذا يمكن تنفيذها مع wp_editor وظيفة ، والتي لا تنشئ فقط ترميز textarea المطابق ، ولكن أيضًا تقوم بتعيين وظيفة تحرير rich إليها وأزرار اختيار الوسائط.
لماذا هذا مفيد؟ باستخدام هذه الوظيفة ، يمكننا تقسيم حقل محتوى واحد إلى عدة وفقًا لهيكل الكائن. عند القيام بذلك ، نضيف مكونًا بنيويًا لأجسامنا. أيضًا ، سيكون لكل منطقة قابلة للتحرير واجهة مستخدم موحدة ومألوفة ستساعد المحررين على إدراج الترميز الضروري في الحقول المناسبة بسهولة ، بما في ذلك الرموز القصيرة.
ما هي حدوده؟ يجب أن نقوم بتخزين البيانات التي تم إدخالها في مناطق تحرير rich مثل data meta ، وهذا يعني المزيد من استدعاءات قاعدة البيانات ، إلخ. لذلك ، سيتطلب هذا النهج مزيدًا من الاهتمام لتحسين الموقع ، مثل التخزين المؤقت. لا توجد وظيفة مضمنة لتمثيل هذه البيانات في النماذج ، لذلك سنحتاج إلى إنشائها.
باستخدام هذا الأسلوب ، سيتم تحويل شاشة التحرير المألوفة بشكل كامل:
تمكّننا أدوات WordPress التي نوقشت أعلاه من جعل المحتوى أكثر تنظيماً من خلال تعريف الكائنات واستبدال كتلة واحدة من المحتوى بمجموعة من الحقول التي تخزّن الأجزاء المختلفة للمحتوى وبيانات التعريف.
الآن دعونا نرى ما هي الأدوات التي لدينا لفصل المعنى والعرض التقديمي. في الواقع ، هناك قاعدتان أساسيتان فقط:
القاعدة الأولى سهلة المتابعة. باستخدام فلتر بسيط ، يمكننا إزالة المحرر المرئي لجميع المستخدمين.
add_filter('user_can_richedit', '__return_false');
القاعدة الثانية أكثر صعوبة في اتباعها. بالتأكيد ، لن نقوم بمطاردة كل علامة من علامات HTML في نصنا - تلك التي تمثل العناصر الدلالية حقا هي موافق تماما. ولكن عندما نبدأ في إدخال تنشأ مشكلة كبيرة أخرى عن طريقة إدراج WordPress الوسائط الغنية - وخاصة الصور - في حقول المحتوى. في الوقت الحالي ، تقوم بطباعة HTML واضحة تقوم بترجمة الوصلة إلى الصورة وحجمها وترميزها. إنه أسوأ سيناريو ممكن لمقاربة التكيف. ماذا لو احتجنا إلى صيغة أخرى من الصورة لحالة استخدام معينة؟ ماذا لو قمنا بنقل مكتبة الوسائط الخاصة بنا إلى مجال آخر؟ ماذا لو قمنا بتغيير تصميم كائن ، وبالتالي ، تحتاج الصورة في حجم آخر؟ ماذا لو قمنا بتنفيذ تقنية سريعة الاستجابة تتطلب منا تحديد عدة مصادر لصورة واحدة؟ جميع حالات الاستخدام هذه مستحيلة تمامًا إذا لم نغير السلوك الافتراضي لـ WordPress. ومع ذلك فإن WordPress يملك كل شيء تقريباً لجعل الانتقال إلى نهج التكيف ممكنًا: مع وضع كل ذلك معًا ، يمكننا تمثيل ترميز الوسائط باستخدام رمز قصير يحتوي على معرف العنصر في مكتبة الوسائط. مثال أساسي جدا سيبدو هكذا: uploads
مجلد منفصل ، بحيث يمكن بناء المسار الكامل بشكل حيوي. add_shortcode('frl_image', 'frl_image_screen');function frl_image_screen($atts, $content = ''){extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));$out = '';$id = intval($id);if($id == 0)return ''; // no attachment$out = "