المشاكل الرئيسية لتطوير واجهات حديثة

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




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

أنا مقتنع أنه يمكنك بدء معرفتك "مباشرة من الخفافيش" وليس هناك حاجة لدراسة التكنولوجيا (المكدس التكنولوجي لتطوير الويب - مترجم تقريبًا) بترتيب معين. ولكني أعتقد أيضًا أن تراكم الخبرة والمهارات المهنية في المجال المختار له أهمية كبيرة. أنا شخصياً كنت مهتمًا دائمًا بإنشاء واجهات المستخدم.

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

---

اليوم ، هناك العديد من الطرق المختلفة لتعلم التكنولوجيا. أي مكتبة للمراهنة عليها في عام 2019؟ وفي 2020؟ يجب أن أتعلم Vue أو الرد؟ أو الزاوي؟ ماذا عن الإعادة أو آر إكس؟ هل أحتاج إلى تعلم أبولو؟ الراحة أو GraphQL؟ من السهل أن تضيع هنا! بالإضافة إلى ذلك ، قد يكون المؤلف أيضًا مخطئًا.

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

---

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

الاتساق

لقد أعجبك المنشور وظهر النقش: "أنت و 3 آخرون من أصدقائك قدروه". قمت بالنقر فوق الزر "أعجبني" مرة أخرى واختفت الكتابة. هذا يبدو سهلا! لكن من الممكن أن يكون هذا النقش موجودًا في عدة أماكن على الشاشة. من الممكن أن يكون هناك أيضًا مؤشر مرئي إضافي لما شابه (على سبيل المثال ، لون خلفية الزر) ، والذي يجب أن يتغير أيضًا. وقائمة "الإعجابات" ، التي تم تلقيها مسبقًا من الخادم وعرضها عند المرور بالماوس ، يجب أن تتضمن اسمك الآن. وإذا ذهبت إلى قسم آخر أو قمت بالنقر فوق الزر "السابق" ، فلا ينبغي للنشر أن "ينسى" أنه يشبهك. كما ترون ، حتى النزاهة المحلية لمستخدم واحد يخلق عددا من المهام الصعبة. في الوقت نفسه ، يمكن للمستخدمين الآخرين أيضًا التفاعل مع البيانات التي يتم عرضها عليك (على سبيل المثال ، مثل المنشور الذي تعرضه). كيف نحافظ على مزامنة البيانات في أجزاء مختلفة من الشاشة؟ كيف ومتى يجب علينا التحقق من البيانات المحلية مع الخادم وتلقي / إرسال التغييرات؟

استجابة

لا يسمح الأشخاص بنقص الملاحظات المرئية عن تصرفاتهم إلا لفترة محدودة للغاية. بالنسبة لإجراءات المستخدم المستمرة ، مثل التمرير ، يكون عدم وجود رد فعل للتطبيق ممكنًا لأقصر فترة. حتى تخطي إطار واحد في 16 مللي ثانية يبدو بالفعل عربات التي تجرها الدواب وغير مكتملة. بالنسبة إلى الإجراءات المنفصلة (لمرة واحدة) ، مثل النقرة ، وفقًا لبعض الدراسات ، يتصور المستخدمون عادة تأخيرات في استجابة أقل من 100 مللي ثانية. إذا استغرق الإجراء مزيدًا من الوقت ، فمن الضروري إظهار مؤشر مرئي. ومع ذلك ، هناك العديد من المهام المضادة للحدس. يمكن للمؤشرات التي تتسبب في حدوث تحول في قالب الصفحة أو التي تمر بعدة مراحل متناوبة أن تجعل الإجراء يستغرق وقتًا طويلاً حتى "يشعر" مما كان عليه بالفعل. وبالمثل ، فإن استجابة أحد التطبيقات خلال 20 مللي ثانية بتخطي إطار واحد من الرسوم المتحركة قد "تشعر" أبطأ من الرسوم المتحركة الكاملة في غضون 30 مللي ثانية. وعينا لا يعمل مثل المعايير. كيف نحافظ على استجابة التطبيقات؟

زمن الاستجابة (الكمون)

يستغرق حوسبة الكمبيوتر ونقل البيانات عبر الشبكة وقتًا. في بعض الأحيان ، يمكننا تجاهل وقت الحساب إذا لم يؤثر ذلك على الاستجابة على أجهزة المستخدمين (ومع ذلك ، تأكد من اختبار الشفرة على الأجهزة القديمة وأجهزة الميزانية). ومع ذلك ، لا يمكن تجنب معالجة وقت نقل البيانات عبر الشبكة - يمكن حسابه في ثوانٍ! لا يمكن للتطبيق "تعليق" ببساطة أثناء انتظار تحميل البيانات أو التعليمات البرمجية. هذا يعني أن أي إجراء يتطلب بيانات أو تعليمات برمجية أو أصول جديدة قد يكون غير متزامن ويجب أن يتعامل مع حالة تحميله. هذا صحيح بالنسبة للغالبية العظمى من الشاشات والعناصر. كيفية التعامل بشكل صحيح مع التأخير في نقل البيانات دون عرض سلسلة من المغازل الدوارة أو "الثقوب" الفارغة في الواجهة؟ كيفية تجنب التحولات تخطيط الصفحة؟ وكيف يمكن تغيير التبعيات غير المتزامنة دون الحاجة إلى إعادة كتابة الكود الثابت؟

الملاحة

نتوقع أن تكون الواجهة "مستقرة" عند التفاعل معها. لا ينبغي أن تختفي العناصر فجأة. يجب أيضًا الالتزام بهذا المبدأ داخل كلٍ من التطبيق (على سبيل المثال ، الروابط) والخارجية (على سبيل المثال ، زر الرجوع في المتصفح). على سبيل المثال ، يجب ألا يؤدي التبديل بين /profile/likes و /profile/follows علامات التبويب التالية في قسم المستخدم إلى إلغاء محتويات حقل البحث خارج هذا القسم. يجب أن يبدو التبديل إلى شاشة أخرى حتى المشي إلى غرفة أخرى. يتوقع الناس أنه عندما يعودون ، سيجدون كل الأشياء التي تركوها (وربما سيكونون سعداء ببعض الأشياء الجديدة). إذا كنت في منتصف الشريط الخاص بك ، نقرت على علامة التبويب ملف التعريف ، ثم عدت مرة أخرى إلى الشريط - فأنت بالتأكيد لا تريد إعادة التمرير الشريط من البداية أو الانتظار حتى يتم تحميل الحالة السابقة من الشريط. كيفية تصميم تطبيق للتعامل مع التنقل التعسفي للمستخدم دون فقدان السياق المهم؟

Stalness

يمكننا أن نجعل تنفيذ الزر "رجوع" فوريًا عن طريق إضافة ذاكرة تخزين مؤقت محلية إلى التطبيق. للقيام بذلك ، سنقوم بتخزين البيانات اللازمة في ذاكرة التخزين المؤقت (البيانات من الحالة السابقة - تقريبا. المترجم). يمكننا حتى من الناحية النظرية تحديث ذاكرة التخزين المؤقت للحفاظ على تحديث البيانات. ومع ذلك ، فإن تنفيذ التخزين المؤقت يستلزم تحديات جديدة. قد تكون ذاكرة التخزين المؤقت قديمة. إذا قمت بتغيير الصورة الرمزية ، فيجب تحديثها بما في ذلك في ذاكرة التخزين المؤقت. إذا نشرت منشورًا جديدًا ، فيجب أن يظهر على الفور في ذاكرة التخزين المؤقت ، وإلا ستصبح ذاكرة التخزين المؤقت غير صالحة. قد يصبح هذا الرمز في النهاية معقدًا وصعبًا للغاية. ماذا لو فشلت عملية النشر؟ ما هي مدة ذاكرة التخزين المؤقت؟ عندما نعيد الحصول على مجموعة البيانات ، هل ندمج البيانات الجديدة مع البيانات المخزنة مؤقتًا في وقت سابق ، أم نتخلص من ذاكرة التخزين المؤقت القديمة ونسخة التخزين المؤقت للمجموعة بأكملها مرة أخرى؟ كيف يجب تقديم ترقيم الصفحات والفرز في ذاكرة التخزين المؤقت؟

الانتروبيا

يقرأ القانون الثاني للديناميكا الحرارية كما يلي: "بمرور الوقت ، يتحول كل شيء إلى فوضى كاملة" (وليس حرفيًا ، بالطبع). هذا صحيح أيضًا على واجهات المستخدم. لا يمكننا التنبؤ بتصرفات مستخدم معين وتسلسله. في أي وقت ، يمكن أن يكون طلبنا في عدد كبير من الحالات (العملاقة!). نحن نبذل قصارى جهدنا لجعل النتيجة قابلة للتنبؤ ومحدودة وفقًا لتصميمنا. لا نريد أن ننظر إلى لقطة الشاشة مع الخطأ ونفكر في أنفسنا: "كيف حدث هذا حتى؟" للحالات المحتملة N ، توجد انتقالات محتملة N × (N - 1) بينها. على سبيل المثال ، إذا كان من الممكن وجود خمس حالات مختلفة لزر (عادي ، نشط ، مرر ، مظلل ، معطل) ، يجب أن تكون الشفرة المسؤولة عن تغيير الزر صحيحة لمدة 5 × 4 = 20 انتقالات محتملة - أو تحظر صراحةً بعضها. كيف نتعامل مع الزيادة الاندماجيّة في الحالات المحتملة وخلق مخرجات مرئية يمكن التنبؤ بها؟

الأولوية

بعض الأشياء أكثر أهمية من غيرها. ربما يجب أن تظهر واجهة الحوار الخاصة بك "أعلى" بدقة الزر الذي تم استدعاؤه ، وتجاوز الحاوية الأصل. أو ، قد تكون المهمة المجدولة للتو (أي نتيجة النقرة) أكثر أهمية من مهمة طويلة الأمد بدأت بالفعل. أثناء تكبير التطبيق ، تبدأ أجزائه المختلفة ، التي كتبها أشخاص مختلفون أو حتى فرق ، في التنافس على موارد محدودة ، مثل طاقة حوسبة المعالج أو حركة مرور الشبكة أو مساحة الشاشة أو حجم الحزمة. في بعض الأحيان ، يمكنك توزيع العناصر على مقياس "أهمية" واحد ، على غرار قاعدة CSS z-index . ولكن عادة ما لا ينتهي مع أي شيء جيد . أي مطور يعتبر بصدق رمزه مهم. ولكن إذا كان كل شيء على نفس القدر من الأهمية ، فهذا يعني - لا شيء مهم. كيف يمكننا أن نجعل الأجزاء المستقلة من التطبيق تتفاعل بدلاً من الكفاح من أجل الموارد المحدودة؟

إمكانية الوصول

المواقع التي لا تتكيف مع الأشخاص ذوي الإعاقة ليست مشكلة عالية التخصص. على سبيل المثال ، في إنجلترا يواجه كل مستخدم خامس هذه المشكلة (فيما يلي رسم بياني بصري). شعرت به على نفسي. على الرغم من أنني أبلغ من العمر 26 عامًا ، إلا أنني بالكاد أستخدم المواقع ذات الخطوط الرفيعة ونظام الألوان المعتمة. أحاول استخدام لوحة التتبع كثيرًا ، لكنني خائف من اليوم الذي يتعين علي فيه استخدام موقع غير مناسب للوحة المفاتيح. يجب ألا نحول طلباتنا إلى كابوس للأشخاص ذوي الإعاقة - والخبر السار هو أنه ليس بالأمر الصعب. يجب أن تبدأ باستكشاف الحلول والأدوات. بالإضافة إلى ذلك ، يجب أن نجعل من السهل والمفهوم للمصممين والمطورين اتخاذ القرارات الصحيحة. ما الذي يمكننا فعله لضمان إتاحة تطبيقاتنا افتراضيًا ، وليس المراجعة المتأخرة؟

التدويل

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

التسليم

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

المرونة (المرونة)

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

التجريد

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

---

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

من المغري أن نقرأ عن هذه المشكلات ، مع الأخذ في الاعتبار كحل إطار عمل محدد لعرض البيانات أو مكتبة لتلقي البيانات. لكنني أوصي بأن تتخيل أن هذه الحلول غير موجودة ومحاولة القراءة مرة أخرى. كيف تحاول حل هذه المشكلات؟ حاول أن تدرك أفكارك حول تطبيق بسيط. سأكون سعيدًا لرؤية نتائج تجاربك على جيثب. (ما عليك سوى وضع علامة على دان أبراموف على Twitter وإرفاق روابط إلى المستودعات - مترجم تقريبًا).

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

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

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