كثير من الشركات عند تطوير موقعها الرسمي تذكر عرضًا: لنقم بتطوير لوحة الإدارة أيضًا. يبدو الأمر وكأنه خطوة إضافية بسيطة، لكنه عمليًا يتحول غالبًا إلى مجموعتين من المتطلبات تتصارعان.
الموقع الرسمي يجب أن يكون جميلًا وسريعًا وقابلًا للفهرسة في محركات البحث؛ بينما لوحة الإدارة يجب أن تتيح تعديل المحتوى وعرض البيانات وإدارة الصلاحيات. كلاهما يشتركان في نموذج بيانات واحد، لكنهما يخدمان مستخدمين مختلفين تمامًا. إذا لم يكن التخطيط جيدًا، فالنتيجة الأكثر شيوعًا هي: إطلاق الموقع أولًا، ثم عند تعديل حقل واحد في لوحة الإدارة تنهار الواجهة الأمامية بالكامل؛ أو الانتهاء من لوحة الإدارة ليكتشف الفريق أن هيكل المحتوى في الموقع لا يتطابق معها إطلاقًا.
تشرح هذه المقالة، وفقًا لتسلسل المشروع الفعلي، تخطيط الموقع الرسمي مع لوحة الإدارة في تطوير المواقع الإلكترونية.
افصل أولًا بين مسارين: منطق العرض ومنطق التحرير
الموقع الرسمي هو منطق العرض، ولوحة الإدارة هي منطق التحرير. يجب تصميم هذين المسارين بشكل منفصل، لكن مع مشاركة نموذج بيانات واحد.
الطريقة العملية هي تحديد نموذج المحتوى أولًا، ثم تحديد الصفحات. على سبيل المثال، الأقسام الشائعة في موقع الشركة: الأخبار، المنتجات، الحالات، التوظيف. ما الحقول الموجودة في كل قسم، وأيها إلزامي، وما أبعاد الصور، وهل يدعم تعدد اللغات — كل هذا يجب تحديده قبل رسم الصفحات.
نقطة يجب تجنبها: لا تجعل لوحة الإدارة تقابل وحدات الصفحة مباشرة. في كثير من المشاريع تُصمم لوحة الإدارة على شكل «نص الشاشة الأولى من الصفحة الرئيسية» و«صورة الشاشة الثانية من الصفحة الرئيسية»، وعند إعادة تصميم الموقع تصبح لوحة الإدارة كلها بلا فائدة. الطريقة الصحيحة هي أن تدير لوحة الإدارة المحتوى، وتدير الصفحة العرض، ويتم الربط بينهما عبر تعيين الحقول.
مشكلة أخرى هي الصلاحيات. يجب أن تحتوي لوحة الإدارة على الأقل على ثلاثة أدوار: مسؤول، محرر، وقارئ فقط. غالبًا ما يُغفل هذا في مشاريع مواقع الشركات، ولا يُكتشف إلا بعد الإطلاق أن المتدرب يستطيع حذف البيانات.
من حيث الجدول الزمني، يجب أن تكمل لوحة الإدارة طبقة البيانات قبل الموقع
الترتيب الأكثر أمانًا هو: نموذج البيانات → واجهات لوحة الإدارة → واجهة لوحة الإدارة → صفحات الموقع.
صفحات الموقع تعتمد على بيانات حقيقية، وإذا لم تكن لوحة الإدارة جاهزة، فسيضطر الفريق الأمامي للعمل ببيانات وهمية، وستنفجر المشكلات دفعة واحدة في مرحلة الربط. اجعل لوحة الإدارة قادرة أولًا على الإدخال والتعديل وإرجاع الهيكل الصحيح، ثم يربط الموقع بها، وستقل إعادة العمل كثيرًا.
مثال عملي: شركة لتأجير المعدات، يحتاج موقعها إلى عرض قائمة المعدات والحجز عبر الإنترنت، وتحتاج لوحة الإدارة إلى إدارة معلومات المعدات وسجلات الحجز وتدفق الحالات. إذا تم تطوير الموقع أولًا، فمن السهل ألا تتطابق حقول نموذج الحجز مع هيكل السجلات في لوحة الإدارة، مثلًا يستقبل الموقع «مدة الإيجار المطلوبة» بينما تخزن لوحة الإدارة «تاريخ البدء» فقط. هذه المشكلات لا تُكتشف إلا عند الربط، وتعديلها يتطلب تغيير قاعدة البيانات.
لذلك يجب تخصيص ثلث الوقت على الأقل للوحة الإدارة كمرحلة سابقة، وعدم اعتبارها ملحقًا للموقع.
اتفق على الواجهات أولًا، لا تنتظر انتهاء رسم الصفحات
العلاقة بين الموقع ولوحة الإدارة هي علاقة واجهات. من الأفضل كتابة وثيقة بسيطة قبل التطوير تحدد أسماء الحقول وأنواعها وطريقة الترقيم وأكواد الأخطاء.
لا حاجة لوثيقة رسمية معقدة، جدول من صفحة واحدة يكفي: مسار الواجهة، المدخلات، مثال الاستجابة، الحالات الاستثنائية. هذا يوفر الكثير من التواصل الشفهي.
نقطة يجب تجنبها: رفع الصور. كل من الموقع ولوحة الإدارة يتعاملان مع الصور، لكن المتطلبات مختلفة. الموقع يحتاج ضغطًا وCDN وتحويلًا للتحميل المتأخر؛ ولوحة الإدارة تحتاج الصورة الأصلية وإمكانية القص والترتيب. من الأفضل توحيد منطق الرفع في خدمة واحدة، وعدم كتابة نسختين منفصلتين.
كذلك البحث والتصفية. شروط التصفية في لوحة الإدارة غالبًا أكثر تعقيدًا من الموقع، وإذا صُممت الواجهة للموقع فقط، فستحتاج لوحة الإدارة إلى مجموعة استعلامات إضافية. صمّم معاملات التصفية مسبقًا بشكل قابل للتركيب، وستوفر عناءً لاحقًا.
يجب النظر إلى الأمان ومدخل المسؤول بشكل منفصل
لوحة الإدارة هي أكبر سطح هجوم. إحدى الخطوات التي غالبًا ما تُتجاوز في تطوير المواقع الإلكترونية هي اختبار أمان لوحة الإدارة.
الحد الأدنى المطلوب: إضافة رمز تحقق وحد لمحاولات تسجيل الدخول في لوحة الإدارة؛ فرض تعقيد كلمة مرور المسؤول؛ التحقق من الصلاحيات في الواجهات وعدم الاعتماد فقط على إخفاء القوائم في الواجهة الأمامية؛ تسجيل سجل العمليات.
إذا كان المشروع تطوير تطبيقات مصغرة أو تطوير تطبيقات App، فغالبًا ما تحتاج لوحة الإدارة إلى الربط مع عدة عملاء، ويصبح نموذج الصلاحيات أكثر تعقيدًا. في هذه الحالة يُنصح بتقسيم لوحة الإدارة إلى «إدارة المحتوى» و«إدارة الأعمال»، الأولى لفريق التشغيل والثانية لفريق الأعمال، لتقليل الأخطاء.
نقطة يجب تجنبها: لا تستخدم نفس نظام الحسابات الخاص بالموقع لإدارة لوحة الإدارة. مستخدمو الواجهة الأمامية والمسؤولون يجب أن يكونوا في جدولين منفصلين ومنطقي تسجيل دخول منفصلين.
اكتب معايير القبول مسبقًا، لا تفكر فيها قبل الإطلاق
قبول الموقع يعتمد على سرعة التحميل والتوافق مع الجوال وعناصر SEO الأساسية (العنوان، الوصف، البيانات المنظمة). قبول لوحة الإدارة يعتمد على ثلاثة أمور: هل يمكن الإدخال الكامل، وهل يظهر بشكل صحيح على الموقع، وهل الصلاحيات صحيحة.
يُنصح بإعداد قائمة قبول، كل بند فيها يقابل إجراء فحص قابلًا للتنفيذ. مثلًا «إضافة خبر جديد، يظهر في صفحة قائمة الموقع خلال دقيقة واحدة»، «دور المحرر لا يستطيع حذف البيانات»، «بعد رفع الصورة يظهر الموقع صورة لا تتجاوز 300KB».
الاتفاق على القائمة مع فريق التطوير في بداية المشروع أكثر فعالية بكثير من طرح المتطلبات في اللحظة الأخيرة قبل الإطلاق.
متى يكون من المناسب التعاون مع MIC Studio
إذا لم يكن لدى الفريق مطور خلفي متخصص، أو كان الموقع ولوحة الإدارة يجب أن يلحقا بموعد واحد، فإن الاستعانة بجزء من العمل الخارجي أمر معقول. عند قيام MIC Studio بتطوير مواقع الشركات ولوحة الإدارة بشكل متكامل، فإنها عادة تساعد العميل أولًا في ترتيب نموذج المحتوى والاتفاق على الواجهات، ثم تبدأ التطوير.
الحالات المناسبة للتعاون معنا: الموقع يحتاج إعادة تصميم ولوحة الإدارة تحتاج إعادة بناء؛ المواقع التي تتضمن تدفقات أعمال مثل الحجز والتسجيل؛ المشاريع التي تحتاج لوحة إدارتها إلى الربط مع تطبيق مصغر أو App متعدد العملاء. أما إذا كان الأمر مجرد تعديل بضعة أسطر نصية، فلا حاجة لاتباع دورة مشروع كاملة.
ثلاث توصيات قابلة للتنفيذ
أولًا، اكتب صفحة واحدة لنموذج المحتوى قبل البدء، وحدد الأقسام والحقول والحقول الإلزامية، وليسر كل من الموقع ولوحة الإدارة وفقًا لها.
ثانيًا، في الجدول الزمني، اجعل طبقة بيانات لوحة الإدارة تعمل أولًا، ثم يربط الموقع بالواجهات الحقيقية، لتقليل إعادة العمل في مرحلة الربط.
ثالثًا، أجرِ فحص أمان واختبار صلاحيات للوحة الإدارة قبل الإطلاق، ولا تنتظر وقوع مشكلة لتصلحها.