لوحة المتصدرين

هل سمعت عن نظام إدارة الإصدارات Git وترغب بتعلم المزيد عنه؟ هل أنت مطور ترغب في استخدام GitHub وتجد التعامل معه صعبًا؟ هذا الفيديو أُعدّ خصيصًا لك. سنشرح مفاهيم Git وأساسياته، وسنطبق ذلك عمليًا. يمكنك أن تطلع على سلسلة المقالات التي وفرناها في أكاديمية حسوب عن Git.

ثورة الأجهزة المحمولة ليست فقط اختراعًا تكنولوجيًا يمكننا من الابتعاد عنه بأي وقت، فلا يمكننا الابتعاد عن الهواء الذي نتنفسه أو عن الأقدام التي تحملنا. وعلى نفس الصعيد، فلا نستطيع الابتعاد عن أجهزتنا المحمولة وما عليها. لأنها تعد امتدادًا لشخصياتنا. وبالنسبة للشركات، هذا يعني التركيز على إسعاد الزبون بتجربة رائعة على الهاتف حيث يوجد السياق والخصوصية. كن لحوحًا: إما إسعادهم أو لاشيء آخر يستطيع معظمنا ببساطة البقاء بعيدًا عن التكنولوجيا. فعندما نريد عزل أنفسنا، نبتعد ببساطة عنها بمغادرة المكتب أو المصنع في نهاية اليوم مع إطفاء الحاسوب أو التلفاز. ولكن ماذا عن برامج ومنتجات الأجهزة المحمولة؟ هل نبتعد عنها كما نبتعد عن وسائل التكنولوجيا الأخرى؟ نتمنى بأن نستطيع إقفال هواتفنا المحمولة ببساطة، ولكن قليل منا من يستطيع فعل هذا. وفي الحقيقة، قد أظهرت الإحصائيات بأن 2 من أصل 3 أشخاص يضعون أجهزتهم المحمولة على المنضدة بجانب أسرّتِهم. إنها آخر ما نضعه قبل نومنا وأول ما نتفقّده عند استيقاظنا. أسعد المستخدمين أو اترك كل شيء لا نستطيع النوم وأجهزتنا المحمولة بعيدة عنا قليلًا، فنحن لا نرغب بالانفصال عنها فقد أصبحت ما يسمى بالتكنولوجيا اللصيقة (sticky technology) حيث أصبحنا مرتبطين بشكل قوي بأجهزتنا المحمولة وأصبح استخدامنا لها عادةً مستمرة وتقريبًا بدون إدراك. وازن هذا بالحقيقة القاسية بأن نصف تطبيقات الأجهزة المحمولة في متجر "آبل" للتطبيقات ليس لديها أي مستخدمين على الإطلاق. يجب على الشركات التي ترغب بالنجاح في نطاق الأجهزة المحمولة أن تتأكد من أنها تنشئ تجربة مستخدم تتوافق تمامًا مع التوقعات العالية للجمهور. تحدث بالأمور الشخصية: سياق الكلام يهم ومع ثورة الأجهزة المحمولة، فإن هنالك من البيانات عن كل شيء وكل شخص أكثر بكثير من أي وقت سابق، وهذا الشيء لا تراجع عنه. خذ على سبيل المثال شركة "فيسبوك"، فخلال فترة عملي هناك، أجرى فريقي اختبارًا لتحديد قابلية المستخدمين لتقبل الإشعارات المنبثقة، فقمنا باختيار مجموعة من المستخدمين الذين لم يرغبوا في استقبال الإشعارات المنبثقة وقمنا بعرض شاشة لهم بعدما قاموا مباشرة بإرسال رسالة فورية مما وضح لهم أهمية الإشعارات المنبثقة. الشيء الذي كان مخادعًا لنا خلال فحصنا هو كم استغرق المستخدمين حتى يكون ناجحًا، وكان قد احتاجوا ل5 خطوات لتغيير إعداداتهم. وعادةً ما تخسر شركات الأجهزة المحمولة 90% من مستخدميها مع كل خطوة لذلك لم نكن متفائلين. ولكن تفاجأنا بأن تقريبًا 1 من أصل كل 4 مستخدمين قام بالفعل بتغيير خصائصه. والشيء الذي وجدته مشوقًا حول هذا، هو كيف تطور سلوك المستخدم بسرعة على الأجهزة المحمولة. وتقريبًا بمدة 6 أشهر قبل أن نجري الاختبار، كان هنالك أغلبية من مستخدمي "فيسبوك" مشككين بالإشعارات المنبثقة لذلك رفضوا استقبالها. هم لم يكونوا متأكدين تمامًا من طبيعة هذه الاشعارات المنبثقة أو اذا كان لها أي قيمة على الإطلاق. وشعر بعضهم بالانتهاك من قِبل هذه الإشعارات، وفجأةً أدرك الناس بأن الإشعارات المنبثقة مكّنتهم فورًا من معرفة عندما ينشر أحد الأصدقاء صورةً لهم أو عندما يرسل لهم رسالة أو يشير لهم في منشور. لذلك أرادوا الإشعارات المنبثقة وما كان ملائمًا من قبل أصبح غير طبيعي. كمية البيانات المتاحة لشركات الهاتف المحمول تعني بأنهم يستطيعون تخصيص التجربة لكل واحد من المستخدمين حسب مزاجه، موقعه وسياقه. والشركات التي تحقق هذا سوف تربح. أظهر الاحترام ماذا لو كان جهازنا المحمول المفضل هو ساعة بدلاً من هاتف؟ زوج من العدسات اللاصقة؟ الرقعة الذكية؟ حبة دواء ذكية؟ نهاية عصبية رقمية؟ وكلما تصغر الأجهزة المحمولة تندمج أكثر وأكثر بأغراضنا اليومية التي تحيطنا وتصبح مترسخة بشكل عميق بداخلنا. المعلومات الغزيرة التي تجمعها أجهزتنا المحمولة مفيدة لنا غالبًا بالرغم من أنها تكشف حياتنا الشخصية أحيانًا بشكل يهدد مستوى راحتنا. مستوى الإفصاح الغير مسبوق للحياة الشخصية الذي تحتاجه ثورة الأجهزة المحمولة حتى تعمل بشكل صحيح مجهول لحد ما ولذلك سنحتاج لوضع حدود ولتوازن. عندما كان للحكومة وصول سهل لمعلوماتنا الشخصية في الماضي نتج عن ذلك عواقب وخيمة: الدول المراقبة، قوائم الأعداء واضطهاد المنشقين وفي مناطق مثل الصين هذا لا يزال قائمًا حتى يومنا هذا. ونفس الشيء ينطبق على التحكم التجاري لبياناتنا الشخصية. والجدل الأوروبي حول "الحق في أن تُنسى" يعد مثالاً على الديمقراطية في التصرف وعلى طلب الناس للمزيد من السيطرة على أتباعهم الرقميين. وضياع الخصوصية في الحقيقة هو موضوع مفرق للأجيال. معظم الشباب لا يعتقدون بأن هناك شيء يسمى خصوصية: ومعظم الناس كثيري الإنجاب يعتبرونه حقًا من حقوقهم. يعد الإطلاق المخيب للآمال لنظارات Google Glass مثالاً على ما قد يحدث عندما يفشل منتج من منتجات الأجهزة المحمولة في الوصول إلى التوقعات المتعلقة بالخصوصية. فقوة هذه النظارات تم اعتبارها مخيفة وخارجة عن أيدي المستخدمين. وشعر الناس بأنه تم صنعها لخدمة مصالح شركة Google الشخصية، وبأنه تم تصميمها لجمع البيانات لمصلحة هذا الوحش التقني بدلاً من خدمة احتياجات المستخدمين. فتم الطلب من الناس الذين يرتدون نظارات Google Glass بأن يغادروا الحانات، مسارح السينما والأماكن الحساسة. وتم سحب المنتج من الأسواق في بداية عام 2015. ترجمة -بتصرف- للمقال ‎3 ways to be just pushy enough on mobile لصاحبته SC Moatti

أحيانًا ننهمك في التركيز على الحاضر في مسيرتنا المهنيَّة دون الانتباه إلى الوجهة التي نتَّجه إليها، أو إذا ما كانت ستترك لنا الفرصة في المستقبل. فكر في المهن والمهارات التي لم تكن موجودة منذ عقد مضى، وحين تضع ذلك في اعتبارك، ابدأ في التفكير في أمنك الوظيفيّ بعد 5 أو 10 أو 15 عامًا من الآن. ما الذي يخبِّئه المستقبل للوظائف الإبداعية؟ إذا كان الإبداع حرفتك، فأنت تتعامل مع مزيج من الطبقات والفروع والأنظمة التي تبدو وكأنها تخلق شيئًا رائعًا حين تلتحم معًا. لكن لهذا المسار المهنيّ بعض السلبيّات. فقد جعل التقدُّم التكنولوجيّ السوق أكثر تنافسيّةً مما كان عليه، حيث أصبحت نحو 45% من الوظائف المتاحة في السوق حاليًا عرضة لأن تصبح مؤتمتة في المستقبل. لقد أصبحت المخاوف من أن تستولي الروبوتات على وظائفنا حقيقة ملموسة بالنسبة للكثير منا. في عالم أصبح من الممكن فيه أن يستبدل بالإنسان آلة، يجب عليك الانتباه إلى الوجهة التي يتَّجه إليها مسارك المهني، وأن تظل متفوِّقًا على الآلات التي تسعى للاستيلاء على راتبك. تعرَّف على منافسك لحسن الحظ، لم تتقن الروبوتات بعد فن الإبداع، فنحن الذين نمتلك القدرة على إيجاد الأفكار الأصيلة. لكنَّ هذا لا يعني أن عليك الاعتماد على إنجازاتك السابقة، فإتقان صنعتك ودفع نفسك للتميُّز والوصول إلى قمَّة الإبداع هو ما سيساعدك على التقدُّم دائمًا. بالإضافة إلى منافسة الروبوتات، تزايدت أيضًا شدَّة المنافسة بين المبدعين في المجالات المختلفة. فقد تخطَّى عدد الموظفين المستقلين (freelancers) 4.5 مليون في 2017. وقد خلق هذا مناخًا قاسيًا، حيث لم يعد أحدٌ بمأمن. إنها مسألة حياة أو موت، حيث عليك أن تظلّ تسعى للتفوُّق طوال الوقت. بعد أن استعرضنا المشكلات التي نواجهها، فلنتطلّع إلى المستقبل ونرى كيف يمكننا، كمبدعين، أن نكيِّف التعلّم الشخصيّ والتطوير الوظيفيّ من أجل حماية مهنتنا الغالية لسنوات قادمة. كن قابلًا للتكُّيف من الضروريّ جدًا أن تتعلم كيف تسير مع التيار وكيف تطوّر مهارات تبادليّة في مسارك الإبداعيّ. بحلول عام 2030، من المتوقَّع استحداث 900 ألف وظيفة إبداعية في المملكة المتحدة. يشكل هذا فرصة كبيرة، ومجال واسع للمهام الدقيقة، من المحتمل أن ينتج عنها أدوار جديدةً تمامًا. اجعل مجموعة المهارات الخاصة بك مزيج من القدرات العرضيّة، وكل مستعدًا للتكيّف حين يلزم الأمر. حاول التعرُّف على مجالات أخرى، ليس فقط لكي تتعَّلم، بل لأن ذلك سيساعدك على فهم لماذا تفعل ما تفعله. تعرُّفك على المؤثرات التي تؤثِّر على مجالات موازية لمجالك سيوسع إدراكك لما تعمل، وسيساعدك على الارتقاء بقدراتك. بناء الشبكات كن ودودًا، ليس فقط مع من يعمل في نفس مجالك. صحيح أن تكوين علاقتك قوية بزملائك أمر مفيد، لكن التعارف بين أشخاص من مجالات مختلفة يعطيك الثقة أن لديك من ترجع إليه إذا ما احتجت إلى المشورة، خاصة إذا ما كانوا من مجالات إبداعية أخرى، فقد تستلهم الإبداع من المصممين والكتاب وغيرهم ممن لديهم مواهب إبداعية. الأمر أسهل مما تظن. تفكر في الآتي: تفقَّد Meetup لتعثر على لقاءات عمل ومناسبات غير رسمية لتكوين العلاقات تجديد التواصل مع الزملاء القدامى وأصدقاء الدراسة والتعرف على ما وصلوا إليه في مسيرتهم المهنية الاشتراك في مجموعات فيسبوك ومناقشات تويتر ومشاركة رابط حسابك على الإنترنت في أماكن عدة. الإنترنت تتيح لك فرصًا كبيرة، فلعل هناك من يتابعك باهتمام عبر حسابك الشخصي. استمر في العمل باجتهاد إن عملك في مجال الإبداع، رغم أنه مُرضٍ نفسيًا، هو أيضًا مصدر رزقك، وهذا قد يكون مرهقًا أحيانًا. عندما يحين وقت الانصراف، أو حين تترك المكتب وتستمر في العمل على الأريكة، إذا كنت مستقلًا، من الجيد أن يظل شغفك حيًا في مشروع لا يتعلق بمهامك اليومية. تلك المشروعات التي تتعلق بالشغف تساعدك على الاحتفاظ بدرجة عالية من الحماس، وتظهر للعملاء المحتملين أنك تحب مجالك كثيرًا وأنك التزامك طويل المدى. أعد تقييم مسيرتك لا يستطيع أي منا التنبؤ بالمستقبل. لكن يجب عليك الاختلاء بنفسك والتفكر في إجابة بعض الأسئلة: ما هي درجة الأمان في عملي؟ ما هي الخطوة التالية؟ هل مهاراتي مطلوبة في سوق العمل؟ هل يمكن أن يستبدل بي روبوت؟ ما الذي أستطيع أن أقدمه أكثر من ذلك؟ هذه الأسئلة ليست مسلية، لكن عليك أن تسألها. عليك أن تجد الإجابات وتتصرف في ضوئها. عليك أيضًا أن تجري موازنة بين مجال عملك والمجالات الأخرى الصاعدة. كن صريحًا مع نفسك: هل المجال في طريقه إلى الاندثار؟ كيف يمكنك الدخول إلى سوق واعد؟ كيف تعرف إن كانت وظيفتك تناسبك؟ استثمر في نفسك عن طريق التعلم المستمر لا شك أن أهم شيء عليك فعله، وهو الشيء الذي يشمل كل ما ذكر أعلاه، هو أن تتعلم. في مجال الأعمال تزداد قيمتك مع زيادة مهاراتك. التعلم المستمر هو أفضل ما يمكنك الاستثمار فيه. علِّم وتعلم وكن دائمًا على استعداد لأن تستمع. إن وتيرة التقدم التكنولوجي ونماذج الأعمال سريعة بدرجة تجعل استيعاب المعارف الجديدة من أهم أولوياتك. أن تتعلم بنفسك أمر جيد، لكنه ليس فعالًا بما يكفي. مشاركة تجربة تعليمية مع الزملاء والأقران يضعك في تواصل مباشر مع زملاء مستقبليين محتملين بينما تتعاون معهم في تجربة تعليمية، وهذا ما لا يمكنك فعله وأنت تجلس خلف شاشة حاسوب. هذه النصائح لن تؤمن مسيرتك الإبداعية ضد المخاطر المستقبلية وحسب، بل ستساعدك أيضًا على الانطلاق على الفور. حين تعيش وتعمل في وجود هدف، فلن يستطيع أحد أن يوقفك. مترجم بتصرف عن How to future-proof your creative career لصاحبته Emily Rodgers

يعدُّ Yeoman (وتلفظ «يومِن» ومعناها في اللغة الأجنبية الخادم الجليل الذي يخدم النبلاء أو الشخص الذي يقدم خدمات جليلة ذات شأن) نظامًا عامًّا للسقالات يسمح بإنشاء أي نوع من التطبيقات، فهو يتيح البدء السريع في مشاريع جديدة ويبسّط صيانة المشاريع القائمة. السقالة باللغة العربية هي هيكل مؤقت يُستخدَم في حمل الأشخاص والمواد بغرض البناء؛ أمَّا في البرمجة، فينطبق التعريف تمامًا عليها أي هي منصةٌ مؤقتةٌ تُستعمَل في بناء هياكل التطبيقات للانطلاق بعملية الإنشاء بسرعة وذلك بتوليد الملفات البدائية الأساسية للمشروع أو التطبيق (الهيكل العام) الذي تود إنشاءه وفق مواصفات ومعايير تحدِّدها مما يوفر عليك الكثير من الوقت. ويمكن القول أنَّ Yeoman محايدٌ مع لغات البرمجة أي يسمح بإنشاء مشاريع بأي لغة تريد (لغات الويب أو لغة جافا أو بايثون أو سي شارب أو غيرها). لا يتخذ Yeoman في حد ذاته أي قرارات. تُتخَذ كل القرارات من قبل المولّدات التي هي في الأساس ملحقات في بيئة Yeoman. هناك الكثير من المولدات المتاحة كما أنّه من السهل إنشاء مولّد جديد يناسب أي سير عمل تريد. Yeoman هو دائمًا خيارك الصحيح لاحتياجات بناء التطبيقات وتوليد ملفات المشروع الابتدائية. فيما يلي بعض حالات الاستخدام الشائعة له: إنشاء مشروع جديد بسرعة إنشاء أقسام جديدة من المشروع، مثل وحدة تحكم جديدة مع اختبارات الوحدة إنشاء وحدات (modules) أو حزم (packages) التمهيد لخدمات جديدة فرض المعايير والممارسات الجيّدة والدلائل النمطية الترويج لمشاريع جديدة من خلال السماح للمستخدمين بالبدء مع تطبيق أو مشروع نموذجي وغيرها من حالات الاستخدام جدول المحتويات حرصًا على تنظيم المقالة ولتسهيل الوصول إلى القسم الذي تريده بسهولة، سنذكر هنا جدول المحتويات باختصار: الجزء الأول: البدء مع Yeoman تثبيت yo وبعض المولدات تنصيب السقالة واستخدامها عمليًا أوامر yo الأخرى استكشاف الأخطاء وإصلاحها الجزء الثاني: تنصيب سقالة Yeoman لبناء تطبيق ويب بناء تطبيق نموذجي باستخدام Yeoman ماذا لدينا في هذه الورشة؟ الخطوة 1: إعداد بيئة التطوير الخاصة بك الخطوة 2: تثبيت مولّد Yeoman الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله الخطوة 4: مراجعة بنية التطبيق الذي أنشأته بواسطة Yeoman الخطوة 5: معاينة تطبيقك في المتصفح الخطوة 6: اختبار التطبيق بواسطة Karma و Jasmine الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) الخطوة 8: الاستعداد لمرحلة الإنتاج ختام الورشة، تهانينا! المصادر الجزء الأول: البدء مع Yeoman يُعدُّ yo أداة سطر الأوامر في Yeoman التي تسمح بإنشاء مشاريع باستخدام قوالب السقالات (scaffolding templates، يشار إليها باسم «المولدات» [generators]). يُثبَّت yo والمولدات المستخدمة باستعمال مدير حزم نود (npm). تثبيت yo وبعض المولدات تأكد بدايةً من تثبيت Node.js ومدير حزمه npm على حاسوبك. نفِّذ الأمر التالي للتأكد من وجود Node.js و npm لديك: $ nodejs -v v8.10.0 $ npm -v 3.5.2 ننصحك بالرجوع إلى مقال تثبيت Node.js على نظام أبونتو لمزيد من المعلومات حول عملية التثبيت على نظام لينكس. أمَّا على نظام ويندوز، نقترح استخدام أداة سطر أوامر أفضل مثل cmder أو PowerShell لتجربة أفضل. يمكنك دومًا الرجوع إلى موقع Node.js الرسمي واختيار نوع نظام التشغيل لتثبيت Node.js و npm عليه. ثبِّت بعد ذلك yo باستخدام npm عبر الأمر التالي: npm install -g yo بعد ذلك، تُثبَّت المولد(ات) اللازم(ة)، والتي تكون عبارة عن حزم npm تسمى بالشكل generator-XYZ، إذ XYZ هو اسم المولِّد. ابحث عنها على في هذه الصفحة أو عن طريق تحديد خيار قائمة "تثبيت مولد" (install a generator) أثناء في سطر الأوامر yo. إن أردت تثبيت المولد webapp مثلًا، نفِّذ الأمر التالي: npm install -g generator-webapp قد يواجه مستخدمو Node و npm الجدد مشكلات متعلقة بالأذونات. تظهر هذه المشكلات في شكل أخطاء EACCESS أثناء التثبيت. ارجع إلى دليل npm لإصلاح الأذونات إذا حدث لك هذا. تنصيب السقالة واستخدامها عمليًا سنستخدم المولِّد generator-webapp الذي ثبَّتناه للتو في أمثلتنا أدناه. استبدل بالاسم webapp (الذي هو XYZ) اسم المولد الخاص بك للحصول على نفس النتيجة. من أجل تنصيب السقالة في مشروعك الجديد، نفِّذ الأمر التالي: yo webapp ستطرح أغلب المولّدات مجموعة من الأسئلة من أجل تخصيص المشروع الجديد؛ هل تذكر المواصفات والمعايير التي أخبرتك آنفًا بها لتخصيص بها مشروعك؟ ها هي عمليًا. لمعرفة الخيارات المتاحة، استخدم أمر المساعدة : yo webapp --help تعتمد الكثير من المولدات على أنظمة البناء (تعرف بأنها «أدوات بناء» أيضًا) مثل Gulp أو Grunt، ومديري الحزم مثل npm و Bower. تأكد من زيارة موقع المولّد لتتعلّم كيفية تشغيل التطبيق الجديد وصيانته. يمكنك الوصول بسهولة إلى الصفحة الرئيسية للمولّد بتنفيذ الأمر التالي: npm home generator-webapp من المرجّح أن توفر إطارات العمل المعقدة للسقالات مولدات إضافية لبناء الأجزاء الصغيرة من المشروع. يشار إلى هذه المولدات عادةً بالمولدات الفرعية (sub-generators)، ويمكن الوصول إليها كما يلي: generator:sub-generator. لنأخذ المولِّد generator-angular مثالًا. يمكن بمجرد إنشاء تطبيق angular بالكامل إضافة ميزات أخرى. لإضافة وحدة تحكم جديدة إلى المشروع، شغِّل المولد الفرعي لوحدة التحكم: yo angular:controller MyNewController أي أن عمل السقالة لا تقتصر على بناء التطبيق توليد ملفاته الأولية، بل إضافة مزايا وعناصر إليه. أوامر yo الأخرى بخلاف الأساسيات التي غطّيناها في القسم السابق، يعد yo أيضًا أداة تفاعلية بالكامل. ستوفر كتابة yo ببساطة في الطّرفية قائمة من الخيارات لإدارة كل ما يتعلق بالمولدات: التشغيل والتحديث والتثبيت والمساعدة وغيرها من الأدوات. تُوفّرyo أيضا الأوامر التالية: yo --help: تمكنك من الوصول إلى شاشة المساعدة الكاملة yo --generators: تعطي قائمة بكل المولدات المثبتة yo --version: للحصول على الإصدار استكشاف الأخطاء وإصلاحها يمكن إيجاد معظم المشكلات بتنفيذ الأمر: yo doctor سيشخِّص الأمر doctor خطوات لحلّ المشكلات الأكثر شيوعًا. الجزء الثاني: تنصيب سقالة Yeoman لبناء تطبيق ويب أصبحت الآن جاهزًا لبناء تطبيق ويب كامل الوظائف من البداية بالاستعانة بمنصة Yeoman و FountainJS. سيُكتَب نموذج التطبيق في React أو Angular1 أو Angular2. ليس لديك أي فكرة عن React أو Angular؟ لا بأس، سوف نرشدك. ومع ذلك، فإننا نفترض أن لديك تجربة سابقة مع لغة جافاسكريبت. بناء تطبيق نموذجي باستخدام Yeoman سيكون نموذج تطبيق الويب الذي ستنشئه تنفيذًا لمشروع إطار عمل يسمى TodoMVC. ستتمكن من إضافة عناصر مهام لإنجازها (todos) أوحذفها، أو ترشيحها، وسنضيف معًا ميزة لحفظها في وضع عدم الاتصال. ماذا لدينا في هذه الورشة؟ سنبني تطبيق TodoMVC أعلاه من الصفر. كل خطوة سوف تُبنَى على التي تسبقها، لذلك سننتقل من خلال كل خطوة تلو الأخرى: الخطوة 1: إعداد بيئة التطوير الخاصة بك الخطوة 2: تثبيت مولّد Yeoman الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله الخطوة 4: مراجعة بنية التطبيق الذي أنشأته بواسطة Yeoman الخطوة 5: معاينة تطبيقك في المتصفح الخطوة 6: اختبار التطبيق بواسطة Karma و Jasmine الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) الخطوة 8: الاستعداد لمرحلة الإنتاج سوف تستغرق هذه الخطوات حوالي 25 دقيقة لإتمامها. في الختام، سيكون لديك تطبيق TodoMVC أنيق وسوف يكون جهاز حاسوبك معدًّا لإنشاء المزيد من تطبيقات الويب الرائعة في المستقبل. جاهز؟ لنبدأ مع الخطوة الأولى! الخطوة 1: إعداد بيئة التطوير الخاصة بك ستكون معظم تفاعلاتك مع Yeoman عبر سطر الأوامر. نفّذ الأوامر في الطّرفية إذا كنت تستخدم نظام التشغيل Mac أو في الصدفة shell في نظام لينكس أو في واجهة cmder (وهي المفضلة) أو PowerShell أو cmd.exe إذا كنت تستخدم نظام التشغيل ويندوز. تثبيت المتطلبات الأساسية قبل تثبيت Fountain Webapp Generator، ستحتاج إلى ما يلي: الإصدار السادس من Node.js أو ما بعده. الإصدار الثالث من npm أو ما بعده (والذي يأتي مرفقًا مع Node) نظام التحكم بالإصدارات Git يمكنك أن تتحقق مما إذا كان لديك Node و npm مثبتين بكتابة ما يلي: node --version && npm --version إذا كنت بحاجة إلى ترقية Node أو تثبيته، فإن أسهل طريقة هي استخدام المثبت في نظامك الأساسي. نزِّل حزمة "msi." بالنسبة لنظام ويندوز أو "pkg." لنظام التشغيل Mac من موقع NodeJS ثم ثبِّتها. وإذا كنت تستخدم نظام لينكس، يمكنك تنزيل أحدث إصدار من صفحة التنزيل في الموقع الرسمي. يكون مدير الحزم npm مدمجًا مع Node، رغم أنّك قد تحتاج إلى تحديثه. وتأتي بعض إصدارات Node مع الإصدارات القديمة بدلاً من npm. يمكنك تحديث npm باستخدام هذا الأمر: npm install --global npm@latest يمكنك التحقق من تثبيت Git من خلال كتابة ما يلي: git --version إذا لم يكن لديك Git، حمّل أداة التثبيت من الموقع الرسمي. إن كان نظام التشغيل لديك هو أحد توزيعات ديبيان من لينكس، فنفِّذ الأمر التالي لتثبيت Git: sudo apt install git تثبيت أدوات Yeoman بمجرد تثبيت Node، ثَبِّت أيضًا مجموعة أدوات Yeoman عبر تنفيذ الأمر التالي: npm install --global yo هل هناك أخطاء؟ إذا واجهت أي أخطاء في الأذونات أو الوصول، مثل خطأ EPERM أو EACCESS، فلا تستخدم sudo كحلّ بديل. تستطيع الاستفادة من هذا الدليل. ويمكنك أيضًا الإطلاع على هذا المقال لمعلومات أوسع حول عملية التثبيت. التحقق من نجاح عملية التثبيت من المستحسن التحقق من تثبيت كل شيء كما هو متوقع عبر تنفيذ أوامر Yeoman شائعة الاستخدام مثل yo مع الراية version-- كالتالي: yo --version إصدارات أدوات CLI التي تعمل معها هذه الورشة البرمجية تتغير التكنولوجيا بسرعة! لقد نُفِّذت هذه الورشة التعليمية باستخدام الإصدار 1.8.4 من سطر الأوامر yo. إذا كنت تواجه مشكلات في إصدار أحدث، فسيسعدنا أن نعرف عنها. يمكنك فتح تذكرة في GitHub للإبلاغ بأي مشكلة. الخطوة 1: تثبيت مولد Yeoman ستحتاج في سير عمل تطوير الويب التقليدي إلى قضاء الكثير من الوقت في إعداد الشيفرة المتداولة (boilerplate code) الخاص بتطبيق الويب الذي تعمل عليه، وتنزيل التبعيات، وإنشاء بنية مجلد الويب الخاصة بك يدويًا. ولكن مولّدات Yeoman ستسهّل عليك المهمّة كثيرًا! لنثبِّت مولّدًا لمشاريع FountainJS. تثبيت المولّد يمكنك تثبيت مولدات Yeoman باستخدام الأمر npm وهناك أكثر من 3500 مولد متاح الآن، وكثير منها كتبه أفراد مجتمع المصادر المفتوحة. ثبِّت المُولِّد generator-fountain-webapp باستخدام هذا الأمر: npm install --global generator-fountain-webapp سيبدأ هذا بتثبيت حزم Node المطلوبة للمولد. تذكير: إذا واجهت أي أخطاء في الأذونات أو الوصول، مثل خطأ EPERM أو EACCESS، فلا تستخدم sudo كحلّ بديل. تستطيع الاستفادة من هذا الدليل. في الوقت الذي تستخدم فيه npm install مباشرة، يمكنك البحث عن المولدات عبر قائمة Yeoman التفاعلية. نفِّذ الأمر yo وحدِّد Install a generator للبحث عن المولدات المنشورة. الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله لقد استخدمنا كلمة «سقالة» مرات عديدة وشرحنا معناها في بداية هذا الدليل لكن قد ما تزال غريبة بعض الشيء. تعني السقالة، بالمفهوم المستخدم في Yeoman للكلمة (وفي عالم البرمجة عمومًا)، إنشاء ملفات لتطبيق الويب الخاص بك وفق معايير ومواصفات تضبطها أنت. سترى في هذه الخطوة كيف يمكن لـ Yeoman إنشاء ملفات خاصة بمكتبتك أو إطارك المفضل، مع خيارات لاستخدام مكتبات خارجية أخرى مثل Webpack و Babel و SASS وربطها بمشروعك، بأقل جهد ممكن. إنشاء مجلد المشروع أنشئ مجلدًا باسم mytodo ليحوي جميع ملفات المشروع الذي سنعمل على بنائه: mkdir mytodo && cd mytodo هذا المجلد هو المكان الذي سيولِّد المولد فيه ملفات مشروعك الابتدائية (أي هيكل المشروع). الوصول للمولدات عبر قائمة Yeoman نفِّذ الأمر yo لرؤية المولدات الخاصة بك: yo إذا كان لديك عدد قليل من المولدات المثبتة، فستتمكن من الاختيار بشكل تفاعلي منها. اختر المُولِّد Fountain Webapp لتشغيله. استخدام المولدات مباشرة عندما تستأنس أكثر بسطر الأوامر yo، ستفضّل تشغيل المولِّد مباشرةً دون استخدام القائمة التفاعلية (وضغط المزيد من الأزرار) على النحو التالي: yo fountain-webapp إعداد المولد الخاص بك توفر بعض المولدات إعدادات اختيارية لتخصيص تطبيقك مع مكتبات مطوّري البرامج المشتركة لتسريع الإعداد الأولي لبيئة التطوير الخاصة بك. يوفر المولد FountainJS بعض الخيارات لكي تستخدم ما تفضله: إطار العمل (React أو Angular2 أو Angular1) وحدة الإدارة (Webpack أو [SystemJS] أو لا شيء إذا كنت تستعمل Bower) معالج أولي لشيفرة جافاسكربت (Babel أو TypeScript أو لا شيء) معالج أولي لشيفرة CSS ‏(SASS أو LESS أو لا شيء) ثلاثة نماذج للتطبيق (صفحة هبوط وصفحة "مرحبا بالعالم" [hello world] ونموذج TodoMVC) سوف نستخدم لهذه الورشة الخيارات التالية: React Webpack Babel SASS نموذج Redux TodoMVC حدّد هذه الخيارات على التوالي باستخدام مفاتيح الأسهم ثم زر "إدخال" واستمتع بما يحدث على الشاشة. سيبني Yeoman تلقائيًا هيكل تطبيقك ويولد لك جميع الملفات الابتدائية الأساسية له، وسيجلب كل الاعتماديات (dependencies) الخاصة به. بعد بضع دقائق، سنكون مستعدين للانتقال إلى الخطوة التالية. الخطوة 4: مراجعة التطبيق الذي بناه Yeoman افتح المجلّد mytodo الخاص بك لإلقاء نظرة على ما جرى بناؤه إلى الآن. يجب أن يبدو مثلما توضحه الصورة التالية: لدينا في مجلد المشروع المجلدات الفرعية التالية: src: مجلّد رئيسي لتطبيق الويب app: شيفرة React و Redux index.html: ملف html الرئيسي index.js: نقطة الدخول لتطبيق TodoMVC conf : مجلّد رئيسي لملفات الضبط الخاصة بالأدوات الخارجية (Browsersync و Webpack و Gulp و Karma) gulp_tasks و gulpfile.js: مهام أداة البناء Gulp babelrc. و package.json و node_modules: الضبط والاعتماديات المطلوبة gitattributes. و gitignore.: ملفات ضبط Git أنشِئ الإيداع (commit) الأول في المستودع الآن وبعد التوليد والتثبيت، يجب أن يكون لديك مستودع git جديد مهيأ بالفعل. يمكنك الإيداع فيه بأمان لحفظ الحالة الراهنة من خلال هذه الأوامر: git add --all && git commit -m 'First commit' الخطوة 5: استعرض تطبيقك في متصفّح الويب إن أردت معاينة تطبيق الويب الخاص بك في متصفحك المفضل، ليس عليك القيام بأي شيء خاص لإعداد خادم ويب محلي على جهاز حاسوبك، فهو جزء من مهام Yeoman. تشغيل الخادم شغّل سكربت npm لإنشاء خادم http محلي يستند إلى Node على localhost:3000 (أو 127.0.0.1:3000 بالنسبة لبعض التكوينات) بتنفيذ الأمر التالي: npm run serve افتح لسانًا جديدًا في متصفحك وانتقل إلى العنوان 3000:localhost: إيقاف الخادم إذا احتجت في أي وقت إلى إيقاف الخادم، فاستخدم الاختصار Ctrl + C لإنهاء عملية سطر الأوامر الحالية. ملاحظة: لا يمكنك تشغيل أكثر من خادم http واحد على نفس المنفذ (3000 افتراضيًا). مراقبة ملفاتك افتح محرر النصوص الذي تفضّله وابدأ في إجراء التغييرات. سيفرض كل حفظِ لملفاتك تحديث المتصفح تلقائيًا إذ لا يتعين عليك القيام بذلك بنفسك. يُطلق على هذا إعادة التحميل المباشر وهي طريقة رائعة لتعاين حالة تطبيقك في الوقت الفعلي وعكس التغييرات مباشرةً على المتصفح دون أن تفعل أي شيء. تُوَّفر لتطبيقك عملية إعادة التحميل المباشر (Live reloading) من خلال مجموعة من مهام Gulp التي يتم إعدادها في الملف gulpfile.js و Browsersync التي يتم إعدادها في الملف gulp_tasks/browsersync.js؛ فهي تراقب التغييرات التي تطرأ على ملفاتك وتعيد تحميلها تلقائيًا في المتصفح في حالة اكتشاف تغيير ما. فيما يلي أدناه، حرّرنا الملف Header.js القابع في المجلّد src/app/components. بفضل التحديث المباشر، تظهر التغييرات مباشرةً في المتصفح وهذه صورة قبل إجراء أي تعديل: وصورة بعد إجراء تعديل (تغيير عنوان التطبيق) وحفظ الملف: لا تنس الاختبار! لديك تطبيق TodoMVC مجرّب وأنت تقوم بتغيير العنوان. يتعيّن عليك تعديل الاختبار في mytodo/src/app/components/Header.spec.js أو التراجع عن التغيير للتثبت من عملية إعادة التحميل المباشر. الخطوة 6: الاختبار باستخدام Karma و Jasmine إذا لم يكن Karma مألوفًا لديك، فهو برنامج اختبار شيفرات جافاسكربت أي إطار عمل محايد للاختبار. أمّا إطار الاختبار Jasmine فهو مدمج في المولد fountainjs. عندما نفّذنا الأمر yo fountain-webapp في وقت سابق من هذا الدليل، قام المولد بتوليد الملفات ذات النمط spec.js.* في المجلد المصدري لمجلد المشروع mytodo، وأنشأ الملف conf/karma.conf.js، ثم سحب وحدات Node إلى Karma. سنحرّر سكربت Jasmine لوصف الاختبارات قريبًا ولكن دعنا نرى كيف يمكننا إجراء الاختبارات أولًا. تشغيل اختبارات الوحدة دعنا نعود إلى سطر الأوامر ونوقف الخادم المحلي قسرًا باستخدام الاختصار Ctrl + C. يوجد بالفعل سكربت npm أُدرِج في الملف package.json الخاص بنا لإجراء الاختبارات. يمكن تشغيله على النحو التالي: npm test ينبغي أن تنجح جميع الاختبارات. تحديث اختبارات الوحدة ستجد اختبارات الوحدة مهيّأة في المجلد src، لذلك افتح الملف src/app/reducers/todos.spec.js. هذا هو اختبار الوحدة للمخفض (reducer) الخاص بـ Todos. على سبيل المثال، نركز على الاختبار الأول الذي يتحقق من الحالة الابتدائية. (ملاحظة: على ويندوز، قد تحتاج إلى إضافة 127.0.0.1 localhost إلى الملف etc/hosts): it('should handle initial state', () => { expect(todos(undefined, {})).toEqual([ { text: 'Use Redux', completed: false, id: 0 } ]); }); واستبدل هذا الاختبار بما يلي: it('should handle initial state', () => { expect(todos(undefined, {})).toEqual([ { text: 'Use Yeoman', // <=== هنا completed: false, id: 0 } ]); }); عندما نعيد تنفيذ الاختبارات عبر الأمر npm test، ينبغي أن نرى أن الاختبارات تفشل في هذه الحالة. ملاحظة: إذا كنت تريد تشغيل الاختبارات تلقائيًا بعد إجراء أي تعديل، يمكنك استخدام npm run test:auto بدلًا من ذلك. افتح src/app/reducers/todos.js ثم ضع الشيفرة التالية مكان الحالة الابتدائية (initial state): const initialState = [ { text: 'Use Yeoman', completed: false, id: 0 } ]; رائع! لقد أصلحت الاختبار: تسهِّل كتابة اختبارات الوحدة (unit tests) تحديد الأخطاء كلّما أصبح تطبيقك أكبر فأكبر وكلّما انضمّ المزيد من المطورين إلى فريقك. تجعل ميزة الاعتماد على السقالة (scaffolding) في Yeoman كتابة اختبارات الوحدة أسهل، لذا لن يكون لك عذر إذا لم تكتب اختباراتك بيديك! ;-) الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) دعنا نعيد النظر في مشكلة العناصر التي لا تثبت (تعاد إلى حالتها الأولية) عندما يُحدَّث المتصفح من خلال تطبيق mytodo مع React/Redux. تنويه: إذا لم يكن الثبات والتخزين المحلي مشكلةً بالنسبة لك أو كان وقتك ضيقًا، فيمكنك تخطي هذه الخطوة والانتقال مباشرة إلى الخطوة 8، "الاستعداد للإنتاج". تثبيت حزمة npm يمكننا استخدام وحدة Redux أخرى تسمى "redux-localstorage" تتيح لنا تنفيذ التخزين المحلي بسرعة وسهولة. نفِّذ الأمر التالي لتثبيتها: npm install --save redux-localstorage@rc استخدام redux-localstorage يجب إعداد مخزن Redux وضبطه لاستخدام التخزين. افتح الملف src/app/store/configStore.js واحذف كل محتواه وضع الشيفرة التالي مكانه: import {compose, createStore} from 'redux'; import rootReducer from '../reducers'; import persistState, {mergePersistedState} from 'redux-localstorage'; import adapter from 'redux-localstorage/lib/adapters/localStorage'; export default function configureStore(initialState) { const reducer = compose( mergePersistedState() )(rootReducer, initialState); const storage = adapter(window.localStorage); const createPersistentStore = compose( persistState(storage, 'state') )(createStore); const store = createPersistentStore(reducer); if (module.hot) { // Enable Webpack hot module replacement for reducers module.hot.accept('../reducers', () => { const nextReducer = require('../reducers').default; store.replaceReducer(nextReducer); }); } return store; } إذا عاينت تطبيقك في المتصفح، سترى أن هناك عنصرًا واحدًا "Use Yeoman" في قائمة مهام todo. يعمل التطبيق على تهيئة مخزن مهام todos إذا كانت مساحة التخزين المحلية فارغة ولم نضف فيها أي عناصر حتى الآن. جرب إضافة بعض العناصر إلى القائمة: الآن عندما تُحدِّث المتصفح، نلاحظ أن العناصر موجودة وثابتة. أمرٌ جيدٌ! يمكننا التأكّد من ثبات بياناتنا في التخزين المحلي عبر التحقق من لوحة الموارد (Resources) في أدوات المطور Chrome DevTools واختيار Local Storage في الجانب الأيسر: اكتب اختبارات الوحدة تريد تحديًا إضافيًا؟ حسنًا لك ذلك؛ أعد زيارة اختبارات الوحدة في الخطوة 6 وفكّر في كيفية تحديث اختباراتك الآن إذ تستخدم الشيفرة التخزين المحلي. الخطوة 8: الاستعداد لمرحلة الإنتاج هل أنت مستعد لعرض تطبيقك الجميل؟ دعنا نحاول بناء نسخة جاهزة للإنتاج نستطيع تسليمها للعميل مثلًا. تحسين الملفات من أجل الإنتاج لإنشاء نسخة نهائية من تطبيقنا، نحتاج إلى: فحص الشيفرة بحثا عن أي أخطاء محتملة عبر الأداة lint. تجميع واختصار السكريبتات والأنماط الخاصة بنا لحفظها. تفسير أي مُخرَجات للمعالجات الأولية (preprocessors) التي نستخدمها. وإجمالًا جعل تطبيقنا رشيقًا. ما يثير الدهشة هو أننا نستطيع فعل كل ما سبق فقط بتنفيذ الأمر البسيط التالي: npm run build إنّ تطبيقك الرشيق الجاهز للإنتاج متوفرٌ الآن في المجلد dist في جذر مجلد المشروع mytodo الخاص بك. هذه هي الملفات التي يمكنك وضعها على خادمك باستخدام FTP أو أي خدمة نشر أخرى. بناء ومعاينة التطبيق الجاهز للإنتاج هل تريد معاينة تطبيقك الجاهز للإنتاج محليًا؟ إليك مجرد سكربت npm بسيط آخر: npm run serve:dist سيعمل على بناء مشروعك وإطلاق خادم ويب محلي. إنّه رائع حقًّا! ختام الورشة، تهانينا! كما ترى، يمكن أن يتيح لك Yeoman الكثير والمزيد من الأدوات الخيارات، فيدعم تنصيب السقالات بناء تطبيقات Angular وبعض الإطارات الأخرى التي لم نتطرق لها هنا. على سبيل المثال، يدعم مولد Fountain Angular كذلك إنشاء أنابيب (pipes) وتوجيهات (directives) وخدمات (services) ومكونات (components) جديدة لك. يمكن توليد مكونات جديدة ببساطة وسهولة عبر تنفيذ الأمر: yo fountain-angular2:component componentName، والذي سيؤدي إلى إنشاء ملف المكون الخاص بك وإضافة شيفرة componentName.spec.js جديدة لاختبار الوحدة أيضًا. العثور على المزيد من المولدات الفرعية يمكنك في أي وقت استخدام الأمر: yo --generators للاطلاع على جميع المولدات الفرعية لمولدات Yeoman المثبَّتة. وماذا بعد ذلك؟ Yeoman دائم التطور. احرص على زيارة الموقع yeoman.io للحصول على مزيد من المعلومات ومتابعة Yoman@ على تويتر لمواكبة المستجدات. ساعدتنا مولدات Fountain على كتابة هذا التطبيق Todo بسرعة وأناقة. تابع YeomanFountain@ للبقاء على اطلاع على الميزات الجديدة والإصدارات الجديدة. React هو مكتبة جافا سكريبت لبناء واجهات المستخدم. اطلع على توثيق React في موسوعة حسوب للتعرف على هذه المكتبة أكثر. Angular2 إطار عمل للتطوير على كافة المنصّات. Webpack عبارة عن وحدة مجمعة (module bundler) نموذجية تأخذ الوحدات النمطية ذات الاعتماديات وتولد أصول ثابتة (static assets) تمثل تلك الوحدات. *JSPM حزمة إدارة متصفح. حمّل أي تنسيق للوحدة (ES، و AMD، و CommonJS، وglobals) مباشرة من أي سجل مثل npm و GitHub مع إدارة تبعية حديثة الإصدار (flat versioned dependency management). هذا كل ما ينبغي ذكره الآن بخصوص Yeoman. المصادر Getting Started With Yeoman Let's Scaffold A Web App With Yeoman

أنت كمصمم, إذا قمت يومًا ما بتسليم أعجوبتك المرئية لمطور فأنت تعرف تمامًا مدى الجدل الذي ينتج عن ذلك. هل ما تخيلته قابل للعمل عند النظر إليه من المنظور التطويري؟ هل يعلم المطور ما الآلية التي كانت تدور في عقلك؟ هل يقوم مطوّرك حقًا بالتطوير؟ القائمة تطول وتطول ولكن دائمًا ما يكون هنالك طرفين للقصة. وماذا عن المطور الذي ينتظر تصميمك؟ وللإجابة على هذا السؤال وعلى أسئلة أخرى قمنا بمقابلة فريقنا الخاص في KlientBoost للخروج بهذه الست نصائح لتعاون أفضل بين المطور والمصمم. كل هذا يبدأ بالتركيز على المستخدم يجب على كل من المطورين والمصممين أن يعملوا دائمًا وأن يُبقوا المستخدم في الحسبان. إن لم تكن التجربة أفضل للمستخدم فلا فائدة من تصميم او حتى بناء أي شيء أي أن جهودك المبذولة لن تكون متماثلة مع أهداف العمل. فإما إن كنت تصمم موقعًا جديدًا أو تطور خصائص جديدة للمنتج فيجب من البداية على فِرق التصميم والتطوير أن يكون لديها هدفًا مشتركًا لتطوير تجربة المستخدم. ولكن كيف بالإمكان أن نعرف ما هو أفضل للمستخدم؟ بالاختبار. وحسب "تن كادويك" من وكالة Five, فإن تجربة المستخدم واختبار المنتج يبدآن بمجرد بدء الأسبوع الأول من المشروع. والاختبار لتحسين تجربة المستخدم لا يتوقف أبداً خلال فترة حياة المشروع. تعطينا مجموعة Nielsen Norman قائمةً يجب على كل من المصممين والمطورين أن يتبعوها عندما يتعلق الأمر باختبار قابلية الاستخدام. وبمجرد اكتمال مرحلة ما قبل الاختبار, فإن فرق التصميم والتطوير تتقارب أكثر وتعلم بالضبط ما يجب التركيز عليه. كلما كان مبكرًا، كان أفضل لن تعلم فِرق التطوير أي شيء عادةً عن المشروع حتى تصلهم ملفات التصميم. وإذا كانت هذه الملفات من الصعب جدًا تنفيذها, فإن هذا يعني بأن المصمم أهدر وقته وأن عليه الآن العودة منذ البداية. ولتجنب حدوث هذا, فإن المصممين والمطورين يحتاجون للعمل سوياً منذ البداية. والانخراط منذ المراحل الأولى يضمن بأن تبقى كل الأطراف متوافقة سوياً ولديها نفس التركيز طوال الوقت. وجدت دراسة في قسم الهندسة الصناعية والإدارة في جامعة "أولو" بفنلندا بأن التعاون المبكر في مشروع ما بين جميع الأطراف يؤدي إلى: فرصة ضئيلة في تطوير تصاميم ركيكة. رضى أكبر بكثير عن عمل المنتج واستخدامه من قبل المستخدم. خلق مساحة للحلول الإبداعية والتبادل المكثف للأفكار قبل فوات الأوان. ولا يختلف المصممون والمطورون في هذا الشأن. أنظمة أقوى تعني عمليات أفضل. عندما تمتلك كل الفرق الأدوات والمعرفة المطلوبتين لإنجاز شيء ما فهي عادةً ما تنجح في انجازه. ولكن أحد الأخطاء الشائعة التي ستجدها بين المصممين والمطورين هي أحياناً أشياء بسيطة مثل: معايير التسمية. الأحجام. الهوامش. الحشوات. الشبكات. ولكن وجود ترتيب موحد من العمليات وطريقة معينة للتعامل معها يساعد على تسريع الأمور, وذلك لأنه لن يتم اهدار الوقت في الإجابة على أسئلة من السهل الإجابة عليها. وهذا يساعد على الوصول لهدف موحد لكل من المصممين والمطورين والذين لن يتعثروا بالمشاكل اللوجستية. وعندما يتعلق الأمر بالأنظمة والعمليات, فإنه هنا تحديداً يجب عليك الحصول على قائمة مفصلة يتّبعها كل فريق من الفرق قبل الانتقال للمرحلة التالية من المشروع. مما يؤدي إلى... ما قبل التسليم بتتبعك لكل نصائحنا حتى هذه النقطة فإنك بالتأكيد تدرك مدى أهمية تسليم مشروعك جاهزًا وبدون أي نقص للتحرك للمرحلة التالية. وبينما يقترب المصممون من إكمال أعمالهم, فإنه من المهم أن تعرج على الأهداف الرئيسية للمشروع للتأكد من اجتيازه للفحص. أسئلة مثل المذكورة بالأسفل ستساعدك على أن تجد تحديثات يجب أن تحدث قبل تمرير المشروع لفريق التطوير: هل جودة التصميم عالية وهل أنت راضٍ عنها؟ هل يحسّن التصميم تجربة المستخدم؟ هل تم اختبار التصميم من قِبل الزبائن الواقعيين؟ بالإجابة بنعم على كل الأسئلة السابقة, فإنك تقلل من فرصة عمل أي إعادة تصميم أو إعادة عمل. سيكون من الصعب عليك أن تجري أي تعديلات على التصميم بمجرد وصوله لأيدي المطور. كيف تسير الأمور؟ 10 مرات بإمكانك قراءة نبرة صوت أحد أو لغة جسده عندما تقابله, ولكن هل هذا كله يختفي عند قراءتك لنص أو لبريد إلكتروني؟ هذا هو نفس الشيء الذي يحدث مع المصممين والمطورين. بمجرد مرور المشروع من مرحلة ما لأخرى, فإن هنالك فرصة كبيرة بأن ترجمة المشروع سوف تختلف من عضو فريق لآخر. هل قصدت أن تعمل هذا لتصميمك أم ذاك؟ وبالفحص المتكرر بين المصممين والمطورين, يمكن للمشروع أن يستمر بالتحرك وذلك بفضل إزالة مشاكل التواصل والتفسير. التواصل الواقعي كلما عمل المصممون والمطورون سويًا على مشاريعك, زادت فرص التوتر. ومع فرقنا في KlientBoost, وجدنا بأنه من سرعان ما نسينا بأننا نعمل كفريق واحد للوصول لنفس الهدف. أما بوجود الوعي الذاتي والإيثار عند التواصل مع أعضاء الفريق الآخرين ستكون قادرًا على إيجاد حل منطقي لأي مشكلة قد تحدث وبسرعة. وباتّباع ال5 نصائح السابقة, بإمكانك وضع أساسات صلبة للتواصل تمنع المشاكل من التصاعد في المقام الأول. والآن حان دورك الفرق التي تتواصل بشكل منفتح وبشكل متكرر تبني منتجات أفضل. جرب هذه النصائح الستة في مؤسستك ونؤمن بأنك ستجد المشاريع أكثر سلاسة وسرعة وسيحظى الناس بالمزيد من المرح أيضًا. ترجمة -بتصرف- للمقال ‎6 tasty ways for designers and developers to collaborate better لصاحبه Johnathan Dane

حين تُستخدم كلمة مرن (Agile) في مجال الرياضة فإنها تشير إلى الحيوية، والطاقة والمرونة، ويوصف بها الرياضيون وأبطال الأولمبيات الذين تميزوا في ألعابهم، كما يمكن استخدامها لوصف العمليات العقلية التي تتسم بالسرعة والمرونة والحدّة. أما في عالم تصميم تجربة المستخدم فإنها تشير إلى عدد العمليات التي تبدأ بميزانية قليلة، وتجمع فرقًا من المساهمين من أجل إنهاء سلسلة مهام معينة. ويركّز المنظور المرن على التفاعلات والأفراد، ومساهمات المستخدمين، والاستجابة السريعة للتغيير. منهجية التدافع (Scrum Methodology) بدأ استخدام نمط العمل المرن المبني على نموذج التدافع (Scrum Model) لأول مرة في تصميم البرمجيات، ويبدأ عادة بفريق يخطط لاجتماع يقسّم الأعضاء فيه العمليات إلى أجزاء صغيرة ويقررون أي المهام ستوكل إلى كل عضو، ثم ينشئون قائمة بالمهام التي يمكن إنهاؤها في إطار زمني محدد، ويكون عادة بين الأسبوعين والشهر. ويقوم فريق التدافع (Scrum Team) بكتابة الشيفرة البرمجية واختبار أداء المزايا خلال المرحلة الأولى التي تُسمّى "First Agile Sprint”، وهي إطار زمني قصير من العمل المكثّف. ويحضر أعضاء هذا الفريق اجتماعات قصيرة يومية ينظمّها شخص تكون مهمته أشبه بالمدرّب، ويطلق عليه عادة "Scrum Master”، ويشارك الأعضاء في هذه الاجتماعات ما أنجزوه ويفكرون في حلول للمشاكل، وتحافظ هذه الاجتماعات اليومية على إبقاء جميع الأعضاء مدركين لما فعله كل واحد منهم خلال تلك المرحلة. الصورة عبر الموقع prosoftnearshore.com. ثم يعرضوا ما أنجزوه في نهاية المرحلة على المالكين (حملة الأسهم [stakeholders]) ليتلقّوا منهم النقد والملاحظات، فيخططوا للمرحلة التالية من التطوير وما سيتغير فيها أو يُراجَع على ضوء هذه المراجعات. ويساعد نمط العمل المرن الفرَق على إنهاء المشاريع أسرع، لهذا تبنّت مجالات مثل القانون والتسويق منهجيات مشابهة، ذلك أن نمط العمل المرن في تجربة المستخدم هو المسؤول عن رسم الخطوات من أول البحث وتجميع بيانات المستخدمين من خلال اختبار قابلية الاستخدام، وذلك قبل التطوير مباشرة. ويُقدّر من يستخدمون نمط العمل المرن لتجربة المستخدم بنحو 69% من العاملية في مجال تجربة الاستخدام، ولدى جوجل منهجية تيسّرالانتقال من التصميم إلى الاختبار في وقت لا يتجاوز أسبوعًا، لكن لا شك أن كل منظّمة تستطيع أن تعدّل مراحل تلك المنهجية لتناسب أفضل الإطارات الزمنية لمشاريعها. الانتقال إلى أنماط عمل تجربة المستخدم المرنة يسرّع العمل الجماعي من عملية التحول إلى مخططات العمل المرنة إذ ينشئ المصممون والمطورون والمدراء فرقًا مشتركة تتداخل وظائفها ليعمل الجميع على أوجه مختلفة من المشكلة في نفس الوقت. وتركز كل فئة -كمجموعة و كأفراد- على أنشطة المستخدم واحتياجاته وتفاعلاته، وتنظر إلى كل ناحية من خلال تلك العدسة. وتكون العملية بهذا الشكل سلسلة من المراحل أو الأجزاء، ويمكن أن يرجع التطوير من أجل تصحيح خطأ أو فكرة غير صحيحة، أو يتقدّم للأمام إلى المرحلة التالية. تصميم تجربة المستخدم القِطَعية للتخطيط المرن (Chunk UX Design) قد يكون من المغري أن ينقل الفريق تركيزه من تلبية احتياجات المستخدم إلى إنهاء المهام التي بين يديه حين يتحرك بسرعة ليرى المشروع من البداية إلى النهاية في فترة موجزة للغاية. وإن المنتج النهائي لن يكون له قيمة إن لم يحقق الأهداف التي صُمم من أجلها. ويأتي دور التصميم القِطَعي (Chunk design) هنا في أنه يقسّم العمل إلى مهام أصغر كي تعيد تركيزك إلى البحث المرتكز حول المستخدم، فتحدد أولًا هدفك ثم تخطط أنشطة تجربة الاستخدام التي تدعم هذا الهدف، ثم بعد ذلك تقسّم تلك الأنشطة إلى مهام أصغر، وتستخدم بعدها برنامج يعتمد النظام المرن-agile أو بطاقات لاصقة لإنشاء قصص المستخدم- user stories. ويجب أن تقرر الترتيب المناسب لإنجاز تلك المهام ومن سيكون مسؤولًا عن كل واحدة، ويجب أن يكون كل قرار مرتبطًا بإحدى قصص المستخدم- user story. العمل مثل جوجل تتبع عمليات التصميم القوية خطة نظامية، لكن تمهّل قليلًا إن خرجت فكرة عما هو مخطط لها إذ هناك دومًا مساحة للتنفيذ مرة أخرى، وأعد النظر فيها مرة أخرى قبل التقدّم لما بعدها. ويتضمن أسلوب العمل في جوجل خمس مراحل، يحق للمصممين أن يتنقلوا بينها ذهابًا وإيابًا في أي وقت. ودعنا نلق نظرة على كل واحدة من تلك الخطوات التي صممت لتستغرق كل منها يومًا واحدًا، وتستطيع الشركات التي لا تتبع الخط الزمني لجوجل أن تستخدم نفس التسلسل لكي تتحول إلى نمط عمل مرن هي الأخرى. تفصيل المشروع (Unpack the Project) تبدأ مرحلة التصميم في جوجل باجتماع يشمل كل الأفراد الذين لهم علاقة بالمشروع من مختلف أقسام المؤسسة، من المصممين إلى مسؤولي المبيعات إلى ممثلي خدمة العملاء وحتى المدراء، إذ يجب أن يدلي كل هؤلاء بآرائهم من البداية. وبسبب هذا الجمع من الأشخاص ومستويات المسؤولية، فمن من المفيد هنا دعوة شخص تكون مهمته إبقاء الحديث داخل نطاق المشروع. إليك بعض الأمور التي يجب أن تناقشها في خطوة تفصيل المشروع: قدّم تصورًا عامًا عن الكيفية التي ستنتفع بها الشركة من الحل الذي لديك. اعرض مقارنات لما لدى المنافسين لك. استعرض المشكلة والحلول الجزئية الحالية التي تحاول معالجتها. جهّز شخصيات المستخدمين التي تستهدفها، وكذلك نتائج التحليلات التي قمت بها. لخّص الحل الذي تقترحه. استعرض مقاييس تجارية تدعم نجاح الحل الذي تقدّمه. إن نمط العمل المرن يبدأ بتوضيح رؤيتك من البداية، حتى لو لم تتبع أو تستخدم تسلسل جوجل في مشاريعها، فيقدّم المصممون رؤيتهم المبدئية للفريق، سواء عبر رسومات سريعة "Sketches” أو عبر تخطيط لرحلة المستخدم "cutomer journey mapping” داخل الموقع أو المنتج بشكل عام. صياغة مسوّدات للحلول (Sketching Solutions) يتفرق كل من حضر اجتماع تفصيل المشروع لينشئ رسومات بسيطة باستخدام قلم وورقة للحلول المحتملة، وللمشاركين أن يقسّموا الحلول إلى أجزاء صغيرة، ويوضّحوا الترتيب الذي يرونه لتلك الأجزاء. وبشكل عام، ابدأ بإطار عمل بسيط، وستتضح التفاصيل مع الوقت في كل مرة تكرره فيها. اتخاذ القرارات (Making decisions) اسرد العوامل المهمة لك، مثل ميزانيتك، والعوائق التقنية، ومدخلات المستخدمين، ثم راجع الحلول المحتملة لتقلل هذه الحلول إلى عدد محدود وفقًا لما تقتضيه العوامل التي لديك. أيضًا، أنشئ لوحات قصصية "Storyboards” لأفضل الحلول التي جمعتها، واستخدم حائط تصميم "Design Wall” -حائط أو لوحة تعلق عليها الحلول- لتعرض الحلول التي لديك، ثم أعد تقييمها من حيث تركيز كل منها على المستخدم. إنشاء نماذج أولية (Creating Prototypes) تأخذ كل مجموعة أحد الحلول وتبدأ في العمل، تقترح جوجل هنا بناء نماذج أولية بسرعة باستخدام قوالب Keynote أو أي أداة أخرى تسمح بتطوير النماذج في فترة يوم. لا تنس أن تطور عملية اختبار لهذه النماذج لاستخدامها في اليوم التالي أو المرحلة التالية، ويحبّذ كذلك أن تدعو حمَلة الأسهم للمشاركة في كل خطوة. اختبار التصاميم (Testing Designs) اطلب من المستخدمين أن يتفاعلوا مع نموذجك الأولي، وسجّل أنت ملاحظاتك عن تفاعلهم بينما يستخدموه لترى ما الذي لم يحدث كما خططت له، فإن تجربة المستخدم هي التي ستقود المرحلة التالية. يمكن هنا أن يسجّل المصممون المشاكل في تجربة الاستخدام من أخطاء التصميم أو مشاكل الأداء الخلفي (Back End Performance). قد تحتاج المؤسسات في البداية إلى وقت أطول من المتوقع لإنهاء بعض المراحل، تمامًا مثلما يتطور الرياضيون مع التمرين المستمر، لذا فإن فرق التصميم ستنجز أسرع مع التدرب المستمر والمتكرر، وسواء كنت ستجعل نمط العمل المرن الخاص بك مثل نموذج جوجل أو ستطور واحدًا مختلفًا لمؤسستك، فإن إدارة الوقت ستكون جزءًا مما يجعل العملية المرنة ذات كفاءة إنتاج عالية. تعقّب الوقت وضبطه (Time Tracking and Time Boxing) يتوقع أسلوب العمل المرن تقدّم العمل ويتابعه على مدار الوقت تمامًا كما يتوقّع العدّاء الوقت اللازم لإنهاء مسافة ما ويستخدم نقاطًا على طول تلك المسافة ليتابع إنجازه. وتساعد هذه التوقعات الفِرَق على توقع الوقت اللازم لتسليم منتج ما، وقد يكون حساب وقت كل مرحلة صعبًا في البداية، لكن ستجد أن العمل يسير على نمط يمكن توقعه مع الوقت، فيمكنك معه توقع الوقت اللازم لإنهاء مهام فردية خلال المرحلة. أما ضبط الوقت فيتضمن وضع وقت محدد يمكن لنشاط أن ينتهي فيه، فضع إطارًا زمنيًا لبحث تجربة المستخدم وراجع الاجتماعات والمراحل كي تقف على أسباب زيادة الكفاءة، هذا الأسلوب سيدفع كل عضو أن يرفض الأفكار التي لا تصلح مباشرة، ويركز على تلك التي تبدو واعدة. العمل الجماعي هو الذي يوجه مخطط العمل كما أن مرحلة التصميم لها أجزاء واضحة تتجانس معًا، فإن كل عضو في الفريق له دور داخل حلقة تتكرر، فالمصممون يتصورون الصفحات بشكل عام، ويناقشون مهام التصميم على أنها ضرورة لإنشاء الصورة الكاملة، لكن ذلك قد يعني أنهم يعملون بشكل مستقل عن بقية الفريق. ولتلافي ذلك، اكتب مهامًا -مثل قصة المستخدم user story- ، وأشرك الفريق في إنشاء محتوى موجه لأهداف منفردة صغيرة، واسمح للصورة الكاملة أن تتطور من مدخلات الفريق. وإن للمصممين أغلب المدخلات في المزايا التقنية الضرورية للمشروع "Backlog#Product_backlog)"، وكذلك التحليل والتطوير والاختبار، ويكون الوقت مناسبًا لمساهمة المصممين حين يبدأ مطوِّر في العمل على التفاصيل، ويمكن استخدام أدوات إدارة مشاريع مثل basecamp ومنصات التصميم مثل UXPin وتطبيق invision لتسهيل عملية التواصل بين المصممين والمطورين. إن دورة التصميم التكراري هذه تشمل التصميم من أجل القصص الفردية، وتخوض كل منظمة عملية فريدة حين تنتقل إلى مخطط عمل مرن لتجربة المستخدم، فكن مستعدًا للتغيير إلى أن يتطور فريقك ومنتجك إلى شيء أكبر مما كنت تتصور في البداية. ترجمة -بتصرف- لمقال How to Create an Agile UX Workflow لصاحبه Stephen Moyers

في كل مرة أسمع فيها كلمة "بيان" (manifesto) تسري رعدة في جسدي، إذ أنها متصلة في ذهني دومًا بالسياسة، ألا ترى أن الساسة الذين لا يستحقون الثقة يستخدمونها قبل الخوض في سيل وعود ما قبل الانتخابات، والتي سيتناسونها مباشرة بعد خداع الناس كي يعطوهم أصواتهم؟ لكن البيان الذي أسعد بالقول أني لا تصيبني نفس الرعدة حين أسمع به هو بيان Agile (التطوير المرن) لتطوير البرامج، ذلك الذي يضع مبادئ عامة لتطوير البرمجيات. وقد ظهر هذا البيان نتيجة حيرة سببها أسلوب الشلال التقليدي "Waterfall process" الذي كانت تُجهَّز فيه كل المتطلبات دفعة واحدة مقدَّمًا، وترسم التصاميم وتُعتَمد ثم تُختَبر، وكل ذلك بأسلوب خطي (Linear). وقد كان ذلك أسلوبًا عقيمًا ومرهقًا وغير فعّال لتطوير البرامج. ثم اجتمع بعض المطورين في فبراير من 2001 بعد أن سئموا هذا الأسلوب وخرجوا بشيء أفضل، وهو أسلوب Agile لتطوير البرمجيات -حيث agile تعني مرن-، وكتبوا بيانًا يضعون فيه المبادئ العامة لهذا المنظور الجديد من أجل نشره في وسط المبرمجين: وقد ألهمني بيان Agile فوضعت بياني الخاص حول تجربة المستخدم كي أنشر ما أظنها بعض المبادئ المهمة في تجربة الاستخدام، وأنا أسوقها إليك فيما يلي. التعاون عوضًا عن العمل في صوامع كتبت فيما مضى عن كيف أن تجربة المستخدم تشبه الرياضة الجماعية، ويجب أن يُنظر إليها هكذا، ذلك أن التعاون مفتاح لتصميم تجربة مستخدم رائعة، سواء كان تعاونًا مع مصممين آخرين أو مطورين أو خبراء في النطاقات (domains) أو المستخدمين أنفسهم أو حاملي الأسهم في الشركة، …إلخ. ولأن تجربة المستخدم هي المساحة المشتركة بين كل من حاجة المستخدم وقيود التقنية وأهداف الشركة، فلا يمكن أن تكون أي شيء غير مجهود جماعي، أما البديل فيشبه أسلوب "اقذفها من فوق السور" الذي لا زالت بعض شركات التصميم تستخدمه للأسف. إذ يجلس بعض المصممين في برجهم العاجي ليخرجوا ببعض التصاميم التي "تبدو" رائعة ثم يلقونها من برجهم ذاك إلى فريق التطوير كي يعتمدها، وقد ركّزت على كلمة "تبدو” لأن تلك التصاميم لا تجتاز قنطرة الفحص والمراجعة لأنها بُنيَت على افتراضات فقط. ثم يأتي حملة الأسهم ليشتكوا أن أحدًا لم يستشرهم في تلك التصميمات، ويشتكي فريق التطوير أن التصميمات يستحيل تطبيقها واعتمادها، ويجد المستخدمون أنفسهم في النهاية أمام تصميم لا يحل مشكلتهم أو يلبي حاجاتهم. النماذج الأولية التفاعلية، عوضًا عن التوثيق الثابت إنني أكره كتابة التوثيق لأنه نشاط ممل يدمّر نفسيتي في كل مرة، ولا أحد يقرؤها في النهاية، ويجب أن تُحدَّث كلما تغير التصميمات أو المتطلبات، ومن الصعب أن تكتب التوثيق بدرجة تفصيل مناسبة، فالإسهاب أكثر من اللازم يجعل المطورين يهربون من قراءته، وكذلك الإيجاز أكثر من اللازم يجعلهم يكثرون من الأسئلة حتى لَتَعجَبَ من جدوى التوثيق أصلًا. من أجل ذلك فإني أفضّل النماذج الأولية التفاعلية، فهي أفضل طريقة لعرض التصاميم ومتطلباتها لأنها تظهر كيف ستعمل التصميمات في سياقها، أو على الأقل في سياق افتراضي، فبدلًا من توثيق مرهق عن ماذا سيحدث حين ينقر المستخدم على هذا أو ذاك، يمكنك ببساطة أن تعرض ذلك الحدث كتفاعل في النموذج الأولي. ويحب المطورون النماذج الأولية لأنها تريهم كيف سيعمل التصميم، ويحبها حملة الأسهم لأنها تريهم التصميم حيًا يتحرك أمامهم، وكذلك فإن من يختبر التصميمات يحبونها أيضًا لأنها تريهم كيف يعمل التصميم وكيف سيبدو في النهاية. والأهم من هذا كله أن النماذج الأولية مهمة لجمع الملاحظات من المستخدمين من خلال جعلهم يتفاعلون مباشرة مع التصميم. وقد صار من السهل جدًا هذه الأيام أن تنشئ تصميمات تفاعلية بسرعة بسبب كثرة الأدوات التي تقوم بهذا والتي زادت في السوق مؤخرًا. يمكنك إنشاء نموذجًا أوليًا بسرعة وبسهولة باستخدام برنامج مثل Axure. التصميم للمستخدمين عوضًا عن التصميم لحملة الأسهم إن مصطلح UX يختصر كلمتي User eXperience واللتان تترجمان إلى "تجربة المستخدم"، لطالما تساءلت لماذا كانت X وليس E من الكلمة الثانية، لعلها تبدو أجمل هكذا، المهم أني أريدك أن تذكّر نفسك بمعنى هذا الاختصار في كل مرة يأتيك أحد حملة الأسهم ليحاول التحكم في مسار أو شكل تصميم ما. ذلك أنك تصمم للمستخدم بالنهاية، وليس لحملة الأسهم، ولو كان حملة الأسهم هم من يدفعون المال لهذا التصميم كي يخرج إلى النور فإن المستخدمين هم في النهاية من يحكمون على نجاح أو فشل التصميم وليس حملة الأسهم. فالتصميم الرائع لتجربة المستخدم يدور حول العثور على نقطة وسط بين حاجات المستخدم وقيود التقنية وأهداف الشركة. فلا شك أن حملة الأسهم لن يفكروا في أي شيء سوى المال، وكذلك الفِرَق التقنية لن تفكر في أي شيء سوى قيود التقنيات التي يستخدمونها، فيؤول الأمر في النهاية إلى تجربة الاستخدام ومن يختبرها كي يعتنوا بالمستخدمين من خلال التفكير في حاجاتهم وتلبيتها. ما يحتاجه المستخدمون، عوضًا عما يريدونه إنني والد لطفلين صغيرين، وأنا أعلم -كأي أب- أن ما يريده الأطفال يختلف تمامًا عما يحتاجونه حقًا، فلو أني تركتهم لما يريدون لقضوا أغلب النهار في مشاهدة التلفاز وهم يأكلون الشوكولاتة والكعك والمثلجات. وكذلك فإن مهمة معرفة حاجات المستخدم تقع على عاتق المصممين وليس المستخدمين أنفسهم، ويدعم ستيف جوبز -أحد مؤسسي Apple- هذا الكلام بقولته المشهورة "ليست مهمة المستخدمين أن يعرفوا ما يريدون". وقد كتبت من قبل عن كيف أن المستخدم ليس دائمًا على حق، فلا يمكنك أن تعرف ما يحتاجونه بمجرد سؤالهم، بل عليك أن تفهمهم وتفهم مشاكلهم وأهدافهم، وسبب حيرتهم، ودوافعهم، والمهام التي يريدون تنفيذها. صحيح أن بإمكانك سؤالهم وإشراكهم في كل خطوة من عملية التصميم، لكن لا تتوقع أن يقوموا بعملك بدلًا عنك. ما يفعله المستخدمون عوضًا عما يقولونه لقد راقبت عن كثب مئاتٍ من جلسات اختبار سهولة الاستخدام عبر السنوات الماضية، قضيت فيها ساعات تلو ساعات أشاهد فيها الناس تستخدم تقنيات من هنا وهناك، وقد وجدت نمطًا يتكرر في كل تلك الجلسات، وهو أن ما يقوله المستخدمون يختلف تمامًا عما فعلوه. إليك مثالًا لتوضيح قصدي: أنا: كيف وجدت هذا المنتج من حيث سهولة استخدامه؟ المشارِك: أوه، لقد كان سهلًا، لم أعاني أية مشكلة في استخدامه. أنا: حقًا؟ لم تختبر أية مشكلة؟ المشارِك: لا. أنا: فماذا عن المهام الثلاثة التي لم تستطع إتمامها، أو تلك النافذة التي قلتَ أنَّ من صممها غبي؟ المشارِك: آه صحيح! .. لكن بخلاف ذلك، لقد وجدته سهل الاستخدام. قد يستحي المشاركون من الاعتراف أن منتجًا ما صعب الاستخدام، أو أنهم يرفضون الاعتراف أن هم اضطروا لتنفيذ الأمر بطريقة ملتوية، بل إنهم حتى قد لا يتذكروا أنهم واجهوا مشاكل أصلًا، إذ تخبرنا قاعدة peak-end أننا نميل إلى تذكّر لقطات سريعة من أي تجربة، فحين يخبرك أحدهم أنه وجد س أو ص سهل الاستخدام رغم أنك راقبته ووجدت الأمر خلاف ذلك، فاعلم أنَّه لا يحاول خداعك، بل في الغالب يعني ما يقول. فما أريد قوله هو أن المهم هو ما يفعله المستخدمون حقًا، وليس ما يقولونه، سواء كان ذلك في تجربة استخدام أو مراقبة مستخدمين أو جمع بيانات استخدام أو حتى سؤال أحدهم أن يصف مهمة أو وظيفة يقوم بها. ملاحظات المستخدمين، عوضًا عن الافتراضات لقد كتبت من قبل "لماذا يجب أن يقوم المصممون بدراسات، ولماذا يجب أن يصمم الباحثون"، فدراسة المستخدم (User Research) وملاحظات المستخدم (User Insights) التي تخرج من دراسة جيدة للمستخدمين هي حجر الزاوية في تصميم تجربة استخدام ناجحة. أما بدون هذه الملاحظات التي تجمعها من المستخدمين فإنك تصمم بناءً على افتراضات، وتخيل معي أنك تصمم منزلًا مثلًا على أساسات هشّة ثم لا يلبث أن ينهار ويخرّ متهدّمًا، فكذلك التصميم بناءً على افتراضات غير واقعية. لكن لا أريدك أن تسيء فهمي، فالافتراضات ليست سيئة في ذاتها، فوضع افتراضات والعمل عليها ثم تقييمها وتعديلها خلال سير العمل فيما بعد قد يسرّع عملية التصميم -طالما أنك تقيّمها فعلًا--. لكن يجب أن تكون ملاحظات المستخدمين هي ما تقود تصميماتك، وليس الافتراضات، فكما قال جوبز "كلما زاد فهمك للتجارب البشرية، كانت تصميماتك أفضل". الواقعية عوضًا عن مثالية التصميم المرتكز حول المستخدم لقد قدّمت عرضًا قبل بضع سنين بعنوان يقول "كيف تخلصت من عادة التصميم حول المستخدم وتعلمت أن أحب التصميم الرشيق لتجربة الاستخدام" في UX Cambridge. وقد تحدثت حول تجربتي مع التصميم المرتكز حول المستخدم (User-Centered Design) وكيف بدأت في اعتماد عقيدة جديدة هي التصميم الرشيق لتجربة المستخدم. فكما ترى فإن لي علاقة حب وكراهية معًا مع هذا التصميم، فأنا أحب فكرة وضع المستخدمين في قلب عملية التصميم، لكني أكره حقيقة أن مشاريع ذلك النوع من التصميم لا تبتعد عادة عن مؤشر الصفر، أو تكون بطيئة ومكلّفة، ولا تقدّم ما وعدت به في البداية. فأظن أن بعض ذلك سببه أننا -مصممي تجربة المستخدم- نميل عادة إلى المثالية حين نعمل في مثل هذه المشاريع، فربما يقول أحدنا "نحن نحتاج على الأقل إلى 12 مستخدمًا قبل أن نفكر في اعتماد التصميم" أو "نحن نحتاج إلى ميزانية كذا وكذا لأعمال دراسات المستخدمين وحدها!". وصحيح أني معجب بالتصميم الرشيق لتجربة المستخدم لكني أريده أن يكون عمليًا فهذا أهم عندي، وقد ذكرت في كلمتي التي ألقيْتها مثلًا عن صيغة mp3، فالشخص المثالي هنا سيكون ذلك الذي لن يتردد في شراء نظام Hi-Fi رغم ثمنه الباهظ، وستجده يتحدث عن مساوئ مشغلات mp3، وكيف أن جودة الصوت منها رديئة وباهتة وصناعية. لكن بالنسبة لنا -باقي المستخدمين لهذه التقنية- فإن الاستماع إلى ملفات بهذه الصيغة عبر سماعات الأذن العادية التي يكون صوتها غير نقي غالبًا، أو حتى عبر مكبرات صوت عادية، أكثر من كافٍ طالما أنه يؤدي الغرض، ناهيك أننا نستمع إلى تلك الملفات في أماكن مزدحمة غالبًا وبها ضجيج أو ضوضاء، فهذه جودة أكثر من جيدة في الواقع. ألن يكون أفضل أن يكون لديك صيغة تعطيك صوتًا أفضل وأغنى بالتفاصيل والطبقات؟ بالتأكيد! لكن من المنظور العملي (pragmatic)، فإن الجودة التي تعطيها صيغة mp3 ممتازة في 99% من الحالات. والشاهد من مثالي الطويل هذا أنك يجب أن تطبّق نفس المبدأ في التصميم المرتكز حول المستخدم، فلا تبذل أكثر من الجهد الذي يخرج معك نتائج مشابهة للتي كان التصميم المرتكز حول المستخدم ليُخرجها، فقط، ولا تزد على ذلك. فلا تخشى تعديل دراسات أسلوبك في دراسات تجربة الاستخدام وأعمال التصميم، فذلك خيرٌ من أن تكون مثاليًا. خاتمة ها قد انتهيت من بياني لتجربة المستخدم، ألخصه لك فيما يلي: التعاون عوضًا عن العمل في صوامع. النماذج الأولية التفاعلية، عوضًا عن التوثيق الثابت. التصميم للمستخدمين عوضًا عن التصميم لحملة الأسهم. ما يحتاجه المستخدمون، عوضًا عما يريدونه. ما يفعله المستخدمون عوضًا عما يقولونه. ملاحظات المستخدمين، عوضًا عن الافتراضات. الواقعية عوضًا عن مثالية التصميم المرتكز حول المستخدم. وأنا أريد الآن أن أسمع منك، فماذا ترى؟ وما هي القواعد التي تريدها في "بيانك" الخاص بك؟ ملاحظة: “ … وأعلم أن هناك قيمة في العناصر على اليمين، لكني أقدّر العناصر على اليسار أكثر". ترجمة -بتصرف- لمقال A UX manifesto لصاحبه Neil Turner

هناك العديد من شركات تطوير صفحات الويب التي تستخدم أُطُر تصميم مواد حصرية لمشاريع تطوير صفحات الويب وتطبيقات الهواتف المحمولة الخاصة بتجربة المستخدم UX أو واجهة المستخدم UI. وبما أنّ أُطُر تصميم المواد هي مصادر مفتوحة، فإنها توفر أُطُر ومكونات واجهة مستخدم مصممة مسبقًا تساعد في تطوير تطبيقات مخصصة للهاتف المحمول وصفحات الإنترنت. تم إطلاق مفهوم إطار تصميم المواد من قِبَل جوجل في عام 2014. وقد تم استخدامه في البداية لتحسين تصاميم تطبيقات آندرويد، وتطبيقات الويب، ونظام تشغيل Chrome، وتطبيقات iOS وما إلى ذلك. وساعد الإطار كثيرًا في إنشاء واجهات سهلة الاستخدام للتطبيقات التي تمكّن المستخدمين من فهمها واستخدامها بسهولة. تقدّم العديد من أطر تصميم المواد الحديثة، واجهات مفيدة ومكونات أخرى مثل الأيقونات، والأزرار، ومربعات الاختيار، والألوان، والخطوط، وغيرها. تساعد هذه العناصر في تطوير تطبيقات مبتكرة للغاية وسهلة الاستخدام لجميع مشاريع التطبيقات القائمة على صفحات الويب والهواتف المحمولة. إضافةً إلى أنّ الأُطُر توفر مرونة لإجراء التغييرات اللازمة في التطبيقات وتعزيز نهجها سهل الاستخدام للعميل. ومع ذلك، فقد قامت أُطُر تصميم المواد بتحديث طريقة عمل تصميم التطبيقات واقتراح السُبُل المناسبة للمطورين لإكمال مشاريع تطبيقات صفحات الويب والهواتف المحمولة بنجاح. لنستكشف بعض أُطُر تصميم المواد المطلوبة بشدةّ والتي يستخدمها المطورون بشكل متكرر في مشاريعهم، مثل: Material UI هذا إطار عمل CSS، ويتضمن مجموعة من مكونات واجهة المستخدم المفيدة التي تستخدم تصاميم المواد من جوجل. إنّها مجموعة من العديد من العناصر سهلة الاستخدام مثل مفاتيح التحويل، ومربعات الحوار، وأشرطة الأدوات، والقوائم المنسدلة، وخانات الاختيار، وما إلى ذلك. يمكنك استخدام هذه الواجهات في تطبيقاتك ويمكنك جعلها سهلة الاستخدام للعميل. Ionic Material هذا إطار متقدم، يُستخدم على نطاق واسع لتطوير التطبيقات الهجينة في HTML5. يمكن للمطورين الذين يعملون على إطار عمل Ionic، استخدام هذا التصميم لإنشاء تطبيقات سهلة الاستخدام لمشروع العميل المرتكز على صفحات الويب. Materialize هذا إطار متجاوب بالكامل، يستند إلى دليل تصميم المواد (material design) من جوجل. ويوفر مجموعة من مكونات CSS مثل grid، و table، و color، و shadow وغيرها. علاوةً على ذلك، يستخدم أيضًا مكونات الـ JavaScript مثل القائمة المنسدلة، ومربعات الحوار، واختلاف الموضع، وعلامات التبويب، والانتقال وغيرها. Leaf إنه إطار حديث لتصميم المواد القائمة على CSS وفقًا لمعايير جوجل. يوفر هذا الإطار مكونات مفيدة ومتنوعة لإضافتها في التطبيقات مثل الأزرار والصور، والقوائم المنسدلة، والرموز، والشبكة، والألوان وغيرها الكثير. Angular Material سيساعدك استخدام إطار تصميم المواد هذا على جعل مكونات واجهة المستخدم قابلة لإعادة الاستخدام ويسهل الوصول إليها من المعرض. تتوفر جميع عناصر تصميم المواد في هذا الإطار، كموجهات Angular وخدمات يمكن تخصيصها بناءً على المتطلبات. MUI هو إطار مجاني مفتوح المصدر ولا يزال قيد التطوير. يتيح لك تخصيص تصميم التطبيق عن طريق تغيير لونه، وخطه، ونقطة توقفه وغيرها. Bootstrap Material Design هذا إطار عمل للجودة يعتمد على السمات ويوفر 740 أيقونة مفيدة لتصميم المواد التي يمكن استخدامها لمشاريع تطوير تطبيقات صفحات الويب والهاتف المحمول. يمكنك أيضًا العثور على هذه الرموز في معرض تصميم المواد من جوجل. Lum X هذا إطار آخر مفيد لتصميم المواد لمحبي Angular. إنه إطار متجاوب بالكامل، تم تطويره باستخدام أساس jQuery ويوفر أداء أفضل في مشاريع التطبيقات القائمة على صفحات الويب. Polymer يعتمد هذا الإطار على مكونات صفحات الويب التي يمكن تخصيصها أيضًا وفقًا للمتطلبات. يوفر Polymer دعمًا أفضل لجميع المتصفحات الحديثة مثل Firefox و Safari و Chrome وما إلى ذلك. سيساعدك هذا الإطار في استخدام مكونات صفحات الويب بطريقة مخصصة ويمكن الوصول إليها من خلال جميع المتصفحات. Paper إنّه سمة مخصصة تنفذ تصميم المواد باستخدام المواد الأولية، والأيقونات والخطوط من جوجل. يمكّن هذا الإطار من تطوير أنماط تصميم مواد مخصصة جاهزة للاستخدام ويمكن تعديلها وفقًا للمتطلبات. الخلاصة لتطوير تطبيقات الويب وتطبيقات هاتف محمول سهلة الاستخدام وإبداعية، يمكنك استخدام أُطُر تصميم مواد واجهة المستخدم وتجربة المستخدم الأنسب لك والتي اقترحتها جوجل. توفر هذه الأُطُر العديد من المكونات المفيدة لتنفيذها في التطبيقات وإنشاء تطبيقات فعّالة للغاية للعميل. ترجمة – وبتصرف – للمقال Best Material Design Frameworks for Modern UX/UI Web Design لصاحبه Tom Hardy

إن السعي إلى إنشاء برامج خالية من الأخطاء في العالم الرقمي هو أمر جدير بالاهتمام. ولكن في حال وجدت هذه الأخطاء، فليس من الضروري أن تتسبب في مشكلة، إذ يمكن أن نقابل نتائج غير مرضية أو أقل من المتوقع للموقع أو التطبيق. بمعنى آخر، لا تكمن المشكلة غالبًا في الشيفرة بل في تصميم واجهة المستخدم (UI) أو تجربة المستخدم (UX) أو كليهما. يمكن للأدوات والموارد المطروحة هنا أن توفر لك الوقت والمال وتساعدك في تجنب مشكلات ناتجة عن قابلية الاستخدام (usability issues) عند استخدام المواقع والتطبيقات الخاصة بك. تعدُّ هذه الأدوات الأفضل في مجالها، إذ اخترناها بعناية من بين العديد من الخيارات المتوافرة. هل أنت جاهز؟ لنبدأ رحلة التعرف عليها. 1. Mason من الأمور البديهية في عالم تصميم وتطوير البرمجيات هو أن الحاجة إلى إجراء تغيير بسيط في منتج سبق نشره سيسبب في حدوث إشكاليات كبيرة في التخطيط والتنفيذ عدا عن النفقات غير المتوقعة وغير المخطط لها. لذلك، من الضروري أن تحمل الفرق على عاتقها مسؤولية تصميم التغيير، والذي يتم غالبًا من خلال استخدام أسلوب النموذج الأولي (prototyping approach) واختباره وبرمجته ثم الانتظار لحين دورة النشر القادمة لتثبيته واعتماده. وأثناء ذلك، لن يتمكن العميل أو المستخدم النهائي من فعل شيء سوى أن يتنتظر. لكن مع Mason، الأمر مختلف؛ فهو يقدم منصة مرئية مدعمَّة بأدوات بناء الواجهة الأمامية مما يوفر للفِرق بيئة عمل مشتركة وسريعة لإضافة الميزات للتطبيقات أو المنتجات الرقمية الأخرى المطلقة (أو المنشورة)، حيث يمكن بسهولة بناء تلك الميزات دون الحاجة إلى النماذج الأولية، أو الإطارات الشبكية، أو فحص ضمان الجودة (QA inspection). كذلك لا حاجة إلى البرمجة أيضًا نظرًا لأنَّ Mason ينشئ قاعدة بيانات خاصة به لإضافتها إلى قاعدة بيانات موجودة مسبقًا، مما يتيح للمطورين العمل في مشاريع برمجية أكبر وأكثر تعقيدًا. إن التطور السريع والقدرة الفائقة لـ Mason جعلت العملاء يشعرون بمزيد من الرضا والسعادة. يتم تشغيل Mason عند الحاجة دون أن يؤثر تشغيله على سرعة موقعك، وستظل الميزات التي تنشئها دائمًا موثوقة وقوية وقابلة للتوسيع والتطوير. 2. UXPin يوجد نماذج أولية مخصصة بالأساس لأغراض معينة ويوجد ونماذج أخرى تفاعلية، وواقعية، وقوية تثير لديك السؤال التالي: لماذا لا يمكن تجاهل مرحلة التطوير برمتها؟ تلك هي درجة الواقعية التي يمكن للمستخدم توقعها من الأداة UXPin. وذلك بفضل أنها أدة تصميم تعتمد على الشيفرة. تعرض UXPin حلولًا قريبة من رغبة المستخدم، فربط اللوحات الفنية الثابتة معًا لم يعد متواجدًا في وقتنا الحالي. هذه الأداة هي بمثابة الحلم الذي تحقق للمصمم. لماذا؟ لأنها تسهل عليه التصميم، وإنتاج النموذج الأولي، والتعاون مع مصممين آخرين في مكان واحد وآنيًّا. إبدأ بفكرة إثبات مفهوم الإطارات الشبكية، ثم تدرج في العمل نحو النماذج منخفضة الدقة إلى النماذج عالية الدقة. أنجز كل شيء آنيًّا دون الحاجة إلى ترك ومغادرة UXPin. تعد أداة تصميم واجهة وتجربة المستخدم UX/UI المعتمدة على السحابة أداةً ثابتةً ومفضلة لدى شركات 500 Fortune كشركة PayPal و Microsoft وذلك بفضل امكانياتها الهائلة في تصميم النماذج الأولية. فهي تتضمن العديد من الخصائص مثل: حالات التفاعل، والشرط المنطقي، والمتغيرات، ومكونات الشيفرة، وتعابير JavaScript وغيرها. ناهيك عن الطريقة التي تعزز وتبسط بها تعاون الفريق. 3. Interfacer متى كانت آخر مرة اضطررت فيها إلى إجراء بحث موسع للعثور بسهولة على أنسب خط، أو أيقونة، أو صورة، أو مجموعة أدوات واجهة المستخدم UI؟ سواء كان ذلك بالأمس القريب أو قبل عام، فمن المحتمل أنك تتذكره وتتذكر كم كان ذلك مضيعة للوقت! إن Interfacer هي عبارة عن مجموعة من المكتبات المصغرة المليئة بأدوات تصميم عالية الجودة من جميع الأنواع. كل ما يتم تقديمه ليس مجانيًا فحسب، ولكنه مجاني للاستخدام في المنتجات التجارية أيضًا. 4. Webflow من الأهمية بمكان أن تبحث عن منتج يتيح لك تصميم وتطبيق وإنشاء وإطلاق واستضافة موقع سريع الاستجابة من خلال منصة واحدة؛ وهذا تماما ما تقوم به الأداة Webflow. يمكنك من خلال تلك الأداة متعددة الامكانيات القيام بجميع ما سبق ذكره، بما في ذلك إنشاء نظام إدارة محتوى CMS سهل الاستخدام لكل موقع تقوم بإنشائه، دون الحاجة إلى برمجته. يمكنك كذلك بدء المشروع من واجهة فارغة أو باستخدام أحد القوالب المتوافرة أو مجموعة أدوات واجهة المستخدم UI المقدمة من قبل المجتمع. لماذا من المهم أن تختار واحدة أو أكثر من بين تلك الأدوات أو الموارد؟ التصميم الجيد لتجربة المستخدم UX يزيد من نسبة العثور على الموقع واستعماله وتفوقه على منافسيه. ربما صادفت أكثر من مرة وأنت تتصفح الويب بحثًا عن خدمة أو منتج معين ظهور عدة مواقع أخرى تخدم نفس الغرض في وجهك مباشرة؛ إذن، ما السبب في ظهور تلك المواقع؟ السبب هو تجربة المستخدم UX المتميزة التي تسهل استخدامك للموقع وكذلك تساعدك على العثور على ما تريده بسرعة ودون عناء. بعد أن تنجز ما أردته، يمكنك وضع إشارة مرجعية على الموقع لتتمكن من استخدامه في المستقبل. أليس من الرائع أن تكون مالكاً لذلك الموقع؟ التركيز على تصميم تجربة المستخدم UX يمكن أن يزيد من إخلاص العملاء للعلامة التجارية. إن التصميم الفريد والفعال لتجربة المستخدم UX يأخذك في رحلة فريدة وممتعة، إذ أنه يزيد من ثقة وإخلاص العملاء والمستخدمين لعلامتك التجارية أو لمنتجك أو الخدمة التي تقدمها. تعد تجربة المستخدم UX يستخدمها المصمم ليسهِّل على المستخدم عثوره على ما يريد أو إيصاله للمكان الذي يطلبه دون عناء بالإضافة إلى توفير أجواء ممتعة له خلال التصفح. صمم تجربة مستخدم UX تذهل العقول وتجعل كل من استعمل الموقع أو التطبيق يتحدث عنها. كيف يمكنك تحقيق ذلك؟ ببساطة من خلال تصميم تجربة المستخدم UX بشكل يسهل على المستخدمين التصفح بمرونة. فتزيد لديهم الرغبة بمشاركة خبراتهم مع الآخرين. والنتيجة؟ ستكون سلسة عملاء متنقلين يمدحون بك ويسهون في إذاعه صيتك، وهؤلاء العملاء من يقاتل الجميع حتى الموت لكسبهم. خاتمة ما الذي تحاول تحقيقه؟ توفير الوقت والمال وضمان توفير التحسيان دون الحاجة إلى النماذج الأولية؟ توفير الوقت والمال على المدى الطويل باستخدام أسلوب النماذج الأولية التكرارية أو السريعة؟ استخدام منصة واحدة فقط لإنجاز جميع الأعمال؟ البحث عن مصدر واحد يجمع أدوات تصميم مساعدة عالية الجودة (مثل الخطوط والصور والأيقونات ...إلخ.) تبقى متاحة عند الحاجة إليها؟ الأدوات والخيارات التي ذكرناها آنفًا توفر وتتيح لك ذلك بالإضافة إلى تحسين تصميم واجهة وتجربة المستخدم UI/UX. يمكنك اختيار واحدة منها، أو جميعها، ومن المؤكد أنك ستصل إلى نتائج جيدة باستعمالها. ترجمة -وبتصرف- للمقال Need help choosing a UX/UI tool? Check out these options

ربّما تكون شاشات اللّمس أحد الأسباب التي جعلت الأجهزة الجوّالة ذات شعبيّة كبيرة جدّا. تحذف شاشات اللمس المسافة بين الشخص والجهاز التفاعليّ، ونتيجةً لذلك، يحسّ الأشخاص بأنّ شاشات اللمس بديهيّة وسهلة الاستخدام. لهذا السبب، يمكن إدماج المنزلقات (Sliders) بسهولة في الأجهزة الجوّالة. تشجّع المنزلقات المستخدمين على استكشاف محتوى موقع بسهولة عن طريق إجراء حركات أفقيّة على الشاشة. رغم ذلك، فإنّ المنزلقات خيار قليل الاستخدام للتصفّح على الجوّال. تقدّم المنزلقات خيّار تصفّح رائعًا للمواقع والتطبيقات التي لديها عناصر قليلة لاستكشافها. تبدو المنزلقات طبيعيّة للمستخدمين، وتوفّر طريقة مرحة لتعديل الإعدادات أو استكشاف الميزات. يسهُل على الزوّار التعرّف على المنزلقات، ممّا يجعلها سهلة الاستخدام؛ وبالتالي، خيّارًا عمليًّا جدًّا ليستغلّه المصمّمون. ما لذي تصلُح له المنزلقات المنزلقات سهلة الفهم والاستكشاف، وهو ما يجعلها بديهيّة. تمثّل المنزلقات - نظرًا لكونها لا تأخذ مساحة كبيرة - خيّارًا جيّدًا في الأجهزة التي تستخدم شاشات لمس، التي هي شاشات صغيرة. كما أنّ المنزلقات مناسبة لما تمثّله من إضافة لتصميم واجهات المستخدم. تساعد المنزلقات المستخدمين في التحرّك جيئة وذهابًا، أو زيّادة السرعة أو الصوت، وتمنح حسَّا نسبيًّا للأنشطة (جعل مستوى الصوت أرفع ممّا هو عليه الآن). مصاعب عند استخدام المنزلقات النظر إلى التصميم من زاويّة المستخدم أمر مهمّ في سبيل التأكد من قابليّة الاستخدام (Usability). مستخدمو الجوّال – في الغالب – مستعجِلون أو مشتّتو الانتباه عند استخدام أجهزتهم. يمكن أنْ يستخدموا أجهزتهم وهم يتجوّلون في مركز تسوّق، أو يتناولون الطعام، أو يتنزهون في الحديقة. عندما يمرّ المستخدمون على منزلق، فهم يفعلون ذلك في الغالب مشتّتي الانتباه أو مستعجِلين. يعني هذا غالبًا دفع المنزلق كثيرًا إلى أحد الجانبيْن أثناء محاولة إبعاد أصابعهم عن الشاشة. يمكن أن تكون المنزلقات كذلك صعبة الاستخدام بالنسبة للأشخاص الذين لديهم صعوبات حركيّة. قد يكون من الصعب جعل المنزلق يعمل بالطريقة التي تفضّل أن يعمل بها إذا تلقّى ضغطًا زائدًا قليلًا على الشاشة. قد تكون المنزلقات كذلك صعبة الاستخدام بالنسبة للمستخدمين المتقدّمين في السنّ الذين ترتعش أيديهم؛ وهو ما يجعل ضمان نتيجة محدّدة صعبًا أثناء استخدام المنزلق. ربّما يفقد المستخدمون في مثل هذه الحالات الأمل في إمكانيّة تصفّح الموقع. ضع الجمهور المستهدَف من الموقع بالحسبان. إنْ كنت تستهدف زوّارًا متقدّمين في السن، أو أشخاصًا لديهم صعوبات حركيّة أو صحيّة، فلن يكون المنزلق خيّارك الأمثل. فكّر في مشاكل قابليّة الاستخدام بعد التأكّد من ملاءمة استخدام المنزلقات لجمهورك المستهدَف، يأتي الوقت للتفكير في قابليّة استخدام التصميم. يعتمد مستخدمو شاشات اللمس – غالبًا – الأصابع عند العمل على أجهزتهم. بما أنّك تريد أن يكون تصميمك قابلًا للاستخدام، فمن المهمّ استكشاف أماكن شاشة اللمس التي سيشغلها الأصبع أو اليد عند استخدام الجهاز الجوّال. سيساعد ذلك في وضع المنزلق بحيث يمكن استخدامه والتعامل معه. يختلف التصميم لسطح المكتب، حيث تُستخدَم الفأرة لتحريك المنزلق، عن الأجهزة بشاشات لمس. يجب أن تسعى في حالة شاشة لمس إلى التقليل من إمكانيّة الخطأ، أو الضغط على روابط أخرى، أو تغطيّة التعليمات أثناء وضع المستخدمين أصابعهم على الشاشة. يجب أن تظهر جميع اللافتات (Labels) والقيّم التي تفسّر المنزلق بجانب أصابع المستخدم وزرّ التمرير، أو فوقهما. استخدم المنزلقات لترك انطباع بصريّ واضح يفيد غالبًا استخدام المنزلق لتقديم متتاليّة من الصوّر البصريّة للمستخدمين إذا كان لديك محتوى مهمّ لعرضه، ولكنّ به معلومات كثيرة جدًّا، يصعُب استكشافها أو استيعابها على زوّار الموقع. على سبيل المثال، إنْ رغبت في عرض سلسلة من الأحداث التي يمكن للمستخدم متابعتها بهدف شراء منتَج من موقع تجارة إلكترونيّة، فإنّ مجموعةَ صوّر واضحة تقود المستخدم عبر خطوات متتاليّة يمكن أن تكون مفيدة ولا تتطلّب الكثير من العمل. تقتصد الطريقة السابقة أعلاه من وقت الزائر وتجعل الموقع سهل التصفّح. يمكن استخدام هذه العمليّة في حالات كثرة لمساعدة المستخدم في تصفّح موقع أو تطبيق للجوّال. أنواع المنزلقات التي يمكنك استخدامها توجد أنواع عدّة يمكن استخدامها عند تصميم موقع أو تطبيق: المنزلقات المنفردة (Single sliders): مناسبة للعمل مع قيمة وحيدة في كلّ مرة. المنزلقات المزدوجة (Double sliders): مناسبة للعمل مع مجال من القيم (مثلًا، منزلق للقيمة الدنيا وآخر للقيمة القُصوى). المنزلقات المتواصلة (Continuous sliders): تسمح المنزلقات المتواصلة بتحديد موقع نسبي على مجال مُحدَّد بقيمتين دنيا وقُصوى. المنزلقات المتقطّعة (Discrete sliders): تتميّز بنقاط توقّف يمكن للمستخدم استعمالها لإعطاء قيمة دقيقة. الدقة أم التخمين؟ قد يكون صعبًا أو معقّدًا بالنسبة للزائر استخدامُ منزلق بصورة دقيقة. يتأكّد هذا الأمر على شاشات اللمس. من الصعب جدًّا الحصول على الدقّة في التحديد إذا كنت أمام مؤشّر تمرير صغير على شاشة لمس. يكون استخدام المنزلقات – غالبًا – أسهل عندما لا تكون دقّة القيمة المُختارة مهمّة. إنْ كان المستخدم يستطيع استخدام المنزلق لمشاركة قيمة تقريبيّة، فسيكون ذلك – غالبا – كافيّا. مالعمل إنْ احتجت لقيمة دقيقة؟ يمكن إنشاء منزلق بقيم عدديّة قابلة للتعديل إذا كان من اللازم على المستخدم إدخال قيمة مضبوطة. يعني هذا أنّه سيكون باستطاعة المستخدم لمس المنزلق ثم إدخال عدد في صندوق نصّيّ. يمكن أن يُصبح الصندوق قابلًا للتعديل كلّ ما لمس الأصبعُ المنزلق. رغم ذلك، إنْ كانت واجهة المستخدم تتطلّب قيمة دقيقة من أجل قابليّة الاستخدام، فسيكون من الأفضل عدم استخدام المنزلقات. عرض مجال قِيم تسخدم بعض المنزلقات قيمًا عدديّة بحيث يمكن للزائر تحديد اختيّارات. يمكن لتطبيق تجارة إلكترونيّة أن يوفّر مجموعة من المنتجات تبدأ أسعارها من دولار واحد، لكنّها تصل إلى 999 دولار. يكون من المفيد في هذه الحالة – غالبًا – عرضُ مجال القيّم المتوفّرة على المتجر بدقّة. تمنح هذه الطريقة المستخدم إمكانيّة إنشاء مجال مخصَّص للعناصر التي يريدون استكشافها. تتجنّب بتخصيص مجال من القيّم حصول الزائر على إجابة بمجموعة عناصر فارغة. ستوفّر مجموعة قليلة من قيّم البحث نتيجة بعناصر أقلّ، في حين يوفّر مجال بحث أوسع عناصر أكثر. على الرغم من ذلك، لن يحدّد المستخدمون مجموعةً من القيّم إلّا لسبب، ولن يزعجهم غياب مجموعة من الخيّارات لا يمكنهم دفع ثمنها. أعط للمستخدمين القدرة على استكشاف التطبيق، حتى ولو لم يكونوا يفهمون مغزى المنزلق والمجالات التي يتيحها للمستخدم. وفّر تغذيّة راجعة بصريّة للمستخدمين أضف تغذيّة راجعة بصريّة لتفاعلات المستخدمين مع المنزلق، فتلك هي طريقة العمل التي يتوقّعها المستخدم. وفّر إجابة بصريّة فوريّة للمستخدم عند استخدامه لمنزلق أو عندما يُدخل معلومات في صندوق إدخال. يمكن استخدام التحريكات (Animations)، حالات الحومان (Hover)، والتأشير فوق العناصر (Rollover) للتواصل مع المستخدم. تجذب هذه الميزات انتباه المستخدم وتخلُق بالتالي قناة اتّصال معه. مواقع الويب التفاعليّة جذّابة دائما. عندما تمدّ المستخدم بتغذيّة راجعة بصريّة فإنّه يشعُر بالتقدير، ممّا ينتُج عنه إحساس بالثقة في قدرته على تصفّح الموقع. خاتمة تبدو المنزلقات بديهيّة وسهلة الاستخدام في تطبيقات الويب؛ كما أنّها خيّار جمالي، إلّا أنّها ليست دائمًا الأداة الأفضل للاستخدام. إنْ كنت تبحث عن قيم نسبيّة، وتعلم أنّ الجمهور المستهدَف لديه قدرة حركيّة جيّدة، فإنّ المنزلقات قد تكون خيّارًا جيّدا. أمّا إذا كنت تبحث عن قيّم دقيقة، فسيكون من المفيد توفير خيّارات لإدخال تلك القيّم. اعمل، بوصفك مصمِّمًا، على إنشاء شرائط تمرير يمكن للمستخدم من خلالها اختيار مجال من القيّم يمكن استغلاله على الموقع. يساعد هذا الأمر المستخدمين الذين قد يجدون صعوبة في تحديد قيم دقيقة عند استخدام المنزلق. ترجمة – بتصرّف – للمقال How to Create a Good UI Slider in Mobile Design لصاحبه Bogdan Sandu.