المحتوى عن 'سهولة الوصول'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • ASP.NET
    • ASP.NET Core
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • سهولة الوصول
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 6 نتائج

  1. كنت أعمل البارحة على إنشاء الشرائح والعروض التجريبية المرافقة لحديثي القادم عن الشيفرة في موقع web directions الأسبوع المقبل. أحد العروض التجريبية التي أنشئها هو دليل أساسي لمفهوم المفتاح البسيط الذي يُستخدم لتبديل مظهر واجهة المستخدم من مضيء إلى مظلم وبالعكس، أحببته واستلهمته من مبدّل المظهر في تطبيق Medium المبين أدناه. مُخصِّص مظهر تطبيق Medium هو لوحة منبثقة بسيطة تتضمن مفتاح بسيط للتبديل من وضع مضيء إلى مظلم وبالعكس. الاختلاف الوحيد الذي أريده هو أن يشير مفتاحي إلى حالة المظهر الفعالة حاليًا بشكلٍ واضح. لذا بدلًا من تفعيل وتعطيل المظهر المظلم فقط مثل مفتاح Medium، أريد أن يبدّل المستخدم بين خيارَي مضيء ومظلم بوضوح. لا يوجد سبب محدد لذلك سوى أنّه تفضيل شخصي. هناك طرق أخرى للقيام بذلك أيضًا، يبقى أمر كيفية تصميمه تفضيلًا شخصيًا، طالما أنّه يعمل وقابلًا للفهم بسهولة من قِبل المستخدمين. بدأت أفكر كالعادة في كيفية تمييز هذا العنصر البسيط، مع التأكّد من سهولة الوصول إليه مباشرةً من البداية. لذا بدأت القيام بواجبي وقراءة وتعلّم كل ما بوسعي بشأن هذا الموضوع. كان من المهم بالنسبة إليّ التأكد أنّ هذا العرض التجريبي سهل الوصول حتى لو كان مجرد دليل سريع للمفهوم لحديث. أولًا وقبل كل شيء، بما أنّ شيفرة العرض التجريبي ستكون متاحة للعامة، كان لدي مسؤولية أكبر للتأكّد من أنّها سهلة الوصول، لأنني لا أريد نشر أي شيفرة لا يمكن الوصول إليها، خاصةً إذا كان هناك فرصة ليستخدمها الناس في مكان آخر. وأردت أن تكون الشيفرة جيدةً لسببٍ آخر هو أنّني ربما أرغب في إعادة استخدامها لمكونات أخرى في ورشة عمل قادمة لي حول تطوير الواجهة الأمامية. البدء بالشيفرة كما ذكرت أعلاه، بدأت أفكر في كيفية ترميز هذا العنصر لضمان سهولة وصوله إلى قارئات الشاشة. عندها أدركت (وأحسست بالغباء نوعًا ما) أنّ الوظيفة والترميز يعتمدان على الطريقة التي أريد أن يكون سلوك التبديل بها وكيف أريده أن يظهر. كان الأمر واضحًا جدًا بالنسبة لي: سيسمح المفتاح للمستخدم بالاختيار بين المظهر المضيء والمظهر المظلم، وسيكون المظهر المضيء هو الافتراضي. وفي هذه اللحظة تبادر إلى ذهني أزرار الانتقاء (radio buttons): خياران يمكن تفعيل أحدهما فقط في وقت واحد، هذا يمكن أن يصنع حالة استخدام ممتازة لأزرار الانتقاء القديمة الجيدة. كنت أعلم أنّه يجب عليّ اختيار شيء ما مختلف في حال أردت أن تبدو واجهة المستخدم وتتصرف بشكلٍ مختلف. مثلًا، إذا أردت لواجهة المستخدم أن تعرض "تفعيل/تعطيل النمط المظلم"، عندها لن أحتاج إلى استخدام أزرار الانتقاء لأنّ لدي خيارًا واحدًا فقط للتعامل معه وهو التشغيل أو إيقاف التشغيل، سيكون ذلك حالة استخدام رائعة لمربع تأشير (checkbox) أو عنصر زر <button> تبديل قديم جيد. تحليلات التصميم والوظيفة مترابطان، مما يساعد على التفكير في هذين الأمرين في وقت واحد عند التصميم لسهولة الوصول (وفي الحقيقة تصميم أي شيء بشكلٍ عام). ابدأ دائمًا وأبدًا بالتفكير حول الترميز وسهولة الوصول عند إنشاء المكونات بغض النظر عن مدى صغرها وبساطتها. دراسة كنت بحاجة -كما هو الحال دائمًا- إلى دعم نظريتي وتطبيقي العملي بالبحث الجيد، لذا بدأت بالقراءة، مراجعي الأولى التي ألجأ إليها هي المكونات الشاملة ومشروع A11y لـ Heydon Pickering. كما اتّضح، لدى Heydon مقالة رائعة حول أزرار التبديل تعلّمت منها الكثير، ولدى صديقي Scott O’Hara زر تبديل ARIA مضمّن في قسم الأنماط من مشروع A11y. لذلك، بطبيعة الحال، فحصتُ شيفرة الزر وقرأتُ مقالة Heydon للتأكّد فيما إذا كنت على الطريق الصحيح. تجدر الإشارة قبل المتابعة إلى أنّ هذه ليست مقالة حول كيفية إنشاء مفاتيح تبديل سهلة الوصول. مقالة Heydon تقوم بعمل رائع يغطي ذلك. النقاط الرئيسية التي استخلصتها شخصيّا من البحث أعلاه هي: هناك أنواع مختلفة من المفاتيح التي تبدو وكأنّها تقوم بأشياء مماثلة ولكنها تختلف اختلافًا جوهريًا عندما يتعلق الأمر بالترميز وسهولة الوصول. ليس بالضرورة أن تكون متشابهة، لمجرد أنّها مصممة لتظهر بنفس الشكل. أحتاج إلى التفكير بالسلوك الذي ستسلكه واجهة المستخدم، الشكل والصوت عند التبديل. أولًا التصميم وتجربة المستخدم، ثمّ الشيفرة. يمكن استخدام مفتاح التبديل للتبديل بين خيارين منفصلين، أو يمكن استخدامه لتشغيل خيار واحد أو إيقاف تشغيله (أو مثل تفعيل/تعطيل خيار). هنا تبدأ اختلافات التطبيق بالظهور. إذا كنت تبدّل بين خيارين منفصلين، فإنّ استخدام أزرار الانتقاء القياسية يبدو منطقيًا. يتم استخدام أزرار الانتقاء عندما تريد من المستخدمين اختيار خيار واحد فقط من خيارين أو أكثر، لذا فإنّ هذه حالة استخدام مثالية لهم. لديهم أيضّا إمكانية وصول أساسية وسيتم وضع إشارة إلى جانب الخيار الذي تم تفعيله. تأكّد فقط أنّك لا تحدّ من إمكانية الوصول لأيٍّ منهما في HTML أو باستخدام CSS. إذا كان الهدف من التبديل هو تفعيل/تعطيل ميزة (أو تشغيلها/إيقافها)، هناك طرق أخرى لذلك: استخدام صندوق تأشير لتأشير/إلغاء تأشير (تفعيل/تعطيل) هذا الخيار. استخدام زر <button> يكون له حالتان: مضغوط وغير مضغوط. تتطلب هذه الطريقة استخدام ARIA والذي بدوره سيتطلب جافاسكربت لتعمل التقنيات المساعدة بشكل صحيح (يتم تحديث قيم خاصية ARIA عند الضغط باستخدام جافاسكربت). اقرأ مقال Heydon للمزيد من التفاصيل عن هذه الطريقة. تعني هذه الطريقة أن لديك خيارًا واحدًا فقط، وهذا يعني بدوره أنّ زر التبديل له تسمية واحدة مرتبطة فقط، وربما لن يبدو زر "التبديل المزدوج" بعد الآن، إلا إذا: حالات زر التبديل المزدوج (التي تشير إلى تشغيل/إيقاف) سيكون لها نصّا واضحًا يصف الحالة الحالية الفعالة، لذا ستبدو مثل هذا المثال من العرض التجريبي لـScott في مشروع A11y: بالنسبة لاستخدامي لمحوّل المظهر، فهو خيارٌ واضحٌ: بما أنّ المستخدم لديه خيارات (مظلم ومضيء)، أردت استخدام أزرار الانتقاء. لم أكن أريد أن أقول "تشغيل/إيقاف تشغيل الوضع المظلم" إنّما أردت أن أقول "تفعيل الوضع المضيء أو تفعيل الوضع المظلم". سيكون الحل هو HTML وCSS فقط، ولا يتطلب جافاسكربت، وستتم إتاحة إمكانية الوصول بشكلٍ افتراضي. تحليل دَع لديك فكرة واضحة حول كيفية تصميم المكون وماذا يُفترض أن يفعل أو لا يفعل، واجعل الترميز والتصميم يعتمدان على هذه الفكرة. فحص الشيفرة الآن، وبعد قراءة وفحص المصادر السابقة، قررت أن أرى كيف يقوم الناس بالتبديل. بعد كل ذلك، كنت أعلم أنني سأجد الكثير من الأمثلة لمفاتيح التبديل التي تبدو وتتصرف مثل هذا المثال الحي على codepen، من الرائع دومًا أن أرى كيف يفعل الآخرون ذلك - ربما أفتقد بعض التقنيات الرائعة التي يمكن أن أتعلمها للتصميم، أو ربما أفتقد بعض المعلومات المهمة عندما يتعلق الأمر بالترميز وقابلية الوصول. نظرًا لأنني كنت أعمل في codepen على نسختي الخاصة من هذا المفتاح (شاركت العرض التجريبي أدناه)، أظنُّ أنني فحصت مفتاح التبديل الخاص بـcodepen: المفتاح الذي تستعمله لاختيار فيما إذا إذا كنت تريد لتصميمك أن يكون عامًا أو خاصًا. تحليل سريع من المفيد والممتع أن تتعلم من عمل الآخرين بفحص شيفرتهم (سواء ذلك عن طريق أدوات المطور [devtools] أو على codepen). مفتاح الخصوصية في Codepen يعرض مفتاح التبديل في codepen بعض السلوكيات الغريبة التي لاحظتها سابقًا ولكن لم أشعر أبدًا بالفضول لأقوم بال"تنقيح". يُظهر الفيديو التالي هذا السلوك: Your browser does not support the video tag. تجدر الإشارة أولًا إلى أنّني كنت محتارة بشأن هذا المفتاح. دائمًا ما يعطي اللون الأحمر مقابل الأخضر حلقة ردود فعل غريبة. إذا جعلت التصميم خاصًا، سيتحول اللون للأخضر، وجعله عامًا سيجعل اللون أحمر. بالنسبة لي فإنَّ الأخضر يعني أكثر من ذلك "التصميم قابل للوصول من قِبل الأشخاص، إنّه متاح" واللون الأحمر أكثر من ذلك "هذا التصميم مغلق، لا يُسمح للأشخاص بالوصول". ولكن بالنسبة لـcodepen فإن هذه الألوان ترمز إلى أشياء أخرى. وبشكل أكثر تحديدًا يرمز الأحمر إلى "المنطقة العامة = المنطقة الخطرة" أو "احذر هذا التصميم متاح للعامة وهذا غير جيّد". (آسفة لأنّي درامية جدًا، ولكن هذا هادفًا). ثمّ هناك سلوك الأخطاء المبيّن في الفيديو أعلاه (إذ أنّ النقر على نفس التسمية يغيّر قيمة المفتاح إلى قيمة التسمية الأخرى). كنت فضولية مجددًا لمعرفة سبب ذلك، شغّلتُ أدوات المطور وفحصت الشيفرة. وجدت أنَّ مفتاح codepen هو صندوق تأشير واحد يبدو أنّه يحتوي تسميتين. لذلك عند الضغط على "عام" و"خاص" معًا عدة مرات يؤدي إلى تشغيل وإيقاف تشغيل المفتاح عدة مرات. بكلماتٍ أخرى، هذا هو السبب في أنَّ رد الفعل/ السلوك المرئي للمفتاح لا يُطابق هدف المفتاح أو ما يبدو أنّه يعمل. كتبت تغريدةً حول هذا الخطأ، وسببه المحتمل واقترحتُ حلًا بديلًا يُصلح الأمر. بدأت في الحصول على ردود وآراء من مطورين آخرين، مما أدّى إلى نقاش جيد ومفيد للغاية استمتعت به تمامًا (أحد الجوانب الإيجابية القليلة في تويتر). بالطبع، كان الإجماع العام هو أنّ المفتاح يحتاج إلى إصلاح. لكن كيفية إصلاحه تعتمد بشكلٍ كبير على ما يريد فريق codepen القيام به: إذا كان من المفترض أن يكون مفتاح التبديل هو زر تفعيل/تعطيل للخيار "خاص" عندها: هذا يعني أنّ نمط التبديل تشغيل/إيقاف المذكور في القسم السابق أعلاه سيكون الحل المثالي. هذا يعني أنّه سيتم تجاهل التسمية "عام" والاحتفاظ بالتسمية "خاص" فقط، مع إشارة واضحة إلى أنّ المفتاح المجاور لها يعمل على إيقاف الخيار أو تشغيله، وهذا يقودني إلى نقطة أخرى: يجب إمّا أن يتغير التمثيل البصري للمفتاح بالكامل أو يتم تعديله: إذا كان يجب أن يبقى زر المفتاح كما هو بصريًا (أي الحفاظ على سلوك المفتاح المزدوج "نقل هذا التبديل يسارًا ويمينًا")، أقترح إضافة تسميات "تشغيل/إيقاف" له بشكلٍ شبيه لما فعله Scott في عرضه التجريبي مشروع A11y، لأنّه وفقًا لإرشادات الوصول لمحتوى الويب (WCAG)، يجب ألا تستخدم اللون فقط لنقل المعلومات. تحتاج الألوان أيضًا أن يكون لديها تباين كافٍ إذا كنت تستخدمها. ومرةً أخرى، كنت أعيد النظر في ألوان الأحمر والأخضر لأنّها قد تربك شخصًا ما مثلما أربكتني لفترةٍ من الوقت. (اقترح عليّ أحدهم الرمادي والأخضر، لأنّ "إضافة اللون يمكن أن تدلّ بشكلٍ كبيرٍ على الحالة الفعّالة (بدون لون مقابل لون يواجه لونين منفصلين)"). يمكن أن تكون البنية الأساسية والترميز لهذه الحالة (تسمية واحدة فقط): صندوق تأشير، يمكن أن يكون مفعّلًا أو غير مفعّل. أودّ اقتراح استخدام تصاميم صندوق تأشير بسيطة (ربما رائعة) لهذا السلوك والتخلّي عن أسلوب التبديل المزدوج بالكامل. زر <button> مع خاصية aria-pressed (و aria-checked إذا احتجت)، إذ تشير حالة الضغط إلى أنّ التصميم خاص، وحالة عدم الضغط إلى أنّ التصميم غير خاص، أي أنّه عام. سيتغير تصميم الزر في هذه الحالة أيضًا، وقد يتطلّب سلوكه استخدام جافاسكربت لتعديل قيمة خواص ARIA عند الضغط. إذا كان من المفترض أن يعرض مفتاح التبديل خيارين بشكلٍ واضح ويمكّنهما: عام وخاص برأيي، عندها سيكون استخدام زوج من أزرار الانتقاء له معنىً كبير. يعلن زري الانتقاء، كلّ منهما بتسمية خاصة به، عن تقنيات جذابة كخيارين منفصلين يجب على المستخدم اختيار أحدهما، وسهلة الوصول تمامًا عبر لوحة المفاتيح، ولا تتطلب ARIA أو جافاسكربت لتعمل، واستخدم قليلًا من الـCSS لها لتخلق تصميم زر "التبديل المزدوج" إذا أردت (حقيقةً لا أعرف ماذا أسميه بشكلٍ آخر) وستكون قمت بكل العمل. قد يختلف قليلًا الترميز والتصميم لمثل هذا الحل بين المطورين، ولكن جوهر الشيفرة سيكون نفسه. وهذا سيقودني إلى التجربة الحية… مثال حيّ هذا تنفيذي لمفتاح تبديل بين خيارين. لقد قمت بإنشاءه ليس كحلّ لمفتاح codepen، لكن ببساطة كمفتاح لتبديل المظهر مضيء/مظلم الذي أستخدمه في حديثي: سيكون مفتاح التبديل في سياق مجموعة أكبر من عناصر النموذج، لهذا السبب ليس لدي أيّ مجموعة حقول (fieldset) أو وسيلة إيضاح (legend) في العرض التجريبي. وأعلم جيّدًا أنّك قد تعدّل الشيفرة لعدم الحاجة إلى عناصر span إضافية في الترميز وتستخدم عناصر زائفة بدلًا منها، ولكنني على أيّة حال قد اخترت هذه الطريقة، فقط لأنني أريدها. جرّب أن تلعب بالشيفرة وتزيل تعليقات بعض التصاميم (حاول إزالة عناصر span بشكلٍ خاص لتشاهد كيف يبدو مفتاحي بدونها) لتحلل الشيفرة وتمتلك فكرة أفضل عن خياراتي وما الذي كنت أحاول تحقيقه. أضفت أيضًا تصميمًا للتأكّد من أنّ مستخدمي لوحة المفاتيح يمكنهم رؤية مكان التركيز، إذ أنني غطيت أزرار الانتقاء الافتراضية بعناصر span، ولم يتم تسليط الضوء على التسميات بشكلٍ افتراضي. استخدمت :focus-visible فقط في البداية (مع polyfill) لكنه لم يعمل كما هو متوقع في متصفحي فايرفوكس وسفاري، لذا انتهيت بإضافة :focus مجددًا واستخدمته بدلًا من :focus-visible. وأعلم أيضًا أنّ تصميم التركيز ليس جميلًا جدًا، لكن هذا العرض التجريبي هو مجرد دليل للمفهوم لذا لا يحتاج أن يكون جميلًا بشكلٍ ملفت للنظر. إذا كنت ترغب في مشاهدة عرض تجريبي آخر يستخدم أيضًا أزرار انتقاء لكن ينفذّها بطريقةٍ مختلفةٍ، بدون عناصر spanواستخدام عناصر زائفة، راجع هذا التصميم على codepen لصديقي Scott O’hara: كلمات أخيرة دعني أبدأ بالقول أنني قد أكون مخطئة. أعلم أنّ مستخدمي codepen قد يريدون شيئًا آخر مختلف تمامًا، أو يفكرون في شيء ما مختلف تمامًا. لذلك لا تهدف هذه المقالة إلى إعادة تصميم زر التبديل في codepen، إنّما تقدم توثيقًا لبحثي وتدريبي على التفكير أثناء العمل على إنشاء زر التبديل الخاص بي لحديثي. سأحتاج أن أقوم بالمزيد من الأبحاث عندما يحين الوقت لمتابعة عملي على ورشة العمل الجديدة الخاصة بي، وقد تتغير الأمور، وأعلم أنني سأتعلّم وأعرف المزيد عندما أنشئ مفتاحي التالي. لكن، حتى ذلك الحين، أعلم أنني حصلت على منشور المدونة هذا للإشارة إلى بعض الأفكار والآراء التي دارت في ذهني عندما اتخذت الخطوة الأولى لذلك. أتمنى أن تجد شيئًا مفيدًا بقراءتك لهذا المقال. إذا حصل ذلك بالفعل، فشكرًا لقراءتك. شكرًا. ترجمة -وبتصرف- للمقال On Designing and Building Toggle Switches لصاحبته Sara Soueidan
  2. واصل فريقي الوقوع في نفس النقطة مرارًا وتكرارًا في المراحل الأولى من كل مشروع. حتى عندما ملكنا مُحلِّلًا خاصًّا بسهولة الاستخدام بين أيدينا، لازلنا نعتمد في النهاية على الإحساس وصنع قرارات مبنية على العلم. أعطانا تحليل البيانات صورةً واضحةً عن ما كان يحدث ولكنه جعلنا نخمن، لماذا كان يحدث أصلًا. كنا قد حصلنا على ردود فعل هائلة من فحص سهولة الاستخدام، ولكننا شعرنا وكأن ردود الفعل لم تكن جديرة بالثقة حيث أن المستخدمين يتصرفون بشكل مختلف عندما يدركون بأنه تتم مراقبتهم. لذلك قمنا بصنع Jaco، وهي أداة تمكنك من رؤية ما يفعله الناس على موقعك أو تطبيقك. مهما كان تطبيقك معقدًا أو أيًا كان إطار العمل الذي تستعمله، فإن Jaco بإمكانه إعادة عرض كل جلسة مستخدم على شكل فيديو. خلال عملية تطوير Jaco، تعلمنا الكثير عن حالة الاستخدام لقدرة كهذه، واستخدمنا في الحقيقة Jaco لتطوير نفسه. التالي هو قصة حول كيف أضفنا Jaco لخط عملنا التقليدي وعن القيمة الإضافية التي ربحناها منه. بناء نسخة تجريبية لم يكن لدينا أدنى فكرة عن إذا ما كان Jaco شيءً يريده أو يحتاجه الناس، لذلك قمنا ببناء نسخة تجريبية لاختبار ردة الفعل. وكان هذا بتطوير إثبات عن الفكرة POC، وقررنا أن نشرك صفحتين أساسيتين فيها: صفحة الجلسات (لوحة التحكم الخاصة بنا) والتي تعرض قائمة بكل الجلسات المسجلة والأداء الوظيفي الأساسي لتصفية الجلسات حسب التاريخ، واسم المستخدم ورابط الصفحة الإلكتروني (بداخل الجلسة). صفحة المشغّل، حيثما يمكنك عرض تسجيل فيديو لمستخدمين حقيقيين ومشاهدتهم يتفاعلون مع موقعك. كل تفاعل خاص بمستخدم يتم ادراجه في نسخة على الجانب الأيمن من الصفحة ويتم أيضًا نقله للمخطط الزمني. الهدف الوحيد هنا كان أن تقدر على تخزين ومن ثم عرض جلسات المستخدم. لم يكن أي مصمم يعمل معنا وقمنا بإعطاء اهتمام قليل لتجربة المستخدم في ذلك الوقت. جعل الزبائن يستخدمون منتجاتنا الأساسية بعد أن أصبح لدينا شيءٌ يعمل فعليًا، كان قد حان الوقت للحصول على أول مختبرين لنسختنا التجريبية. وبما أن هدفنا كان إيجاد شركات ناشئة في مراحل متعددة لكسب فهم أفضل عن التناسب السوقي لمنتجنا، فكرنا في أفضل الأماكن التي يمكننا الذهاب إليها لإيجادهم، لذلك قمنا بحضور مقابلات ومحادثات موجهة نحو الشركات الناشئة واستطعنا أن نجد مختبري نسخة تجريبية متحمسين. قام أول المختبرين بتسليمنا قائمة بطلبات عن المزايا وأعطونا ردود فعلة ثمينة وملخّصة بالأسفل: الشركات الناشئة في المراحل المتقدمة: "على الرغم من أننا نتعلم شيئًا جديدًا من كل جلسة نشاهدها، لدينا أسئلة معينة نود تحريها باستخدام Jaco ولكن ينقص علينا الأدوات اللازمة لعمل ذلك." أخبرنا هذا بأننا احتجنا إلى إضافة المزيد من الفلاتر أو عوامل التصفية وإلى عمليات التكامل للسماح لزبائننا الذين يملكون حركة اتصالات كثيرة بأن يستخدموا Jaco. الشركات الناشئة في المراحل المبكرة: "مشاهدة تفاعل مستخدمينا مع منتجاتنا قام بإقصاء التخمينات من عملية صنع القرارات الصعبة." هذا أخبرنا بأن الشركات الناشئة في المراحل المبكرة يكتسبون الكثير من القيمة باستخدام Jaco. في ذلك الوقت، كنا شركة ناشئة في المراحل المبكرة، لذلك قررنا أن نجرب دراسة حالة على منتجنا الخاص واستخدام Jaco لمراجعة التسجيلات الخاصة بمختبري النسخ التجريبية. استخدام تسجيلات العملاء لتحسين Jaco لاحظنا نمطًا مرتبطًا بالطريقة التي يستخدم فيها عملاؤنا صفحة المشغّل. عندما يبدأ مستخدم جديد باستخدام منتجنا، فهو يقضي الوقت في مشاهدة مقاطع الفيديو المجمعة من البداية للنهاية. بعد فترة معينة، يبدأ المستخدم بمشاهدة المقاطع بسرعة مضاعفة 3 أضعاف، ولاحقًا، بينما يصبح على دراية أكبر بالمنتج، يبدأ باستخدام نسخة طبق الأصل لفحص محتوى الجلسة، يقوم أيضًا بالبحث عن مزايا في المخطط الزمني. بناءً على ما أظهر لنا Jaco، صنعنا ثلاثة تغييرات على ميزة النص: قمنا بتحريكها للجهة اليسرى حيث أصبحت مرئية أكثر بحثنا بالأصل عن السلوك في المخطط الزمني (وليس في النص)، لكن بما أننا لاحظنا أن العديد من المستخدمين يقومون بالضغط على فعالية ما في النص قبل أن يضغطوا على العلامة المترابطة في المخطط الزمني، قررنا أن نضيف هذا السلوك للنص أيضًا. أضفنا أيقونات وألوان مختلفة لكل نوع من أنواع الفعاليات في النص، بجانب سلوك التمرير التلقائي لجعل هذا العنصر ينبثق ويحث على تفاعل المستخدم. خلال يومين، 73% من مستخدمينا أصبحوا خبراء في صفحة المشغّل: بدأوا باستخدام النص لفحص الجلسة والبحث عن أجزاء معينة من التسجيلات، واستخدموا ميزة البحث لرؤية الأجزاء الأكثر صلة فقط من التسجيل. أنشأ هذا التغيير ردود فعل إيجابية من عملائنا، وبدأنا بالتفكير بطرق نستطيع من خلالها تطبيق ما تعلمناه في صفحة المشغّل على بقية Jaco. فكرنا بأخذ المخطط الزمني للجلسة من صفحة المشغّل ونسخها في صفحة الجلسة، وبالتالي مساعدة عملائنا على البحث بشكل أسرع في أكثر من جلسة واحدة على حدة. قمنا بتجسيد أفكارنا واختبارها بواسطة العديد من جلسات واحد لواحد مع عملائنا. بعد هذه العملية السريعة، صممنا النماذج بالأسفل: استثمرنا معظم تركيزنا في صنع إصدار أصغر من المخطط الزمني، وأضفنا المعلومات من النسخة طبق الأصل. عرض المخطط الزمني في صفحة الجلسات أعطى عملاءنا القدرة على فهم الإيقاع والمستوى الخاص بارتباط المستخدم في الجلسة بنظرة سريعة فقط. بعد ذلك، صنعنا نموذجًا تجريبيًا سريعًا. بعد اختبار فكرتنا الجديدة مع عملائنا، استنتجنا بأنه بينما كانت ردود الأفعال المتعلقة بفكرة هذا العنصر موجبة، بعض عملائنا شعروا بأن عملية التصفية الخاصة بنا كانت واهنة ومعقدة. أدركنا بأنه على الرغم من أن هذا الحل هو خطوة جيدة في الإتجاه الصحيح، كان لا يزال هنالك عمل يجب القيام به. أنشأنا نماذج جديدة مع اعتبار ردود الفعل، مما أدى للتصميم التالي: وبجانب عوامل التصفية الواهنة، أردنا حلًا يعطي الجدول مساحة أفقية أوسع والمزيد من الفراغ للمعلومات. قررنا أن نزيل العمود الأيسر وبناء واجهة جديدة كليًا للشرائح وميزة التصفية. بدت الواجهة الجديدة لعوامل التصفية أكثر بديهية، مرونة وأسهل في الاستخدام. استخدمنا عوامل تصفية JIRA كمرجع. أحببنا كيف يسمح JIRA باختيار كيفية إدخال استعلام أو قسم. بما أن سلسلة عملائنا الأساسية تتضمن مصممين ومالكي منتجات على طرف، وقراصنة على الطرف الآخر، فإن هذا حل مثالي لنا. وها هو التصميم النهائي: الملخص بمجرد إكمالنا دراسة الحالة الخاصة بنا، تعلمنا بأن Jaco يعود علينا بالفائدة بشكل أفضل عند إضافته لخط العمل الخاص بنا بالطرق التالية: بعد تحليل كل معلوماتنا من تحليلات جوجل Google Analytics لمعرفة حالتنا، نستخدم Jaco لتحديد كيف يجب علينا تحسين الأشياء. بعد كل نشر، نستخدم Jaco لرؤية الجلسات التي تم فيها استخدام ميزتنا الجديدة لكي نسبق المنحنى ونتنبأ بأداء الإعلان الجديد. هذا يمكننا من أن نتحقق من الفاعلية بدون الحاجة للانتظار لكمية كبيرة من حركة الاتصالات الخاصة بالتحاليل. مكنتنا هذه الطريقة من أن نكون معتمدين على البيانات خلال مرحلتنا المبكرة عندما لم تكن حركة الاتصالات الخاصة بنا كثيفة بشكل كافي ليتم تجميعها، وهذه الطريقة تساعدنا الآن بالتحرك بشكل أسرع وأن نكون معتمدين على البيانات بشكل أكبر حيث أننا نحصل على ردود فعل مباشرة من عملاء حقيقيين في غضون ساعة بعد أي طرح جديد. يقضي Jaco حاليًا آخر أسابيعه في مرحلة النسخة التجريبية المجانية، ونحن نعمل بحيوية لإضافة المزيد من التكاملات وعوامل التصفية المتقدمة. ننوي في المستقبل القريب بأن نضيف المزيد من الأدوات التي تسمح لمالكي المنتجات بأن يحصلوا على بيانات مجتمعة متعلقة باستخدام منتجهم من قبل كل من الجلسات وجوانب المستخدمين. ترجمة -بتصرف- للمقال ‎Creating a tool that records user interactions لصاحبه Ran Klein
  3. Lighthouse هو أداة مُؤَتمتة (Automated) مفتوحة المصدر لتحسين صفحات الويب. يمكن تطبيق الأداة على أي صفحة ويب سواء كانت عامّة أو تحتاج للاستيثاق (Authentication). يمكن استخدام الأداة للتدقيق في الأداء، قابليّة الوصول (Accessibility)، صفحات الويب التقدميّة (Progressive web apps) وغيرها. تستطيع تشغيل Lighthouse من أدوات المُطوّر في Chrome أو سطر الأوامر أو بصيغة وحدة Node. تستقبل الأداة Lighthouse رابط URL لتدقيقه فتُشغِّل سلسلة من التدقيقات على الصفحة ثم تولّد تقريرًا عن حالة الصفحة. اعتمد على التقرير واستخدم التدقيقات التي أخفقت فيها الصفحة دليلا لكيفية تحسينها. يوجد في كلّ تدقيق توثيق مرجعي يشرح أهميّة التدقيق وكيف تصلح الصفحة لتتوافق معه. البداية اختر سير عمل Lighthouse الذي يناسبك: أدوات التطوير في Chrome. دقّق الصفحات التي تحتاج الاستيثاق بسهولة واقرأ التقارير بصيغة مفهومة للمستخدم. عبر سطر الأوامر. أتمت تشغيلات Lighthouse بسكربتات Shell. وحدة Node. ادمج Lighthouse في نظام التكامل المستمر (Continuous integration) الخاصّ بك. ملحوظة: تتطلّب كل واحدة من طرق العمل في Lighthouse وجود Google Chrome مثبَّت على جهازك. شغّل Lighthouse من أدوات تطوير Chrome يشغّل Lighthouse لوحة Audits في أدوات تطوير Chrome. اتبع الخطوات التالية لتشغيل تقرير: نزّل Google Chrome للأجهزة المكتبية. استخدم Google Chrome لتصفّح الصفحة التي تودّ تدقيقها. يمكنك تدقيق أي صفحة على الوِب. افتح أدوات التطوير DevTools في Chrome. انقر على اللسان Audits. يظهر في يسار الشاشة الإطار المعروض من الصفحة التي ستُدقَّق. تظهر في اليمين لوحة التدقيقات (Audits) التي يشغّلها Lighthouse. انقر على Perform an audit. تظهر أدوات التطوير قائمة بتصنيفات التدقيق. اتركها جميعا مُعلَّمة. انقر على Run audit. يعطيك Lighthouse بعد 60 إلى 90 ثانية تقريرًا عن الصفحة. تثبيت سطر أوامر Node وتشغيله اتبع الخطوات التالية لتثبيت وحدة Node: 1- نزّل Google Chrome للأجهزة المكتبية. 2- ثبّت الإصدار طويل الدعم الحالي من Node. 3- ثبّت Lighthouse. يشير الخيار ‎-g إلى تثبيت الوحدة على مستوى النظام. npm install -g lighthouse 4- نفّذ الأمر التالي لتنفيذ تدقيق: lighthouse <url> 5- لعرض خيارات التدقيق: lighthouse --help تشغيل وحدة Node برمجيا راجع استخدام هذا الرابط لمثال على تشغيل Lighthouse برمجيًّا على صورة وحدة Node. تشغيل Lighthouse عن طريقة إضافة Extension على Chrome ملحوظة: يُفتَرض استخدام خطة سير عملا مبنية على أدوات المطوِّر في Chrome بدلا من هذه الإضافة، إلا إذا كان لديك سبب خاصّ. تُوفّر أدوات المطوّر في Chrome نفس الفوائد التي توفّرها الإضافة، علاوةً على كون الأدوات لا تحتاج لتثبيت. اتبع الخطوات التالية لتثبيت الإضافة: نزّل Google Chrome للأجهزة المكتبية. ثبّت إضافة Lighthouse من مخزن إضافات Chrome. اتبع الخطوات التالية لتشغيل تدقيق: استخدم Google Chrome لتصفّح الصفحة التي تودّ تدقيقها. انقر أيقونة Lighthouse. يُفتَرَض أن توجد الأيقونة بعد شريط العنوان في Chrome. إن لم تكن هناك، افتح القائمة الرئيسية في Chrome وانقر على الأيقونة في أعلى القائمة. تتمدّد قائمة Lighthouse بعد النقر على الأيقونة. انقر على الزرّ Generate report. يدقّق Lighthouse الصفحة النشطة ثم يفتح لسانًا جديدًا يحوي تقريرًا عن نتائج تدقيق الصفحة. شارك التقارير واعرضها على الشبكة استخدم Lighthouse Viewer (عارض Lighthouse) لعرض التقارير ومشاركتها على الشبكة. شارك التقارير بصيغة JSON يحتاج Lighthouse Viewer إلى مُخرج بصيغة JSON من تقرير Lighthouse. تشرح الخطوات أدناه كيفية الحصول على مُخرج بصيغة JSON، حسب طريقة العمل التي اخترتها. بالنسبة لأدوات التطوير: انقر على تنزيل التقرير (السهم المتّجه إلى الأسفل). سطر الأوامر: lighthouse --output json --output-path <path/for/output.json> إضافة Chrome: انقر على زرّ التصدير Export ثم Save as JSON. لمعاينة بيانات التقرير: افتح Lighthouse Viewer في متصفّح Chrome. اسحب ملف JSON إلى العارض ثم أفلته، أو انقر في أي مكان في العارض لفتح متصفّح الملفّات لديك واختيار الملفّ. مشاركة التقارير عبر GitHub Gists إن لم تكن ترغب في تمرير تقاريرك يدويّا بصيغة ملفات JSON فيمكنك مشاركتها بسريّة عبر خدمة GitHub Gists. أحد فوائد الخدمة هو الحصول على تحكّم مجاني في الإصدارات Version control. اتبع الخطوات التالية لتصدير التقارير إلى GitHub Gists عبر إضافة Lighthouse على Chrome: انقر على Export ثم Open In Viewer. يُفتَح التقرير في العارض المتوفّر على الرابط https://googlechrome.github.io/lighthouse/viewer/. انقر على المشاركة Share في العارض. ستطلُب منك نافذة منبثقة في المرة الأولى السماح بالوصول إلى بياناتك الأساسية على GitHub، وصلاحية القراءة والكتابة على GitHub Gists. أنشئ Gist يدويًّا ثم انسخ التقرير بصيغة JSON وألصقه، إن أردت تصدير التقرير إلى GitHub Gists من سطر الأوامر. يجب أن ينتهي اسم Gist الذي يحوي مُخرَج JSON باللاحقة lighthouse.report.json. راجع هذا الرابط لمثال على كيفية توليد مُخرَج JSON من سطر الأوامر. اختر إحدى الطريقتيْن التاليّتين لعرض تقرير محفوظ على GitHub Gists: . أضف ‎?gist=<ID>‎ إلى رابط العارض، حيثُ ID هو معرّف Gist: https://googlechrome.github.io/lighthouse/viewer/?gist=<ID>‎ افتح العارض وألصق فيه رابط Gist المساهمة في Lighthouse Lighthouse مفتوح المصدر، ويرحّب مطوّروه بالمساهمة فيه. تحقّق من متتبّع المشاكل Issues tracker في المستودع للعثور على علل (Bugs) يمكنك إصلاحها، أو تدقيقات يمكنك إنشاؤها أو تحسينها. يعدّ متتبّع المشاكل مكانا جيّدا للنقاش حول قياسات التدقيق أو أفكار لتدقيقات جديدة أو أي أمر آخر له علاقة بأداة Lighthouse. ترجمة - بتصرّف - للمقال Lighthouse من موقع مطوّري Chrome.
  4. سيفاجئك العملاء بطرق استخدام منتجك مبتكرة. وهذا لا يأتي من دراسة وتفكّر من جانبهم وإنّما نتيجة لجعلهم منتجك يتكيّف مع احتياجاتهم. يقول Peter Drucker قولته المشهورة: "نادرًا ما يشتري العميل ما تظنّ الشركة أنّها تبيعه"؛ وهذه إشارة إلى أنّه لكي تطوّر منتجًا ما يجب عليك أوّلًا أن تدرس وتفهم الغرض الذي سيُستخدم من أجله. لنوضّح الأمر بمثال: بعد أن أطلقنا Intercom بفترة قصيرة قمنا بإضافة ميزة الخارطة لنتمكّن من معرفة أماكن عملائنا حول العالم. كانت هذه الميزة من النوع الكلاسيكي وكانت رائعة جدًّا لكنّنا لا نعرف لماذا. ولقد استطعنا رؤية كم أصبحت هذه الخارطة شعبيّة من خلال عدد الأشخاص الذين يستخدمونها. لكن التسويق للخارطة كميزة كان صعبًا، لأنّه كان من الصعب معرفة سبب استخدامها. هل هو معرفة المكان الذي يأتي منه أغلب العملاء؟ كلّا، العديد من المُنتجات تفعل ذلك.هل هو رؤية العملاء من مدينة معيّنة؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير.هل هو معرفة عدد مستخدمي المنتج في بلد معيّن؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير أيضًا.إذًا ما هو الغرض من الخارطة بغضّ النظر عن كونها مثيرة للإعجاب؟ لقّد فكّرنا بثلاث طرق استُخدمت فيها هذه الخاصيّة: هنالك أشخاص يفضّلون استعراضها في المعارض التجارية والمؤتمرات (انظر إلى الحاسوب الشخصي): وأشخاص يفضّلون استعراضها على تويتر: وآخرون يفضّلون استعراضها أمام المستثمرين: إذًا ما تفعله الخارطة هو أنّها تبدو رائعة وتثير إعجاب العملاء؛ هذا كل ما تفعله. التحسين على أساس الاستخداملو أردنا تحسين الخارطة قبل معرفة الغرض الذي تُستخدم من أجله لحاولنا إنشاء خارطة أفضل. فيما يلي بعض الأمور التي قد نركّز عليها: الدّقة الجغرافية.المجموعات الجغرافيّة.حدود أفضل للدولة أو المدينة.خاصية السحب لإنشاء مناطق regions.تحسينات خرائطيّة أخرى متنوّعة.قد تستغرق منّا هذه التحسينات عدّة أسابيع أو أشهر، وفي النهاية تؤدّي إلى منتج أسوء؛ لأنّ العميل لم يكن يشتري ما كنّا نظن أنّنا نبيعه. فالخارطة أصبحت عبارة عن قطعة للعرض وليست خارطة. ما الذي يجعل الخارطة تقوم بتلك المهمّة بشكل أفضل؟ أولًا وقبل كل شيء، خارطة مصمّمة لتبدو جيّدة.خارطة تقوم بإخفاء البيانات الحسّاسة بشكل تلقائي مما يجعلها قابلة للمشاركة.خارطة من السهل على العملاء مشاركتها.وهذا بالضبط ما قمنا بعمله. لقد قمنا بعرض على عملائنا فرصة مشاركة خارطة متحرّكة وجميلة، وزوّدناهم بعنوان URL فريد من نوعه وقابل للمشاركة: خارطة أسوء تقوم بعمل أفضلعندما تقوم بالتركيز على الكيفيّة التي تُستخدم فيها الميزة، متجاهلًا فئة أو نوع الميزة، ستتعلم كيف تقوم بتحسينها بسرعة، وهذه التحسينات سيتردد صداها على الفور. بإمكانك مشاهدة المزيد من ردود أفعال العملاء تجاه الخارطة القابلة للمشاركة هنا. حقوق التّصميم عائدة لـHongyuan وحقوق تطوير الميزة عائدة لـEoin وPatrick. ترجمة -وبتصرّف-للمقال This is not a map لصاحبه: Des Traynor. حقوق الصورة البارزة: Designed by Freepik.
  5. نعتقد جميعنا أننا نفهم هندسة المعلومات، ومع ذلك فإن هذا المجال مجال خاص نوعا ما والأشياء التي نظنّ أننا نعلمها قد لا تكون صحيحة. لم نعد نسمع عن مصطلح هندسة المعلومات كثيرًا في هذه الأوقات، هناك الكثير من الحديث عن فهم احتياجات المستخدمين وتقديم المحتوى المناسب لهم، ولكن القليل منه حول كيف يجد المستخدم هذا المحتوى. يعود هذا الأمر إلى أنّ هذا الموضوع مغطّى بشكل كامل، يوجد بعض الكتب الرائعة حول الموضوع، وعليه لا يشعر المدونون أنّ هناك المزيد لإضافته. المشكلة هي أنه عندما تتم تغطية الموضوع بشكل جيد، فإنه ينتقل إلى عالم المعرفة العامّة. إن مشكلة المعرفة العامّة أنّه يعلوها الغبار مع مرور الوقت، تظهر معلومات خاطئة وتكبر بعض الخرافات.هذا الأمر يتكرّر دائمًا، مثلما هو عليه الحال مع فكرة أن المُحتوى يجب أن يكون فوق خط الطّي الوهمي above the fold بحجة أن المُستخدمين لا ينزلون أسفل الصّفحة users don’t scroll. للأسف أصبحت هندسة المعلومات مشبعة بمثل هذه الخرافات، ولهذا أود أن آخذ القليل من الوقت لتبديد بعضٍ منها. أريد أن أبدأ مع الاعتقاد السّائد بأنه يُفترض ببنية المواقع أن تكون منطقيّة. يجب أن تكون بنية موقعك منطقيّةعندما أعمل على بنية موقع مُعيّن فعادة ما أدفع العميل وحتى زملائي إلى حافّة الجنون، حيث أنني لا أجعل بنية موقعي منطقية دائمًا. يوهم الناس أنفسهم بأن هندسة المعلومات تدور حول تنظيم المحتوى بطريقة منطقيّة. ولكنّ الأمر ليس كذلك. المشكلة هي أنّ الناس ليسوا منطقيين، نحن ندعيّ ذلك ولكننا نقوم باتخاذ القرارات بناءً على النزعات الثقافيّة، التنشئة، الأفكار المبلورة سابقًا وغيرها من العوامل. خذ على سبيل المثال سوق الخضر. عندما تقوم بزيارته أين تبحث عن الطماطم؟ تبحث عليها في قسم الخضروات أليس كذلك؟ ولكن لماذا لا تضع الأسواق الطماطم في قسم الفاكهة، فهي فاكهة ولا يُمكن تصنيفها مع الخضروات، حيث أن هذا هو التصّرف المنطقي إلا أنهم لا يقومون بذلك لأن الناس تتوقع رؤية الطماطم مع الخضروات وذلك بسبب أفكارهم المبلورة سابقًا. يجب علينا أن نتخلى عن فكرة أن تكون بنية مواقعنا منطقية بالنسبة لعقولنا، وعوضًا عن ذلك يجب أن تتناسب مع النموذج العقليّ لمستخدمينا سواء كان هذا الأمر منطقيًّا أم لا. يجب على المستخدم أن يكون قادرا إلى الوصول إلى المحتوى بثلاث نقراتفيما يخص المنطق دائمًا، هناك خرافة أخرى قد تبدو منطقيّة وتنصّ على أنه يجب على المستخدم أن يصل إلى المحتوى بـ 3 نقرات كأقصى حدّ، قد يبدو هذا الأمر منطقيّا إلا أنه لسوء الحظ ليس كذلك. بدأت هذه الخرافة من الأيام الأولى للويب عندما كان المستخدمون يستخدمون صلات dial-up. جعلت السرعات البطيئة المستخدمين يشعرون بالإحباط أثناء التصفّح بين العديد من الصفحات، وفسّر هذا الأمر بشكل مغلوط على أنّه مرتبط بعدد النقرات. في الواقع لا يوجد هناك أي دليل لدعم هذه الفرضية بل أن هناك من يقترح بأن عدد النقرات لا يهم. ما يهم عوضًا عن ذلك هو الشعور بالتقدّم إلى الهدف المطلوب. فإن شعر المستخدمون بأنهم يتقدمون، سيكونون سعيدين بالتقدّم بشكلٍ جيد بعيدًا عن النقرات الثلاث السحريّة. يجب أن يكون لديك فقط 7 خيارات (زائد أو ناقص 2)إحدى خرافات الأرقام السحرية الأخرى هي فكرة أنه لا يجب أن يكون لديك أكثر من 7 خيارات (زائد أو ناقص 2) أثناء التصفّح. يعود أصل هذا الاعتقاد إلى بحث في علم نفس أعدّه جورج ميلر. يُعلّل جورج ميلر ذلك بأن الأشخاص لا يستطيعون استيعاب أكثر من 7 خيارات (زائد أو ناقص 2) في ذاكرتهم قصيرة الأمد. إلا أنّ هذا الفرضية خاطئة لسببين: أولًا، هناك بحثُ آخر يقول أننا نجد صعوبات لكي نبقي أكثر من 4 أشياء في ذاكرتنا قصيرة الأمد، ولهذا فإن بطاقات الدّفع الإلكتروني تقوم بجمع الأرقام في مجموعات من أربعة أرقام. ثانيًا، إن صفحة الويب لا تطلب من المستخدم أن يقوم بحفظ الخيارات في الذاكرة قصيرة الأمد وذلك لأن المعلومات تظهر أمامه بشكل بصريّ.تكمن المشكلة في أن الأشخاص يحبون مثل هذه القواعد. قواعد يمكنك متابعتها والتي تجنبك القيام بأمور قد لا ترغب فيها مثل اختبار قابلية الاستخدام. ولكن في الحقيقة هذه هي الطريقة الوحيدة للتأكد مما يصلح من غيره. وبحكم أننا نتحدّث عن الأشياء التي يرغب النّاس في تجنّبها، لنُعرّج على ترتيب الأولويات. من المستحيل تجنب تحديد الأولوياتيُدهشني عدد المنظمات التي تكره تحديد الأولويات. سواء تعلّق الأمر بتحديد الأولويات للأهداف التجارية أو الجمهور. وذلك لأن تحديد الأولويات هو أمر مثير للخلاف. وهذا يعني القول إن قسما ما أكثر أهمية من قسم آخر أو مجموعة واحدة من المستخدمين لديها قيمة أكثر من غيرها. يمكن أن يكون هذا الأمر مشكلة في بعض المنظمات والتي يتراجع أداؤها بسبب غياب تحديد الأوليات. والنتيجة هي موقع على شبكة الإنترنت يحاول إرضاء الجميع وينتهي به المطاف بعدم إرضاء أيّ أحد. فتجدهم يُرتّبون عناصر التّصفّح أبجديا لتجنّب الإساءة لطرف أو لآخر، كما أن عناصر الصّفحة الرّئيسية تظهر بنفس الشّكل لتجنب مشكلة تفضيل عنصر على حساب آخر. ما لا تدركه هذه المنظمات أن تجنب تحديد الأولويات هو أمر مستحيل. فحتى ولو تم ترتيب العناصر أبجديّا، فإن العناصر التي تظهر في أعلى القائمة ستكون مُفضّلة على غيرها. بإمكانك عرض جميع عناصر الصّفحة بنفس الشّكل، لكن سيبدأ المستخدمون بتصفّح الموقع من الزاوية العلوية اليسرى. حاول أن تقوم بذلك، لكنه لا يُمكنك تجنب تحديد الأوليات وبالتالي فمن باب أولى أن تُعطي الأولية لما هو أكثر أهمّيّة. لا يهم إن لم يفهم المستخدم مصطلحا ما، ما لم يكن موجها إليهإحدى الجامعات التي كان لي شرف العمل مثال واضح عن هذا المُشكل، كان لدينا بعض التحفظات حول إذا ما كان مصطلح Alumni مناسبا لوضعه في قائمة التّصفّح الرّئيسية حيث توقّعنا أن بعض الزّوار لن يتمكّنوا من فهمه. في بداية الأمر عارضت الجامعة فكرة تغيير المصطلح، بحجة أن الناس الذين لا يقدرون على فهم مصطلح Alumni هم غير مناسبون لمؤسستهم، لكنهم قاموا بتغيير رأيهم عندما أشرنا لهم أن الطّلبة الذين لا تكون الإنجليزية لغتهم الأم لن يفهموا المُصطلح، حيث أن نسبة ليست صغيرة من مداخيل الجامعة مصدرها الطّلبة الأجانب. ثم ما لبثوا أن وقعوا في فخ المُغالطة التي يقع فيها الكثيرون: "سيتجاهل الزوّار المُصطلح إذا لم يفهموه وسيعتقدون بأنّه غير مُوجّه لهم". ولسوء الحظ هذا ليس صحيحا، فإن واجهت الزّائر مجموعة من الخيارات ولم تكن أيها هي الخطوة القادمة (الصفحة القادمة) التي يجب أن يذهب إليها فإنه من المُحتمل جدًا أن يذهب إلى قسم ما حتّى وإن لم يفهم ما يعنيه له ظانا بأنه سيحتوي على الإجابة التي يبحث عنها. والمزيد من الخرافاتخلاصة القول: القليل من المعرفة خطير ومُضرّ والأمر صحيح حتّى في مجال هندسة المعلومات ونفس الأمر مع تجربة المُستخدم. يجب أن نحذر أي النّظريات والقواعد يجب أن نُصدّق ونتّبع، حيث أنه يجب علينا أن نبحث ونحقّق من الأمر بأنفسنا ونُبث صحّته أو خطأه عبر التّجربة. ترجمة -وبتصرّف- للمقال What you know about information architecture, might not be true لصاحبه Paul Boag. حقوق الصورة البارزة: Infographic vector designed by Freepik.
  6. إن الهدف من إعداد وتجهيز المخططات الهيكلية (Wireframes) لمواقع الإنترنت هو حلّ مشاكل التصميم المُرتبطة بتخطيط وتصميم الصّفحة، وترتيب عناصرها، وذلك عبر ابتداع تصوّر للموقع قبل تطويره، وذلك باستخدام جملة من المُمارسات والمبادئ. إن تطبيق مبادئ جشطلت (Gestalt) على العناصر، سيُساعد على تحضير الأفكار بسرعة، فالفكرة من الأساس من العمل على هذا المُستوى من الجودة هو السرعة الّتي تُمكن المُصمّم من اكتشاف الأفكار بدرجة معقولة من الدقّة. تعلّمتُ بعض الطُرق المُفيدة في السنوات الأخيرة، جعلت مني أعمل بإنتاجيّة أكبر مع الحفاظ على الجودة، وبطبعي أكره كتابة عناوين من نوع" أفضل الحيل مع تصاميم المخططات الهيكلية" ولكن بعد عملي مع مُصممين قليلي الخبرة، وجدت أنّ بعض هذه المواضيع تحدث بشكل متكرّر ومن الضروري الإشارة إليها. 1. كل شيء مهم وذو معنى كل تلوين، كل خطّ، كل ظل، كل تدرّج لوني، كل شيء يَهم وله معنى، فاستخدام حواف وإطارات غير متقطّعة (solid)، وخلفيّة ملوّنة، وظلالًا، قد يكون أمرًا لا لزوم لها، خاصّة أنّ هذه العناصر يُمكن أنّ تنتقل إلى مرحلة التصميم والتطوير، وبدون أنّ يُفكّر بها مليًّا، فيجب على كل شيء أنّ يكون له معنى، وأنّ لا تُدرج العناصر والرسومات هنا وهناك اعتباطيًّا. الانسجام يُساعد يجدر الانتباه عند استخدام الرسم التمهيدي (sketching) هو أنّ التلوين والخطّ موحد في كامل الرسم (يعني، وجوب تبديل القلم المُستخدم، أو تغيير خطّ اليد من أجل إبراز الاختلاف)، بالإضافة إلى تتكرّر مُشكلة مع المخططات الهيكلية وهي الاختلاف في تدرجات الألوان وعمق السطور والخطّ المُستخدم، جميعها يُدرج ويُستخدم بدون تفكير، الأمر الّذي يجعل من المخطط الهيكلي صعب الفهم والقراءة، ويجعل مني أتساءل في معظم الأحيان: هل التغيير من الخط المُستخدم هنا متعمّد؟ هل هذه الرقعة (label) هي أكبر حجمًا لأنّها أكثر أهميّة؟ وغيره من هذه الأسئلة، ولتجنب هذه المشكلة، من المُستحسن استخدام مجموعة محدّدة من الألوان، (ربّما من 3-5 من اللون الرمادي) ونوعين من الخطوط، واستخدام عناصر HTML الافتراضيّة، مع العلم أنّ هذا قد يؤدي إلى مخططات هيكلية باهتة، ولكن يجب أنّ يُعلم أنّ جميع المخططات الهيكلية ينتهي الأمر بها إلى سهلة المهملات، فليس الغرض منها إبهار الزوّار، إنما الغرض هو تصميم برمجيّة قابلة للاستخدام، أمّا المخطط الهيكلي الخلّاب فهو مضيعة للوقت. إن من الأمور المُهمّة الّتي يجب التركيز عليها هي نقطة الانطلاق، فالبدء مع خطّ أسود، يعني إمكانيّة تكبير وتعريض الخط فقط، الأمر الّذي قد يؤدي إلى جعل المخطط الهيكلي صارخ وحاد بالنسبة لبقيّة الأجزاء، ولكن البدء مع خطّ رمادي، يسمح للمُصمّم بزيادة العمق اللوني وتخفيفه بطبيعة الحال. السرعة والاستكشاف إن الغرض من التصميم ذو الدقّة المُنخفضة ليس التلوين والتحسين، ولكن الغرض هو استكشاف الحلّ الأنسب، حيثُ سيظهر العديد من الحلول، وفقط عن طريق استكشاف بعضها، وصفهم أمام الأعين سيمكّن المُصمّم من التقرير أيها سيَعمل بالشكل الأمثل للمشروع، لقد شرح كانيد بولز كيف يواجه لاعبي الشطرنج تحديًّا مُشابهًا، حيثُ في بداية اللعب، يوجد الكثير من الخيارات، بعضها يُمكن استبعاده عن طريق الغريزة أو عبر الخبرة والممارسة، وتُستكشف باقي الحلول ذهنيًّا، ولذلك سيُعجب المُصمّمون المبتدؤون بفكرتهم الأولى، ويتعلّقون بها ويبذلون جهدًا كبيرًا في تنفيذها مهما تتطلّب الأمر، ولقد وصفَ آندي روتلدج هذه الظاهرة بظاهرة "ملك الخواتم" وذلك في مقالة أكثر من رائعة بعنوان "كنزي العزيز". إن لم يكن بالإمكان تنفيذ التصوّر بسرعة، إذًا فإن التنفيذ يتمّ على الدقّة الخاطئة، فإن كان المخطط الهيكلي يعمل على تقديم نسخة ذات التدرّج الرمادي (grayscale) فقط مما قد تقرّر بناؤه بالفعل، فذلك مضيعة للوقت. النسخة المُطابقة تعطي نتائج أكثر واقعيّة تصدر الأخطاء عادةً من المُصممين الذين ليس لديهم تصوّر مُسبق للمحتوى، فإن كان المشروع يتضمّن معرضًا للصور، فمن المفترض رؤية الصور قبل اتخاذ القرار في إدراجها، والاهتمام بها كميّزة رئيسيّة أو عدم إبرازها لعدم أهميتها، وبشكل مُشابه، إن كان التصميم مبني بالأساس لعرض البيانات، فيجب معرفة ماهيّة هذه البيانات، مع العلم أنّ استخدام البيانات الوهميّة في التصميم الأوّلي تَدفع بالمُصمّم إلى تصاميم مخططات هيكلية تكون فيها العناوين والنصوص مُتناسقة بمثاليّة كبيرة، والصور مُتجاوبة مع التصميم ككل، والأرقام مُلائمة داخل صناديق صغيرة لا تتخطاها، طبعًا هذا أبعد ما يكون عن الواقع، بعبارة أخرى، إن هلاك واجهة المُستخدم يبدأ بالعنوان "لوريم أيبسزم". يجب إتقان التقنيّة المُستخدمة يُمكن للتصميم الخلّاب أنّ يُقدّم حلًّا سيّئًا للمشروع، فإن كان التصميم يتضمّن عناصر HTML مخصّصة، وأزرارًا جذّابة وقوائم مُنسدلة، وحقل بحث ديناميكي بتقنيّة أجاكس، فمن الضروري على المُصمّم أنّ يدرك أنّ لكل مشروع ميزانيّة مُختلفة عن الآخر، وخاصّة إن كان المُصمّم يعرف أساسيّات HTML و CSS و جافا سكريبت، فهو بالتأكيد يعرف ما يُتطلّب لاختبار هذه العناصر على المُتصفحات، وبالتالي على المُصمم أنّ يفكّر مليًّا فيما يُدرج في المخطط الهيكلي، طبعًا قد لا يكون هذا العنصر بذلك التعقيد، وقد يكون متوفّرًا في مكتبة jQuery، ولكن على المصمم أنّ يدرك أنّه لا يوجد شيء يدعى "مجرّد تعديل بسيط"، طبعًا هذا لا يعني عدم إدراج عناصر تفاعليّة في المخطط الهيكلي، ولكن يجب على المُصمم دائمًا معرفة تكلفة كل عنصر يُدرج في التصميم، فبعض المواقع قد تتطلّب هذا النوع من التعقيد، فمثلًا الاهتمام في عنصر اختيار التاريخ قد يكون أمرًا جوهريًا ومطلب أساسي في بعض المواقع، ومن المنطقي جدًا التركيز عليه، ولكن عندما يكون عنصر اختيار التاريخ من أجل "تاريخ الميلاد"، فمن الأفضل استغلال هذا الوقت على أمرٍ أكثر أهميّة فليعمل ما يعمل إن الهدف الرئيسي هو تقديم شيء عمليّ، وليس شيء مثالي، فلا يُبهر بالجماليّات سوء مُصمّمي تجربة المُستخدم UI، بمعنى إن تمّ الرسم والتخطيط باستخدام الورق فقط وبخط اليد، وكان المُصمّم واثقًا من تقديم الحلّ المطلوب، وذلك بتوافق تصميمه مع البيانات المعُطاة من قبل العميل، وكان هذا الرسم رسمًا واضحًا لجميع فريق العمل، فإذًا لا قيمة من إعادة تمثيل هذا الرسم باستخدام المخطط الهيكلي، بمعنى آخر على المُصمّم أنّ يكون عمليًّا، وأن يهتم بتقديم المطلوب وأن يَبتعد عن تصميم تصميمات مثاليّة . مصادر إضافيّةإن جميع المواضيع السابقة هي من واقع الخبرة ونتاج طويل من والتجربة والخطأ، ولتكتمل الصورة، هذه بعض المقالات الهامّة، والّتي ترتبط بالموضوع بشكل مُباشر وغير مُباشر: هيكلة وتوزيع محتوى صفحات الويب.ما هو النّظام اللّوني.أساسيات الوزن البصري في التّصميم الجرافيكي.الاختلافات ما بين التصاميم المسطّحة (flat design) و التصاميم المادية (material design).مدخل إلى عالم الخُطوط.مصادر أجنبية: Gestalt Principles – Andy Rutledge.Good design faster – Leah Buley.Sketching User Experiences – Bill Buxton.ترجمة وبتصرّف للمقال Wireframing for Web Apps.