كل إطار مثالي: لماذا تُحكم الواجهة إطاراً بإطار

كل إطار مثالي

العبارة تأتي من وثائق Wayland: "كل إطار مثالي" هدف معلن لبروتوكول العرض، الذي يسعى إلى استعادة السيطرة من منظومات GPU المتزايدة التعقيد. وفي تدوينة نُشرت على tonsky.me يرى الكاتب أن المبدأ نفسه يجب أن ينطبق على واجهات المستخدم لا على مسار الرسوميات فحسب.

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

لماذا يهم منتصف الانتقال

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

ويعدد الكاتب ما يعنيه ذلك عملياً: لا ومضات بيضاء بين الشاشات، ولا محتوى محمّل جزئياً، ولا تغيّر في التخطيط أثناء تحميل البيانات، واتساق داخلي — فلا يجوز أن يقول جزء من الواجهة "يتوفر تحديث واحد" بينما يقول جزء آخر "جارٍ التحقق من التحديثات..." — وتحريكات دقيقة.

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

خلل تزامن صغير وشكوك كبيرة

الأمثلة من برامج يومية. في Safari يتحرك نص العنصر النائب من المركز بينما يُحرّك المؤشر من الموضع الأيسر، فيبدو المكوّنان غير متزامنين ويُطرح سؤال: هل صُمّما معاً أصلاً؟ وفي Photos، عند التبديل بين وضعَي Crop وAdjust، تستقر الصورة في مكانها فوراً بينما يتحرك إطار القص، ما يخلق انطباعاً زائفاً بأن شيئاً ما تغيّر قليلاً.

أما مثال YouTube فهو أبسط مهمة ممكنة: نقل مستطيل من موضع إلى آخر. ومع ذلك يصعب تفسير النتيجة. ويسمي الكاتب هذه الحالات "التقنية تفوّقت على المبرمج"، مشيراً إلى قيود في معمارية DOM. وأياً كان السبب، فالإطار ليس مثالياً.

تنتهي التدوينة بتحريك تكبير "غير مبرَّر" من تطبيق Preview وبطلب: انتبهوا لا إلى حالتَي البداية والنهاية فقط، بل إلى كل ما يجري بينهما.