عن تولاتي
أدوات أقل تشتتًا، ومهام أوضح.
تولاتي مشروع عربي مستقل بُني لفكرة بسيطة: عندما تحتاج إلى إنجاز مهمة صغيرة على الويب، لا يفترض أن تضيع وقتك بين عشر صفحات متشابهة أو إعدادات لا تعرف لماذا وُضعت أصلًا. لذلك نجمع الوظائف المرتبطة بالمهمة نفسها داخل مساحة واحدة، ونحاول أن يكون كل زر ومعلومة في مكانها.
الموقع يجمع أدوات للصور وملفات PDF والنصوص والحسابات والملفات والمطورين، ومعها محتوى يشرح الاستخدام وحدود النتائج عندما يحتاج الأمر إلى شرح فعلي.
ما الذي يهمنا؟
الوضوح قبل كثرة المزايا.
الأداة يجب أن تُفهم قبل أن تُستخدم.
المهمة قبل الصفحة.
لا ننشئ صفحة جديدة لمجرد زيادة عدد الصفحات.
المعلومة في مكانها.
ما تحتاج لمعرفته يظهر قريبًا من الوظيفة التي تستخدمها.
لماذا بدأ المشروع؟
المشكلة لم تكن نقص الأدوات. كانت كثرتها بلا تنظيم.
محاولة ضغط صورة، تنظيف نص أو فحص ملف تبدو مهمة صغيرة. لكن التجربة على الويب كثيرًا ما تتحول إلى سلسلة مزعجة: صفحة للأداة، وصفحة أخرى لوظيفة مرتبطة بها، ونوافذ إضافية، ومصطلحات تقنية لا يحتاجها المستخدم أصلًا.
هنا جاءت فكرة تولاتي. بدل بناء عشر أدوات منفصلة تحت أسماء مختلفة، نرتب الوظائف بحسب المهمة التي تجمعها. أداة الصور مثلًا لا تحتاج أن تتجزأ بلا نهاية؛ الضغط وتغيير المقاس والتحويل بين الصيغ يمكن أن تعيش في واجهة واحدة. الفكرة نفسها نطبقها على بقية الأقسام كلما كان الجمع منطقيًا ولا يربك الاستخدام.
قاعدة نعود إليها دائمًا
إذا احتاج المستخدم إلى شرح طويل حتى يفهم أين يضغط، فالمشكلة غالبًا في تصميم الأداة لا في المستخدم.
لهذا نحاول تقليل الخطوات، تسمية الوظائف بأسمائها المباشرة، وإظهار الحدود المهمة قبل التنفيذ بدل إخفائها في صفحة تعليمات بعيدة.
داخل تولاتي
ستة مجالات، وكل مجال له وظيفة واضحة
لا نريد تصنيفات تحمل أسماء جميلة ثم تفتح على صفحات فارغة. كل قسم موجود لأنه يخدم نوعًا محددًا من المهام اليومية.
الصور
ضغط الصور، تغيير أبعادها والتحويل بين الصيغ الشائعة دون توزيع كل عملية على صفحة مستقلة.
وظائف عملية لملفات PDF مثل الدمج والتقسيم والضغط والتحويل عندما تكون متاحة داخل القسم.
النصوص
تنظيف النص، عد الكلمات والحروف، إزالة التكرار أو التشكيل وتنفيذ المعالجات التي تتكرر في العمل والدراسة.
الحاسبات
حاسبات تركز على نتيجة مفهومة ومدخلات محددة بدل شاشات مليئة بالمتغيرات التي لا يحتاجها أغلب الناس.
الملفات
فحص معلومات الملف والخصائص الأساسية المرتبطة به حتى تعرف ما تتعامل معه قبل تنفيذ أي عملية.
المطورون
أدوات صغيرة يحتاجها المطور باستمرار مثل JSON وBase64 وURL وUUID وTimestamp في مكان واحد.
قبل أن نضيف أداة
لا يبدأ العمل من زر «إنشاء صفحة».
نسأل أولًا عن المهمة نفسها: ما الذي يحاول الزائر إنجازه؟ ما المدخلات التي يحتاجها فعلًا؟ ما الأخطاء التي يمكن أن يقع فيها؟ بعدها يبدأ التصميم. هذه الخطوات الأربع تلخص الطريقة التي نحاول الالتزام بها.
تحديد الاستخدام الحقيقي
نبدأ بحالة استخدام واضحة، لا بعنوان جذاب. إن لم نستطع وصف المشكلة التي تحلها الأداة في جملة مفهومة، فالفكرة ليست جاهزة.
تقليل المدخلات
كل حقل إضافي يحتاج سببًا. المدخل الذي لا يغير النتيجة أو لا يساعد المستخدم لا مكان له لمجرد أن الواجهة تبدو «احترافية».
اختبار النتيجة والحالات المزعجة
القيمة الفارغة، الملف غير المدعوم، النص الطويل، الهاتف الصغير، والضغط المتكرر على الزر؛ هذه ليست تفاصيل هامشية. هي جزء من الأداة نفسها.
شرح ما يحتاج إلى شرح فقط
نضيف تعليمات عندما تمنع خطأً أو توضح حدًا مهمًا. لا ندفن الأداة تحت مقال طويل قبل أن يتمكن الزائر من استخدامها.
معايير الجودة
نفضّل أداة مفهومة على عشر خصائص لا يستخدمها أحد.
إضافة ميزة جديدة ليست هدفًا في حد ذاتها. أحيانًا يكون حذف خيار مربك تحسينًا أكبر من إضافة ثلاثة خيارات جديدة.
لغة مفهومة: نستخدم اسم الوظيفة الذي يعرفه الناس، ونشرح المصطلح التقني عندما لا يوجد بديل أوضح.
سرعة الوصول: الوظيفة الأساسية يجب أن تكون أمامك، لا مختبئة خلف خطوات لا تضيف شيئًا.
تصميم متجاوب: الأداة التي تعمل جيدًا على الحاسوب وتنهار على الهاتف لم تنتهِ بعد.
نتيجة قابلة للفهم: لا يكفي إظهار رقم أو ملف جديد؛ يجب أن يكون واضحًا ماذا حدث وما الذي تستطيع فعله بعد ذلك.
مراجعة مستمرة: المتصفحات والصيغ وطرق الاستخدام تتغير، لذلك لا نتعامل مع نشر الصفحة باعتباره نهاية العمل.
الشفافية أهم من المبالغة في الوعود
بعض النتائج التي تقدمها الحاسبات تقديرية بطبيعتها؛ الرقم الناتج يساعد على الفهم أو المقارنة، لكنه لا يتحول تلقائيًا إلى تشخيص طبي أو نصيحة مهنية. وعندما تتغير النتيجة بحسب بيانات المستخدم، نحاول إظهار المدخلات المؤثرة بوضوح.
الأمر نفسه ينطبق على الملفات. نوع الملف وحجمه والمتصفح والجهاز قد تؤثر في بعض العمليات. إذا كانت هناك صيغة غير مدعومة أو حد تقني معروف، الأفضل أن يظهر ذلك للمستخدم بدل أن تتركه يكتشفه بعد الفشل.
ولا ننشر أرقامًا أو مزاعم من عندنا داخل المقالات. عندما يحتاج الموضوع إلى معلومة خارجية قابلة للتحقق، يكون الاتجاه الصحيح هو الرجوع إلى المصدر الأصلي أو جهة موثوقة، ثم صياغة الشرح بما يخدم القارئ بدل نسخ النص كما هو.
المدونة والمحتوى
نكتب عندما تكون المعلومة امتدادًا للأداة، لا حشوًا حولها.
المدونة ليست مكانًا لإعادة تعريف أشياء يعرفها الجميع. نستخدمها لشرح سؤال عملي، مقارنة طريقة بأخرى، توضيح صيغة ملف، تفسير نتيجة حاسبة، أو مساعدة القارئ على تجنب خطأ شائع.
ونفصل قدر الإمكان بين الشرح وبين تنفيذ المهمة. من يريد الأداة يصل إليها مباشرة. ومن يحتاج التفاصيل يجدها في محتوى مستقل يمكن قراءته دون أن تتحول واجهة الأداة إلى جدار نصي.
سياسة تحرير بسيطة
• لا ننسخ المقالات من مواقع أخرى.
• لا نمدد النص لمجرد الوصول إلى عدد كلمات معين.
• نراجع المعلومة التي يمكن أن تتغير بدل التعامل معها كحقيقة ثابتة.
• نعدّل الشرح عندما نكتشف أن طريقة الاستخدام أو الأداة نفسها تغيرت.
المشروع مستمر
تولاتي ليس كتالوجًا مغلقًا.
الأدوات الحالية هي نقطة البداية. عندما نضيف وظيفة جديدة، نحاول أن يكون لها سبب واضح ومكان منطقي داخل الموقع. وعندما نجد أن جزءًا قديمًا أصبح أثقل من اللازم أو لم يعد مفيدًا، فالتعديل أو الحذف خيار طبيعي.
أفضل إشارة بالنسبة لنا ليست عدد الصفحات؛ بل أن يدخل الزائر، يفهم ما أمامه، ينجز مهمته، ويعرف حدود النتيجة التي حصل عليها.
آخر تحديث لهذه الصفحة: 18 سبتمبر 2026