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

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

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

## كيف قد تبدو

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

ها هو HTML:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

التسميات حيث تبدأ مناقشتنا.

## تسميات

في " إمكانية الوصول للجميع " ، تحدد Laura Kalbag أربعة معايير عامة تعمل على تحسين تجربة المستخدم للجميع:

• بصري : اجعلها سهلة الرؤية.
• السمع : اجعل من السهل سماعه.
• المحرك : اجعل من السهل التفاعل معه.
• معرفي : اجعله سهل الفهم.

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

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

لتوصيل أحد المُدخلات بتسمية ، يجب أن يتطابق id for وتسمية السمة ويكون فريدًا مع الصفحة. في حالة حقل البريد الإلكتروني ، تكون القيمة "بريد إلكتروني":

 html < label for = "email" > Email address </ label > < input id = "email" >

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

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

## العناصر النائبة

الغرض من سمة placeholder تخزين تلميح. يمنح المستخدمين إرشادات إضافية عند ملء حقل - مفيد بشكل خاص للحقول التي تحتوي على قواعد معقدة مثل حقل كلمة المرور.

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

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

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

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

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

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

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

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

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

تُستخدم السمة aria-describedby لربط التلميح عن طريق id الخاص به - تمامًا مثل السمة الخاصة بالتسميات ، ولكن بالعكس. يتم إلحاقه بتسمية عنصر التحكم ويتم قراءته بعد فترة توقف قصيرة. في هذا المثال ، "يجب أن تحتوي كلمة المرور [إيقاف مؤقت] على ثمانية أحرف زائد برقم واحد على الأقل وحرف كبير واحد."

هناك اختلافات أخرى أيضا. أولاً ، لن يؤدي النقر فوق التلميح ( <p> في هذه الحالة) إلى تركيز عنصر التحكم ، مما يؤدي إلى تقليل منطقة الإصابة. ثانيًا ، على الرغم من الدعم المتزايد لـ ARIA ، فلن يتم دعمها أبدًا مثل العناصر المحلية. في هذه الحالة بالذات ، لا يدعم Internet Explorer 11 aria-describedby . هذا هو السبب في أن القاعدة الأولى لـ ARIA هي عدم استخدام ARIA:

"إذا كان بإمكانك استخدام عنصر أو سمة HTML أصلي مع الدلالات والسلوك الذي تطلبه مضمّنًا بالفعل ، بدلاً من إعادة تحديد عنصر وإضافة دور أو حالة أو خاصية ARIA لإتاحة الوصول إليه ، فافعل ذلك ."

تسميات عائمة

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

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

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

"يبدو أن هناك الكثير من الجهد عندما يمكنك ببساطة وضع التسميات فوق المدخلات والحصول على جميع الفوائد / لا شيء من المشكلات."
- Luke Wroblewski على ملصقات عائمة

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

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

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

## بروتوكول السؤال

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

هل يحتاج نموذج التسجيل إلى جمع الاسم الأول واسم العائلة وعنوان البريد الإلكتروني وكلمة المرور؟ هل هناك طرق أفضل أو بديلة لطلب هذه المعلومات التي تبسط التجربة؟

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

### تسجيل الدخول بدون كلمة مرور

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

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

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

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

### عبارات المرور

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

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

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

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

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

## التصميم الميداني

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

### موضع التسمية

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

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

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

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

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

### الشكل والحجم والمساحة

يجب أن تبدو حقول النموذج مثل حقول النموذج. ولكن ماذا يعني ذلك بالضبط؟

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

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

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

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

### أنماط التركيز

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

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

 input:focus { outline: 4px solid #ffbf47; }

## حقل البريد الإلكتروني

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

كما ذكرنا سابقًا ، تحتوي بعض الحقول على تلميح بالإضافة إلى التسمية ، وهذا هو سبب وجود التسمية داخل امتداد فرعي. تتيح لنا فئة field-label من خلال CSS.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

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

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

سيرى الأشخاص الذين يستخدمون متصفحًا لا يدعم إدخال نص قياسي ( <input type="text"> ). هذا شكل من أشكال التحسين التدريجي ، وهو حجر الزاوية في تصميم التجارب الشاملة.

### تحسين تدريجي

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

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

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

يبدأ بـ HTML للهيكل والمحتوى. إذا لم يتم تحميل CSS أو JavaScript ، فلا بأس لأن المحتوى موجود.

إذا تم تحميل كل شيء بشكل جيد ، فربما لا يتم التعرف على عناصر HTML المختلفة. على سبيل المثال ، لا تفهم بعض المتصفحات <input type="email"> . لا بأس بذلك ، لأن المستخدمين سيحصلون على مربع نص ( <input type="text"> ) بدلاً من ذلك. لا يزال بإمكان المستخدمين إدخال عنوان بريد إلكتروني ؛ لا يحصلون فقط على لوحة مفاتيح خاصة بالبريد الإلكتروني على الهاتف المحمول.

ربما لا يفهم المتصفح بعض أنواع CSS الرائعة ، وسوف يتجاهلها فقط. في معظم الحالات ، هذه ليست مشكلة. لنفترض أن لديك زرًا border-radius: 10px . المتصفحات التي لا تتعرف على هذه القاعدة ستعرض زرًا بزوايا زاوية. يمكن القول إن التكلفة المتصورة للزر تقل ، لكن المستخدمين لم يصابوا بأذى. في حالات أخرى ، قد يكون من المفيد استخدام استعلامات الميزات.

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

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

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

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

## حقل كلمة المرور

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

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

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

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

### كشف كلمة المرور

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

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

توفر الإصدارات الحديثة من Internet Explorer و Microsoft Edge هذا السلوك في الأصل. نظرًا لأننا سننشئ الحل الخاص بنا ، يجب علينا منع هذه الميزة باستخدام CSS على النحو التالي:

 input[type=password]::-ms-reveal { display: none; }

أولاً ، نحتاج إلى حقن زر بجوار الإدخال. يجب أن يكون العنصر <button> هو عنصر الانتقال لتغيير أي شيء باستخدام JavaScript - باستثناء تغيير الموقع ، وهو الغرض من الروابط. عند النقر فوقه ، يجب تبديل سمة النوع بين password text ؛ وتسمية الزر بين "إظهار" و "إخفاء".

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### بناء جملة JavaScript والملاحظات المعمارية

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

أولا ، نحن نستخدم منشئ. المُنشئ هو دالة مكتوبة بشكل تقليدي في حالة الجمل العلوية - PasswordReveal ، وليس passwordReveal . تمت تهيئته باستخدام الكلمة الأساسية new ، والتي تتيح لنا استخدام نفس الرمز لإنشاء عدة مثيلات للمكون:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

ثانيًا ، يتم تحديد طرق المكون في النموذج الأولي - على سبيل المثال ، PasswordReveal.prototype.onButtonClick . النموذج الأولي هو الطريقة الأكثر فاعلية لمشاركة الطرق عبر مثيلات متعددة لنفس المكون.

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

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

ربما لاحظت أيضًا استخدام وظيفة $.proxy . هذا هو تنفيذ jQuery لـ Function.prototype.bind . إذا لم نستخدم هذه الوظيفة للاستماع إلى الأحداث ، فسيتم استدعاء معالج الحدث في سياق العنصر ( this ). في المثال أعلاه ، سيكون هذا this.button غير معرف. لكننا نريد أن يكون this هو كائن إظهار كلمة المرور بدلاً من ذلك ، حتى نتمكن من الوصول إلى خصائصه وطرقه.

#### خيارات الواجهة البديلة

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

إذا أظهر البحث أن هذه مشكلة ، فيمكنك تجربة نهجين بديلين.

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

أو ، ثانيًا ، قم بتغيير state الزر - وليس التسمية. لنقل الحالة إلى مستخدمي قارئ الشاشة ، يمكنك تبديل سمة aria-pressed الصوت بين true (مضغوط) false (غير مضغوط).

 <button type="button" aria-pressed="true"> Show password </button>

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

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

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

### تقنية Microcopy

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

عندما تكون "كلمة المرور" غامضة ، يوفر خيار "اختيار كلمة المرور" الوضوح.

## أنماط الزر

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

الأزرار التي ترسل النماذج هي "أزرار إرسال" ويتم ترميزها عادةً على أنها إما <input type="submit"> أو <button type="submit"> . يعد عنصر <button> أكثر مرونة من حيث أنه يمكنك تداخل العناصر الأخرى بداخله. لكن نادرًا ما تكون هناك حاجة لذلك. تحتوي معظم أزرار الإرسال على نص فقط.

ملاحظة: في الإصدارات القديمة من Internet Explorer ، إذا كان لديك أكثر من <button type="submit"> s ، فسيرسل النموذج قيمة جميع الأزرار إلى الخادم ، بغض النظر عن النقر فوقها. ستحتاج إلى معرفة الزر الذي تم النقر عليه حتى تتمكن من تحديد الإجراء الصحيح الذي يجب اتخاذه ، ولهذا السبب يجب تجنب هذا العنصر.

يتم إدخال أزرار أخرى في الواجهة لتحسين تجربة JavaScript - مثلما فعلنا مع مكون كشف كلمة المرور الذي تمت مناقشته سابقًا. كان هذا أيضًا <button> ولكن تم ضبط type على button (وليس submit ).

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

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

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

لا يزال بإمكان الأزرار تقديم ملاحظات حول التمرير (والتركيز) عن طريق تغيير لون الخلفية ، على سبيل المثال.

### تحديد مستوى

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

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

### نص

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

يمكن أن تتطابق الكلمات الدقيقة مع نبرة صوت علامتك التجارية ، لكن لا تتبادل الوضوح مع الغرابة.

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

## تصديق

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

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

### التحقق من صحة HTML5

التحقق من صحة HTML5 موجود منذ فترة حتى الآن. بإضافة بعض سمات HTML فقط ، فإن المتصفحات الداعمة ستحدد الحقول الخاطئة عند إرسال النموذج. المتصفحات غير الداعمة تعود إلى التحقق من جانب الخادم.

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

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

نريد أيضًا أن نمنح المستخدمين نفس الواجهة سواء تم اكتشاف الأخطاء على الخادم أو العميل. لهذه الأسباب سنقوم بتصميم الحل الخاص بنا. أول شيء يجب فعله هو إيقاف التحقق من صحة HTML5: <form novalidate>

### التعامل مع التقديم

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

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

لاحظ أننا نستمع إلى حدث إرسال النموذج ، وليس حدث النقر على الزر. سيؤدي هذا الأخير إلى منع المستخدمين من إرسال النموذج بالضغط على Enter عندما يكون التركيز داخل أحد الحقول. يُعرف هذا أيضًا باسم إرسال النموذج الضمني .

### عرض الملاحظات

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

#### عنوان المستند

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

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

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

تقوم JavaScript التالية بتحديث العنوان:

 document.title = "(" + this.errors.length + ")" + document.title;

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

ملخص الخطأ

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

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

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

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

تلعب الحاوية role group ، والتي تُستخدم لتجميع مجموعة من عناصر الواجهة: في هذه الحالة ، العنوان وروابط الخطأ. يتم تعيين السمة tabindex على -1 ، لذلك يمكن التركيز برمجيًا باستخدام JavaScript (عند إرسال النموذج مع وجود أخطاء). يضمن ذلك تمرير لوحة ملخص الخطأ إلى العرض. وإلا ستظهر الواجهة غير مستجيبة ومتعطلة عند إرسالها.

ملاحظة: استخدام tabindex="0" يعني أنه سيكون قابلاً للتركيز بشكل دائم عن طريق مفتاح Tab ، وهو 2.4.3 Focus Order فشل WCAG. إذا تمكن المستخدمون من الانتقال إلى شيء ما ، فإنهم يتوقعون أنه سيفعل شيئًا ما بالفعل.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

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

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

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

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

ملاحظة: يمكنك استخدام السمة / الخاصية hidden لتبديل رؤية العنصر ، ولكن هناك دعم أقل لها. يتعلق التصميم الشامل باتخاذ قرارات تعلم أنه من غير المرجح أن تستبعد الأشخاص. استخدام الفصل يتوافق مع هذه الفلسفة.

#### أخطاء مضمنة

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

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

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

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

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

 <input aria-inval>

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

### تقديم النموذج مرة أخرى

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

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### التهيئة

بعد الانتهاء من تحديد مكون FormValidator ، نحن الآن جاهزون لتهيئته. لإنشاء مثيل لـ FormValidator ، تحتاج إلى تمرير عنصر النموذج كمعامل أول.

 var validator = new FormValidator(document.getElementById('registration'));

للتحقق من صحة حقل البريد الإلكتروني ، على سبيل المثال ، اتصل addValidator() :

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

المعلمة الأولى هي name عنصر التحكم ، والثانية عبارة عن مصفوفة من كائنات القاعدة. تحتوي كل قاعدة على خاصيتين: method message . method هي وظيفة تختبر شروطًا مختلفة لإرجاع إما true أو false . تضع False الحقل في حالة خطأ ، والتي تُستخدم لملء الواجهة بالأخطاء كما تمت مناقشته سابقًا.

#### مسامحة الأخطاء التافهة

في تصميم الأشياء اليومية ، يتحدث دون نورمان عن التصميم للخطأ. يتحدث عن الطريقة التي يتحدث بها الناس:

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

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

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

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

### التحقق المباشر المباشر

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

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

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

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

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

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

### نمط تأكيد قائمة التحقق

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

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

### ملاحظة حول تعطيل أزرار الإرسال

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

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

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

### صياغة رسالة خطأ جيدة

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

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

"المحتوى هو تجربة المستخدم."
- جيني ريديش

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

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

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

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

تتطلب الأخطاء المختلفة تنسيقات مختلفة. تعليمات مثل "أدخل اسمك الأول" طبيعية. لكن "أدخل الاسم الأول المكون من 35 حرفًا أو أقل" يكون أطول ، وكلمات أكثر ، وأقل طبيعية من وصف مثل "يجب أن يتكون الاسم الأول من 35 حرفًا أو أقل".

فيما يلي قائمة مرجعية:

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

## ملخص

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

### أشياء يجب تجنبها

• استخدام سمة placeholder كآلية لتخزين نص التلميح والتسمية.
• استخدام أنواع إدخال غير صحيحة.
• أزرار التصميم والروابط نفسها.
• التحقق من صحة الحقول كما يكتب المستخدمون.
• تعطيل أزرار الإرسال.
• استخدام المصطلحات المعقدة والنسخ المصغر المتأثر بالعلامة التجارية.

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