الزيارة كلها.
شغالة مع بعض.

دراسة حالة من فريق الهندسة في Softworks

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

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

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

لقطة موجودة من 17 أكتوبر 2026. معاينة التطبيق جوه التصميم بتستخدم بيانات توضيحية. تفاصيل الصور.

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

فهمنا المنتج من الزيارة نفسها

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

صاحب الصالون بيشوف نفس الزيارة من زاوية تانية: مين متاح؟ الخدمة هتاخد وقت قد إيه؟ هل فيه كرسي مناسب؟ هل العميل محتاج تجهيز معين؟ وهل الزيارة لسه طلب جديد ولا اتأكدت؟

بنينا رحلة Salony بحيث المعلومات دي تفضل مرتبطة ببعض. بيانات الخدمات والمواعيد ومعرض الأعمال مش مجرد محتوى للتسويق؛ هي جزء من القرار اللي العميل بياخده. وجود صورة حلوة مع معلومات تشغيل غير دقيقة يخلق توقعات صعب تنفيذها.

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

من صورة محفوظة لطلب زيارة مفهوم

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

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

الرحلة عندنا بتربط الخطوات دي:

1. اكتشاف الصالونات والخدمات وأفكار اللوك.
2. اختيار الفرع والخدمة أو مجموعة الخدمات.
3. اختيار المتخصص ومعرفة المواعيد المناسبة.
4. مراجعة سياسة الزيارة والتفاصيل المطلوبة.
5. إضافة صورة مرجعية وملاحظات بشكل اختياري.
6. إرسال الطلب ومتابعة خطوة الدفع المناسبة.
7. متابعة حالة الحجز والإجراء اللي مطلوب بعد كده.

واجهة React Native فعلية من تصدير الويب الموجود، ببيانات صالونات افتراضية. الصورة مش دليل اختبار على جهاز موبايل حقيقي.

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

بنية النظام ومسؤولية كل جزء

المشروع موجود في مستودع واحد باستخدام npm workspaces، وفيه تطبيق الموبايل وتطبيق الويب. الموبايل مبني بـ React Native وExpo، والتنقل بـ React Navigation. الويب مبني بـ Next.js، وبيضم الصفحات العامة ولوحات الإدارة وطبقة الـ API.

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

MongoDB مع Mongoose بيخزنوا بيانات التشغيل في نماذج واضحة. تخزين الصور مرتبط بـ AWS S3، ومكتبة الإلهام بتتعامل مع مصدر صور خارجي مع الحفاظ على بيانات المصدر وصاحب الصورة.

flowchart TB
  A[تطبيق العميل] --> D[خدمات المنتج المشتركة]
  B[الموقع العام] --> D
  C[لوحة تشغيل الصالون] --> D
  D --> E[المواعيد ودورة الحجز]
  D --> F[الصور المرجعية ومعرض الأعمال]
  D --> G[الدفع والتواصل]
  E --> H[(MongoDB)]
  F --> H
  G --> H
  F --> I[تخزين الصور ومصدر الإلهام]

رسم توضيحي على مستوى المنتج؛ مش خريطة للإعدادات أو التفاصيل الداخلية.

النشر الحالي للويب بيستخدم Cloudflare Workers مع OpenNext. تشغيل سيرفر Next جوه Durable Object بيحافظ على سياق اتصال Mongoose الحالي. قاعدة البيانات نفسها فضلت MongoDB؛ اختيار الاستضافة ما كانش معناه نقل بيانات المنتج إلى قاعدة مختلفة.

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

التقنيات اللي موجودة فعلًا في النسخة اللي راجعناها

الأرقام دي بتوصف ملفات المشروع وقت المراجعة. مش قائمة بأحدث إصدار لكل مكتبة، ومش توصية إن أي مشروع تاني يرقّي لنفس النسخ. كمان وجود مكتبة مش معناه إن كل إمكانياتها مستخدمة في Salony.

التحدي الأول: الصالون مفتوح، لكن هل الخدمة متاحة؟

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

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

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

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

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

التوقيت جزء من نفس المشكلة. اعتمدنا على Africa/Cairo في تكوين وعرض وقت الشغل، بدل الاعتماد على فرق ساعات ثابت. دعم فروع دولية بتوقيت مختلف لكل فرع يفضل توسع له متطلبات إضافية، مش ميزة هنفترض إنها موجودة.

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

التحدي التاني: المعاد اللي ظهر من دقيقة ممكن يتغير

سيناريو توضيحي: عميلين فتحوا نفس المعاد، وكل واحد بدأ يكمل الحجز. وقت عرض الشاشة كان متاح، لكن أول طلب ينجح بيغيّر الواقع بالنسبة للتاني.

الحل محتاج مراجعة وقت التنفيذ، مش الاعتماد على نسخة قديمة من الشاشة. خدمة الحجز بتراجع الإتاحة تاني، وبتستخدم سجلات حجز للفترة المطلوبة. لو فيه طلب تاني سبق، العملية تقدر ترجع إن المعاد مبقاش متاح.

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

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

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

التحدي التالت: الدفع والحجز ليهم حالات مختلفة

سيناريو توضيحي: العميل أرسل بيانات تحويل، لكن التحويل لسه محتاج مراجعة. وفي نفس الوقت، الفرع لسه ما وافقش على الزيارة.

لو وصفنا كل ده بكلمة «تم»، هنخلق توقع غير دقيق. فصلنا حالة الدفع عن حالة الموعد، بحيث كل شاشة تقول إيه اللي حصل فعلًا وإيه اللي لسه مستني خطوة.

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

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

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

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

التحدي الرابع: الصورة المرجعية تفضل مرتبطة باختيار العميل

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

لو الحجز معتمد على رابط حي لبيانات الكتالوج بس، تعديل ملاحظة بسيطة ممكن يحتاج إعادة تحميل المصدر كله. ده يربط سجل الزيارة بحاجة خارج سيطرتنا في لحظة التعديل.

بنحتفظ بلقطة من بيانات المرجع وقت اختياره: الصورة، والعنوان، والتصنيف، وبيانات المصدر المتاحة، وملاحظة العميل. المسار الحالي بيسمح لحد تلات صور مرجعية مع ملاحظة محدودة الطول لكل صورة.

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

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

لقطة ديمو موجودة من 13 أكتوبر. الصورة المرجعية وسيلة للتفاهم، والنتيجة النهائية بيتفق عليها العميل والمتخصص في الصالون.

المبدأ هنا إن القرار القديم يحتفظ بسياقه. الكتالوج ممكن يتطور، لكن كلام العميل عن الزيارة يفضل واضح وقابل للفهم بعد التغيير.

// Illustrative contract, not extracted production source.
type ReferenceSnapshot = {
  imageId: string;
  imageUrl: string;
  title: string;
  credit?: string;
  note: string;
};

type ReferenceEdit =
  | { kind: "keep" }
  | { kind: "remove-all" }
  | { kind: "update-note"; imageId: string; note: string };

function applyReferenceEdit(
  saved: ReferenceSnapshot[],
  edit: ReferenceEdit,
): ReferenceSnapshot[] {
  if (edit.kind === "keep") return saved;
  if (edit.kind === "remove-all") return [];

  // Editing a note preserves the original image and credit.
  return saved.map(reference =>
    reference.imageId === edit.imageId
      ? { ...reference, note: edit.note }
      : reference,
  );
}

التحدي الخامس: ترتيب الصور ما يغيّرش إعداداتها

سيناريو توضيحي: صالون رفع تلات صور لنفس اللوك، وقرر يخفي صورة، وينسب صورة تانية لمتخصص، وبعدها غيّر ترتيب الصور.

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

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

نسبة الشغل لمتخصص اختيارية. وفي عارض الصور، الاسم المعروض بيتغير مع الصورة المحددة. ده بيخلي المعلومة مرتبطة بالعمل اللي العميل بيشوفه فعلًا.

واجهة فعلية ببيانات اختبار افتراضية من 17 أكتوبر. صورة الاختبار مش ادعاء إنها شغل صالون حقيقي.

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

التوافق هنا قرار منتج وهندسة مع بعض: المستخدم القديم يفضل قادر يقرأ المحتوى، والمستخدم الأحدث يستفيد من تحكم أدق في العرض.

التحدي السادس: مكتبة صور مفيدة من غير اختراع معلومات

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

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

تجربة البحث نفسها فيها تفاصيل مهمة: تصنيفات مناسبة، وكلمات بحث مرتبطة بيها، وإرسال واضح للبحث، وصفحات نتايج مع إزالة التكرار، وفلاتر موجودة في الرابط، واسترجاع الحالة عند الرجوع بالمتصفح.

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

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

حافظنا كمان على الصيغة الأصلية للصورة. افتراض إن كل رابط لازم ينتهي بـ JPEG ممكن يكسر صورة مصدرها PNG. اختيار مقاسات مناسبة للكروت والتفاصيل بيكمل نفس سلسلة التعامل مع الوسائط.

لقطة موجودة لصور مزود الإلهام. نتائج البحث مش توصيات علاجية أو ضمان لنتيجة خدمة.

التحدي السابع: العربي والثيم جزء من سلوك المنتج

دعم العربي بيتعدى ترجمة الجملة. ترتيب القراءة، ومحاذاة المحتوى، واتجاه الحركة، وظهور الأرقام وأسماء البراندات، وطول التعليمات، كلها بتأثر على فهم الواجهة.

استخدمنا Cairo للعربي وManrope للإنجليزي ضمن الهوية الحالية. اللون الداكن والدرجات المحايدة واللمسات اللايم موجودة في الأسطح المختلفة، ومعاها وضع فاتح له تباين وأدوار ألوان واضحة.

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

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

نفس واجهة الديمو في نسختين من نفس جلسة التصوير الموجودة. الاختلاف في المظهر، مش في حقيقة بيانات المنتج.

إيه اللي اتعمل مخصوص لطريقة شغل الصالونات؟

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

واجهة تشغيل ببيانات توضيحية. الأسماء والمواعيد الظاهرة مش دليل على حجم استخدام فعلي.

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

تطور التنفيذ حسب التاريخ الموجود فعلًا

راجعنا تاريخ Git المتاح كله، مش الفرع الحالي بس. لقينا تسجيلات عامة في البداية، وشغل مدفوعات أكثر تفصيلًا في تاريخ فروع تانية. وفيه شغل أحدث كتير موجود في مساحة العمل ولسه مش متسجل في commits جديدة.

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

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

مشاكل موثقة اتعاملنا معاها

صور موجودة عند المصدر لكنها مش بتظهر في الموقع. التقرير بيوضح إن أصل الصورة كان بيرجع بشكل صحيح، لكن مسار معالجة الصور في الويب كان بيرفض مصدرها، وجزء تجهيز بيانات الصفحة كان بيستبعدها. وحّدنا التعامل مع المصدر بين المسارين، واتراجع تحميل الصور في الصفحات الفعلية. الدرس إن فحص الصورة الأصلية لوحدها ما يكفيش؛ لازم تراجع سلسلة تجهيزها وعرضها.

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

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

دي مشاكل لها تقارير. أمثلة العميلين على نفس المعاد والصورة اللي مصدرها توقف، مواقف شرح مبنية على الكود، مش حكايات منسوبة لعملاء حقيقيين.

اختبرنا إيه، وكل دليل معناه إيه؟

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

تقرير معرض الأعمال بتاريخ 17 أكتوبر سجل 59 اختبار ويب مركز في تسع ملفات، وفحوص TypeScript للويب على 25 جزء، ورحلات واجهة محلية ومنشورة. وسجل للموبايل 218 اختبار في 43 ملف، وتصديرات، ودليل تثبيت وفتح إصدار Android التجريبي رقم 6 على محاكي.

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

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

الأدلة المتاحة مش بتثبت كل أنواع الأجهزة الفعلية، ولا كل نتائج توصيل المزودين، ولا إصدار iOS منشور في المتجر، ولا أداء تحت حجم زيارات محدد. روابط تنزيل المتاجر في المادة اللي راجعناها لسه بتعرض Coming soon.

النتايج اللي نقدر نقولها بثقة

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

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

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

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

الطريق للمرحلة الجاية

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

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

أسئلة شائعة

إيه اللي يخلي Salony نظام مخصص للصالونات؟

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

ليه فيه تطبيق وموقع؟

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

هل الصورة المرجعية معناها نتيجة مضمونة؟

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

هل كل ميزة موجودة في الكود متاحة في النسخة الحالية؟

لا. لازم نبص على المسارات النشطة والإعدادات ودليل الإصدار. ملفات Premium والذكاء الاصطناعي وخطط المرحلة الجاية مش معناها إنها متاحة للعميل في V1.

الصور دي منين؟

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

عندك منتج فيه تشغيل معقد وتجربة محتاجة تبقى واضحة؟

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

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

اتكلم مع فريق Softworks عن منتجك · شوف Salony

---

المادة متراجعة على الكود والأدلة المتاحة في 18 أكتوبر 2026. المصادر والتحرير · دليل الصور · اختار نسخة تانية.