UX و HTML5: دعنا نساعد المستخدمين على ملء نموذج هاتفك المحمول (الجزء 1)

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

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

يوصى بقراءة : شبكة الويب العالمية ، وليس شبكة الويب الغربية الثرية

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

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

ملاحظة : على الرغم من أن معظم تحسينات الشفرة في هذه المقالة مرتبطة بالويب (لأنني لا أعرف Swift أو Java) ، فإن أفضل ممارسات الاستخدام تنطبق على تطبيقات الهاتف المحمول .

تصميم النموذج 101: إعطاء الأولوية لقابلية المسح والقراءة

"النموذج هو الاسم ، والقيمة ، والأزواج ، في هيكل لتخزين البيانات على جهاز كمبيوتر يتم عرضه كتسميات وحقول إدخال للإنسان." هذا اقتباس مباشر من Luke Wroblewski في أحد المؤتمرات. مثله ، أعتقد أن معظم مشكلات قابلية الاستخدام تأتي من هذا الاتجاه لخدمة بنية قاعدة البيانات للمستخدمين.

بنية معلومات قوية

لإنشاء نماذج أفضل ، عليك أولاً اتخاذ بضع خطوات بعيدًا عن بنية قاعدة البيانات الخاصة بك. حاول أن تفهم كيف يريد المستخدمون ملء النماذج. هذا هو المكان الذي يصبح فيه إجراء بعض اختبارات قابلية الاستخدام وأبحاث المستخدم حول النماذج الخاصة بك مفيدًا. النماذج العقلية للمستخدم هي مفهوم UX يمكن أن يساعدك في ذلك. تصفها مجموعة Nielsen Norman Group بأنها "ما يعتقده المستخدم عن النظام الموجود". اطلب من المختبِر التفكير بصوت عالٍ وإخبارك بكيفية ملء النموذج. ما هي الخطوات التي يتوقعونها؟ ماذا يأتي اولا؟ ماذا سيأتي بعد ذلك؟ سيعطيك هذا فكرة أفضل عن كيفية هيكلة النموذج الخاص بك بطريقة أكثر سهولة في الاستخدام.

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

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

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

أخيرًا ، خطط مسبقًا للترجمة: ماذا سيحدث عندما تتم ترجمة النموذج الخاص بك؟ ماذا سيحدث ، على سبيل المثال ، بالنسبة للألمانية؟ هل سيظل تصميمك يعمل؟

وضع الملصق وتحسين المدخلات

يعمل التخطيط أحادي العمود بشكل أفضل

نظرًا لضيق المساحة ، لا تحصل على خيارات لا حصر لها لوضع الملصقات والحقول على شاشات الجوال:

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

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

لمزيد من المعلومات حول وضع الملصق ، راجع "قابلية استخدام نموذج الهاتف المحمول لمعهد Baymard: ضع الملصقات فوق الحقل".

يجب أن تكون الملصقات واضحة ومرئية وتعمل بدون سياق

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

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

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

أفضل ممارسة لحجم الإدخال

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

استخدام الأقنعة لتجنب تقسيم المدخلات على الهاتف المحمول

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

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

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

أخيرًا ، تذكر أن بعض البيانات يمكن أن تختلف باختلاف البلدان ، وأحيانًا يتغير التنسيق أيضًا (أرقام الهواتف ، على سبيل المثال). خطط وفقًا لذلك.

أوصاف الحقول بكفاءة

يمكن أن يُحدث عرض الأوصاف الميدانية الفعالة فرقًا بين تجربة الشكل السلسة والمؤلمة.

ما الذي يمكن استخدام الأوصاف فيه؟

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

• ما الذي تطلبه بالضبط؟
  

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

  

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

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

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

  

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



• "كيف يمكنني تنسيق المعلومات؟"
  تحتاج بعض الحقول إلى تنسيق معين . في هذه الحالة ، استخدم الأوصاف للسماح للمستخدمين بمعرفة قواعد التنسيق مقدمًا. وفيما يلي بعض الأمثلة على ذلك:
  • رقم الهاتف: هل أحتاج إلى وضع رمز الاتصال الدولي (+ xx) أمام الحقل؟
  • هل يوجد حد أقصى للطول؟ يقوم Twitter على الهاتف المحمول بعمل جيد مع ذلك.
  • عند التعامل مع المبالغ النقدية ، هل التنسيق يحتوي على فاصلة (مثل 10000) أم مسافة (مثل 10000)؟
  • ما هو الشكل الذي تتوقعه للتواريخ؟ سأدعك تتحقق من ويكيبيديا يا له من كابوس. يمكن أن يتسبب الاختلاف بين DD MM YY و MM DD YY في حدوث * الكثير * من المتاعب للمستخدمين عند الحجز عبر الإنترنت.
  لاحظ أنه يمكن حل الكثير من مشكلات التنسيق هذه عن طريق أقنعة الإدخال. سنصل إلى ذلك لاحقًا في المقالة (أو يمكنك القفز مباشرة إذا كنت لا تتحلى بالصبر).

  

كيفية عرض الأوصاف

في الأمثلة أعلاه ، رأينا بعض الطرق لعرض أوصاف الحقول. فيما يلي ملخص لما يجب القيام به:

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

كن حذرا مع العناصر النائبة

فهمت: من المغري إزالة الحقول على الهاتف المحمول للحصول على مساحة واستخدام العناصر النائبة بدلاً من ذلك. لقد ذهبنا جميعًا في هذا الطريق. لكن من فضلك لا تفعل. مواصفات HML5 واضحة حول هذا الأمر: "تمثل سمة العنصر النائب تلميحًا قصيرًا (كلمة أو عبارة قصيرة) يهدف إلى مساعدة المستخدم في إدخال البيانات". وهذا هو السبب:

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

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

إذا كنت ترغب في التعمق في هذا الموضوع ، فهناك مقال رائع بعنوان "سمة العنصر النائب ليست تسمية ، وكذلك يشرح جوشوا وين و FeedbackGuru سبب كون هذه فكرة سيئة. قامت مجموعة Nielsen Norman Group أيضًا بكتابة قطعة حول هذا الموضوع بعنوان "العناصر النائبة في حقول النموذج ضارة".

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

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

منذ نجاح تصميم المواد في Android ، بدأ نمط في الظهور: التسمية العائمة. توجد هذه التسمية داخل الحقل عندما لا يتم ملء الحقل ، لذا فهي تشغل مساحة عمودية أقل قليلاً على الهاتف المحمول. عندما يبدأ المستخدمون في التفاعل مع الحقل ، تنتقل التسمية فوق الحقل.

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

خفض تكلفة التفاعل للنماذج الناجحة

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

أخبرتني دراسة سحرية على الإنترنت بتقليل عدد الحقول

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

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

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

أيضًا ، لا تثق بشكل أعمى في كل إحصائية ودراسة تجدها على الإنترنت. هل تتذكر 11 حقلاً إلى 4 دراسة؟ حسنًا ، أظهرت دراسة حديثة أخرى أنه من خلال تقليل الحقول من 9 إلى 6 ، انخفضت التحويلات بنسبة 14٪. صدمة ، أليس كذلك؟ لماذا ا؟ حسنًا ، لقد أزالوا المجالات الأكثر جاذبية. باختصار ، عادوا بعد ذلك إلى 9 حقول ، ووضعوا الأهم في المقدمة ، وفويلا ، زادت التحويلات بنسبة 19.21٪.

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

ذلك ما يمكن أن تفعله؟ اختبار. اختبار. واختبر!

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

تحسين تفاعلات اللمس

جعل الضوابط سهلة اللمس

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

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

أجرى ستيفن هوبر بعض أبحاث المستخدم حول مناطق اللمس. ستجد ملخصًا في "Designing for Touch". بناءً على ما اكتشفه ، قام ببناء أداة مسطرة بلاستيكية صغيرة: قالب اللمس المحمول. يمكن أن تساعدك الأداة في التأكد من أن مناطق اللمس لديك كبيرة بما يكفي لنماذج الأجهزة المحمولة وبشكل عام لتصميم الأجهزة المحمولة.

لمعرفة المزيد حول التصميم باللمس ، يمكنك قراءة ما يلي:

• "تصميم مناسب للإصبع: أحجام مستهدفة مثالية لشاشة اللمس على الأجهزة الجوّالة"
• "منطقة الإبهام: التصميم لمستخدمي الجوّال"

توفير التغذية المرتدة

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

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

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

تكريم ترتيب الزر التالي والسابق

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

تجنب القوائم المنسدلة على الهاتف المحمول إن أمكن

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

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

قائمة البلدان هي مرشح جيد للمكون. تعد القائمة المنسدلة لأكثر من مائة دولة بمثابة كابوس تفاعل على الهاتف المحمول. لا بأس إذا كنت تبحث عن أفغانستان (في بداية القائمة) أو زيمبابوي (نهاية القائمة). إذا كنت تبحث عن لوكسمبورغ ، فسوف ينتهي بك الأمر في لعبة التمرير للوصول إلى منتصف القائمة ، والذهاب بعيدًا جدًا إلى الحرف M ، ومحاولة العودة إلى L ، وما إلى ذلك.

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

إذا كنت تريد أن يختار المستخدمون تاريخًا ، فانسَ أمر تقسيمه إلى قائمة منسدلة ليوم وشهر وسنة مثلما اعتاد الأشخاص على استخدام النماذج الورقية. استبدل القوائم المنسدلة المتعددة بمنتقي التاريخ . type=date يعمل في معظم الحالات. ولكن قد يكون لديك بعض الاحتياجات الخاصة وينتهي بك الأمر إلى إنشاء منتقي التاريخ الخاص بك في JavaScript ، خاصة إذا كنت تعمل في مجال الحجز (الفنادق والسيارات والرحلات الجوية).

في مقالته "إعادة النظر في قوائم Mobile DropDowns" ، يشرح كلاوس شايفر كيف أن استخدام منتقي التاريخ لتواريخ الوصول والمغادرة جعل التفاعلات أسرع بنسبة 60٪.

دعنا نتمسك بأعمال الحجز. افترض أن المستخدم يحتاج إلى إضافة عدة مسافرين إلى خط سير الرحلة. يمكنك ** استبدال القائمة المنسدلة * بـ * السائر ** لتحديد عدد الركاب. السائر هو عنصر تحكم يسمح للمستخدم بزيادة القيم وتقليلها ببساطة عن طريق النقر على أزرار + و- . يميل ذلك إلى أن يكون أسرع عندما يتم إضافة أقل من ستة أشخاص. إنها أيضًا أكثر سهولة. يوجد أدناه مثال لخطوة مستخدمة في تطبيق Android الأصلي Airbnb لاختيار الضيوف ، وعلى موقع Kayak المحسّن للجوّال لإضافة ركاب.

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

الحصول على الذكاء مع الإكمال التلقائي

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

الأماكن والعناوين

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

يمكنك استخدام:

• واجهة برمجة تطبيقات أماكن Google
• Algolia Places ، التي تعتمد على OpenStreetMap

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

بطاقات الائتمان

من المجالات الأخرى التي يسهل فيها الاكتشاف التلقائي بطاقات الائتمان. لست بحاجة لأن تسأل المستخدم عن نوع بطاقة الائتمان لديه. يمكنك اكتشاف هذا تلقائيًا بناءً على الأرقام الأولية التي يدخلونها. حتى أن هناك مكتبة يمكنها القيام بالمهمة نيابة عنك.

استخدام الإكمال التلقائي لـ HTML5 (الملء التلقائي)

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

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

باختصار ، عندما يتعين عليك الاختيار من بين أنظمة مختلفة ، احسب عدد التفاعلات التي سيتطلبها كل نظام.

حدوث أخطاء: معالجة الأخطاء في نماذج الجوّال

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

تجنب الأخطاء أثناء تعبئة الاستمارات

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

تحديد التنسيق الصريح

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

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

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

تعليم الحقول الإلزامية (والحقول الاختيارية)

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

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

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

افتراضات معقولة

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

أيضا ، كن حذرا بشأن الجنس. مرة أخرى ، لديك خيار للأشخاص الذين لا يريدون الكشف عنه ؛ وضح لماذا تسأل عن جنسهم ؛ الأفضل من ذلك ، اسأل عن الضمائر ، أو لا تسأل عما إذا كنت لا تحتاج إلى ذلك حقًا. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

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

  

  اختبرت أمازون الإصدار الأخير ، وشعر 60٪ من الناس بالريبة. لذلك ، قاموا باستبدال مربع الاختيار "إخفاء كلمة المرور" غير المحدد بمربع تحديد "إظهار كلمة المرور". سيُظهر هذا كلمة المرور بأحرف أصغر ، أسفل الحقل ، بينما يكتب المستخدم. هذا ما كان يبدو عليه وقت كتابة هذا المقال:

  

  كما ترى ، هناك دائمًا مجال للتحسين.

التحقق المضمن

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

بدلاً من ذلك ، يجب وضع رسائل الخطأ بالقرب من الأخطاء نفسها .

التحقق في الوقت الحقيقي

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

بعض النصائح:

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

ملاحظة : * كتب ميخائيل كونجيفيتش مقالًا رائعًا حول "التحقق المضمّن في النماذج: تصميم التجربة." يشرح مفهوم " الثواب مبكرًا ، عاقب متأخرًا ". *

"إذا كان المستخدم يدخل البيانات في الحقل الذي كان في حالة صالحة ، فقم بإجراء التحقق بعد إدخال البيانات."

"إذا كان المستخدم يدخل البيانات في الحقل الذي كان في حالة غير صالحة ، فقم بإجراء التحقق أثناء إدخال البيانات."

مسائل اللون

أنا لا أقول أن اللون مهم فقط بسبب لون شعري الحالي من الزنجبيل والوردي والأرجواني. اللون مهم حقًا في تصميم النموذج.

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

الحديث عن عمى الألوان: لا ينبغي أن يكون اللون هو الطريقة الوحيدة لإيصال رسالة خطأ . هذا هو معيار الوصول.

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

التعافي من الأخطاء: كتابة رسائل خطأ سهلة الاستخدام

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

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

أنت لست روبوتًا ولا مستخدموك أيضًا

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

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

احذر اللغة التي تستخدمها في الرسائل

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

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

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

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

لمساعدتك في كتابة رسالة خطأ أفضل ، أقترح عليك قراءة ما يلي:

• "قائمة التحقق المصغرة المكونة من 6 نقاط لفرق المنتج بدون كتّاب UX"
• "فن رسالة الخطأ: كتابة نسخة واضحة ومفيدة عندما تسوء الأمور"

حان الوقت لتقديم النموذج

قام المستخدم بملء النموذج ، ولم تعد هناك أخطاء ، ويبدو كل شيء على ما يرام. أخيرًا ، حان وقت إرسال النموذج!

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

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

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

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

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

خاتمة

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

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

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