Skip to content
Softworks
Softworks
hi@softworks.studio
Instagram LinkedIn
DocuBexمنتج بالشراكة / دراسة حالة هندسية

المستند وصل.والحكاية لسه مكملة.

من الورق للملف، ومن أول مراجعة لآخر توقيع. بنينا DocuBex علشان سياق المستند يفضل معاه في كل خطوة.

افتح الحكاية21 دقيقة
Softworks / DocuBexمن الورق لمساحة العمل
نظرة عامة فعلية على DocuBex، بمظهر داكن وبيانات اختبارWorkspace / Overview
مكتبة مستندات DocuBex الفعلية، بمظهر فاتح وبيانات اختبارRecords / Library
Capture. Review. Keep the context.
شاشات تجريبية · تصوّر للأجهزة
الشراكة

منتج من Softworks بالشراكة مع Binary Solutions وContalents.

النطاق
مستندات، توقيع وأرشيف
التطبيقات
Web + Windows
مرحلة المنتج
Controlled Beta
آخر مراجعة
١٨ أكتوبر ٢٠٢٦
  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Prisma
  • Electron
  • .NET
التقنيات ودورها

في أي شغل فيه مستندات، غالبًا هتقابل ملف اسمه «نهائي». وبعده «نهائي بجد». وبعده «نهائي بعد التعديل». الاسم متفائل، لكن دورة الشغل لسه عندها رأي تاني.

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

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

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

الشغل اللي حوالين الملف

الملف مجرد البداية.

سؤال التصميم

فين الملف؟ مين عليه الدور؟ والأصل الورقي فين؟

البداية كانت مستند… وبعد كده الموضوع اتفتح

فاصل ثقافي صغير: «الموضوع تطور» — إشارة قصيرة لميم مفهرس ضمن واد سيد الشغال في Arabic Memes. مرجع الصورة.

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

لو ما سمّيناش الأسئلة دي صح، هتتجمع كلها في حقل اسمه status، وبعدها نحاول نخمن معناه من لون الـ badge. ودي بداية مشروع ترجمة بين البشر والواجهة طول اليوم.

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

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

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

كل شاشة ليها شغلانة، مش كل شاشة محتاجة أربع كروت

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

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

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

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

النظام المترابط

رحلة واحدة. مسؤوليات واضحة.

خريطة المنتج

اختار مرحلة واستكشف مسؤوليتها.

مسارات مترابطة، لكل واحد حالته
الملف ونسخته

سجلات دائمة بتوصف الملف ونسخه. مخزن الملفات بيحتفظ بالمحتوى نفسه.

  • PostgreSQL
  • Prisma

المعالجة اختيارية، والتوقيع والأرشيف مسارات منفصلة.

الهندسة / الأدوات

كل أداة ليها شغلانة.

طبقات واضحة، من أول ورقة للحالة المحفوظة.

مساحة العمل

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

  • Next.js
  • React
  • TypeScript

Next.js App Router · React 19 · أنواع مشتركة

السجل الدائم

النسخ والشغل القابل للاستكمال بيحتفظوا بحالتهم بين العمليات.

  • PostgreSQL
  • Prisma
  • Redis

مخزن متوافق مع S3 · BullMQ حسب الإعداد · pgvector

فهم المستند

عرض المستند، استخراج اختياري، ومساعدة بنتائج منظمة.

  • OpenRouter
  • Zod

PDF.js · pdf-lib · AI SDK · استخراج Chandra / Datalab حسب الإعداد

جسر Windows

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

  • Electron
  • .NET

واجهة Electron · .NET 8 · NAPS2 SDK

الواجهة والاختبارات
  • Tailwind CSS
  • Radix
  • TanStack Table
  • Vitest

المعمارية: مين بيعمل إيه، ومين فاكر اللي حصل؟

«أنا راجل مهندس» — إشارة ثقافية قصيرة، مفهرسة في دهليز ضمن السفارة في العمارة. وبعد الفاصل ده، لازم فعلًا نشرح الهندسة.

تطبيق الويب الأساسي Next.js وReact وTypeScript. PostgreSQL وPrisma بيمسكوا بيانات الشغل. تخزين متوافق مع S3 بيمسك محتوى الملفات. خدمات الخلفية بتمسك المعالجة اللي مدتها أطول من إننا نفضل رابطينها بطلب متصفح.

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

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

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

قائمة الأدوات، بس كل أداة معاها شغلانتها

الأداةبتساعدنا في إيه؟
Next.js 16.3.8 وReact 19 وTypeScript 5.8الويب والتفاعل وأنواع البيانات
PostgreSQL وPrisma 7.10علاقات الملفات والنسخ والطلبات والمهام
S3-compatible storageمحتوى المستندات
Redis وBullMQتوزيع مهام المعالجة في البيئات المجهزة
PDF.js وpdf-libعرض PDF والتعامل مع هندسته والناتج
Chandra/Datalabاستخراج المحتوى حسب الإعداد
AI SDK وOpenRouter وZod وpgvectorالمحادثة، المخرجات المنظمة والبحث الدلالي
Electron و.NET/NAPS2سطح المكتب وربط الاسكانر
Tailwind وRadix والجداول والرسومواجهة عملية ومتسقة
Paymobتكامل الدفع السحابي
Vitest وPlaywright وNode testsاختبارات المنطق والتفاعل والرحلات

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

اقرأ مصدر مخطط المنتج
document-journey.mermaid
flowchart RL
  A[المستند وصل] --> B[نقل وتأكيد]
  B --> C[ملف ونسخة]
  C --> D[مراجعة وحفظ]
  C --> E[معالجة اختيارية]
  E --> F[نص وبيانات وبحث]
  D --> G[توقيع أو طلب أو أرشفة]
الاستقبال والاستكمال

نصمّم للي لسه ما خلصش.

جرّب حالات الرفع

نموذج توضيحي، مش رفع ملف فعلي.

المتصفحagreement.pdfمستند توضيحي
مخزن الملفاتممكن يكون اكتملغير مؤكّد
  1. النقل
  2. الرد ما وصلشالحالة المعروضة
  3. اتأكدنا
غياب الرد مش معناه فشل الرفع.

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

راجع حالة المحاولة

الرفع وصل ١٠٠٪… بس ده مش آخر المشهد

شريط التقدم بيحكي عن نقل البيانات. تأكيد إن العملية كلها اكتملت حكاية تانية.

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

الرفع: أنا خلّصت.

الرد: أنا اتأخرت في السكة.

الهندسة: تمام، هنراجع الحالة بدل ما نعيد القصة.

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

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

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

تبويبين وملف واحد: اتفقوا مين اللي بيكمل

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

استخدمنا Web Locks لما تكون موجودة، وبديل في IndexedDB بمدة امتلاك قابلة للتجديد. التبويب اللي يفقد المهمة بيوقف محاولته. ونتيجة الإكمال بتتحفظ علشان تبويب قديم ما يرجعش يكتب فوق نجاح معروف.

اتنين فاتحين نفس الملف؟ عادي. اتنين فاكرين إنهم قائد نفس محاولة الرفع؟ هنا لازم ننظم الكلام.

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

OCR: الصفحة الأولى بتقرأ، والباقي عامل نفسه صورة

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

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

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

الـ worker القديم: عندي نتيجة.

النظام: ممتاز، بس النتيجة دي تبع أنهي نسخة؟

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

مش لازم كل ورقة تدخل جلسة ذكاء اصطناعي

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

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

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

صورة مصغرة، ومشكلة مش صغيرة

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

في يونيو ٢٠٢٦، سجل التعديلات بيورينا إصلاح لتجنب توليد المعاينات داخل طلب الرفع في serverless، وعدم الاعتماد على Poppler في مسار غير مدعوم. التنفيذ الحالي عنده مهام منفصلة للصور المصغرة.

الصورة صغيرة، لكن ده ما يديهاش حق توقف وصول المستند كله.

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

عارض المستندات في DocuBex مع معاينة PDF وأدوات التنقل

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

الاسكانر خلّص شغله… المستند لسه عنده مشوار

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

Scanner Bridge اتبنى علشان الرحلة دي. تطبيق Windows باستخدام Electron، ومعاه .NET/NAPS2 لطبقة أجهزة المسح. تجهيز المستند منفصل عن النقل، علشان «ارفع» تيجي بعد «راجع».

الواجهة الحالية بتقسم الشغل بين Scan وTransfers وDevices وSettings. كل مساحة ليها مسؤولية: صفحات وتجهيز، نقل وسجل، أجهزة وفحص، ثم تفضيلات.

واجهة Scanner Bridge الداكنة، مع اسم جهاز طويل ظاهر أسفل الاختيار

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

النافذة نايمة؟ الاتصال لسه له شغله

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

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

وبعد نجاح الرفع، بنفصل إنهاء حالة الاستكمال عن حذف الملفات المحلية. «المهمة خلصت» و«امسح كل حاجة» مش طلب واحد بالضرورة.

الـ Refresh المفروض يجيب الجديد، ويسيب اللي كتبته في حاله

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

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

ملفين نجحوا وواحد وقف؟ الاتنين يستاهلوا يعدّوا، والتالت ياخد فرصته في التصحيح.

الهدف إن المستخدم يكمل من آخر نقطة مفهومة، مش من أول القصة.

recovery.illustration.ts
// Explanatory model — not copied production code.
async function reconcileUpload(attemptId: string) {
  const attempt = await attempts.read(attemptId);
  const object = await storage.inspect(attempt.objectKey);

  if (matchesExpectedObject(object, attempt)) {
    // Recover the existing attempt; do not upload a duplicate.
    return attempts.confirmCompleted(attempt.id, object);
  }

  // Unknown is preserved until the outcome can be confirmed.
  return attempts.keepRecoverable(attempt.id);
}

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

الفهم والتوقيع

الإجابة. المصدر. التوقيع.

المساعدة ليها حدود.

استكشف دور المساعد ودور المستلم.

السياق بيتجه للمساعد. القرار بيفضل مع الناس.

Bexi بيقرأ ويشرح ويوصّل للمصدر المتاح. مش بيغيّر المستندات ومش بيوقّع بالنيابة عن حد.

  • OpenRouter
  • Zod

نموذج للمسؤوليات.

Bexi: الكلام حلو، والمصدر فين؟

إشارة ثقافية: «من قائل هذا البيت؟» — كما هي مفهرسة في Arabic Memes ضمن رمضان مبروك أبو العالمين حمودة. مرجع الصورة.

السؤال مناسب جدًا لمساعد جوه نظام مستندات، مع تغيير صغير: المعلومة دي جاية من أنهي سجل أو مستند؟

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

المخرجات المنظمة بتعدّي من Schemas. ده بيساعد التطبيق يتعامل مع حقول مفهومة بدل فقرة بنحاول نستخرج منها المعنى مرة تانية.

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

لو الإجابة وقفت في النص، ما نركّبش عليها إجابة تانية

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

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

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

شاشة بداية Bexi مع اقتراحات أسئلة عن المستندات

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

التوقيع مكانه هنا… «هنا» حسب أنهي إحداثيات؟

المستخدم يحط الحقل في مكانه، وإحنا لازم نطلعه في نفس المكان داخل PDF النهائي. الجملة سهلة لحد ما ندخل rotation وcrop وzoom ونقطة بداية مختلفة للصفحة.

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

التوقيع مش بيغير رأيه. التحويل بين الإحداثيات هو اللي محتاج يتظبط.

بنينا حساب واضح لهندسة الصفحة باستخدام MediaBox وCropBox وUserUnit واتجاه الصفحة. المكان اللي بيتعرض للمستخدم بيتحوّل للمكان المناسب في PDF. وعند إنتاج المستند، نفس المنطق بيكمل الرحلة.

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

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

Simple Sign هو نطاق التوقيع الحالي في المتصفح: مستند، مستلمين، حقول مدعومة، ترتيب أو توازي، ثم اكتمال. Scanner Bridge بيفضل في شغل الاسكانر والرفع.

واجهة رسم توقيع من شاشة موبايل داخل رحلة Simple Sign

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

بعد الشاشة

سجلات رقمية. ونتايج على الأرض.

قراية المخزون

جرّب الفرق بين جزء من السجلات والقائمة الكاملة.

رف توضيحي / A03 / 06 مرصود
A01مشغول
A02مشغول
A03متاح
A04?غير معروف
A05?غير معروف
A06?غير معروف
مشغولمتاحغير معروف
3 / 6خانات حالتها معروفةالمجهول مش مساحة فاضية.

الصفحة الأولى مش كل المخزن. الخانات اللي حالتها مش معروفة ما ينفعش تظهر كأنها متاحة.

بيانات توضيحية؛ مش صورة للمخزون الحقيقي.

الصندوق مش أيقونة نحرّكها وخلاص

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

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

وجود مكان في الرسم مش معناه وجود مكان على الرف.

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

استخدام المعاملات هنا مش كلمة تقنية نحطها في عرض. ده اللي بيخلّي واجهة العمليات تقول نتيجة واحدة مفهومة بدل نتيجتين متعارضتين.

أول صفحة من المخزون مش المخزون كله

لو الـ API بيقسم النتائج، وقرأنا أول صفحة بس، ممكن الواجهة تستنتج إن فيه مساحة متاحة وهي ما شافتش باقي الصناديق أصلًا.

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

الفرق بين «مفيش صناديق» و«مش قادرين نحمّل الصناديق» لازم يفضل موجود. المستخدم اللي هيبني قرار على الشاشة يستاهل يعرف الفرق.

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

صندوق تجريبي واحد علشان نشرح العلاقة. مش محتاجين نزود الرقم في الصورة علشان الفكرة تبان مهمة.

فبراير مش بيوافق على يوم ٣١ مهما حاولنا نقنعه

الاشتراك الشهري معناه شهر في التقويم، مش مدة ثابتة نضيفها ونمشي. نهاية يناير بتكشف الفرق من غير مقدمات.

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

التقويم مش بيغلط علشان يرخّم علينا. إحنا اللي لازم نسأله السؤال الصح.

الفترة بتتحسب من التاريخ الداخل للدالة. ما بندّعيش إن يوم ٣١ هيفضل مرساة ثابتة لكل الشهور الجاية. الدقة في وصف السلوك هنا مهمة قد الدقة في تنفيذه.

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

الخدمة ما ردتش؟ بلاش نستنتج إنها ما عملتش حاجة

في التكامل الخارجي، العملية ممكن تتنفذ والرد ما يوصلش. هنا لازم نميّز بين رفض مؤكد ونتيجة غير معروفة، ونراجع النتيجة بدل ما نكرر العملية تلقائيًا.

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

التكامل الحالي بيشرح تنسيق العمليات. اعتماد Paymob مع حساب التاجر والبيئة الفعلية موضوع له تحقق منفصل؛ قائمة الكود مش إيصال تشغيل حي.

مساحة بتتكيف مع الشغل

لغة واحدة. وشغل مختلف.

رسم أصلي للاسكانر والماسح وصندوق الأرشيف

أكتر من شاشة.

كل خطوة ليها أداتها. وكل الأدوات بتخدم نفس الرحلة.

التخصيص: المؤسسة تشوف شغلها، من غير نسخة كود لكل عميل

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

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

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

الهدف ندي مرونة مفهومة، مش نفتح خمسين إعدادًا يخلي كل شاشة محتاجة كتالوج لوحدها.

الوضع الداكن مش حفلة تنكّر للألوان

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

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

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

اللي غيّر مزاجه هو إطار التطبيق. المستند ملوش ذنب.

مكتبة DocuBex بالمظهر الداكن مع مستندات اختبار

لقطة داكنة حقيقية محفوظة. ما لوّناش صورة فاتحة علشان نعمل مقارنة شكلها حلو.

الموبايل مش كمبيوتر اتحط في الغسالة

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

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

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

مراجعة مستند عربي في صندوق استقبال الاسكانر من الموبايل

نفس نوع الشغل، بمساحة قراءة مناسبة للشاشة الصغيرة، ومن غير ما نغيّر شكل الورقة.

الدليل واللي اتعلّمناه

الفرق في التفاصيل.

والـ commits بتقول إيه بعيدًا عن الحكاية؟

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

التاريخالمرجعالحكاية الهندسية اللي يدعمها
مايو ٢٠٢٦820072edاختلاف مزودي الخدمة بين بيئات التشغيل
يونيو ٢٠٢٦9693575eالمعاينات لازم تناسب بيئة الاستضافة
أغسطس ٢٠٢٦4a801eb5استكمال الرفع وتنسيق التبويبات وأساس مهام المعالجة
سبتمبر ٢٠٢٦0a1d2d83نهاية الشهر محتاجة حساب تقويمي مضبوط
أكتوبر ٢٠٢٦bdf85a42هندسة PDF، اكتمال المخزون وتحسينات الاسترجاع
التعديلات المحلية وقت المراجعةغير مسجلة في commitاتصال الاسكانر وصندوق الاستقبال والمظهر

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

رحلة مستند من غير القفز على الخطوات

خلّينا نمشي مثال توضيحي كامل:

  1. ورق أو PDF يدخل Scanner Bridge، والموظف يرتب الصفحات ويراجعها.
  2. النقل يحصل، ونتيجته تتحدد من غير خلطها بمعالجة النص.
  3. المراجع يفتح صندوق الاستقبال، يشوف المستند ويختار مكانه.
  4. الأصل يتحفظ، والمعالجة الاختيارية تبدأ لو مطلوبة ومتاحة.
  5. المستند يبقى قابل للوصول من المكتبة، أو من سؤال مناسب لـ Bexi مع الرجوع للسجل.
  6. رحلة Simple Sign تتجهز بالمستلمين والحقول والترتيب.
  7. كل شخص يكمل دوره من المتصفح، والمستند المكتمل يرجع لمساحة العمل.
  8. الأصل الورقي يفضل مربوط بمكانه، علشان طلبه بعد فترة ما يبدأش بسؤال «هو راح فين؟».

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

الاختبار: الزر اشتغل، طيب الناتج عامل إيه؟

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

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

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

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

النتيجة من غير أرقام لابسة بدلة

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

وفيه سلوكيات محددة نقدر نشرحها: المسودة تفضل موجودة بعد التحديث. النتيجة غير المؤكدة تتراجع. القائمة الناقصة ما تتعرضش كأنها كاملة. التوقيع يتحسب من هندسة الصفحة. والتجديد يحترم عدد أيام الشهر.

ما أضفناش «وفرنا ٨٠٪» علشان الجملة شكلها قوي. من غير قياس فعلي، الرقم هيبقى ديكور. الأثر عند العميل محتاج متابعة استخدام حقيقية: مستندات مكتملة، وقت لأول نتيجة مفيدة، نسبة تعثر المعالجة وطلبات المساعدة.

الحاجات اللي هنفضل ناخدها معانا لأي مشروع

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

خلّي الاستكمال موجود من البداية. المستخدم مش المفروض يعيد اللي كتبه علشان خدمة اتأخرت.

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

راجع الناتج الحقيقي. مستند PDF وموضع صندوق أهم من إحساسنا إن الواجهة كانت شكلها تمام.

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

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

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

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

ناقش مشروعك مع فريق Softworks. وهات معاك «النسخة النهائية» عادي. إحنا متفاهمين إن ممكن يكون فيه واحدة بعدها.

عايز نفس التفاصيل بنبرة أهدى؟ اقرأ المصري المهني · Read the formal English edition

عندك رحلة مستندات معقّدة؟

هات الحكاية. ونبني اللي يربطها.

ابدأ مشروعك
DocuBexشوف كمان: Transito
Softworks

Softworks Studio