البحث في الموقع

يمكن أن تقوم SVG بأكثر بكثير من مجرد عرض الصور الثابتة، إذ تعد إمكانياتها الحركيّة واحدة من أكثر مميزاتها قوةً، مما يعطيها مزايا فريدة عن صيغ الصور الأخرى، وهي أحد الأسباب العديدة التي تجعل SVG أفضل من الصور النقطية، بما فيها GIF. ولكن هذا، بالطبع، ينطبق فقط على الصور التي تعد مرشحةً جيدةً لتكون SVG، مثل: table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } الشعارات، الصور غير المعقدة، المعتمدة على الأشعة، أدوات التحكم بواجهة المستخدم، الرسوم البيانية، والأيقونات. بالطبع، إذا كان لديك صورة أكثر ملاءمةً للصيغة النقطية – مثل الصور الفوتوغرافية أو الرسومات المعقدة جدًا المعتمدة على الأشعة (والتي من الطبيعي أن تكون كبيرة الحجم جدًا مثل صور SVG)، فعليك استخدام صيغة الصور النقطية بدلاً منها. لا يجب أن تكون الصورة مرشّحاً جيداً لـ SVG فقط، ولكن يجب أن يكون SVG مرشّحاً جيداً للصورة. فمثلًا، إذا كان حجم الصورة صغير جداً كصور PNG، يجب استخدام PNG، وتقديم إصدارات/معاملات دقة مختلفة للصورة باستخدام srcset أو <picture>، بالاعتماد على ما تعمل عليه وتحاول تحقيقه. عمومًا، الصور المذكورة أعلاه هي عادةً مرشّحات مثالية لـ SVG. وإذا كنت ستحرّك أيًا منها، فإنّ الطريقة المعقولة للقيام بذلك هي إنشاء صورك المتحركة عن طريق تحريك شيفرة SVG. ومع ذلك، في الأسبوع الماضي، ظهر رابطًا منبثقًا في يوميات حسابي على التويتر يشير إلى مجموعة من الأيقونات المتحركة كـ GIF. إنّ أول ما مرّ في ذهني عندما رأيتهم بأنّهم كانوا مرشحين مثاليين لـ SVG ويجب أن يتم إنشاؤهم كصور SVG، وليس صور GIF. في العديد من الحالات يمكنك استبدال صور GIF بصور SVG بالفعل، تمامًا كما يمكن أن تستبدلها بتنسيقات الصور النقطية الأخرى لمرشّحين مثل تلك المذكورة أعلاه. إنّ القدرة على تحريك صور SVG هي ما يمنحها هذه الميزة والقدرة. وهذا ينطبق على عناصر أكثر من الأيقونات المتحركة. لذا، لهذا السبب أعتقد أنّه يجب عليك استخدام SVG بدلًا من صور GIF كلما استطعت. جودة الصورة الميزة الأولى لاستخدام SVG بدلًا من GIF - أو أية صيغة صورة لهذه المسألة - هي - كما هو متوقع - ميزة SVG الأولى: استقلالية الدقة. ستبدو صورة SVG فائقة الوضوح عند أي دقة للشاشة، بغض النظر عن حجمها. في حين أن صور GIF - صيغة الصورة النقطية - لا تظهر كذلك. حاول تكبير الصفحة التي تحتوي على صورة GIF وشاهد كيف ستبدو صورة الـ GIF منقطة ومحتوياتها غير واضحة. مثلّا، يبدو تسجيل GIF التالي لحركة صورة SVG جيدًا بهذا الحجم الصغير: يؤدي تكبير الصفحة عدّة مرات إلى جعل الصورة غيرَ واضحةٍ وتصبح حواف ومنحنيات العناصر الداخلية مسننةً، كما تشاهد في الصورة أدناه: بينما إذا قمت بالتحقق من عرض SVG التجريبي وتكبير الصفحة، فإن محتوى SVG سيبقى واضحًا وصافيًا بغض النظر عن مقدار التكبير. لتوفر صورًا واضحةً للشاشات عالية الدقة عند استخدام صيغة صورة نقطية مثل GIF، تحتاج إلى استخدام <picture> أو srcset وتشغيل الصور بسياقات مختلفة. بالطبع، كلما زادت دقة الصورة، زاد حجم الملف. مع صور GIF، سيصل حجم الملف لحجمٍ كبير بشكلٍ هائل. لكننا سنصل إلى ذلك في غضون دقيقة، كذلك، فإنّ استخدام صور GIF عالي الدقة وعرضها بحجمٍ أصغر للهواتف المحمولة يعد أمرًا سيئًا بالنسبة للأداء، لذا لا تفعل ذلك. عندما تنشئ أيقونات أو صور GIF متحركة، أبعادها ثابتةٌ. غيّر الأبعاد أو كبّر وصغّر الصفحة، وستحصل على صورة غير واضحة. أمّا مع SVG، ستتخلص من مشكلة الحجم، وستحصل على وضوحٍ دائم. يمكنك إنشاء صور SVG صغيرة وتغيير أبعادها وفق احتياجاتك دون التضحية بوضوح الصورة. نتيجة صورة GIF صورة SVG متحركة GIF مثل تنسيقات الصور الأخرى تمامًا، غير مستقلة الدقة، ولذا ستبدو غير واضحة عند تغيير حجمها أو عرضها بدقة أعلى صورة SVG قابلة لتغيير الحجم ومستقلة الدقة، وستبدو واضحةً بأي دقة شاشة الألوان والشفافية ربما يكون السبب الأول لتبتعد عن التعامل مع صور GIF هو الطريقة التي يتعامل بها مع الشفافية، خاصةً عندما يتم عرض الصورة على خلفية غير الخلفية البيضاء. هذه مشكلة تظهر غالبًا عند استخدام أيقونات GIF (سواءً كانت متحركة أم لا)، عندما يتم إنشاء الأيقونات عادةً بخلفيات شفافة. مثلًا، فكر مليّا بالدائرة التالية المحاطة بحدّ، أُنشئت كصورة SVG (يسار) وGIF بخلفية شفافة (يمين). المشكلة واضحة بمجرد النظر إلى الصورتين: تحتوي دائرة GIF على حواف رمادية حول حدّها. إذا كنت لا تعاينها في المتصفح، فقد لا يكون التأثير مرئيًا لك لأنّه من الممكن ألا يتم تطبيق أنماط الشكل. فيما يلي لقطة توضح المشكلة (على اليمين): يحدث هذا لأن الشفافية في صور GIF ثنائية. هذا يعني أن كل بكسل إما يعمل أو لا يعمل؛ البكسل سيظهر إما شفافًا أو ممتلئًا بشكلٍ كامل. وهذا بدوره يعني أنّ الانتقال بين اللون الأمامي ولون الخلفية ليس سلسًا، والتشوهات الناتجة تظهر بسبب تردد العينات غير المناسب، والمعروفة باسم التعرج. عندما لا يكون الخط مستقيمًا تمامًا، فإنّه يتسبب بأن تكون بعض البكسلات (حول الحواف) شفافة جزئيًا وممتلئة جزئيًا ، لذلك يحتاج البرنامج إلى معرفة اللون الذي يجب استخدامه لهذه البكسلات. تأثير الهالة "ناتج عن كل البكسلات التي كانت ممتلئة أكثر من 50٪ امتلاءً كاملاً وتحمل لون الخلفية بدلاً من اللون الذي تم تنقيطه" كريس ليلي. لذلك يكون هذا التأثير عادةً ناتجًا عن تلوث البكسل من لون الخلفية التي تتكون الصورة على أساسه مقارنةً بما هي عليه عند إنشائها/حفظها في محرر الرسومات. عادةً ما يحاط التعرج بمكافح تعرج، ولكن هذا ليس بالأمر البسيط عندما تكون الشفافية ثنائية: حلّ هذه المشكلة هو الشفافية المتغيرة، والمعروفة باسم قناة ألفا، والتي تسمح بدرجات متفاوتة من الشفافية وبالتالي انتقالًا أكثرَ سلاسةٍ بين اللون الأمامي ولون الخلفية، وهذا غير متوفر في GIF؛ وبالتالي، هذا يسبب مشكلة تأثير الهالة. تظهر الصور ذات تأثير الهالة أفضل عادةً عند استخدامها مع خلفيات بيضاء؛ أي لون خلفية آخر عالي التباين سيجعلها تبدو مشوهةً. لست متأكدةً تمامًا مما إذا كانت هناك طريقة لحل هذه المشكلة، لكنني لم أجد بعد صورة GIF ذات خلفية شفافة وحواف منحنية لم تكن بها هذه المشكلة. لقد رأيت الأشكال المستطيلة تعاني منها أيضًا. إذا كنت ترغب في استخدام صورتك/أيقونتك على خلفية غير بيضاء - مثلًا، على خلفية تذييل داكنة، قد يكون هذا لوحده يبعدك عن التعامل مع GIF، ولكن هناك أسباب أخرى تجعل استخدام SVG أفضل من GIF أيضًا، والتي سنغطيها في الأقسام التالية. ملاحظة: إذا كنت تقرأ هذه المقالة باستخدام المتصفح ولكنك لا ترى الحواف في الصورة الأولى على شاشة أصغر، فحاول تكبير الصفحة لترى التأثير. لماذا من الممكن ألا تكون قادرًا على رؤية الحواف على أحجام أصغر؟ الإجابة هي: ينعّم المتصفح الحواف كجزءٍ من عملية تغيير حجم الصورة. هل هذا يعني أنّه يمكنك استخدام هذا للتخلص من الحواف والاستمرار باستخدام GIF؟ نعم تستطيع. ولكن للقيام بذلك، يجب عليك استخدام صور GIF بحجم أكبر بكثير من الحجم الذي تريد أن تكون الصورة به، ثم تغيير حجمها. هذا يعني أيضًا أنك ستعرض صورًا للمستخدمين أكبر بكثير مما يحتاجون إليه، وبالتالي استهلاك المزيد من النطاق الترددي على الهاتف المحمول، بالإضافة إلى الإضرار بالحجم العام للصفحة وأدائها. رجاءً لا تفعل ذلك. نتيجة صورة GIF صورة SVG متحركة صور GIF قادرة على الشفافية الثنائية فقط. يسبب هذا التشوهات، المعروفة باسم تأثير الهالة التي تظهر كلما تمّ استخدام الصورة أو الأيقونة مع خلفية غير بيضاء كلما كان تباين لون الخلفية مع الصورة أعلى، كان تأثير الهالة أكثر وضوحًا مما يجعل الأيقونات غير قابلة للاستخدام عمليًا. تأتي صور SVG مع قناة ألفا ولا تعاني من أيّة مشاكل عند استخدامها مع ألوان خلفية مختلفة. تقنيات الصور المتحركة وأداؤها يمكنك تحريك صور SVG باستخدام CSS أو جافاسكربت أو SMIL، وتمنحك كلٌّ منها مستوىً مختلفًا من التحكم يمكنك الاستفادة منه لإنشاء جميع أنواع الصور المتحركة على عناصر SVG. لا توجد "تقنيات" لتحريك صور GIF. يتم تحريكها من خلال عرض سلسلة من الصور - صورة لكل إطار - بشكلٍ تسلسلي، بأسلوبٍ ثابتٍ وسرعةٍ ثابتةٍ. تعلم أنّ هذه الطريقة التي تعمل بها صور GIF فقط. ومن المؤكد أنّه يمكنك الإبداع مع أيقوناتك قبل تحويلها إلى صور GIF ثم "تسجيل" الحركات وتحويلها إلى GIF، ولكن ما مدى جودة مظهرها؟ وما مدى السيطرة على وقت الحركة التي ستحصل عليها بعد ذلك؟ لا شيء. لن تبدو الحركة سلسةً ما لم تتأكد من أن لديك 60 إطارًا على الأقل - أي 60 صورة - في الثانية لإنشاء صورتك الـ GIF. بينما مع SVG، فإنّ الحصول على صورٍ متحركةٍ سلسةٍ أسهل وأبسط بكثير من خلال الاستفادة من تحسينات المتصفح. حجم صور GIF أكبر من حجم صور PNG أو JPEG، وكلما طالت مدة حركة صورتك، زاد حجمها. ماذا لو أردت الآن تشغيل صورتك المتحركة لمدة 5 إلى 6 دقائق على الأقل؟ ماذا لو أردت تشغيلها لفترة أطول؟ ستحصل على الصورة. لنلقِ نظرةً أكثر تحديدًا على مثالٍ بسيط. يوجد أدناه صورتان: صورة SVG متحركة على اليسار وصورة GIF متحركة على اليمين. يتغير لون المستطيل في كلتا الصورتين بفترة ست ثوانٍ. يوجد العديد من الأشياء لملاحظتها هنا: تبدو صور GIF المتحركة سلسةً، لكن إذا ألقيت نظرةً قريبةً ستلاحظ أنّ مستطيل SVG يمر بمجموعة أكبر من الألوان عندما ينتقل من اللون الأولي إلى اللون النهائي. عدد الألوان التي يمر بها GIF محدودًا بعدد الإطارات. في الصورة أعلاه، تمر صورة الـ GIF بـ 60 إطارًا، أي 60 لونًا، بينما يمر SVG عبر الطيف بأكمله بين ظل اللون الوردي المستخدم واللون الأخضر النهائي. بالنسبة لتكرار الصور المتحركة مثل هذه، من الأفضل عمومًا تجنب قفزة اللون الظاهرة في الصورة المتحركة أعلاه، وإنشاء الصورة المتحركة بحيث تنعكس ما إن تصل إلى اللون الأخضر؛ بهذه الطريقة، ستنتقل بسلاسة إلى اللون الوردي ثم تبدأ الجولة الثانية من الصورة المتحركة من هناك أيضًا، مع تجنب قفزة الألوان القبيحة. مع CSS، يمكنك عكس حركة الصورة باستخدام قيمة اتجاه الحركة alternate. ولكن مع GIF، ستحتاج إلى العمل على عدد إطاراتك وربما ينتهي بك الأمر إلى مضاعفتهم لتحقيق ذلك؛ سيؤدي هذا بالطبع إلى زيادة حجم الصورة أيضًا. أحجام الصورتين الظاهرتين في الأعلى: حجم صورة GIF هو 21.23 كيلوبايت حجم صورة SVG هو 0.355 كيلوبايت هذا ليس فرقًا بسيطًا. ولكننا نعلم جميعًا أنه يمكننا تحسين صورنا. لذلك دعونا نفعل ذلك. يؤدي تحسين SVG باستخدام واجهة المستخدم الرسومية SVGO بالسحب والإفلات إلى تقليل حجم ملف الـ SVG إلى 0.249 كيلوبايت. لتحسين صورة الـ GIF، يمكنك استخدام واحدة من العديد من أدوات تحسين GIF عبر الإنترنت. لقد استخدمت ezgif.com لتحسين الصورة أعلاه. (توجد أدوات أخرى أيضًا؛ مثل gifsicle.) انخفض حجم الملف إلى 19.91 كيلوبايت. هناك العديد من الخيارات التي يمكنك الاختيار من بينها عند تحسين صور GIF. قمت بتحسين الصورة أعلاه بحيث يبقى عدد الإطارات نفسه، باستخدام ضغط Lossy GIF، الذي "يمكن أن يقلل من حجم ملف GIF المتحرك بنسبة 30 ٪ - 50 ٪ بتكلفة بعض التدرج / التشويش". يمكنك أيضًا تحسينها عن طريق إزالة كل إطار ذو الرقم n؛ مما يمكن أن يقلل من حجم الملف إلى أبعد حد، ولكن على حساب حركة الصورة التي لم تعد سلسةً بعد الآن. وفي حالة الصور المتحركة مثل الحالة المدروسة الآن، فإن إزالة الإطارات سيجعل التغيير في اللون "سريعًا" وملاحظًا. تتوفر أيضًا خيارات أخرى للتحسين مثل تقليل الألوان (الذي لن يكون مناسبًا للصور المتحركة المعتمدة على الألوان هنا) وخفض الشفافية. يمكنك معرفة المزيد حول هذه الخيارات في صفحة التحسين في موقع ezgif.com. للتلخيص: إذا كنت أردت أن تكون صورك الـ GIF المتحركة سلسةً، ستحتاج إلى المزيد من الإطارات في الثانية، وسيؤدي ذلك بالتالي إلى زيادة حجم الملف كثيرًا. بينما مع SVG، من المحتمل أن تحتفظ بحجم ملف أصغر بكثير. المثال أعلاه صغيرٌ، وأنا متأكد من وجود أمثلة أفضل، ولكني أردت أن يوضح المثال البسيط الفرق بين الصيغتين. حتى إذا كنت تحرّك المستطيل أعلاه باستخدام جافاسكربت أو حتى إطار عمل جافاسكربت — نظرًا لأن الصور المتحركة SVG لا تعمل في متصفح IE، مثلًا، من المحتمل أن يكون حجم ملف إطار العمل المقترن بحجم SVG أصغر أو يساوي على الأقل حجم صورة GIF. مثلًا، باستخدام GreenSock’s TweenLite، سيكون حجم SVG مع المكتبة المدمجة أقل من 13 كيلو بايت (والذي لا يزال أقل من حجم GIF)، إذ انّ حجم TweenLite المصغر هو 12 كيلو بايت. إذا انتهى بك الأمر إلى حجمٍ مساوٍ لحجم GIF، فإن الفوائد الأخرى لـ SVG ستزيد من الحجم وستحصل على المزيد منه. توجد بعض مكتبات جافاسكربت الأخرى التي تركز على مهام حركة معينة في وقت واحد، وتأتي بأحجام ملفات صغيرة بشكلٍ ممتاز (أصغر من 5 كيلوبايت)، مثل Segment التي تستخدم لتحريك مسارات SVG لإنشاء تأثيرات رسم خطية. حجم Segment المصغر هو 2.72 كيلو بايت. هذا ليس سيئًا للغاية، أليس كذلك؟ يمكن أن يكون هناك استثناءات، لذلك يجب عليك دائمًا الاختبار. ولكن بالنظر إلى طبيعة صور GIF وكيفية عملها، فمن المحتمل أن تجد أن SVG يُعدُّ خيارًا أفضل في معظم الحالات. ملاحظة: أداء SVG ليس في أفضل حالاته اليوم، ولكن نأمل أن يتغير هذا في المستقبل. توفر متصفحات IE/MS Edge أفضل أداء لعرض SVG بين جميع المتصفحات اليوم. على الرغم من ذلك، ستظل صور SVG المتحركة تبدو أفضل من صور GIF المتحركة، خاصةً عند التعامل مع الصور ذات الحركة الطويلة، لأنّ حجم ملف GIF - بافتراض تسجيلها بمعدل 60 إطارًا في الثانية - سيكون له تأثيرًا سلبيًا على الأداء العام للصفحة. تقدم المكتبات مثل GreenSock أداءً رائعًا أيضًا. نتيجة صورة GIF صورة SVG متحركة - صور GIF أكبر حجمًا عمومًا من صور SVG. حركة الصورة الأكثر تعقيدًا والأطول مدةً، تتطلّب عدد إطارات أكبر لإنشائها ولهذا يكون حجم الملف أكبر ويؤثر سلبًا على الأداء - ما لم تعمل حركة الصورة بمعدل 60 إطارًا في الثانية، فإنّ الحركة ستصبح مسننة وغير سلسة. أيضًا زيادة عدد الإطارات في الثانية سيؤدي إلى زيادة حجم الملف خاصةً للحركات الطويلة نتيجة: سيكون هناك حل بسيط يجب القيام به. إمّا أن تكون حركة صورة GIF ناعمة وسيتأثر الأداء وحجم الملف الكلي وحجم الصفحة بشكلٍ سلبي، أو ستعاني الصورة المتحركة GIF من إطارات أقل. سيتم المخاطرة بأحد أشكال الأداء في كلا الحالتين تستفيد صور SVG من تحسينات المتصفح عند تحريك العناصر. على الرغم من أنّ أداء المتصفح على عناصر SVG لا تزال في أفضل حالاتها، إلا أنّ الصور المتحركة ستبقى تعمل بشكلٍ جيد بدون الحاجة لتقديم تنازلات في أداء الصفحة لا يزال حجم ملف SVG معقولًا جدًا، إن لم يكن صغيرًا جدًا، مقارنةً بـ GIF، حتى عندما قد نحتاج إلى مكتبات معينة للصور المتحركة لإنشاء صور متحركة عابرة للمتصفحات إصلاح وتعديل الصور المتحركة إنّه من المحزن أن تستخدم صور GIF. ستحتاج إلى استخدام محرر رسومات مثل Photoshop أو Illustrator أو After Effects، على سبيل المثال لا الحصر. وإذا كنت مثلي، فلن يكون محرر الرسومات المكان الذي تصقل فيه مهاراتك، وستشعر أكثر أنّك في مكانك الصحيح أكثر عند إجراء تعديلات في الشيفرة، وليس في برامج تحرير الرسومات. ما الذي يحدث إذا كنت ترغب في تغيير توقيت صورتك المتحركة؟ أو إذا كنت تريد تغيير وظائف التوقيت لعنصرٍ واحدٍ أو عدة عناصر داخل صورتك؟ أو إذا كنت ترغب في تغيير الاتجاه الذي يتحرك فيه عنصرٍ ما؟ ماذا لو كنت تريد تغيير التأثير بالكامل وجعل العناصر في صورتك تفعل شيئًا مختلفًا تمامًا؟ ستحتاج إلى إعادة إنشاء الصورة أو الأيقونة مرةً أخرى. يتطلب منك أي تغيير الانتقال إلى محرر الرسومات والعمل مع الإطارات وواجهة المستخدم المعتمدة على الإطار. سيكون ذلك بمثابة تعذيب للمطورين، ومهمةً مستحيلةً لأولئك الذين لا يعرفون طريقتنا بالتعامل مع هذه المحررات بشكلٍ كافٍ لإجراء هذه التغييرات. مع SVG، فإن إجراء أي نوع من التغيير على الصورة المتحركة (الصور المتحركة) لا يُعدُّ سوى بضعة أسطر من الشيفرة. نتيجة (من وجهة نظر المطور) صورة GIF صورة SVG متحركة إصلاح وتعديل الصور المتحركة GIF يتطلّب إعادة إنشاء الصورة أو اللجوء إلى واجهة المستخدم في محرر الرسومات المعتمد على الإطارات للقيام بذلك، ويعدّ هذا مشكلة للمطورين في مواجهة التصميم عادةً، يمكن أن تتغير صور SVG ويتم التحكم بها بشكلٍ صحيح داخل شيفرة SVG - أو في أي مكان تم تعريف الصور المتحركة به، باستخدام عدة سطور من الشيفرة. حجم الملف، ووقت تحميل الصفحة والأداء في القسم السابق، ركزنا على أداء الصور المتحركة نفسها. في هذا المثال، أريد إلقاء بعض الضوء على أداء الصفحة ككل وكيفية تأثرها باختيار صيغة الصورة الذي تقوم به. في الحقيقة: كلما زاد حجم الملف، زاد التأثير السلبي على وقت تحميل الصفحة والأداء. بأخذ ذلك بالحسبان، لنرى كيف يمكن أن يساعد استخدام SVG بدلاً من GIF في تحسين إجمالي وقت تحميل الصفحة من خلال النظر إلى مثالٍ أكثر واقعيةٍ وعمليةٍ. في حديثي الأول عن SVG، منذ 18 شهرًا، ذكرت كيف يمكن استخدام SVG لاستبدال صور GIF المتحركة وكيف تؤدي إلى تحسين أداء الصفحة بشكلٍ عام. في ذلك الحديث، قدمت مثالًا واقعيًا لصفحة ويب واقعية استفادت مما توفره SVG وحصلت على الفوائد: الصفحة الرئيسية لـ Sprout. تحتوي صفحة الرئيسية لـ Sprout على صورتين متحركتين تم إنشاؤهما في البداية وعرضهما بشكل صور GIF. قبل عامين، كتب Mike Fortress مقالًا في مدونة Oak، يوضح فيه كيف قاموا بإعادة إنشاء صور GIF متحركة، خاصةً مخطط GIF (انظر الصورة أدناه) كصورة SVG متحركة. يشارك Mike في مقالته بعض الأفكار المثيرة للاهتمام حول أدائهم الجديد للصفحة كنتيجةٍ للتغيير إلى SVG: إنّه بالفعل فرقٌ كبيرً. مخطط Sprout هو المرشّح المثالي لـ SVG. لا يوجد سبب لتحريكها عن طريق تحويل الصور المتحركة إلى تسجيل GIF، عندما يمكن لـ SVG أن تحقق الكثير من الفوائد. يدرك Jake Archibald قوة صور SVG المتحركة أيضًا ، ويستخدمها لإنشاء الرسوم التوضيحية التفاعلية وتحريكها لاستكمال مقالاته. مقاله كتاب الطبخ دون اتصال يعتبر مثالًا ممتازًا (وبالمناسبة مقالًا ممتازًا). هل كان بإمكانه استخدام صور GIF للقيام بذلك؟ بالتأكيد. ولكن بالنظر إلى عدد الصور التي استخدمها، كان من الممكن أن تزيد صور GIF بسهولة الحجم الكلي للصفحة إلى 2 ميغابايت أو أكثر، بحيث يكون حجم كل GIF على الأقل مئات الكيلوبايت؛ في حين أن صفحة الويب بأكملها تبلغ حاليًا 128 كيلو بايت فقط مع جميع صور SVG المضمنة داخليًا، لأنّه يمكنك إعادة استخدام العناصر في SVG، لذا فإن أيّة عناصر متكررة لن تتسبب فقط في أن الصفحة بأكملها ستستعمل برنامج gzip كثيرًا، ولكن لكل صفحة سيصبح الحجم الكلي لصور SVG أصغر. الآن هذا رائع! سأبقي حالتي حول تحميل الصفحة والأداء هنا. ولكن لا يزال من المهم الإشارة إلى أنّه يمكن أن يكون هناك استثناءات. مرةً أخرى، في معظم الحالات، من المحتمل أن تجد أن SVG أفضل من GIF، لكنك ستحتاج دائمًا إلى الاختبار على أي حال. نتيجة صورة GIF صورة SVG متحركة صور GIF أكبر حجمًا بشكلٍ عامٍ من صور SVG مع الحركات المضافة لهم. وهذا يؤثر سلبًا على حجم الصفحة الكلّي ووقت التحميل والأداء. يمكن أن تُستعمل صور SVG وأن يُعاد استخدامها، مما يجعل حجم الملف أصغر عمومًا من GIF وهذا يحسّن من وقت تحميل الصفحة والأداء دعم المتصفح ربما تكون الميزة الوحيدة المتفوقة لصور GIF على صور SVG هي دعم المتصفح. تعمل صور GIF إلى حدٍ كبير في كل مكان، في حين أن دعم SVG أقل انتشارًا. على الرغم من أن لدينا العديد من الطرق لتوفير النسخ الاحتياطية للمتصفحات غير الداعمة - ويجب ألا يعوق دعم المتصفح الحالي أي شخص عن استخدام SVG، إنّ الصور الاحتياطية، إذا تم توفيرها كـ PNG أو JPG، ستكون ثابتة وبدون حركة. بالطبع ، يمكنك دائمًا تقديم GIF كخطوة احتياطية لـ SVG، ولكن يجب مراعاة الاعتبارات والعيوب المذكورة سابقًا. نتيجة صورة GIF صورة SVG متحركة تعمل صور GIF تقريبًا في كل مكان صور SVG يدعمها عدد أقل من المتصفحات، لكنها تأتي مع طرق كثيرة لتوفير صور احتياطية للمتصفحات التي لا تدعمها مخاوف سهولة الوصول (a11y#) انقل شيئًا ما إلى صفحة، أو أيّ مكان، لهذه القضية، لقد أضفت للتو تسليةً - شيءٌ ما من المؤكد أنّه سيجذب انتباه المستخدم بمجرد أن يبدأ التحرك. هكذا يعمل الدماغ البشري ببساطة. يعدُّ هذا أيضًا أحد الأسباب التي تركز عليها لافتات الإعلانات - وهي مبنية على - تركيزٍ قوي على الصور المتحركة. وهذا هو السبب في أنّ لافتات الإعلانات المتحركة مزعجةٌ للغاية. إنها تشتت الانتباه، خاصةً عندما تحاول أداء مهمة على صفحة تتطلب اهتمامك بالكامل، مثل قراءة مقال. تخيّل الآن صفحة بها مجموعة من الأيقونات المتحركة (أو الصور) التي لن تتوقف عن الحركة بغض النظر عما تفعله. لم نعد نتحدث عن صورة أو صورتين على الصفحة الرئيسية أو داخل مقالة هنا؛ نحن نتحدث عن متحكمات وعناصر واجهة المستخدم، والأيقونات الأصغر التي من المحتمل أن تكون موجودة في أماكن متعددة على الصفحة، وعلى صفحات متعددة. ما لم يكن من المفترض أن تكون الأيقونة عبارة عن رسوم متحركة بشكلٍ غير محدود - مثلًا، إذا كانت عبارة عن دوران متحرك أثناء مرحلة انتظار غير نشطة للمستخدم، فمن المحتمل أن تسبب مشكلة، وتصبح مصدر إزعاجٍ أكثر من كونها "شيئًا جميلًا". في الواقع، يمكن أن يصبح الأمر أكثر إزعاجًا لبعض الناس، لأن الحركة المستمرة يمكن أن تجعل بعض الناس حرفيًا يشعرون بالمرض. تناقش المصممة ومستشارة صور الويب المتحركة Val Head في مقالتها "تصميم رسوم متحركة للويب أكثر أمانًا من أجل حساسية الحركة" تأثيرات الصور المتحركة المفرطة الاستخدام في الويب على الأشخاص الذين يعانون من اضطرابات الدهليزية المتسببة بصريًا (منجم التركيز): تخيّل الآن ما إذا كانت الصور المتحركة لا تنتهي … مضاعفات مزدوجة. تشرح مقالة Val المشكلة بمزيدٍ من التفصيل، حيث تجمع ردود فعل من شخصين يواجهان هذه المشاكل بالفعل ويشاركان تجربتهما مع الصور المتحركة بأمثلةٍ مختلفةٍ. أحد الحلول التي يمكن أن تساعد في تجنب هذه المشاكل هو تزويد المستخدم بالقدرة على التحكم في الصور المتحركة حتى يتمكنوا من إيقافها عندما تصبح مزعجةً. يمكنك القيام بذلك باستخدام SVG. يمكنك التحكم بشكلٍ كاملٍ في الصور المتحركة وتشغيلها مرةً واحدة أو مرتين عند تحميل الصفحة - إذا كنت تحتاج حقًا إلى تشغيلها بمجرد قيام المستخدم "بالدخول" إلى صفحتك، ثم إظهارها عند تمرير مؤشر الفأرة لمرات متتالية، باستخدام سطورٍ قليلةٍ من الـ CSS أو جافاسكربت. لا تحتاج إلى المئات أو الآلاف من أسطر CSS أو جافاسكربت لإنشاء صورةٍ متحركةٍ للأيقونة، إلا إذا كانت أيقونتك مشهدًا معقدًا بالفعل فيها الكثير من المكونات المتحركة. لكنني أعتقد أنّه في هذه الحالة، لم تعد تمثل "أيقونةً" بعد الآن، وأنّها أصبحت عبارةً عن صورةٍ عاديةٍ أكثر. يمكنك الوصول إلى أقصى قدر من التحكم في إعادة التشغيل، والسرعة لكل تشغيلٍ لاحقٍ، وأكثر من ذلك بكثير، بفرض، بالطبع، أنّك تستخدم جافاسكربت للحصول على هذا المستوى من التحكم. أو يمكنك إضافة تبديل لمنح المستخدم القدرة على إيقاف تشغيل الصور المتحركة بلا حدود. لا يمكنك فعل ذلك باستخدام GIF … إلا إذا اخترت استبدال GIF بصورة ثابتة عند إجراء تبديلٍ معينٍ. قد يجادل البعض بأنّه يمكنك عرض نسخة ثابتة من الصورة – مثل صورة PNG مثلًا، ثم توفير إصدار GIF عند تمرير مؤشر الفأرة. ولكن هذا يسبب بعض المشاكل: إذا كانت الصورَ مضمنةٌ، فستحتاج إلى استبدال هذه الصور باستخدام جافاسكربت. هذا الإجراء لا يتطلب أي جافا سكربت إذا كنت تستخدم SVG. إذا كانت الصور عبارة عن صور أمامية (مضمنة في HTML باستخدام <img>)، وتحتاج إلى استبدال هذه الصور، فسينتهي بك الأمر إلى مضاعفة كمية طلبات HTTP لكلّ صورة. وإذا كانت صور الخلفية مضمنة في صفحة الأنماط (هذا غير مستحسن)، فإنّ الصور (خاصةً صور GIF) ستزيد حجم صفحة الأنماط وبالتالي تزيد الوقت الإجمالي لحظر عرض الصفحة. إذا كنت تبدّل/ عندما تبدّل مصادر الصورة عند تمرير مؤشر الفأرة، فهناك وميض ملحوظ بين الصورة الأولى والثانية في الاتصالات البطيئة. اتصالي بطيء؛ أحيانًا اتصال 3G بطيء، ولم أتذكر بعد وقتًا تم فيه استبدال صورة بأخرى عند تمرير مؤشر الفأرة، أو تم تغيير حجم منفذ العرض، أو أي شيء آخر، ولم أشاهد هذا الوميض. يزداد هذا الموقف سوءًا عندما تكون الصورة الثانية (GIF التي تحمّل عند تمرير مؤشر الفأرة) كبيرة الحجم إلى حدٍ ما — سيكون هناك وميض، تتبعه صورةً متحركةٌ بطيئةٌ غير متقنةٍ لـ GIF أثناء تحميلها بالكامل. هذا ليس جذابًا أبدًا. لذا، نعم، يمكنك تبديل مصادر الصورة للتحكم إذا أو عندما تشتغل الصور المتحركة GIF أو متى يتم ذلك، لكنك تفقد التحكم الدقيق في GIF وتؤثر على تجربة المستخدم مع واجهة المستخدم. يمكنك أيضًا التحكم في عدد المرات التي يتم فيها تشغيل الصور المتحركة في GIF - وهو أمرٌ رائعٌ، لكن هذا يعني أن الصور المتحركة ستعمل فقط عددًا محددًا من المرات. ثم لإعادة تشغيل الصور المتحركة عند تفاعل المستخدم، ستحتاج إلى اللجوء إلى الأسلوب أعلاه مع صور متعددة. يمكن تحقيق الصور المتعددة التي تحتاج إلى إصلاح، وطلبات HTTP المتعددة، والحل العام المُستهلَك غير الأمثل بصورة SVG واحدة. ضمّن صورة SVG واحدة على الصفحة. أنشئ الصورة المتحركة بالطريقة التي تريدها/تحتاجها. (أو أنشئ الحركة قبل تضمين الصورة.) شغّل وأوقف وتحكّم بالصورة المتحركة. وأمنح المستخدم القدرة على التحكم فيها أيضًا. لا توجد طلبات HTTP إضافية لكل صورة، ولا صيانة معقدة للخط الزمني للصورة المتحركة في محرر الرسومات، ولا توجد أي مخاوف تتعلق بسهولة الوصول أو مشاكل لا يمكن تجنبها ببضعة سطور من التعليمات البرمجية. نتيجة صورة GIF صورة SVG متحركة صور GIF لا يمكن إيقافها من قبل المستخدم بدون طلب صور إضافية وطلبات HTTP إضافية. لا تتم السيطرة بشكلٍ كاملٍ حتى يتم ذلك يمكن تخصيص صور SVG المتحركة بشكلٍ كامل لذا يمكن تفعيلهم وتعطيلهم والتحكم بهم من قبل المستخدم بدون الحاجة إلى طرق مستهلَكة سهولة الوصول إلى المحتوى صورة GIF صورة SVG متحركة صور GIF سهلة الوصول مثل صور PNG وJPEG باستخدام قيمة الخاصية `alt` لوصفهم. لا يمكن تمييز المحتوى الموجود داخل الصورة أو إتاحته مباشرةً لقارئات الشاشة بما يتجاوز الوصف العام للصورة يمكن الوصول إلى صور SVG ودلالتها. يمكن أيضًا وصف المحتوى المتحرك داخل الصورة وجعله قابلًا للقراءة من قِبل قارئات الشاشة باستخدام عناصر سهولة الوصول المدمجة في SVG، كما يمكن تحسينها باستخدام أدوار ARIA وخاصيّاتها أيضًا. (يمكنك أن تقرأ [هنا](https://www.sitepoint.com/tips-accessible-svg/) كل شيء عن جعل SVG قابلة للوصول) التفاعل لا يوجد الكثير لإضافته هنا، ولكن الحقيقة أنّه يمكنك التفاعل مع العناصر الفردية داخل SVG، أثناء أو قبل أو بعد تحريك الصورة، لكن هذا غير ممكن مع GIF. لذا، إذا كنت تستخدم GIF، فستفقد القدرة على فعل أي شيء يتجاوز تشغيل الصور المتحركة أو إيقافها، وحتى هذا لم يتم تنفيذه فعلاً باستخدام الـ SVG، كما رأينا، ولكن يتم تحقيق ذلك عن طريق مبادلة GIF بالخارج ببديلٍ ثابت. حتى تغيير ألوان العناصر داخل GIF سيتطلب صورًا إضافية للقيام بذلك. هذه ميزة أخرى لاستخدام SVG بدلاً من GIF. نتيجة صورة GIF صورة SVG متحركة لا يمكن أن تكون الحركات المحددة في صور GIF تفاعلية، لا يمكنك التفاعل مع العناصر الفردية داخل عنصر GIF، ولا يمكنك إنشاء روابط خارج العناصر الفردية أيضًا. محتوى SVG تفاعلي بالكامل. يمكنك إنشاء التفاعلات مثل تمرير ماوس الفأرة والضغط (والمزيد) التي تستجيب لها العناصر الفردية داخل صورة SVG. استجابة وتكيّف الصور المتحركة إنّ القدرة على تحريك صورة SVG مباشرةً من الشيفرة، بالإضافة إلى معالجة العديد من خاصياتها، تعطي وتضيف ميزةً أخرى على الصور المتحركة المعتمدة على GIF: القدرة على إنشاء صور متحركة جيدة الأداء، سريعة الاستجابة وقابلة للتكيّف، دون إضافة أي طلبات HTTP إضافية باستخدام بضعة أسطر من الشيفرة وبأحجام ملفات أصغر. كتبت سارة دراسنر مقالةً في مجلة Smashing Magazine تُظهر طرقًا مختلفة لتحريك SVG sprites. تتمثل إحدى هذه الطرق في وجود "مشاهد" متعددة داخل الـ SVG، وتحريكها باستخدام CSS، ثم تغيير "عرض" الـ SVG - عن طريق تغيير قيمة خاصية الـ viewBox - لإظهار مشهدٍ واحدٍ في وقتٍ واحدٍ، اعتمادًا على حجم منفذ العرض الحالي ومساحة الشاشة المتاحة. إذا كنت ترغب في إنشاء نفس الحركات باستخدام صور GIF، فستفقد إمكانيات التحكم في الصور المتحركة، كما ستحتاج إلى صور متعددة ربما تكون أكبر (في حجم الملف) من صورة الـ SVG الواحدة. ولكن إذا كنت لا ترغب في استخدام شيفرة SVG المتحركة، فيمكنك دائمًا إنشاء SVG sprite وتحريكه بالطريقة التي يمكنك بها تحريك أي صيغة صورة آخرى - باستخدام ()steps وعدة أسطر CSS. تتحدث سارة أيضًا عن هذه التقنية في مقالتها. لا يحتاج تحريك صور SVG أن يكون معقدًا، وهو يقدم أداءً أفضل بشكلٍ عام. نتيجة صورة GIF صورة SVG متحركة بما أنّه لا يمكن التحكم بالمحتوى داخل صورة GIF بالشيفرة، فلا يمكن جعل الصور المتحركة تتكيف أو تستجيب لتغيّرات منفذ العرض أو السياق بدون اللجوء إلى فصل الصور. بما أنّه يمكن تحريك محتوى SVG بشكلٍ مباشر باستخدام الشيفرة، فإنّه يمكن تعديل المحتوى والحركات بحيث يستجيب و/أو يتكيّف مع سياقات وأحجام منافذ عرض مختلفة، بدون الحاجة إلى اللجوء إلى أي أصول إضافية. كلمات أخيرة تتمتع صور GIF بدعم جيد جدًا للمتصفح، نعم، ولكن مزايا صور SVG تفوق مزاياها في جميع الجوانب تقريبًا. قد تكون هناك استثناءات، وفي هذه الحالات، تستخدم صور GIF بالتأكيد أو أي صيغة صور آخرى تقدم عملًا أفضل من SVG. قد تستخدم حتى فيديو أو HTML5 Canvas أو أيًا كان. يمكن أن توفر SVG الكثير من مزايا الأداء إلى القائمة عند موازنتها مع صيغ الصور الأخرى، وخاصةً GIF. وبالتالي، وبالنظر إلى كل ما سبق، أوصي بأنه في أي مكان يمكن استخدام SVG للصور المتحركة، يجب تجنّب استخدام صور GIF. أنت حر بالطبع في تجاهل توصيتي لكنك ستتخلى عن المزايا الكثيرة التي توفرها صور SVG المتحركة. ما لم توفر صور GIF الكثير من المزايا على صور SVG التي لا تحقق دعم المتصفح IE8 وأقل منه، فإنني أعتقد أن صور SVG ينبغي أن تكون هي السبيل للانطلاق. بعض المصادر لمساعدتك على البدء مع صور SVG المتحركة: عالم الصور المتحركة SVG. عدة طرق مختلفة لاستخدام SVG sprites في الصور المتحركة. إنشاء الصور المتحركة مع SVG. لدى GreenSock مجموعة من المقالات المفيدة حول تحريك SVG. Snap.svg ويُعرف أيضًا بأنّه "مكتبة jQuery للـ SVG". الصور المتحركة SVG باستخدام CSS وSnap.SVG. تصميم وتحريك صور SVG مع CSS. رسم خط متحرك في SVG. أرجو أن تكون قد وجدت هذه المقالة مفيدةً. شكرًا للقراءة. ترجمة -وبتصرف- للمقال Animated SVG vs GIF [CAGEMATCH]‎ لصاحبته Sara Soueidan

حسب موقع smart insights فإن 80% من مستخدمي الإنترنت يمتلكون هاتفًا ذكيًا، هذا يعني ملايين الأشخاص الذين يتصفحون الإنترنت ويحاولون أن يجدوا منتجات ومعلومات خلال تصفحهم. ولإرضاء الزبائن المحتملين يجب على كل شركة أن تجعل موقعها الإلكتروني قابلاً للتصفح على الأجهزة المحمولة. ها هي بعض النصائح المستوحاة من تجربتنا الخاصة في شركة Sonifi لتساعدك على تصميم وبرمجة موقع إلكتروني متوافق مع الأجهزة المحمولة. النصيحة الأولى: كل المواقع الإلكترونية على الأجهزة المحمولة تحتاج للخاصية name="viewport"‎ في العنصر meta تذكر بأن ترفق الخاصية viewport من العنصر meta عند انشائك لموقع الكتروني خاص بالأجهزة المحمولة. حجم الإطار المعروض (viewport) هو عبارة عن حقل وهمي مستخدم من قِبَل محركات البحث لتحديد كيفية قياس وتحجيم محتوى الموقع الإلكتروني لذلك يعد تضمين الخاصية viewport ضروريًا جدًا عند بناء تجربة متعددة الأجهزة. حجم الإطار المعروض يخبر متصفح الهاتف بأنه يجب عليه أن يتوافق مع شاشة أصغر وبدونه فإن الموقع الإلكتروني ببساطة لن يعمل بشكل جيد على الأجهزة المحمولة. وبالرغم من أي إعدادات تقرر أن تستخدمها لتحديد ما يتحكم به منفذ العرض الخاص بك، تأكد من أن تضعه في العنصر head من الصفحة. "80% من مستخدمي الإنترنت يبحثون عن المنتجات عبر هواتفهم الذكية" النصيحة الثانية: الحجم مهم في المواقع المتوافقة مع الأجهزة المحمولة هل جربت من قبل أن تزور موقعًا إلكترونيًا واحتجت أن تضغط على زر معين ولكن الزر كان صغيرًا جدًا بحيث أنك ضغطت على زر أخر عن طريق الخطأ؟ أو هل جربت من قبل أن تكبِّر الشاشة لتقرأ شيئًا معينًا؟ هذا الأمر مزعجٌ جدًا ولذلك إنه من المهم أخذ الحجم بعين الاعتبار عند تصميم الموقع الإلكتروني، وليس فقط حجم الصفحة، بل أيضًا حجم الخطوط والأزرار. الخطوط حجم الخط للمواقع على الهواتف يجب أن يكون 14 بكسل على الأقل، وعلى الرغم من أن هذا الحجم قد يبدو أكبر مما تريد ولكنه يسهل على الزائر أن يقرأ الصفحة بدون أي تكبير للصفحة أو أي صعوبة. أما الخط الأصغر يمكن أن يستخدم في العناوين والنماذج وبإمكانك تقليصه حتى 12 بكسل. الأزرار دائمًا تذكر هذا الإختصار «أ.أ.أ»: أي «الأزرار الأكبر أفضل»،إذ أن الأزرار الكبيرة تقلل من احتمالية الضغط بشكل خاطئ على زر آخر. بالنسبة لرواد الهواتف المحمولة مثل شركة "آبل" فهم ينصحون بأن يكون حجم الأزرار على الأقل 44 بكسل × 44 بكسل من أجل تحسين تجربة المستخدم وزيادة التحويلات في مواقع التجارة الإلكترونية. النصيحة الثالثة: النوافذ المنبثقة لا يجب استخدامها في تصميم مواقع الإنترنت الخاصة الأجهزة المحمولة كَون المتصفحات الخاصة بالهواتف لا تدعم النوافذ المنبثقة، فإن وجود هذه النوافذ يسبب الكثير من التشتت والقلق لتجربة المستخدم بشكل كامل، وحتى أصغر النوافذ تسبب هذا التشتت لمستخدمي الهواتف. وعلى مدار عملية التصميم، احرص جيدًا على تجنب استخدام النوافذ المنبثقة للحصول على أفضل النتائج واحرص ايضًا على تجنب التحديث الدوري للصفحة وذلك لعدم امتلاء ملفات ذاكرة التخزين المؤقت في الهاتف بل أعطِ المستخدم حرية التحكم في هذه العملية. النصيحة الرابعة: قلّل من استخدام الحقول الخاصة بالكتابة في قائمة التنقل لأنه وكما تعلم، من الصعب بعض الشيء إدخال النصوص والكتابة عند تصفح المواقع على الهاتف فينصح باستبدال هذه الحقول بأزرار او قوائم مما يمكن المستخدمين من اختيار ما يريدون بسهولة وبدون الوقوع في أي اضطرابات. وعليك الأخذ بعين الاعتبار بأن مستخدمي الأجهزة المحمولة لا يستطيعون استخدام لوحة مفاتيح او فأرة، على عكس مستخدمي الكمبيوتر، لذلك احرص على ايجاد طرق ابداعية أكثر لجعل تجربتهم هي نفسها وبدون اللجوء لاستخدام لوحة مفاتيح صغيرة او التصفح بصعوبة. بعض الحلول تشمل: القوائم القوائم المنسدلة الأزرار -خيارات الصور النصيحة الخامسة: استخدم وضع تصفح ذكي في تصميمك قد أجريتَ بالتأكيد بالعديد من الأبحاث قبل بنائك للموقع الإلكتروني لمحاولة فهم جمهورك وما يتوقعون وجوده في الموقع، قم بمراجعة المعلومات ثانيةً عند تطويرك لنموذج خاص بالأجهزة المحمولة لتستطيع تحديد كيف سوف يتصفح هذا الجمهور موقعك على الهاتف. إن كان جمهورك المستهدف من المستخدمين يرغب برؤية محتوى متجدد بشكل مستمر فعليك وضع قائمة التصفح أسفل المحتوى الرئيسي مما سيترك مساحة كافية للمحتوى والعناوين لتظهر أكثر وبدون إعاقة لمظهر الصفحة. أما إن كان المتابعون يريدون الوصول الدائم للتصفح حسب الفئة، إذن يجب عليك وضع قائمة التصفح في أعلى الصفحة. النصيحة السادسة: قم بتبسيط تصميم موقعك الإلكتروني حاول بأن تتخلص من المحتوى الغير ضروري في موقعك وقم بتبسيط التصميم الخاص بالصفحة لجعل الاستخدام أفضل، وتذكر بأن التصميم الخاص بالأجهزة المحمولة يدور حول نظرية الحد الأدنى (minimalism)، وتبسيط التصميم يساعد على تحسين الاستخدام. أنشئ موقعك بحيث تسمح للمستخدمين بتصفحه دون أي صعوبات وذلك عن طريق تجنب الجداول والإطارات والصيغ الأخرى. ودائمًا أبقِ الحشوة على أقل مستوى لأنه كلما زاد عدد المستخدمين الذين يضغطون على الروابط كلما زاد انتظارهم للتحميل، واجعل موقعك بسيطًا لخلق توازن بين المحتوى والتصفح. النصيحة السابعة: قسّم الصفحة لأجزاء صغيرة عملية عرض المحتوى الذي يتناسب تمامًا مع الشاشات الكبيرة للكمبيوتر وتعبئتها في أجهزة صغيرة ومحمولة باليد تشبه كثيرًا عملية ادخال قطعة مربعة في فتحة دائرية. قسّم الصفحة لأجزاء صغيرة بوضع الأقسام الطويلة من النصوص في عدة صفحات بدلاً من وضعها في صفحة واحدة طويلة تجعل المستخدمين يمررون بشكل مستمر لرؤية المحتوى وبإمكانك التخلص من المحتوى الأقل أهمية وعمل عمود واحد من النص لتجنب التمرير الأفقي في الصفحة. النصيحة الثامنة: قياس الصور يصنع فرقًا كبيرًا لمستخدمي الأجهزة المحمولة لاحظ جميع الصور المستخدمة في المحتوى وفي الخلفية، وتأكّد بأن الصورة مقاسها صحيح عند التصفح بالوضع العمودي أو الأفقي، وإذا كانت الصور لا تحقق الأبعاد المناسبة فعليك تغيير تنسيق صفحات في CSS لجعل الصورة بعرض 100% أو بأن تجعل الصورة نفسها مناسبة بداخل الصفحة (خاص بصور الخلفية). وباتباعك لهذه النصائح السهلة بإمكانك التأكد من أن تصاميمك مناسبة لكل من الحاسوب والهاتف وبالتالي يمكن للزائرين أن يحظوا بأفضل تجربة ممكنة. ترجمة -بتصرف- للمقال ‎8 tips for designing mobile-friendly websites لصاحبته: Sarah Almond

هل تساءلت عن كيفية عرض صفحة الويب على مختلف أحجام الشاشات؟ لتسهيل الأمر لنفكك السؤال باستخدام المثال التالي: لنتخيل أن تصميم صفحة الويب هو مخطط هندسي لمنزل جديد وجميل. الأساس الّذي يستند عليه المنزل يمثل استعلامات الوسائط (Media queries)، يليه الطابق الأرضي الذي يُحدد كيف ستُبنى بقية المنزل. هذا الطابق الأرضي هو ما نعده نقطة حدِّية. ما النقاط الحدية لصفحات الويب المتجاوبة؟ النقاط الحدِّية (Breakpoints)، بمفهوم تصميم صفحات الويب المتجاوبة، هي مجال من القيم مصحوبة باستعلام وسائط لتغيير تصميم الصفحة بمجرد أن يكون عرض نافذة المتصفّح داخلًا في المجال المذكور. سيتغير في مثال استعلام الوسائط التالي تصميم الصفحة من العرض الأساسي 960 بكسل عندما تُعرض على شاشة 768 بكسل: }(media only screen and (max-width: 768px@ /* هنا تكتب تعليمات CSS */ { تنشئ التعليمة أعلاه نقطة حدِّية عند وصول عرض نافذة المتصفح لأقل من 768 بكسل. النقاط الحدية القياسية تحتوي صفحات الويب التفاعلية عادةً على نقطتين حدِّيتين على الأقل تستهدفان أجهزة الجوال الذكية والأجهزة اللوحية. على خلاف أجهزة الحاسوب، اعتمدت النقاط الحدِّية لأجهزة الجوال والأجهزة اللوحية على أجهزة الآيفون والآيباد باعتبارهما الأكثر شيوعًا في كل من تصنيفي الهواتف الذكية والأجهزة اللوحية. رغم أن تلك الممارسة قابلة للنقاش، إلا أننا سنترك ذلك النقاش لوقت لاحق، ونصب تركيزنا في الاستعلامات التالية التي تمثل تلك القيم القياسية. الاستعلام الخاص بأجهزة الجوال @media only screen and (min-device-width : 320px) and (max-device-width : 480px) { /* هنا تكتب تعليمات CSS */ } الاستعلام الخاص بالأجهزة اللوحية @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) { /* هنا تكتب تعليمات CSS */ } تفاصيل إضافية الاستعلامان السابقان أساسيان لكنهما غير كافيين لتغطية جميع حالات الاستخدام. مثلاً إنشاء نقاط حدِّية اعتمادًا على الوضع الأفقي أو الرأسي للجهاز. الوضع الرأسي للجوال @media only screen and (max-device-width : 320px) { /* هنا تكتب تعليمات CSS */ } الوضع الأفقي للجوال @media only screen and (min-device-width : 321px) { /* هنا تكتب تعليمات CSS */ } الوضع الرأسي للجهاز اللوحي @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : portrait) { /* هنا تكتب تعليمات CSS */ } الوضع الأفقي للجهاز اللوحي @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : landscape) { /* هنا تكتب تعليمات CSS */ } إنشاء نقاط حدية مخصصة لماذا ننشئ نقاط حدية مخصصة؟ من المعروف أنه لا يوجد موقعان بُنيا بنفس الشكل. بوضع ذلك في الحسبان، من المنطقي التفكير أن موقعي ويب متجاوبين لا يمكن لتصميمهما المتفاعل الاكتفاء بالكامل باستخدام المعايير القياسية فقط للنقاط الحدِّية الخاصة بهما. هنا تنبع الحاجة لتحديد أين ومتى يحتاج تصميم موقعك لمزيد من النقاط الحدِّية حتى داخل مجال الاستجابة للنقاط القياسية السابق ذكرها. كيف تنشئ نقطة حدية مخصصة يمكن إنشاء نقطة حدِّية مخصصة بسهولة حيث لا يتطلب الأمر سوى معرفة بالتعامل مع استعلامات الوسائط، لكن من السهل هنا ارتكاب الأخطاء وإنشاء نقاط حدِّية عديمة الجدوى. لنفترض مثلًا أن موقعًا مّا يبدو سيئًا عند عرضه بنافذة تبلغ 355 بكسل. لإصلاح الخلل قد يقوم المطور بكتابة استعلام كهذا: @media only screen and (max-device-width : 355px){ /* CSS هنا تكتب تعليمات */ } مشكلة الاستعلام أعلاه أنه يحل مشكلة عرض محتوى الصفحة عند أجهزة عرضها 355 بكسل، لكنه يسبب مشاكل للأجهزة ذات عرض أقل من 355 بكسل. الطريقة السليمة لحل هذه المشكلة هي بإيجاد مدى العرض الذي يوجد به مشاكل عند عرض الصفحة لتخصيص مجال قيم يعالج هذه المشكلة. لنتخيل أن المشكلة تبدأ بالظهور عند عرض 340 بكسل وتستمر حتى 355 بكسل، هذا هو مجال الخلل. الاستعلام المخصص سيكون كالتالي: @media only screen and (min-device-width : 340px) and (max-device-width : 355px) and (orientation : portrait) { /* هنا تكتب تعليمات CSS */ } هل يجب الاعتماد في النقاط الحدية على نوع الجهاز أم مخطط الصفحة؟ تخيل الوضع التالي، موقع جديد متفاعل يبدو رائعًا على جميع مقاسات شاشات الأجهزة الشائعة، لكن لديه مشكلة. عندما يقترب العرض من 400 بكسل تخرج الأمور عن السيطرة. بما أنه من الصعب إيجاد أجهزة بمقاسات عرض قريبة من تلك النقطة قرر المطور تجاهلها وحسب. هل كان ذلك قرارًا حكيما؟ لا!. المغزى من التصميم المتجاوب هو إنشاء تصميم أفضل آخذًا بالحسبان جميع احتمالات أبعاد شاشات العرض. لضمان ذلك، يجب ألا يكون نوع جهاز العرض العامل الرئيسي لتحديد كيفية استجابة تصميم الموقع، ولا أن يكون أولوية حتى. من الأفضل أن نعد مقاسات أجهزة العرض الحالية نقاط ارتكاز أو مراجع للاستناد عليها. ما يجب أن نفعله في هذه الحالة هو التركيز على شكل الصفحة نفسها، وإيجاد عرض المتصفّح الذي يبدأ فيه التصميم بالظهور بشكل سيئ. لم سيجعلك هذا تبدو محترفًا في تصميم المواقع المتجاوبة؟ منذ انتشار أطر التصاميم المتجاوبة عالية الجودة، أصبح تعلم وتطبيق مهارات التصميم المتفاعل يزداد سهولة. ولكن كأي شفرة برمجية معدّة للبدء منها، فقط المبتدئون يستعملون تصاميم جاهزة يعتمدون عليها تمامًا في مشاريعهم. قدرتك على عرض تصميم المواقع بشكل صحيح على مختلف أنواع ومقاسات أجهزة العرض، وليس فقط المقاسات المعيارية، هي ما يحدد مستوى مهاراتك. ستُترجم المفاهيم العميقة بدورها إلى رؤية أفضل لأعمالك من قبل عملائك وتمنحك أساسًا أقوى لبدء التفاوض معهم. كيف تخصص نقطة حدية مثالية؟ أولاً: تأكد من تثبيت إضافة المتصفح المناسبة إضافات مثل Resize Window لمتصفح كروم مناسبة لمهام كالتي ذكرناها، لأنها ستظهر أبعاد النافذة الحالية أسفل يمين الشاشة عندما تغيّر قياس النافذة. ثانيًا: تأمّل في القيم بين النقاط الحدِّية الحسيّة هنا ستبحث عن قيم العرض - بالبكسلات - التي يختل عندها تصميم الموقع مستعملًا إضافة مثل Resize Window. عليك تغيير قيمة عرض نافذة المتصفح تصغيرًا وتكبيرًا لإيجاد مجالات العرض التي تظهر بها مشاكل التصميم وتوثيقها حتى لو تطلب ذلك فحص كل حجم العرض بكسلًا تلو الآخر. ثالثًا: أنشئ استعلامات الوسائط بنفسك استعمل ببساطة أبعاد العرض التى سجلتها سابقًا لكتابة استعلامات وسائط شبيهة بالمُدرجة أعلاه وستكون قد انتهيت! ماذا اغتنمت النقاط الحدِّية هي حيث يصل عرض نافذة موقعك لمقاس معين لينتقل إلى تصميم متناسب مع ذلك العرض. النقاط الحدِّية القياسية هي الخاصة بالجوال والجهاز اللوحي بالإضافة إلى اختلاف اتجاه عرضهما. من المهم دائمًا اختبار موقعك على أبعاد غير معتادة لتعزيز تماسك موقعك وتجربة الزوار. تأكد أن النقاط الحدِّية المخصصة لا تتعارض مع النقاط القياسية. التصميم المتفاعل هو محاولة للتحضير للمستقبل، لذا فإن قضاء وقت طويل في التركيز على الأجهزة الحالية ليست ممارسة جيدة. الحرص على جودة التصميم باختلاف أبعاد العرض سيجعلك تبدو محترفًا بالنسبة للعملاء. ترجمة - وبتصرّف - للمقال The Ultimate Overview of Responsive Web Design Breakpoints من إعداد فريق موقع 1stwebdesigner.

لم يعد إنشاء تصاميم متجاوبة اختياريًّا، فلقد أصبحت شبكات CSS وعلى نحو سريع الخيّار المفضّل لإنشاء بنى منسجمة لمواقع ويب تبدو بمظهر رائع على مختلف أنواع الأجهزة. تزوّدنا شبكات CSS بطريقة سريعة لبناء أيّ موقع. فلا بدّ أن تكون قد عانيت مع خصائص التموضع والتعويم float في CSS من قبل. كل هذه المعاناة ستنتهي مع شبكات CSS. تجعل شبكات CSS3 من عمليّة إنشاء وتعديل موقع، شيئًا يسيرًا للغاية. سنتعلّم كيف تعمل هذه الشبكات ولماذا ينبغي علينا استخدامها، وكيف ننشئ شبكاتنا الخاصّة بنا لبناء layouts مُخصّصة. ما هو نظام شبكة CSS؟ قبل أن نبدأ بإنشاء بنية خاصّة بنا، هناك بعض الأمور التي نحتاج أن نعرفها مسبقًا. لإنشاء مخطّط لموقع ويب جديد نبدأ أولّا بشبكة. ستحتوي هذه الشبكة الأساسيّة على أسطر rows وأعمدة columns وخلايا cells ومسارات tracks وخطوط lines ومناطق areas. هناك أيضًا عناصر الشبكة وهي بشكل أساسي عبارة عن المحتوى الذي نضعه ضمن الشبكة. تشبه الشبكة الجدول من ناحية الإظهار. ولكن يكمن الفرق الكبير بينهما في وجود خصائص مُحدّدة وقويّة متاحة ضمن شبكة CSS، سنتحدّث عنها بعد قليل. تحمل الأسطر والأعمدة والخلايا نفس المعنى في كلّ من شبكات CSS وجداول HTML العاديّة. أمّا المسار track فهو عبارة عن سطر كامل أو عمود كامل. المسار track في الشبكة، عبارة عن سطر كامل أو عمود كامل. وبالنسبة للمنطقة فهي مكوّنة من خلايا تشكّل حاويةً مستطيلة الشكل للمحتوى، في حين أنّ خطوط الشبكة grid lines هي الفواصل بين الخلايا في البنية الشبكيّة، وهي تشبه على أية حال حدود الخلايا في جداول HTML العاديّة. تشكّل المناطق مقاطع بنيويّة ذات طبيعة متنوّعة، مثل المناطق الخاصة بالعنوان header والشريط الجانبي sidebar والمحتوى الأساسي والتذييل footer. تشكّل المنطقة area مقاطع بنيويّة متنوّعة في الشبكة. بتعريف هذه المناطق باستخدام شيفرة CSS الجديدة المتاحة، يمكننا إنشاء وتنسيق البنية الشبكيّة المطلوبة، بنفس السرعة التي تحتاجها لإنشاء بنية جدوليّة قديمة، ولكن بمزايا قابلية التعديل والتغيير بسهولة أكبر بكثير. المشكلة الوحيدة في شيفرة CSS الجديدة هي أنّها حتى هذه اللحظة ليست متوافقة بشكل كامل مع جميع المتصفّحات، ولكن تبقى مسألة وقت قبل أن تصبح قياسيّة في المدى القريب، بحيث تعمل على جميع المتصفّحات الأساسيّة المعاصرة. يمكنك تجربة مزايا الشبكة الجديدة مع جميع المتصفّحات من خلال إضافة يمكن الحصول عليها من هنا. يمكننا في متصفّح Chrome تفعيل منصّة الويب التجريبيّة experimental web platform بكتابة العنوان التالي في شريط عنوان المتصفّح: Chrome://flags انتقل إلى الأسفل حتى تصل إلى قسم تفعيل مزايا منصّة ويب التجريبيّة Enable Experimental Web Platform features ثم انقر Enable تحت العنوان. يمكننا اختبار شبكات CSS3 في متصفّح Chrome بإجراءات بسيطة. انقر بعد ذلك زر إعادة التشغيل الآن Relaunch Now وهذا كلّ شيء. أصبحنا الآن مستعدّين لتجربة شبكات CSS في Chrome ضمن أنظمة تشغيل Windows و Mac و Linux وحتى أجهزة Android. إعداد الشبكات باستخدام HTML5 الآن وبعد تفعيل الأدوات التجريبيّة، يمكننا البدء بإنشاء البنية الشبكيّة. نحتاج إلى صفحة لاختبار تأثيرات شيفرة CSS، انشأ ملف index.html. نحن مستعدّون الآن لإضافة شيفرة HTML5 أساسيّة لعرض أي شبكة ننشئها بعد قليل. سننشئ منطقة خاصّة بالعنوان header وأخرى خاصّة بالتذييل footer بالإضافة إلى منطقة خاصّة بالمحتوى content ومنطقة للشريط الجانبيّ sidebar على الجانب الأيمن من الصفحة. لنضيف الشيفرة التاليّة إلى الصفحة: <div id="grid"> <div class="header"></div> <div class="sidebar"></div> <div class="content"></div> <div class="footer"></div> </div> يمكننا وبشكل اختياري أن نضيف محتوى إلى كلّ قسم من الأقسام السابقة إذا أردنا أن نرى أين ستظهر الشبكة بعد الانتهاء. تنسيق الشبكة بشيفرة CSS قبل أن نبدأ بتنسيق الشبكة يجب أن نعلم أنّ هناك بعض تنسيقات CSS لا تعمل مع الشبكات: الخصائص column-* أي جميع الخصائص التي تبدأ بـ column- مثل column-span و column-width و column-rule. الخاصيّة float، وهذه الخاصيّة يمكن استخدمها إذا طبّقتها قبل تطبيق الخاصيّة display التي تُعيّن طريقة العرض إلى شبكة كما سنرى بعد قليل. لن يكون بالإمكان تعويم float المحتوى داخل الشبكة. الخاصيّة clear، حيث أنّه بمجرّد العمل مع بنى الشبكات فلا داعي لاستخدام هذه الخاصيّة لأنّ الشبكة تتجاهلها. الخاصيّة vertical-align، لا تمتلك هذه الخاصيّة أي تأثير على بنية الشبكة. العنصرين الزائفين first-line:: و first-letter:: لا يمكن تطبيقهما ضمن الشبكة. بالنسبة لأي خاصيّة CSS غير موجودة في القائمة السابقة فيمكن استخدامها مع الشبكات. قم بإنشاء الملف style.css لنعمل على تطبيق بنية الشبكة على التصميم. سنبدأ الآن باستخدام مُحدّد معرّف العنصر كما يلي: #grid { display:grid; } إذا وجدت أنّ تموضع الشبكة ليس مناسبًا، جرّب تغيير الخاصية السابقة لتصبح display:inline-grid حيث يؤدي ذلك إلى إنشاء البنية ضمن المنطقة التي تعمل ضمنها بدلًا من إنشاء حاوية مُخصّصة كما تفعل القيمة block عند استخدامها. نلاحظ أنّ الشبكة قد تمّ إنشائها ولكنّها فارغة. لإنشاء الخلايا يمكننا استخدام grid-template-rows و grid-template-columns بحيث نضعهم أسفل الخاصيّة display التي عرّفناها قبل قليل. القيم التي يمكن تزويدها لهاتين الخاصيّتين هي قيم أحجام الخلايا التي نرغب بإنشائها. فمثلًا إذا عرّفنا قيمة حجم واحدة من أجل سطر ما، فسيؤدّي ذلك إلى إنشاء سطر واحد فقط، في حين يؤدّي تعريف خمس قيم حجم إلى إنشاء خمسة أسطر. ويمكن تطبيق نفس الأسلوب على الأعمدة. فلإنشاء البنية السابقة المقترحة، يمكننا تعريف الأسطر والأعمدة على الشكل التالي: #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); } أنشأنا في المثال السابق ثلاثة أسطر وتسعة أعمدة. يبلغ ارتفاع السطر الأوّل 100 بيكسل، أمّا السطر الثاني فسيتم ضبطه تلقائيًّا بحيث يلائم المحتوى المُضاف بالنسبة إلى الشبكة، وسيبلغ ارتفاع السطر الثالث 100 بيكسل أيضًا. تسمح لنا الدالّة repeat بإنشاء أي عدد من الأعمدة أو الأسطر طالما أردنا أن يكون لها نفس القياس. في مثالنا هذا سننشئ تسعة أعمدة بعرض 100 بيكسل لكلٍّ منها. يبدو للوهلة الأولى أنّنا أضفنا عددًا عشوائيًّا من الأعمدة، خصوصًا أنّه لدينا خمس مناطق areas في البنية التي خطّطنا لها مسبقًا. تكمن الإجابة على ذلك أنّه بإمكاننا أن نجعل المناطق تمتد span على أكثر من خليّة، ويسمح لنا ذلك بضبط الحجم الافتراضي لكلّ منطقة بشكل فعّال. في مثالنا هذا ومن أجل سطر واحد يمكن أن تمتدّ المنطقة التي تضمّ المحتوى الرئيسي عبر سبعة أعمدة بحيث يبلغ العرض الافتراضي لها 700 بيكسل، كما يمتدّ الشريط الجانبيّ عبر عمودين ليصبح عرضه 200 بيكسل، وهكذا نحصل على عرض إجمالي قدره 900 بيكسل. لاحظ أنّه كان بإمكاننا تعريف عدد أقل من الأعمدة بعرض أكبر لكلّ منها، ولكننا لم نفعل ذلك. يكمن السبب في أنّه عند استخدام عدد أعمدة أكبر بعرض أصغر لكلّ منها، فإنّ ذلك سيؤدّي إلى تحكّم أكبر في عرض المناطق الممتدة على تلك الأعمدة، وخاصةً التي تحتاج إلى عرض قليل نسبيًّا مثل المنطقة التي نضع فيها حقوق التأليف والنشر مثلًا. تُطبّق نفس الفكرة تمامًا من أجل الأسطر، لكن لاحظ بأنّنا قد اخترنا عددًا قليلًا منها ممّا لا يمنحنا نفس المرونة المتوفّرة بالنسبة للأعمدة. على العموم لا بأس في ذلك، فهدفنا هنا هو تحقيق الفكرة والتعلّم حول الإمكانيّات المتوفّرة لتخطيط البنية الشبكيّة. لا تبدو الأمور حتى الآن كما هو مخطّط لها، لكن بمجرّد تعريف وتسمية مناطق الشبكة ستأخذ البنية الشبكيّة الشكل المطلوب. لتسمية المناطق فإنّنا نعيّن اسم المنطقة لكلّ عمود وسطر ستمتدّ عليه هذه المنطقة. يمكننا استخدام الخاصيّة grid-template-areas بحيث نضعها أسفل الخاصّتين المسؤولتين عن تعيين عدد الأسطر والأعمدة الّلتين أضفناهما قبل قليل، أي على النحو التالي: #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); grid-template-areas: "header header header header header header header header header" "content content content content content content content sidebar sidebar" "footer footer footer footer footer footer footer footer footer"; } نلاحظ من السطر الأوّل أنّ المنطقة header تمتدّ على كامل الأعمدة، وكذلك الأمر بالنسبة للمنطقة footer على السطر الثالث. أمّا السطر الثاني فسيحتوي على منطقة المحتوى الرئيسي main بالإضافة إلى منطقة الشريط الجانبي sidebar. حتى هذه اللحظة لم يتم إنشاء الشبكة بعد. في الحقيقة تُشير الأسماء المعرّفة توًّا: header و content و sidebar و footer إلى أسماء أصناف CSS سنعرّفها بعد قليل. بحيث نستخدم خصائص جديدة مع هذه الأصناف تُشير إلى بداية ونهاية كل منطقة بالنسبة للأسطر: grid-row-start و grid-row-end وبالنسبة للأعمدة: grid-column-start و grid-column-end. يمكن إضافة أصناف CSS هذه مباشرةً بعد شيفرة الشبكة السابقة: .header { grid-row-start:1; grid-row-end:2; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:2; grid-row-end:3; grid-column-start:1; grid-column-end:8; } .sidebar { grid-row-start:2; grid-row-end:3; grid-column-start:8; grid-column-end:10; } .footer { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:7; } تُحتسب المناطق اعتبارًا من خطّ البداية (سطر أو عمود) إلى الخطّ الذي يلي خطّ النهاية الفعليّ حتى ولو لم يكن هذا الخط موجودًا، فإذا لم نأخذ هذا الأمر بعين الاعتبار، فمن الممكن إسناد نفس القيمة للبداية وللنهاية لمنطقة ما وبالتالي لا تظهر هذه المنطقة أبدًا. بهذا نكون قد انتهينا من إعداد الشبكة ويمكن البدء بإضافة التنسيقات المرغوبة. الأمر السلبيّ الوحيد في التصميم السابق أنّه ليس متجاوبًا مع شاشات الأجهزة المحمولة. جعل البنية متجاوبة مع الأجهزة المحمولة وفقًا لهذا التقرير فإنّ أكثر من نصف مجموع الأوقات التي قضاها المستخدمون على الانترنت في النصف الأوّل من عام 2015 كانت على الأجهزة المحمولة. وهذا يزيد بمقدار 11% عمّا كان عليه الوضع في العام السابق ويزيد بمقدار 39% عمّا كان عليه في عام 2008. من الملاحظ أنّ عدد الساعات التي يتمّ قضائها على الأجهزة المحمولة في ازدياد مطّرد، فإن لم نجعل موقعنا متجاوبًا مع هذه الأجهزة فسيفوتنا القطار! قد تبدو هذه العمليّة صعبة للوهلة الأولى، ولكنّ الأمر ليس بهذه الصعوبة. يوجد أسلوب أساسيّ يمكن من خلاله جعل البنية الشبكيّة متجاوبة، حيث يمكن باستخدام القاعدة media@ والخاصيّتان max-width و min-width أن نسمح للمتصفّح بعرض محتوى مناسب إذا استُخدم الجهاز المحمول لعرض الموقع. يمكن باستخدام القاعدة media@ تعريف أنماط تنسيق مُحدّدة للموقع بحيث تُطبّق عند استعراض هذا الموقع ضمن شاشة الجهاز المحمول. تسمح الخاصيّة max-width بشكل عام لأيّ عنصر بالالتزام بقياس مُحدّد عن طريق إسناد العرض الأعظمي للمنطقة التي يُسمح للمحتوى الخاص به أن يشغلها. تخبر هذه الخاصيّة موقعنا بأنّه من الممكن أن ندع محتويات المناطق تكبر أو تصغر طالما أنّها لا تتجاوز القيمة التي حدّدناها ضمن الخاصيّة max-width. أمّا عند استخدام الخاصيّة max-width مع القاعدة media@ فسيكون للخاصيّة max-width دور جديد وهو تحديد شرط لتطبيق أنماط تنسيق مُحدّدة عندما يتم استخدام شاشات صغيرة، كشاشات الأجهزة المحمولة. وينطبق نفس الأسلوب تمامًا على الخاصيّة min-width عند استخدمها مع القاعدة media@. الآن لنضع القاعدة التالية أوّل تنسيقات CSS التي أضفناها إلى ملف التنسيق: @media (max-width:900px) and (min-width:500px) { /* Your grid layout code goes here */ } ستُطبّق التنسيقات الموجودة ضمن القاعدة media@ عندما يُستخدم أيّ جهاز يتراوح عرض شاشته بين 900 بيكسل (العرض الأعظمي max-width) و500 بيكسل (العرض الأصغري min-width). لا ننسى بالطبع تعديل هذه القيم بما يتلاءم مع احتياجاتنا. التغييرات البسيطة في البنية لنضع الآن جميع التنسيقات مع بعضها البعض، ونضيف المزيد منها إلى البنية الجديدة. الشكل النهائي لملف تنسيقات CSS سيبدو مشابهًا لما يلي: @media (max-width:900px) and (min-width:500px) { #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); } } .header { grid-row-start:1; grid-row-end:2; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:2; grid-row-end:3; grid-column-start:1; grid-column-end:8; } .sidebar { grid-row-start:2; grid-row-end:3; grid-column-start:8; grid-column-end:10; } .footer { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:7; } وهنا صورة تمثيليّة لما سنحصل عليه ضمن المتصفّح: صورة تمثيليّة للشكل الناتج يتألّف من ترويسة ومنطقة محتوى رئيسيّة وشريط جانبي ومنطقة للتذييل. إذا أردنا في أيّ وقت تعديل البنية الشبكيّة السابقة، فكل ما علينا فعله هو إعادة تعريف المناطق بتغيير مواقع البداية والنهاية لها لنحصل على الشكل المرغوب. وهذا يساعدنا على الانتقال إلى أيّ شكل جديد دون الحاجة لإعادة تصميم الصفحة بشكل كامل. توجد هناك تقنيّات متقدّمة يمكننا استخدمها لإضافة المزيد من المزايا إلى هذه البنية، يمكننا كما هو متوقّع استخدام تنسيقات CSS المألوفة لإكساب بنيتنا الجديدة تنسيقات جميلة وجذّابة. خاتمة نحن مستعدّون الآن لاستخدام آخر التحسينات في عالم CSS، يمكننا الآن فهم وإنشاء عناصر جديدة ومختلفة وتجميعها معًا لتشكيل بنية شبكيّة. أنصح بمراجعة وثائق العمل الحاليّة الخاصّة بالبنية الشبكيّة، وبشكل دوريّ، للاطّلاع على آخر المستجدّات حالما تصدر. ترجمة -وبتصرّف- للمقال Understanding CSS Grids for Modern WordPress Website Design لصاحبته Jenni McKinnon.

هل تحتاج إلى تطبيق في متجر التطبيقات؟ هل يجب أن تكون أصلية (Native) أم مُهجّنة (Hybrid)؟ ما الفرق بين تطبيق جوال وتطبيق ويب وموقع متجاوب؟ هل تعتقد أن يكون الموقع متجاوبًا (Responsive Website)، فهذا يجعله متوافقًا مع الجوال (Mobile Friendly)؟ كل هذه الاسئلة عليك أن تُجيب عنها إذا ما أردت التعامل مع الأجهزة المحمولة كمُطوِّر، وهذا ما سنسلط عليه الضوء في هذا المقال. أنواع تطبيقات الجوال هناك الكثير من الالتباس بين المؤسسات حول كيفية التعامل مع الأجهزة المحمولة. ومع ذلك، عندما يتعلق الأمر بهذا فلديك 4 خيارات كالتالي: التطبيقات الأصلية أو الأصيلة (Native Applications). تطبيقات الويب (Web Application). التطبيقات المُهجّنة (Hybird Application). المواقع المُتجاوبة (Responsive Websites). التطبيقات الأصلية (Native Applications) التطبيقات الأصلية هي تطبيقات تعمل فعليًا على الجهاز المحمول ويتم ترميزها خصيصًا لنظام تشغيل الجهاز. هذه هي التطبيقات التي تجدها عادةً في متجر تطبيقات Google Play أو iOS. هذا هو أفضل نهج حيث السرعة والميزات الأصلية (Native Features) مطلوبة. تطبيقات الويب (Web Application) هناك خصائص مشتركة بين كلٍ من تطبيقات الويب، التطبيقات الأصلية، والمواقع المُتجاوبة. كما هو الحال مع الموقع المتجاوب، تُصمَّم تطبيقات الويب باستخدام HTML و CSS و Javascript ويكون بالكامل على الإنترنت. ومع ذلك، عندما يكون الموقع المُتجاوب موجَّهًا للمحتوى (Content Oriented)، فإن تطبيق الويب يركز على المهمة بنفس طريقة التطبيق الأصلي. ومن الأمثلة على ذلك تطبيق Blackpool Pleasure Beach للهاتف المحمول. التطبيق متاح عبر الإنترنت ولكنه ليس موقع ويب غني بالمحتوى. بدلاً من ذلك، إنه تطبيق حجز يسمح للمستخدمين بشراء تذاكرهم وبطاقاتهم. نظرًا لأنه يتطلب اتصالًا مستمرًا بالخادم(Server)، ولم يستخدمه المستخدمون بشكل منتظم ولا يحتاج إلى ميزات أصلية، فلا فائدة من جعله تطبيقًا أصليًا. التطبيقات الهجينة (Hybird Application) ربما يكون التطبيق المُهجّن أو الهجين هو الأصعب في شرح الخيارات. يُعَد التطبيق المُهجّن تطبيقًا أصليًا أُنشئ باستخدام HTML و CSS و Javascript. فمن خلال بناء هذه التطبيقات باستخدام تقنية الويب، يكون تطويرها أسرع وأسهل للنشر على منصات متعددة (مثل iOS أو Android). الجانب السلبي هو أن الأداء لا يميل إلى أن يكون جيدًا ويفتقر إلى نمط التصميم لكل منصة. مثال على هذا النوع من التطبيقات هو إثبات مفهوم تطبيق "فراشة العد butterfly counting" الذي طوّرته Headscape. تم بناء هذا التطبيق المُهجَّن في PhoneGap وسمح للمستخدمين بتحديد وحساب الفراشات في الحقل حتى مع عدم وجود اتصال بالانترنت. كان قرار إنشاء هذا كتطبيق هجين لأنه إثباتًا للمفهوم وأرادت الشركة إنتاجه بسرعة وبأقل تكلفة. المواقع المتجاوبة (Responsive Websites) الموقع المُتجاوب هو الذي يتكيف مع أي جهاز يتم عرضه عليه. سواء كان ذلك عبارة عن جهاز سطح مكتب أو جهاز لوحي أو جهاز محمول، سيعرض موقع الويب نفسه المحتوى نفسه باستخدام تصميم مرئي يناسب هذا الجهاز. خذ على سبيل المثال Macmillian English. فهو موقعٌ غنيٌّ جدًا بالمعلومات. يُنقِّب مستخدمو الموقع عن المعلومات بدلاً من إتمام المهام. يضمن موقع الويب المتجاوب أن يتمكنوا من العثور على نفس المعلومات مهما كان الجهاز الذي يستخدمونه. المواقع المُتجاوبة جيدة لـ : المواقع الغنيّة بالمعلومات. المستخدمين الذين يتطلعون إلى جمع المعلومات. إذا كنت لست متأكدًا من الخيار الذي تحتاجه، فعادةً ما يكون الموقع المُتجاوب نقطة انطلاقٍ جيدة. هذا ما نعتقده عادًًة، أن تكون المواقع مُتجاوبة، فهذا يجعلها متوافقة مع الجوال (Mobile Friendly)، لكن هذا ليس كل ما في الأمر. لا تزال هناك طرق كثيرة تُمكّننا من إفساد تجربة المُستخدم والإضرار بموضعنا في نتائج البحث. ألق نظرة على دورة تطوير تطبيقات الجوال باستخدام تقنيات الويب والتي ستتعلم فيها تطوير تطبيقات جوال لأنظمة أندرويد وأيفون و ويندوز فون باستخدام تقنيات الويب البسيطة JavaScript, HTML, CSS مما يمكنك من تطوير تطبيق واحد يعمل مباشرة على جميع المنصات. إنشاء موقع متجاوب متوافق تمامًا مع الجوال ندرك جيدًا أهمية أن يكون الموقع متوافقًا مع الجوال، ويميل معظمنا إلى التفكير في "التصميم المتجاوب Responsive Website" كحل لهذا. لا ريب أن "التصميم المُتجاوب" قد أحدث طفرةً في تطبيقات الويب على الهواتف الذكيّة. فبوجٍه عام، لقد حسّنَ "تجربة المُستخدم User Experience" وسهّل علينا إدارة المواقع وجنّبنا الحفاظ على إصدارات متعددة لنفس الموقع. دعني أقدم لك بعض الأمثلة عن "أين يمكن أن تسوء الأمور" بدءًا من المشكلة الأكبر على الإطلاق "المواقع شبه المتجاوبة". هل موقعك مُتجاوب بالكامل؟ عندما نقوم بإعادة تصميم موقع ويب من البداية، فإن بناءه حيث يصبح "موقعًا متجاوبًا" أمرًا منطقيًا تمامًا. لكن تعديل لموقع موجود بالفعل (خاصةً إذا كان موقعًا كبيرًا) حيث يصبح "موقعًا متجاوبًا"، يمكن لهذا أن يتحول إلى كابوس. العديد من العملاء واجهوا هذه المشكلة، تحتوي معظم المواقع الإلكترونية الخاصة بهم على عشرات الآلاف من الصفحات على الأقل، تم إنشاؤها على مدار سنوات. مما جعل أمر أن تكون هذه المواقع "صديقة للهواتف الذكيّة" تحديًا بشكل لا يُصدَّق. لتقليل العمل الذي ينطوي عليه الأمر، فهم يتخذون قرارًا بالتركيز على الصفحات الأساسية وجعلها سهلة الاستخدام على الهواتف الذكيّة ومٌتجاوبة أيضًا، متجاهلين البقية. بالرغم من أنني أستطيع فهم هذا القرار إلا أنه سيء جدًا من منظور "تجربة المستخدم". ليس هناك ما هو أكثر إحباطًا من التورط في التفكير بأنّك تتصفح موقعًا صديقًا للهاتف، فقط لتجد نفسك عالقًا في صفحة مُحسّنة لسطح المكتب لا يمكنك قراءتها أو تصفّحها. تحتاج هذه المنظمات إلى التفكير بتمعن ولفترة طويلة حول ما إذا كانت تحتاج لمثل هذه المواقع الكبيرة. من واقع خبرتي، نادرًا ما يقومون بذلك، ويقومون فقط بترحيل المحتوى بشكلٍ أعمى من إصدارٍ لآخر. هل قلصت وظائفية الموقع؟ يواجه المصممون مشكلة مماثلة عندما يصطدمون ببعض الوظائف الشاقة للموقع. شيء يبدو معقدًا جدًا لدرجة لا تمكّنه من صداقة الهواتف المحمولة ويكون التعامل مع الموقع على الهاتف شاقًا جدًا على المُستخدم. بدلًا من مضاعفة الجهود والتوصل لحل مُبتكر، نسهل الطريق الأقل صعوبة ومقاومة. نحن نقنع أنفسنا بأن مُستخدمي الهواتف لن يحتاجوا إلى هذه الوظائف وسيُزيلونها من الموقع. هذا بالطبع، أمرٌ ساذج بشكل لا يُصدّق. لا يختلف مُستخدمو الهواتف المحمولة بطريقة سحرية. هم نفس المُستخدمين الذين يستخدمون موقعك على "سطح المكتب Desktop". لقد بدّلوا الأجهزة فقط. لقد رأيتُ حتى أن الناس يستخدمون الهواتف المحمولة أثناء الجلوس في متناول اليد من أجهزة الحاسوب الخاصة بهم. لا يمكننا وضع افتراضات حول متطلباتهم بناءً على الجهاز. هل تؤيد إشارات اللمس؟ لا تتعلق الأخطاء الصديقة لأجهزة الهاتف فقط بإزالة الأشياء، يمكن أن يكون الفشل في إضافة شيء ما بنفس الخطورة. خذ على سبيل المثال "دعم إشارات اللمس". لا عجب أن كثيرًا من المُستخدمين يفضلون أحيانًا تطبيقات الأجهزة المحمولة عندما لا يُمكنهم التحرك والضغط على موقع إلكتروني على الهاتف. يجب حقًا على مصممي المواقع السماح للمستخدمين بتحريك الصور الدائرية والضغط عليها. فغالبًا ما يتم التغاضي عن هذا النوع من الوظائف لأننا نركز على تكييف التصميم لنقاط التوقف المختلفة. هل يتكيف المحتوى وكذلك التصميم؟ أن يكون الموقع صديقًا للهاتف المحمول، فهذا لا يعني تغيير التصميم فقط، إنّه يتعلق أيضًا بتغيير المحتوى نفسه. خذ "الجدول" على سبيل المثال. فقط لأننا نعرض البيانات كجدول بأحجام شاشات أكبر، فهذا لا يعني أن علينا أن نفعل ذلك على الهواتف أيضًا. قد نستنتج أن عرض "مخطط تفاعلي interactive chart" أو شكل من أشكال الآلة الحاسبة أكثر صداقة للهاتف "Mobile Friendly". نحتاج إلى تعديل المحتوى وليس فقط التصميم والجداول ومخططات المعلومات البيانية، إلى شيء يسهل التعامل معه على الهاتف ثم يأتي دور "الرسوم البيانية infographics"، التي تبدو رائعة على الشاشات الكبيرة لكنها تصبح غير قابلة للقراءة على أجهزة الهاتف. نستطيع بالتأكيد أن نسمح للمُستخدم بتكبير الشاشة وندّعي بذلك أننا قمنا بعملنا على أكمل وجه، أو يمكننا أن نعيد تخيلهم. ربما يجب علينا أن نُقسِّم هذه الرسوم البيانية إلى "لوحة رسوم Storyboard" أو نستخدم فيديو عوضًا عن ذلك. هل موقعك مقروءًا على الهاتف بقدر الإمكان؟ لا تقتصر مشاكل الوضوح فقط على الصور والجداول، إنما ينطبق الأمر بنفس القدر على النص. لن تُخلق تجربة ودية ومقروءة مع الهاتف بمجرد إضافة نقاط توقف إلى عناصر إعادة الموضع. انها غالبًا ما تُقصِّر أطوال الخطوط لدرجة تجعل القراءة صعبة للغاية. يبذل المصممون جهدًا في هذا الصدد بجعل حجم الخط يتناسب مع نقطة التوقف (breakpoint)، وبتقليص حجمه وفقًا لذلك. لكنني زرتُ العديد من المواقع على الأجهزة المحمولة حيث أصبحت أحجام الخطوط صغيرة جدًا مما يجعل النص غير مقروء. وأخيرًا، هناك قضية "اللون". غالبًا ما يفشل المصممون في أن يأخذوا بعين الاعتبار وهج الشاشة التي يعاني منها مستخدمو الهواتف المحمولة، ومن ثَمَّ يصنعون لوحات الألوان الدقيقة التي تُصعِّب تجربة القراءة على الهاتف وهذا على أقل تقدير. هل تركز بشكل كبير على أحدث وأفضل الهواتف الذكيّة؟ بالطبع، بعض مشاكل الوضوح هذه غير مرئية لنا حتى عند اختبارها على جهاز محمول. ذلك لأن لدينا أحدث وأكبر هاتف ذكي. إنه يحتوي على شاشة شبكية (retina screen)، ذات دقة عالية جدًا، وسطوع لا يمكن حتى للشمس أن تجاريها! ولكن ليس الجميع لديه أجهزة كهذه. حتى لو تجاهلت الهواتف المميزة كبندٍ للمقارنة، فقد تختلف التجارب بشكل كبير. ثم، بالطبع، هناك نقاط توقف. ما زلت أرى أن المصممين يقومون بتعيين نقاط التوقف استنادًا على الجهاز، بدلًا من المكان المناسب في المحتوى. لديهم تصميم بحجم iPad، وتصميم بحجم iPhone وما إلى ذلك. ولكن في الحقيقة، الأحجام متنوعة بشكل كبير، ونحتاج إلى التوقف عن التفكير في أجهزة معينة. هل أداؤك صديقًا للهاتف؟ الأداء هو ما يجب أن نفكر به. في الواقع، ربما تكون هذه هي المنطقة الأكبر الوحيدة حيث يخذلنا "التصميم المتجاوب". لا تسيئ فهمي أنا لا أقول أن "التصميم المتجاوب" يجعل مواقعنا أبطأ. إنه فقط لا يفعل شيئًا لتحسينه وهو شيء تحتاجه الأجهزة المحمولة. حجم الصورة بالتأكيد هو السبب. قد يؤدي استخدام "استعلامات الوسائط media queries" إلى تصغير الصورة بصريًا، لكنه لن يؤثر في تقليل حجم الصورة أو أوقات التحميل. هذا ليس جيدًا عند استخدام شبكة خلوية. أضف إلى ذلك الخطوط والمكتبات والأطر وجميع العناصر الأخرى التي تنتفخ في مواقع الويب الحالية ولديك أوقات تحميل سيئة. يمكن أن يؤدي اختبار أداء موقعك على الأجهزة المحمولة إلى قراءة محبطة! لكن هذه ليست مجرد مشكلة في حجم التنزيل وسرعة الشبكة الخلوية. الأداء هو مشكلة في الجهاز أيضًا. تفتقر العديد من الأجهزة المحمولة إلى قدرة معالجة أجهزة الحاسوب المحمولة أو أجهزة الحاسوب المكتبية أو الأجهزة اللوحية. والنتيجة هي أنها لا تستطيع التعامل مع قالب مُكثف من كود الجافاسكريبت "intensive javascript" موجود على العديد من المواقع الحديثة. هل ملء البيانات سهلًا على الهواتف؟ بعد ذلك، نأتي إلى مجموعة معينة من الأخطاء تحدث عندما نقوم بإدخال البيانات على الأجهزة المحمولة. فهل لك أن تتخيل كيف يمكن لأحد إدخال كم كبير من البيانات عبر لوحة مفاتيح هاتفه الصغير خلال فترة زمنية قصيرة؟ الأمر مريع حقًا، خصوصًا إن كان المستخدم مسنًا. كمصممي ويب، يبدو أننا نجعل المشكلة أسوأ بمئة مرة على مواقع الويب. عند إدخال بيانات رقمية، نفشل في عرض لوحة مفاتيح رقمية. عند إدخال كلمات المرور، نخفي ما يكتبه المستخدم، على الرغم من حقيقة أن الأخطاء المطبعية أمرًا شائعًا على الأجهزة المحمولة. في الواقع، لا ينبغي لنا أن نتوقع من مستخدمي الجوال ملء كلمات المرور على الإطلاق. هناك العديد من البدائل الأخرى مثل الإشعارات النصية أو روابط البريد الإلكتروني أو "معرف اللمس Touch ID". هناك العديد من المواقف التي يمكن فيها تجنب إدخال البيانات أو تبسيطها. سيكون تذكر اسم المستخدم لتسجيل الدخول بين الجلسات بداية جيدة. ولكن يجب علينا أيضًا تحسين تصميم النموذج وتجنب عناصر الأشكال المملوءة مثل منتقي التواريخ أو القوائم المنسدلة الطويلة. هل الروابط معبأة بإحكام أيضًا؟ عند الحديث عن التفاعلات المزعجة، أشعر بالدهشة إزاء قلة الاهتمام الذي يبديه المصممون للتحديات المحيطة باستخدام شاشة تعمل باللمس. أجد أن العديد من مواقع الويب التي تدّعي أنها صديقة للهاتف، ليست كذلك عندما تبدأ بالتفاعل معها. غالبًا ما يتم تجميع الارتباطات والأزرار معًا لزيادة حجم الشاشة إلى الحد الأقصى، بحيث يصبح من المستحيل النقر عليها. مرةً أخرى، مجرد تغيير موضع المحتوى لا يكفي. نحتاج إلى ضمان أن المساحة حول العناصر تتّسع للسماح بنقص الدقة الذي يحدث جرّاء استخدام الإصبع. من المسلَّم به أن المساحة هي ميزة استثنائية، ولكن إذا استخدمنا المساحة المتوفرة لدينا بحكمة، فلا يوجد سبب يمنع اختيار الروابط بسهولة أكبر. فقط إلقِ نظرة على متوسط التطبيق المحمول الخاص بك. هل يتعين على المستخدمين تحمُّل محتوى ثابت الموضع؟ بالحديث عن قلة المساحة، لماذا على الرغم من رغبة جميع المصممين في إنشاء موقع ويب سهل الاستخدام للهاتف المحمول، فإننا نعتبر أنه من المقبول إضافة محتوى موقع ثابت إلى الصفحة. هذا يقلل بشكل كبير من المساحة المتاحة لعناصر المحتوى الأخرى. فكر بتمعُّن قبل نقل تنقلاتك الثابتة إلى منظور موقعك الإليكتروني على الهاتف. بالمثل، قم بإبعاد تلك الطبقات ونوافذ الحوار، وكذلك رموز مواقع التواصل الاجتماعي الثابتة. ليس لديهم مكان على موقع إليكتروني على الهاتف. يكاد يكون من المستحيل قراءة المحتوى الموجود على Mashable على جهاز محمول نظرًا لحجم عناصر الموضع الثابت. ما المناسب لك؟ كلٌ من الخيارات الأربعة التي تمت مناقشتها في هذا المنشور له مكانه المناسب الذي سيختلف بناءً على الاحتياجات الخاصة بك. ومع ذلك، فإن نقطة الانطلاق الجيدة هي السؤال عمّا إذا كان المستخدمون يقومون في المقام الأول بإكمال مهمة أو الوصول إلى المعلومات. إذا كان الوصول إلى المعلومات هو الهدف، فمن المؤكّد أنّ المواقع المُتجاوبة هي الحل الأمثل. أمّا اذا كان "إكمال مهمة" هو الهدف، فعليك أن تسأل عمّا إذا كانت السرعة أم الوصول إلى الميزات الأصلية أيهما أهم. إذا كان الأمر كذلك، فستحتاج إلى تطبيق أصلي أو مُهجّن، وإلاّ سيكون تطبيق الويب مثاليًا. ترجمة -وبتصرف- للمقالين Is your site as mobile friendly as you think و Mobile app vs mobile website design: Your four options لصاحبهما Paul Boag

سيُزار موقعك الإلكتروني هذه الأيام من مجموعةٍ واسعةٍ من الأجهزة: أجهزة الحواسيب المكتبيّة ذات الشاشات الكبيرة وأجهزة الحواسيب المحمولة متوسطة الحجم والأجهزة اللوحيّة والهواتف الذكيّة وغيرها. يتوجب على موقعك من أجل تحقيق تجربة المستخدم المثلى كمطوّر واجهة أماميّة (front-end engineer) ضبط تخطيط الصفحة (layout) استجابةً لهذه الأجهزة المختلفة (على سبيل المثال، دقّة الشاشة وأبعادها المتنوعة). يُشار إلى عملية الاستجابة لشكل جهاز المستخدم باسم (ربما توقعت ذلك) تصميم الويب المتجاوب (RWD). لماذا يجدر بك صرف وقتك لدراسة أمثلة تصميم الويب المتجاوب وتحويل تركيزك إليه؟ يعمل بعض مصممي الويب على سبيل المثال على التأكّد من الحصول على تجربة مستخدم مستقرة عبر جميع المتصفحات، حيث يمضون غالبًا أيامًا في معالجة قضايا صغيرة باستخدام المتصفح Internet Explorer. هذا نهج فاشل. يُمضي بعض مصممي الويب أيامًا في معالجة المشكلات الصغيرة لمستخدمي متصفح Internet Explorer ويتركون مستخدمي الأجهزة المحمولة لديهم كزوار درجة ثانية. وهذا نهج فاشل. أطلق Mashable على عام 2013 عام تصميم الويب المتجاوب. لماذا ا؟ لأن أكثر من 30 ٪ من «حركة مرور البيانات» (traffic) الخاصّة بهم تأتي من الأجهزة المحمولة. إنّهم يتوقعون أن يصل هذا العدد إلى 50٪ بحلول نهاية العام. في الويب بشكل عام، جاءت 17.4٪ من حركة مرور بيانات الويب من الهواتف الذكيّة في عام 2013. يمثل استخدام Internet Explorer في الوقت نفسه على سبيل المثال 12٪ فقط من إجمالي حركة مرور بيانات المستعرض، بانخفاض وقدره 4٪ تقريبًا عن مثل هذا الوقت من العام الماضي (وفقًا لـ W3Schools). إذا كنت تعمل على التحسين لمتصفح معين، بدلًا من مستخدمي الهواتف الذكيّة العالميين، فأنت تضيع في التفاصيل. يمكن أن يُشكّل هذا في بعض الحالات الفرق بين النجاح والفشل - التصميم المتجاوب له آثار على معدلات التحويل (conversion rates) وتحسين ظهور الموقع في محركات البحث (SEO) ومعدلات الارتداد (bounce rates) وغيرها. نهج تصميم الويب المتجاوب إنّ الأمر الأكثر أهميّة في RWD عادةً لا يتعلق فقط بضبط مظهر صفحات الويب الخاصّة بك، بل إنّ التركيز يجب أن يكون على تكييف موقعك منطقيًا للاستخدام عبر أجهزة مختلفة. على سبيل المثال: لا يوفّر استخدام الماوس تجربة المستخدم نفسها التي توفّرها شاشة اللمس. ألا توافقني الرأي؟ يجب أن يعكس تخطيط هاتفك المحمول مقابل تخطيطات الأجهزة المكتبيّة هذه الاختلافات. أنت لا تريد في الوقت نفسه إعادة كتابة موقعك بالكامل من أجل كل حجم من عشرات الأحجام المختلفة للشاشة التي قد يُعرض عليها - فهذه الطريقة ببساطة غير مُمكنة. إنّ الحل البديل هو استعمال عناصر تصميم متجاوبة مرنة تستخدم نفس شيفرة الـ HTML للتكيّف مع حجم شاشة المستخدم. يكمن الحل من وجهة نظر تقنيّة في هذا الدليل للتصميم المتجاوب: في استخدام استعلامات وسائط CSS والعناصر الزائفة وضبط تخطيطات الشبكة المرنة، وأدوات أخرى للتكيُّف ديناميكيًا مع دقّة معيّنة. استعلامات الوسائط في التصميم المتجاوب ظهرت أنواع الوسائط للمرة الأولى في HTML4 و CSS2.1، مما أتاح وضع ملف CSS منفصل للشاشة و آخر للطباعة. وبهذه الطريقة، أصبح بالإمكان تعيين أنماط منفصلة لعرض الصفحة على الحاسوب بشكل مقابل للنسخة المطبوعة. <link rel="stylesheet" type="text/css" href="screen.css" media="screen"> <link rel="stylesheet" type="text/css" href="print.css" media="print"> أو @media screen { * { background: silver } } يمكنك في CSS3 تحديد تنسيق الصفحة وتخطيطها اعتمادًا على عرض الصفحة. ولأن عرض الصفحة يرتبط بحجم جهاز المستخدم، فإنّ هذه الإمكانية تتيح لك بالتالي تحديد تخطيطات مختلفة للأجهزة المختلفة. ملاحظة: تُدعم استعلامات الوسائط من قبل جميع المتصفحات الرئيسية إنّ هذا التعريف ممكن من خلال إعداد الخصائص الأساسية: max-widt وdevice-width وorientation وcolor وهناك تعريفات أخرى ممكنة كذلك، ولكن في هذه الحالة فإنّ أهم الأشياء التي يجب وضعها في الحسبان هو الحد الأدنى من الدقّة («العرض» (width)) وإعدادات الاتجاه (أفقي أو عمودي). يوضّح مثال CSS المتجاوب أدناه الإجراء لبدء ملف CSS معين اعتمادًا على عرض الصفحة. ستُطبّق على سبيل المثال الأنماط المحدّدة في الملف main_1.css إذا كان الحد الأقصى لدقّة شاشة الجهاز الحالي هو 480 بكسل. <link rel="stylesheet" media="screen and (max-device-width: 480px)" href="main_1.css" /> يمكننا أيضًا تحديد أنماط مختلفة داخل ورقة أنماط CSS نفسها بحيث تُستخدم فقط في حالة استيفاء قيود محدّدة. لن يُستخدم على سبيل المثال هذا الجزء من ملف CSS المتجاوب إلا إذا كان عرض الجهاز الحالي أكثر من 480 بكسل: @media screen and (min-width: 480px) { div { float: left; background: red; } ....... } التكبير الذكيّ (smart zoom) تَستخدم متصفحات الهاتف المحمول ما يسمى «التكبير الذكي» (smart zoom) لتزويد المستخدمين بتجربة قراءة "ممتازة". يُستخدم التكبير الذكيّ في الأساس لتقليل حجم الصفحة بشكل متناسب. وهذا يمكن أن يظهر بطريقتين: (1) التكبير الذي يبدؤه المستخدم (على سبيل المثال، النقر مرتين على شاشة iPhone للتكبير على موقع الويب الحالي)، و(2) عرض نسخة مكبّرة منذ البداية من صفحة الويب عند التحميل. نظرًا لأنه يمكننا فقط استخدام استعلامات الوسائط المتجاوبة لحل أي من المشكلات التي قد يستهدفها التكبير / التصغير الذكيّ، فمن المستحسن في كثير من الأحيان (أو حتى الضروري) تعطيل التكبير والتأكّد من أنّ محتوى صفحتك يملأ المتصفح دائمًا: <meta name="viewport" content="width=device-width, initial-scale=1" /> إننا نتحكم في مستوى تكبير الصفحة الأولي (أي مقدار التكبير عند تحميل الصفحة) عن طريق ضبط قيمة initial-scale إلى القيمة 1. إذا صُممت صفحة الويب الخاصة بك لتكون متجاوبة، فإنّه عليك أن يملأ التصميم الديناميكي المتكيّف شاشة الهاتف الذكي بطريقة ذكيّة دون الحاجة إلى أي تكبير أولي. يمكننا إضافة إلى ذلك تعطيل التكبير / التصغير بالكامل باستخدام user-scalable=false. عرض الصفحة (page widths) افترض أنك ترغب بتوفير ثلاثة تخطيطات مختلفة للصفحة المتجاوبة: واحدة من أجل أجهزة الحواسب المكتبيّة، وأخرى للأجهزة اللوحيّة (أو أجهزة الحواسيب المحمولة)، وثالثة للهواتف الذكيّة. ما هي أبعاد الصفحة التي يجب أن تستهدفها كقوالب (على سبيل المثال، 480 بكسل)؟ لا يوجد لسوء الحظ معيار محدّد يمكن اعتماده لعرض الصفحة (page width)، ولكن غالبًا ما يتم استخدام قيم التجاوب التالية: 320 بكسل 480 بكسل 600 بكسل 768 بكسل 900 بكسل 1024 بكسل 1200 بكسل يوجد مع ذلك عددًا من تعريفات العرض المختلفة. يحتوي على سبيل المثال عرض 320 وما فوق على خمس زيادات افتراضية لاستعلام الوسائط في CSS3 وهي:480، 600، 768، 992، 1382 بكسل. يمكنني أن أعدّد عشرة أساليب أخرى على الأقل إضافة إلى المثال الوارد في هذا الدليل لتطوير الويب المتجاوب. يمكنك تغطية معظم أجهزة العرض مع أي من هذه المجموعات المنطقية من الزيادات. عمليًا لا توجد حاجة عادةً للتعامل بشكل منفصل مع جميع الأمثلة المذكورة أعلاه لعرض الصفحة- سبعة خيارات دقّة مختلفة تُعدّ مبالغةً نوعًا ما. إنّ 320px و 768px و 1200px هي القيم الأكثر استخدامًا اعتمادًا على تجربتي. يجب أن تكون هذه القيم الثلاثة كافيةً للتعامل مع الهواتف الذكيّة والأجهزة اللوحيّة / أجهزة الحواسيب المحمولة وأجهزة الحواسيب المكتبيّة بالترتيب. العناصر الزائفة (Psuedo-Elements) قد ترغب أيضًا بناءً على أفضل استعلامات الوسائط المتجاوبة لديك في المثال السابق بإظهار أو إخفاء معلومات معيّنة برمجيًّا وفقًا لحجم شاشة جهاز المستخدم. يمكن لحسن الحظ تحقيق ذلك أيضًا باستخدام CSS صرف كما هو موضّح في الدليل أدناه. بالنسبة للمبتدئين، يمكن أن يكون إخفاء بعض العناصر (display: none;‎) حلاً رائعًا عندما يتعلق الأمر بتقليل عدد العناصر التي تظهر على شاشة التخطيط الخاص بالهاتف الذكيّ حيث لا تتوفر دائمًا مساحة كافية. يمكنك من جهة أخرى أيضًا أن تكون مبدعًا باستخدام عناصر CSS الزائفة (محددات (selectors))، مثل ‎:before و‎:aft. ملاحظة: مرّةّ أخرى، تُدعم العناصر الزائفة من قبل جميع المتصفحات الرئيسية. تُستخدم العناصر الزائفة لتطبيق أنماط محدّدة على أجزاء محدّدة لعنصر HTML، أو لتحديد مجموعة فرعيّة معيّنة من العناصر. يتيح لك على سبيل المثال العنصر الزائف :first-line تحديد الأنماط المطبّقة فقط على السطر الأول لمحدّد معين (على سبيل المثال، p:first-line سيُطبّق على السطر الأول من كل عناصر الفقرة p). وبالمثل، فسيُتيح لك العنصر الزائف a:visited تحديد الأنماط المطبّقة على كافة عناصر a مع الروابط التي زارها المستخدم سابقًا. كان هذا مفيدًا صراحةً. فيما يلي مثال بسيط لتصميم متجاوب، حيث نُنشئ ثلاثة تخطيطات مختلفة لزر تسجيل الدخول لكل من أجهزة الحواسيب المكتبيّة والأجهزة اللوحيّة والهواتف الذكيّة. سيكون لدينا على الهاتف الذكيّ فقط أيقونة، بينما سيكون على الحاسوب اللوحيّ الأيقونة نفسها مرفقةً بعبارة "User name"، سنُضيف أخيرًا للأجهزة المكتبيّة أيضًا رسالة توضيحيّة قصيرة ("Insert your user name"). .username:after { content:"Insert your user name"; } @media screen and (max-width: 1024px) { .username:before { content:"User name"; } } @media screen and (max-width: 480px) { .username:before { content:""; } } يمكننا إنجاز ما يلي اعتمادًا فقط على العناصر الزائفة التالية:before و:after:: لمعرفة المزيد عن سحر العناصر الزائفة، يوجد لدى Chris Coyier " وصف تفصيلي جيد عن حيل CSS)(CSS-Tricks. إذًا، من أين أبدأ؟ أنشأنا في هذا الدليل بعضًا من العناصر الأساسيّة لتَصميم ويب متجاوب (أي استعلامات الوسائط والعناصر الزائفة) وقدّمنا بعض الأمثلة لكل منها. ولكن إلى أين سنذهب الآن؟ الخطوة الأولى التي يجب اتخاذها هي تنظيم جميع عناصر صفحة الويب الخاصة بك من أجل أحجام مختلفة للشاشة. ألقِ نظرة على إصدار الأجهزة المكتبيّة للتخطيط المقدّم أعلاه. يمكن في هذه الحالة أن يكون المحتوى على اليسار (المستطيل الأخضر) كنوع من أنواع القائمة الرئيسية. ولكن عند استخدام الأجهزة ذات الدقة المنخفضة (على سبيل المثال، جهاز لوحي أو هاتف ذكي)، فقد يكون من المنطقي إظهار هذه القائمة الرئيسية بالعرض الكامل. يمكنك تطبيق هذا النهج باستخدام استعلامات الوسائط كما يلي: @media screen and (max-width: 1200px) { .menu { width: 100%; } } @media screen and (min-width: 1200px) { .menu { width: 30%; } } لسوء الحظ، غالبًا ما يكون هذا النهج الأساسي غير كافٍ مع زيادة تعقيد الواجهة الأماميّة. ونظرًا لأن تنظيم محتوى الموقع غالبًا ما يختلف اختلافًا كبيرًا بين إصدارات الأجهزة المحمولة والأجهزة المكتبيّة، فإنّ تجربة المستخدم تعتمد في نهاية المطاف ليس فقط على استخدام CSS المتجاوب، ولكن أيضًا على استخدام HTML وJavaScript. هناك عدة عناصر رئيسيّة مهمّة عند تحديدك لتخطيطات متجاوبة للأجهزة المختلفة. يُعد التطوير بالنسبة للهواتف الذكيّة أكثر تطلبًا بخلاف الإصدارات الخاصّة بالحواسيب المكتبيّة حيث تتوفر مساحات كافية لعرض المحتوى. فمن الضروري أكثر من أي وقت مضى تجميع محتويات محدّدة وتحديد أهميّة الأجزاء الفرديّة هرميًّا. إنّه من المهم أكثر من أي وقت مضى بالنسبة للهاتف الذكي تجميع محتويات محدّدة وتحديد أهمية الأجزاء الفرديّة هرميًّا. إنّ الاستخدامات المختلفة لمحتواك مهمة أيضًا. فمثلًا عندما يكون لدى المستخدم إمكانية استخدام الفأرة يمكنه عندها ضبط المؤشر فوق عناصر معيّنة للحصول على معلومات إضافيّة، بحيث يمكنك (كمطوّر ويب) ترك بعض المعلومات لتُجمّع بهذه الطريقة - لكن الحال لن يكون ذاته عند استخدام الهاتف الذكيّ. بالإضافة إلى ذلك، إذا وضعت أزرارًا على موقعك والتي ستظهر على الهواتف الذكيّة بحجم أصغر من الحجم النموذجي للإصبع، فسَتخلق حالةً من عدم اليقين وعدم الارتياح في استخدام موقعك وفي مظهره. لاحظ إنّ عرض الويب القياسي في الصورة أعلاه (على اليسار) يجعل بعض العناصر غير قابلة للاستخدام تمامًا عند عرضها على جهاز أصغر. سيزيد هذا السلوك أيضًا من فرص قيام المستخدم بخطأ ما، مما يؤدي إلى إبطاء تجربته. يمكن أن يتجلى ذلك في الممارسة العمليّة في انخفاض عدد مرات عرض الصفحة، وانخفاض المبيعات، ومشاركة أقل بشكل عام. عناصر تصميم متجاوبة أخرى يتوجب تذكّر سلوك جميع عناصر الصفحة عند استخدام استعلامات الوسائط وليس فقط العناصر المستهدفة -لا سيما عند استخدام «الشبكات المرنة» (fluid grids)- وفي هذه الحالة (وعلى عكس الأبعاد الثابتة) ستُملئ الصفحة بالكامل في أي وقت، وسيكبر ويصغر حجم المحتوى بما يتناسب معها. نظرًا لتعيين قيم العرض بالنسب المئوية، يمكن أن يحدث تشوه للعناصر الرسوميّة (أي الصور) أو تلفها عند استخدام الشبكات المرنة. إنّ أحد الحلول للصور هو كما يلي: img { max-width: 100% } يجب التعامل مع العناصر الأخرى بطرق مماثلة. فمثلًا يُعدّ استخدام IconFontsحلًّا رائعًا للأيقونات في تصميم الويب المتجاوب. نبذة عن أنظمة الشبكات المرنة عندما نناقش عملية التكيّف الكامل للتصميم فإننا غالبًا ما نتطلع إلى تجربة المشاهدة المثلى (من وجهة نظر المستخدم). يجب أن تتضمن مناقشة كهذه الحد الأعلى لسهولة الاستخدام ولأهميّة العناصر (استنادًا إلى مناطق الصفحة المرئية) ولسهولة القراءة وللتنقل السهل. يُعدّ ضبط عرض المحتوى (content width) من أهم المكونات من بين التصنيفات السابقة. حدَّدت على سبيل المثال ما يسمى بأنظمة الشبكات المرنة عناصر تعتمد على العرض النسبي كنسب مئوية من الصفحة الإجمالية. وبهذه الطريقة تُضبط تلقائيًا جميع العناصر في نظام تصميم الويب المتجاوب بما يتناسب مع حجم الصفحة. على الرغم من أن أنظمة fluid grids هذه ترتبط ارتباطًا وثيقًا بما ناقشناه هنا، إلا أنّها في الحقيقة كيان منفصل بالكامل يتطلب تعليمًا إضافيًا للمناقشة التفصيليّة. لذلك سأذكر هنا فقط بعضًا من الأُطر الرئيسيّة التي تدعم مثل هذا النهج: Bootstrap و Unsemantic و Brackets. الخلاصة كان تحسين موقع الويب حتى وقت قريب مصطلحًا مخصّصًا حصريًا لتخصيص الوظائف استنادًا إلى متصفحات الويب المختلفة. يفترض هذا المصطلح الآن إلى جانب الصراع المحتوم مع معايير المتصفح المختلفة التي نواجهها اليوم التكيف مع الأجهزة والأحجام المختلفة الشاشة ومع تصميم الويب المتجاوب أيضًا. ولكي يتناسب مع شبكة الإنترنت الحديثة. يجب أن يعرف موقعك ليس فقط من يتصفحه ولكن كيف يتصفحه. ترجمة وبتصرف للمقال Introduction to Responsive Web Design: Pseudo-Elements, Media Queries, and More لصاحبه Tomislav Krnic.

أطلقتُ مدوّنة ووردبريس منذ عامين. أضفت إليها الكثير من المحتوى لبضعة أشهر. كتبتُ المقال بعد المقال، مع التركيز على أن يكون المحتوى عالي الجودة. كل هذا أملاً في أن يأتي النجاح ولو بعد حين. ولكن كما هي العادة في هذه القصص، بعد فترة صرفتني التزامات أخرى عن المدوّنة، وتركتها في حالة من الإهمال. لم أنشر حتى كتابة هذه السطور مقالاً واحدًا على الموقع لمدّة تزيد عن 15 شهرًا. كانت المدوّنة تجذب أقل من 2000 زائرًا شهريًا وقت التخلّي عنها. قررتُ قبل بضعة أيّام التحقّق من إحصاءات الموقع على تحليلات جوجل للمرّة الأولى خلال مدّة تزيد عن العام. والعجيب أنّي اكتشفت أنّ المدوّنة قد جذبت أكثر من 10,000 زائرًا في الشهر السابق من دون أيّ تدخل من طرفي. ربّما تقول أنّها أيّام سعدي ولكن كانت هناك مشكلة كبيرة: المقاييس. نتحدّث بالتحديد عن معدّل ارتداد (Bounce Rate) تجاوز 90%، فقط 1.18 صفحة في الجلسة الواحدة ومتوسّط الجلسة 46 ثانية. إذًا ما هو المغزى من القصّة؟ ببساطة لا يهم عدد الزّيارات الذي تحصل عليه، فإنّ موقعك لن يربح شيئًا إذا لم يكن مُحسّنًا بشكلٍ يتوافق مع قابلية الاستخدام. يعتبر الحصول على زوّار لموقع هو نصف التحدّي، ما يهمّ حقًّا هو جعل هؤلاء الزوّار يسجّلون في موقعك. ومن تجربتي فإنّ قابلية الاستخدام غالبًا ما تكون الجانب الذي تُهمله الكثير من المُدوّنات والمشاريع التقنية على الويب. لحسن الحظّ فإنّ ووردبريس (وعدد لا يحصى من القوالب والإضافات) يعطينا كل الأدوات التي نحتاجها لبناء مواقع قابليّة استخدامها عالية. في هذا المقال سنقوم باستكشاف خمسة طرق رئيسيّة والتي من خلالها يمكنك جعل تجربة تصفّح موقع ووردبريس الخاص بك ممتعة أكثر. لماذا يعد "تحسين تجربة المستخدم" سببا في غاية الأهمية لنجاح موقعك/ مدوّنتك ربّما لا حاجة لي أن أذكّرك بماهية تجربة المستخدم (User Experience – UX) ولكن إذا كنت ترغب في معرفة المزيد، فلدينا قسم يحتوي مجموعة مقالات حول تجربة المستخدم على أكاديمية حسوب. كما هو مُتوقّع فإن تحسين تجربة المستخدم (User Experience Optimization – UXO) تهدف إلى تحسين موقعك ليكون أكثر قابلية للاستخدام. لاحظ أنّنا هنا لا نتحدّث عن جانب تصميم الموقع في حدّ ذاته. فيمكن لموقع سيء التصميم أن يقدّم تجربة مستخدم رائعة لجمهوره المستهدف. إنّما نتحدّث هنا تحديدًا عن "قابلية استخدام" موقعك. يرتبط هذا الأمر ارتباطًا وثيقًا بالتصميم الخاص بموقعك ولكن لا يعتمد بالضرورة على جودة التصميم في حدّ ذاتها. لن نتطرّق اليوم لكيفيّة جعل موقعك يبدو جميلًا وإنّما سنتطرّق إلى كيف تجعل موقعك قابلاً للاستخدام على أكمل وجه. الأمر الذي يهم في نهاية المطاف إذا أردت الحصول على عدد أكبر من الزوّار الدائمين. 1- التصميم المتجاوب (Responsive Design) من المؤكّد أنّك تعرف مدى أهميّة التصميم المتجاوب. إلا أنّه هناك اختلافًا كبيرًا بين معرفة أهميّة التصميم المتجاوب وأن يكون لديك بالفعل تصميم ووردبريس متجاوب وقابل للاستخدام بشكلٍ عالي الجودة. الأمر بسيط: إذا كان موقعك غير قابل للاستخدام على أكبر عدد من الأجهزة المستخدمة بواسطة جمهورك المستهدف، فإنّ موقعك لا يعدّ متجاوبًا بما فيه الكفاية. لأن هذه هي الفكرة عندما يتعلّق الأمر بالتجاوب. موقعك ليس إما مُتجاوبًا أو ليس مُتجاوب فالإجابة على هذا السؤال (هل موقعك مُتجاوب) ليست “نعم” أو “لا” بل هي نسبة مئوية إن صحّ التّعبير، حيث يجب أن نجيب على سؤال آخر وهو "ما نسبة الزيارات التي يظهر فيها موقعك مُتجاوبًا". يمكنك معرفة أكثر الأجهزة التي يستخدمها زوّار موقعك من خلال تحليلات جوجل عن طريق مسار Audience > Mobile > Devices: في المثال أعلاه يمكنك رؤية أنّ غالبيّة زوّار الموقع يستخدمون أجهزة Apple iPhone وiPad. ثاني أكثر الأجهزة شيوعًا لدى زوّار الموقع هو Nexus 5. بناءً على هذه البيانات فمن الطبيعي أن تقوم باختبار موقعك على iPhone وiPad. لن أخوض في تفاصيل اختبار قابلية الاستخدام لأجهزة الهاتف. بدلاً من ذلك فسنركّز على الإجابة على السؤال البديهي: هل تصفّح موقعك يبدو سهلاً على الهاتف الذي قمت باختياره؟ سيكون من الجيّد إذا استطعت طلب مساعدة من قريب أو صديق لك في هذا الاختبار (خاصّةً إذا لم ير هذا الشخص موقعك من قبل). إذا كنت تملك الجهاز المستخدم بصورة أكبر لتصفّح موقعك فبالتأكيد يمكنك اختبار موقعك عن طريق هذا الجهاز. ولكن إذا لم يكن لديك الجهاز فأقترح عليك أدوات اختبار مثل MobileTest.me وأداة StudioPress' responsive testing. هذه الخدمة رائعة أيضًا. نقطة أخيرة: إذا لم تكن لديك الوسائل الكاملة للحصول على تصميم متجاوب لموقع ووردبريس الخاص بك فبإمكانك استخدام Jetpack's Mobile Theme. هذا القالب ليس الحل الأمثل، ولكنّه مجّاني وفوري التنفيذ. 2- الانتقال الثابت (Fixed Navigation) يمكنك تخمين ما تقوم به هذه الخاصيّة من اسمها: يبقى شريط القوائم ثابتًا في الجزء العلوي من الشاشة عندما تقوم بالتمرير (Scroll)، بدل اختفائه. تزيد خاصيّة الانتقال الثابت من قابليّة استخدام موقعك حيث أنّها تعتبر بمثابة ضمان لإمكانيّة وصول الزوّار لأكثر الروابط أهميّة في موقعك أغلب الوقت. نظرًا لحجم شاشات الهواتف، فيجب عليك إذا كنت تستخدم خاصيّة الانتقال الثابت أن تتأكّد من أن شريط الانتقال لا يستولي على معظم مساحة الشاشة بالنسبة للهواتف ذات الشاشات الصغيرة. راجع قسم التصميم المتجاوب أعلاه لمعرفة الأدوات التي يمكنك اختبار تصميم موقعك من خلالها على أجهزة الهاتف للتأكد من شريط الانتقال يعمل بالشكل المطلوب. إذًا كيف يمكنك إضافة شريط الانتقال الثابت إلى موقعك؟ هناك عدّة حلول. هناك الكثير من قوالب ووردبريس التي تقدّم لك إمكانيّة الحصول على شريط انتقال ثابت كأمر أساسي لكن لا تبدو فكرة استبدال قالب بآخر لمجرد الحصول على هذه الخاصّيّة فكرة عملية. لحسن الحظ فإن هناك إضافات ووردبريس مجّانية جاهزة لحلّ هذه المشكلة ، لديك حرية الاختيار من بين ثلاث إضافات مجّانيّة عالية الجودة متاحة للتحميل: Sticky Header myStickymenu Sticky Menu (or Anything!) on Scroll 3- قائمة جانبية ثابتة (عناصر) بعد استعراض الانتقال الثابت يمكنك بسهولة تخمين ما تفعله القائمة الجانبيّة الثابتة. برأيي فإنّ هذه الميزة لها تأثير أقلّ من قائمة الانتقال الثابتة من ناحية قابليّة الاستخدام إلا أنّها تعتبر مفيدة إذا أردت على سبيل المثال جذب الانتباه إلى عنصر محدّد مهم في موقعك. لاحظ أنّني قد قمت بتضمين كلمة "عناصر" أعلاه لسبب وجيه – ستكون الخاصيّة أكثر فعاليّة إذا أردت تثبيت عنصر محدّد من الشريط الجانبي بدلاً من الشريط بأكمله. بإمكانك تثبيت القائمة الجانبية باستخدام: الإضافة المذكورة سابقًا Sticky Menu أو وودجت Q2W3 Widget - Sticky Widget: 4- أزرار المشاركة الاجتماعية العائمة (Floating Social Share Buttons) من المؤكّد أنّك رأيت أزرار المشاركة الاجتماعيّة العائمة من قبل. الصورة التالية مثال على هذا النوع من الأزرار: يمكن لهذه الأزرار أيضًا أن تظهر إلى جانب المحتوى إلا أنّ هذا النّوع لم يعد شائعًا كما كان. إحدى العثرات التي يجب الحذر منها بالنّسبة لأزرار المشاركة الاجتماعيّة العائمة هي طريقة ظهورها في أجهزة الهواتف. هل تختفي جميع الأزرار معًا، وإذا كانت تختفي معًا فعلاً، كيف يمكن للمستخدم المشاركة من جهازه بسهولة عن طريق حلّ بديل؟ كل هذه هي أسئلة عليك الإجابة عليها من منظور قابليّة الاستخدام. إذا كانت أزرار المشاركة العائمة تختفي بالفعل فإنّك بحاجة لإيجاد حل بديل سهل الاستخدام لمستخدمي الهواتف النقّالة. إذًا كيف يمكن إضافية خاصيّة أزرار المشاركة الاجتماعيّة العائمة على موقع ووردبريس الخاص بك؟ ستقوم إضافة Floating Social بتنفيذ الأمر ببساطة. لا يوجد هناك الكثير من البدائل في الوقت الراهن ولكن الإضافتين Flare و Digg Digg يمكنهما تقديم الخاصيّة إلا أنّه لم يتمّ تحديثهما منذ فترة. بديل آخر لكل الحلول المعروضة أعلاه هو دمج أزرار المشاركة الاجتماعيّة الخاصّة بك في قائمة التنقّل الثابتة أو في القائمة الجانبيّة الثابتة في موقعك. غيض من فيض تردّدتُ كثيرًا عند كتابة هذا المقال لمعرفتي بأن الطرق التي يمكن استخدامها لزيادة قابليّة استخدام موقعك كثيرة جدًا. رغم ذلك فإنّك في نهاية المطاف اكتفيت بأربعة طرق فقط. هناك الكثير من الطرق إضافة إلى الأربعة طرق المذكورة سابقًا يمكنك استخدامها لتحسين قابلية المستخدم الخاصّة بموقعك. ركّزنا في هذا المقال على بعض الأشياء الأكثر ظهورًا للمستخدم ولكن في الحقيقة فإنّ الأشياء غير المحسوسة هي التي تخلق فرقًا أكبر بالنسبة لقابليّة الاستخدام. على سبيل المثال، تعتبر سرعة التحميل جزءًا كبيرًا جدًّا من قابليّة الاستخدام. إذا استغرق موقعك وقتًا طويلاً في التحميل فإنّ معظم الزّوار سيقومون ببساطة بمغادرة الموقع، في هذه الحالة فإنّ جميع جوانب موقعك ستصبح بلا معنى. مع أخذ ذلك في الاعتبار، يمكنك العمل على كل شيء بدءًا من تحسين الصورة، إلى التخزين المؤقّت، إلى حلول شبكة توصيل المحتوى (Content Delivery Network) ولا تنسى أدوات سرعة الصفحة. ترجمة -وبتصرّف- للمقال 4Quick Ways To Lower Your WordPress Site's Bounce Rate لصاحبه Tom Ewer

أصبحت قابلية الوصول accessibility من أبرز المواضيع والنقاشات تداولًا بين مطوّري الويب، وازداد اهتمام أصحاب المواقع حول قابلية الوصول ومدى تكيّف مواقعهم مع أغلب الأجهزة والشاشات، وأعطى هذا الاهتمام المتزايد المجال لبزوغ شكل جديد كليًا من أشكال التصميم وحمل الاسم ‹‹تصميم المواقع المتجاوبة Responsive Web Design››، فمع زيادة حصّة أجهزة الهاتف والأجهزة اللوحيّة، أصبح من الضروري التأكّد من تجاوبيّة وتوافقيّة الموقع مع أي جهاز يستطيع الوصول إلى الإنترنت. يهتم كل من التصميم الُمتلائم AWD والتصميم الُمتجاوب RWD في كيفيّة عرض صفحة الموقع على مختلف الأجهزة والشاشات، إذا ما الذي يجعل لكل منهما كينونة خاصة به؟ هذا ما سيُجاب عليه في السطور القادمة في توضيح للفروقات الجوهرية بين التصميم المتجاوب RWD والتصميم المتلائم AWD. ما هو التصميم المتلائم (Adaptive Web Design (AWD؟يَستخدم التصميم المُتلائم الخادوم server في تحديد الجهاز المستخدم في تصفّح الموقع، بمعنى آخر، سيُستخدم الخادوم في تحديد فيما إذا كان الموقع يُعرض على جهاز سطح مكتب أو هاتف ذكي smartphone أو جهاز لوحي tablet، وكما سيُستخدم قالب template منفصل لكل جهاز على حِدة، بمعنى سيختلف القالب template المعروض على شاشة الحاسب المحمول عن القالب المعروض على شاشة الهاتف الذكي، وبما أن الموقع المصمم باستخدام التصميم المتلائم مستضاف على مجال domain خاص به، فإن صفحات الموقع تحمّل بسرعة عالية نسبيًا. ما هو التصميم المتجاوب (Responsive Web Design (RWD؟يَستخدم التصميم المُتجاوب شيفرة CSS محدّدة لتعديل مظهر الموقع وفقا للجهاز الذي يستعرض الموقع، والبيانات المرتبطة بكل جهاز تُحمّل بصرف النظر فيما إذا كانت تُستخدم أم لا، وتمامًا عكس المواقع المصممة باستخدام التصميم المتلائم، فإن المواقع المصممة باستخدام التصميم المتجاوب تُحمّل بسرعة منخفضة نسبيًا. ما هو الفرق إذا؟يكمن الاختلاف الجوهري بين التصميم المتلائم والتصميم المتجاوب في أن المتلائم سيتغيّر تغيّرًا كليًّا لكي يُلائم أبعاد الشاشة المختلفة، بينما المتجاوب سيتغيّر بانسيابية ليتجاوب مع مجموعة من الأجهزة وقياسات الشاشات، وعليه سنستعرض بقيّة الفروقات التفصيليّة بين التصميم المتلائم AWD والتصميم المتجاوب RWD: يَستوجب استخدام التصميم المتلائم تطوير موقع منفصل إما عن طريق عناوين URLs منفصلة أو عن طريق تطوير شيفرة HTML/CSS منفصلة، وبالمقارنة بالمثل، فإن التصميم المتجاوب RWD يعتمد على HTML/CSS3 و جافا سكريبت كليًّا، مما يوفّر على المطوّر تطوير وصيانة عناوين URLs منفصلة و/أو HTML/CSSs.إن صُمّم الموقع باستخدام التصميم المتلائم، فإن إجراء التعديلات سيَستوجب مراجعة SEO (تحسين محركات البحث) والمحتوى وبُنية الموقع، وبعكس ذلك فإن صُمّم الموقع باستخدام التصميم المتجاوب، فإن إجراء التعديلات سيكون سهلًا للغاية لأن إجراءات تحسين محركات البحث والمحتوى والروابط links موجودة جنبًا إلى جنب مع HTML/CSS وجافا سكريبت JavaScript.بينما يَعتمد التصميم المتلائم على قياسات الشاشة المحددة مسبقًا، فيعتمد التصميم المتجاوب على شبكة grid مرنة وسلسة، بمعنى آخر، يتطلّب التصميم المتجاوب مزيدًا من الشيفرة البرمجية ليلائم صفحات الويب مختلفة القياسات، بينما يملك التصميم المتلائم تصميم معدّ مسبقًا تحدده برمجية معينة من جهة الخادوم في سبيل ملائمة قياسات الشاشة المختلفة.يقع الحمل الأكبر على عاتق الخادوم في معالجة تجاوبيّة الصفحات مع التصاميم المتلائمة، بينما يقع الحمل الأكبر على عاتق المُتصفّح (جهة العميل) في معالجة تجاوبيّة الصفحات.يستغرق التصميم المتلائم وقتًا أطول في التطوير، على عكس التصميم المتجاوب والذي يتطلّب وقتًا أقل نسبيًا.إن المواقع المصممة باستخدام التصميم المتلائم AWD تتعامل مع صور محسنة ومعدّلة لكل جهاز وقياس شاشة، بينما المواقع المصممة باستخدام التصميم المتجاوب RWD تحمّل الصور أوّلًا على المتصفّح ومن ثم يُعاد تحجيمها لتُلائم الجهاز الموافق لها.خاتمةبصرف النظر فيما لو اختير التصميم المتلائم Adaptive Web Design أو التصميم المتجاوب Responsive Web Design، فمن المهم وجود استراتيجية معينة من أجل أجهزة الهاتف، والتأكّد دائمًا من أن محتوى الموقع مُحسّن للزوّار مهما كان الجهاز المستخدم في تصفّح الموقع، طبعًا مع الحفاظ على موقع جميل ومتناغم الألوان والعناصر. ترجمة وبتصرّف للمقال Responsive Web Design vs Adaptive Web Design - Whats the Difference لصاحبه Mike Swan.