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



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

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

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

نوع المُحتوى


التصنيفات

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

التصنيفات

  • 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
  • سير العمل
    • 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

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

  1. 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.
  2. سيفاجئك العملاء بطرق استخدام منتجك مبتكرة. وهذا لا يأتي من دراسة وتفكّر من جانبهم وإنّما نتيجة لجعلهم منتجك يتكيّف مع احتياجاتهم. يقول Peter Drucker قولته المشهورة: "نادرًا ما يشتري العميل ما تظنّ الشركة أنّها تبيعه"؛ وهذه إشارة إلى أنّه لكي تطوّر منتجًا ما يجب عليك أوّلًا أن تدرس وتفهم الغرض الذي سيُستخدم من أجله. لنوضّح الأمر بمثال: بعد أن أطلقنا Intercom بفترة قصيرة قمنا بإضافة ميزة الخارطة لنتمكّن من معرفة أماكن عملائنا حول العالم. كانت هذه الميزة من النوع الكلاسيكي وكانت رائعة جدًّا لكنّنا لا نعرف لماذا. ولقد استطعنا رؤية كم أصبحت هذه الخارطة شعبيّة من خلال عدد الأشخاص الذين يستخدمونها. لكن التسويق للخارطة كميزة كان صعبًا، لأنّه كان من الصعب معرفة سبب استخدامها. هل هو معرفة المكان الذي يأتي منه أغلب العملاء؟ كلّا، العديد من المُنتجات تفعل ذلك.هل هو رؤية العملاء من مدينة معيّنة؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير.هل هو معرفة عدد مستخدمي المنتج في بلد معيّن؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير أيضًا.إذًا ما هو الغرض من الخارطة بغضّ النظر عن كونها مثيرة للإعجاب؟ لقّد فكّرنا بثلاث طرق استُخدمت فيها هذه الخاصيّة: هنالك أشخاص يفضّلون استعراضها في المعارض التجارية والمؤتمرات (انظر إلى الحاسوب الشخصي): وأشخاص يفضّلون استعراضها على تويتر: وآخرون يفضّلون استعراضها أمام المستثمرين: إذًا ما تفعله الخارطة هو أنّها تبدو رائعة وتثير إعجاب العملاء؛ هذا كل ما تفعله. التحسين على أساس الاستخداملو أردنا تحسين الخارطة قبل معرفة الغرض الذي تُستخدم من أجله لحاولنا إنشاء خارطة أفضل. فيما يلي بعض الأمور التي قد نركّز عليها: الدّقة الجغرافية.المجموعات الجغرافيّة.حدود أفضل للدولة أو المدينة.خاصية السحب لإنشاء مناطق regions.تحسينات خرائطيّة أخرى متنوّعة.قد تستغرق منّا هذه التحسينات عدّة أسابيع أو أشهر، وفي النهاية تؤدّي إلى منتج أسوء؛ لأنّ العميل لم يكن يشتري ما كنّا نظن أنّنا نبيعه. فالخارطة أصبحت عبارة عن قطعة للعرض وليست خارطة. ما الذي يجعل الخارطة تقوم بتلك المهمّة بشكل أفضل؟ أولًا وقبل كل شيء، خارطة مصمّمة لتبدو جيّدة.خارطة تقوم بإخفاء البيانات الحسّاسة بشكل تلقائي مما يجعلها قابلة للمشاركة.خارطة من السهل على العملاء مشاركتها.وهذا بالضبط ما قمنا بعمله. لقد قمنا بعرض على عملائنا فرصة مشاركة خارطة متحرّكة وجميلة، وزوّدناهم بعنوان URL فريد من نوعه وقابل للمشاركة: خارطة أسوء تقوم بعمل أفضلعندما تقوم بالتركيز على الكيفيّة التي تُستخدم فيها الميزة، متجاهلًا فئة أو نوع الميزة، ستتعلم كيف تقوم بتحسينها بسرعة، وهذه التحسينات سيتردد صداها على الفور. بإمكانك مشاهدة المزيد من ردود أفعال العملاء تجاه الخارطة القابلة للمشاركة هنا. حقوق التّصميم عائدة لـHongyuan وحقوق تطوير الميزة عائدة لـEoin وPatrick. ترجمة -وبتصرّف-للمقال This is not a map لصاحبه: Des Traynor. حقوق الصورة البارزة: Designed by Freepik.
  3. نعتقد جميعنا أننا نفهم هندسة المعلومات، ومع ذلك فإن هذا المجال مجال خاص نوعا ما والأشياء التي نظنّ أننا نعلمها قد لا تكون صحيحة. لم نعد نسمع عن مصطلح هندسة المعلومات كثيرًا في هذه الأوقات، هناك الكثير من الحديث عن فهم احتياجات المستخدمين وتقديم المحتوى المناسب لهم، ولكن القليل منه حول كيف يجد المستخدم هذا المحتوى. يعود هذا الأمر إلى أنّ هذا الموضوع مغطّى بشكل كامل، يوجد بعض الكتب الرائعة حول الموضوع، وعليه لا يشعر المدونون أنّ هناك المزيد لإضافته. المشكلة هي أنه عندما تتم تغطية الموضوع بشكل جيد، فإنه ينتقل إلى عالم المعرفة العامّة. إن مشكلة المعرفة العامّة أنّه يعلوها الغبار مع مرور الوقت، تظهر معلومات خاطئة وتكبر بعض الخرافات.هذا الأمر يتكرّر دائمًا، مثلما هو عليه الحال مع فكرة أن المُحتوى يجب أن يكون فوق خط الطّي الوهمي 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.
  4. إن الهدف من إعداد وتجهيز المخططات الهيكلية (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.