موقع شركة أم تطبيق ويب؟ الفرق الذي يغيّر عرض التنفيذ

إذا كان العميل سيقرأ خدماتك ثم يرسل طلب تواصل، فأنت تناقش احتياجًا مختلفًا عن عميل يدخل إلى حسابه ويرفع مستندًا ويعتمد عرضًا ويتابع تنفيذ طلبه. قد تبدو الشاشتان بسيطتين، لكن الثانية تحتاج قواعد وبيانات ومسؤوليات لا يكشفها عدد الصفحات.

قبل طلب «موقع شركة» أو «تطبيق ويب»، اكتب ما الذي سينجزه كل مستخدم وما الذي ينبغي أن يبقى محفوظًا بعد إغلاق المتصفح. المصطلح يساعد في وصف المشروع، لكنه لا يغني عن النطاق. يمكن أن يجمع المشروع واجهة عامة للتعريف بالشركة ومساحة عمل خاصة للعملاء أو الموظفين.

الفرق يبدأ من العمل الذي يحدث خلف الصفحة

الموقع التعريفي يهتم عادة بعرض معلومات وخدمات ومحتوى ووسائل تواصل يمكن لإدارة الشركة تحديثها. أما تطبيق الويب فيضيف عملًا ينفذه المستخدم داخل المتصفح: إنشاء سجل، ومراجعته، وتغيير حالته، والوصول إلى بيانات بحسب دوره. هذه أمثلة لتوضيح النطاق وليست حدودًا تقنية صارمة بين نوعين لا يلتقيان.

توضح MDN أن المواقع قد تولد محتوى ديناميكيًا وتتعامل مع بيانات وطلبات من المتصفح. لذلك لا يصح افتراض أن كل موقع شركة ثابت، أو أن وجود قاعدة بيانات يحوله وحده إلى منتج أعمال معقد. اسأل عمن يستخدم الوظيفة، وماذا يتغير بسبب استخدامها، ومن يعتمد التغيير.

مثال لشركة ترجمة افتراضية

تريد الشركة عرض اللغات والخدمات ونشر مقالات واستقبال استفسارات. قد يحقق موقع عام بإدارة محتوى هذه البداية. بعد ذلك تطلب أن يرفع العميل ملفًا ويطّلع على عرضه ويوافق عليه ويتابع حالة التسليم، بينما يسند الموظف الطلب إلى الشخص المسؤول. أصبح هناك مسار عمل يحتاج تعريفًا مستقلًا.

لا يعني ذلك بالضرورة بناء نظام جديد لكل شيء. قد تملك الشركة نظام طلبات مناسبًا يحتاج ربطًا بواجهة العميل، أو تقرر بدء المرحلة الأولى بطلب استفسار فقط. المهم أن يظهر القرار: أي خطوة ستتم داخل الموقع، وأي خطوة ستظل في نظام آخر أو يدويًا، ومن يشرح الحالة للعميل.

مصفوفة تساعدك على تحديد ما تطلبه

السؤال	ما الذي يكشفه؟	ما تسجله في النطاق
هل يختلف ما يراه كل مستخدم؟	حاجة إلى حسابات وأدوار وحدود وصول.	من يرى الطلب أو الملف ومن يستطيع تغييره.
هل يستكمل المستخدم عملًا بدأه سابقًا؟	حفظ الحالة والعودة إليها عبر جلسات مختلفة.	ما الذي يُحفظ وكيف يعرف المستخدم آخر حالة.
هل توجد مراجعة أو موافقة؟	قواعد انتقال بين حالات ومسؤوليات.	من يعتمد، وما يحدث عند الرفض أو التعديل.
هل تأتي البيانات من نظام آخر؟	تكامل واعتماد على مصدر خارج الواجهة.	مصدر المعلومة واتجاه الربط وحالة تعذره.
هل سيشغل الموظفون الخدمة يوميًا؟	أدوات تشغيل وصلاحيات وتدريب.	مهام الموظف وسجلها ومخرجات التسليم.

لا تجمع عدد الإجابات لتنتج حكمًا آليًا. قد يكفي استخدام خدمة قائمة خلف موقع بسيط، وقد تحتاج وظيفة واحدة حساسة إلى تحليل أعمق. المصفوفة تكشف أسئلة العرض، ولا تصنف كل مشروع وفق درجة ثابتة أو سعر مفترض.

قسّم العرض إلى مساحة عامة ومسار عمل

ضع في جزء الموقع العام الصفحات والمحتوى واللغات والتحرير والنماذج المطلوبة. ثم ضع لكل مسار عمل مستخدمه ومدخلاته وحالاته ومخرجاته. في مثال الترجمة، إرسال ملف ليس مجرد حقل مرفق إذا كان الملف سيرتبط بطلب خاص ويظهر لاحقًا لصاحب صلاحية محددة.

حدد كذلك ما يحتاجه الموظف: قائمة طلبات، ومسؤول إسناد، وطريقة اعتماد حالة، وسجل يفسر التغيير. إذا لم تكن هذه العمليات ضمن العرض، فاطلب بيان النظام أو الإجراء الذي سيغطيها. لا تجعل عبارة «لوحة إدارة» تُخفي الاختلاف بين تعديل نص صفحة وإدارة طلبات العملاء.

اكتب الحالات التي لا تظهر في صورة التصميم

ماذا يحدث إذا انقطع رفع الملف، أو انتهت جلسة الدخول، أو عدّل العميل طلبًا سبق اعتماده؟ وما الذي يراه مستخدم يحاول فتح طلب لا يخصه؟ ناقش هذه الحالات بمستوى العمل المطلوب، واتفق على ما سيُختبر دون مشاركة ملفات عملاء حقيقية في عرض تجريبي.

يساعد شرح MDN لتبادل الطلبات بين المتصفح والخادم في فهم أن الضغط على زر يبدأ معالجة ونتيجة، وليس مجرد تغيير مرئي في الشاشة. لا تحتاج إلى كتابة تفاصيل البروتوكول في طلب السعر؛ تحتاج إلى نتيجة واضحة عند النجاح والفشل والعودة إلى المهمة لاحقًا.

اختر مرحلة أولى تستطيع تشغيلها

إذا كان الهدف الحالي استقبال استفسارات منظمة، فقد تبدأ بالموقع والنموذج وتؤجل البوابة. وإذا كان أصل المشكلة أن العملاء لا يعرفون حالة طلباتهم، فلا تعتبر إطلاق صفحات تعريفية حلًا كاملًا لها. اختر مسارًا يخدم الهدف، وحدد طريقة تشغيل الأجزاء المؤجلة.

راجع ما إذا كانت استضافة الموقع ودعم مسارات العمل وتحديث الربط والتراخيص الخارجية ظاهرة كبنود مفهومة. لا تفترض أن كل تكلفة تشغيل متشابهة لمجرد أن المستخدم سيفتح الحل من متصفح. أثر البيانات والحسابات والتكاملات يحتاج شرحًا في عرض الشركة.

اختبار قرار قبل إرسال الطلب

1. اكتب ما يفعله الزائر العام وما يفعله العميل والموظف بعد تسجيل الدخول إن وُجد.
2. اختر مهمة أساسية وسمِّ البيانات التي تبدأ بها والحالة التي تنتهي إليها.
3. حدد ما يملكه نظامك الحالي وما يحتاج تنفيذًا أو ربطًا.
4. راجع استثناء واحدًا وعودة المستخدم بعد إغلاق المتصفح.
5. اطلب من الشركة إعادة وصف النطاق بلغتك قبل مناقشة السعر.

للميزانية الأوسع راجع دليل نطاق وتكلفة موقع الشركة، ولصياغة المهام استخدم دليل تجهيز المتطلبات. وعندما تحتاج مساحة عمل فعلية في المتصفح، ناقش تطوير تطبيق ويب بالمصفوفة والمسار، بدل الاكتفاء باسم منتج يشبه فكرتك.

المراجع

فُتحت في 3 نوفمبر 2026 مقدمة MDN للبرمجة على الخادم وشرح التفاعل بين المتصفح والخادم. المثال والمصفوفة إرشاد شراء أصلي، لا تصنيف تقني ملزم أو تسعير سوقي. أُعد النص بمساعدة الذكاء الاصطناعي مع مراجعة المحتوى ومصادره.