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

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

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

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

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

تقدر تبدأ من نموذج المنتج، أو تدخل على المعمارية، أو تروح مباشرة لـحكايات التطوير الموثّقة.

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

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

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

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

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

الـ Page هي مكان الشغل الفعلي. الهوية، والترتيب، وعلاقة الصفحة بالصفحة الأم متخزنين بشكل relational. محتوى الملاحظة نفسه متخزّن في JSONB، عشان يقدر يشيل blocks مختلفة من غير ما شكل قاعدة البيانات يتغيّر مع كل أداة جديدة.

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

المهام والتقويم بيضيفوا عامل الوقت. المادة مش بس معلومات مطلوب نفهمها؛ أوقات بيبقى فيه تدريب أو تسليم لازم يتعمل. ربط الموعد بالمادة بيسهّل الانتقال من «أنا بذاكر إيه» لـ«إيه الخطوة الجاية».

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

في العرض التجريبي، نور طالب خيالي عنده مواد مختلفة. بيفتح Database Systems، ويلاقي ملاحظات المادة والمطلوب منه قريب. يدخل على شرح العلاقات بين Student وCourse وEnrollment، وبعد القراءة يجاوب سؤال صغير موجود في نفس الملاحظة.

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

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

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

Knownly متقسم لتطبيق Next.js للواجهة، وتطبيق Fastify للـ API. كل واحد ليه dependencies وlockfile وأوامر تشغيل منفصلة. طلبات المتصفح بتمرّ من طبقة API في تطبيق الويب لحد خدمات الـ backend.

جوا الـ backend، تنظيم الموديولات بيفصل routes عن services وعن repositories. الـ route بتتعامل مع الطلب، والـ service بتعبّر عن سلوك الميزة، والـ repository بتتعامل مع البيانات. الفصل ده بيساعدنا نعرف التغيير مكانه فين، ونراجع أثره على بقية الرحلة.

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

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

القائمة بتوصف النسخة اللي راجعناها. وجود مكتبة في المشروع مش لوحده دليل على سرعة أو قابلية توسع معينة. وحتى نجاح الـ build ما بيلغيش أهمية مراجعة توافق dependencies؛ التثبيت المحلي أظهر peer warnings، واتسجلت ضمن حدود التحقق.

استخدمنا BlockNote كأساس، وبنينا فوقه schema خاصة بأدوات المذاكرة. الـ quiz ليه أسئلة واختيارات وإجابة وشرح. الـ flashcards ليها سؤال وإجابة بتظهر وقت المراجعة. لوحة Kanban ليها أعمدة وكروت. كل نوع محتوى بيتفسّر ويتعرض من خلال renderer مناسب له.

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

وفي المقابل، جمعنا بعض الأدوات في مكان أنسب. الـ frontend الحالي بيعتبر مجموعة من أنواع الصفحات القديمة deprecated، وبيوجّه المستخدم إنه يضيف الأدوات جوّه الملاحظة. وجود اسم نوع قديم في constants مش معناه إنه لسه شاشة مستقلة مدعومة.

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

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

استخدام blocks بيدي كل جزء هوية وحدود. النص بيتعامل كنص. السؤال بيتعامل كسؤال. واللوحة البصرية ليها payload خاص بيها. الصفحة بتحتفظ بترتيب الأجزاء، وكل renderer مسؤول إنه يفهم البيانات اللي تخصه.

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

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

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

الـ autosave hook بيستنى ثانية بعد آخر تغيير متجدول، وبيحتفظ بأحدث محتوى لسه محتاج يتحفظ. كل جدولة ليها sequence. لما طلب يخلص، الكود بيتأكد إن النتيجة تخص الترتيب الحالي قبل ما يغيّر مؤشر الحفظ.

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

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

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

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

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

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

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

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

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

الرد بيتعرض تدريجيًا، وسجل المحادثة ليه مسار تخزين. في العرض المحلي، نفس رحلة الواجهة والـ API بتشتغل، لكن الرد جاي من stub مكتوب مسبقًا ومعلن إنه تجريبي. ده يسمح نراجع العرض والبث والحفظ من غير ما ندّعي جودة موديل حي.

الرد الظاهر scripted. شوف نفس التكوين بالوضع الداكن.

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

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

وفيه helper تاني للتوليد بيستخدم settled results، فيحتفظ بالصفحات الناجحة ويعمل fallback للصفحات اللي ما نجحتش. وجود الآليتين محتاج وصف دقيق؛ ما ينفعش نقول إن كل مسار توليد في المشروع شغال بنفس الخطوات بالضبط.

الدرس إن الفشل الجزئي محتاج مكان في نموذج المنتج. الـ spinner لوحده ما بيشرحش اللي حصل. حالة مفهومة مع خطوة تالية بتخلي المستخدم يعرف يكمل إزاي. ده تصميم لسلوك المنتج قبل ما يكون اختيار مكتبة queues.

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

تنفيذ Knownly بيعمل سجلات جديدة، وبيحتفظ بخريطة بين الـ IDs القديمة والجديدة. بعدها بيرجع علاقات الصفحات والمصادر، ويعيد ترتيب روابط مسار التعلّم باستخدام نفس الخريطة. الشغل ده بيتم داخل transaction.

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

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

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

البحث احتاج المعنى والكلمة الدقيقة مع بعض

في commit 87f6ace بتاريخ ٢٣ أغسطس ٢٠٢٦، اتضاف hybrid retrieval. التنفيذ بيجمع مرشحين من البحث الدلالي ومرشحين من البحث النصي في PostgreSQL، وبعدها بيرتب الاتحاد بينهم باستخدام reciprocal rank، ويطبّق فلترة قبل اختيار النتائج النهائية.

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

الـ fallback لازم يوصل للمحاولة اللي بعدها

في 7404a9c اتفعل الاستمرار بعد رفض موديل بديل في مسار RAG. وجود قائمة موديلات لوحده مش كفاية؛ منطق التحكم لازم يسمح بالانتقال للبديل التالي في الحالة المقصودة.

دي معالجة محددة لحالة فشل محددة. ما وسّعناش معناها لوعد إن النظام بيتعافى من كل مشكلة ممكن تحصل عند أي provider.

قبول الاقتراح كان ممكن يوقف إدخاله

في 36c65dd بتاريخ ٢٦ أغسطس، اتضاف guard في تغيير المحرر أثناء إدخال اقتراح autocomplete تدريجيًا. التغيير اللي بيحصل بسبب قبول الاقتراح كان محتاج يتعامل بشكل مختلف عن كتابة المستخدم العادية.

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

تفاصيل صغيرة حوالين الكتابة كان ليها وزن

Commit c192c97 أضاف مراعاة مفاتيح التعديل في الاختصارات، وعدّل التعامل مع علامة نهاية SSE، وحط حد لعدد عناصر cache الاقتراحات. دي تفاصيل بتأثر على استخدام متكرر جدًا: الكتابة وقبول الاقتراح.

الـ commit فيه اختبارات كمان، لكن ما شغّلناش اختبارات الفرع ده ضمن تحقق main. وجودها دليل على تاريخ التطوير، مش رقم نجاح نعرضه على إنه نتيجة الاختبار المحلي الحالي.

الـ backlinks لازم تحترم التحديد والعنوان

في 21376e4، الاقتراحات بتتوقف لو المستخدم محدد نص. وفي de63f80، عناوين المرشحين بتتظبط من ناحية المسافات، والعنوان الفاضي بيتشال. الأول بيحترم حالة تحرير لها معنى، والتاني بيحسّن قابلية قراءة الوجهة المقترحة.

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

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

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

المنتج فيه خمس اختيارات للشكل: light وdark وSolarized وNord وDracula. الصور الحالية بتوثّق شاشات مختارة في light وdark. وجود الاختيارات التانية ما يساويش إن كل مكوّن اتراجع بصريًا في كل وضع.

التقويم متعبّي ببيانات العرض. نسخة الوضع الداكن.

جهّزنا تشغيل محلي بخدمات PostgreSQL وRedis وتخزين متوافق مع S3. البيانات التجريبية فيها ٨ مواد، و٤٨ ملاحظة، و٤٠ مصدر، و٢٤ مهمة، و٢٤ حدث في التقويم، بالإضافة للمساحة الشخصية اللي التطبيق بيعملها.

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

التحقق شمل build للـ backend، وlint وproduction build للواجهة، وتطبيق migrations، واختبار رحلة API، ومراجعة من المتصفح. الرد التجريبي عدى من نفس مسار التطبيق واتخزن في قاعدة البيانات. وتعديل عادي في المحرر ظهر بعد إعادة التحميل.

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

Knownly بيجمع أنشطة التعلّم في نموذج واحد مترابط. المادة ليها مساحة. الملاحظة فيها شرح وتدريب. المصدر ليه هوية وحالة. المحادثة تقدر تفهم السياق الحالي. والمهمة ليها علاقة بالمادة وميعادها.

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

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

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

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

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

افصل مرونة المحتوى عن ثبات الهيكل. الـ blocks تقدر تتنوع، بينما هوية الصفحة وترتيبها وعلاقاتها تفضل واضحة.

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

هل Knownly نظام LMS كامل؟

النسخة اللي اتراجعت مساحة تعلّم. فيه أجزاء مهيأة لتكاملات LMS، لكن Canvas sync لسه scaffold. أسماء providers في schema ما تعتبرش دليل إن كل التكاملات شغالة.

هل البحث الدلالي والـ autocomplete موجودين في الصور؟

لأ. الصور من main، والبحث فيه مطابقات للعناوين. حكايات hybrid retrieval والـ autocomplete والـ backlinks متوثقة كعمل على فروع تطوير منفصلة.

هل أسئلة المراجعة والردود طالعة من AI حي؟

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

هل النسخة المصرية معناها إن التطبيق عربي؟

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

إيه المطلوب عشان نقول إن المنتج حسّن التعلّم؟

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

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

الخطوة الأساسية: احكي لفريق Softworks عن المنتج اللي بتبنيه.

للقراءة التقنية: راجع خريطة الأدلة والصور المصاحبة.

خريطة الأدلة · مكتبة الصور · النسخة الإنجليزية · النسخة المصرية بخفة دم