قد يراجع المشتري الطلب ثم يكتشف أن عنوان الفاتورة أصبح عنوان المستلم. تكرار أسماء الحقول وحده لا يشرح للمتصفح الفرق بين المجموعتين. الملء التلقائي يحتاج وصفًا دلاليًا لكل حقل، واختبارًا يحافظ على اختيار المستخدم عندما تختلف وجهة الشحن عن بيانات الفاتورة.
رتب الرموز بحسب وظيفة الحقل
تشرح وثائق HTML لخاصية autocomplete استخدام قائمة رموز مرتبة، منها بادئة section-* لتجميع الحقول، ثم shipping أو billing عند الحاجة، ثم رمز الحقل نفسه. مثال توضيحي لشارع الشحن: section-ship shipping street-address، وللفاتورة: section-bill billing street-address.
هذه معلومات مساعدة للمتصفح وليست أمرًا يضمن ملء القيمة في كل جهاز. قد يتأثر السلوك ببنية النموذج ووجود name أو id وزر إرسال وبسياسة المتصفح والبيانات المحفوظة. ولا تعتبر autocomplete بديلًا عن عنوان ظاهر واضح للحقل.
أنشئ خريطة قبل تكرار المكونات
| المجموعة | ما تراجعه في القالب |
|---|---|
| عنوان الشحن | بادئة ثابتة وshipping ورمز كل حقل |
| عنوان الفاتورة | مجموعة مستقلة وbilling |
| مستلم إضافي | تمييز section عن المستلم الأول |
| نفس عنوان الشحن | قرار واضح للنسخ والتراجع عنه يدويًا |
اختبر اختلاف العنوانين
في سيناريو افتراضي، احفظ في ملف متصفح تجريبي عنوانين مصطنعين، ثم اختر شحنًا لمستلم وفاتورة لجهة أخرى. راجع كل حقل بعد الملء، ثم غيّر عنوان الشحن وافحص ألا تتغير الفاتورة دون إجراء مقصود. كرر الرحلة على الهاتف وسطح المكتب والمتصفحات التي يدعمها المتجر.
لا تستخدم عناوين حقيقية في التسجيلات أو الصور المشتركة. إذا فشل الملء التلقائي يجب أن يستطيع المستخدم إدخال القيم وتصحيحها بنفسه. إغلاق هذه الإمكانية أو تعطيل الملء في كل النموذج قد يخفي الالتباس دون حل سببه.
طابق واجهة العنوان مع الطلب المحفوظ
ضمن تطوير المتاجر الإلكترونية افحص الحمولة وقيم الطلب بعد الحفظ، مع تحقق الخادم من العقد المقبول. وفي تصميم تجربة الشراء اختبر أسماء المجموعات ووضوح خيار النسخ بينهما. معيار القبول أن تبقى هوية كل عنوان مفهومة، سواء ملأه المتصفح أو أدخله المستخدم، وأن يصل إلى موضعه الصحيح في الطلب.
