متجر قهوة مختصة مع لوحة الإدارة التي تديره.

رحلة المشروع

1. نظرة عامة

   Coffee Shop Website، عمل لعميل تولّيت فيه التصميم والتطوير المتكامل. وهو واجهة متجر مع لوحة الإدارة التي تديره، مبني بالكامل بقاعدة بياناته الخاصة وتصميم تجربة وواجهة وتغليف بـDocker.

2. المشكلة

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

3. البحث والفهم

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

4. الحل والعملية

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

5. النتيجة

   واجهة متجر ولوحة إدارة مكتملتان، مغلَّفتان بـDocker كوحدة متنقلة. والصور أدناه مقسومة على الطرفين: ما يراه العميل، وما يدير منه صاحب المتجر متجره.

6. الأثر

   العمل منتهٍ وواقف عند خطوة واحدة قبل الإطلاق، إذ تحتاج بوابة الدفع وربط التوصيل مفاتيح API لا يصدرها إلا العميل، فلا يوجد بعد رقم تشغيل حقيقي يُذكر.

7. الخلاصة والدروس

   هذا أول مشروع استخدمت فيه واجهات API وبوابات الدفع وواجهات التوصيل بصورة حقيقية، وتعلّمت فيه تغليف برنامج كامل بـDocker بحيث يسهل تسليمه ونقله. وما كنت سأغيّره: فتح حسابات البوابة والتوصيل في بداية المشروع لا في نهايته، فهذا الاعتماد هو ما يُبقي عملًا مكتملًا خارج الخدمة.