منتج بالشراكة / دراسة حالة هندسيةكل مستند.حكاية مترابطة.
من الورق للملف، ومن أول مراجعة لآخر توقيع. بنينا DocuBex علشان سياق المستند يفضل معاه في كل خطوة.
افتح الحكاية24 دقيقة
Workspace / Overview
Records / Library
منتج من Softworks بالشراكة مع Binary Solutions وContalents.
- النطاق
- مستندات، توقيع وأرشيف
- التطبيقات
- Web + Windows
- مرحلة المنتج
- Controlled Beta
- آخر مراجعة
- ١٨ أكتوبر ٢٠٢٦
Next.js
React
TypeScript
PostgreSQL
Prisma
Electron
.NET
المستند في الشغل نادرًا ما بيقف عند خطوة واحدة. ورق بيتعمل له مسح ضوئي، وملف بيتسمّى ويتحط في مكانه، ومراجع بيحتاج يشوفه، وشخص تاني بيحتاج يوقّعه. وفي نفس الوقت، الأصل الورقي ممكن يفضل موجود في صندوق على رف داخل مخزن.
إحنا في Softworks بنينا DocuBex علشان الرحلة دي تفضل مترابطة. جمعنا إدارة المستندات الرقمية، والأرشيف الورقي، وطلبات التشغيل، والتوقيع من المتصفح، ومعالجة المستندات الاختيارية في منتج واحد. التحدي الهندسي كان إن كل جزء يفهم حالة الشغل بدقة، وإن المستخدم يعرف إيه اللي تم وإيه اللي لسه محتاج إجراء.
الدراسة دي بتشرح قرارات البناء والتفاصيل التقنية اللي ورا التجربة. الكلام مبني على الكود وسجل التعديلات لحد مراجعة ١٨ أكتوبر ٢٠٢٦، مع التمييز بين النسخة التجريبية والتعديلات المحلية الحديثة. السيناريوهات أمثلة توضيحية لسلوك موجود في التنفيذ، مش حكايات منسوبة لعملاء بعينهم. الصور لقطات تجريبية سابقة محفوظة من المشروع.
تفاصيل نطاق المشروع
| البند | التفاصيل |
|---|---|
| فريق التطوير | Softworks |
| المنتج | DocuBex |
| المشكلة الأساسية | ربط المستند الرقمي ومكان الأصل الورقي والخطوات المطلوبة عليهم |
| مساحات الشغل | مكتبة المستندات، معاينة PDF، استقبال الاسكانر، الأرشيف، Simple Sign وBexi |
| التطبيقات | تطبيق ويب متجاوب، Scanner Bridge على Windows، وتطبيق منفصل لإعداد التشغيل المحلي |
| التخصيص | هوية مساحة العمل، تنظيم الملفات، إعداد الأرشيف وتفضيلات المظهر |
| المرحلة | نسخة Beta للاستخدام والتقييم المتحكم فيه |
| التركيز الهندسي | حالة واضحة، معالجة قابلة للاستكمال، نتائج دقيقة وواجهة مناسبة لطبيعة المهمة |
الملف مجرد البداية.
فين الملف؟ مين عليه الدور؟ والأصل الورقي فين؟
بدأنا من دورة الشغل اللي حوالين المستند
حفظ الملف خطوة أساسية، لكن لوحدها مش كفاية. الشخص اللي بيشتغل على المستند محتاج يعرف نسخته، والجهة المرتبط بيها، ومكانه، ونتيجة معالجته، وهل فيه توقيع أو طلب لسه مستني إجراء.
خلّينا ناخد مثال توضيحي من المشتريات. اتفاقية ورقية وصلت لفريق العمليات. موظف عمل لها مسح ضوئي، ومراجع محتاج يرتب الصفحات ويربط الملف بالجهة المناسبة. بعد كده مدير يوقّع، والنسخة المكتملة ترجع للمكتبة، والأصل الورقي يفضل في الأرشيف. بعد فترة حد يطلب النسخة الموقعة ومكان الأصل.
لو كل خطوة في أداة مختلفة، الفريق بيضطر يربط القصة بنفسه. اسم الملف يتحول لطريقة لتحديد النسخة، وملف Excel يتحول لخريطة المخزن، والمحادثات تبقى وسيلة متابعة الطلبات. كل أداة ماسكة جزء، والمستخدم هو اللي بيكمل الفراغات.
في DocuBex، ادّينا كل مفهوم مكان واضح في نموذج البيانات. الملف ليه نسخ ونتائج معالجة. الصندوق ليه مكان في المخزن. الطلب بيوصف شغل مطلوب. مظروف التوقيع بيمثل رحلة توقيع محددة. ربطنا المفاهيم دي من غير ما نختصرهم في حالة واحدة مبهمة.
الفرق بيبان في مواقف يومية: النسخة الرقمية ممكن تكون جاهزة والأصل لسه بيتنقل. شخص ممكن يكون وقّع، لكن المظروف لسه مستني شخص تاني. نقل الملف ممكن يخلص، لكن استخراج النص لسه شغال. كل حالة محتاجة تفسير يناسبها.
صممنا كل مساحة حسب المهمة اللي بتتعمل فيها
مكتبة المستندات وظيفتها تسهّل البحث والتنظيم. عارض 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
المعمارية: كل طبقة ليها مسؤولية مفهومة
تطبيق الويب الأساسي مبني باستخدام Next.js App Router وReact وTypeScript. بيانات الشغل موجودة في PostgreSQL من خلال Prisma. الملفات نفسها موجودة في تخزين متوافق مع S3. المعالجة الطويلة ليها خدمات في الخلفية، علشان مدتها ما تبقاش هي مدة انتظار طلب المتصفح.
التقسيم ده بيحدد مين مسؤول عن إيه. المتصفح بيعبّر عن طلب المستخدم وبيعرض الحالة. خدمات التطبيق بتنسق العملية. قاعدة البيانات بتحتفظ بالحالة اللي لازم تفضل موجودة بعد إغلاق الصفحة. تخزين الملفات بيحتفظ بالنسخة الأصلية، وخدمات المعالجة بتنتج النص والمعاينات والنتائج المشتقة.
رسم توضيحي لمسؤوليات المنتج؛ التسميات هنا مش أسماء الحالات الداخلية في قاعدة البيانات.
أهمية الحالة المحفوظة بتظهر لما العملية تعدّي بين أكتر من جزء. المتصفح ممكن يتقفل، وخدمة المعالجة ممكن تعيد التشغيل، والخدمة الخارجية ممكن تخلص بعد انتهاء انتظار الطلب. علشان نكمل الشغل، محتاجين نعرف اللي حصل من مصدر ثابت، مش من ذاكرة شاشة كانت مفتوحة.
كمان احتفظنا بنواة مشتركة للتشغيل السحابي والتشغيل داخل بيئة العميل. اختلاف الخدمات المتاحة بيتعالج في طبقة اختيار مزودي الخدمة وإمكانيات النشر. تطبيق الاسكانر وتطبيق الإعداد المحلي منفصلين لأن مسؤولياتهم مختلفة عن صفحة ويب.
التقنيات اللي استخدمناها وليه
| التقنية | دورها في المنتج |
|---|---|
| Next.js 16.3.8 وReact 19 وTypeScript 5.8 | تطبيق الويب، التفاعل وتنظيم أنواع البيانات |
| Prisma 7.10 وPostgreSQL | العلاقات بين الملفات والنسخ والمهام والطلبات |
| تخزين متوافق مع S3 | الاحتفاظ بمحتوى الملفات بعيدًا عن سجلات قاعدة البيانات |
| Redis وBullMQ | توزيع مهام الخلفية في البيئات المجهزة ليهم |
| PDF.js وpdf-lib | عرض PDF والتعامل مع صفحاته وإنتاج المستند النهائي |
| Chandra/Datalab | استخراج محتوى المستندات حسب الإعداد المتاح |
| AI SDK 6 وOpenRouter وZod | المساعدة التفاعلية والمخرجات المنظمة |
| pgvector | تمثيل أجزاء المستندات للبحث الدلالي |
| Tailwind وRadix وTanStack Table وRecharts | مكونات الواجهة والجداول والرسوم |
| Electron و.NET 8 وNAPS2 SDK | تجربة Windows وربط أجهزة المسح الضوئي |
| Paymob | تكامل الدفع والتجديدات السحابية في السياق المصري |
| Vitest وPlaywright وأدوات Node للاختبار | التحقق من المنطق والتفاعل والرحلات |
إحنا ما بننسبش المكتبات دي لنفسنا. شغل Softworks هو تصميم نموذج المنتج، وبناء الخدمات والواجهات، وتنظيم التواصل والاستكمال بينهم. كمان إصدارات تطبيق الويب مش معناها إن كل تطبيق مساعد بيستخدم نفس سلسلة الأدوات.
اقرأ مصدر مخطط المنتج
flowchart RL
A[رفع من الويب أو الاسكانر] --> B[استقبال وتأكيد النقل]
B --> C[ملف ونسخ مرتبطة به]
C --> D[معاينة وحفظ في المكان المناسب]
C --> E[معالجة اختيارية في الخلفية]
E --> F[نص وبيانات وبحث]
D --> G[أرشيف ورقي وطلبات]
D --> H[Simple Sign]
H --> I[مستند مكتمل داخل مساحة العمل]نصمّم للي لسه ما خلصش.
نموذج توضيحي، مش رفع ملف فعلي.
- النقل
- الرد ما وصلشالحالة المعروضة
- اتأكدنا
المخزن ممكن يكون خلّص والرد ضاع. نحتفظ بالمحاولة ونراجع حالة المخزن قبل تكرار الشغل.
التحدي الأول: الملف وصل، لكن رسالة النجاح ما وصلتش
في المثال البسيط للرفع، الملف يا إما بيتنقل يا إما خلص. في التنفيذ الفعلي، فيه حالة تالتة لازم نفهمها: النتيجة مش مؤكدة لسه.
تخيّل إن آخر خطوة في رفع ملف على أجزاء نجحت عند التخزين، وبعدها الاتصال اتقطع قبل ما المتصفح يستقبل الرد. لو بدأنا من الأول، ممكن نكرر شغل خلص. ولو عرضنا فشل نهائي، ممكن نكون بنقول معلومة غلط. ولو حذفنا بيانات المحاولة، هنخسر الطريق اللي نقدر نعرف منه الحقيقة.
علشان كده، بنينا سجل محفوظ لمحاولة الرفع: الحجم المتوقع، وتقسيم الأجزاء، وحالة الإكمال. عند الاستكمال، النظام يقدر يقارن السجل باللي موجود فعليًا عند خدمة التخزين، ويحدد هل المستند اكتمل، ولا فيه أجزاء ناقصة، ولا خطوة معينة محتاجة إعادة محاولة.
حتى التنظيف له نفس المنطق. عدم تأكيد الحذف مش معناه إن الحذف تم. لازم المعلومات اللي تساعد على حسم الحالة تفضل موجودة لحد ما النتيجة تتحدد.
النتيجة للمستخدم هي استكمال له معنى، بدل ما كل انقطاع يتحول لمحاولة جديدة باسم جديد. وعلى مستوى الاختبار، نقدر نحاكي نجاح التخزين وبعده تعثر تحديث قاعدة البيانات، ونتأكد إن الاستكمال ما بيطلبش إكمال نفس العملية الخارجية مرة تانية.
لما نفس الملف يبقى مفتوح في تبويبين
حفظ تقدم الرفع في المتصفح مفيد، لكنه بيفتح سؤال تاني: مين اللي يكمل لو المستخدم فتح تبويبين؟ وإيه اللي يحصل لو تبويب قديم رجع بعد ما تبويب أحدث بدأ يستكمل؟
استخدمنا Web Locks لما تكون متاحة، ومعاها بديل بيعتمد على مدة امتلاك قابلة للتجديد في IndexedDB. لما التبويب يفقد امتلاك المهمة، بيوقف المحاولة بتاعته. كمان بنحتفظ بنتيجة الإكمال علشان حالة قديمة محفوظة ما تستبدلش نتيجة نجاح معروفة.
التنسيق بين التبويبات بيساعد التجربة، لكن النتيجة النهائية بتفضل مبنية على حالة العملية عند الخادم والتخزين. دي نقطة بتخلي استكمال الرفع مرن حتى لو المتصفح نفسه عنده قيود.
التحدي التاني: وجود PDF مش معناه إن النص جاهز
مستند ممكن يبدأ بصفحة فيها نص رقمي واضح، وباقي صفحاته صور ممسوحة. لو اعتبرنا أول نص لقيناه دليل إن المستند كله قابل للبحث، هنفوت محتوى مهم.
اتعاملنا مع استخراج النص باعتباره دورة شغل مستقلة. مهمة المعالجة ليها تقدم، ومحاولات، وأجزاء، ونتيجة واضحة. المسار يقدر يراجع تغطية النص على مستوى الصفحات، ويستخدم مزود الاستخراج المتاح لما ده يكون مطلوب. المستندات الطويلة ممكن تتقسم لوحدات عمل محدودة.
فيه كمان علاقة بين المهمة ونسخة المستند. لو نسخة أحدث وصلت أثناء معالجة النسخة القديمة، النتيجة القديمة ما ينفعش تتحط فوق الجديدة لمجرد إنها خلصت بعدها. التنفيذ بيراجع حالة المهمة الحالية قبل نشر نتيجتها.
بالتالي، إضافة Queue لوحدها مش حل كامل. لازم نحدد مين ماسك المهمة، وإمتى امتلاكه ينتهي، وإيه اللي يتكرر، وإمتى النتيجة تفضل مرتبطة بالنسخة الصحيحة.
المستخدم يختار عمق المعالجة المناسب
مش كل مستند محتاج ذكاء اصطناعي. فيه فرق بين حفظ الأصل، واستخراج النص، وتجهيز البحث، والإثراء الكامل. في صندوق استقبال الاسكانر، المستخدم يقدر يحفظ الأصل والمعالجة مقفولة.
الاختيار ده مهم تشغيليًا. استقبال المستندات يفضل مفيد حتى لو خدمة إضافية مش متاحة في البيئة الحالية. ولو مرحلة لاحقة تعثرت، ما نختصرش كل اللي حصل في كلمة «فشل» ونخفي إن الأصل أو النص بقى موجود.
الواجهة هنا لازم تجاوب على سؤال محدد: الملف وصل؟ النص جاهز؟ ولا فيه معالجة إضافية لسه شغالة؟ كل إجابة ليها دلالة مختلفة للمستخدم.
التحدي التالت: الصورة المصغرة محتاجة بيئة مناسبة
المعاينة المصغرة شكلها بسيط، لكن إنتاجها ممكن يعتمد على برنامج محلي لمعالجة PDF. الكود اللي يشتغل على جهاز المطور مش بالضرورة يشتغل بنفس الطريقة داخل خدمة استضافة.
سجل التعديلات فيه إصلاح واضح في يونيو ٢٠٢٦ لتجنب توليد الصور المصغرة داخل طلب الرفع في بيئة serverless، وتجاوز بديل Poppler غير المناسب للبيئة. التنفيذ الحالي فصل الشغل ده أكتر من خلال مهام وخدمات مخصصة للمعاينات.
الفكرة الهندسية إن ميزة مساعدة زي الصورة المصغرة ما توقفش استقبال الأصل بسبب اختلاف بيئة التنفيذ. كل مرحلة يبقى ليها حالتها وطريقة التعامل مع تعثرها.
لقطة سابقة لمستند اختبار واضح التسمية، بالمظهر الفاتح.
التحدي الرابع: الاسكانر جزء من رحلة أطول
ربط الاسكانر بيجمع بين تطبيق ويب، وجهاز فعلي، وتعريفات Windows، وملفات محلية، وتطبيق سطح مكتب. خروج الصفحة من الجهاز مش نهاية الشغل. المستخدم ممكن يحتاج يضيف PDF موجود، ويغيّر ترتيب الصفحات، ويعمل تدوير أو قص، ويفصل مستندات، وبعدين يحدد المكان اللي هيرفع له.
بنينا Scanner Bridge على Windows علشان يجمع الخطوات دي. Electron مسؤول عن تطبيق سطح المكتب، و.NET/NAPS2 مسؤول عن طبقة التعامل مع أجهزة المسح. تجهيز الصفحات منفصل عن النقل، علشان المراجعة تسبق إرسال المستند.
الواجهة الحالية فيها Scan وTransfers وDevices وSettings. مساحة Transfers بتجمع المستندات الجاهزة، واختيار المكان، وسجل النقل. Devices بتعرض الأجهزة ونتائج الفحص. Settings بتتعامل مع المظهر والتفضيلات المحلية المتاحة.
لقطة محفوظة من واجهة التطبيق الفعلية مع بيانات أجهزة تجريبية. الصورة بتشرح التصميم، مش إثبات تجربة جهاز اسكانر متصل.
متابعة الاتصال ما تعتمدش على ظهور النافذة
التعديلات المحلية الحديثة نقلت متابعة الاتصال للعملية الرئيسية في تطبيق سطح المكتب. نافذة العرض ممكن تبقى في الخلفية أو مؤقتاتها تتأخر؛ ده ما ينفعش لوحده يحدد هل التطبيق متصل ولا لأ.
تحديث سجل النقل له توقيت مستقل، مع الاحتفاظ بالاختيار والبيانات المفيدة أثناء الاسترجاع. وبعد تأكيد اكتمال النقل، حالة الاستكمال النشطة بتتقفل من غير ما ده يفرض حذف كل نسخة محلية محفوظة.
فصلنا هنا بين ثلاثة أسئلة: هل الاتصال موجود؟ هل المستند اتنقل؟ وهل النسخة المحلية المفروض تفضل؟ كل سؤال ليه إجابة وسلوك مختلف.
صندوق الاستقبال يحافظ على شغل المراجع
بعد النقل، صندوق الاستقبال في الويب بيجمع قائمة المستندات والمعاينة وبيانات الحفظ. المستخدم يراجع المستند ويحدد وجهته من نفس مساحة العمل.
التحديث الدوري بيجيب الجديد مع الحفاظ على المسودة. لو مجموعة فيها مستندات نجحت وأخرى تعثرت، النتيجة بتفضل واضحة لكل مستند. ولو الرد مش مؤكد، الواجهة بتحتفظ بالحالة المناسبة لحد ما تتراجع مع البيانات المسجلة.
الهدف إن التحديث ما يرجّعش المستخدم لنقطة البداية، وإنه يقدر يكمل الجزء اللي محتاج تدخل من غير ما يكرر اللي نجح.
// 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 موجود جوه منتج مستندات، وبالتالي قيمة الإجابة مرتبطة بقدرة المستخدم يرجع للسجل أو المصدر اللي بيوضحها. فقرة مكتوبة كويس لوحدها مش كفاية علشان تحدد مستند مطلوب أو خطوة ناقصة.
التنفيذ بيجمع البحث في بيانات المستندات مع البحث الدلالي، وأدوات للتعامل مع أسئلة عن الملفات والصناديق والطلبات والتوقيعات. النتائج ممكن تظهر في كروت ملفات أو جداول أو رسوم أو خطوط زمنية حسب السؤال. استخراج البيانات المنظمة بيعتمد على Schemas علشان الناتج يبقى قابل للاستخدام داخل التطبيق.
مثال دقيق هو الفرق بين «المستندات اللي أنا وقعتها» و«المستندات اللي توقيعها اكتمل». السؤال الأول عن مشاركة شخص. التاني عن حالة الرحلة كلها. لو الاتنين اتترجموا لنفس الفلتر، الإجابة ممكن تبقى غير مناسبة حتى لو الاستعلام اشتغل من غير خطأ.
الإجابة المتدفقة محتاجة اتساق
لو النموذج تعثر قبل ما يبدأ يطلع كلام، استخدام بديل ممكن يكون مناسب. لكن لو طلع جزء من الإجابة وبعدين تعثر، تبديل النموذج بصمت ممكن يركّب إجابتين مختلفتين في شكل إجابة واحدة.
مسار المحادثة بيحصر الانتقال للبديل في المرحلة اللي قبل أول جزء متدفق. ده قرار تقني صغير، لكنه بيحافظ على وضوح اللي المستخدم بيقرأه.
Bexi بيساعد في القراءة والشرح والمقارنة والتنقل. مش بيعدّل المستندات أو يوقّع بدل المستخدم. وتوفره بيعتمد على البيئة والخدمات المتاحة؛ وجود مزود محلي في المعمارية مش معناه إن كل تجربة Bexi متاحة من غير إنترنت.
الصورة بتعرض نقطة البداية، مش نتيجة إجابة أو قياس دقة نموذج.
التحدي السادس: مكان التوقيع على الشاشة مش هو إحداثيات PDF
المستخدم بيشوف صفحة ويحط عليها حقل توقيع. لكن الصفحة الظاهرة ممكن تكون معمولة لها rotation أو crop، ومقاس عرضها بيتغير مع zoom وحجم الشاشة. ملف PDF نفسه ممكن يكون ليه نقطة بداية ووحدة قياس مختلفين.
لو حفظنا المكان باستخدام بكسلات الشاشة بس، الحقل ممكن يظهر مظبوط في المحرر ويطلع في مكان مختلف داخل الملف النهائي.
علشان كده، بنينا تحويلات واضحة لهندسة الصفحة. التنفيذ بيتعامل مع MediaBox وCropBox، واتجاه الصفحة، وUserUnit. بيفصل بين مساحة العرض ومساحة PDF الأصلية، وبيستخدم نفس الفهم عند إنتاج الناتج.
تغيير حجم الحقل محتاج نفس الدقة. لما المستخدم يسحب الحافة اليمين، المتوقع إن الحافة المقابلة تفضل مكانها. حركة غير مقصودة للمستطيل كله بتخلي الضبط مرهق حتى لو الأرقام النهائية تبدو منطقية.
التفاصيل دي موجودة في تعديلات أكتوبر وفي اختبارات الإحداثيات. وبتوضح ليه اختبار المحرر لازم يكمله فحص الناتج نفسه: المطلوب مش مجرد شكل صحيح أثناء السحب، المطلوب مستند نهائي متوافق مع اختيار المستخدم.
نطاق واضح للتوقيع
تجربة التوقيع الحالية هي Simple Sign داخل المتصفح: تجهيز المستند، تحديد المستلمين، ترتيب الخطوات، وضع الحقول المدعومة ومتابعة الاكتمال. التسلسل أو التوازي بين المستلمين بيعبّر عن اختلاف حقيقي في طريقة الشغل.
تطبيق الاسكانر بيكمل دوره في الالتقاط والتجهيز والرفع. الفصل ده بيخلي كل تجربة مركزة في مهمتها، وبيمنع الخلط بين التنفيذ الحالي وأفكار تاريخية موجودة في ملفات قديمة.
صورة محفوظة من اختبار متصفح باستخدام اسم تجريبي.
سجلات رقمية. ونتايج على الأرض.
جرّب الفرق بين جزء من السجلات والقائمة الكاملة.
الصفحة الأولى مش كل المخزن. الخانات اللي حالتها مش معروفة ما ينفعش تظهر كأنها متاحة.
بيانات توضيحية؛ مش صورة للمخزون الحقيقي.
التحدي السابع: نقل الصندوق عملية بتغيّر أكتر من سجل
الأرشيف الورقي ليه قيود فعلية. الرف ليه سعة، والمكان ممكن يكون مشغول، والصندوق ممكن يتنقل، وفي نفس الوقت يكون فيه طلب مفتوح عليه.
بنينا علاقات واضحة بين المخزن والمنطقة والرف والصندوق. الملف الرقمي يقدر يفضل مرتبط بالسياق الورقي، والطلب يعبّر عن العملية المطلوبة زي الاسترجاع أو النقل.
وقت تغيير المكان، النظام بيراجع الحالة الحالية والسعة المتاحة. تحديث موقع الصندوق والبيانات المرتبطة بيه جزء من عملية شغل متماسكة. نجاح نقل شكل في الرسم مش كفاية لو باقي السجلات لسه بتقول المكان القديم.
نفس الفكرة موجودة في الطلبات. إكمال عملية مرتبطة بصندوق وتحديث حالة الطلب لازم يعبّروا عن نتيجة واحدة. استخدام المعاملات هنا بيحافظ على اتساق بيانات العمل اللي الواجهة بتعرضها.
المخزون الناقص ما ينفعش يتعرض كأنه كامل
تقسيم النتائج لصفحات مناسب للقوائم الطويلة، لكن شاشة إشغال الرفوف لازم تعرف هل معاها كل العناصر المطلوبة ولا جزء منها. لو قرينا أول صفحة بس، ممكن نعرض مساحة فاضية وهي مش فاضية.
بنينا قارئ مشترك للمخزون بيكمل الصفحات، ويتعامل مع التكرار، ويتأكد من وجود أو انتهاء النتائج داخل الحد المدعوم. لو البيانات الكاملة ما وصلتش، بيرجع حالة واضحة بدل قائمة ناقصة شكلها نهائي.
ده بيحافظ على فرق مهم: مفيش صناديق، ولا مش قادرين نحمل الصناديق؟ الإجابتان مختلفتان تمامًا لما المستخدم هيتصرف على أساسهما.
لقطة تجريبية سابقة بالمظهر الداكن. أسماء المواقع والصناديق بيانات اختبار.
التحدي الثامن: الشهر مش عدد أيام ثابت
الاشتراك الشهري محتاج حساب شهور تقويمية. إضافة مدة ثابتة مش دايمًا بتطلع بداية الفترة التالية بشكل مناسب. نهاية يناير مثال بسيط بيكشف المشكلة.
سجل سبتمبر فيه تعديل من التعامل المحلي المباشر مع التاريخ لحساب UTC مع ضبط اليوم على آخر يوم صالح في الشهر المستهدف. التنفيذ بينقل الحساب ليوم آمن قبل تغيير الشهر أو السنة، وبعدها بيرجع لليوم المناسب داخل الفترة الجديدة.
كده تاريخ غير موجود في فبراير ما يتسببش في تجاوز غير مقصود لشهر مارس. المنطق بقى واضح وقابل للاختبار عند نهاية الشهر وفي السنوات الكبيسة. ده وصف لحساب الفترة من التاريخ المقدم له، مش وعد إن يوم ٣١ هيفضل نقطة مرجعية ثابتة للأبد.
الفاتورة مرتبطة بفترة الاشتراك، فتكرار تشغيل مهمة التجديد ما يبقاش معناه إنشاء دورة تجارية جديدة. التحصيل نفسه خطوة منفصلة، مرتبطة بإعدادات مزود الخدمة واختيارات العميل المناسبة.
عدم وصول الرد محتاج مراجعة للنتيجة
التكامل مع خدمة خارجية ممكن يتعثر بعد إرسال العملية. عدم وصول رد مش دليل كافي إن العملية ما حصلتش. علشان كده، فيه فرق بين رفض مؤكد ونتيجة لسه غير معروفة، ومسار لمراجعة النتيجة بدل تكرارها تلقائيًا.
بالنسبة للمستخدم، ده معناه إن حالات الانتظار والنجاح والتعثر ليها معنى واضح. تكامل Paymob هنا بيشرح طريقة تنسيق الشغل الموجودة في التنفيذ، بينما اعتماد التشغيل الفعلي مع حساب التاجر يفضل مرحلة مستقلة.
لغة واحدة. وشغل مختلف.
أكتر من شاشة.
كل خطوة ليها أداتها. وكل الأدوات بتخدم نفس الرحلة.التخصيص اللي بنيناه مرتبط بطبيعة المؤسسة
التخصيص في DocuBex له أمثلة محددة: شعار وألوان واسم البوابة، تنظيم الجهات والمجلدات، بيانات المستندات، أنواع الصناديق، وسعة الرفوف. تفضيلات المستخدم بتضيف المظهر المناسب لطريقة قراءته.
المهم إن الإعدادات تفضل معبرة عن مفاهيم معروفة في الشغل. العميل ما يحتاجش نسخة منفصلة من الكود علشان ينظم مساحة العمل باسمه، وفي نفس الوقت ما نوصفش الإعدادات الموجودة كأنها منصة مفتوحة لتغيير أي شيء بلا حدود.
| الاحتياج | التخصيص الموجود |
|---|---|
| مساحة عمل بهوية المؤسسة | الشعار والألوان واسم البوابة |
| تنظيم المستندات حسب الشغل | جهات ومجلدات ونسخ وبيانات مرتبطة |
| أرشيف له توزيع فعلي | مخازن ومناطق ورفوف وأنواع صناديق |
| استقبال بدون معالجة إضافية | حفظ الأصل أو اختيار مستوى المعالجة |
| بيئة تشغيل مختلفة | إعداد سحابي أو داخل بيئة العميل |
| راحة القراءة | مظهر فاتح أو داكن أو حسب النظام |
| استخدام من شاشة أصغر | واجهات ويب متجاوبة للرحلات المدعومة |
المظهر الداكن محتاج نظام ألوان له معنى
تغيير الخلفية للون غامق مش كفاية. النص الثانوي، وحدود الحقول، والقوائم، وحالات النجاح والتعثر، وتسميات الرسوم كلها لازم تفضل مقروءة ومفهومة.
استخدمنا Semantic Tokens: متغيرات بتعبّر عن دور اللون، زي سطح أو نص أو حدود أو حالة. التعديلات المحلية الحديثة وسعت استخدام النظام ده عبر صفحات ولوحات وقوائم مختلفة. زر تغيير المظهر مرتبط بتفضيل الحساب، وبيعرض انتظار الحفظ ويرجع للقيمة المؤكدة لو الحفظ تعثر.
أما المستند نفسه، فبيحتفظ بشكله. الورقة تفضل ورقة، والتوقيع يفضل بلون الحبر المقصود. المظهر بيتغير حوالين المحتوى، من غير ما يبدل معنى الصورة أو المستند اللي المستخدم بيراجعه.
اللقطة أحدث من صورة المكتبة الفاتحة، ومحتواها مختلف. الصورتان أمثلة محفوظة للمظهرين، مش مقارنة متزامنة لنفس الحالة.
الشاشة الصغيرة بتغيّر ترتيب التفاعل
في الكمبيوتر، ثلاث مناطق جنب بعض ممكن تساعد المراجع: القائمة والمعاينة وبيانات الحفظ. على الموبايل، ضغط نفس المناطق جنب بعض هيصغّر المستند ويصعّب استخدام الحقول.
التصميم المتجاوب بيقسم المهمة لخطوات مناسبة للمساحة: اختيار المستند، مراجعته، وحفظه. العلاقة بينهم تفضل واضحة، مع مراعاة الأسماء الطويلة وأماكن الأزرار والتنقل.
كمان فرّقنا بين دعم محتوى بلغتين وبين ترجمة واجهة التطبيق. الاختبارات المحفوظة فيها مستندات وأسماء عربية، لكن واجهات كتير لسه بالإنجليزي. النسخة المصرية من الدراسة دي محتوى تحريري موجه للقارئ المصري، مش دليل إن التطبيق كله اتعرّب.
المستند التجريبي محتفظ بخلفيته الورقية داخل مساحة القراءة الداكنة.
الفرق في التفاصيل.
إيه اللي نقدر نقوله من سجل التعديلات
راجعنا التعديلات نفسها، مش عناوين الـ commits بس. بعض اللقطات بتجمع شغل كبير، فبنستخدمها كنقاط موثقة في تطور التنفيذ، من غير ما نخترع حكاية يومية عن اجتماعات أو مواقف ما عندناش دليل عليها.
| التاريخ | المرجع | التعديل ودلالته |
|---|---|---|
| ٢٨ مايو ٢٠٢٦ | 820072ed | طبقة اختيار مزودي الخدمة علشان اختلاف بيئة التشغيل يبقى واضح |
| ٢٣ يونيو ٢٠٢٦ | 9693575e | فصل توليد المعاينة غير المناسب عن طلب الرفع في الاستضافة |
| ٢٠ أغسطس ٢٠٢٦ | 4a801eb5 | تنسيق استكمال الرفع بين التبويبات وأساس معالجة قابلة للاستكمال |
| ٢٩ سبتمبر ٢٠٢٦ | 0a1d2d83 | حساب الفترات بالتقويم وUTC مع ضبط نهاية الشهر |
| ١٤ أكتوبر ٢٠٢٦ | bdf85a42 | هندسة صفحات PDF، اكتمال قراءة المخزون وتحسينات الاسترجاع |
| العمل المحلي الحالي | غير مسجل في commit وقت المراجعة | متابعة اتصال الاسكانر، استرجاع صندوق الاستقبال وتحسينات المظهر |
النمط المشترك هو تحويل الافتراض لحالة صريحة. بدل ما نفترض إن الرفع خلص، فيه سجل نتيجة. بدل ما نفترض إن القائمة كاملة، فيه تحقق من استمرار الصفحات. وبدل ما نفترض إن إحداثيات الشاشة هي إحداثيات الملف، فيه تحويل هندسي واضح.
مثال متكامل من أول الاسكانر لحد الرجوع للأرشيف
المثال التالي توضيحي لطريقة اتصال الأجزاء ببعض:
- موظف يستورد صفحات أو يمسحها في Scanner Bridge، ويراجع ترتيبها ويجهز PDF.
- المستند يتنقل لمساحة العمل، وتتحدد نتيجة النقل بشكل مستقل عن معالجة النص.
- المراجع يفتح صندوق الاستقبال، يشوف الصفحات ويحدد الجهة أو المكان المرتبط بيها.
- لو المعالجة مطلوبة ومتاحة، تبدأ مهمة الخلفية. ولو المطلوب حفظ الأصل فقط، الحفظ يفضل مسار كامل ومفيد.
- زميل يلاقي المستند في المكتبة أو يستخدم Bexi للوصول للسياق المناسب، ويراجع السجل نفسه.
- المرسل يجهز رحلة Simple Sign بالمستلمين والحقول المدعومة والترتيب المناسب.
- كل مستلم يكمل خطوته في المتصفح، والمستند المكتمل يقدر يرجع لمساحة المستندات.
- الأصل الورقي يفضل مرتبط بصندوقه ومكانه، علشان طلب الاسترجاع بعد كده ما يبدأش من الصفر.
القيمة هنا في اتصال المسؤوليات. المثال مش ادعاء إن عميل بعينه نفذه أو حقق منه نسبة توفير محددة.
التحقق اتبنى حوالين السلوك اللي لازم يفضل صحيح
الحسابات المحددة زي نهاية الشهر وتحويل الإحداثيات وتقسيم صفحات المخزون محتاجة اختبارات مركزة. حفظ المسودات والنتائج الجزئية وتغيير المظهر محتاجين اختبارات تفاعل. رحلة التوقيع محتاجة اختبار متصفح وفحص PDF الناتج. أجهزة الاسكانر والخدمات الخارجية محتاجة تحقق في بيئتها الفعلية.
في المشروع تقارير سابقة بتوثق رحلات محلية ومراجعات بصرية على الكمبيوتر والتابلت والموبايل. وفي شغل الاسكانر فيه مراجعة محفوظة لنقل PDF تجريبي، وبعدها مراجعة لحفظ المستندات من صندوق الاستقبال. كل تقرير مرتبط بنسخته وتاريخه؛ ما جمعناش النتائج المختلفة وكأنها اعتماد جديد للمنتج كله.
إعداد الدراسة دي اعتمد على قراءة الكود والتعديلات، وتحديث الوثائق، وفحص الصور الموجودة وحفظ مصدرها. التطبيق ما اتشغّلش علشان الدراسة، وما اتعملتش لقطات جديدة.
النتيجة اللي نقدر نعرضها بدقة
اللي اتبنى هو تنفيذ مترابط لإدارة الملفات ونسخها، واستقبال قابل للاستكمال، ومعالجة اختيارية، وربط Windows بالاسكانر، وتوقيع من المتصفح، وأرشيف ورقي، وواجهة مشتركة متجاوبة.
النتائج الأقوى هنا سلوكية ومحددة: التحديث يقدر يحافظ على المسودة. المخزون الناقص يظهر ناقص. مكان التوقيع يتحسب من هندسة المستند. فترة شهرية تطلع بتاريخ صالح. ومهمة قديمة ما تنشرش فوق نسخة أحدث لمجرد إنها انتهت متأخر.
دي نتائج هندسية مهمة، لكنها مش بديل عن قياس أثر الاستخدام عند عميل. علشان كده، ما أضفناش أرقام توفير وقت أو تكلفة أو نسب أداء من غير بيانات. القياس الفعلي ممكن يركز على اكتمال المستندات، والوقت لأول نتيجة مفيدة، وتعثر المعالجة وحجم طلبات المساعدة.
الدروس اللي المشروع بيأكدها
وضوح النتيجة جزء من جودة المنتج. الحالة غير المؤكدة محتاجة اسم وطريقة متابعة، مش رسالة عامة تدفع المستخدم يكرر العملية.
الحاجات اللي بتخلص في أوقات مختلفة محتاجة نماذج منفصلة. الملف والمعالجة والتوقيع ونقل الأصل الورقي مرتبطين، لكن مش نفس العملية.
الاستكمال جزء من المسار الأساسي. الحفاظ على اللي المستخدم كتبه، ومعرفة اللي نجح، وإعادة محاولة الجزء المتعثر، كلها تفاصيل بتحدد هل المنتج عملي وقت الانقطاع.
الناتج أهم من الانطباع. محرر التوقيع لازم يطلع PDF مطابق، وشاشة الرف لازم تعرض بيانات كافية لاتخاذ قرار.
الاتساق ما يمنعش اختلاف التكوين. نقدر نستخدم لغة بصرية واحدة، ونصمم كل مساحة حسب مهمتها.
من workflow واضح لمنتج قابل للاستخدام
DocuBex بيوضح نوع الشغل اللي بنقدمه في Softworks: نفهم العمليات المترابطة، ونحوّلها لنموذج بيانات وخدمات خلفية وواجهات متفقة على معنى الحالة والنتيجة.
لو عندك مشروع مشابه، البداية المفيدة هي رحلة حقيقية للمستند: بييجي منين، ومين بيشتغل عليه، وإيه الأنظمة اللي بيعدّي عليها، وإيه اللي ممكن يتعطل، وإزاي نعرف إن الشغل اكتمل. الإجابات دي بتحدد نطاق عملي ومعمارية قابلة للتقييم ومعايير قبول واضحة.
ناقش رحلة المستندات عندك مع فريق Softworks. التفاصيل اللي بتضيع بين خطوة والتانية غالبًا هي المكان اللي يستحق يبدأ منه التطوير.
اقرأ كمان: النسخة الإنجليزية · النسخة المصرية بروح خفيفة
من جوه المنتج
الشغل، من كل زاوية.
١٤ لقطة محفوظة للويب والاسكانر والموبايل. الصور الفاتحة والداكنة حالات تاريخية مختلفة؛ صور الاسكانر بتستخدم بيانات أجهزة تجريبية.
لقطات عرض واختبار محفوظة. اختار صورة وافتحها بالحجم الكامل.
14 شاشة
Webنظرة على مساحة العمل
نظرة على مساحة العمل. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
Webمكتبة المستندات · فاتح
مكتبة المستندات · فاتح. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
Webمكتبة المستندات · داكن
مكتبة المستندات · داكن. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
Webمساحة مراجعة PDF
مساحة مراجعة PDF. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
Webصندوق استقبال الاسكانر
صندوق استقبال الاسكانر. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
موبايلالمراجعة من الموبايل
المراجعة من الموبايل. لقطة عرض أو اختبار محفوظة من أكتوبر ٢٠٢٦؛ ليست قياسًا لنتائج العملاء.
