قرارات المطور لبناء مكونات مرنة

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

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

تغيير عقلية التنمية لدينا

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

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

التصميم

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

ملاحظة: إذا كنت تريد القفز مباشرة إلى الكود وعرض جميع الحلول الممكنة التي قدمناها لهذا المكون ، فيمكنك العثور عليها في هذا العرض التوضيحي لـ Codepen.

التخطيط والنظام

نص المصمم على أن كل مكون آخر يجب أن يكون التخطيط مقلوبًا بحيث تكون الصورة على اليمين وعمود النص على اليسار.

ومع ذلك ، في تخطيط الأجهزة المحمولة ، يتم تكديس الصورة فوق محتوى النص في جميع الحالات. بافتراض أننا قمنا ببناء هذا التخطيط باستخدام إما Grid أو flexbox ، يمكننا استخدام flex-direction أو خاصية order لإعادة ترتيب التخطيط لكل مكون ثانٍ:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

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

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

1. طرح مخاوفنا المتعلقة بإمكانية الوصول والتوصية بتغيير الترتيب المرئي لتخطيطات الأجهزة المحمولة لمطابقة ترتيب سطح المكتب.
2. استخدم Javascript لإعادة ترتيب العناصر في DOM.

نحتاج أيضًا إلى التفكير فيما إذا كان يجب تنفيذ الأمر من خلال :nth-child selector أو السماح للعميل بالتحكم في الأمر (عن طريق إضافة فئة إلى المكون ، على سبيل المثال). من المحتمل أن تعتمد ملاءمة كل خيار على المشروع.

التعامل مع أطوال المحتوى المختلفة

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

أطول المحتوى

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

1. تظل الصورة أو الفيديو في الأعلى ، بينما تتم إضافة المسافة أدناه (الشكل 1).
2. الصورة أو الفيديو في المنتصف ، مع إضافة مسافة في الأعلى أو الأسفل (الشكل 2).
3. يتم قياس نسب الصورة أو الفيديو لتتناسب مع الارتفاع ، باستخدام object-fit: cover لمنع التشويه والتأكد من أن الصورة تملأ المساحة المتاحة. قد يعني هذا إمكانية قص بعض أجزاء الصورة (الشكل 3).

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

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

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

محتوى أقصر

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

طول العنوان

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

هل يُسمح لمؤلفي المحتوى بحذف العنوان تمامًا حيث يناسبهم؟ هذا يقودنا إلى الاعتبار التالي.

حذف المحتوى

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

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

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

روابط متعددة

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

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

هل نحتاج إلى نمط ارتباط ثانوي للتمييز بينهما؟ هذه كلها أسئلة للنظر فيها.

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

فيديو

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

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

وضعه في السياق

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

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

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

يمكننا إما فرض نمط باستخدام :nth-child أو إضافة حقل في CMS لمنح العميل مزيدًا من التحكم الإبداعي.

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

أنماط نص WYSIWYG

عند التفكير في المحتوى ، نحتاج إلى مراعاة ليس طول النص فحسب ، بل مراعاة عناصر HTML الفعلية التي قد يُسمح بها في حقل النص الأساسي. قد يرغب مؤلفو المحتوى في إضافة فقرات متعددة وروابط ربط وقوائم والمزيد إلى النسخة الأساسية. في Atomic Smash ، نود توفير WYSIWYG (ما تراه هو ما تحصل عليه) أو حقل نص منسق لهذه المناطق ، والذي يمكن أن يسمح بالعديد من العناصر المختلفة. من المهم اختبار أنواع مختلفة من المحتوى ، والنمط بشكل مناسب - بما في ذلك اختبار تباين الألوان الكافي على جميع ألوان الخلفية المستخدمة.

تغليف

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

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

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

قائمة التحقق

أشياء يجب اختبارها:

1. سهولة الوصول إلى التخطيط (المحمول وسطح المكتب).
2. الصور ذات النسب الجوهرية المختلفة - هل تم اقتصاصها بشكل مناسب؟
3. نص أساسي أطول وأقصر (بما في ذلك فقرات متعددة).
4. عنوان أطول وأقصر (بما في ذلك أطوال الكلمات المختلفة).
5. حذف (بشكل مختلف) العنوان والنص الأساسي والروابط والصورة.
6. روابط متعددة (بما في ذلك أطوال مختلفة لنص الارتباط).
7. سهولة الوصول إلى محتوى الفيديو.
8. محتوى نص WYSIWYG (بما في ذلك الروابط والقوائم وما إلى ذلك في النص الأساسي).
9. اختبار في السياق - قم بتضمين مكونات متعددة (مع خيارات محتوى مختلفة) ، بالإضافة إلى مكونات أخرى مختلطة في تخطيط الصفحة.