عبدالرحيم فاخوري

هذا الجزء الثاني من سلسلة من جزأين تتحدث عن الحوسبة السحابيّة. نرجو أن تكون قرأت موضوع تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة قبل قراءة هذا المقال، إذ يحوي المقال السابق معلومات مهمة، وشرحًا للمصطلحات المستخدمة في هذا الموضوع. ينقسم هذا المقال إلى قسمين، يناقش القسم الأول عيوب الحوسبة السحابيّة والمشكلات التي يمكن أن تواجهها، ويعدّ مقدّمة للقسم الثاني. أما القسم الثاني، فيتحّدث عن الانتقال إلى الحوسبة السحابيّة والمزايا والعيوب وسيساعدك على تجهيز خطّة للانتقال الأمثل، بحيث تستفيد من المزايا وتتجنب المساوئ في الانتقال. مقدمة إذا كنت ترغب في تقديم خدمات رقميّة أيًّا كان نوعها، فعليك تقدير كلّ أنواع الموارد، بما في ذلك المعالج والذاكرة والتخزين والشبكة. إن اختيار أيّ الموارد ستستخدم لتقديم تلك الخدمات - سواء سحابيّة أو محليّة - عائد لك. ولكنّك ستحتاج بكل تأكيد للبحث والتخطيط. ستحتاج إلى فهم مزايا وعيوب الحوسبة السحابيّة وكيف تأخذ نقاط ضعفها في الحسبان. لقد أفادت الخدمات السحابية العديد من المؤسسات، وذلك بتقليل التكاليف، وتمكينها من التركيز على الجانب المتعلّق بالأعمال الخاصّة بها، بدلًا من القضايا المتعلّقة بتقنيّة المعلومات والبنية التحتيّة لها. وعلى الرغم من الكثرة الحديث عن أهميتها في الأوساط التقنيّة، إلّا أنّها قد لا تخلو من العيوب، وخاصّة في الأعمال الصغيرة. لدى معظم الشركات حمل واحد على الأقل يعمل في نظام حوسبة سحابية. رغم هذا، فالانتقال إلى الحوسبة السحابيّة قد لا يكون الخيار الصحيح للجميع. وعلى الرغم من أنّ البيئات السحابيّة عامّة تكون قابلة للتوسعة، ويعتمد عليها، ومتاحة دائمًا، يجب أن لا تدع هذه النواحي وحدها تقود قراراتك. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ مثل الفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش هنا العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. سنتحدث عن بعض العيوب الرئيسيّة، وسنعرض بعض النصائح والطرق السليمة لاستخدامها والتي من الممكن أن تستخدمها الفرق التقنية للتعامل مع تلك العيوب. يمكنك صياغة نمط محدّد لهذه العمليّة، وذلك باستخدام توجُّه مُفصَّل ومجهًَز مُسبقًا لفهم أمن الحوسبة السحابيّة. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ كالفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش في هذا المقال العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. توضيح عيوب الحوسبة السحابيّة 1. انقطاع الخِدمة يُعدّ انقطاع الخدمة (downtime) أحد أهمّ عيوب الحوسبة السحابيّة. بما أن أنظمة الحوسبة السحابيّة تعتمد على الإنترنت، فيحتمل حدوث انقطاع في الخدمة في أيّ وقت، ويمكن أن يحدث لأيّ سبب كان. هل يمكن لشركتك أن تتحمل انقطاع الخدمة أو بطئها؟ لقد كلّف انقطاع خدمة الحوسبة السحابيّة التابعة لأمازون (AWS) عام 2017 شركات مساهمة عامّة أكثر من 150 مليون دولار أمريكيّ. للأسف، لا توجد شركة آمنة من هذا، وخاصّة بالنسبة للأعمال الحسّاسة التي لا تتحمل أن تنقطع. في شهري حزيران وتمّوز (5 و6) من عام 2019، تعرّض عدد كبير من الشركات لانقطاع في الخدمة، بما في ذلك Cloudflare (وهو مزوّد خدمة مهمّ لمواقع الإنترنت)، وGoogle، وAmazon، وShopify، وReddit، وVerizon، وSpectrum. أفضل الممارسات لتقليل انقطاع الخدمة المخطط له في بيئة الحوسبة السحابيّة تصميم خدمات متاحة باستمرار مع أخذ الاسترجاع من الكوارث بعين الاعتبار. استفِد من ميزة تعدّد المناطق (multi-availability zones) التي يتيحها مزودو الخدمة السحابيّة في البنية التحتيّة لديك. إذا كانت خدماتك لا تتحمّل انقطاع الخدمة، فخذ بعين الاعتبار نشر خدمتك في عدّة مناطق، مع تدارك آليّ للانقطاعات لتتجنّب انقطاع الخِدمة قدر الإمكان. حدِّد ونفِّذ خطّة للاسترجاع من الكوارث تتوافق مع أهداف مؤسستك لتقليل وقت الاسترجاع من الكوارث قدر الإمكان (RTO) وأهداف نقطة الاستعادة (RPO). خذ بعين الاعتبار تنفيذ خدمة اتصال مخصّصة مثل AWS Direct Connect أو Azure ExpressRoute أو Dedicated Interconnect أو Partner Interconnect. تقدّم هذه الخدمات اتصال شبكة مخصّص بينك وبين مكان وجود الخدمة السحابيّة. يمكن أن يقلِّل هذا من العرضة إلى خطر انقطاع الخدمة المؤقت الذي قد تسببه الإنترنت. اقرأ تفاصيل اتفاقيّة الخدمة (Service Level Agreement - SLA). هل تضمن لك أن تكون الخدمة متاحة 99.9% من الوقت أو حتى أكثر من ذلك؟ هذا الانقطاع الذي يشكِّل 0.1% يساوي 45 دقيقة شهريًّا أو حوالي ثماني ساعات في العام. 2. الأمن والخصوصيّة على الرغم من إنّ مزودي الخدمة ينفذون أفضل معايير الأمن والإجراءات التي يتطلّبها المجال، إلّا أنّ تخزين البيانات والملفات المهمّة عند مزوّدي خدمة خارجيّين يفتح دائمًا المجال للمخاطرة. يجب أن تغطّي أيّ محادثة تتعلّق بالبياناتِ الأمنَ والخصوصيّةَ، وخاصّة عندما يتعلّق الأمر بإدارة البيانات الحسّاسة. يجب أن لاننسى ما حدث لـCode Space واختراق لوحة تحكّمهم على AWS، والذي أدى إلى حذف بياناتهم مما تسبب في أغلاق الشركة. إن اعتمادهم على بنية تحتيّة بعيدة معتمدة على الخدمات السحابيّة يعني المخاطرة بجعل كلّ ما يتعلّق بهم لدى شركة أخرى. إن كلّ مزود خدمة سحابيّة يتوقّع منه إدارة وتأمين البنية التحتيّة العتاديّة التي تقوم عليها الخدمة. وعلى الرغم من ذلك، تقع على عاتقك مسؤوليّة إدارة وصول المستخدمين، ولهذا عليك أن توازن بحذر كلّ حالات الخطر المحتملة. وعلى الرغم من أن الاختراقات التي كشفت معلومات بطاقات بنكيّة ومعلومات الدخول إلى حسابات على الإنترنت لا تزال جليّة في أذهان العامّة، إلّا أنه قد تم اتخاذ إجراءات لتأمين البيانات؟ ومن الأمثلة على هذه الإجراءات القانون العامّ لتأمين البيانات ( General Data Protection Rule - DGPR )، والذي تم سنّه في الاتحاد الأوروبيّ لإعطاء المستخدمين قدرة اكبر على التحكّم ببياناتهم. وعلى الرغم من ذلك، ما زلت بحاجة إلى معرفة المسؤوليات التي تقع على عاتقك، وأن تتّبع أفضل الممارسات المتعلّقة بهذا الشأن. أفضل الممارسات لتقليل مخاطر الأمن والخصوصيّة هذه النقطة مهمّة: افهم نموذج التشارك في المسؤوليّة لدى مزوّد خدمة الحوسبة السحابية الذي تتعامل معه. ستتحمل أنت مسؤولية ما يحدث في داخل شبكتك ومنتجك. نفّذ الإجراءات الأمنيّة في كلّ مستوى من مستويات خدمتك. اعرف من المفترض أن يكون لديه وصول لكل مورِد وخدمة، وقيّد الوصول قدر الإمكان. إذا خان أحد الموظفين الأمانة (أو أخطأ في أمر ما) وكان لديه وصول إلى الخدمة التي تقدّمها، فسترغب بأن تكون الأضرار في أضيق إطار ممكن. تأكّد من أنّ مهارات فريقك ترقى إلى المستوى المطلوب. إن مقال أهم عشرة أشياء يجب على المختصّين في الأمن الإلكترونيّ معرفتها ممتاز لفهم طريقة تجنب المشكلات المتعلّقة بالأمن والخصوصيّة في الحوسبة السحابيّة. اعتمد توجّها مبنيًّا على تقييم المخاطر من أجل تأمين الموارد التي في النظام السحابيّ واجعل سياسة الأمن تشمل الأجهزة. استخدم نظام استيثاق متعدد الجوانب لكل الحسابات التي تصل إلى البيانات الهامّة في النظام. عليك بالتشفير والتعميّة، ثم عليك بالتشفير والتعمية. فعّل التشفير أينما استطعت. الأهداف السهلة للّصوص هي أماكن تخزين الأشياء، وهذا ينطبق على الحوسبة السحابيّة؛ مكان تخزين البيانات مثل Amazon S3 أو Azure Blob Storage هي أماكن تخزين معلومات الزبائن، وهي هدف مهم للمخترقين. إنّ مجرّد تفعيل التشفير على S3 كان سيكفي لمنع الاختراق الذي حصل في شهر تمّوز عام 2019 - لو أنه استُخدِم - والذي كشف بيانات مئة مليون شخص. 3. التعرّض للهجوم إنّ جميع مكونات الحوسبة السحابيّة متّصلة بالإنترنت، مما يجعلها معرّضة للاختراق في حال وجود ثغرات لم يعرف عنها الفريق المسؤول عن النظام أو لم يغلقها؛ بل إنّ أفضل الفرق تعاني من هجمات واختراقات أمنيّة من وقت لآخر. وبما أنّ الحوسبة السحابيّة مبنيّة كخدمة عامّة، فستجد البعض بدأ الركض قبل أن يتعلّم المشي، إذا صحّ التعبير. فعلى أيّ حال، لا أحد من مزودي الخدمات السحابيّة يختبر مدى براعتك في إدارة النظام قبل أن يعطيك خادمًا لتديره: كل ما يُطلب منك هو أن تدفع لاستخدام الخدمة وحسب. أفضل الممارسات للمساعدة في تقليل الهجمات الإلكترونيّة على الخدمة السحابيّة اجعل الأمن محورًا مهمًا لجميع العمليات التقنيّة. ابقِ جميع الفرق التي تعمل معك على اطّلاع على كلّ ما يتعلّق بأفضل الممارسات لأمن الحوسبة السحابية أولًا بأوّل. تأكّد من تفقُّد ومراجعة السياسات والإجراءات الأمنيّة باستمرار. أمِّن سرّيّة المعلومات وقيّد الوصول إليها لتتجنب المشكلة قبل حدوثها. استخدم الخدمات السحابيّة مثل AWS Inspector، وAWS CloudWatch، وAWS CloudTrail، وAWS Config لجعل التحكّم بالالتزام تلقائيًّا. اكتشف المشاريع والاختبارات الخارجة عن أهداف المؤسسة. امنع الدخول باستخدام كلمة المرور عن الحسابات التي لا تحتاج الولوج إلى النظام. غيِّر مفاتيح الوصول وكلمات المرور باستمرار. تابع المدونات والمواقع المتعلّقة بأمن المعلومات وما تعلن عنه لتكون على دراية بالهجمات المعروفة. طبّق أفضل ممارسات الأمن للبرمجيات مفتوحة المصدر التي تستخدمها. نكرر، استخدم التشفير كلّما أمكن وأينما أمكن. ستساعد هذه الممارساتِ المؤسّسةَ على مراقبة حركة البيانات الهامّة ومدى عرضتها للمشكلات الأمنيّة، وستساعدها كذلك على حماية الأنظمة الهامّة من الهجمات والاختراقات، وعلى استيثاق الوصول إلى البنية التحتيّة والبيانات، وذلك من أجل الحماية من المخاطر الإضافيّة المحتملة. 4. الوصول المحدود والمرونة بما أنّ البنية التحتيّة المعتمدة على الحوسبة السحابيّة بأكملها مملوكة ومدارة ومراقبة من مزوّد خدمة الحوسبة السحابيّة، فهي تبقي القليل فقط من التحكّم في يد الزبون. قد يجد مستخدمو الحوسبة السحابيّة أنّ التحكمَ الذي لديهم في الوظائف والتنفيذ للخدمات في البنية التحتية المستضافة سحابيًّا محدودٌ، وذلك بدرجات متفاوتة، حسب الخدمة التي يقدّمونها. قد تقيّد اتفاقية استخدام الخدمة السحابيّة والسياسات الإداريّة ما يمكن للزبائن فعله بتطبيقاتهم. يحتفظ الزبائن بحقّ التحكّم بتطبيقاتهم وبياناتهم وخدماتهم، ولكن قد لا يكون لديهم نفس القدر من التحكم فيما يتعلّق بالبنية التحتيّة للنظام الخلفيّ وبما يجري خلف الكواليس. أفضل الممارسات لضمان قدرٍ من التحكّم والمرونة خذ بعين الاعتبار الاستفادة من شريك يقدّم خدمة الحوسبة السحابيّة ليساعدك على تنفيذ وتشغيل ودعم خدمات الحوسبة السحابيّة. افهم مسؤوليّاتك ومسؤوليّات مقدّم الخدمة السحابيّة في نموذج المسؤوليّة المشتركة، وذلك من أجل الحدّ من التنصّل من المسؤوليّة وكذلك للحدّ من الأخطاء المحتملة. خذ الوقت الكافي لفهم مستوى الدّعم الأساسيّ الذي يقدّمه مزوّد الخدمات السحابيّة الذي تتعامل معه. هل يفي هذا المستوى من الخدمة بمتطلّباتك؟ يقدّم مزودو خدمة الحوسبة السحابيّة دعمًا إضافيًّا فوق الدعم الأساسيّ مقابل تكلفة إضافيّة. تأكّد من فهمك لاتفاقيّة مستوى الخدمة (Service Level Agreement - SLA) المتعلّقة بالبنية التحتيّة والخدمات التي ستستخدمها وكيف ستؤثّر الاتفاقيّة على زبائنك. 5. البقاء عالقًا عند مزوّد معيّن من العيوب التي تُأخذ بالحُسبان عند التعامل مع الحوسبة السحابيّة هي احتمال أن تبقى عالقًا عند مزوّد خدمة سحابيّة معيّن. إن الانتقال بسهولة بين مزودي الخدمة السحابيّة لم يصل إلى المستوى المطلوب من التطور، وقد تجد المؤسسات صعوبة في نقل خدماتها من مزوّد خدمة إلى آخَر.قد تنشأ صعوبات نتيجة للاختلاف بين مزودي الخدمة مما قد يتسبب بتكاليف إضافيّة وتعقيدات في الإعداد. إنّ الفجوات التي يمكن أن يتسبب بها الانتقال من مزوّد إلى آخر من شأنها أن تؤدي إلى تعريض أمن وخصوصيّة البيانات إلى الخطر. أفضل الممارسات لتقليل الاعتماد على مزوّد الخدمة صمِّم نظامك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة. تتيح كلّ خدمات الحوسبة السحابيّة فرصًا لتحسين الإتاحة والأداء، وفصل الطبقات المختلفة، والحدّ من عنق الزجاجة في الأداء. إذا بنيت خدماتك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة، فسيقل احتمال أن تواجه مشكلات تتعلق بالانتقال من منصّة حوسبة سحابيّة إلى أخرى. افهم جيدًا ما يسوّقه لك مزودو الخدمة لتتجنّب أن تعلق عندهم. طبّق استراتيجيّة تعدد السحابات لتجنب أن تعلق عند مزود خدمة معيّن. على الرغم من أن هذا قد يتسبب بتعقيدات في كلّ من التطوير والتشغيل، إلّا أنها لن تكون بالضرورة معقدة لدرجة أن تثنيك عن ذلك. يمكن تدريب الفرق لتكون مستعدّة لهندسة واختيار أكثر التقنيات والخدمات اتساقًا مع احتياجاتك. اتبع سياسة المرونة المضمّنة عندما تصمِّم تطبيقات، وذلك من أجل جعلها قابلة للنقل في أيّ وقت. ابن تطبيقاتك مستخدمًا الخدمات التي تقدّم ميزة الاستفادة من مزايا الحوسبة السحابيّة كإحدى أولويّاتها، كأن تتكون من برمجيّات وخدمات مصغّرة ومجزّأة وقابلة للنقل. فكّر باستخدام الحاويات وKubernetes. 6. القلق من ارتفاع الكلفة يمكن أن يُنظَر إلى اعتماد حلول الحوسبة السحابيّة على نطاق ضيّق ولمشاريع قصيرة الأمد على أنّها مكلفة. رغم هذا، تنبع أهمّ فوائد الحوسبة السحابيّة من إمكانيّة خفض التكلفة. يمكن أن تقدِّم خدمات الدفع حسب الاستخدام مرونة أكثر وتكلفة عتاد أقلّ، ولكن قد ينتهي المطاف بفاتورة عليها رقم أكبر من المتوقّع. إلى أن تتأكّد من ما يناسبك، يُنصَح بأن تجرّب عددًا من العروض. يمكنك أيضًا استخدام حاسبة التكلفة التي يقدّمها مزودو الخدمة، مثل AWS و Google Cloud Platform. أفضل الممارسات لخفض التكلفة حاول أن لا تحدّد مدى استخدام خدماتك، بل ابحث عن الخدمات المتغيّرة ذاتيًّا حسب الاستخدام. تأكّد من إمكانيّة تقليل مواصفات الخدمة بقدر إمكانيّة زيادتها. ادفع مسبقًا واستفد من الخدمات المحجوزة إذا كنت تعلم الحدّ الأدنى لاستخدامك. اضبط خدماتك لتبدأ وتتوقّف آليًّا لتوفير المال عندما لا تستخدمها. أنشئ تنبيهات لتتبّع نفقات الحوسبة السحابيّة. الفوائد المحتملة للانتقال إلى الحوسبة السحابيّة العديد من المشاكل يمكن حلّها بالانتقال إلى الحوسبة السحابيّة. فيما يلي بعض الحالات التي يمكن أن تستفيد فيها من الانتقال. يواجه تطبيقك ازديادًا في كميّة البيانات المارّة فيه، مما يصعّب زيادة الموارد لحظيًّا لتناسب الطلب. تحتاج إلى تقليل التكلفة التشغيليّة بينما تزيد كفاءة تقنية المعلومات. يتطلب زبونك تنفيذًا ونشرًا سريعين للتطبيق، ولهذا يريد تطويرًا أكثر وتقليلًا للتأخير الذي قد ينشأ من البنية التحتيّة. يريد زبائنك توسيع أعمالهم جغرافيًّا، ولكنك تعتقد بأن تجهيز بنية تحتيّة متعدّدة الأقاليم سيكون تحدّيًا كبيرًا، وذلك لما فيه من مجهود متعلّق بالإدارة والوقت والكوادر البشريّة والسيطرة على الأخطاء. مواكبة النمو المتزايد للاحتياج إلى تخزين البيانات صارت أكثر صعوبة وتكلفة. تحتاج إلى بناء فريق تطوير موزّع جغافيًّا. تسمح بيئة الحوسبة السحابيّة للموظفين البعيدين الوصول إلى التطبيقات واستخدامها عبر الإنترنت. تحتاج إلى تأسيس نظام استرجاع من الكوارث ولكن تجهيزه لمركز بيانات بأكمله قد يضاعف التكلفة، وسيحتاج أيضًا إلى خطة معقّدة للاسترجاع من الكوارث. يمكن تطبيق أنظمة الاسترجاع من الكوارث المعتمدة على الحوسبة السحابيّة أسرع، وستعطيك تحكّمًا أفضل بكثير بالموارد التي لديك. تتبُّع وتطوير البرمجيات التي يحويها الخادم يأخذ وقتًا، ولكنه مهم، ويحتاج إلى تطوير دوريّ وأحيانًا فوريّ, سيهتم مزود خدمة الحوسبة السحابيّة بهذا الأمر في بعض الأحيان تلقائيًّا. وكذلك، تهتم بعض نماذج الحوسبة السحابية ببعض الأمور الإدارية كالنسخ الاحتياطيّ لقواعد البيانات وتحديث البرمجيّات والصيانة الدوريّة. تكلفة رأس المال والتكاليف التشغيليّة: تحوِّل الحوسبةُ السحابيّةُ تقنيةَ المعلوماتِ إلى نموذج الدفع مقابل الاستخدام، وهي ميزة مغريةٌ وخاصّةً للشركات الناشئة. المخاطر المحتملة نتيجة الانتقال إلى الحوسبة السحابيّة رغم أن المخاطر التي تنطبق على كلّ حالة تعتمد كثيرًا على طبيعة البيئة المراد نقلها، إلّا انّ هناك عيوب عامّة تتعلق بالانتقال إلى الحوسبة السحابيّة التي عليك أخذها بعين الاعتبار. إذا كان تطبيقك يخزّن ويسترجع بيانات حسّاسة جدًّا، فقد لا تتمكن من إبقائها في النظام السحابيّ. وكذلك قد تحُدّ متطلّبات التوافق خياراتك. إذا كان الإعداد الموجود لديك من قبل يفي باحتياجاتك، ولا يحتاج الكثير من الصيانة والتحجيم والإتاحة، وكان جميع زبائنك راضين عنه، فلِمَ تعبث به؟ إذا كانت بعض التقنيات التي تعتمد عليها حاليًّا مملوكة، فقد لا يُسمَح لك قانونًا بنشرها على نظام سحابيّ. قد تعاني بعض العمليات من تأخير إضافيّ عند استخدام تطبيقات سحابيّة عبر الإنترنت. إذا كان العتاد بين يدي شخص آخر أو جهة أخرى، فقد تخسر الشفافية والتحكم اللازمين لتتبع مشاكل الأداء. قد يسبب "الجيران" في بعض الأحيان "إزعاجًا" عبر الموارد المشتركة (الإنترنت). قد لا يتبع تتصميم ومعمارية تطبيقك معمارية الحوسبة السحابيّة الموزّعة، ولهذا قد يتطلّب بعض التعديلات قبل نقلها إلى الحوسبة السحابيّة. البقاء عالقًا عند مزود خدمة سحابيّة معيّن: قد يكون من الصعب المغادرة أو الانتقال إلى منصّة سحابيّة أخرى بمجرد أن تبدأ باستخدام بيئة سحابيّة معيّنة. انقطاع الخدمة: يحدث هذا للجميع، ولكنك قد لا ترغب بأن تكون الأمور بيد شخص آخر. باتّباع هذا الأسلوب في التفكير، إذا كنت تفكّر بنقل أعمالك إلى الحوسبة السحابيّة، فقد تسأل نفسك عن العثرات الشائعة التي يمكن أن تواجهها عند النقل. ما نموذج الحوسبة السحابيّة الذي تحتاجه؟ إذا كنت قررت تجربة الحوسبة السحابيّة، فسيكون عليك اختيار نموذج الحوسبة السحابيّة الذي من الممكن ان تستخدمه. فيما يلي أكثر هذه النماذج شيوعًا: البنية التحتيّة كخدمة: Infrastructure as a Service (مثل AWS، وAzure، وGoogle Cloud، و Alibaba Cloud). المنصّة كخدمة: Platform as a Service (مثل AWS Elastic، وBeanstalk، وHeroku، وGoogle App Engine، وEngine Yard). البرنامج كخدمة: Software as a Service (مثل Google G Suite، وOffice 365، وSalesforce، وNetSuite). وهنا يكمن قرار مهمّ عليك اتّخاذه. النوع الأول هو الأفضل للشركات التي لا مانع لديها من استضافة تطبيقاتها في مراكز بيانات شركة أخرى، وتفضِّل أن يهتم غيرها بالبنية التحتيّة العتاديّة لتركّز بالكامل على تطوير ونشر ومتابعة تطبيقها. رغم هذا، إذا كنت تفضّل أن تكون تطبيقاتك قابلة للنقل، فقد ترغب في أن تضع البرمجية في منصّة PaaS متينة تقدّم بيئة بنية تحتيّة كاملة (وواضحة). إنّ تبّني PaaS سيقلّل أيضًا الوقت الذي تحتاجه لتكون جاهزًا للسوق - وذلك لأنها ستكون مجهّزة مسبقًا بمعظم المتطلّبات اللازمة لتشغيل برمجيّاتك. ستحتاج إلى نشر أعلى طبقة في تطبيقك فقط، وفي بعض الأحيان التطبيق نفسه وحسب. أمّا عن SaaS، فهو نموذج توصيل محتوى تكون البرمجيات الانتاجيّة فيه مستضافة مركزيًّا ومرخّصة حسب الاشتراك. فيما يلي جدول يوضّح ما توفّره كلّ من النماذج الثلاثة المذكورة أعلاه. IaaS PaaS SaaS تخزين البيانات منصّة التطبيق برنامج إدارة الزبائن الأجهزة الظاهريّة قاعدة البيانات إدارة الأعمال نظام توصيل محتوى التطوير الأمن الشبكة التكامل الأدوات الحوسبة table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } خاصّة أم عامّة أم هجينة؟ لنفترض أنّك اخترت نموذجًا سحابيًّا، وقد حان الوقت لاختيار النوع. لديك ثلاثُ خيارات أساسيّة: عامّ: جميع الموارد التي لديك مستضافة بالكامل لدى واحد أو أكثر من مزودي خدمة الحوسبة السحابيّة، مثل AWS، Azure، GCP، Alibaba، DigitalOcean، …إلخ. خاصّ: تُنشئ نظام الحوسبة السحابيّة الخاصّ بك بنفسك باستخدام منصّة مثل OpenStack أو VMWare vCloud. هجين: مواردك موزّعة على منصات خاصّة وعامّة، مع اتصالات بينها تتابعها أنت. يمكن أن يكون الخيار الهجين جذّابًا بسبب مزجه الجيد لكل من الاستخدام عند الطلب والاستقرار والإتاحة الدائمة والأمن والتكلفة التشغيلية القليلة. باستخدام هذا النوع يمكنك أن تجمع بين مزايا النوعين. سنشرح فيما يلي كيف تعمل الحوسبة السحابيّة الهجينة في شركة معيّنة. لنتخيّل أنّ تطبيقك المبنيّ للإنترنت يزدهر من ناحية الشعبية وعدد المستخدمين. ستحتاج إلى الموارد اللازمة للتوسعة باستمرار، وذلك من أجل أن تواكب الطلب المتزايد عليه. يجب أن تتمكن من زيادة الموارد المستخدمة إلى أقصى حدّ عندما يصل الاستخدام حدّه الأقصى، وأن تقلل تلك الموارد عندما لا تحتاجها وذلك لخفض التكلفة. يمكن فعل ذلك في الحوسبة السحابيّة العامّة. افترض بأن البيانات التي يجعمها تطبيقك سرّيّة جدًّا، ولا يمكن تخزينها خارج نطاق المؤسّسة. وهنا يمكن أن نستفيد من النوع الهجين. يمكنك في هذه الحالة أن تختار الأجزاء التي يمكنها أن تسكن السحابة العامّة، والأجزاء التي ستبقى في مركز البيانات عندك. يقول موقع RightScale في تقرير له أنّ الشركات تتبنى استراتيجيّة تعدد مزودي الخدمة 84%، وأنّ 58% منها تخطط لاستخدام حوسبة سحابيّة هجينة. تقييم التطبيقات للنقل إلى الحوسبة السحابيّة ما إن تختار النموذج والنوع، يبدأ التحدّي الحقيقيّ. لقد حان الوقت لنرى إذا كانت التطبيقات التي لديك جاهزة للنقل إلى الحوسبة السحابيّة. فيما يلي بعض العوامل التي عليك أخذها بعين الاعتبار: تعقيد تصميم التطبيق بعض التطبيقات القديمة معقدة جدًا ومترابطة داخليًّا إلى حد بعيد، مما يجعل مستخدميها غير راغبين في إعادة برمجتها. رغم هذا، فالمتطلب الرئيسيّ لأي انتقال ناجح هو أن تتبع التطبيقات معمارية موزعة، ويجب أن تكون من أساسها قابلة للتحجيم. يمكن لأدوات مثل PaaSLane و Cloudamize أن تساعدك على تقييم إلى أيّ مدى تطبيقاتك جاهزة لنقلها إلى منصّة سحابيّة. إنّ خدمة AWS’s Migration Hub تحوي كلّما تحتاجه من أدوات لاكتشاف وتقييم ذلك. تعقيدات التكامل لكل تطبيق نقاط تكامل، كبوابات الدفع، وخوادم البريد، وخدمات الويب، والتخزين الخارجي، والمزودين الخارجيين. من الضروريّ جدًّا تحليل أثر الانتقال إلى الحوسبة السحابية على هذه الاعتماديات. ستواجه في بعض الأحيان تحديات غير متوقعة تتعلق بالاتصال والاستيثاق، وعليك تحديدها وحلّها قبل حدوثها. أكثر المهام أهميّة (ومللًا) تحديد كلّ نقاط التكامل هذه. وبما أن التطبيقات القديمة قد يكون توثيقها ضعيفًا، وقد يكون المطورون الملمّون بتفاصيلها غير متاحين، فقد تحتاج إلى تفقّد أجزائها كلّها يدويًّا. تزداد المهمّة تعقيدًا إذا كنت تفكّر بترحيل مئات التطبيقات التي تعمل حاليًّا في مركز البيانات لديك. يمكن مواجهة العديد من هذه التحديات بالاعتماد على معرفة فريقك للتطبيقات، وعلى أداة اكتشاف الموارد (سواء مفتوحة المصدر أو تجارية). يمكن لأداة اكتشاف الموارد مساعدتك على تحديد كلّ إعدادات الخوادم في شبكتك، بما في ذلك تفاصيل الاتصال. على سبيل المثال، لنقل أن لديك مركز بيانات فيه شبكة تستضيف مئة تطبيق. يمكن لأداة الاكتشاف تلك أن تقدم لك نظرة عامّة للنظام بأكمله. ويمكنها أيضًا أن تعطيك تفاصيل متفرقة يمكنها مساعدتك في تقييم إدارة السعة العامّة (general capacity management، مصطلح إداريّ). من أدوات اكتشاف الموارد المعروفة BMC Atrium و HP DDMA. تقدّم Cloudamize أداة يمكنها اكتشاف التطبيقات والأجهزة آليًّا، ويمكنها أيضًا عمل خرائط باعتماديات التطبيقات آليًّا، وذلك من أجل اكتشاف الاعتماديات بين التطبيقات. نظام التشغيل المضيف ما إن تقرّر الانتقال إلى الحوسبة السحابيّة، من الضروريّ أن تعلم إذا كان باستطاعتك نشر تطبيقك على نفس نظام التشغيل. يمكن أن يعمل تطبيقك على نظام تشغيل محدّد (أو إصدار محدّد من نظام التشغيل). إذا لم يكن هذا النظام متوافقًا مع مزود الخدمات السحابيّة، فسيكون عليك أن تجد نظام تشغيل بديل يمكن استخدامه، أو مزود خدمات سحابيّة آخر، أو أن تلغي مشروع النقل من أساسه. على سبيل المثال، لا يتيح معظم مزودي الخدمات السحابيّة خيارات لأنظمة تشغيل 32بت، وقد يكون لدى البقيّة متطلّبات اشتراك غير متوقّعة. من الضروريّ أن تجري بحثًا في هذا الأمر قبل التخطيط للنقل. قاعدة بيانات التطبيق من المعروف أن قاعدة البيانات جزء هامّ من أيّ تطبيق. يستثمر الزبائن كثيرًا في خوادم قواعد البيانات، وغالبًا في تراخيصها أيضًا. إضافة إلى ذلك، قد لا ترغب في نقل قواعد البيانات الآن، وذلك بسبب تعقيدها وحساسيّة البيانات التي فيها، كما أن نقل كميات ضخمة من البيانات ليست بالأمر السهل. في جميع الأحول، عليك أن تتأكد من أن طرق النقل التي ستستخدمها يمكن الاعتماد عليها إلى حدّ بعيد، ويمكن كذلك عكسها في حال حصول مشكلة كبيرة غير متوقّعة. يوفّر معظم مزودي الخدمات السحابيّة أدوات نقل خاصّة بهم. ولهذا من الضروريّ أن تقيّم هذه الخدمات قبل أن تضغط زرّ البدء. فمثلًا، تقدم AWS خدمة Migration Hub، والتي - على حد تعبيرهم - "تسهّل وتسرّع الاكتشاف والنقل من مراكز بياناتك إلى AWS Cloud". وهناك العديد من من مزودي خدمة نقل البيانات كطرف ثالث، مثل Attunity CloudBeam، وATADATA ATAmotion، وCloudEndure Live Migration، وRacemi DynaCenter. الشبكة لا تدعم معظم بيئات الحوسبة السحابيّة ميزة multicasting، ولهذا إذا كان تطبيقك يعتمد على هذه الميزة، فعليك أن تفكّر جيدًا قبل أن تخطو أيّ خطوة. موازنة الأسعار لدى العديد من مزودي الخدمات السحابيّة حاسبات تكلفة من شأنها أن تساعدك على تقدير التكاليف الحقيقيّة التي ستواجهها عند الانتقال إلى الحوسبة السحابية، ومقارنتها بالتكلفة الحاليّة، ومنها AWS TCO (Total Cost of Ownership) calculator و Azure Pricing Calculator. يسمح لك موقع Cloudamize بمقارنة التكاليف لدى كلّ من AWS وAzure و Google Cloud Platform (GCP)، بحيث يمكنك من الاختيار بينها بما يتوافق مع مدى الحمل الذي يقوم به تطبيقك. إثبات المفاهيم (Proof of Concept) من الأفكار الرائعة دائمًا بناء "إثبات للمفاهيم" (أي تجربة الأمر عمليًّا على نظام بديل ومنفصل عن النظام الحقيقيّ الذي تستخدمه، وذلك للتأكد من أن كل شيء يعمل كما يجب) على نطاق صغير قبل نقل التطبيق الحقيقيّ إلى الحوسبة السحابيّة. لن تتوقع هذه النماذج كل المشاكل التي يمكن أن تحصل، ولكنها ستوضّح التحديات التي يمكن أن تواجهها بوضوح أكثر، وستساعدك على فهمها. من الأمور التي عليك البحث فيها أثناء تنفيذ هذه الخطوة: مقارنة الأداء مع التطبيق الموجود فعليًّا. مستويات التعقيد أثناء ترحيل التطبيق. التحديات المتعلقة بالشبكة والتي يجب العمل على حلّها. إمكانيّة الاعتماد عليها. تقييم دعم مزود الخدمة. خُلاصة القول تستفيد العديد من المؤسسات من المرونة التي تقدّمها خدمات الحوسبة السحابيّة، فيما يتعلّق بإمكانية تشغيلها وإيقافها وتغيير حجمها ومزاياها والدفع حسب الاستخدام. رغم هذا، وكما في أيّ خدمة بنية تحتيّة، يجب عليك تقييم مدى ملاءمة الحوسبة السحابيّة لحالة الاستخدام لديك تحديدًا، وذلك لعمل تقييم مبني على المخاطر المحتملة (risk-based evaluation). خصِّص وقتًا للبحث والتخطيط لتفهم كيف ستؤثِّر الحوسبة السحابيّة في أعمالك. لا يمكن حصر كلّ التحديات التي يمكن أن تواجهها عند النقل في مقال واحد، ولكننا حاولنا هنا الوقوف على بعض المشاكل الشائعة التي يجب أن تأخذها بعين الاعتبار قبل بدء هذا العمل. شاركنا تجربتك في نقل عملك إلى الحوسبة السحابية في التعليقات. ترجمة -وبتصرف- للمقالين: Disadvantages of Cloud Computing لصاحبه Andrew Larkin. Cloud Migration Risks & Benefits لصاحبه Jeremy Cook.

هذا المقال هو الجزء الأول من جزأين يشرحان موضوع الحوسبة السحابيّة. يناقش هذا المقال المتطلبات المسبقة وما تحتاج إلى معرفته قبل بدء رحلتك في الحوسبة السحابية. ويناقش كذلك بعض الافتراضات الخاطئة المتعلقة بالحوسبة السحابية، ويعمل على تصحيح المفاهيم المتعلقة بها، كما ويوضح مفهومي الأجهزة الافتراضيّة (الأجهزة الظاهريّة)، والحوسبة السحابيّة العامّة والخاصّة. ومن ثمّ يناقش أحد المفاهيم المتعلّقة بالحوسبة السحابية والتي تتردّد كثيرًا، وهو مفهوم "مهندس حوسبة سحابية" (Cloud Architect)؛ سنناقش في هذا المقال ما يقوم به مهندس الحوسبة السحابية، وسنحلّل المهارات والشهادات اللازمة لتصبح مهندس حوسبة سحابيّة. وسنذكر كذلك بعض أنواع الوظائف المتاحة إذا قرّرت جعل هذا المجال حرفتك. المتطلبات المسبقة لتعلم الحوسبة السحابية يسأل العديد من المهتمين: "ما المتطلبات والمعرفة المسبقة اللازمة لبدء تعلم الحوسبة السحابية؟" سنعطي - في هذا المقال - المعلومات اللازمة للإجابة على هذا السؤال، لتكون جاهزًا لبدء تعلم الحوسبة السحابية دون قلق. يشير مفهوم الحوسبة السحابية إلى مجال واسع من تقنية المعلومات تشمل: البنية التحتية العتادية، والبنية التحتية البرمجية، ومنشآت مراكز البيانات (data centers)، وتقنيات الأجهزة الافتراضية (أو الأجهزة الظاهرية - Virtualization)، ومفاهيم هندسة البرمجيات. كلّ هذه المجالات متصلة ببعضها وتوفر لك معرفة أولية جيدة تسهّل عليك رحلتك في استكشاف وتعلّم استخدام منصات الحوسبة السحابية والعمل فيها؛ ولكننا سنركّز في هذا المقال على مزودي خدمة البنية التحتية السحابية (Infrastructure as a Service - IaaS)، مثل خدمات أمازون (Amazon Web Services - AWS)، و Microsoft Azure، و Google Compute Engine و Rackspace Cloud، وكذلك على مزودي خدمة المنصة السحابية (Platform as a Service - PaaS)، مثل Salesforce.com، و Microsoft Azure، و Google App Engine. يمكننا البدء بافتراض أنّك لن تحتاج شهادة جامعية في أحد مجالات الحاسوب لتعلم الحوسبة السحابية. يمكنك بدء تعلم الحوسبة السحابية من الصفر حتى وإن كانت مهاراتك في تقنية المعلومات بسيطة جدًّا. افتراضات مغلوطة عن الحوسبة السحابية 1. لتعلم الحوسبة السحابية يجب أن تجيد البرمجة يمكنك أن تبدأ تعلم الحوسبة السحابية باستخدام خدمة حوسبة سحابية - عامّة أو خاصّة - حتّى وإن لم تكن مطوّر برمجيات. 2. يجب أن تكون لديك خبرة سابقة في عالم تقنية المعلومات الحوسبة السحابية تقنية مستخدمة في كل المجالات وحول العالم، ومن شأن فهمها أن يساعد الجميع، وليس فقط ذوي الاهتمامات التقنيّة؛ بل غالب الظنّ أنك تعمل في مؤسّسة تستخدم الحوسبة السحابية بالفعل. 3. الحوسبة السحابية فقط للتقنيين ومطوري البرمجيات إنّ الحوسبة السحابيّة تغيّر طريقة بناء الشركات لأنظمة المعلومات لديها، وكيفية استخدامها لها، بما في ذلك كلّ برمجياتها، ويجب على المدراء، والمسوّقين، ومدراء الأنظمة، والمطورين تعلّمها؛ ولكن - بالطبع- بتوجّهات مختلفة، مركّزين على الجوانب المتعلّقة بأدوارهم ومسؤوليّاتهم. أنظمة التشغيل والأجهزة الافتراضيّة والشبكة بما أنّ الحوسبة السحابية مجالها واسع، لكي تتعلّم الحوسبة السحابية تحتاج لبعض المهارات تتعلق بالمفاهيم الأساسيّة لأنظمة التشغيل وكيف تعمل (دون الخوض في تفاصيلها الدقيقة)، مثل Windows ولينُكس ومفاهيم بسيطة تتعلّق بهما. إذا كانت معرفتك جيدة في هذه الأمور، فأنت تعرف أنّ التقنيات المتعلّقة باستخدام الأجهزة الافتراضيّة (أو الأجهزة الظاهريّة Virtualization) لها دورً مهمّ عندما نتحدّث عن الحوسبة السحابيّة. لا توجد تجربة تضاهي تشغيل جهاز افتراضيّ بنفسك (يمكنك فعل ذلك باستخدام VirtualBox) لتفهم كيف تعمل بيئة الأجهزة الافتراضيّة. تمكّنك هذه التقنيّات من إنشاء بيئة ظاهريّة تحدّد فيها عدد وسرعة المعالجات المركزية (CPU) والذاكرة الرئيسيّة (RAM) ومساحة التخزين، وكذلك نظام التشغيل الذي يعمل عليها مثل Windows أو Linux. تتشارك الأجهزة الافتراضيّة في العتاد الحقيقيّ وأجهزة الشبكة ولكنّها منفصلة عن بعضها. من أوائل الشركات الرائدة في هذا المجال شركة تُدعى VMWare. لقد كانت الحوسبة الظاهريّة (أو الأجهزة الافتراضيّة) معروفة جيّدًا قبل VMWare، ولكنّ هذه الشركة غيّرت السوق المتعلّق بها، حيث حوّلت هذه التقنيّة إلى حزمة برمجيّة جاهزة للاستخدام ممّا جعلها شائعة في الشركات صغيرة كانت أم كبيرة. لقد قدّمت هذه التقنيّة مفهومًا اقتصاديًّا واستراتيجيًّا جديدًا، وهو Consolidation، ويعني حرفيًّا الدمج أو الجَمع، ويشير إلى جمع أكثر من خدمة وأكثر من جهاز افتراضيّ على جهاز حقيقيّ واحد. ويعني هذا أن الشركات حول العالم لم يعد واجبًا عليها توفير خادم حقيقيّ لكل نوع من التطبيقات أو الأحمال التي يشغّلونها، بل صار بإمكانهم مشاركة الموارد وتقسيمها بين عدد من الأجهزة الافتراضيّة. مفاهيم أساسيّة عليك معرفتها عن الأجهزة الافتراضيّة Hypervisor: هو قلب نظام الأجهزة الافتراضيّة والذي يشغّل كلّ الأجهزة الافتراضيّة. ومن الأمثلة عليه VMWare وKVM وXen و OpenVZ. تستخدم كلّ بيئات الحوسبة السحابيّة hypervisor معدّل. أمازون مثلًا تستخدم Xen. الجهاز الافتراضيّ (أو الجهاز الظاهريّ، وبالإنجليزيّة: Virtual Machine): وهو العنصر الأساسيّ في هذه التقنيّة. اعلَم أنّ للجهاز الافتراضيّ نظام تشغيل ومعالج وذاكرة وقرص تخزين والعديد من الإعدادات المتعلّقة بالشبكة. مزايا استخدام الأجهزة الافتراضيّة: الجَمع (جمع أكثر من جهاز على عتاد واحد)، وإمكانيّة نقل الأجهزة الافتراضيّة بين الخوادم الحقيقيّة (والتي تسمّى أيضًا بالعُقَد physical nodes)، والمرونة في إضافة موارد جديدة إلى جهاز افتراضيّ موجود. ما إن تصبِح ملمًّا بأساسيّات تقنيّات الحوسبة الظاهريّة (الأجهزة الافتراضيّة) وأنظمة التشغيل، فعليك بأخذ مساق مقدمة في الشبكات، ومن ثمّ ستتعلّم الحوسبة السحابية بسهولة. يمكن أن يكون مجال الشبكات صعبًا، وسيحتاج حتّى ذوو المهارات العالية بعض الوقت لفهمه بالكامل. راجع القسم المتعلّق بالشبكات في هذا المقال لفهم المتطلبات اللازمة للخوض في هذا المجال. وفي النهاية، نريد تكوين فكرة واضحة عن معنى كلّ من الحوسبة السحابيّة العامّة والخاصّة. السحابة العامّة: تشير إلى البنية التحتية التي من الممكن للعموم الوصول إليها وتخزين بيانات وأجهزة افتراضيّة وأيّ نوع من الموارد السحابيّة. يمكنك استخدامها بنفسك، ولست بحاجة إلى الاستثمار في العتاد والبنية التحتيّة من أجل ذلك. يمكنك استخدام السحابات العامّة والدفع حسب الاستخدام. وهذا يشبه استئجار السيّارة لمدّة معينة من الوقت بدلًا من شرائها وامتلاكها. السحابة الخاصّة: تحتاج الشركات إلى كلّ المرونة والمزايا التي تقدمها الحوسبة السحابيّة، ولكن قد تكون لديها بنيتها التحتيّة ومركز البيانات (data center) الخاصّ بها. في هذه الحالة، تكون الشركة مسؤولة عن إدارة كلّ شيء فيها. ما هي هندسة الحوسبة السحابيّة يشير مفهوم معمارية الحوسبة السحابيّة (أو هندسة الحوسبة السحابيّة) إلى المكوّنات الرئيسيّة والفرعيّة التي تحتاجها الحوسبة السحابيّة. وتتكون هذه المكوّنات عادة من منصّة الواجهة، والمنصّة الخلفيّة، ونظام التوصيل السحابيّ للمحتوى (cloud-based delivery) والشبكة. وتشكّل هذه المكوّنات مجتمعة معماريّة الحوسبة السحابيّة. ويعتمد تصميم حلول الحوسبة السحابيّة على أساليب وإجراءات هندسيّة تمّ تطويرها على مدى العقدين الماضيين. مهندس الحوسبة السحابية مسؤول عن تحويل المتطلبات التقنيّة للمشروع إلى معماريّة وتصميم يوجّهان سير العمل للوصول إلى المنتج النهائيّ. وغالبًا يكون مهندس الحوسبة السحابية مسؤولًا أيضًا عن رأبِ الصدعِ بين المشكلات المركّبة المتعلّقة بالأعمال وبين الحلول المعتمدة على الحوسبة السحابيّة. ويعمل الأعضاء الآخرون في الفريق التقنيّ - بما فيهم مهندس دعم المطورين DevOps والمطورون - مع مهندس الحوسبة السحابيّة للتأكد من بناء الحلّ أو الحلول التقنيّة المناسبة. ما المهارات المطلوبة في البداية؟ إذا كنت تفكر بأن تغدو مهندس حوسبة سحابية، فيفترض بأن لديك بالفعل معرفة مسبقة قويّة في الحوسبة السحابيّة أو مجال تقنيّ مشابه. إذا كنت ترى المفاهيم التالية مفهومة بالنسبة لك، أو على الأقل بعضها، فغالبًا أنت على الطريق الصحيح. أمّا إذا لم تكن كذلك، فأنصحك أوّلًا بدراسة أو العمل في مجال قريب قبل أن تسعى إلى أن تغدو مهندس حوسبة سحابيّة. معرفة جيّدة في واحد من أنظمة التشغيل على الأقل: لينُكس، يونكس، سولاريس، أو ويندوز. ما أنصحك به هو نظام التشغيل لينُكس بأيّ من توزيعاته (سواء بتوزيعة دبيانيّة أو ردهاتيّة أو غيرها). وجود خبرة مسبقة كمدير نظام أو مهندس نظم لأيّ من أنظمة التشغيل المعروفة قد يفيدك أيضًا. فهم جيّد في الشبكات: TCP/IP و HTTP و DNS. أقترح أن تتعرف على المفاهيم المتعلقة بها قبل السعي لأن تصبح مهندس حوسبة سحابية. لغة برمجة: ستحتاج على الأقل إلى فهم بسيط للغة برمجة مفسّرة (scripting language). غالبًا هذا ليس إلزاميًّا، ولكنه بكل تأكيد سيفيدك. الأمن: أمن المعلومات مهم في الحوسبة السحابيّة، ولهذا، يجب أن يكون لديك فهم جيّد للمفاهيم الأساسيّة في مجال أمن المعلومات، كجدران الحماية مثلًا. إن القائمة المذكورة أعلاه ليست كاملة أبدًا. إن العبرة من ذكرها هو ضرورة أن تكون لديك معرفة تقنيّة قويّة إذا كنت تفكّر بدخول مجال هندسة الحوسبة السحابيّة. يقدّم موقع Could Roster قائمة محدّثة بالمهارات التقنيّة الدارجة، ويشرح ما تقوم به هندسة الحوسبة السحابيّة، ويوضّح الخصائص والتوقّعات اليوميّة، ويعرض قائمة بالمهارات التي يحتاجها السوق. يتم تحديث القائمة شهريًّا، لذا تأكّد من مراجعتها قُبَيلَ بدئك في السعي نحو الحصول على شهادة في المجال. [001-Cloud-Roster-Features.gif] ما الخطوة التالية؟ لنفترض بأنّك تحقّق بعض المتطلّبات المذكورة أعلاه؛ ماذا تفعل الآن لتغدو مهندس حوسبة سحابيّة مؤهّلًا؟ يعتمد هذا على المنصّة التي تفضّلها: خدمات أمازون السحابيّة - AWS مهندس معتمد لحلول خدمات أمازون السحابيّة (AWS Certified Solutions Architect – Associate) - تحقِّق هذه الشهادة الخبرات التقنيّة في تصميم ونشر نظام قابل للتوسعة، ومتاح دائمًا، ومقاوم للأخطاء على منصّة AWS التابعة لأمازون. يوضّح هذا المقال كيفيّة التحضير للاختبار بالتفصيل، ويتعمّق أكثر فيما يتعلّق بالمصادر المتاحة على Cloud Academy التي من شأنها مساعدتك على النجاح في الاختبار. Microsoft Azure مهندس حلول حوسبة سحابية لمنصّة Microsoft Azure (بالإنجليزيّة Microsoft Azure Solutions Architect - إنّ منصّة Microsoft Azure رياديّةٌ في هذا السوق الصاعِد، وتتطلّب شهادتها خبرة في الحوسبة، والشبكات، والتخزين، والأمن، وذلك من أجل تصميم حلول تعمل على Azure. للحصول على شهادة مهندس حلول Azure، ستحتاج إلى النجاح في اختبارين، وهما: AZ-300 و AZ-301. لا تحتاج إلى اجتياز أيّ امتحانات أقلّ درجة من أجل التقدم إلى هذين الامتحانين. يركّز اختبار AZ-300 على تقنيات Azure، بينما يركّز اختبار AZ-301 على التصميم. خدمات Google السحابيّة - Google Cloud Platform مهندس مختصّ في الحوسبة السحابيّ: يمكّن المهندسُ المختصّ في الحوسبة السحابيّة (Profestional Cloud Architect) المؤسساتِ من الاستفادة من التقنيات التي تتيحها خدمات Google السحابية. يمكن لهذا المهندس - بفهمه العميق لمعمارية الحوسبة السحابية ومنصّة Google للخدمات السحابيّة - أن يصمّم ويطوّر ويدير حلول تقنيّة متينة وآمنة وقابلة للتوسعة ومتاحة دائمًا ومرنة وذلك لتحقيق أهداف المؤسسة. لقد غدوتُ مهندس حوسبة سحابية مؤهَّلًا - ماذا أفعل الآن؟ ما إن تتخطى اختبار التأهيل، ستُفتَح أمامك العديد من فُرَص العمل التي ربما لم تفكِّر فيها حتّى. إنّ بعض الشركات الأكثر ابتكارًا في مجال البيانات الضخمة (big data) ليس بوسعها تحقيق أيّ شيء دون مهندس حوسبة سحابيّة مؤهّل لإحدى منصّات الحوسبة السحابية المذكورة. تُقدِّم AWS المرونة وإمكانيّة التوسعة والرزانة المطلوبة لأكثر من مليون زبون. من الشركات التي تستفيد من خدمات AWS في مجال البيانات الضخمة كلّ من General Motors، وIBM، وSplunk، وWeather Company. قد تجد نفسك يومًا ما تعمل لدى شركة طبيّة لبناء نظام لتحليل الحمض النووي (الجينات) لتوقع الأمراض من خلالها. إذا كنت تحب السّفر، فقد تعمل في يوم ما لدى شركة Expedia، التي تستخدم AWS لاستضافة خدمتها (Expedia Service)، وهي خدمة متخصّصة بتقديم الاقتراحات المتعلّقة بالسياحة. ولكي لا ننسى أحد أكبر زبائن AWS، وهي Netflix، تستخدم منصة AWS في نظام توصيل محتوى متاح دائمًا ومقاوم للأخطاء لخدمة بثّ الأفلام والبرامج التلفازيّة التي تقدّمها. تعتمد Netflix على إمكانات البنية التحتيّة لأمازون في التوسّع السريع والخوادم وتخزين البيانات، وذلك بسبب الكمّ الهائل ونمط الاستخدام المتأرجح لزبائنها. لا يسعنا إلا أن نتخيّل أنّهم يوظّفون مئات إن لم يكن آلاف مهندسي حلول الحوسبة السحابيّة لمنصّة AWS. إنّ منصّة Microsoft Azure أسرع مزوّدي الخدمات السحابيّة نموًّا لبناء واختبار ونشر وإدارة التطبيقات والخدمات عبر مراكز بيانات تديرها Microsoft. من الشركات التي تستخدم Azure كلّ من Adobe، وApple، وiCloud، وEbay، وTravelocity، وSamsung، وXerox، وNFL، وNBC. ما إن تصبح مهندس حوسبة سحابيّة مؤهًلًا لمنصّة Microsoft Azure، فسيكون باستطاعتك التقدّم لأيّ من آلاف الشواغر المتاحة لـمهندسي الحوسبة السحابيّة لمنصّة Azure. إنّ منصّة Google للحوسبة السحابيّة هي حقيبة كاملة من خدمات الحوسبة السحابيّة التي تعمل على نفس البنية التحتيّة التي تستخدمها Google من أجل خدماتها التي تقدّمها للمستخدمين الأفراد، وتستخدمها كذلك كلّ من Target، وPayPal، و20th Century Fox، وTwitter. إذا صرت مؤهلًا في هندسة الحوسبة السحابية لمنصة Google، فبإمكانك التقدّم للوظائف ذات العلاقة. إنّ مهندس الحوسبة السحابيّة لَذو دور هامّ، وهناك حاجة ماسّة في السوق لهذا التخصّص، والإمكانات فيه غير محدودة. وتشير التوقعات أيضًا إلى نموّ هائل في هذا المجال في السنوات القليلة القادمة، ولهذا نعتقد بأنّ الحصول على مؤهّل في هندسة الحوسبة السحابية خطوة في الاتجاه الصحيح، سواء للعمل في المجال، أو للتعرف على أيّ تقنيات حديثة ومذهلة تنشأ في حلبة الحوسبة السحابيّة. ترجمة -وبتصرف- للمقالين: What Exactly Is a Cloud Architect and How Do You Become One?‎ لصاحبه Michael Sheehy Prerequisites to Learn Cloud Computing – Introduction لصاحبه Stefano Bellasio

ما الفرق بين دوكر (Docker) والأجهزة الافتراضية (والمسماة أيضًا بالأجهزة الظاهرية Virtual Machines)؟ سنشرح في هذا المقال الاختلافات بينهما، وسنذكر وجهة نظرنا لمساعدتك على الاختيار. ما هو دوكر؟ تسعى المؤسسات هذه الأيام إلى تحويل أعمالها إلى أعمال إلكترونية، ولكن يعيقها التنوع الكبير في البنية التحتية في داخل المؤسسة نفسها وفي الحوسبة السحابية والتطبيقات. يحل دوكر هذه المشكلة بتوفير منصة حاويات تساعد على تحويل الخدمات الصغيرة والتطبيقات التقليدية المبنية لويندوز ولينكس والخوادم الكبيرة إلى سلسلة إمداد مؤتمتة وآمنة. إنّ دوكر أداة تطوير برمجيات وتقنية حوسبة ظاهرية تسهِّل تطوير ونشر وإدارة التطبيقات باستخدام حاويات. والحاويات هي حزم تنفيذية خفيفة وقائمة بذاتها لتطبيق ما، تحوي كل المكتبات وملفات الإمداد والاعتماديات والأجزاء الأخرى الضرورية ليعمل التطبيق. وبعبارة أخرى، فإنّ التطبيقات تعمل بنفس الطريقة بغضّ النظر عن مكانها أو نوع الجهاز الذي تعمل عليه، وذلك لأن الحاوية توفّر بيئة التطبيق طوال دورة حياة البرنامج. وبما أنّ الحاويات معزولة، فأنها توفر أمنًا إضافيًّا، مما يسمح لتشغيل أكثر من حاوية على نفس الجهاز في نفس الوقت. إضافة إلى ذلك، فهذه الحاويات خفيفة لأنها لا تتطلّب حملًا إضافيًّا كالأجهزة الافتراضية. تشغّل الأجهزة الافتراضية أنظمة مستضافة (كما في حالة VMWare و VirtualBox)، أما الحاويات فتعمل ضمن نواة النظام المضيف مباشرة دون الحاجة إلى نظام ضيف. تتميّز الحاويات عن الأجهزة الافتراضية بما يلي: تحتاج موارد أقل لإدارتها. حجم نسخ احتياطيّة فوريّة (snapshots) أصغر. أسرع في عمل نسخ معدّلة للتطبيقات. تحديثات أمنية أقل وأبسط. كتابة شيفرات أقلّ لنقل وترحيل ورفع العمل. ما هي الأجهزة الافتراضية؟ أما عن الأجهزة الافتراضية، فتُستَخدَم لتنفيذ مهام قد تكون خطرة لو تم تنفيذها على النظام المضيف. الأجهزة الافتراضية معزولة عن بقية النظام، ولا يمكن للنظام الضيف أن يعبث بالجهاز المضيف. ولهذا، فبعض المهام - كالوصول إلى ملفات مصابة بفيروسات، واختبار أنظمة التشغيل - تُستخدَم معها الأجهزة الافتراضية. يمكننا تعريف الجهاز الافتراضيّ كما يلي: الجهاز الافتراضيّ هو ملف أو برمجيّة حاسوب يُشار إليها عادة بـ"الضيف" (guest) تُنشَأ في داخل بيئة حاسوبيّة أخرى تُسمّى "المضيف". باستطاعة الجهاز الافتراضيّ تنفيذ مهام كتشغيل التطبيقات أو البرامج كحاسوبٍ مستقِلّ، مما يجعله بيئة مثاليّة لتجربة أنظمة تشغيل أخرى، كالإصدارات التجريبيّة، وعمل نسخ احتياطيّة لأنظمة التشغيل، وتشغيل تطبيقات وبرمجيات. ويمكن للنظام المضيف أن يحوي عددًا من الأجهزة الافتراضية، وأن تعمل كلّها أو بعضها في نفس الوقت. ومن الملفات التي يتكوّن منها الجهاز الافتراضيّ: ملفات التقارير، وإعدادات الذاكرة، وملف القرص الصلب الافتراضيّ، وملف الإعدادات. ومن المجالات الأخرى التي تحتاج إلى أجهزة افتراضيّة الخوادم؛ حيث يمكن تقسيم خادم حقيقيّ إلى عدد من الخوادم الافتراضيّة المنفصلة والمعزولة عن بعضها، ممّا يسمح لهذه الخوادم الافتراضيّة أن تعمل بأنظمة تشغيل خاصة بها. ويوفِّر كلّ جهاز افتراضيّ عتاده الافتراضيّ، كالمُعالِج، والذاكرة، وواجهات الشبكة، والأقراص الصلبة، وأجهزة أخرى. عمومًا، تقسَّم الأجهزة الافتراضيّة إلى فئتين حسب استخدامها: أجهزة افتراضيّة على مستوى النظام: وهي منصّات تسمح بوجود عدد من الأجهزة الافتراضيّة يعمل كلّ منها بنسخة نظام تشغيل خاصّة به وتتشارك كلها في موارد الجهاز المضيف. وتوفِّر الطبقة البرمجيّة التي تشغّل الأجهزة الافتراضيّة من هذا النوع (والمسماة Hypervisor) التقنيات المتعلقة بتنفيذ الأجهزة الافتراضيّة. وتُنفَّذ هذه الطبقة فوق نظام التشغيل المضيف أو على العتاد مباشرة. أجهزة افتراضية على مستوى الخدمات: تتيح هذه الأجهزة بيئة برمجة مستقلّة. وتُصمَّم خدمة الجهاز الافتراضيّ لإخفاء المعلومات المتعلّقة بالعتاد ونظام التشغيل وتسمح للبرنامج بالعمل بنفس الطريقة في كلّ منصّة من هذا النوع. وعلى الرغم من أن تشغيل عدد من الأجهزة الافتراضيّة يبدو للوهلة الأولى استغلالًا جيّدًا للموارد، إلّا أنّه يؤدي إلى أداء سيء؛ إذ سيكون لكلّ نظام ضيف نواته ومجموعة مكتباته واعتمادياته، مما سيشغل قدرًا كبيرًا من موارد النظام. ومن العيوب الأخرى للأجهزة الافتراضيّة قلّة أداء برمجية مشرف الجهاز الافتراضيّ (Hypervisor) موازنة بالعتاج الحقيقيّ، وكذلك المدة الطويلة التي يحتاجها ليقلع النظام ويكون جاهزًا للعمل. يتغلّب مفهوم الحاويات -بما في ذلك منصّة دوكر- على هذه العقبات. الموازنة فيما يلي الاختلافات المهمّة بين دوكر والأجهزة الافتراضيّة. 1. المعمارية ودعم أنظمة التشغيل الاختلاف الرئيسي بين دوكر والأجهزة الافتراضيّة يكمن في المعمارية، كما هو موضّح في ما يلي. في حال الأجهزة الافتراضيّة، لدينا نظام تشغيل مضيف، ولدينا نظام تشغيل ضيف في كلّ جهاز افتراضيّ، ويمكن ان يكون نظام التشغيل الضيف أيّ نظام تشغيل - مثل ويندوز أو لينكس - بغض النظر عن النظام المضيف. أما دوكر فيستضيف البرمجيات على نفس النظام المضيف. مشاركة النظام المضيف بين الحاويات يجعلها خفيفة وسريعة عند تشغيلها. وتعدّ حاويات دوكر مناسبة لتشغيل عدد من التطبيقات على نواة نظام تشغيل واحدة؛ أما الأجهزة الافتراضية فهي ضروريّة إذا كان التطبيق أو الخدمة بحاجة إلى نظام تشغيل مختلف. 2. الأمن الأجهزة الافتراضيّة قائمة بذاتها، ولها نواتها وخصائصها المتعلقة بالأمن. ولهذا، تُستخدَم الأجهزة الافتراضيّة لتشغيل التطبيقات التي تحتاج إلى صلاحيات وأمان أكثر. أما بالنسبة لدوكر، فلا يُنصح بإعطاء صلاحيات عُليا للتطبيقات أو تشغيلها بصلاحيات المسؤول أو الجذر، وذلك لأنّ هذه الحاويات تتشارك مع النظام المضيف نواته؛ حيث يمكن لتقنية الحاويات الوصول إلى الأنظمة التابعة للنواة؛ مما يعني أن وجود تطبيق واحد مُصاب ببرمجية خبيثة يمكن أن يؤدّي إلى اختراق النظام المستضيف بأكمله. 3. إمكانية النقل الأجهزة الافتراضيّة معزولة عن النظام الذي تعمل عليه، ولهذا فهي لا تنتقل إلى أنظمة أخرى بدون حدوث مشكلات تتعلق بالتوافقيّة. ولهذا، إذا كان من الضروريّ اختبار التطبيق على منصات مختلفة في مرحلة التطوير، فيجب أخذ دوكر بالحسبان في هذه الحالة. إنّ حزم حاويات دوكر تحوي كل ما تحتاجه، ويمكنها تشغيل التطبيقات في أيّ بيئة، وبما أنها لا تحتاج إلى نظام تشغيل ضيف، فيمكن نقلها بسهولة إلى منصات مختلفة. كذلك، يمكن نشر حاويات دوكر في الخوادم، وذلك لأنها خفيفة، ويمكن تشغيلها وإيقافها في وقت أقلّ بكثير من الأجهزة الافتراضيّة. 4. الأداء تحتاج الأجهزة الافتراضيّة إلى موارد أكثر من حاويات دوكر، فهي بحاجة إلى تحميل نظام تشغيل بأكمله عند بدئها. أما حاويات دوكر فهي ذات معمارية خفيفة ولا تحتاج موارد كثيرة كما في الأجهزة الافتراضيّة. في حال الأجهزة الافتراضيّة تكون الموارد - بما فيها المعالج والذاكرة والدخل/الخرج - ثابتة لا تتغير، على خلاف الحاويات، والتي يزداد استخدام الموارد فيها حسب الحمل أو كمية البيانات المارّة. توسعة واستنساخ الحاويات بسيط وسهل مقارنة بالأجهزة الافتراضيّة، حيث لا تحتاج هذه الحاويات إلى تثبيت أنظمة تشغيل فيها. في ما يلي بعض الاختلافات الأخرى بين الاثنين، عدا عن الاختلافات الرئيسيّة: ... دوكر الأجهزة الافتراضيّة وقت الإقلاع تُقلِع في ثوانٍ قليلة يستغرق تشغيل الجهاز الافتراضي بضع دقائق تعمل على يستفيد دوكر من محرّك التنفيذ (excution engine) تستخدم مشرف الأجهزة الافتراضيّة (hypervisor) كفاءتها في استخدام الذاكرة تحتاج ذاكرة قليلة وذلك لعدم حاجتها إلى جهاز افتراضيّ تحتاج إلى تحميل نظام تشغيل كامل قبل أن تبدأ التطبيق، ولهذا فهي أقل كفاءة من هذه الناحية. العزل معرّضة لاستغلالها بطريقة سيئة، وذلك لعدم وجود احتياطات لأنظمة العزل إمكانيّة التعارض بينها منخفضة بسبب كفاءة آليّة العزل فيها النشر نشرها سهل، حيث يمكن استخدام نسخة واحدة في حاوية على كل المنصات النشر يأخذ وقتًا أطول، وذلك لوجود نماذج منفصلة مسؤولة عن التنفيذ الاستخدام لدى دوكر آليّة استخدام مركّبة تتكون من أدوات تديرها دوكر وأخرى من أطراف خارجيّة الأدوات سهلة وأبسط في الاستخدام table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } أيّ الخيارين أفضل؟ لا يمكن موازنة دوكر بالأجهزة الافتراضيّة بعدالة، إذ صُمِّمت كلّ منها لاستخدامات مختلفة. لا شكّ بأنّ دوكر ينتشر بقوّة هذه الأيّام، ولكن لا يمكنه أن يحلّ محلّ الأجهزة الافتراضيّة. وعلى الرغم من أنّ دوكر يزداد شعبيّة، إلّا انّ الأجهزة الافتراضيّة خيار أفضل في حالات معيّنة. تُعدّ الأجهزة الافتراضيّة خيارًا مناسبًا في الإصدارات النهائيّة، وهي أفضل من حاويات دوكر في هذه الحالة، حيث تعمل هذه الأجهزة الافتراضيّة بنظام تشغيلها الخاص دون أن تشكّل خطرًا على الحاسوب المضيف. ولكن إذا كانت التطبيقات بحاجة إلى اختبار، فالخيار الأفضل هو دوكر، إذ يقدّم منصات أنظمة تشغيل مختلفة يمكن استخدامها لعمل اختبارات كثيرة للتطبيق أو البرنامج. إضافة إلى ذلك، تستخدم حاويات دوكر محرّك دوكر (docker-engine) بدلًا من استخدام مشرف (hypervisor) كالذي تستخدمه الأجهزة الافتراضيّة. وبما أنّ النواة المضيفة مشتركة، فإنّ استخدام محرك دوكر يجعل الحاويات صغيرة ومعزولة ومتوافقة وعالية الأداء وسريعة الاستجابة. لحاويات دوكر عبء اقلّ، حيث أنها متوافقة بتشارك نفس النواة ومكتبات تطبيقات. تستفيد المؤسسات من خليط من الاثنين غالبًا، حيث يعتمد الاختيار في كلّ حالة على نوع الحمل الذي تحتاجه المؤسسة. لا تعتمد كثير من المؤسسات على الأجهزة الافتراضيّة كخيارها الرئيسيّ، وتفضّل الانتقال إلى استخدام الحاويات، حيث انّ عمليّة النشر تكون طويلة وتأخذ وقتًا، وتشغيل خدمات مصغّرة من التحديات الكبيرة التي تنشأ منها. على الرغم من هذا، ما زالت هناك شركات تفضّل الأجهزة الافتراضيّة على دوكر، أما الشركات التي تستخدم خدمات أمن مخصصة للشركات لبنيتها التحتيّة تفضل الاستفادة من دوكر. خلاصة القول أن الحاويات ودوكر ليست في صراع مع الأجهزة الافتراضيّة، حيث تكمل كلّ منهما الأخرى في أعمال واستخدامات مختلفة. تُنشأ الأجهزة الافتراضيّة للتطبيقات التي عادة تكون ثابتة ولا تتغير كثيرًا، أمّا منصّة دوكر فهي مصمّمة لتكون مرنة أكثر بحيث يمكن تحديث هذه الحاويات بسهولة وباستمرار. هل دوكر مجرد "موضة"؟ أم أنّه سيحلّ محلّ الأجهزة الافتراضيّة؟ هل لديك ما تشاركنا به؟ شاركنا برأيك في التعليقات. ترجمة -وبتصرف- للمقال Docker vs. Virtual Machines: Differences You Should Know لصاحبه Simran Arora

الناس ليسوا مهتمين بشراء سرير؛ إنّ ما يريدونه هو أن يناموا في الليل قريري العَين ومُرتاحين. قد لا يمانع البعض في النوم على لوح من الخشب إذا كان هذا يعني أنهم سيفيقون نشيطين. هذا ما يجعلنا (كمسوقين) في مشكلة حقيقيّة نحتاج لحلّها. على الرياديين أن يذهبوا إلى أبعد من مجرد بناء منتج؛ عليهم أن يسوّقوا لما سيسمح مُنتجهم للزبائن بفعلَه. إذا لم يفعلوا هذا، فمن الواضح أنهم ليسوا من ذوي الخبرة. وهذا ما لخّصته المستثمرة Dina Routhier في قولها: لننظر إلى بعض الأمثلة عن كيف تساعد الفوائد في التسويق للمنتَج. "افقد 15 كيلوجراما في ثلاثين يوما!"من السهل على من هو جالس على أريكته يتابع التلفاز أن يستهزئ بأفضل البرامج التسويقيّة (infomercials) التي تعرضها قنوات التلفاز في وقت متأخر من الليل. ورغم هذا، تُحقِّق هذه الإعلانات مبيعات عادة تتخطّى بكثيرٍ تطبيقَ الوّب فائق الأناقة التي يتحدّث عنه الجميع ولكن لا أحد يرغب بأن يدفع مقابل استخدامه. حقيقة الأمر أنّ صناعة البرامج التسويقيّة تلك ما زالت تتزايد. حتى أنّها وصلت إلى درجة التغطية على الإعلام التلفازي ذاته. لماذا نذكر هذا الأمر؟ إذا كان هناك ما تتميز به هذه البرامج، فهو أنها تسوّق للفائدة المرجوة من المنتَج. وأحد أسباب ذلك هو أنّهم يعلمون أن بالإمكان استمالة الناس وليس دفعهم إلى شراء المُنتَج. سبق لـClaude C. Hopkins أن قال: بيع ما له علاقة برغبات موجودة أسهل من إنشاء رغبات جديدة. قد تبدو البرامج التسويقيّة كلها متشابهة، ولكنها ناجحة، لأنّها تسوّق لحلول مطلوبة دائمًا. الأمر شبيه بالطريقة التي تأتي بها أكثر الشركات الناشئة نجاحًا لتعمل على مشكلة موجودة بالفعل أو موجودة منذ زمن، وتجعل حلّها أسهل وأسرع وأرخص وفي متناول اليد أكثر من غيره. هناك أيضًا استخدام فعّال لنظام التسويق. "15 كيلوجرامًا في 30 يومًا" عبارة جدّابة لأنك تعلم ما ستحصل عليه. تستغل أقراص التخسيس السحرية هذا الأمر للخداع، ولكن اللغة نفسها بالنسبة للبرامج الرياضية الحقيقية، مثل P90X و Insanity. لا أحد يرغب بشراء برامج رياضيّة لذاتها، إنّ ما يريده المشتري هو عضلات مشدودة وتقوية أفضل ضمن نطاق زمني معقول. ما الذي سأحصل عليه؟لندع البرامج التسويقيّة جانبًا ونلاحظ فعالية التسويق للفائدة في عالم الأعمال "الحقيقيّ". هذه الطريقة تعمل بشكل جيّد. لقد فهمت Apple هذا الأمر عندما أطلقت أول إصدار من iPod. لم تكن مشغلات MP3 شيئًا جديدًا، فقد تفوّقت هذه المُشغّلات على الأقراصَ المضغوطة. لقد كانت المشكلة في التسويق؛ لم تُستخدَم الطريقة الصحيحة في توضيح كم ستكون حياة الزبائن أفضل عندما يملكون يستخدمون جهازًا مُماثلًا. كيف تظن Apple أبدعت في خلق أسطورة iPod ؟ هل بنَتها على القوة التقنيّة، أم على ما يمكن للمستخدم عمله بجهاز iPod ؟ لقد كانت الرسالة مقنعة لأنّها –على حدّ تعبير Seth Godin–: إن ما يدعو للسخرية هو أنّ أولئك المعجبين بشركة Apple ومديرها التنفيذي الراحل ستيف جوبز –وخاصة من في مجتمع الشركات الناشئة منهم– يعانون مشاكل جمّة في مجال التسويق. تمتلئ الكثير من مواضيع HackerNews بمعلقين ذوي انتقادات لاذعة يصرّون على أنّ من يذكر أكثر المزايا التقنيّة قوّة هو من يفوز. لقد وصلت هذه المشكلة إلى جعل Justin Jackson يكتب مقالًا مشهورًا جدًّا يذكّر فيه مطوري البرمجيات بأنّهم "ليسوا "عاديين" بالنسبة للزبائن. قد يفاجئك ذلك، لكن زيادة التحدّي التقنيّ عند بناء منتَج لن يضمن لك إمكانيّة بيع كميّة أكبر منه. بمُجرّد أن تخطر على بالك فكرة لمُنتج جديد، نشرع في التّفكير بالتقنيات التي قد نستخدمها لبنائه، وننجرف في هذا الاتجاه."يمكني أن أبني هذا على واجهة برمجة تطبيقات Twilio!". "يمكنني أن أتعلم الإطار البرمجيّ الجديد لـCSS!". "يمكنني استخدام هذه الأداة الجديدة التي اشتريتها للتو!"المشكلة هي أنّ كلّ هذا يدور حولنا نحن، المُؤسّسين، وليس حول الزبائن، المستهلكين. هناك ميل طبيعي لدى الحرفي لأن يتحدّث عن حرفته. لكن تذكّر أنّ الزبائن غالبًا لن يهتموا بالتروس الداخليّة التي تحرّك المنتَج. إن ما يهمهم معرفته هو "ما الذي سأستفيده من هذا المنتَج؟" نسخة محسنة منك إنّ الناس لا يشترون منتجات؛ إنّهم يشترون نسخة محسنة من أنفسهم. وكما قال Jason Fried: وكما هو الأمر بالنسبة للعديد من نواحي التسويق، يعود الأمر دائمًا إلى الحصول على عرض قويّ للقيمة. هذا ما يغقل عنه الكثيرون، وهذا ما يدفع بعض المُعلّقين لكتابة تعليقات مثل هذا التّعليق الذي يدّل على محدودية اطّلاع كاتبه: وكأن لسان حال هذا المُعلّق يقول: يجب أن عليك الجلوس في قبو منزلك وبناء أشياء دون أن تحاول أبدًا تسويقها للناس الذين هم بأشدّ الحاجة إليها. وكما هو واضح فإنّ هذا الأمر غير معقول. ألقِ نظرة على صفحة البداية لشركة عظيمة مثل Bidsketch: عندما تقرأها تجدها متخمة بـ"التسويق للفائدة" (benefit selling) الذي ناقشناه خلال هذا المقال. "التسويق" هنا مفيد لي كزبون: أفهم جيّدًا ما تقدّمه، وما يمكنني فعله به، دون الخوض في تفاصيل لا أحتاجها. وكمثال على ما عليك أن لا تفعله، مررت مرّة بتطبيق SaaS (لم يكنّ مصممًا للمطورين) ذُكِرَ تحت العنوان الرئيسيّ مباشرة "صُنِعَ بِفَخر باستخدام Ruby on Rails". "ماذا تعني Ruby on Rails؟ هل هي مرحلة في لعبة Mario Kart؟". 99 بالمئة من المستخدمين لن يعرفوا ولن يهتموا بالأمر. هذا أشبه بعرض مخطّطات الكهرباء والماء لشخص يزور شقّتك بغرض شرائها حتّى قبل أن يبدي اهتمامًا بالأمر. إليك أمثلة لشركات تميل لأن تفهم بعمق قيمة التسويق للفوائد (لأنهم يفهمون جيّدًا كيف يُجنى المال). لا يذكر Freckle حتى مجرّد ذكر لكلمة "برمجيّة" قبل أن يذكرك بمشكلتك الأكبر عند استخدامك لتطبيق تتبّع الوقت. و تعلم SerpIQ أن المستقبل سيجيب بنعم على أسئلتهم. بمجرد أنّ تكون الفوائد واضحة، سيعلمون كيف ولماذا هي أداة أسرع وأكثر دقّة. المزايا ما زالت مهمةمن الواضح أنّ المزايا تصف المنتَج. فبمجرّد أن تسوّق للآفاق التي يمكن أن تفعلها باستخدام تلك الفوائد، ستسهّل هذه التفاصيل اتخاذ القرار. خذ شراء سيّارة على سبيل المثال؛ ما تحتاجه هو سيارة واسعة وآمنة لعائلتك، ولكن عندما يتعلق الأمر بالقرار النهائيّ، فقد تختار تلك التي فيها تدفئة في المقاعِد. إلى أن تكون الفوائد واضحة، فهذه الأمور (التفاصيل الفنيّة المتعلّقة بالمزايا) هي مجرّد جماليّات. يمكن للمزايا في غالب الأوقات أن تضع النقاط على الحروف وتضع الفوائد ضمن سياق أكبر. هناك طريقتان لعمل هذا: التعليل: تستخدم شركات التأمين مقارنة الأسعار لتوضيح سبب كون تأمينهم أرخص (عبر المزايا). بمجرد أن يتم التسويق للفوائد، تُستخدَم المزايا لتوضّح لك كيف سيتم الأمر. إذا قالت شركة استضافة بأنّ موقعك آمن بالكامل. ستريك المزايا كيف أنّ هذا الادعاء صحيح ومضمون. سوّق للفوائد أولًا، ثم وضّح المزايا التي تقدّمها لإتمام الأمر.التمييز: وصف نقاطك المتعلقة بالوسائل وتفصيلها بتوضيح المزايا التي لديك. كثيرًا ما نخبر زبائن Help Scout كيف أن أغلب خدمات الدّعم الفنّي بوكلاء خارجيين لمساعدتهم في مراجعة رسائل البريد الإلكترونيّ. أما نحن فنقوم بذلك داخليًّا مما يسمح لنا بإضفاء تكامل بين البريد الإلكترونيّ ودعم البريد الصوتيّ وهو أمرٌ لا يستطيع الآخرون عمله (تغدو هذه الميزة مهمّة فقط بعد الحديث عن مشكلة "المشاكل التي تُسببها خدمات الدّعم الفني").لدى Claude Hopkins طريقة مفيدة تتعلق بكيفيّة عرض المزايا والفوائد بطريقة صحيحة: هناك طريقة واحدة وبسيطة للإجابة عن تساؤلات كثيرة حول الإعلانات. اسأل نفسك "هل سيساعد هذا مندوبَ المبيعات في بيع المُنتجات التي لديه؟ هل ستساعدني على بيعها إذا قابلت المشتري وجهًا لوجه؟" هل ستقوم –عند قيامك بالبيع بنفسك– بالخواص التّقنية للمُنتج التي ترغب في بيعه قبل أن تُخبره بفوائده؟ تذكّر أن قيامك بالتسويق غير المبني على الفوائد لا يخدم الزبائن. أعطهم ما يريدونه بأن تظهر لهم لماذا منتجك هو "الشيء الوحيد" الذي كانوا يبحثون عنه. أخيرًا ولكن –بالتأكيد– ليس آخرًا، احذر أن تبيع "فوائد مزيّفة"، أو أن تخفي المزايا التي لديك تمامًا، وخاصّة عندما تتحدّث إلى جمهور من الشركات أو التقنيين المتقدمين. المزايا هامّة، وهي ضروريّة لدعم الحلّ الذي تسوّق له والذي يجعل الفئة المستهدفة مهتمّة في المقام الأول. ترجمة -وبتصرّف- للمقال Features Tell, but Benefits Sell لكتابه Gregory Ciotti. حقوق الصورة البارزة: Designed by Freepik.

يكثر الحديث هذه الأيام عن أنماط تصميم البرمجيات، ومن الأسئلة الأكثر شيوعًا "كيف يمكنني استخدام النمط الفلاني مع التقنية (التكنولوجيا) الفلانيّة؟". أما في حالة Laravel ونمط المستودع (Repository pattern)، فكثيرًا أرى أسئلة من قبيل "كيف يمكنني أن أستخدم نمط المستودع في Laravel 4؟" أو في هذه الأيام "مع Laravel 5؟". من المهم أن تتذكر أنّ أنماط التصميم لا تعتمد على تقنيّة محدّدة، أو إطار برمجي محدد، أو لغة برمجة محددة. إذا كنت قد فهمت نمط المستودع بالفعل، فلا يهم الإطار البرمجي أو اللغة البرمجة التي ستستخدمها. المهم أن تفهم المبدأ الذي يقف خلف نمط المستودع، ومن ثم يمكنك استخدامه في أيّ تقنية تريد. آخذين هذا بعين الاعتبار، لنبدأ بتعريف نمط المستودع: يفصل نمط المستودع منطق الوصول إلى البيانات (data access logic) ويربطه مكانيًّا بكيانات الأعمال (business entities) في المنطق الأعمال (business logic). ويتم التواصل بين منطق الوصول إلى البيانات ومنطق الأعمال باستخدام واجهات (interfaces). ولتبسيط ذلك، فإن نمط المستودع نوع من الحاويات يخزّن فيه منطق الوصول إلى البيانات، بحيث يخفي منطق الوصول إلى البيانات عن منطق الأعمال. وبعبارة أخرى، نسمح لمنطق الأعمال أن يصل إلى كائن البيانات دون معرفة هيكلية الوصول إلى البيانات التي تتم خلف الكواليس. ولفصل الوصول إلى البيانات عن منطق الأعمال فوائد عدّة، منها: مركزية منطق الوصول إلى البيانات تجعل النصوص البرمجية أسهل في الصيانة.يمكن فحص منطق الأعمال ومنطق الوصول إلى البيانات كلًّا على حدة.تقليل تكرار الأكواد البرمجية.فرصة أقل للوقوع في أخطاء برمجية.الأمر كلّه يتعلق بالواجهاتكلّ ما في نمط المستودع ذو علاقة بالواجهات. تعمل الواجهة كاتفاقية تحدّد ما على فئة concrete تنفيذه.لنفكّر قليلًا. إذا كان لدينا كائني بيانات، الممثل والفلم، فما هي مجموعة العمليات الشائعة التي يمكن تطبيقها على هذين العنصرين؟ سنرغب في غالب الأحيان بالقيام بالعمليات التالية: الحصول على جميع السجلات.الحصول على مجموعة السجلّات مرقّمة.إنشاء سجلّ جديد.الحصول على سجل باستخدام المفتاح الرئيسيّ.الحصول على سجل باستخدام خواص (attributes) أخرى.تحديث سجلّ.حذف سجلّ.هل يمكنك الآن أن ترى كميّة النصوص البرمجيّة المكررة التي ستكون لدينا إذا قمنا بذلك مع كلّ كائن بيانات؟ حسنًا، هذه ليست مشكلة كبيرة بالنسبة للمشاريع الصغيرة، ولكنها أمر سيّء بالنسبة للمشاريع الكبيرة. الآن، وبعد أن عرّفنا العمليات الشائعة، يمكننا إنشاء واجهة: interface RepositoryInterface { public function all($columns = array('*')); public function paginate($perPage = 15, $columns = array('*')); public function create(array $data); public function update(array $data, $id); public function delete($id); public function find($id, $columns = array('*')); public function findBy($field, $value, $columns = array('*')); }هيكليّة الدليل Directory Structureقبل أن نتابع إنشاء فئة مستودع concrete التي ستنفّذ هذه الواجهة، لنفكّر قليلًا كيف نريد أن ننظّم النصوص البرمجيّة لدينا. عادة، عندما أنشئ شيئًا ما، أفضّل أن أفكر بطريقة تقسيمه إلى مكوّنات، حيث أرغب بأن أكون قادرًا على إعادة استخدام ذاك النصّ البرمجيّ لمشاريع أخرى. إن هيكليّة الدليل البسيطة التي أتبعها لمكونات المستودع تبدو كما يلي: ولكنها يمكن أن تكون مختلفة، كأن يكون للمكونات خيارات ضبط مثلًا. لدي في داخل الدليل src ثلاثة أدلّة أخرى، هي: Contracts وEloquent وexceptions. كما ترى، أسماء المجلدات مناسبة للغاية لما نريد وضعه فيها. ففي Contracts نضع الواجهات، أو الاتفاقيات – كما سميناها أعلاه - . ويحوي مجلد Eloquent مستودعي abstract و concrete تنفّذ الاتفاقات. ونضع في المجيد Exceptions فئات الاستثناءات. وحيث أننا ننشئ حزم، فعلينا أن ننشئ ملف composer.json، حيث نجد فيه ربطًا مكانيًّا لنطاق الأسماء (namespaces) لأدلّة معيّنة، واعتماديات حزم، وبيانات وصفيّة أخرى للحزم. فيما يلي محتوى composer.json لهذه الحزمة: { "name": "bosnadev/repositories", "description": "Laravel Repositories", "keywords": [ "laravel", "repository", "repositories", "eloquent", "database" ], "licence": "MIT", "authors": [ { "name": "Mirza Pasic", "email": "mirza.pasic@edu.fit.ba" } ], "require": { "php": ">=5.4.0", "illuminate/support": "5.*", "illuminate/database": "5.*" }, "autoload": { "psr-4": { "Bosnadev\\Repositories\\": "src/" } }, "autoload-dev": { "psr-4": { "Bosnadev\\Tests\\Repositories\\": "tests/" } }, "extra": { "branch-alias": { "dev-master": "0.x-dev" } }, "minimum-stability": "dev", "prefer-stable": true } كما ترى، فقد ربطنا Bosnadev\Repository إلى الدليل src. وهناك شيء آخر علينا أخذه بعين الاعتبار قبل البدء بتنفيذ RepositoryInterface، فحيث أنها موجودة في المجلد Contracts، فعلينا أن نحدّد نطاق الاسم لها: <?php namespace Bosnadev\Repositories\Contracts; interface RepositoryInterface {...}نحن الآن مستعدون لبدء تنفيذ المحتوى. تنفيذ المستودععلى كل مستودع فرعيّ في concrete أن يزيد من مستودع abstract لدينا، مما يعني تنفيذ اتفاقية RepositoryInterface. أما الآن، فكيف تنفّذ هذه الاتفاقيّة؟ ألقِ نظرة على method الأولى. ما الذي يمكنك قوله عنها بمجرد النظر إليها؟ تُسمى method الأولى في اتفاقيتنا بالاسم ()all للتوضيح. مهمتها هي جلب كلّ السجلات لهيئة concrete. تستقبل معامِلاً واحدًا، وهو columns$ الذي يجب أن يكون مصفوفة (array). يُستخدّم هذا المعامِل – كما هو واضح من اسمه – لتحديد الأعمدة التي ترغب بجلبها من مصدر البيانات، ومبدئيًّا نقوم بجلبها كلّها. لهئيات محدّدة، يمكن أن تبدو كالتالي: <?php namespace Bosnadev\Repositories\Contracts; interface RepositoryInterface {...}لكننا نريدها أن تكون عامّة أكثر لكي نتمكن من استخدامها متى أردنا: public function all($columns = array('*')) { return $this->model->get($columns); } في هذه الحالة this->model$ هي نسخة من Bosnadev\Models\Actor، ولهذا، فعلينا إنشاء نسخة جديدة للنموذج الموجود في مكان ما في المستودع. هنا أحد الحلول التي يمكنك استخدامها لتنفيذ هذا الأمر: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @param App $app * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app) { $this->app = $app; $this->makeModel(); } /** * Specify Model class name * * @return mixed */ abstract function model(); /** * @return Model * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model; } } وحيث أننا عرفنا الفئة كـ abstract، فهذا يعني أن علينا زيادتها باستخدام فئة متفرّعة عن concrete. فعند تعريف method المسمّى ()model كـ abstract، فإننا نجبر المستخدم على تنفيذ هذه الطريقة (method) في فئة متفرعة عن concrete. فمثلًا: <?php namespace App\Repositories; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Eloquent\Repository; class ActorRepository extends Repository { /** * Specify Model class name * * @return mixed */ function model(){ return 'Bosnadev\Models\Actor'; } }يمكننا الآن أن ننفذ بقية طرق (methods) الاتفاقات: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @param App $app * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app) { $this->app = $app; $this->makeModel(); } /** * Specify Model class name * * @return mixed */ abstract function model(); /** * @param array $columns * @return mixed */ public function all($columns = array('*')) { return $this->model->get($columns); } /** * @param int $perPage * @param array $columns * @return mixed */ public function paginate($perPage = 15, $columns = array('*')) { return $this->model->paginate($perPage, $columns); } /** * @param array $data * @return mixed */ public function create(array $data) { return $this->model->create($data); } /** * @param array $data * @param $id * @param string $attribute * @return mixed */ public function update(array $data, $id, $attribute="id") { return $this->model->where($attribute, '=', $id)->update($data); } /** * @param $id * @return mixed */ public function delete($id) { return $this->model->destroy($id); } /** * @param $id * @param array $columns * @return mixed */ public function find($id, $columns = array('*')) { return $this->model->find($id, $columns); } /** * @param $attribute * @param $value * @param array $columns * @return mixed */ public function findBy($attribute, $value, $columns = array('*')) { return $this->model->where($attribute, '=', $value)->first($columns); } /** * @return \Illuminate\Database\Eloquent\Builder * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model->newQuery(); } } الأمر سهل للغاية، صح؟ الشيء الوحيد المتبقي الآن هو حقن ActorRepository في ActorsController، أو الجزء المتعلق بالأعمال (business logic) من تطبيقنا. <?php namespace App\Http\Controllers; use App\Repositories\ActorRepository as Actor; class ActorsController extends Controller { /** * @var Actor */ private $actor; public function __construct(Actor $actor) { $this->actor = $actor; } public function index() { return \Response::json($this->actor->all()); } }استعلامات المعايير Criteria Queriesكما يمكنك أن تتخيل، فهذه الأعمال البسيطة كافية فقط لاستعلامات البسيطة. أما بالنسبة للتطبيقات الكبيرة، فستحتاج بالتأكيد لعمل بعض الاستعلامات الخاصّة لاستدعاء مجموعة بيانات محدّدة أكثر باستخدام معايير محدّدة. للقيام بذلك، نبدأ بتحديد ما على معايير الفروع (child ، أو العميل client) القيام به. وبعبارة أخرى، سننشئ فئة abstract non-instantiable باستخدام method واحدة فقط : <?php namespace Bosnadev\Repositories\Criteria; use Bosnadev\Repositories\Contracts\RepositoryInterface as Repository; use Bosnadev\Repositories\Contracts\RepositoryInterface; abstract class Criteria { /** * @param $model * @param RepositoryInterface $repository * @return mixed */ public abstract function apply($model, Repository $repository); }ستحوي هذه الطريقة (method) استعلام معايير يتم تطبيقه في فئة Repository ضمن هيئة concrete. علينا أيضًا أن نزيد على فئة Repository قليلًا لتغطية استعلامات المعايير. لكن قبل ذلك، هيّا ننشئ اتفاقية أخرى لفئة Repository. <?php namespace Bosnadev\Repositories\Contracts; use Bosnadev\Repositories\Criteria\Criteria; /** * Interface CriteriaInterface * @package Bosnadev\Repositories\Contracts */ interface CriteriaInterface { /*** @param bool $status * @return $this */ public function skipCriteria($status = true); /*** @return mixed*/public function getCriteria(); /*** @param Criteria $criteria* @return $this*/public function getByCriteria(Criteria $criteria); /*** @param Criteria $criteria* @return $this*/public function pushCriteria(Criteria $criteria); /*** @return $this*/public function applyCriteria(); }يمكننا أن نزيد فاعلية فئة Repository بتنفيذ اتفاقية CriteriaInterface: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\CriteriaInterface; use Bosnadev\Repositories\Criteria\Criteria; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Support\Collection; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface, CriteriaInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @var Collection */ protected $criteria; /** * @var bool */ protected $skipCriteria = false; /** * @param App $app * @param Collection $collection * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app, Collection $collection) { $this->app = $app; $this->criteria = $collection; $this->resetScope(); $this->makeModel(); } /** * Specify Model class name * * @return mixed */ public abstract function model(); /** * @param array $columns * @return mixed */ public function all($columns = array('*')) { $this->applyCriteria(); return $this->model->get($columns); } /** * @param int $perPage * @param array $columns * @return mixed */ public function paginate($perPage = 1, $columns = array('*')) { $this->applyCriteria(); return $this->model->paginate($perPage, $columns); } /** * @param array $data * @return mixed */ public function create(array $data) { return $this->model->create($data); } /** * @param array $data * @param $id * @param string $attribute * @return mixed */ public function update(array $data, $id, $attribute="id") { return $this->model->where($attribute, '=', $id)->update($data); } /** * @param $id * @return mixed */ public function delete($id) { return $this->model->destroy($id); } /** * @param $id * @param array $columns * @return mixed */ public function find($id, $columns = array('*')) { $this->applyCriteria(); return $this->model->find($id, $columns); } /** * @param $attribute * @param $value * @param array $columns * @return mixed */ public function findBy($attribute, $value, $columns = array('*')) { $this->applyCriteria(); return $this->model->where($attribute, '=', $value)->first($columns); } /** * @return \Illuminate\Database\Eloquent\Builder * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model->newQuery(); } /** * @return $this */ public function resetScope() { $this->skipCriteria(false); return $this; } /** * @param bool $status * @return $this */ public function skipCriteria($status = true){ $this->skipCriteria = $status; return $this; } /** * @return mixed */ public function getCriteria() { return $this->criteria; } /** * @param Criteria $criteria * @return $this */ public function getByCriteria(Criteria $criteria) { $this->model = $criteria->apply($this->model, $this); return $this; } /** * @param Criteria $criteria * @return $this */ public function pushCriteria(Criteria $criteria) { $this->criteria->push($criteria); return $this; } /** * @return $this */ public function applyCriteria() { if($this->skipCriteria === true) return $this; foreach($this->getCriteria() as $criteria) { if($criteria instanceof Criteria) $this->model = $criteria->apply($this->model, $this); } return $this; } } إنشاء معايير جديدة، حيث يمكنك الآن أن ترتب مستودعاتك بسهولة أكبر. لست بحاجة لأن تكون مستودعاتك مكونة من آلاف الأسطر. يمكن أن تبدو فئة المعايير لديك كالآتي: <?php namespace App\Repositories\Criteria\Films; use Bosnadev\Repositories\Contracts\CriteriaInterface; use Bosnadev\Repositories\Contracts\RepositoryInterface as Repository; use Bosnadev\Repositories\Contracts\RepositoryInterface; class LengthOverTwoHours implements CriteriaInterface { /** * @param $model * @param RepositoryInterface $repository * @return mixed */ public function apply($model, Repository $repository){ $query = $model->where('length', '>', 120); return $query; } }استخدام للمعايير (Criteria) في المتحكّمات (Controllers)الآن وقد صارت لدينا معايير بسيطة، لنرَ كيف يمكننا استخدامها. هناك طريقتان يمكنك اتباعهما لتطبيق المعايير على مستودع. الأولى باستخدام طريقة ()pushCriteria: <?php namespace App\Http\Controllers; use App\Repositories\Criteria\Films\LengthOverTwoHours; use App\Repositories\FilmRepository as Film; class FilmsController extends Controller { /*** @var Film*/private $film; public function __construct(Film $film) { $this->film = $film; } public function index() { $this->film->pushCriteria(new LengthOverTwoHours()); return \Response::json($this->film->all()); } }هذه الطريقة مفيدة إذا كنت ترغب بتطبيق أكثر من معيار في نفس الوقت، حيث يمكنك رصّها معًا كما تشاء، ولكن إذا رغب بتطبيق معيار واحد فقط، فيمكنك استخدام طريقة ()getByCriteria: <?php namespace App\Http\Controllers; use App\Repositories\Criteria\Films\LengthOverTwoHours; use App\Repositories\FilmRepository as Film; class FilmsController extends Controller { /** * @var Film */ private $film; public function __construct(Film $film) { $this->film = $film; } public function index() { $criteria = new LengthOverTwoHours(); return \Response::json($this->film->getByCriteria($criteria)->all()); } }تثبيت الحزميمكنك تثبيت هذه الحزمة بإضافة الاعتمادية التالية إلى قسم require في ملف composer لديك: "bosnadev/repositories": "0.*"وتنفيذ composer update بعد ذلك، الخلاصةلاستخدام المستودعات في تطبيقك العديد من الفوائد. من أشياء بسيطة كتقليل تكرار الأكواد ومنعك من ارتكاب أخطاء برمجيّة وجعل تطبيقك أسهل في التكبير والتوسعة، والاختبار، والصيانة. من وجهة نظر هندسيّة، فقد تمكنت من عزل الاهتمامات. المتحكّم (controller) لديك ليس بحاجة لأن يعرف كيف وأين تخزَّن البيانات. بسيط وجميل. تجريديّ (Abstract). ترجمة وبتصرف للمقال: Using Repository Pattern in Laravel 5.

قبل أن نذهب إلى الموضوع الرئيسيّ للمقال، سأعطيك لمحة قصيرة عن مشاكل التصميم التي قد تواجهها. لقد اشتكى لي أحد زبائني بأن بعض الصفحات تفتح ببطء شديد. وعندما أقول ببطء شديد، فإنني أعني ذلك! فقررت أن أصحح تلك الصفحة (بعمل debugging)، وما رأيته قد صدمني. لقد أظهر لي قسم الاستعلامات (queries) أن تلك الصفحة كانت تنفَّذ بعد القيام بكم هائل من الاستعلامات تعدّى 16500 استعلامًا!! لقد وجدت أن جزءًا من النصّ البرمجي هو سبب تلك المشكلة. لقد كانت هناك ثلاث حلقات foreach تستعلم عن خاصيّة والخواص الفرعيّة التابعة لها. لقد كانت تعمل جيدًا إلى أن صار في قاعدة البيانات 5500 عنصرًا. وفيما يلي ما كان يحدث: $main_object = MainObject::all(); foreach($main_object as $object) { echo $object->some_property; foreach($object->related_object as $related) { echo $related->some_property; echo $related->another_property; } foreach($object->another_related as $another) { echo $another->some_property; echo $another->another_property; } }إذا كان الاستعلام ;()main_object = MainObject::all$ يعيد 5500 نتيجة، فستعيد حلقة foreach الأولى ذلك القدر أيضًا، وكذلك بالنسبة للثانية والثالثة. باستخدام ORM، كثيرًا ما يقع المبرمجون في فخّ كتابة استعلامات قواعد بيانات غير كفؤة، وتجعلها ORM أكثر صعوبة في الاكتشاف. تُسمّى هذه المشكلة بمشكلة N+1 (بالإنجليزيّة N+1 problem). وأظن المطور السابق لم يكن على علم بذلك. ولتفادي هذه المشكلة، نستخدم التحميل الحثيث (eager loading). ما هو التحميل الحثيث؟لتبسيط الأمر، التحميل الحثيث طريقة تُعنى بعمل كل شيء عند الطلب. وهذه الطريقة أيضًا على العكس تمامًا من التحميل الكسول (lazy loading) عندما ننفذ المهام عند الحاجة. يساعدنا التحميل الحثيث على تجنب مشكلات الأداء، كما رأيت في مثالي أعلاه. ستفهم الأمر أكثر من خلال مثال، لذا لنتخيل الوضع التالي: لدينا نموذج علاقة هيئة محسّنة (بالإنجليزيّة: Enhanced Entity Relationship، واختصارًا EER)، بثلاث هيئات، كلّ منها مرتبطة بالأخرى. يمكنك أن تقرأ EER كما يلي: يمكن لكل عضو أن يملك العديد من المحلات، ولكن المحل الواحد ملك لعضو واحد فقط. يمكن للمحل الواحد أن يحوي العديد من المنتجات، ولكن المنتج الواحد لا يكون إلّا في محل واحد. الخطوة التالية هي إنشاء نماذج Eloquent لهذه الهيئات: العضو: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Member extends Model { protected $fillable = ['username', 'email', 'first_name', 'last_name']; public function stores() { return $this->hasMany('App\\Store'); } }المحلّ: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Store extends Model { protected $fillable = ['name', 'slug', 'site', 'member_id']; public function member() { return $this->belongsTo('App\\Member'); } public function products() { return $this->hasMany('App\\Product'); } }المُنتَج: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Product extends Model { protected $fillable = ['name', 'short_desc', 'long_desc', 'price', 'store_id', 'member_id']; public function store() { return $this->belongsTo('App\\Store'); } }تخيّل أنك تبني تطبيقًا يسمح لمستخدميك أن يُنشئوا محالّهم التجاريّة الخاصّة. يمكن للمستخدمين –كما هو الحال بالنسبة للمحال الأخرى كلها طبعًا– أن يُنشئوا منتَجات عديدة. وأيضًا، يمكننا أن ننشئ صفحة واحدة تعرض كل المحلات وأفضل المنتجات لكل محلّ. شيء من قبيل هذا: يمكن أن ينتهي بك المطاف إلى الحصول على شيء كهذا في المتحكّم لديك: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->all(); return \View::make('stores.index')->with('stores', $stores); } }وفي العرض الذي ستقدم فيه تلك البيانات: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span><br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/>========================<br/> @endforeachوالنتيجة كالتالي: ومن اجل هذا المثال، زوّدت قاعدة البيانات بخمس مستخدمين، وثلاثة محالّ، وأربعة منتَجات. يقوم الاستعلام الأول باستدعاء كل المحال من قاعدة البيانات، وهذا هو الجزء +1 من مشكلة N+1. في هذا المثال تحديدًا، حرف N يمثّل عدد المحلات التي أرجعها لنا الاستعلام الأول، حيث أنها تمثل عدد المرات التي سنقوم فيها بالاستعلام select * from على جدولي products و members. وبما أن لدينا 3 محلات، فسنستعلم 3 مرات على جدول المستخدمين، وثلاث مرات على جدول المنتجات. وفي النهاية، قمنا بتنفيذ الاستعلامات بعدد مرات قدره 3+3+1. تخيل الآن ما الذي يمكن أن يحدث لو كان لديك 5000 أو 10000 محل؟ سيكون لديك في تلك الحالة عشرة آلاف إلى عشرين ألف استعلام في كل مرة يقوم فيها أحد المستخدمين بزيارة الصفحة. وماذا لو كانت لديك عشرة آلاف أو مئة ألف زيارة كلّ أربع وعشرين ساعة؟ هذا كابوس! من الواضح الآن أن هذا التوجّه مدمّر للأداء. وبغض النظر عن نوع قاعدة البيانات التي تستخدمها، وعن مدى قوة الخادم الذي لديك، فستصل دائمًا إل تلك النقطة التي يقف فيها العتاد القوي لديك عاجزًا. يمكنك أن تحسّن الأداء بعمل cache لهذه الاستعلامات، باستخدام Redis على سبيل المثال. سيؤدي هذا الغرض، ولكن لبعض الوقت فقط. وبتلك الطريقة، أنت فقط تؤجل النهاية الحتميّة التي ستكلّفك الكثير من المال والوقت، وفي الغالب ستفقد بعض الزبائن، أو أنّ قاعدة بياناتك ستضعف كثيرًا. وهنا يأتي التحميل الحثيث لينقذك من هذه الورطة. استخدام التحميل الحثيث في Laravel بسيط للغاية. العلاقات التي ترغب أن يتم تحميلها بشكل حثيث تحددها في طريقة with كما يلي: $stores = Store::with('member','products')->get();الآن، بدل استخدام 7 استعلامات، قلّلنا باستخدام التحميل الحثيث عدد الاستعلامات إلى 3 فقط: وستكون ثلاثة استعلامات حتى ولو كانت لديك عشرة آلاف مدخلة في جدول المحلات. وكما ترى، فإن الاستخدام السليم للتحميل الحثيث يمكن أن يؤدي إلى تحسين أداء تطبيقك بقدر هائل. ولكي نحصل على تحسن للأداء بالفعل، فعلينا أن نوجد فهرسًا لحقل الهويّة id في جدولي members و products. ومع وجود كمّ هائل من السجلات، فإن تنفيذ (... ,'in( '1', '2 على حقل غير مفهرس سيأخذ وقتًا طويلًا. وبعد هذه المقدمة عن التحميل الحثيث، هيا بنا نرى كيف يمكننا أن نستخدم العلاقات مع المستودعات. تمديد فئة المستودعسأريك طريقة واحدة يمكنك فيها أن تستخدم العلاقات في فئات مستودعات concrete. وهنا مثال عن النتيجة النهائيّة: function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); .... }وكما ترى هنا، لدينا طريقة with يمكنك أن تسلسل فيها نموذج العلاقات. ستكون هذه الطريقة شبيهة بطريقة with في Laravel’s Query Builder. public function with($relations) { if (is_string($relations)) $relations = func_get_args(); $this->with = $relations; return $this; }نحتاج الآن لأن نربط كلّ علاقة من العلاقات التي قمنا بتقديمها بالنموذج: protected function eagerLoadRelations() { if(!is_null($this->with)) { foreach ($this->with as $relation) { $this->model->with($relation); } } return $this; }وها هو ذا، والشيء الوحيد الذي تبقّى هو أن نحدّث طريقة مستودع ()all (وأي شيء آخر ترغب بتحديثه) لاستخدام التحميل الحثيث: public function all($columns = array('*')) { $this->applyCriteria(); $this->newQuery()->eagerLoadRelations(); return $this->model->get($columns); }وكما سبق وذكرت، فيمكنك أن تضيف عدّة علاقات ضمن طريقة ()with. وفيما يلي مثال على StoresControler: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); return \View::make('stores.index')->with('stores', $stores); } }وفي العرض يمكنك أن تعرض البيانات بالطريقة التي تريدها، ولغرض التجربة يكفي هذا: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span><br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/>========================<br/> @endforeachوكما هو متوقع، لدينا الآن هذه الاستعلامات الثلاثة فقط: الخلاصةيمكنك باستخدام التحميل الحثيث أن تحسّن أداء تطبيقك. وأحيانًا، عندما يكبر التطبيق، حتى التحميل الحثيث ليس كافيًا للحفاظ على أعلى أداء. في الدرس التالي سأريك كيف يمكنك تجميل مستودعاتك لتقوم بعمل cache للاستعلامات من أجل أداء أفضل. ترجمة -وبتصرف- للمقال: Using Repository Pattern in Laravel 5 - Eloquent Relations and Eager Loading.

عمل أطر مفرغة -أو تصاميم مبدئيّة- أثناء التصميم لا يكلف شيئًا تقريبًا، ولكن يمكنه أن يحقق عائدًا ممتازًا. ورغم أن العديد من المصممين يبدؤون برسم "سكِتش" في ذهنهم، ومن ثمّ يضعونه في برنامج فوتوشوب أو حتى يبدؤون بكتابة الأكواد مباشرة، بينما يبدأ آخرون على الورق. نعم، هو الورق العادي الذي تعرفه، والذي تكتب عليه بالقلم. يبدو هذا كتقنية عمرها عشر سنوات، ولكن حتى الآن ما زال أفضل المصممين في هذا العالم يستخدمونه لصالحهم. سيوفر عليك عمل تصميم مبدئيّ الكثيرَ من الإحباط في المراحل اللاحقة من تطوير المشروع، حيث يؤكّد بأنه ليس هناك أشياء عليك التراجع عنها أو إعادة تصميمها. إذا قمت بعمل تصميم أوليّ بطريقة سليمة، فبإمكانك أن تبيت مرتاح البال بأنك لن تضطر مستقبلًا لإعادة التصميم من البداية. إن ما تعنيه الأطر المفرغة هو وضع أفكار التصميم على الورق لكلّ من صفحات الموقع. في الغالب ستتشارك كل الصفحات ببعض العناصر، ولهذا فستكون الصفحة الأولى أكثر صعوبة في التصميم، بينما ستكون بقيتها أقل صعوبة، حيث تكون قد حصلت على فكرة مبدئيّة عن النمط العام للتصميم. أبق في بالك أن هذه العناصر مهمّة لأيّ تصميم. عندما تقلّب بين الصفحات، سيكون على المستخدم أن يقدر على التعرف على الصفحة وأن يعلم أنه لم يغادر الموقع ويذهب إلى موقع آخَر. أبق دائمًا على التنقلات والأقسام المهمة (المحتوى، الشريط الجانبي، ذيل الصفحة) في نفس المكان، ولكن هذا صار شائعًا كما لو أنه دليل للمبتدئين في التصميم، لذا لننتقل إلى أمور متقدمة أكثر. الأطر المفرغة – نظرة عامةلكي تكون قادرًا على استخدام إطار مفرغ، فأنت بحاجة إلى معرفة كيف يعمل. ما يفعله الإطار المفرغ بسيط، فهو يُظهِر الشكل العام للوقع والمكونات الرئيسيّة على الورق. يمكنك أن تستخدم أشكال مختلفة كصناديق وحاويات لرسم المحتوى فيها، وتنقلات، وعناصر وظيفيّة أخرى. قد تسأل نفسك، لم نستخدم الأشكال؟ الإجابة بسيطة: لأنها تسمح لنا بأن نركّز على التصميم أكثر وان ننسى الأكواد والتوافقية بين المتصفحات والصور وما إلى ذلك. إنه تصميم بسيط ونقيّ. الصورة من Zach Hoeken. الأطر المفرغة أم تصاميم فوتوشوب؟وكبديل عن التصاميم الأوليّة للمواقع على الورق، يمكن إنشاء التصميم المرئيّ على برنامج فوتوشوب أولًا. ورغم أن لها مزايا إلى حدّ ما، فإن إنشاء الشكل العام في فوتوشوب غير عمليّ، وذلك لأنه لا يسمح لك بالتركيز على العناصر الأساسيّة للتصميم. ولهذا، إذا أردت البدء بالتصميم في فوتوشوب، فقد تبدأ أيضًا بالتفكير في الألوان والصور والخطوط. لا حاجة لهذا الأمر إذا بدأت العمل على الورق. والعمل على الورق أسرع بكثير أيضًا، ولذا لِمَ لا تقوم بها بهذه الطريقة؟ ولهذا، يمكنك أن تبدأ التصميم في فوتوشوب في مرحلة لاحقة، ولكن لا أنصح بعمل ذلك قبل أن تكون لديك فكرة واضحة عن ما ترغب بالحصول عليه من المشروع. الطريقة الوحيدة لتحقيق ذلك هي البدء على الورق. يمكنك أن تدعو الإطار المُفرَغ بأنه "سكِتش" إذا أردت ذلك. وفي الحقيقة أن الأطر المفرغة هي سكتش بسيط للموقع. توصل الأطر المفرغة بعض الأفكار للزبون، حيث يمكنه أن يقبلها أو يرفضها. إذا رفضها، فسيكون من السهل بالنسبة لك أن تأخذ ورقة أخرى وترسم عليها أفكار أخرى من البداية. الهدف الأساسيّ من الأطر المفرغة هو أن تسمح لك بالتركيز على الأشياء المهمة في الموقع، وهي: كيف تبدو كل صفحة، وأين تقع أهم العناصر فيها، وكيف تحقق التوازن الإيجابيّ الذي تريده بشكل عام. وبعد أن تكون قد حصلت على فكرة عن ما يريده الزبون، ويقبل هو التقسيم الأساسي للموقع، يمكنك حينها أن تطوّر السكتش البسيط إلى شيء أكثر تفصيلاً. قد يكون الآن الوقت المناسب لبدء التفكير في الخطوط والألوان والصور. الصورة من Denkbeelhouwer. مرحلة عمل التصاميم الأوليةمن الضروريّ بالنسبة للمصممين والزبائن أن يعملوا معًا أثناء هذه المرحلة من المشروع. وحيث أنّه ليس لدى الزبون الكثير ليقوله أثناء مرحلة كتابة الأكواد، فهذه هي المرحلة التي يمكنه فيها تقديم الكثير من المدخلات التي عليك أن تأخذها بعين الاعتبار. تذكر أنه بمجرد موافقته على التصميم، فسيعطيك وهو راض حرية أكثر في الأفكار الأخرى؛ في هذه المرحلة يثق فيك وفي خبراتك. سيكون هذا مشروعًا طويلًا وصعبًا إذا لم تحصل منه على الموافقة على الإطار المفرغ الأساسيّ. إذا كنت زبونًا فتذكر أن لا تركز كثيرًا على عدم وجود ألوان وصور وخطوط وأمور أخرى تتعلق بالنمط. إن وظيفة المصمم في هذه المرحلة هي أن يعطيك فكرة بسيطة عن ما يراه بأنه جيد لك. إذا طلبت منه أطر مفرغة مفصلة أكثر ورفضتها ثلاثة أو أربعة مرات، فسيكلفك ذلك الكثير من المال. ومن ناحية أخرى، إذا طلبت أطر مفرغة بسيطة ورفضتها، فلن تكلفك بذلك القدر، وذلك لأن رسمها والتفكير فيها أسهل. أدوات لعمل تصاميم أولية للمواقعفيما يلي قائمة بالأدوات التي اختبرتها حديثًا لأرى إلى أيّ حد يمكن للمصممين الاعتماد عليها لبناء أطر مفرغة. إذا لم يكن الورق مناسبًا لك، فهناك خيارات أخرى ممكنة (دون ترتيب معين): 1. iPlotzتسمح ك هذه الأداة بأن تصنع أطر مفرغة يمكنك أن تنقر عليها وتتنقل خلالها. يسمح لك هذا بإنشاء تجربة مشابهة للموقع الحقيقيّ. ورغم أن بإمكانك الحصول على حساب مجانيّ، إلا أنني أنصحك بالحصول على واحد من حسابات Premium إذا كنت جادًّا في أن تبدأ بعمل التصاميم الأولية للمواقع واتخاذها كمهنة من الآن. 2. Balsamiqإذا كنت تحب الرسم، فستعطيك هذه الأداة شعورًا مشابهًا لذلك، إلا أنه رقميّ هذه المرة. يمكن تضبيط وإعادة ترتيب هذه الأدوات بسهولة، والتحكم بها سهل أيضًا. النتائج نظيفة، ومن المزايا الأخرى لها هو أنّ كل شيء يمكن تكرارها في الوقت الحقيقيّ. 3. Pencil Projectيمكن استخدام هذه الأداة لعمل مخططات انسيابية وتصاميم أوليّة للواجهات بسهولة. 4. templatrرغم أنه لن يسمح لك برسم أيّ شيء، إلى أن هذه الأداة تمكنك من إنشاء تصاميم لموقعك أثناء العمل. لست بحاجة لمعرفة HTML ويمكنك تنزيل القالب في النهاية بنقرة زر واحدة. 5. Flair Builderيمكن لهذه الأداة التفاعل مع الأطر المفرغة بسرعة عالية جدًّا. هذه الأداة سهلة الاستخدام وتأتي مع لوحة من العناصر الفعالة التي ستسهل مهمة إنشاء تصاميم أوليّة. هذه الأداة تفاعليّة، وستحسن تجربتك كثيرًا. صورة من Michael Lancaster. خلاصة القولالأطر المفرغة، أو التصاميم الأوليّة للمواقع، هي عملية يعرفها الكثير من المصممين، رغم أن القليل منهم فقط من يستخدمونها. ورغم أنها تبدو بأنها تأخذ الكثير من الوقت، إلا أنها -على المدى البعيد- ستساعدك كثيرًا. إذا كنت تعرف كيف تتواصل بطريقة سليمة وأن تعمل عن قرب مع الزبون، أثناء مرحلة عمل التصاميم الأولية، فستتم بقية العمل بسلاسة أكبر مما تتوقع. أنصحك كثيرًا أن تقوم بعمل تصميم أوليّ لعملك قبل البدء في كتابة الأكواد، أو أن تُنشئ التصميم الأولي بأكمله في فوتوشوب. هذا سيجعل المهمة كلها أسهل لك، وسيوفر عليك الكثير من الإحباط طوال مدة العمل. وإلى المرة القادمة، تواصل معنا في الردود، وأخبرنا برأيك. هل تقوم بعمل تصاميم أوليّة للتصاميم التي تعمل عليها؟ وما مدى جدوى ذلك بالنسبة لك؟ وإذا لم تكن تفعل ذلك، فلماذا؟ ترجمة -وبتصرف- للمقال: Beginner's Guide to Wireframes and Tools to Create Them.

تتطور أدوات التصميم المبدئي (prototype) للواجهات الرسومية UI بسرعة. لقد أتى إصدار فوتوشوب 2015 محمّلًا بمزايا جيدة تتعلق بـPreview CC الذي يسمح للمصممين بعرض ألواح التصميم الخاصة بهم وكذلك تراكيب الطبقات (layer comps) على الأجهزة. إن رؤية العمل ضمن سياقه على الأجهزة طريقة ثمينة لتقييم وتحسين المفهوم المتعلق بالتصميم. الوصول بالعمل إلى شاشات الأجهزة ذات العلاقة لهو مفتاح الوصول إلى توجهات تقديم المحتوى (content first approaches). التصميم الأولي الرقمي هام للمراحل اللاحقة، حيث يتم تحسين العمل وتطبيق التصميم المرئيّ عليه. سنناقش في هذا المقال الطرق المتبعة في المراحل الأولى للتصاميم الأولية الأقل دقّة التي يمكنك أن تطبقها قبل استخدام الأدوات الرقميّة، إضافة إلى ما عليك أن تبقيه في بالك عند عمل تصميم أولي لواجهة مستجيبة وواجهة تطبيق للأجهزة الكفيّة. ما هو التصميم الأولي (prototype)؟التعريف المفضل لدي لكلمة prototype تأتي من المصمم Adam St. John Lawrence: يعدّ المصممون مهارة التصميم الأوليّ مهارة أساسيّة، حيث يسمح التصميم الأولي باستكشاف أفكار عديدة بسرعة لعرض المفاهيم على زبائننا بدلًا من أن نصفها لهم، وأن نختبر التصاميم في مراحلها الأولى. الدقّة العالية والمنخفضةإن عملية التصميم التي تشمل حلقة من التصميم الأولي، والاختبار، ومعاودة الكرّة، تتيح أفضل فرصة ممكنة للحصول على منتج نهائي جيّد. دقّة التصميم الأولي ستزداد تدريجيًّا مع الوقت في المشروع، حيث تتضح الأفكار أكثر ويقترب الفريق أكثر نحو شيء جاهز للاستخدام. الطرق الأسرع والأرخص والأسهل في التنفيذ هي الأفضل في بداية المشروع. يجب أن تتطور دقة التصميم الأولي مع الوقت. لقد تم اقتباس المخطط أعلاه من Scott Klemmer. عمل سكتش على الورق سكِتشات المراحل الأولى تستعرض تجربة المستخدِم لتطبيق جهاز محمول. إن عمل سكتشات لهو من تقنيات التصميم الأولي الأكثر بساطة. السكتش (sketch، وجمعه سكِتشات) لا يُنتج بالضرورة تصميمًا أوليًّا، ولكن السكتشات هي لبنات البناء الأولى، وهي النسخة الأولى ومرحلة البداية للشيء الذي تعمل عليه. ليس من الضروري أن تجيد الرسم، ولا يتعلق الأمر بجعل الشيء يبدو جميلًا. إن المربعات والمستطيلات البسيطة ممتازة لرسم سكتشات غير دقيقة. يتعلق رسم السكتش في هذه المرحلة بالعمل على أفكار كثيرة بسرعة. ورسم السكِتشات (sketches) أداة تسمح بمشاركة الرؤية مع المعاونين (شركاء، زبائن، زملاء، ...). نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: يمكن أن تساعدك الرسومات البسيطة للواجهة (UI stencils) بأن ترسم سكِتشًا لعناصر الواجهة الشائعة الخاصة بمنصة معينة بسرعة.سيساعدك رسم عدة أحجام للشاشات بجانب بعضها بعضًا للمقارنة على التفكير في التصميم عبر أحجام شاشات متعددة. ارسم سكِتشاتك بحجم صغير ومتوسط وكبير بجانب بعضها، ولا تنتقل إلى صفحة أخرى قبل أن تأخذ جميع أحجام الصفحة التي تعمل عليها بعين الاعتبار.رسم سكِتش في نطاق العالم الحقيقي طريقة ممتازة لتكون واقعيًا فيما يتعلق بتناسب الحجم، وخاصة على الشاشات الصغيرة.القوالب الموجهة لشاشات اللمس على الأجهزة المحمولة رائعة للتأكد من أنها تناسب الفئة المستهدفة من مستخدمي الأجهزة ذات شاشات اللمس، حيث تكون أجهزتهم كبيرة بما يكفي لتناسب التصميم عند الاستمرار في العمل عليه. رسم سكِتشات على اللوح يسمح رسم السكِتش على اللوح بجعل العمل مرئيًّا لفريق أكبر. رسم سكِتشات على اللوح طريقة رائعة للعمل. هذا الوسيط (اللوح) على وجه الخصوص مناسب لجلسات رسم السكِتشات التعاونية. تشجّع المساحة الكبيرة والأقلام كبيرةُ الحجمِ على القيام بعمل أكبر وأقرب إلى مفهوم "سكِتش"، ويمكن أن يساعد أعضاء الفريق الخجولين أو المترددين على أن يشاركوا. إن العمل على لوح يعني أن أكثر من شخص يمكن أن يعملوا على نفس السكِتش أو الفكرة. يسهُل مسح السكِتشات المرسومة على لوح والإضافة إليها والعمل عليها، مما يعني أن أعضاء الفريق سيتمكنون من أن يعملوا على التفاصيل معاً وبسرعة. نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: أبقِ في بالك أن العمل على لوح بحجم كبير لا يعبر عن القيود التي تواجهك على شاشات أصغر. بمجرد أن يتم تطوير فكرة، حاول التبديل إلى رسم سكتشات بمقياس رسم 1:1 على الورق أو باستخدام مناطق محجوزة مسبقًا على اللوح لتقييد العمل.لا تنسَ أن توثِّق السكتشات! خذ صورًا للتقدم قبل أن تنتقل إلى شيء آخَر.للعمل على تصاميم مستجيبة، ارسم سكتشات لإصدارات صغيرة ومتوسطة وكبيرة لنفس الصفحة جنبًا إلى جنب.عمل تصاميم أوليّة على الورق: تصميم أولي بسيط على الورق في بداية العمل. يمكن للتصميم الأولي على الورق أن يتراوح مستويات مختلفة من الدقّة، من مجموعة سكتشات على أوراق منفصلة، إلى عمل تفصيليّ على الورق، إلى أُطُر مفرغة يمكن تصميمها حاسوبيًّا ثم طباعتها. اختبار التصاميم الأولية على الورق طريقة سهلة وغير مكلفة للتحقق من الأفكار. يمكنك أن تسأل المستخدمين أن يعبروا ببساطة عن ما يرونه، أو أن يقوموا بعمل اختبار يتعلق بالوظيفة. يمكن للإنسان أن يعمل كحاسوب وأن يُبدِل الصفحات أو يخرج نوافذ منبثقة وأن يتفاعل مع المستخدم بشكل عام. هذه طريقة فعَالة للغاية، ويتفاعل معها المشاركون بجدية. تُدعى هذه الطريقة من التصاميم الأولية لـ"ساحر أوز" (بالإنجليزية: “Wizard of Oz prototyping”، كما في الرواية الأمريكيّة). نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: يُمكِن للودجات (جمع وِدجَة، بالإنجليزية widget) أن تُمثَّل بورقة أو بطاقة.يُفضَّل العمل على التحجيم في هذه المرحلة، وخاصة إذا كنت تنوي اختبار الواجهة باستخدام النماذج الورقية.أنشئ إطارات أجهزة بالورق أو الورق المقوّى لعرض الصفحات بداخلها.أنشئ قوائم منسدلة وعناصر تفاعلية أخرى بقصّ وطيّ قطع الورق، حيث يمكن إلصاقها باستخدام اللاصق أو تمريرها عبر فتحات في الصفحة.الصق شاشات النموذج الأوليّ الورقيّة بأجهزة حقيقية لأخذ فكرة عن كيفيّة استخدام الناس للجهاز في سياق الواقع، وإلى أيّ حدّ يمكنهم أن يصلوا في الشاشة عند إمساكهم للجهاز في وضعيات مختلفة.التفاعل بلعب الأدوارالتفاعل جزء مهم من تجربة المستخدم (UX). تطوير هذه النماذج الأولية رقميًّا سيأخذ كثيرًا من الوقت ولن يكون واقعيًّا في المراحل الأولى من المشروع. من الطرق السريعة والمجدية اقتصاديًّا وممتعة لتجربة سلاسة التصميم والتفاعل معه: تمثيل الأدوار. أحد الأشخاص يمثل دور الصفحة أو التطبيق، والآخَر يلعب دور المستخدِم. يُساعد التفكير في تجربة المستخدم كمحادثة أو تفاعل ثنائيّ الاتجاه على التأكد من أنّ التجربة تتبع تسلسلًا منطقيًّا بشريًّا. يمكن أيضًا أن تكشف التعبيرات المتخصّصة أو التي يحتمل أن تكون مُبهمَة. نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: فكّر بالرسائل أو لغة التفاعل الخاصّة بالمنصة (البيئة، نظام التشغيل، الجهاز ...) عند تصميم واجهات الموبايل.خذ بعين الاعتبار الاختلاف في الشكل العام بين الأحجام المختلفة للشاشات، وكيف يمكن له أن يؤثر على المسار المحادثة/التفاعل.خلاصةها قد عرفت! ارسم سكتش، اختبر التصميم على الورق، وقم بتمثيل الأدوار التي تتعلق بطريقة التفاعل لتقفز إلى بداية متقدمة في إنشاء تجربة مستخدم ممتازة. ترجمة -وبتصرف- للمقال: Early Stage UX Prototyping: Tips for Mobile and Responsive Design لصاحبه: Linn Vizard. حقوق الصورة البارزة: Designed by Freepik.

استكشف الأفكار باستخدام ورقة وقلمإنّ استخدام الورقة والقلم طريقة جيدة لبدء عمل سير الاستخدام ورسم السكتشات (جمع سكِتش sketch) غير الدقيقة للتصميم. ويتيح الورق -كوسيط للتصميم- مرونة كبيرة ويسمح لك باستكشاف الأفكار وتجربة المفاهيم. قم بحل المشاكل بحرية على الورق دون الاضطرار لأن تفكر بكيفية حل هذه المشكلة باستخدام التطبيقات أو النصوص البرمجية. يضمن لك رسم السكتشات بأن تنشئ عددًا كبيرًا من الأفكار في وقت قصير. لا تبدِ اهتماما كبيرًا لعدم دقة أو ترتيب سكتشاتـك. عليك ببساطة أن تحدد أفكارك المبدئية وأن تحدد المفاهيم. يمكنك لاحقًا أن تأخذ أفضل العناصر وترتب أفكارك. إحدى التقنيات المفضلة لدي هي أن أنسخ بعض سكتشاتـي على آلة تصوير الأوراق، وأن أقطعها إلى أجزاء أساسية -بما يتسق مع شرح Brad Frost في Atomic Design-، ومن ثم أبدأ بإثراء مفهوم التصميم وذلك بتجميع وإعادة ترتيب العناصر. شخصيًّا، أجد أن تَحْريك قصاصات الورق يسمح لي بتحديد النمط والتفكير بكيفية تفاعل المستخدم مع حلول التصميم وتفسيره لرسائلي. لقد بدأت حديثًا باستخدام حاسوب محمول متصل بـCreative Cloude لتوريد الـسكتشات بسرعة إلى التطبيقات لتحسينها أكثر ولعمل تصاميم أولية سريعة. تعتمد إعادتك وتقييمك لحلول التصميم الخاصة بك على التدريب. ارسم سكتشات يوميًا وبتكرار ونفّذ تصاميم أولية. اتبع نمط ABC والذي يعني (Always Be Creating). هرم التصميميساعدك رسم سكتشات وتكرارها مراراً على التقدم في هرم التصميم. يسمح لك هذا أن تسير بأفكارك وتصميمك من حلول غير تفصيلية إلى تفصيلية، وأن تفصل التصميم بما يتناسب مع رسالة التواصل أو المنتج الرقمي. يعتمد هرم التصميم على مفهوم التصميم المتكامل Total Design لـ Stuart Pugh الذي يقسم الأنشطة إلى ست مراحل. أما بالنسبة للتصاميم الرقمية، فقد بسطتها إلى: رسم سكتشات، عمل أطر مفرغة، تمثيل، عمل تصاميم أولية. تذكر أن السكتش لا يساوي الإطار المفرغ. تخط النصوص الحافظة للمكان. استخدم محتوى حقيقيايجب أن يبدأ تصميم أيّ حل رقمي بمحتوى نابع من الحقيقة. النصوص الحافظة للمكان مجرد تقدير لأي تصميم ممكن. يجب أن يشمل تصميمك سياقًا للمحتوى المقدم للمستخدمين (وللزبائن). يمكن أن يُفضي استخدام المحتوى الحافظ للمكان إلى اتخاذ قرارات تصميم خاطئة يمكن أن تؤثر على التصميم وعلى التطوير في المستقبل. لقد رأيت ما لا يعد من النماذج والتصاميم الأولية التي فيها عبارة "Bob Smith, job title here". استخدم محتوى حقيقيًّا لتعرف كيف سيبدو تصميمك متى تمّ إكماله. ستساعدك النسخة الحقيقية من المحتوى على تحديد طول مستطيلات الإدخال في نماذج الوِب، وطول الأقسام وأشرطة التمرير الجانبية. ستعطيك النصوص الحافظة للمكان (lorem ipsum) شعورًا مزيفًا بالأمن وستؤدي إلى افتراضات غير واقعية عن عمل التصميم الخاص بك. ستصمم لتصل إلى مقدار مثالي من النسخ أو المحتوى، والتي لا تحدث أيّ منها في العالم الحقيقيّ. قم باتخاذ قرارات التصميم التي تدعم المحتوى. التصميم يحدد كيفية العملإن البساطة هي الهدف عند تصميم الواجهات وتجربة المستخدم. إن مراجعة حالات الاستخدام وقصص العمل يمكن أن تساعد على تشكيل الواجهة والتخلص من النقاط غير السلسة في طريقة التفاعل بين المستخدم والتصميم. ولكننا ما زلنا لا نعرف بالضبط من سيكون المستخدم النهائيّ أو كيف سيتفاعل مع الواجهة. من المهم لنا كمختصين في تصميم الواجهات وتجربة المستخدم أن ننشئ واجهات ترضي احتياجات كلّ من المستخدمين المبتدئين والخبراء؛ واجهات يسهل تعلمها دون أن تكون متعالية على المستخدم. يتطلب منا الانتقال من النقطة أ إلى النقطة ب أن نصل جسرًا في الهوة بين المستخدم المبتدئ والمتقدم، وذلك باستخدام تلميحات بصرية وتغذية راجعة للمستخدمين المبتدئين، وإتاحة مزايا متقدمة يمكن أن يتعلمها ويستكشفها المستخدمون المتقدمون. اختبر الافتراضات في المتصفحاختبر مبكرًا. اختبر بكثرة. قدم سياقًا للاستخدام. ابن تصميمًا أوليًّا يمكن أن يستخدَم في المتصفحات أو الأجهزة المحمولة وذلك لاختبار افتراضات التصميم التي لديك عبر التصاميم الأولية وذلك للتحقق من أفكارك وحلولك. صمم -باستخدام التصاميم الأولية- تجربة استخدام لا تحتاج لتعلم مسبق، وإنشاء أدوات وواجهات لا يلاحظ المستخدمون أنهم يستخدمونه، الأدوات والتفاعلات التي تتحول إلى جزء من المستخدم. جهّز البيئة للتفاعل مع المستخدم، وللإبقاء على تفاعل مستمر بسيط وسريع وطبيعي. وبالتأكيد، عليك أن تصمم لشاشات اللمس. قائمة التحقق من أدوات تصميم تجربة المستخدم:قلم رصاص وممحاة.أقلام حبر شبه سائلة (جِل)، وهي المفضلة لدي.مسطرة.دفتر رسم سكتشات (إما بورق غير مسطور أو ورق مربعات).أقلام بتدرجات رمادية.شبلونة رسم مفرغة.قصاصات ورقية ملونة.أقلام (ماركَر).هل هناك شيء آخَر ترغب بإضافته إلى هذه القائمة؟ أخبرنا في التعليقات. رحلة تصميم موفقة! ترجمة -وبتصرف- للمقال: Sketch, Iterate, Repeat: Prototyping Your Website Design لصاحبه: Andrew Smyk. حقوق الصورة البارزة: Designed by Freepik.

إن آخر ما تريد سماعه من المستخدم لديك عند دخوله إلى موقعك لأول مرة هو "لحظة، ما الذي علي أن أفعله هنا بالضبط؟!" يمكن أن يكون تصميم عناصر الانتقالات أمرًا شائكًا، وخاصة إذا تركته للأخير بجعلها العنصر الأخير الذي ستقوم بتحسينه عند الاقتراب من الانتهاء من المشروع بأكمله. إنّ توجّهًا كهذا لا يمكن أن ينتهي نهاية حيدة، وهو بالتأكيد ليس الطريق السليم لتصميم عناصر التنقلات. إن التحدي هنا هو أنّ تصميم عناصر التنقلات لا يتعلق فقط بالقوائم التي ستستخدمها وأين ستضع تلك القوائم. يجب أن يبدأ هذا التوجه قبل ذلك بكثير. في الواقع، يفترض أن تعمل عليها منذ اليوم الأول في الوقت الذي تخطط فيه لتصميمك التالي. ولهذا، فما ستقرأه هنا هو دليل موجز: أساسيّات تصميم عناصر التنقلات. أول ما سنركز عليه هنا هو فصل الأشياء الضرورية للتنقل السليم عن غير الهامّة. ونبدأ بما يلي: إن الانطباع الأول هو ما يحدد النجاح أو الخسارةلدى كل منا موقع في العلامات (bookmarks) نستمتع بزيارته رغم سوء تصميم عناصر التنقلات فيه، أليس كذلك؟ لقد تعلمنا بطريقة ما أن نتنقل فيه وأن نحصل على محتواه، رغم صعوبة التنقلات. ما أحاول قوله هنا هو أن الزائر العادي لديك سيتعلم كيف يتعامل مع موقعك مع الوقت، بغض النظر عن مدى سوء تصميم عناصر التنقلات. أما عن زوارك الجدد، فهم فئة أخرى مختلفة تمامًا، ومن شبه المؤكد أنهم لن يتمتعوا بهذا القدر من التفاني والدافعية لتخطي هذه العقبات. ولهذا، فعند العمل على تصميم عناصر التنقلات لديك، عليك أن تركّز على التجربة الأولى للمستخدم قبل أيّ شيء آخَر. إن الانطباع الأول هو ما سيدعو المستخدم لأن يرجع، أو سيخيفه ويبعده بعيدًا عن الموقع. يبدأ التنقل الجيد بهيكلية جيدة للمحتوىفي الواقع الأمر سهل: المحتوى أولًا، ثم القوائم. يجب ان لا يكون تصميم عناصر التنقلات فكرة متأخرة، بل أن يكون نتيجة مباشرة لهيكلية المعلومات التي على الموقع. وبعبارة أخرى فإن الطريقة التي تصمم بها هيكلية المحتوى للموقع ستؤثر على الطريقة التي ستصمم بها عناصر التنقلات، وليس العكس. إن أحد الاحتمالات طريقة فرز البطاقات وهي طريقة لبدء تصميم هيكلية المعلومات وفرزها حسب الأولوية. إن طريقة فرز البطاقات طريقة يتم عملها دون استخدام الحاسوب، ويستخدم فيها المشاركون بطاقات حقيقيّة (قطع من الورق) لترتيب الموضوعات في مجموعات. دائما فكر بأهدافك أنتتُعلمُنا إحدى مدارس تصميم عناصر التنقلات أن نركز دائمًا على ما يريد المستخدم عمله أولًا: اهتم بأهداف المستخدمين أولًا. قد تكون هذه استراتيجية حكيمة في بعض الحالات، ولكنها ليست دائمًا الأفضل من وجهة نظر تجارية. يتعلق الأمر بعلاقته بأهدافك (أو أهداف عميلك) التجارية للموقع. بدلًا من ذلك، رتب تنقلاتك اعتمادًا على المكان الذي ترغب أن يذهب مستخدموك إليه، وليس بالضرورة أن يكون هذا هو ما يريدون هم الذهاب إليه. ربما علي أن أعيد صياغة ذلك. لا يتعلق الأمر بعمل الأشياء بما يخالف نيّة المستخدِم، بل بربط أهداف المستخدم بأهدافك أنت. فمثلًا، قد يرغب مستخدموك بترشيح (فلترة) قائمة التنزيلات لديك ليروا العروض المجانية فقط، ولكن هل الخيار الأفضل من وجهة نظر تجارية أن تسمح لهم بعمل ذلك؟ بدلًا من ذلك، يمكنك أن تجد حلًّا وسطًا بعرض قائمة كاملًا للتنزيلات، مع إعطاء التنزيلات المجانية تركيزًا إضافيًّا (بحيث يتمكن المستخدم من تمييز الأشياء المجانية، ولكن ستُعرض عليهم عروض أخرى مدفوعة). خمن طريقة تفكير المستخدميتعلق هذا القسم من المقال بتخمين طريقة تفكير المستخدِم عند زيارته لموقعك. بشكل عام، هل يعرف الزوار ما يبحثون عنه؟ أم عليك أن تساعدهم في ذلك؟ دعني أعرض عليك مثالين هنا: المثال الأول: جوجل. كل من يذهب إلى موقع جوجل يعرف تمامًا ما يبحث عنه. كل ما يحتاجه الزائر هو حقل إدخال للبحث يمكنه أن يضع فيه الموضوع الذي يبحث عنه وحسب. المثال الثاني: المدونات العاديّة. الزائر العاديّ للمدونة قد لا يعرف ما يبحث عنه بالتحديد. يعرف الزائر أنه يرغب بتلقي محتوىً جيّد، لكن عندما يتعلق الأمر بمقال معين سيقدم إليه، فهنا يأتي دورك بأن تقدم إليه المقال المناسب. ستحتاج في هذه الحالة إلى هيكلية تنقلات أكثر تطورًا من مجرد شريط بحث. تحتاج إلى قوائم، وإلى تصنيفات، وربما تحتاج إلى أرشيف، وما إلى ذلك. ولهذا، فعليك أن تصمم عناصر التنقلات في موقعك بناءً على توقعاتك لطريقة تفكير الزائر. إذا كان هناك انفصال (أيّ، لم تكن هناك تنقلات وروابط مناسبة)، فلن تكون لدى الزائر أدنى فكرة عن ما عليه فعله في موقعك، أو لن يكون بإمكانه تلقي أيّ من المحتوى. يجب أن تكون التنقلات مألوفةمن أكثر الأخطاء التي يقع فيها المصممون شيوعًا عند بنائهم لموقع هو أن يكونوا مبدعين أكثر من اللازم في توجهاتهم المتعلقة بالتنقلات. رغم صعوبة مقاومة الإبداع -خاصة أنّ أغلب أجزاء بناء الموقع تتطلبه- إلّا أنه من الأفضل العمل بأساليب مجرّبة عندما يتعلق الأمر بتصميم التنقلات. وفوق كل شيء، يجب أن لا يكون التنقل مُربكًا. يجب أن يتمكن جميع المستخدمين من تمييز القوائم بمجرد رؤيتها، دون أن يضطروا للبحث عنها. وبمناسبة الحديث عن ذلك، فهذا ليس رأيي وحدي. لقد طلبت من Robert Hapiuc -وهو مصمم في CodeinWP blog- أن يشاركني رأيه فيما يراها الأخطاء الأكثر شيوعًا التي يقع فيها مصممو المواقع عندما يتعلق الأمر بتصميم التنقلات. وفيما يلي ما قال: باختصار، اجعل بنية التنقلات لديك سهلة الفهم، ولا تحاول أن تذهب بعيدًا بإبداعك. اجعل القوائم وعناصر الموقع التي تشكّل التنقلات واضحة قدر الإمكان. إضافة إلى ذلك، لا تبدع أكثر من اللازم في إبراز التنقلات في موقعك. فمثلًا، لا بأس بحركات لتصاميم المسطحة، لكن جعلها متقدّمة ومعقدة جدًّا سيبعد المستخدمين وسيقلل من قابلية الاستخدام. والأهم من هذا كلّه: لا تتجاهل الأعراف المتبعة في الشبكة العنكبوتيةالعديد من أعراف الشبكة العنكبوتية قد رافقتنا لسنوات لسبب. ومن هذه الأشياء سلّة أو عربة التسوق في الزاوية اليمنى العليا للصفحة، أو روابط الولوج/الملف الشخصي في نفس المكان. لقد اعتاد المستخدمون على أن يروها في ذلك المكان، ومحاولة الخروج بمفهوم مختلف لن ينتج عنه إلا إرباك المستخدم. لذا، فالقاعدة الرئيسيّة هي الالتزام بالأعراف الموجودة، وجعلها توافق تصميمك، ولا تعد اختراع العجلة دون داعٍ. أظهر المحتوى الرئيسي بما يكفيبناء تنقلاتك حول المحتوى الرئيسيّ للموقع بداية جيدة. إن تجربة فرز البطاقات المذكورة أعلاه ستعطيك لمحة عامة عن تصنيفات المحتوى الرئيسيّ ومدى أهمية الدور الذي تلعبه في الموقع بأكمله. ستحتاج أيضًا لأن تنظر في أجزاء المحتوى الرئيسيّة المتعلقة بما يقدمه الموقع. فمثلًا، ليس عيبًا أن تضع رابطًا لجزئيّة معينة من المحتوى في القائمة العليا للموقع إذا كان هذا المحتوى هامًّا بما يكفي. لا تقع في فخّ بناء تنقلاتك حول القطاعات أو التصنيفات الرئيسيّة للمحتوى. قد يكون توجه كهذا قد يكون جيدًا لموقع دليل (مثل Alltop)، ولكنه لن يكون فعالًا على المدى البعيد لمواقع من نوع آخر. وهذا لأن تصميم عناصر التنقلات بناء على التصنيفات وحدها يتطلب أن يكون الزائر على اطلاع على ما يُتوقَّع أن يجد في كل تصنيف. (هناك مشكلة مشابهة في القوائم المنسدلة، والتي سنأتي على ذكرها لاحقًا في هذا المقال). أي نوع من عناصر التنقلات أستخدم؟هل نوع عناصر التنقلات التي تستخدمها مهم؟ هل هناك ميزة هامّة لاستخدام شريط التنقل العلوي (top nav. menus) بدلًا من القوائم المنسدلة الكبيرة (mega menus)؟ هل القوائم المنسدلة هي الطريقة السليمة؟ كالعادة -وكم أكره أن أقولها- هذا يعتمد على عدة أمور. الأنواع المختلفة لعناصر التنقلات مناسبة لحالات مختلفة، ولكن عليك أن تعرف خصائصها لتتمكن من اختيار النموذج المناسب لك بدقة. أشرطة التنقل العلوية (top nav bars)هي أداة التنقل الأكثر شيوعًا وربما الأكثر عمليّة. وأما عن عيبها الوحيد، فهو أنها تتسع فقط لقدر محدّد من العناصر. ولكن لا يشترط أن يكون هذا عيبًا. يتطلب استخدامك لشريط الانتقال العلويّ أن تراجع أولوياتك، بحيث تختار فقط أهم العناصر لتعرضها في الشريط العلويّ. كما وتجعل هذه الأشرطة اختيارات المستخدم أسهل. وفي النهاية، يذكرني هذا الكلام بالمثل العربيّ القائل "خير الكلام ما قلّ ودلّ"، والمثل الأجنبي القائل "less is more”. ويشير Dragos Bubu -وهو مصمم في ThemeIsle- أيضًا إلى قضية وجود أشياء أكثر من اللازم ضمن عناصر التنقلات الأساسيّة في حديثه عن الأخطاء الأساسيّة التي يقع فيها مصممو المواقع عند العمل على عناصر التنقلات في المواقع، إذ يقول: القوائم الجانبيةمن خيارات التنقلات الأقرب للموضة هذه الأيام وضع قائمة على الجانب. وبشكل عام، قد يكون هذا حلًّا جيدًا لبعض المواقع، ولكن هذا بشكل رئيسيّ للمواقع التي فيها تصنيفات كثيرة للمحتوى بحيث تتحول هذه التصنيفات نفسها إلى محتوى. وينطبق هذا أيضًا على المواقع التي فيها مرشّحات (فلاتر) يمكن للمستخدم ضبطها باستمرار أثناء تصفّح الجزء الخاص بالمحتوى الرئيسيّ. إن موقعًا صغيرًا يُدعى eBay مثال جيد على هذا. الجانب السلبي لهذه القوائم هو أنها يمكن أن تجذب قدرًا كبيرًا من اهتمام الزائر وتحدّ من ظهور وجاذبيّة الجزء الخاصّ بالمحتوى الرئيسيّ. وفي النهاية، لدينا نوع القوائم الأكثر إثارة للجدل، وهو القوائم المنسدلة (drop-down)مبدئيًّا، لا يوجد ما يعيب القوائم المنسدلة كأداة انتقال. المشكلة هي أن العديد من مصممي المواقع يلجؤون إليها عندما تنفد المساحة في شريط التنقل الرئيسيّ. هذا ليس الحلّ الأنسب. هذا يقلل قابليّة الاستخدام للموقع بأكمله لأن المستخدم لا يستطيع تخمين ما سيجد في هذه القوائم، ولهذا فلن يكون لديه دافع لينقر عليها. وكقاعدة رئيسيّة، القوائم المنسدلة بشكل عام جيدة فقط للقوائم التي يستطيع المستخدم أن يتنبأ بما في داخلها 100% دون أخطاء. فمثلًا، إذا كنت تريد من المستخدم أن يختار المحافظة أو المدينة أو الدولة التي يسكن فيها، فالقوائم المنسدلة خيار مثاليّ. ولكن عندما ترغب بعرض مجموعة قياسية من عناصر القائمة، فلن تكون خيارًا جيدًا. إضافة إلى هذا، ضمِّن تلميحات بصريّة إضافية عند استخدامك قوائم منسدلة، فمثلًا استخدم رمز المثلث الذي يوحي للمستخدم بوجود المزيد عند تمريره مؤشر الفأرة فوق القائمة. اسع إلى النجاح على المدى البعيدكما بالنسبة لمعظم نواحي تصميم المواقع، فمن المرجح أنك لن تصمم هيكلية التنقل الصحيحة في تجربتك الأولى مقارنة بما ستحققه عند رجوعك إلى التصميم والعمل على تحسينه. باختصار، تحقق من الأنماط، وتتبّع سلوك المستخدمين في موقعك والطريق الذي يتبعونه. ستتمكن مع الوقت من تحسين كفاءة التنقلات بجعل العناصر الأكثر استخدامًا مرئيّة أكثر، وبنقل الأقل استخدامًا إلى مكان أقل بروزًا. ما التالي؟تصميم عناصر التنقلات موضوع واسع إذا كنت ترغب باحترافه. وما تزال هناك الكثير من الأشياء التي لم نناقشها في هذا الدليل، ومنها: طريقة التعامل مع تنظيم المعلومات في صفحات المحتوى كلًّا على حدة (أين تضع الصور والنصوص والروابط)، واستخدام آليّات متقدمة للتنقلات، كالصفحات المنفصلة، وخرائط المواقع، والوسوم، والتنقلات الثابتة، وما إلى ذلك. أرى أن ندع الباقي إلى يوم آخَر، ونتوقف هنا لنسمح لعقلنا أن يتشرّب هذه المعلومات. ما رأيك؟ وما هي استراتيجيتك في تصميم عناصر تنقلات فعالة تقوم بمهمتها على أكمل وجه؟ ترجمة -وبتصرف- للمقال: Navigation Design 101 لصاحبته Karol K.

تُستخدَم قواعد البيانات العلاقيّة منذ وقت طويل. لقد اكتسبت قواعد البيانات من هذا النوع شُهرة بفضل أنظمة إدارتها التي تستخدم النموذج العلاقيّ بشكل جيّد للغاية، وهو النموذج الذي أثبت نفسه كطريقة رائعة للتعامل مع البيانات وخاصة في التطبيقات ذات المهام الحرجة. سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (RDBMS) شُهرة واستخدامًا. سنستكشف الفروقات الرئيسيّة بينها من حيث المزايا والأداء الوظيفيّ، وكيفية عملها، ومتى تتفوق إحداها على الأخرى، وذلك من أجل مساعدة المطورين على اختيار نظام إدارة قواعد بيانات علاقية (RDBMS). أنظمة إدارة قواعد البيانات قواعد البيانات هي مساحات تخزين مرتبة منطقيًّا لكل الأنواع المختلفة من المعلومات (البيانات). لكل نوع من قواعد البيانات –باستثناء عديمة المخطط– نموذج يقدم هيكلة للبيانات التي يتم التعامل معها. أنظمة إدارة قواعد البيانات هي تطبيقات (أو مكتبات) تدير قواعد البيانات بأشكالها وأحجامها وأنواعها المختلفة. أنظمة إدارة قواعد البيانات العلاقية تستخدم أنظمة قواعد البيانات العلاقيّة النموذج العلاقيّ للعمل على البيانات. يشكّل النموذج العلاقيّ المعلومات التي ستُخَزَّن مهما كان نوعها، وذلك بتعريفها ككيانات مترابطة ذات خصائص تتعدى الجداول (أي مخططات). تتطلب أنظمة إدارة قواعد البيانات من هذا النوع أن تكون البُنى (كالجداول مثلًا) معرّفة لتحوي بيانات وتتعامل معها. لكلّ عمود (مثل الخصائص) في الجداول نوعٌ مختلف من المعلومات (نوع البيانات). يُترجَم كلّ سجلّ في قاعدة البيانات –مُعرّف بمفتاح فريد– إلى صفّ ينتمي إلى جدول، وتكون مجموعة خصائص كل سجل معروضة كأعمدة للجدول. وتكون كلها مرتبطة ببعضها كما هو محدد في النموذج العلاقيّ. العلاقات وأنواع البيانات يمكن اعتبار العلاقات مجموعات حسابية تحوي مجموعة من الخصائص التي تشكّل معًا قاعدة البيانات والمعلومات المحفوظة فيها. تسمح هذه الطريقة في التعريف والتجميع لقواعد البيانات العلاقيّة بالعمل بالطريقة التي تعمل بها. عند تعريف جدول لإدخال سجلات، يجب أن يطابق كلّ عنصر يشكل سجلًّا (كالصفة attribute مثلًا) نوع البيانات المحدّد له (كأن يكون عددًا صحيحًا أو تاريخًا مثلًا). تستخدم أنظمة إدارة قواعد البيانات العلاقيّة أنواعًا مختلفة من البيانات ولا يمكن في العادة تبديل واحدة من هذه الأنواع مكان الأخرى. التعامل مع وعبر قيود –كالتي ذكرناها قبل قليل– شائع مع قواعد البيانات العلاقيّة. في الحقيقة، تشكّل القيودُ مركزَ العلاقات. ملاحظة: إذا كنت تحتاج للتعامل مع معلومات غير مترابطة إطلاقًا وممثلة عشوائيًّا (كالمستندات مثلًا)، فقد تكون مهتمًّا باستخدام NoSQL (قواعد البيانات عديمة المخططات schema-less). قواعد بيانات علاقية شائعة وهامة سنتعرف في هذا المقال على ثلاثة أنواع رئيسيّة وهامّة من أنظمة إدارة قواعد البيانات العلاقيّة مفتوحة المصدر التي ساهمت في تكوين عالم تطوير البرمجيات: SQLite: نظام إدارة قواعد بيانات علاقيّة مضمّن وقويّ جدًّا. MySQL: نظام إدارة قواعد البيانات العلاقيّة الأشهر والأكثر استخدامًا. PostgreSQL: نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر المتوافق مع SQL الأكثر تقدّمًا. ملاحظة: تقريبًا دائمًا تتيح التطبيقات مفتوحة المصدر حريّة استخدام الطريقة التي تريدها. وفي غالب الأحيان تسمح لك أيضًا إنشاء تفرّع (fork) عن المشروع (وبالتالي استخدام نصوصه البرمجيّة) لإنشاء شيء جديد. إذا كنت مهتمًّا بأنظمة إدارة قواعد البيانات، فقد ترغب بالاطلاع على بعض المشاريع المتفرّعة المبنية على هذه المشاريع الشهيرة، مثل MariaDB. SQLite إنّ SQLite مكتبة رائعة تُضمَّن في التطبيقات التي تستخدمها. وكونها قاعدة بيانات قائمة بذاتها ومعتمدة على الملفات. تقدّم SQLite مجموعة رائعة من الأدوات للتعامل مع كل أنواع البيانات بقيود أقلّ بكثير وسهولة مقارنة بقواعد البيانات المستضافة المعتمدة على العمليات (خواديم قواعد البيانات). عندما يستخدم برنامج ما SQLite، يعمل هذا التكامل بنداءات (calls) مباشرة ومؤدية للغرض موجهة لملف يحوي البيانات (كقاعدة بيانات SQLite) بدلًا من التواصل عبر واجهة من نوع ما (كالمنافذ ports والمقابس sockets). هذا يجعل SQLite كفؤة وسريعة للغاية، وقويّة كذلك، وهذا بفضل التقنية التي بنيت عليها هذه المكتبة. أنواع البيانات التي تدعمها SQLite: NULL: قيمة فارغة NULL. INTEGER: عدد صحيح ذو إشارة (موجب أو سالب) محفوظ في بايت واحد، 2، 3، 4، 6، أو 8 بايت، وهذا يعتمد على حجم القيمة. REAL: قيمة النقطة العائمة (floating point)، مخزنة كرقم نقطة IEEE عائمة ذي 8-بايت. TEXT: سلسلة نصيّة مخزنة باستخدام ترميز قاعدة البيانات (UTF-8, UTF-16BE or UTF-16LE). BLOB: فقاعة من البيانات، تخزّن كما أدخِلَت تمامًا. ملاحظة: لمعرفة المزيد عن أنواع بيانات SQLite والعلاقات بين أنواع SQLite، ألقِ نظرة على التوثيق الرسميّ حول الموضوع. مزايا SQLite: معتمدة على الملفات: تتكون قاعدة البيانات بأكملها من ملف واحد على القرص، مما يجعلها محمولة تمامًا. مدركة للمعايير: رغم أنها قد تبدو كتطبيق قواعد بيانات "بسيط"، إلّا أن SQLite تستخدم SQL. ورغم أنّها أزالت بعض المزايا ( RIGHT OUTER JOIN أو FOR EACH STATEMENT) إلّا أنها تحوي بداخلها مزايا أخرى إضافيّة. ممتازة للتطوير، بل وحتى للاختبار: أثناء مرحلة تطوير التطبيقات، في الغالب يحتاج أغلب الناس لحلّ يمكن تطويعه للطلبات المتعدّدة. لدى SQLite قاعدة مزايا غنيّة، ويمكنها تقديم أكثر مما تحتاجه للتطوير، وبسهولة العمل مع ملف وحيد ومكتبة مرتبطة مبنية على C. عيوب SQLite: لا توفّر إدارة للمستخدمين: تأتي قواعد البيانات المتقدّمة بإدارة للمستخدمين –فمثلًا، فيها اتصالات مُدارة بصلاحيات الوصول إلى قواعد البيانات والجداول–. وبأخذ هدف وطبيعة SQLite بعين الاعتبار (عدم وجود مستوىً عالٍ من تعدّد المستخدمين في ذات الوقت)، لا وجود لهذه الميزة. عدم توفر إمكانية التلاعب بها للحصول على أداء أفضل: ونظرًا لطبيعة تصميمها أيضًا، لا يمكن التلاعب بـ SQLite للحصول على قدر كبير من الأداء. المكتبة سهلة الضبط والاستخدام. وبما أنها ليست معقّدة، فلا يمكن تقنيًّا جعلها أكثر أداءًا مما هي عليه، وبشكل يفوق أداءها الحاليّ الرائع. متى تستخدم SQLite: التطبيقات المضمّنة: كلّ التطبيقات التي تحتاج لقابليّة النقل، والتي لا تحتاج لتحجيم، كتطبيقات المستخدم المحلي والوحيد، وتطبيقات الهاتف النقّال أو الألعاب. كبديل عن الوصول إلى القرص: في العديد من الحالات، يمكن أن تستفيد التطبيقات التي تحتاج للقراءة من والكتابة إلى الملفات على القرص مباشرة من الانتقال إلى SQLite من أجل المزيد من الوظائف والسهولة اللتان تأتيان من استخدام لغة الاستعلام البنيويّة (Structured Query Language – SQL). الاختبار: من التبذير أن تستخدم نسبة كبيرة من التطبيقات عمليّة إضافيّة لاختبار منطقيّة العمل (أي الهدف الرئيسيّ للتطبيق: الوظيفيّة). متى لا تستخدم SQLite: في التطبيقات متعدّدة المستخدمين: إذا كنت تعمل على تطبيق يحتاج فيه العديد من المستخدمين الوصول إلى نفس قاعدة البيانات واستخدامها، فالغالب أنّ مدير قواعد بيانات علاقيّ كامل المزايا (مثل MySQL) خيار أفضل من SQLite. في التطبيقات التي تحتاج لقدر كبير من الكتابة: من محدوديّات SQLite عمليات الكتابة. يسمح نظام إدارة قواعد البيانات هذا عملية كتابة واحدة وحيدة أن تتم في وقت محدّد، مما يسمح بقدر محدود من الدفق. MySQL تعد MySQL أشهر خوادم قواعد البيانات الكبيرة. وهو منتج مفتوح المصدر غنيّ بالمزايا، ويشغّل الكثير من المواقع والتطبيقات على الإنترنت. من السهل البدء باستخدام MySQL، ولدى المطورين وصول إلى كمّ هائل من المعلومات المتعلقة بقواعد البيانات على الإنترنت. ملاحظة: يجب أن نذكر أنّه نتيجة لشيوع المُنتَج، فإنّ هناك الكثير من تطبيقات الشركات الأخرى وأدواتها ومكتباتها المضمّنة التي تساعد كثيرًا في الهديد من نواحي العمل مع نظام إدارة قواعد البيانات العلاقيّة هذا. ورغم عدم محاولتها تطبيق معيار SQL كامل، إلّا أنّ MySQL تقدّم الكثير من الوظائف للمستخدمين. وكخادم SQL قائم بذاته، تتصل التطبيقات بعملية مراقب MySQL (وهو تطبيق يعمل في الخلفية بعيدًا عن مرأى المستخدم، ويشار إليه أحيانًا بعبارة جنيّ أو عفريت) للوصول إلى قواعد البيانات ذاتها على خلاف SQLite. أنواع البيانات التي تدعمها MySQL: TINYINT: عدد صحيح متناهي الصغر. SMALLINT: عدد صحيح صغير. MEDIUMINT: عدد صحيح متوسّط الحجم. INT or INTEGER: عدد صحيح بحجم عاديّ. BIGINT: عدد صحيح كبير. FLOAT: عدد بفاصلة عائمة صغير أحاديّ الدقّة (single-precision floating-point). لا يمكن إلغاؤه. DOUBLE, DOUBLE PRECISION, REAL: عدد بفاصلة عائمة متوسط الحجم مزدوج الدقّة (normal-size/double-precision floating-point). لا يمكن إلغاؤه. DECIMAL, NUMERIC: عدد بفاصلة عائمة غير مُحتوىً. لا يمكن إلغاؤه. DATE: تاريخ. DATETIME: تجميعة من الوقت والتاريخ TIMESTAMP: ختم زمني (وقت وتاريخ حدوث حدث ما). TIME: وقت. YEAR: سنة بهيئة منزلتين أو أربعة منازل (المبدئيّ 4 منازل). CHAR: سلسلة نصّيّة ذات طول محدّد يتم دائمًا إكمالها من ناحية اليمين بفراغات إلى الطول المحدّد عند تخزينها. VARCHAR: سلسلة نصيّة ذات طول متغيّر. TINYBLOB, TINYTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 255 (أي 2^8 – 1) محرفًا. BLOB, TEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 65535 (أي 2^16 – 1) محرفًا. MEDIUMBLOB, MEDIUMTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 16777215 (أي 2^24 - 1) محرفًا. LONGBLOB, LONGTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 4294967295 (أي 2^32 - 1) محرفًا. ENUM: تِعداد. SET: مجموعة. مزايا MySQL سهلة الاستخدام: يمكن تثبيت MySQL بسهولة شديدة. أدوات الأطراف الخارجية (third-party)، بما فيها المرئيّة (أي الواجهات الرسوميّة) تجعل البدء مع قواعد البيانات سهلًا للغاية. غنيّة بالمزايا: تدعم MySQL الكثير من وظائف SQL المتوقّع وجودها في أنظمة إدارة قواعد البيانات العلاقيّة، سواء بطريقة مباشرة أو غير مباشرة. آمنة: الكثير من مزايا الأمن وبعضها متقدّم مبنيّة في MySQL. قويّة وقابلة للتحجيم: يمكن لـMySQL التعامل مع الكثير من البيانات، ويمكنها أيضًا استخدامها على نطاق واسع إذا احتاج الأمر. سريعة: التخليّ عن بعض المعايير سمح لـ MySQL بالعمل بكفاءة عالية وبطريقة سلسة، مما أكسبها سرعة عالية. عيوب MySQL المحدوديّات المعروفة: من حيث التصميم، لا تنوي MySQL عمل كلّ شيء، وتأتي بمحدوديّات وظيفيّة قد تتطلبها بعض التطبيقات المتقدّمة جدًّا من الناحية الفنيّة. القضايا المتعلّقة بالمتانة: الطريقة التي يتم التعامل فيها مع بعض الوظائف في MySQL (كالمراجع، والتبادلات، والتدقيق، وغيرها) تجعلها أقل متانة بقليل من بعض أنظمة إدارة قواعد البيانات العلاقيّة الأخرى. بطء تطويرها: رغم أنّ MySQL ما زالت من الناحية الفنيّة منتجًا مفتوح المصدر، إلّا أنّ هناك انتقادات تتعلق بعمليّة تطويرها منذ الاستحواذ عليها. ولكن علينا التنويه إلى أنّ هناك قواعد بيانات مبنيّة على MySQL ومتكاملة معها تمامًا تضيف مزايا على تثبيت MySQL القياسيّ (مثل MariaDB). متى تستخدم MySQL العمليّات الموزّعة: عندما تحتاج لأكثر مما تتيحه SQLite، فإنّ تضمين MySQL في قائمة التطوير لديك – كذلك بالأمر بالنسبة لتضمين أيّ خادم قواعد بيانات مستقل – يقدّم لك الكثير من الحريّة في العمل إلى جانب بعض المزايا المتقدّمة. الأمان العالي: مزايا MySQL الأمنيّة تقدّم حماية يُعتمد عليها للوصول إلى البيانات (واستخدامها) بطريقة بسيطة. المواقع وتطبيقات الوِب: يمكن للأغلبية العُظمى من المواقع (وتطبيقات الوِب) العمل ببساطة مع MySQL رغم القيود. هذه الأداة المرنة والتي يمكن تحجيمها إلى حدّ ما سهلةُ الاستخدام والإدارة؛ وهذا مفيدٌ جدًّا على المدى البعيد. الحلول الخاصّة: إذا كنت تعمل على حلول محدّدة جدًّا ومخصّصة للغاية، يمكن لـMySQL العمل ضمن احتياجاتك بسهولة، وذلك بفضل إعدادات الضبط الغنيّة فيها وأوضاع العمل. متى لا تستخدم MySQL التوافقيّة مع SQL: بما أنّ MySQL لا تطبّق (ولا تسعى لتطبيق) معيار SQL بأكمله، فإنّ هذه الأداة ليست متوافقة بالكامل مع SQL. إذا كنت قد تحتاج التكامل مع أنظمة إدارة قواعد بيانات علاقيّة كهذه، فإنّ الانتقال من MySQL لن يكون سهلًا. التعدّدية Concurrency: رغم أنّ MySQL وبعض محرّكات الحفظ تعمل بأداء جيّد جدًّا في عمليات القراءة، إلا أنّ عمليات القراءة والكتابة متزامنتين قد تكون سيئة. نقص المزايا: مجدّدًا نقول، اعتمادًا على اختيار محرّك قواعد البيانات، يمكن أن لا تحوي MySQL على بعض المزايا، كالبحث في النصوص الكاملة. PostgreSQL إنّ PostgreSQL هي نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر الأكثر تقدّمًا، والتي هدفها الرئيسيّ أن تكون موافقة للمعايير ويمكن الزيادة عليها. تسعى PostgreSQL (أو Postgres) إلى تبني معايير ANSI/ISO SQL مع مراجعاتها. تتميّز PostgreSQL عن أنظمة إدارة المحتوى الأخرى بدعمها للتوجه الكيانيّ (object-oriented) المتكامل والمطلوب بشدّة و/أو وظائف قواعد البيانات العلاقيّة، كدعمها الكامل للتبادلات (القيود transactions) التي يعتمد عليها، أي أن تكون مكونة من عناصر غير قابلة للتجزئة، وأن تكون متّسقة ومعزولة وذات قدرات تحمل عالية (Atomicity, Consistency, Isolation, Durability – ACID). وبسبب التقنية القوية التي تقف خلفها، لدى Postgres قدرات عالية جدًّا في التعامل مع العديد من المهام بكفاءة عالية. يتم الوصول إلى التعدّدية (concurrency) دون قفل قراءة، وذلك بفضل تطبيق تحكم التعدّديّة متعدد الإصدارات (Multiversion Concurrency Control – MVCC). يمكن برمجة الكثير في PostgreSQL، وبالتالي يمكن توسعتها، وذلك باستخدام إجراءات مخصّصة تُدعى "إجراءات التخزين" (store procesures). يُمكن إنشاء هذه الإجراءات لتسهيل تنفيذ عمليات قاعدة البيانات المكررة والمعقدة والتي تكثر الحاجة إليها. رغم أنّ نظام إدارة قواعد البيانات هذا لا يحظى بشعبيّة MySQL، إلّا أنّ هناك الكثير من أدوات الأطراف الأخرى ومكتباتهم مصمّمة لجعل العمل مع PostgreSQL سهلًا، رغم طبيعته القويّة. يمكن الحصول على PostgreSQL هذه الأيام كحزمة تطبيقات من خلال مدير الحزم المبدئيّ للعديد من أنظمة التشغيل بسهولة. أنواع البيانات التي تدعمها PostgreSQL bigint: عدد صحيح من 8-بايت ذو إشارة bigserial: عدد صحيح من 8-بايت يزداد تلقائيًّا [(bit [(n: سلسلة ثنائيّة ذات طول محدّد [(bit varying [(n: سلسلة ثنائيّة متغيرة الأطوال boolean: متغيّر منطقي (صواب/خطأ) box: صندوق مستطيل في سطح مستوٍ bytea: بيانات ثنائيّة ("مصفوفة بايت") [(character varying [(n: سلسلة محارف (character string) ذات طول متغير [(character [(n: سلسلة محارف ذات طول ثابت cidr: عنوان شبكة IPv4 أو IPv6 circle: دائرة في سطح مستوٍ date: تاريخ في تقويم (السنة، الشهر، اليوم) double precision: عدد فاصلة عائمة ذو دقّة مزدوجة (8 بايت) inet: عنوان مضيف IPv4 أو IPv6 integer: عدد صحيح من 4 بايت ذو إشارة [(interval [fields] [(p: مدة زمنية line: خط لا نهائيّ في مستوى lseg: جزء من خطّ مستقيم في مستوى macaddr: عنوان تحكم بالوصول إلى الوسيط (Media Access Control – MAC) money: مقدار من المال [(numeric [(p, s: دقّة رقميّة محدّدة أو يمكن اختيارها path: مسار هندسيّ على سطح point: نقطة هندسيّة على سطح polygon: شكل هندسيّ مغلق على سطح real: عدد فاصلة عائمة ذي دقّة أحاديّة (4 بايت) smallint: عدد صحيح من 2-بايت ذو إشارة serial: عدد صحيح من 4 بايت يزداد تلقائيًّا text: سلسلة محارف ذات طول متغيّر [time [(p)] [without time zone: وقت في اليوم (دون منطقة زمنية) time [(p)] with time zone: الوقت من اليوم (مع منطقة زمنية) [timestamp [(p)] [without time zone: تاريخ ووقت (دون منطقة زمنية) timestamp [(p)] with time zone: تاريخ ووقت يشمل المنطقة الزمنيّة tsquery: استعلام بحث نصّيّ tsvector: مستند بحث نصيّ txid_snapshot: لَقطَة (transaction) لهويّة التبادل على مستوى المستخدم uuid: معرّف فريد عالميًّا xml: بيانات XML مزايا PostgreSQL نظام إدارة قواعد بيانات مفتوح المصدر موافق لمعايير SQL: PostgreSQL مفتوح المصدر ومجانيّ، ولكنه نظام إدارة قواعد بيانات علاقيّة قويّ جدًّا. مجتمع قويّ: PostgreSQL مدعوم من مجتمع خبيرٍ ومخلص يمكن الوصول إليه عبر مواقع الأسئلة والإجابات والقاعدة المعرفيّة طوال الوقت ومجانًا. دعم قويّ من الأطراف الأخرى: بغض النظر عن المزايا المتقدّمة جدًّا، تُزيّن PostgreSQL العديدُ من الأدوات الجيّدة ومفتوحة المصدر من أطراف أخرى لتصميم وإدارة واستخدام نظام الإدارة هذا. إمكانية التوسعة: يمكن توسعة PostgreSQL برمجيًّا باستخدام إجراءات مخزّنة، كما يفترض أن يكون الوضع في نظام إدارة قواعد بيانات علاقيّة متقدّم. كيانيّ: ليس PostgreSQL مجرّد نظام إدارة قواعد بيانات علاقيّة، ولكنه كيانيّ (objective) أيضًا – ويدعم التضمين (nesting)، ومزايا أخرى. عيوب PostgreSQL الأداء: للعمليات البسيطة كثيفة القراءة، يمكن أن تكون PostgreSQL مبالغًا فيها، ويمكن أن تبدو أقلّ أداءً من منافساتها، مثل MySQL. الشعبيّة: نظرًا لطبيعة هذه الأداة، فإنها تقبع في الخلف فيما يتعلق بشعبيتها، رغم كثرة من استخدامها – مما قد يؤثر على سهولة الحصول على دعم. الاستضافة: نتيجة للعوامل المذكورة أعلاه، يصعب إيجاد مستضيفين أو مقدمي خدمة يعرضون خدمات PostgreSQL مُدارة. متى تستخدم PostgreSQL صحّة البيانات: عندما تكون صحّة البيانات وإمكانية التعويل عليها ضرورة حتميّة، ولا يكون هناك عذر إذا حدث خطب ما، فستكون PostgreSQL الخيار الأفضل. الإجراءات المخصّصة المعقّدة: إذا كنت تتطلّب من قاعدة بياناتك أداء إجراءات مخصّصة، فـPostgreSQL هي الخيار الأفضل، كونه يمكن توسعتها. التكامل: إذا كان يُحتمل في المستقبل أن تكون هناك حاجة لنقل نظام قاعدة البيانات بأكمله إلى حلّ مملوك (مثل أوراكل)، فستكون PostgreSQL الأكثر توافقًا والأسهل في التعامل معها عند الانتقال. التصاميم المعقّدة: مقارنة بتطبيقات أنظمة إدارة قواعد البيانات العلاقيّة المجانية ومفتوحة المصدر الأخرى، تقدّم PostgreSQL لتصاميم قواعد البيانات المعقّدة أكبر قدر من الوظائف والإمكانات دون التفريط بالأمور الأخرى. متى لا تستخدم PostgreSQL السرعة: إذا كان كلّ ما تطلبه عمليات قراءة سريعة، فليست PostgreSQL الأداة التي عليك استخدامها. سهولة الإعداد: إذا لم تكن تحتاج لصحّة مطلقة للبيانات، أو للتوافق مع ACID أو التصاميم المعقّدة، فقد تكون PostgreSQL مبالغًا فيها للإعدادات البسيطة. التكرار: إذا لم تكن مستعدًّا لقضاء الوقت، وبذل الجهد والموارد، فالحصول على التكرار (أو تعدّد النُسَخ) في MySQL قد يكون أسهل لمن ليست لديهم خبرة في إدارة الأنظمة وقواعد البيانات. ترجمة -وبتصرّف- للمقال: SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems لصاحبه O.S. Tezer.

لطالما اعتُبِر تصميم صفحة البداية فنا في ذاته، كما تعتبر الأنشطة الأخرى التي تؤدي إلى بناء تصميم موقع كامل. وبطريقة ما، يجب أن يكون بالإمكان جعل واجهة البداية عملًا قائمًا بذاته، عملًا يحقق أهدافه الخاصّة. رغم أن هذه الأهداف لها ارتباط مباشر للهدف العام للموقع ككل، إلّا أنه يفترض بها أن تكون مركّزة أكثر. أعلم أن هذا قد يبدو مُبهمًا نوعًا ما، ولذا -لأوضح الأمور- لنلقِ نظرة على ثماني خرافات تتعلق بتصميم صفحة البداية يفترض على الجميع أن يعرفها. الخرافة الأولى: يجب أن تبدو صفحة البداية جميلةبالتأكيد لا أحد يستمتع بالنظر إلى صفحة بداية قبيحة، ولكن مع هذا، فجمال صفحة البداية ليس نهاية الحكاية. وبعبارة أخرى، تركيزك على عمل صفحة تسرّ الناظرين لهو أمر غير كافٍ للوصول بك إلى إسعاد زبونك (على المدى البعيد على الأقل). هناك أمر واحد يهمّ أكثر بكثير من المنظر الجذاب لصفحة البداية، وهو قدرة هذه الصفحة على تحقيق هدفها الرئيسيّ. يجب أن يكون لكل صفحة هدفها الخاص بها، وهو الهدف الرئيسيّ الذي من أجله وُجِدَت هذه الصفحة، لذا من أهم مهامك الرئيسيّة عند العمل على تصميم أن تحدد هذا الغرض. يمكنك أن تجرب الإجابة على السؤال التالي لجعل عملك أسهل: ما الأمر الرئيسيّ الذي ترغب أن يقوم به زوارك عند رؤيتهم لصفحة البداية لديك؟ فمثلًا، هل الهدف هو التسجيل قائمة بريدية أو نظام اشتراكات معين؟ أو قد يكون الهدف هو الذهاب إلى المدونة والتفاعل مع المقالات هناك؟ قد يكون الهدف هو الاطلاع على المنتجات أو الخدمات التي يوفرها الموقع؟ مهما كان هذا الهدف، ضعه نصب عينيك عند العمل على تصميم صفحة البداية. إذا كانت النتيجة جميلة (تسرّ الناظرين)، فهذه ميزة تكميليّة. إن أحد أفضل الأمثلة على تصميم الواجهة الرئيسيّة بالتركيز على الأهداف على الإنترنت هو موقع Craigslist. الواجهة قبيحة، لكنها تفي بالغرض: الخرافة الثانية: يجب أن تكون صفحة البداية مناسبة للجميعوبعبارة أخرى، تقول الخرافة أنه بغض النظر عن من يأتي لزيارة صفحة البداية، فعليه أن يُعجَب بها وأن يسعد بما يجده. ولكن مساوئ هذا الأمر أكثر من نفعه. رغم أن الموقع قد يبدو غير عمليّ، مما يُبعِد بعض الزوار مباشرة، إلا أنه قد يكون ذا أثر إيجابيّ على الزوار الذين يقررون البقاء. لأنهم -في تلك المرحلة- يعلمون أن ما يمكن للموقع أن يقدمه لهم سيتم بطريقة مفصلة خصيصًا لهم. دعني أعطيك مثالًا من مجال عمل مختلف كليًّا، وهو المطاعم. من الأخطاء الشائعة لدى العديد من أصحاب المطاعم (وهو ما أقوله على الأقل نتيجة لمشاهدتي لفلم Kitchen Nightmares) هو أن يوفروا كمًا هائلًا من أنواع الوجبات وأن يظنوا أنهم بهذه الطريقة سيوفرون لكل شخص شيئًا يناسبه. ولكن -عمليًّا- كانت النتيجة عكسيّة، حيث لم تكن هناك إشارة واضحة للزبون العاديّ أن هذا المطعم مناسب له. فعلى سبيل المثال، إذا كنت تحب البيتزا، فستذهب إلى محلّ لبيع البيتزا في كلّ مرة، ولن تذهب إلى مطعم يقدم العشرات من الأطباق المختلفة والتي تكون البيتزا واحدًا من عناصر قائمتها. هل تُبعد محلات البيتزا بعض الزبائن لمجرد أنها تقول بوضوح ان وجبتها الرئيسيّة هي البيتزا؟ نعم، بالتأكيد. ولكن هل تخسر هذه المحلات شيئًا على المدى البعيد؟ كلّا. ولهذا، فاجعل صفحة البداية لموقعك كمحل بيع البيتزا. بيّن أن ما يقدمه موقعك هو البيتزا، وبين بوضوح أنه إذا لم يكن شخص ما يحب البيتزا، فيفترض به أن لا يأتي إلى هنا. الخرافة الثالثة: يجب أن تعرض صفحة البداية الكثير من المعلوماتيمكننا أن نقول ونحن واثقون أن عصر صفحات البداية ذات التفاصيل الكثيرة قد ولّت أيامه. لا تحتاج صفحات البداية أن تكون ضخمة لتحقق أهدافها. وكما كنا نقول: خير الكلام ما قلّ ودلّ. الأمر هنا نفسه تقريبًا. كما ناقشنا أعلاه، فإن الوظيفة الأساسيّة لصفحة البداية هي أن تعطي الزائر دفعة باتجاه تنفيذ أشياء معينة. وكما يبدو، فإن عرضك لكمية أكبر من اللازم من المعلومات سيؤدي إلى نتيجة عكس ما تتمنى. ولقد أكدت مجموعة Nielsen Normal Group هذا الأمر في دراساتها. تقول هذه المجموعة أنّ 79% من المستخدمين يتفحصون كلّ صفحة جديدة يرونها بسرعة، بينما 16% فقط يقرؤونها كلمة بكلمة. ولهذا، فخلاصة الكلام أن جعل صفحة ما موجزة يؤدي إلى زيادة في قابلية الاستخدام قدرها 124%. لنلق نظرة على صفحة البداية لـ Contently.com على سبيل المثال: هناك فقط ثلاثة سطور من المعلومات، يتبعها طلبان لاتخاذ إجراء، وهما: "اعرف المزيد" و "تحدّث معنا". بعد قراءة سطور النص الثلاثة هذه، سيعرف الزائر إن كان مهتمًا كفاية لأن يضغط أحد هذين الزرين، وهذا كل ما تحتاج عند عمل صفحة بداية. الخرافة الرابعة: تحتاج صفحة البداية لشريط تمريراستخدام أشرطة التمرير في التصميم توجه كسول جدًّا. في نهاية الأمر، من السهل وضع شريط تمرير تحت الترويسة مباشرة ووضع بعض الرسوميات الشبيهة بالـ "بانر" فيه. الأكثر شيوعًا هو أن تقوم بعمل 3 - 4 شرائح وأن تجعلها تتبدل تلقائيًّا. هذا أسلوب شائع جدًّا وتتبعه آلاف صفحات البداية. ولكن، كما تؤكد المعلومات، فإن هذه الشرائح غير مجدية عندما يتعلق الأمر ببدء حوار، أو جذب انتباه المستخدم، أو عمل أيّ شيء آخَر يمكن أن ينتُج عنه نتائج إيجابيّة. وعلى سبيل المثال، هذا ما قاله عنها Chris Goward من WiderFunnel في إحدى أوراقه البحثيّة: في نهاية المطاف، المعلومات التي لدينا هذه الأيام تقترح حلًّا جيدًا لهذا الأمر: لا تستخدم أبدأ شرائح عرض الصور في صفحة البداية أبداً. الخرافة الخامسة: يجب أن تتحدث صفحة البداية عنك أنتحيث أعني بكلمة "أنت" الشخص أو الشركة صاحبة هذا الموقع. فمثلًا، تعني كلمة "أنت" أن تتحدث عن المنتجات التي تقدمها الشركة. بداية، أن تتحدث الصفحة عنك ليست بالفكرة السيئة أبدًا. عليك أن تقوم بها إلى حدّ ما، وإلّا فلن تبني أيّ علاقة مع الزائر. ولكن ما يهم هنا هو الطريقة التي تستخدمها للتعبير عن الأمر. فمثلًا، استخدام تعبير مثل "نقدم خدماتنا من عام 2004. انقر هنا لمعرفة عرضنا." لا يحقق أيّ شيء فيما يتعلق بالتواصل مع الزائر. إن ما سيحقق نتيجة هو أن تبني صفحة البداية لديك حول مفهوم: ما الذي سأحققه للزائر؟ لنلق نظرة مثلًا على صفحة البداية لموقع Due.com: الصفحة لا تقول: "نحن نعمل في مجال تتبع الوقت منذ 'س' من السنوات". بل تقول: "يساعدك Due.com على تتبع وقتك باستمرار وإخراج فاتورة احترافية". يرتكز النصّ حول الزائر تمامًا تقريبًا. وباختصار، اجعل صفحة البداية تتعلق بـهم -أي الزوار- وليس بك أنت. الخرافة السادسة: يجب أن تعرض الصفحة الرئيسيّة أخبار الشركةلا تفعل هذا، رجاءً! لا يولي الناس -عمومًا- اهتمامًا بما يحدث داخل الشركة. لماذا؟ سأقولها مرة أخرى، لأن هذا الأمر لا يعنيهم هم. من ناحية المبدأ، أيّ نوع من أخبار الشركة لا يعد ذا علاقة بالزائر واحتياجاته، إلا إن كان الزائر مستثمرًا أو كان الموقع للاستخدام الداخلي في الشركة، ففي هذه الحالة لك الحرية الكاملة لأن تعرض أخبار الشركة على الصفحة الرئيسيّة. الخرافة السابعة: يجب أن تبدو صفحة البداية بنفس الشكل على كلّ الأجهزةإن فكرة تصميم المواقع لأكثر من جهاز لَهُوَ فصل جديد في تاريخ تصميم المواقع. قبل زمن ليس ببعيد، كان كل ما علينا أخذه بعين الاعتبار هو ما إذا كان سيبدو الموقع جيدًا على دقة 800×600 كما هو جيد على دقة عرض 1024×768. لكن الزمان تغيّر، ولدينا الآن عدد كبير من أحجام ودقة الشاشات لنتعامل معها. ولكن التفكير بأن موقعك يجب أن يبدو بنفس الشكل عليها كلها فهذا مسار خطير يفترض تجنبه. المشكلة الرئيسيّة في التفكير بهذه الطريقة هو أنّ من يزور موقعك من هاتف محمول لن يفكر بنفس الطريقة التي يفكر بها الشخص الذي يزور الموقع من الحاسوب الشخصيّ. على سبيل المثال، إذا زار شخص ما موقع مطعم من الحاسوب الشخصيّ، فغالب الظنّ أنه يرغب بالتعرف على المطعم وما يقدّمه والأطعمة التي يوفرها، إلخ. ولكن عند زيارته من الهاتف المحمول فإن أول ما يفكر فيه هو العنوان وساعات الدوام. يجب على تصميم صفحة الواجهة الجيد أن يقدم فائدة لمجموعات مختلفة من الزوار بناء على الجهاز الذي يستخدمونه. يمكن تحقيق هذا باستخدام تصميم مستجيب إلى حدّ ما. يمكنك باستخدام فئات CSS (أي classes) أن تبرز أجزاء معينة من صفحة HTML أو أن تخفيها بالكامل. باختصار، ليس من الضروري أن تبدو صفحة البداية بنفس الشكل في كلّ مكان، ولكنها تحتاج لأن تساعد الزائر على تلبية احتياجاته من الموقع. الخرافة الثامنة: بعد أن تنتهي من بنائها، ستبقى كما هييجب أن لا يكون تصميم صفحة البداية مهمة تنفذ لمرة واحدة. لسوء الحظ، لن تكون محاولتك الأولى لتصميم صفحة البداية لأي موقع (أيًّا كان) ذات نتيجة مثاليّة. هذا لأنك لن تتمكن من التنبؤ بطريقة أداء هذه الصفحة في العالم الحقيقيّ. يمكنك فقط أن تفترض كيف سيتعامل الزائر مع صفحة البداية، ولكنك لن تعلم بدقة. تأتي هذه المعرفة مع الوقت وبتجربة مفاهيم مختلفة. ولهذا، بدلًا من أن تفترض أن تصميمك سيكون رائعًا بمجرد أن تنتهي منه أول مرة، أنشئ على الأقل تصميمين مختلفين واختبرهما وقارن النتائج. ما مدى الاختلاف الذي يجب أن يكون بين التصميمين؟ القرار يعود إليك. يمكنك أن تبدأ بنسخة ذات تعديلات طفيفة، أو تغييرات كبيرة في الشكل العام. المهم أن يكون هناك اختلاف بين التصميمين، وعليك أن تضع مقياسًا تعتمد عليه في تقييم الإصدارين وتحديد أيهما أفضل (يتم هذا عادة بتتبع النقرات على روابط محددة أو بوجود زوار يملؤون نماذج معينة). بمجرد أن تكون لديك بيانات خام، يمكنك تفتيت النسخة الأقل أداءً من صفحة البداية وإنشاء صفحة جديدة تمامًا ومن ثم مقارنتها مع الصفحة التي نجحت في المقارنة السابقة. إن طريقة عمل صفحة بداية جيدة يكون بتنفيذ هذا الأمر على الأقل عدّة مرات. الخلاصةهناك أكثر مما يمكن حصره فيما يتعلق بأخطاء تصميم الصفحة الرئيسيّة، ونحن لم ندخل في القضايا التقنية حتى (كاستخدام صور لم يتم تضبيطها لتناسب الموقع، أو خطوط صغيرة جدًّا). أظننا سنترك هذه المواضيع للمرة القادمة. هل كنت ضحية إحدى الخرافات المذكورة أعلاه؟ شاركنا برأيك! ترجمة -وبتصرف- للمقال 8Homepage Design Myths Debunked لصاحبه: Karol K. حقوق الصورة البارزة: Designed by Freepik.

لقد صار التصميم الماديّ (material design) شائعًا جدًّا هذه الأيام، حيث بدأ كثير من المصممين بتضمينه في تصاميمهم ليس فقط لتطبيقات أندرويد، بل ولمشاريع الويب أيضًا. لأذكّرك، لقد تم طرح المفهوم لأول مرة من طرف جوجل في Google I/O 2014 keynote. لقد شوهد هذا العرض التقديميّ أكثر من 1.5 مليون مرة حتى الآن، وما زال يتم التعامل معه على أنه العرض الأساسيّ لماهيّة التصميم الماديّ وكيف علينا أن نتخيله. هل التصميم الماديّ مناسب لك؟السؤال الأول الذي سنحاول الإجابة عليه الآن هو ما إذا كان التصميم الماديّ شيء عليك تعلمه والبدء باستخدامه في عملك. ولكن، كما هي العادة عندما يتعلق الأمر بهذه الأسئلة، ليست هناك إجابة واحدة تناسب الجميع. لنحاول إذًا أخذ هذه المسألة من زاوية أخرى. هناك أشياء أنا متأكد من أنك ستوافقني عليها، ومنها أن التصاميم الرائعة هي تصاميم مميزة وتقوم بمهمتها على أكمل وجه. وقد يكون أداء التصميم دوره على اكمل وجه أهم من أي أمر آخَر. وبعبارة أخرى، جمالية التصميم لمجرد أن يكون التصميم جميلًا أمر لا جدوى منه. ولهذا، فعند التفكير في تبني تصميم material، حاول أولًا أن تربطها بالأهداف التي ترغب بتحقيقها من تصميمك. وبشكل أساسي، أجب الأسئلة التالية بنفسك: هل تتوافق مبادئ وتوجيهات التصاميم المادية مع ما أريد تحقيقه؟ ملاحظة: ربما تكون قراءة مقالنا السابق حول الاختلافات بين التصاميم المسطحة والتصاميم المادية فكرة جيدة قبل الاستمرار في قراءة هذا المقال. لقد تطرّقنا فيه إلى أكبر الاختلافات بين التصاميم المسطحة والتصاميم الماديّة، ومزايا ومساوئ كلّ منها. سيقدم لك هذا المقال مساعدة إضافية عند اختيارك لتوجّه معين. 1. تعرف على المصدر الرئيسيإذا رغبت بتعلم التصاميم الماديّة، فأفضل نقطة تبدأ بها هي المصدر الرسميّ الذي نشرته جوجل. يتم تحديث هذا المصدر باستمرار، ويشرح كلّ التفاصيل الصغيرة التي تندرج ضمن بناء تصاميم ماديّة. والجميل فيه هو أنه لا يغطي النواحي المتعلقة بأندرويد من التصاميم المسطّحة وحسب، بل ويناقش أيضًا التصاميم المسطّحة بشكل عام وعلاقتها بأيّ مشروع موقع أو تطبيق. أنصحك بشدة أن تقرأ على الأقل الفصول الأولى من التوثيق لتتعرف على المفاهيم الأساسيّة. 2. افهم معنى "ماديّ" في التصميم الماديّإن مفهوم "تصميم ماديّ" لم يأتِ اعتباطًا. ببساطة، يشير مفهوم التصاميم الماديّة إلى جعل التصاميم تمثل العالم الحقيقي، ولكن على قدر معين من التجريد. بالطبع لا تريد أن تجعل تصميمك يبدو واقعيًّا أكثر من اللازم إلى مرحلة ينتحل فيها شكل عنصر معين في العالم الحقيقيّ. إليك الفكرة. نحن -البشر- نفهم الأشياء الماديّة. نعرف ملمس المعدن، ونعرف الشكل الذي يكون عليه المكتب الخشبيّ. يمكننا أيضًا أن نميّز أشياء موضوعة فوق أشياء أخرى. يمكننا مثلًا أن نميّز قلم رصاص موضوع على ورقة موضوعة على مكتب. ببساطة، ستتعلم في التصميم الماديّ أن تعبر عن الترتيب نفسه للعناصر، ولكن بأن تستخدم فقط أقل ما يمكن من عناصر التصميم، كالظلال مثلًا. مصدر الصورة: ظلّ - لـNikhil Vootkur من Behance. 3. استخدم الظلال لتوصل مفهوم التقسيم الشجريّإن السطوح والحواف والظلال والإضاءة هي الأدوات الرئيسيّة للتصاميم الماديّة. إن إضافة العمق لتصاميم أمر هامّ جدًّا، ولكن عليك أن تنتبه لأن تستخدم الحدّ الأدنى من الجرعة الفعالة منه. فمثلًا، الظلال هي الأداة الرئيسيّة لديك للتعبير عن هرميّة العديد من العناصر التي تجتمع معًا لتشكل التصميم الكامل. عندما تقرر ما الذي يُلقي ظلًّا صغيرًا واقعيًّا على شيء آخر، فإنك تُبرز الهرميّة المرئيّة للعناصر والطبقات التي هي موضوعة عليها. إن ما يهم هنا هو التكوين العام للتصميم، وما إذا كانت الظلال لديك ككل منطقيّة بالنسبة للناس، وإن كانت تُبدي مفهوم الأشياء الماديّة الحقيقيّة. مصدر الصورة: WhatsApp | Material Design Concept - لـMário Gomide من Behance. 4. استخدم ألوان جريئةثلاثة من المبادئ الرئيسيّة للتصاميم الماديّة هي أن تكون جرئية، وجميلة التصميم، وعالميّة. التصاميم الماديّة تصاميم تعتمد على الحدّ الأدنى من التصميم دون مبالغات بالتأكيد. وبعبارة أخرى، فإنها لا تستخدم الكثير من أدوات التصميم والجماليات. ولهذا، فعلى المصممين أن يلتفوا على هذه القيود وأن يجدوا طرق أخرى لإنتاج معنى وجذب الانتباه إلى إنشاء التركيز المناسب. إن الألوان من الأشياء القليلة المتروكة للمصمم. ولنتكلم بدقة، الألوان الجريئة، وغالباً الألوان الصاخبة. للألوان الجرئية دور مهم في التصاميم الماديّة (وفي التصاميم المسطّحة أيضًا). تجعل هذه الألوانُ الأشياءَ ممتعة، وتجعل المستخدم يستمتع بالتفاعل مع التصميم. مثال على تصميم ملون: مصدر الصورة: Behance New App Concept (Material Design - لـ Fabrizio Vinci من Behance. 5. استخدم لونا أساسيا وآخر ثانوياتقول مستندات جوجل الرسميّة: "حدّد اختيارك للألوان باختيار ثلاثة ألوان من منقاة الألوان (palette) الرئيسيّة، ولونًا ثانويًا من منقاة الألوان الثانوية." قد تكون طريقة تطويع هذه لأي نوع من التصميم كالتالي: استخدم ثلاثة ألوان لتشكل منقاة الألوان الرئيسيّة لك، وانتقِ لونًا آخر ليكون لونًا ثانويًّا. يمكن أن تستخدم لونك الرئيسيّ لأشياء كالخلفية وأماكن الإدخال والصناديق والخطوط والعناصر الأخرى الرئيسيّة في الواجهة. أما اللون الثانوي، -فهو كما يشير اسمه- يعطي عمقًا إضافيًّا عندما ترغب بعرض العناصر الرئيسيّة على صفحة أو شاشة معينة. سيكون من الضروريّ بالتأكيد أن يكون اللون الثانوي متباينًا بشدّة مع الألوان الرئيسيّة. مصدر الصورة: Snapchat – Material Design - لـ Vinfotech من Behance. 6. استخدم المساحات الفارغةيأخذ التصميم الماديّ الكثير من الأفكار من تصاميم الطباعة التقليدية والمفاهيم التي أتتنا بها. فمثلًا، المساحات الفارغة جزء مهم لأيّ تصميم ماديّ، ويمكنها أن تحسن الخطوط وشكل النصوص بقدر هائل. في الواقع، المساحات الفارغة هي أهم الأدوات لإنشاء تركيز ولجذب انتباه المستخدم إلى عنصر معين (وهو شيء غالبًا يجد المصممون المبتدئون صعوبة في فهمه). لذ -باختصار- استخدم خطوطًا كبيرة للعناوين، وأضف الكثير من المساحات البيضاء، ولا تخش أن تضيف الكثير من المساحات الفارغة في تصاميمك بشكل عام. مصدر الصورة: Material Design Sign Up Page - لـ Omkar Abnave من Behance. 7. استخدم الصور من الحافة إلى الحافةإن التصاميم الماديّة صديقة للصور للغاية. ما أعنيه هنا هو أنك إذا قررت تضمين أي صور في تصميمك، فعليك أن تعطيها دورًا مهمًا. إن الصور في التصاميم الماديّة تُستخدم من الحافة إلى الحافة، في ما يعرف بطريقة full-bleed. يعني هذا عدم وجود حاشية بين حافة الصورة وحافة الشاشة. عند عمل هذا بشكل سليم، سيعطي تجربة فريدة للمستخدم، ويعطينا نحن المصممين بعض الأدوات الإضافية إضافة إلى المجموعة الصغيرة من الظلال المسموح بها مسبقًا، والألوان، والطبقات. مصدر الصورة: Twitter Material Design - لـ Rico Monteiro على Behance. 8. للتصاميم المعتمدة على الصور، استخرج الألوان من الصوربالحديث عن الصور، تنصحنا جوجل باستخراج الألوان من الصور التي نستخدمها في تصاميمنا ومن ثم نجعلها جزءًا من مجموعة الألوان لدينا. يصعب أن تجد حجّة تناقض فيها هذا المفهوم. إن اتباع هذه الطريقة سيعطي تجربة متزنة للمستخدم بكل تأكيد، وسيعطي انطباعًا بأن كل شيء في مكانه المناسب، وأن العناصر الموجودة كلها متسقة مع بعضها. مصدر الصورة: Material Design Colors Recontextualization - لـ Lonely Pig Ringo على Behance. 9. استخدم الحركاتوبحسب تعبير جوجل، فإن الحركة تُضفي معنىً. الحركة من العناصر الأساسيّة للتصميم الماديّ الجيّد. وبشكل عام، فإنك معتاد على وجود حركة في العالم الحقيقيّ. تساعدنا الحركة على معرفة كيف تعمل الأشياء وإلى أين علينا أن نركز انتباهنا. تستخدم التصاميم المادية نفس المفهوم، وتستخدم الحركة للتفاعل مع المستخدم، وتجعلك تعرف جيدًا كيف تستخدم التصميم. كيف تستخدم الحركة؟ ببساطة، أعطِ المستخدم تغذية راجعة عن الحدث الذي قام به. فمثلًا، هل ضغط المستخدم زرًّا؟ حرّكه لتظهر أن الأمر قد تمّ. مصدر الصورة: REDBUS APP – Material Design Preview - لـ Anish Chandran على Behance. 10. اجعل الحركات واقعيةكلمة "واقعية" هي مربط الفرس هنا. إن عصر الحركات المزيفة -حيث تتحرك الأشياء في داخل الشاشة- قد ولى منذ زمن. إذا كنت ستضمّن الحركة هذه الأيام، فيمكنك أيضًا أن تجعلها حقيقيّة بما يتوافق مع قوانين الفيزياء وكيفيّة عمل الأشياء في العالم الحقيقيّ. تخصص جوجل قسمًا كاملًا من توجيهات التصاميم المسطحة لمفهوم الحركة الواقعية. تشرح جوجل في هذه التوجيهات كيفية تقديم الكتلة والوزن، والتسارع والتباطؤ، وكيف يتم تحسين الحركة (بالإنجليزيّة: easing؛ وهي طريقة لجعل الحركة تبدو طبيعية أكثر بتغيير السرعة في أوقات محددة). التصاميم المادية جيدة فقط ما دامت تحاكي الحركة في الحياة الحقيقيّة. هذه هي الطريقة الوحيدة التي ستغني فيها الحركةُ الواجهةَ وتجعلها مفهومة أكثر للمستخدم. 11. اجعل كل شيء مستجيبًامن المبادئ الرئيسيّة للتصاميم الماديّة هي جعل العمل الناتج عملًا يمكن الوصول إليه واستخدامه على أيّ جهاز وأي حجم شاشة. وفوق كلّ شيء، الهدف هو جعل التجربة متّسقة. بهذه الطريقة، لن يتوه المستخدم إذا انتقل من جهاز إلى آخَر، حيث لا يجد واجهة مختلفة تمامًا بالنسبة له. باستخدام تصميم ماديّ جيّد، يمكن للمستخدم أن ينتقل دون أيّ عقبات، وأن يتابع في استخدام الموقع أو التطبيق من حيث تركه. ومن الطبيعي أن هذا يعني وجوب كون التصميم مستجيبًا. ولحسن الحظ، باستخدام الأطر البرمجية (frameworks) الحديثة، ستجد الكثير من الأشياء قد بُنيَت لك بالفعل، ولذا فجعل تطبيقك مستجيبًا لن يكون بتلك الصعوبة. 12. تذكر أن كل شيء في التفاصيلمن العناصر الأساسيّة التي تجعل التصاميم المسطحة صعبة التنفيذ جدًّا دون مشاكل هو أنها مبسطة للغاية. فمثلًا، في التصاميم المقلّدة للواقع الحقيقيّ (skeuomorphic) كانت التوجيهات بسيطة: اجعل كل جزء من التصميم يمثل قرينه من الحياة الحقيقيّة قدر الإمكان. وفيما يلي كيف أتت هذه الأشياء إلى الواقع: مصدر الصورة: 15 Puzzle - لـ Kamil Ginatulin على Behance. الأمور أبسط مع التصاميم الماديّة، ولكنها أعقد في الوقت نفسه. في غالب الأمر، التصاميم الماديّة هي لعبة التفاصيل. تحتاج فقط إلى القليل من الواقعية لتعبر عن الوظيفة الحقيقيّة والهدف من الأشياء التي تصممها، ولكنك في نفس الوقت لا ترغب بجعل الأشياء تبدو مطابقة تمامًا لمثيلاتها في الواقع الحقيقيّ. إن كنت في ريب، فتصفح بعض المعارض على الإنترنت لتوحي إليك ببعض الأفكار. هل لك تجارب مع التصاميم الماديّة بعد؟ هل تظن بالإمكان استخدامها لأكثر من مجرد تصميم تطبيقات أندرويد التي وُجِدَت أصلًا لأجله؟ شاركنا برأيك! ترجمة -وبتصرف- للمقال New to Material Design? 12 Principles You Need to Know لصاحبه Karol K.

منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (DataBase Management Systems – DBMS) هي برمجيات عالية المستوى تعمل مع واجهات برمجة تطبيقات (APIs) أدنى منها في المستوى، وتلك الواجهات بدورها تهتم بهذه العمليات. لقد تم تطوير العديد من أنظمة إدارة قواعد البيانات (كقواعد البيانات العلائقيّة relational databases، وnoSQL، وغيرها) لعقود من الزمن للمساعدة على حلّ المشكلات المختلفة، إضافة إلى برامج لها (مثل MySQL ,PostgreSQL ,MongoDB ,Redis، إلخ). سنقوم في هذا المقال بالمرور على أساسيّات قواعد البيانات وأنظمة إدارة قواعد البيانات. وسنتعرف من خلالها على المنطق الذي تعمل به قواعد البيانات المختلفة، وكيفية التفرقة بينها. أنظمة إدارة قواعد البياناتإن مفهوم نظام إدارة قاعدة البيانات مظلّةٌ تندرج تحتها كلّ الأدوات المختلفة أنواعها (كبرامج الحاسوب والمكتبات المضمّنة)، والتي غالبًا تعمل بطرق مختلفة وفريدة جدًّا. تتعامل هذه التطبيقات مع مجموعات من المعلومات، أو تساعد بكثرة في التعامل معها. وحيث أن المعلومات (أو البيانات) يُمكِن إن تأتي بأشكال وأحجام مختلفة، فقد تم تطوير العشرات من أنظمة قواعد البيانات، ومعها أعداد هائلة من تطبيقات قواعد البيانات منذ بداية النصف الثاني من القرن الحادي والعشرين، وذلك من أجل تلبية الاحتياجات الحوسبيّة والبرمجية المختلفة. تُبنى أنظمة إدارة قواعد البيانات على نماذج لقواعد البيانات: وهي بُنى محدّدة للتعامل مع البيانات. وكل تطبيق ونظام إدارة محتوى جديد أنشئ لتطبيق أساليبها يعمل بطريقة مختلفة فيما يتعلق بالتعريفات وعمليات التخزين والاسترجاع للمعلومات المُعطاة. ورغم أنّ هناك عددًا كبيرًا من الحلول التي تُنشئ أنظمة إدارة قواعد بيانات مختلفة، إلّا أنّ كلّ مدة زمنية تضمّنت خيارات محدودة صارت شائعة جدًّا وبقيت قيد الاستخدام لمدة أطول، والغالب أنّ أكثرها هيمنة على هذه الساحة خلال العقدين الأخيرين (وربما أكثر من ذلك) هي أنظمة إدارة قواعد البيانات العلائقيّة (Relational Database Management Systems – RDBMS). أنواع قواعد البياناتيستخدم كلُّ نظام إدارة بياناتٍ نموذجًا لقواعد البيانات لترتيب البيانات التي يديرها منطقيًّا. هذه النماذج (أو الأنواع) هي الخطوة الأولى والمحدّد الأهم لكيفية عمل تطبيق قواعد البيانات وكيفية تعامله مع المعلومات وتصرفه بها. هناك بعض الأنواع المختلفة لنماذج لقواعد البيانات التي تعرض بوضوع ودقّة معنى هيكلة البيانات، والغالب أن أكثر هذه الأنواع شهرةً قواعدُ البيانات العلائقيّة. ورغم أنّ النموذج العلائقيّ وقواعد البيانات العلائقيّة (relational databases) مرنة وقويّة للغاية –عندما يعلم المبرمج كيف يستخدمها–، إلّا أنّ هناك بعض المشكلات التي واجهات عديدين، وبعض المزايا التي لم تقدمها هذه الحلول. لقد بدأت حديثًا مجموعة من التطبيقات والأنظمة المختلفة المدعوّة بقواعد بيانات NoSQL بالاشتهار بسرعة كبيرة، والتي قدمت وعودًا لحل هذه المشكلات وتقديم بعض الوظائف المثيرة للاهتمام بشدّة. بالتخلص من البيانات المهيكلة بطريقة متصلّبة (بإبقاء النمط المعرّف في النموذج العلائقيّ (relational model))، تعمل هذه الأنظمة بتقديم طريقة حرّة أكثر في التعامل مع المعلومات، وبهذا توفّر سهولة ومرونة عاليتين جدًّا؛ رغم أنّها تأتي بمشاكل خاصة بها –والتي تكون بعضها جدّيّة– فيما يتعلق بطبيعة البيانات الهامّة والتي لا غنى عنها. النموذج العلائقيّيقدّم النظام العلائقيّ الذي ظهر في تسعينات القرن الماضي طريقة مناسبة للرياضيات في هيكلة وحفظ واستخدام البيانات. توسّع هذه الطريقة من التصاميم القديمة، كالنموذج المسطّح (flat)، والشبكيّ، وغيرها، وذلك بتقديمها مفهوم "العلاقات". تقدّم العلاقات فوائد تتعلق بتجميع البيانات كمجموعات مقيّدة، تربط فيها جداول البيانات –المحتوية على معلومات بطريقة منظمة (كاسم شخص وعنوانه مثلاً)– كل المدخلات بإعطاء قيم للصفات (كرقم هوية الشخص مثلًا). وبفضل عقود من البحث والتطوير، تعمل أنظمة قواعد البيانات التي تستخدم النموذج العلائقيّ بكفاءة وموثوقيّة عاليتين جدًّا. أضف إلى ذلك الخبرة الطويلة للمبرمجين ومديري قواعد البيانات في التعامل مع هذه الأدوات؛ لقد أدّى هذا إلى أن يصبح استخدام تطبيقات قواعد البيانات العلائقيّة الخيار الأمثل للتطبيقات ذات المهام الحرجة، والتي لا يمكنها احتمال فقدان أيّة بيانات تحت أيّ ظرف، وخاصة كنتيجة لخلل ما أو لطبيعة التطبيق نفسه الذي قد يكون أكثر عرضة للأخطاء. ورغم طبيعتها الصارمة المتعلقة بتشكيل والتعامل مع البيانات، يمكن لقواعد البيانات العلائقيّة أن تكون مرنة للغاية وأن تقدم الكثير، وذلك بتقديم قدر ضئيل من المجهود. التوجّه عديم النموذج (Model-less) أو NoSQLتعتمد طريقة NoSQL في هيكلة البيانات على التخلص من هذه القيود، حيث تحرر أساليب حفظ، واستعلام، واستخدام المعلومات. تسعى قواعد بيانات NoSQL إلى التخلص من العلائقات المعقدة، وتقدم أنواع عديدة من الطرق للحفاظ على البيانات والعمل عليها لحالات استخدام معينة بكفاءة (كتخزين مستندات كاملة النصوص)، وذلك من خلال استخدامها توجّها غير منظم (أو الهيكلة على الطريق / أثناء العمل). أنظمة إدارة قواعد بيانات شائعةهدفنا في هذا المقال هو أن نقدم لك نماذج عن بعض أشهر حلول قواعد البيانات وأكثرها استخدامًا. ورغم صعوبة الوصول إلى نتيجة بخصوص نسبة الاستخدام، يمكننا بوضوح افتراض أنّه بالنسبة لغالب الناس، تقع الاختيارات بين محرّكات قواعد البيانات العلائقيّة، أو محرك NoSQL أحدث. لكن قبل البدء بشرح الفروقات بين التطبيقات المختلفة لكل منهما، دعنا نرى ما يجري خلف الستار. أنظمة إدارة قواعد البيانات العلائقيّةلقد حصلت أنظمة إدارة قواعد البيانات العلائقيّة على اسمها من النموذج الذي تعتمد عليه، وهو النموذج العلائقيّ الذي ناقشناه أعلاه. إنّ هذه الأنظمة –الآن، وستبقى لمدة من الزمن في المستقبل– الخيار المفضّل للحفاظ على البيانات موثوقة وآمنة؛ وهي كذلك كفؤة. تتطلب أنظمة إدارة قواعد البيانات العلائقيّة مخططات معرفة ومحددة جيدًا –ولا يجب أن يختلط الأمر مع تعريف PostgreSQL الخاص بهذه الأنظمة– لقبول هذه البيانات. تشكّل هذه الهيئات التي يحددها المستخدم كيفية حفظ واستخدام البيانات. إنّ هذه المخططات شبيهة جدًّا بالجداول، وفيها أعمدة تمثّل عدد ونوع المعلومات التي تنتمي لكل سجل، والصفوف التي تمثّل المدخلات. من أنظمة إدارة قواعد البيانات الشائعة نذكر: SQLite: نظام إدارة قواعد بيانات علائقيّة مضمّن قويّ جدًّا.MySQL: نظام إدارة قواعد بيانات علائقيّة الأكثر شهرة والشائع استخدامه.PostgreSQL: أكثر نظام إدارة قواعد بيانات علائقيّة كيانيّ (objective-RDBMS) متقدم وهو متوافق مع SQL ومفتوح المصدر.ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد بيانات NoSQL، راجع المقالة التالية عن الموضوع: A Comparison Of NoSQL Database Management Systems. أنظمة قواعد بيانات NoSQL (أو NewSQL)لا تأتي أنظمة قواعد بيانات NoSQL بنموذج كالمستخدم في (أو الذي تحتاجه) الحلول العلائقيّة المهيكلة. هناك العديد من التطبيقات، وكلّ منها تعمل بطريقة مختلفة كليًّا، وتخدم احتياجات محدّدة. هذه الحلول عديمة المخططات (schema-less) إمّا تسمح تشكيلات غير محدودة للمدخلات، أو –على العكس– بسيطة جدًّا ولكنها كفؤة للغاية كمخازن قيم معتمد على المفاتيح (key based value stores) مفيدة. على خلاف قواعد البيانات العلائقيّة التقليديّة، يمكن تجميع مجموعات من البينات معًا باستخدام قواعد بيانات NoSQL، كـ MongoDB مثلًا. تُبقي مخازن المستندات هذه كل قطعة من البيانات مع بعضها كمجموعة واحدة (أي كملف) في قاعدة البيانات. يمكن تمثيل هذه المستندات ككيانات بيانات منفردة، مثلها في ذلك كمثل JSON، ومع ذلك تبقى كراسات، وذلك يعتمد على خصائصها. ليس لقواعد بيانات NoSQL طريقة موحدة للاستعلام عن البيانات (مثل SQL لقواعد البيانات العلائقيّة) ويقدم كلّ من الحلول طريقته الخاصّة للاستعلام. ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد البيانات العلائقيّة، ألق نظرة على هذه المقالة المتعلقة بالموضوع: A Comparison Of Relational Database Management Systems. مقارنة بين أنظمة إدارة قواعد بيانات SQL و NoSQLمن أجل الوصول إلى نتيجة بسيطة ومفهومة، لنحلّل أولًا الاختلافات بين أنظمة إدارة قواعد البيانات: هيكلية ونوع البيانات المحتفظ بها:تتطلب قواعد البيانات العلائقيّة SQL هيكلة ذات خصائص محدّدة للحفاظ على البيانات، على خلاف قواعد بيانات NoSQL التي تسمح بعمليات انسياب حُرّ (free-flow operations). الاستعلام: وبغضّ النظر عن تراخيصها، تستخدم كلّ قواعد البيانات العلائقيّة معيار SQL إلى حدّ ما، ولهذا يمكن الاستعلام فيها بلغة SQL (أي Structured Query Language). أما قواعد بيانات NoSQL فلا تستخدم طريقة محدّدة للعمل على البيانات التي تديرها. التحجيم: يمكن تحجيم كلي الحلين عموديًّا (أي بزيادة موارد النظام). لكن لكون حلول NoSQL تطبيقات أحدث (وأبسط)، فهذا يجعلها تقدّم وسائل أسهل بكثير لتحجيمها أفقيًّا (أي بإنشاء شبكة عنقودية cluster من أجهزة متعدّدة). المتانة Reliability: عندما يتعلق الأمر بالمتانة والثقة الآمنة بالقَيد المنفّذ، تبقى قواعد بيانات SQL الخيار الأفضل. الدعم: لأنظمة إدارة قواعد البيانات العلائقيّة تاريخ طويل استمر لعقود من الزمن. إنها شائعة جدًّا، ومن السهل إيجاد دعم سواء مجانيّ أو مدفوع. إذا حدثت مشكلة، فمن الأسهل حلّها عليها من قواعد بيانات NoSQL التي شاعت حديثًا، وخاصة إذا كان الحلّ موضع السؤال ذا طبيعة معقّدة (مثل MongoDB). احتياجات حفظ واستعلام البيانات المعقدة: إنّ قواعد البيانات العلائقيّة بطبيعتها الخيار الأمثل لاحتياجات حفظ البيانات والاستعلامات المعقّدة. إنها أكثر كفاءة وتتفوق في هذا المجال. ترجمة -وبتصرّف- للمقال Understanding SQL And NoSQL Databases And Different Database Models لصاحبه O.S. Tezer.

إنشاء منتج ذي قيمة يتطلب الحصول على تغذية راجعة ذات قيمة. يحدّد من تتحدّث معه منذ البداية الكثير من الأمور. حيث بدأت أنا وشريكي المُؤسّس قبل بضعة أسابيع في اختبار المنتج الثاني لشركتنا في المرحلة التجريبية بيتا (beta) داخليًّا. إنّ منتجنا الأول Exist في طور بيتا العلنيّ (أي في الطور التجريبيّ الذي يمكن لمن هم خارج فريق العمل الوصول إليه) منذ عام تقريبًا. لقد وقعنا في الكثير من الأخطاء التي تعلمنا منها الكثير. نحن نعلم ما علينا فعله بطريقة مختلفة هذه المرّة، وهو ما سيسمح لنا بارتكاب أخطاء أخرى. فيما يلي بعض الدروس التي أرغب بمشاركتها. انتقِ مستخدميك بعنايةكان خطأنا الأكبر في اختبار النسخة التجريبية بيتا اختيارُ المستخدمين الخطأ. حاولنا حماية ثقتنا الهشّة بأنفسنا ودعَونا فقط الناس الذين كنا نعرفهم. كنّا نأمل بالحصول على تغذية راجعة صريحة (ولكن مؤدبة) لمساعدتنا في تحسين المنتَج دون أنّ نجد أنفسنا غارقين في بحر من الإحباط قبل أن نُطلق مُنتَجنا حتّى. لقد صدمتنا الحقيقة أكثر: لم نتلقَّ أيّة تغذية راجعة مُطلقًا. لم نحصل على التغذية الراجعة التي كنّا بحاجة إليها لأننا لم نكن نتحدّث إلى مستخدمين مهتمين. لقد كان "المستخدمون" لدينا مجرد أشخاص لديهم خمس دقائق ليساعدونا فيها وليس لديهم أيّ اهتمام حقيقيّ بإخبارنا بما أرادوا عمله بمنتجنا. لماذا؟ لأنّهم لم يكونوا بحاجة إلى منتجنا. لم نكن نحلّ أيّة مشاكل تواجههم. لم يعرفوا قيمة المنتَج ولم يتواجدوا لمدّة طويلة. أغلبهم اختفوا بعد أوّل ولوج لهم، والبعض رجعوا مرّة في الشهر في أفضل الحالات. لا تضيّع الوقت مع مستخدمين لا تخدمهم. لن تحصل على التغذية الراجعة التي تحتاجها من أناسٍ ليسوا بحاجة إليك. القيام بالأمر بالطريقة الصحيحة: اختر مستخدمين من السوق الذي تستهدفه.من أجل منتَج جديد، عليك البحث عن مستخدمين يعانون من المشكلة التي تُحاول حلّها، ولديهم حاجة، وراغبون في أن يستثمروا للحصول على قيمة. وبينما تبني أعمالك مع الوقت، يصير هذا أسهل بكثير. نركّز في منتجنا الثاني على نفس الزبائن الذين بنينا لهم مُنتجنا الأوّل، ولهذا فلدينا بالفعل مجموعة مستهدفة يمكننا الحصول على مختبرين لنسخة بيتا منها. عندما تبني علاقة مع أناس يستخدمون منتَجك، فهم أقرب لأن يكونوا مهتمين بمشاريع أخرى تعمل عليها. يمكنك أن ترى هذا في مشاريع أخرى أيضًا. عندما كانت Basecamp ما زالت تُعرف باسم 37aSignals، كانت لديها منتجات تستهدف نفس قاعدة المستخدمين. من الأسهل بكثير إيجاد مختبري بيتا –وفيما بعد مستخدمين يدفعون لقاء الخدمة– من كمّ المستخدمين الذين يعرفونك ويثقون بك بالفعل. إذا كنت في بداية مشروعك الأول، فلن تكون لديك ميزة قاعدة المستخدمين الموجودة بالفعل، ولكن يمكنك بناء جمهور بطرق أخرى. قبل أن نُطلق Exist للعموم بستة أشهر، بدأت في مدونتنا سلسلة مقالات دوريّة تُركِّز على الأخبار والمنتجات الجديدة في المجال الذي يختصّ فيه المُنتج. وبينما كنت أكمل هذه السلسلة كلّ أسبوع، أنشأنا أرشيفًا للمحتوى المتعلق بالسوق الذي نستهدفه وطورنا جمهورًا من الناس المهتمين بهذه المواضيع. لقد أنشأنا قائمة بريديّة لمن ينتظرون Exist لإبقاء الزبائن المحتملين على اطلاع على تقدمنا، ولقد استطعنا باستخدام رسائل البريد الإلكتروني المتعلقة المتعلقة بالتحديثات وبإنشاء محتوى يهتمون به أن نُنشئ علاقات مع الكثير من الزبائن حتى قبل أن يستخدموا منتجنا. وفي في المراحل اللاحقة من اختبار بيتا، استطلعنا قائمة المنتظرين لدينا لنجد الناس المهتمين بمنتجنا والذين يقدّرون قيمته. وبتأمل الأمر، كان يجب أن نأخذ هذه الخطوة قبل هذا بكثير. طلب التغذية الراجعة كلما حصلت على تغذية راجعة مبكرًا كلما كان هذا أفضل. تحصل الأفكار الجيدة على فرصتها، وتُصمَت الأفكار الضعيفة. عدم فهم المستخدمين جيدًا أمر خطير. من دون الفهم الجيد لن تعلم الاتجاه الأفضل لمنتجك ولا تعلم لمَ يُغادر الزبائن (أو لماذا يبقون). التغذية الراجعة هي الحلّ. من السهل أن تشعر أنك تزعج الناس، وخاصة في المراحل المُبكّرة من المُنتج. ولكن كأيّ شيء آخر في هذه الحياة، لن تعلم حتّى تسأل، والناس عادة يكونون مستعدين للمساعدة أكثر مما تتصور. أن تتوقّع من الزبائن أن يعطوك تغذية راجعة دون طلب منك توقُّعٌ مبالغٌ فيه. أنت مسؤول عن بدء الحوار. القيام بهذا الأمر بالطريقة الصحيحة: اسأل كثيرًا، وبطرق مختلفةالتحدّث مع زبائنك في الوقت الحقيقيّ (إمّا وجهًا لوجه أو عبر سكايب) من أفضل الطرق التي وجدتها تكشف عن تغذية راجعة مفيدة. عندما تتحدث إلى مستخدم وجهًا لوجه بهذه الطريقة، فيمكنك أن تتعمّق أكثر في الصغائر التي يقولها وأن تدعه ينطلق بالحديث عن هذه الخفايا. هذه هي الطريقة الأمثل في الحصول على صورة متكاملة عن كينونة هذا المستخدم، وكيف يناسب مُنتَجُك حياتَه. لكن أحيانًا لا تكون هذهِ التغذيةَ الراجعةَ التي تحتاجها. عندما رغبنا أن نعلم ما هي الأجزاء الأكثر شعبية في منتجنا، أرسلنا استبيانًا لكل المستخدمين عبر البريد الإلكترونيّ. لم يكن هذا مباشرًا بقدر المكالمات الحيّة، ولكننا استطعنا جمع معلومات من مستخدمين كُثُر في وقت قصير، وتمكنّا من السؤال عن الأمور التي نرغب بمعرفتها بالضبط. أحيانًا ترغب فقط بتقييم عام وواضح عن منتجك أو خدمتك. يمكنك في هذه الحالات أن تستخدم سؤالًا بسيطًا مثل: "هل تنصح صديقًا باستخدام منتجنا؟"، أو بسؤال مستخدميك كيف يقيمون خدمة الزبائن بعد أن تحل مشكلتهم. يجب أن تعتمد طريقة طلبك للتغذية الراجعة على طبيعة التغذية الراجعة التي تريدها. التزم بتوجّه واحد رئيسيّ للتغذية الراجعة في الأيام الأولى لمشروعك. تقليل الاستجابات وانزعاج المستخدمين يمكن أن يحدثا إذا شعروا أنك تُرسل إليهم طلبات كثيرة. لا ترسل استمارات تُزعِج فيها المستخدمين في نفس الشهر الذي تقوم فيه بجهد لعمل مقابلات تطوير. التغذية الراجعة المركزة المستمرة هي ما يُنشئ انطباعًا ذا معنى. الاستماع إلى الأقليات الصاخبة؟عندما تبذل جهدًا كبيرًا للحصول على تغذية راجعة، فإن أيّ قدر قليل منها يبدو كذهب خالص. قد يوقعك هذا بسهولة كبيرة في فخ الأقليّة الصاخبة (vocal minority، وهي الأقليّة التي تعبّر عن آرائها باستمرار). تجد بأن عددًا من المستخدمين يطلبون ميزة معينة فكرت ببنائها، وفجأة تبدأ بالظنّ بأنّ كلّ المستخدمين يريدونها بالتأكيد وتحدّثك نفسك بأنه من الواضح أنهم لم يتمكنوا من إخبارنا بذلك وحسب، ولهذا تُقرّر بناءها وإضافتها. والأسوأ من هذا أن هناك ميزة معينة لم تفكر ببنائها، فيأتيك ستة أوسبعة مستخدمين ويسألون عنها في نفس اليوم. وتكتشف لاحقًا أنك بدأت تبني ميزة جديدة دون اطلاع كافٍ على الوضع العام. من السهل أن تنقضّ على شيء وتبدأ بالعمل عليه شاعرًا أنه عاجل أو مطلوب، مع أنه ليس كذلك. يبدو هذا سخيفًا، لكننا جميعًا معرضون لذلك. لعمل شيء يريده الناس، أثبت أولًا أنهم يريدونه بحقّ. تأكّد من صحّة الفرضيات التي تعتمد عليها قبل أن تشرع في البناء. التغذية الراجعة هي أفضل وسيلة لبناء فرضيات حول ما قد ترغب به غالبية المستخدمين. يمكنك بعدها أن تقوم بالمزيد من التطويرات المتعلقة بالزبائن لترى إن كانت تلك الفرضية ستصمد. إذا صمدت الفرضيًة، وكانت غالبية المستخدمين لديهم نفس الشعور، فيمكنك عندئذ أن تبدأ بالبحث في أعماق الأمر، لتجد السبب الذي يدفعهم للرغبة بهذه الميزة تحديدًا، وكيف يمكنك حلّ تلك المشكلة بالنسبة لهم (الأمر يتعلق بالاحتكاك وليس بالميزة). لدى بناء مُنتجنا الجديد، نستخدم كلا من Help Scout والوسوم (tags) للتغذية الراجعة لنبقى على اطّلاع دائم بعدد الطّلبات التي تصلنا حول كل خاصّيّة. من السهل والسريع إضافة وَسم (tag) عندما ترد على زبون، ورؤية عدد الطلبات على كل وسم تسهل اختيار ما سيتم عمله لاحقًت دون أن تغرق في طلبات الأقليّة الصاخبة تلك. إنّ التغذية الراجعة جزء متعدد الأوجه من أجزاء بناء شركة. سواءٌ كنت تحصل على تغذية راجعة أكثر من اللازم، أو كانت لديك تغذية راجعة مربكة أو متضاربة، أو لم تكن تحصل على تغذية راجعة على الإطلاق، فلستَ وحدك. اختر زبائنك بحرص، واطلب تغذية راجعة باستمرار، ودائمًا تأكد من الفرضيًة قبل تطبيق ما تتلقاه من الزبائن. القول أسهل من الفعل، ولكن التحسينات التي أقوم بها في التعامل مع التغذية الراجعة للزبائن جعلتي أفضل في بناء أفضل منتج للمستخدمين. ترجمة -وبتصرف- للمقال: Talking to Your Very First Customers.

ليست جودة عملك هي ما يحدّد مدى نجاح مشروعك؛ بل ما يحدّد مدى نجاحهِ جودةُ تواصلك مع العميل. بجدّ! فكر بالأمر كما يلي: لقد حققت أفضل إنجاز عملت عليه طوال حياتك بتصميم شعار (logo)، أو ببرمجة تطبيق، أو بكتابة مقال أو إعلان. هذا العمل يجمع كلّ مهاراتك وخبراتك ومعرفتك وعلمك وشغفك. ولكن فيما بعد، تعرض عملك على زبون ولا يعجبه مطلقًا. ليس هذا وحسب، بل يقولون لك أنّ هذا ليس ما أراده أصلًا، وأنّ عليك إعادة بدئه من الصفر، وأنّه يرغب بالاتصال بك هاتفيًّا في الساعة السابعة من صباح اليوم لمناقشته (لم يتبق حتّى ذلك الوقت أكثر من بضع ساعات). لن أقول بأنّي حذرتك، وذلك لأننا جميعًا عرضة لنتائج كهذه عندما لا نتواصل بشكل فعّال. بغض النظر عن مدى جودة عملك، فعليك فهم احتياجات العميل، والتعبير عن سبب كون العمل الذي تعرضه عليهم هو المطلوب لتلبية احتياجاتهم. عدا ذلك، فلا قيمة لعملك بأكمله. إذا كان التواصل الجيد أساس المشروع الناجح، فماذا بإمكانك أن تفعل لضمان حدوث ذلك؟ تحديد ما يُفترض تسليمه بدقّةإذا لم يكن كلا الطرفين واضحين فيما يتعلق بما يفترض تسليمه، والعملية المطلوبة، والجدول الزمني، ومن المسؤول عن كل جزء – كتابيًّا، وقبل الحديث عن المال – فأنت تقفز في مياه لا تعلم مدى عمقها. عليك أيضًا أن تعلم مدى معرفة العميل بما سيكون مسؤولًا عنه. على سبيل المثال: إذا كنت تبني موقعًا له، فهل يعلم كيف يستخدم نظام إدارة محتوى (CMS)؟ إذا لم يكن العميل يعرف ما تفعله، فعليك أن تفهّمه ذلك بطريقة بسيطة (عدا ذلك، لن يقدّر قيمة ما تقدّمه له). وضّح خبراتكلا يكفي أن تخبر العميل بأنك تستطيع إنجاز العمل. عليك أن توضّح لمَ أنت الشخص المناسب للقيام بهذا العمل، وكيف ستحل المشكلات التي يواجهها، وكيف ستوصله إلى أهدافه. قم بهذا في وقت مبكّر قدر الإمكان، بحيث يبدأ بأخذك بعين الاعتبار كخبير وليس فقط كعامِل مُستأجَر. حدّد أهدافك ونجاحاتك بدقّةما أهداف المشروع؟ وكيف سيتم قياس مدى النجاح؟ بغض النظر عن ما تفعله، سيغذّي هذا التواصلُ أيّةَ مناقشات أثناء العمل على المشروع. يريد العملاء نتائج قبل أيّ شيء آخَر؛ حدّد بدقة ما يعني هذا. التواصل الأسبوعيّبالنسبة للمشاريع طويلة الأمد، تواصل مع عميلك مرة واحدة أسبوعيًّا على الأقلّ. بيّن ما وصلت إليه، وما أتممته، وما المميز، وما المطلوب أن يفعله العميل الآن أو الأسبوع القادِم. هذا سيبقي الأمور في مسارها، وإذا خرج شيء ما عن مساره، فمن الأفضل تصحيح المسار في أسرع وقت. التزم بالمطلوبإذا كانت مهمة ما غير مدرجة في "المتطلبات" (deliverables)، فلا يُفترض بك أن تُنفّذه مجانًا. كن لطيفًا ولكن حازمًا عندما يطلب عميل شيئًا ما خارج نطاق المطلوب. أحيانًا يكون خطأً من العميل بحيث لا يكون عارفًا بخفايا الموضوع، وأحيانًا يكون محاولةً للحصول على أكثر مما يدفع مقابله. تأكّد من وجود خطّة لما بعد المشروع أيضًا؛ إذا كان العميل راغبًا في أن تقوم بالمزيد من العمل بعد انتهاء المشروع، فكيف سيتم الأمر؟ حدّد خط انتهاء لكل مشروع، ليس فقط من حيث وجود تاريخ ونهاية محدّدة للمشروع، بل وحتى وجود فرصة للعمل مستقبلًا (بالمشروع، أو بالتعاقد، إلخ). ضع حدودًاإذا كان المشروع يتطلب الكثير من التواصل الحيّ، فأعلِم العميل متى تكون بالعادة متاحًا، ومتى لا تكون مشغولًا بالعمل. فمثلًا، يمكنك تحديد ساعات عملك من الساعة العاشرة صباحًا وحتى الخامسة مساءً بتوقيت جرينيتش، من يوم الإثنين وحتى الخميس. إذا راسلك أو تواصل معك خارج هذا الوقت، فستكون قد أخبرته مسبقًا بأنك غير متاح. اعلم أنك إذا استجبت للبريد أو المكالمات خارج هذه الأوقات، فأنت تظهر له أنك لا تحترم الحدود التي وضعتها، وبهذا لا يلتزم هو أيضًا. أعد صياغة طلباته وأفكاره بلغتك الخاصّةعندما يسأل العميل عن شيء ضمن حدود العمل، فأكّد بالضبط ما يريد عمله بلغتك الخاصّة. هذا يعطيه فرصة أخرى ليتأكد مما إذا كان هذا ما يريده حقًّا. هذا يجنبك سوء الفهم، ويجنبك كذلك الطلبات الهشّة (حيث يمكن أن يغيّر رأيه). تحدّث عن خبراتكليس عليك أن تكون هجوميًّا، ولكن إذا طلب العميل شيئًا تعلم أنّه غير صحيح أو أنه لن يساعده على تحقيق أهدافه، فأعلمه بذلك. يدفع العميل لك لأنك الخبير، ولأن رأي الخبير له وزنه. استمع بشكل جيّدمن المذهل مقدار ما يمكنك تعلمه عن طريقة تقديم عمل رائع لعميلك عندما تستمع إلى ما يريد قوله. وأكثر من هذا، استمع لما وراء ما يقوله [أو كما نقول، اقرأ بين السطور]، لأنّه يمكن أن يفتقر العميل للبلاغة الكافية للتعبير عنه. فمثلًا، إذا كان عميل ما يريد 100 صفحة من المسجلين لمجلته، فما يريده بالفعل هو المزيد من المسجّلين، وهو ما سيزيد من مبيعات منتجه. اسأل "لماذا؟" للوصول إلى احتياجاته الحقيقيّة. وحتى مع وجود تواصل مثاليّ، فلا يمكنك أن تضمن استجابة مثاليّة من كلّ العملاء. يمكن أن لا يقوموا بالأمر ضمن حدود الجدول الزمنيّ، أو حتى أسوأ من هذا، كأن يتوقفوا عن التواصل نهائيًّا. في هذه الحالات، عليك أن تتذكّر أنه حتى إن لم يكن العميل يتصرف بمهنيّة ويلتزم بما عليه فعله في المشروع، يتحتم عليك أن تكون متحضّرًا وخدومًا. شخصيًّا وجدت أنه في غالب الأوقات إذا توقف العميل عن الاستجابة، أو إذا لم يلتزم بالمواعيد، فهذا بسبب أمرين: 1) هناك شيء شخصيّ يحدث في حياته (ولا يمكنك عمل شيء حيال الأمر)، أو 2) أو أنّه مرتبك أو مُرهَق أو مشغول جدًّا، أو لا يعرف كيف يفعل المطلوب منه. في هذه الحالة، كل ما يمكنك فعله هو أن تعرض عليه المساعدة – ليس بالقيام بشيء خارج نطاق العمل، بل بتوضيح شيء ما مجدّدًا أو بأن تعرض عليه أن يسلّم العمل الذي يقوم به إلى شخص آخر. فمثلًا، معظم عملاء مشاريع تصميم المواقع يتكاسلون عن إضافة وتعديل محتوى مواقعهم. إذا حدث هذا معي، فأول ما أفعله هو أن أقترح عليهم كاتب محتوى أو محرّرًا أو مساعدًا عن بُعد ذي خبرة ليساعدهم في وضع المحتوى في الموقع. إنّ أولئك الذي لا يُرهَقون أثناء كلّ مشروع وذلك لأنّ عملاءهم يطلبون أشياء "خاطئة" أو "غبيّة" يعلمون أن التواصل الجيد من البداية وحتى النهاية هو ما يجعل المشروع ناجحاً وممتعاً بالفعل معًا. العمل الذي تقوم به لعميلك مهمّ، ولكن الطريقة التي تتواصل بها معه عن العمل لها نفس الأهميّة. ترجمة – وبتصرف – للمقال How Communication Determines A Project’s Success.

إذا كنت قد عشت على وجه الأرض لمدة، فمن المؤكد أنك تذكر هذه الصور المتحركة المبتذلة التي تقول "الموقع قيد الإنشاء" والتي استُخدِمَت في أواخر التسعينات. لقد أحببناها، أليس كذلك؟ على أيّة حال، لقد حصل الكثير لتصميم المواقع منذ ذلك الحين. وهكذا بالنسبة للرسوم المتحركة على الوِب، حيث لم تعد هذه الحركات مبتذلة هذه الأيام، بل أنها – على ما يبدو – وجدت مكانها بين أدوات وآليات التصميم الأخرى. فلنلقِ نظرة إذًا على كيفيّة استخدام الرسوم المتحركة بفعالية، والمكان الذي تشغله في عالم تصميم المواقع الحديث. دور الحركات في الوِب الحديثقد يبدو هذا مفاجئًا في البداية، لكن عندما يتعلق الأمر بالفوائد الأساسيّة التي يمكن للحركات الجيدة أن تُضفيها، فلا شيء تغير خلال العقد الماضي، وذلك بالأساس لأن العقل البشري ما زال يعمل بنفس الطريقة تقريبًا، بغضّ النظر عن توجهات التصميم الأكثر شيوعًا هذه الأيام. فعلى سبيل المثال، أُثبِتَ أن هذه الحركات تُساعدنا على فهم ما يحصل على الشاشة، وما العنصر الأكثر أهميّة الذي علينا أن ننتبه إليه. لماذا؟ لأن هذه هي الطريقة التي يعمل بها دماغُنا. آلاف السنوات من التطور جعلتنا ما نحن عليه، وجعلتنا نعير انتباهنا للحركة. عدا ذلك، لم نكن لننجو من هجمات المفترسين في اماضي عندما كنّا نعيش في الكهوف. ولهذا، فمن المثير للاهتمام – حتى في عصر التصاميم المسطّحة والبسيطة – أنّ الحركة ما زالت تحتفظ بمكانها، وما زال بالإمكان (والمفروض أن يتم) بكل تأكيد استخدامها لإثراء تجربة المستخدم وجعل تصاميمنا مفهومة أكثر. إن الشيء الوحيد الذي تغير هو الشكل الذي يمكننا أن نستخدمه به بفعالية. لا تبدو الحركات الجيدة في 2015 – من وجهة نظر تقنيّة – مشابهة للحركات التي كانت شائعة في أواخر التسعينات وبداية العقد الأول لهذا القرن على الإطلاق. هناك العديد من الأسباب لذلك، لكن اثنين منها، وهي: 1- التقنيات الحديثةباستخدام مكتبات CSS وجافاسكربت الحديثة، صار بإمكاننا الآن إنشاء حركات مُذهلة عبر واجهات برمجة تطبيقات (APIs) والأطر البرمجية (frameworks) المُعدّة مسبقًا. وليس علينا أن نفهم الأشياء في أدنى مراحلها البرمجية؛ لكن ما علينا فهمه بدلًا من ذلك هو كيفية العمل داخل الواجهة التي توفرها لنا واجهة برمجة التطبيقات. فعلى سبيل المثال، من الأشياء التي من الممكن أنك تعرفها من مجموعة أدوبي بيئةُ إدج أنيميت Edge Animate. إن هدفها هو السماح لمصممي المواقع أن ينشئوا رسوم HTML متحركة تفاعلية عبر واجهة يسهل فهمها. في نهاية المطاف، إنها الأداة التي تزيح عنك الأحمال لتدعك تركز على الجزء الإبداعي دون القلق بشأن ما يحدث خلف الكواليس. لكن التقنيات لا تتعلق فقط بالأدوات وبجافاسكربت وCSS، بل وتتعلق أيضًا بالعتاد، وعلى وجه الخصوص العتاد الموجود بداخل الأجهزة النقّالة. لنواجه الأمر؛ إنّ الأجهزة النقّالة هذه الأيام هي حواسيب معياريّة دون قدرات عالية على المعالجة، والشيء الوحيد المختلف بشأنها هو حجم شاشة العرض. عدا ذلك، يمكن لهذه الأجهزة أن تواكب كلّ شيء. 2- نُضج تصاميم المواقعقد يكون هذا انطباعي الشخصي وحسب، لكن يبدو أن مدراء المواقع قبل سنوات كانوا يرغبون بوجود أجزاء متحركة في مواقعهم لمجرد وجودها وحسب. لقد جعلت هذه الحركات التنقّل أصعب (أصعب فيزيائيًّا، حيث تتطلب تلك العناصر وقتًا أطول لتحميلها، إلخ) وأقل وضوحًا (كان من الصعب اكتشاف ما يمكن النقر عليه وما لا يمكن). الأمر محتلف هذه الأيام، فلم نعد مُبهرين بالرسوم المتحركة منفردة، ونرغب برؤيتها تخدم هدفًا محدّدًا عوضًا عن مجرد أن تكون هناك دونما سبب يدعو لذلك. وبعبارة أخرى، فإن ما يحدث للحركات مشابه – نوعًا ما – للأيام الأولى لمركبات السير. عندما ظهرت السيارات في بادئ الأمر، كان ما زال بإمكانك السفر أسرع باستخدام الحصان (وبشكل يُعتمد عليه أكثر). إذا كانت لديك سيارة في ذلك الوقت، فقد كانت لديك لمجرد أن تكون لديك، أو للتباهي بها فقط. لكن السيارة هذه الأيام صارت أداة لتحقيق إنجاز معيّن. إن حركات الوِب تذهب بنفس الاتجاه تقريبًا. وبناء على ذلك، ما زلنا في بداية هذا الطريق وسيستغرق الأمر بعض الوقت للاعتياد على الأدوات والمكتبات والنواحي التقنية عمومًا. وهو الأمر الذي أشار إليه ستيفِن سنِل من فاندِلي ديزاين عندما سُئِلَ عن الدور الذي ستلعبه الرسوم المتحركة في مستقبل تصاميم الوِب، حيث قال: ولهذا، في نهاية المطاف يكون السؤال عن كيفيّة استخدام الحركة لوضع نفسك على المسار الصحيح ولجعل واجهاتك سلسة الاستخدام أكثر، بدلًا من أن تكون أكثر بهرجة وإرباكًا. وفيما يلي بعض الأفكار: 1- استخدم الحركات لعرض تسلسل هرميّ.تُظهِر معظم تصاميم المواقع الثابتة المخطط الهرمي لها باستخدام ألوان محدّدة وعناصر كبيرة وسميكة والكثير من المساحات الفارغة حول أهم الأجزاء. هذه استراتيجية سليمة، لكن يمكننا عمل أكثر من هذا بكثير باستخدام حركات إضافيّة. لقد أثبِتَ علميًّا أنَّ الحركة ملحوظة أكثر بكثير من أيّ طريقة للعرض. ولهذا، فليست هناك أيّ طريقة أفضل لتوضيح أهميّة بعض العناصر أكثر من إضفاء الحياة عليها باستخدام الحركة. خذ هذه على سبيل المثال: [حركة تطبيق موسيقى لسِرجى فاليوك و توبيك ستوديو في Behance] واضح من النظرة الأولى العنصر الأكثر أهميّة في هذه الصفحة، وهو استعراض التطبيق. يؤدي هذا التطبيق دوره بامتياز في تركيز انتباه الزائر مباشرة. 2- اجعل التصميم المسطّح أسهل للفهموبقدر ما هي التصاميم المسطّحة عظيمة، ما زالت هناك بعض المشكلات العويصة بالنسبة للمفهوم ذاته. فمثلًا، رغم أنّ المستخدمين ذوي الخبرة في كيفية عمل واجهات المواقع ليست لديهم أيّة مشكلة في التفاعل مع المواقع المسطحة، إلا أن المستخدمين الأقل معرفة يواجهون صعوبة أكبر بكثير، والسبب وراء هذا الإرباك هو أن توجهات التصاميم المسطحة لجعل العديد من عناصر الواجهات العديدة تبدو متشابهة، إلّا أنّ هذه العناصر – كالأزرار مثلًا – ليست دائمًا مباشرة في مظهرها مقارنة بالأشياء الأخرى. في هذه الحالة تكون الحركة واحدة من الآليّات القليلة التي ما زال بإمكانها التفرقة وجعل الواجهة مفهومة من جديد. فمثلًا، ألقِ نظرة على الأيقونات التالية: [115 أيقونة متحركة لهَنَك إرتَن و سِنان كَرتشَم من Behance] رغم أن الحركة البسيطة ليست مميزة في ذاتها، إلا أنها تؤدّي غرض جذب انتباه الزائر وتشجيعه على التفاعل مع الأيقونة. 3- كُن مُرهفًا، لا مُبَهرجًالقد مضت التسعينات منذ زمن بعيد، ووجد الحركة لمجرد وجودها لم يعد له مكان في الوِب، وبما أن المستخدمين لم يعودوا يُبهَرون بالأشياء التي تتحرك، فالطبيعة الأساسيّة للحركات يجب أن تكون أكثر رقّة. إن المعيار الذهبيّ هو جعلها حيويّة بما يكفي لملاحظتها، لكن أن تكون أيضًا خفيفة بما يكفي بحيث لا تغطّي على التصميم بأكمله. إنّ قيمة هذا التوجُّه هي تقليل احتماليّة أن يتشتت الزائر وأن يُركِّز على الحركة ذاتها، بدلًا من أن يركز على عامل الجذب الذي تضجّ به هذه الحركة. 4- استمر في التجربة على الأجهزة النقّالة دون توقُّفإن الهاتف النقّال هو البيئة الرئيسيّة التي يجب تحسين تصميمك لها هذه الأيام. لا يمكن التأكيد على هذا بما يكفي، لذا دعني أعيد ذلك من ناحية أخرى مختلفة كليًّا – الأجهزة النقّالة الآن أكثر أهميّة من الحواسيب المكتبيّة. أولًا، 60% من كل سير البيانات على الوِب هذه الأيام يأتي من الأجهزة النقّالة. ثانياً، حتى جوجل ضاقت ذرعًا بالمواقع غير المناسبة للأجهزة النقّالة، ولذه نشروا هذا البيان: ما يعني هذا بلغة مبسطة هو أنه إذا لم يكن موقعك مناسبًا للهواتف النقّالة، فستعاني من تدني مستواه في نتائج البحث. إضافة إلى ذلك، فإن جعل الموقع مناسبًا للهواتف النقّالة يتعدّى مجرّد جعله سريع الاستجابة، وهذا من الأمور التي ينبغي أن تُبقيها في بالك ليس فقط عند تصميم الحركات، بل عند عملك على موقعك التالي عمومًا. ولهذا، فإن إدراج حركات ليست مناسبة للأجهزة النقّالة أو – أسوأ من ذلك حتى – لا يمكن الوصول إليه عبر الأجهزة النقّالة على الإطلاق هو بحث عن المتاعب. اجعل الاستمرار في اختبار حركاتك على كلّ الأجهزة النقّالة الشائعة خطوةً مستمرة في عملية التطوير لديك. 5- استخدم الحركات كالعنصر الذي يجعلك فريدًافلنبقَ مع التصاميم المسطّحة لدقيقة أخرى هنا. كما قلنا سابقًا في هذا المقال، فإنّ العديد من التصاميم المسطّحة تبدو عادًة متشابهة جدًّا، ولهذا فجعل عملك مميزًا أمرٌ صعب. ورغم أنه بإمكانك دائمًا البحث عن أنماط ألوان إبداعيّة أو ما شابه، إلّا أنك ما زلت محصورًا بهويّة الشركة والمظهر المرتبط بالماركة التجاريّة التي تبني التصميم لها. إنّ كلّ هذه المحدوديّات تجعلُ الحركةَ الأداة المثاليّة لجعل تصميمك فريدًا. والأهم على الإطلاق أنك لست بحاجة للتكون مختلفًا جدًّا. خذ هذه الأمثلة بعين الاعتبار: عين النَّسر (تحليلات لتويتر وإنستجرام) لفرحان رَزَق Dianping Film promotion Html5 / FURY بواسطة wang 2mu, He Fan & 3 Water على Behance كلا التصميمين بسيطان جدًّا بطبيعتهما، والحركات المستخدمة فيها هي العناصر الوحيدة التي تجعل هذه المواقع مميزة. إذا كنت لتزيل هذه الحركات، فسيبدو التصميم بسيطًا جدًّا، ولن يجلب هذا القدر من الانتباه. 6- استخدم الحركة لأجزاء محدّدة من المحتوىعمل تصاميم مواقع مخصّصة باستخدام الحركات أمرٌ، ولكن بإمكانك أيضًا أن تسير باتجاه أقل بُعدًا، وأن تستخدِم الحركات عند العمل على عناصر منفردة. فمثلًا، يُعرَف نِل باتِل من كويك سبراوت بنشره وزيادته لشعبية مفهوم الإنفوجراف المتحرّك. إن الفكرة ذاتها واضحة من حيث المبدأ، حيث يُنشئ ما يمكن أن يكون إنفوجراف معياريّ، لكن بعد ذلك يضيف عناصر متحركة إليه. فيما يلي مثال لإنفوجراف متحرك آخر. عمل ذلك سيعطيك ميزة إضافيّة عن المنافسين والمواقع الأخرى في ذات الموضوع، والتي تُكافِح كلها لجذب انتباه الزائر. الإنفوجراف هذه الأيام مجرد مفهوم واحد. يمكنك أن تستخدم نفس هذه الفكرة في النشرات والمقالات والدراسات القياسيّة وأيّ محتوى آخر. 7- جرِّب الحركات المعتمدة على التمريرإنّ الحركة موضوع واسع، ومتشابك. فمثلًا، ليتم اعتبار شيء ما متحرّكًا، هل يجب أن يكون متحرّكًا فعليًّا أم أنه يجب فقط أن يبدو كذلك؟ من الأمثلة العضيمة على هذا تأثير parallax للتمرير (وهو التأثير الذي يكون فيه المحتوى على شكل طبقات بحيث يتحرك جزء منه بشكل أرع من الآخر، فيبدو كأن هذه العناصر على مسافات مختلفة من الرائي) والحالات الأخرى للحركة المحفّزة بحدث. إن الفكرة هي إنشاء انطباع بوجود حركة، وذلك باستخدام CSS وجافاسكربت وHTML. إن التصميم ذاته ثابت، لكن بمجرد أن يبدأ الزائر بالتمرير، فسيكون بإمكانه أن يرى وهمًا لعمق الميدان، أو حتى عناصر متحركة كاملة النُضج. خُذ هذين المثالين بعين الاعتبار: الأول تأثير انتقال parallax بسيط، والثاني حركة تمرير أكثر تعقيدًا مفعلة بحدَث. 8- استخدم الحركة للإشعاراتتكون الحركة أكثر ظهورًا عندما تبدو أول مرة من شاشة العرض. هذا يجعلها أداة مثاليّة لعرض الأنواع المختلفة للتنبيهات. فمثلًا، يمكنك في أيّ وقت يكون فيه حدث يجري خلف كواليس واجهة الموقع (كحفظ بعض الإعدادات في لوحة تحكّم المدير مثلًا) أن تُنبِّه الزائر إلى أنّ العمليّات تمّت وذلك باستخدام صندوق متحرك يظهر في مكان ما في رأس شاشة العرض. هذا الشعور المتعلق بالحركة غير المتوقّعة في بيئة ثابتة هو كلّ ما تحتاجه لتنبيه المستخدم. فمثلًا، ألقِ نظرة على الإشعارات التي يُمكن أن تُبنى باستخدام هذه الأداة. لا شيء مُبهر من ناحية التصميم، لكنها تقوم بعملها على أكمل وجه وتجذب انتباه المستخدم. 9- ركّز على جودة الحركةكلما كانت الحركة في الوِب هذه الأيّام أقلّ كلما كانت أفضل (وكذلك في المستقبل)، لكن لا يمكنك أن تُخاطِر بالجودة من خلال سعيك نحو الأقلّ. حتى جوجل تُظهِر هذا في قواعد التصميم الماديّ الخاصّة بهم فيما يتعلق بالعمل مع الحركة. إنهم يشجعون في وثائقهم الرسميّة المصممين على جعل حركة كلّ عنصر حقيقيّة؛ مما يعني إضفاء وزن وزخم وتسارع وخصائص أخرى تحظى بها عناصر العالم الحقيقيّ. لا تتردّد في الذهاب لرؤية القواعد إضافة إلى المرئيات الاستعراضية التي عملتها Google. الخُلاصةلم تكن الحركة دائمًا الأداة الأكثر تقديرًا في تاريخ تصميم الوِب، ولكن هذا في الغالب سيتغير في 2015 وما يليها. فمع التطورات التقنيّة والنُضج التام لعالم تصميم المواقع، صار الناس راغبين أكثر في أن يجربوا وأن يحاولوا تحسين واجهات الاستخدام لديهم باستخدام عناصر متحركة بسيطة ولكن مفيدة. فمن ناحية، ذهبت أيام استخدام الحركات المُبَهرجة لمجرد استخدامها منذ زمن بعيد، ولكن من ناحية أخرى، بدأت الأيام التي تُثري فيها الحركات تجربة المستخدم وتجعل الموقع أكثر فعالية. ما رأيك بهذا؟ هل وقعت يدك على أيّة طرق لاستخدام الحركة في تصميم المواقع تجدر الإشارة إليها؟ ترجمة -مع شيء من التصرف- للمقال: Motion in Web Design the Smart Way.

تنبيه: الاختلافات في التفاصيل. بالنسبة للعين غير المدربة، فإنّ التصاميم المسطّحة (flat designs) والتصاميم الماديّة (material designs) تبدوان متشابهة جدًّا. أرجو أن لا تشعر بالإهانة عندما أقول ذلك، فمهما كنت مشجّعًا لأحد التوجّهين على حساب الآخر، فعليك أن تتفق معي على أنّ الاختلافات بينها طفيفة جدًّا. أو يفترض بي أن أقول: طفيفة ولكنّها هامّة. ولكن لنبدأ من البداية ولننظر إلى الحقائق عن كلّ من النوعين من التصاميم. أما بالنسبة للتصاميم المسطّحة، فقد غطّينا مبادئها الرئيسيّة وتاريخها (حتى أنّنا جلبنا 10 مصممين عظماء ليدلوا بدلوهم في الموضوع وليشاركوننا آراءهم حول سيطرة التصاميم المسطّحة على ساحة تصميم المواقع). ولتذكيرك، فإن التصاميم المسطّحة نوعٌ من التصاميم التي جُرِّدَت من كل العناصر ثلاثيّة الأبعاد. إنها تُزيل أيّة أشكال تحاول أن تحاكي العالم الحقيقيّ من هذه العناصر. كلّ ما هو جزء من تصميم مسطّح يبدو كما لو كان ملقىً على سطح واحد منبسط. ومن هنا جاءت التسمية. أما الآن، فلنقارن هذا مع التصاميم الماديّة. أولًا، التصاميم الماديّة مُنتَج ذو علامة تجاريّة (بطريقة ما). ما أعنيه بهذا هو أنّها تشكّلت على أيدي Google، وكل المعايير تم وضعها من طرف Google، وكل التغييرات على المفهوم تتحكم بها أو تقبلها Google. رغم هذا، إلّا أنك ما زلت حرًّا بعمل تصاميم ماديّة دون الحاجة للإشارة إلى Google بأيّ طريقة. يمكنك إلى حدّ ما أن تعتبر التصاميم الماديّة نقطة التقاء تصاميم الوِب، حيث أنه تصميم مسطّح في برنامجك الرياضيّ الخاصّ للتقوية والتطويع. اعذرني على هذا التشبيه. وتبعًا لهذا القَول، فإن ما ذُكِرَ أعلاه مجرد نظرة عامّة على ماهيّة التصاميم المسطّحة والماديّة، لذا هيّا بنا نغوض أعمق قليلًا الآن ونحاول تحديد بعض الاختلافات البسيطة والمبادئ التي عليك أن تلتزم بها عندما تصمِّم تصاميم مسطّحة أو ماديّة، حسب الحالة لديك. ولكن لن اكون وحدي من يناقش هذا الموضوع، فقد دَعَوتُ بعض خبراء تصميم المواقع لمساعدتي، وفيما يلي السؤال الذي سألتهم إياه: ما الذي يمكنك اعتباره الاختلافات الثلاثة الأهم بين التصاميم المسطّحة والتصاميم الماديّة؟وفيما يلي ما سنقوم به. أولاً، لنلقِ نظرة على الاختلاقات التي ذكرها الخُبراء، ثم لنتحدّث عن بعضها بتفصيل أكثر. وفي النهاية نقوم بتجميع كل شيء معاً لنخرج بقائمة للمزايا والمساوئ لكلّ من نمطي التصميم. الاختلافات الثلاثة الأهمّ بين التصاميم المسطّحة والتصاميم الماديّة – الخبراء يُدلون بدلوهم التصاميم الماديّة مفهوم معرّف جيدًافي وقت مضى، قدِمَت جوجل بمقدمتها للتصاميم الماديّة، والتي هي وثيقة متعمِّقة جدًّا تناقش مبادئ وأهداف وتعليمات التصاميم الماديّة. ذاك المستند مستمرٌّ في تلقّي التحديثات. لذا يمكنك عرضه في أيّ وقت لتعلم الخصائص والطبائع للحركة بأكملها. لم قدّمت جوجل التصاميم الماديّة؟ يمكن أن تكون الأهداف كثيرة، لكن أحدها يكمن في توحيد الطريقة التي تظهر فيها الأشياء على أجهزة أندرويد المختلفة (التي تستخدم شائات عرض وأجهزة مختلفة). جعل تطبيق يظهر متشابهًا على أجهزة عِدَّة مهمّة صعبة على المطوّرين، والتصاميم الماديّة تعمل جيدًا كمجموعة من التوجيهات لتسهيل هذه المهمّة. ولهذا، فالأمر المختلف بين التصاميم المسطّحة والماديّة هو أنّ التصاميم الماديّة مفهوم محدّد جيّدًا، بينما التصاميم المسطّحة نتيجة اختباريّة لعدد من أعمال التصميم المستمرة في اتجاه البساطة المطلقة. التصاميم المسطّحة كانت ردّة فعلإضافة إلى ذلك، فقبل أن تأتي التصاميم المسطّحة إلى حيّز الوجود – أو بالأحرى القول أنها تطوّرت إلى شكلها الحاليّ - كانت محاكاة الواقع التوجّه الشائع لتصميم المواقع. ولكن الواقعية (المبالغ فيها) بدت أكثر مما يحتمل للأعمال الحديثة، خاصة عند أخذ قابلية الاستخدام على الأجهزة النقّالة وعلى أجهزة متنوعة بعين الاعتبار. ماذا كان الردّ على ذلك؟ التصاميم المسطّحةباستخدام التصاميم المسطحة، لم يعد على المصممين أن يقلقوا بشأن جعل مشاريعهم تبدو واقعيّة. بدلًا من ذلك، يمكنهم أن يركّزوا على الفعالية والأداء. تعيد التصاميم الماديّة جانبًا من تقليد الواقعرغم أنّها فعّالة، إلّا أنّ مشكلة التصاميم المسطّحة هو أنّها ليست النوع الأكثر بداهة بين أنواع التصميم، وخاصّة عندما يتعلق الأمر بالمستخدمين غير العارفين لواجهات المواقع. بالنسبة لهؤلاء الناس، فإنّ خيارات التصميم والواجهات تجعل التفاعل أكثر صعوبة، خاصة عندما تكون قريبة جدًّا إلى مظهر عدم الوجود. التصاميم المادية تضيف الفيزياءتقول Google: كلمة "ماديّة" مجاز. أحد المبادئ الرئيسيّة للتصاميم المسطّحة تقليد الطريقة التي تعمل فيها الأشياء في العالم الحقيقيّ، ولكن عمل ذلك بطريقة بسيطة للغاية. وبعبارة أخرى، عمل ذلك بطريقة تستخدم الواقعيّة كأداة فقط لجعل أدمغتنا معتادة أكثر على كيفيّة عمل الواجهة، ولكن – في نفس الوقت – عدم جعلها تبدو واقعيّة زيادة عن اللزوم لمجرد ذلك إلى درجة أن تنتحل شخصيّة المقابل الحقيقيّ للعنصر. فمثلًا، زر يبدو كهذا ما زال يظهر كزِرّ: زِر ماديّ من تصميم Mauro Marini على Behance. ليس عليه أن يذهب بعيدًا في تقليد الواقع. انظر لهذا: زر تشغيل نظيف مصمم بـ photoshop من تصميم Pixel Mustache على Behance مزايا ومساوئ التصاميم المسطّحةبأخذ كل ما سبق بعين الاعتبار، لنُسَمِّ بعض المزايا والمساوئ للتصاميم المسطّحة: المزايا:بسيطة وبالحدّ الأدنىأقل استهلاكًا للموارد، وينتج عن ذلك وقت تحميل واستهلاك سرعة أقلّ.تبدو في العدة متطابقة على كلّ الأجهزة، وهي مناسبة للأجهزة النقّالةتتخلص من كلّ العناصر التي لا تخدم غرضًا معيّنًا، مما يعني أنّ كلّ ما يتبقّى على الشاشة ذو هدف.إيجابيّة. هذا مرافق – نوعًا ما – للمفهوم نفسه. ما أعنيه أنّه عندما وجدت التصاميم المسطّحة بالأساس بألوان وأشكال عَنَتْ أن يكون إبراز العنصر مرئيًّا مرتبطًا باستخدام المصمّم لألوان بارزة تجذب انتباه المستخدم بطريقة صحيحة. ومقارنة بغيرها، نادرًا ما نرى تصاميم مسطّح ذات لون رماديّ بَحْت.المساوئ:قد تكون بسيطة زيادة عن اللازم في بعض الأوقاتمحدودة. لا يمكنك أن تفعل الكثير في ظل التعقيدات المرئيّة وهويّة العلامة التجاريّة.ليست بديهيّة. المستخدمون غير المطّلعين يجدون صعوبة في التفاعل مع التصاميم المسطّحة، وهي ليست واضحة جدًّا حتى للمستخدمين الملمّين.يصعب إيصال فكرة تتعلق بأن الموقع فريد من نوعه. إلى حدّ ما تستخدم كلّ المواقع مظاهر تصاميم مسطّحة متشابهة.مزايا ومساوئ التصاميم المادّيةأما الآن فمع مزايا ومساوئ التصاميم المادّية. المزايا:تجعل كل شيء حقيقيًّا بإضفاء بعد ثالث (Z-Axis).هي معايير واضحة يتم تحديثها باستمرار. يمكنك استخدام تلك الموارد للحصول على إجابات حول أيّ شكّ أو شأن لديك اهتمام به عند عملك على مشروع جديد.بديهيّ أكثر. أسهل في الاستخدام من التصاميم المسطّحة لكلّ من المتخدمين الجدد/غير ذوي الخبرة والمستخدمين المتمرّسين.تدعم الحركة في تصاميم الوِب. كما قلنا في المرة الماضية، فإنّ الحركة تساعد المستخدمين على فهم ما يجري على الشاشة والتعرف على العناصر الأهمّ التي عليهم أن ينتبهوا إليها.العيوب:بَنتها وتتحكم بها – إلى حدّ ما – شركة واحدة وهي Google. (ليست مشكلة يوميّة).تستغرق وقتًا أطول لتطويرها، وهذا بسبب وجود المحور الثالث (Z-axis).تدعم الحركة في التصاميم، مما يعني أنّ عليك تضمين الحركات من أجل جعل عملك تصميمًا مادّيًّا حقيقيًّا.مسطّح أم ماديّ؟السؤال الذي يبقى حاضرًا هو إذا ما كان أحد التوجهين خيارًا أفضل من الآخَر… لذا، هل عليك استخدام أحد هذين النوعين من التصميم وتجاهل النوع الآخر؟ الإجابة البديهيّة هي لا. كلاهما لهما مكان اعتمادًا على الهدف مما تبنيه. لتبسيط الأمر بأكمله، يمكننا القول أن التصميم التقليديّ المقلّد للواقع الحقيقيّ هو تقليد لما كانت عليه الأمور، وهي انطباع واقعيّ لعناصر للعالم الحقيقيّ من أجل جعل واجهات التصميم تبدو مألوفة. أما التصاميم المسطّحة فهي بيئة مبسّطة تعتمد كثيرًا على معرفة المستخدم لواجهات التصميم عمومًا، وتتخلص من كل ما لا يخدم هدفًا وظيفيًّا. أما عن التصاميم الماديّة فتحاول أن تزوج بعض أفكار التصاميم التقليديّة للتصاميم المسطّحة، ويهدف ذلك إلى تقديم واجهة محسّنة للعالم الرقمي تُذكّرنا في نفس الوقت بالعالم الحقيقي بما يكفي لجعل الواجهة بديهيّة. ما رأيك؟ هل أنت محبّ لأحد هذين التوجّهين على حساب الآخَر؟ تفضّل وشاركنا رأيك في التعليقات. ترجمة -مع شيئ من التصرف- للمقال: ?Flat Design vs. Material Design: What Makes Them Different لصاحبه: Karol K.

إن أهم ما يلزم مصمم المواقع الذي يعمل على أي شيء (أي شيء!) هذه الأيام هو التأكد من أن تصميمه "له ذاك الملمس المُسطح". وبعبارة أخرى، فإن عبارة "تصميم مسطح" (أو مستوي، وبالإنجليزيّة flat design) قد أصبحت مرادفةً تقريباً لعبارة "تصميم جيد". ولكن، هل التصميم المسطح موضة مؤقتة؟ أم أنه وُجِدَ ليدوم، وأننا سنستمر في تصميم المواقع المسطحة لسنوات قادمة؟ هل من الممكن أن يكون هذا هو المعيار الجديد في تصميم المواقع؟ فلنكتشف ذلك. ولمساعدتي في ذلك، دعوت 10 مصممين وخبراء تصميم مواقع ليشاركوا بما لديهم في سؤال واحد رئيسي، وهو: هل التصميم المسطح شيء وُجِدَ ليدوم؟ أم أنه سيتلاشى ليفسح المجال لتوجه آخر جديد كليًّا؟ لكن قبل ذلك، لنُجِب عن السؤال الأبسط: ماهو التصميم المسطّح على أيّة حال؟لنضع تعريف ويكيبيديا المُربِك نوعاً ما جانبًا – ببساطة – إن التصميم المسطّح تصميمٌ مُجرّد من جميع مظاهر البُعد الثالث، ويُعنى التصميم المسطّح بأن تبدو العناصر كأنها منبسطة على سطح واحد، ومن هنا أنا أتى اسم التصميم المسطّح. يعني هذا عمليًّا أن كلّ الجماليات المرئيّة كالظلال والتدرجات والوَهَج، إلخ. ليست مناسبة للتصاميم المسطحة. هناك ثلاثة أمثلة على مشاريع تصاميم مواقع على Behance هزّت عالَم التصاميم المسطّحة، وهي: Watlinger: "تصميم موقع – وكالة Watlinger" تصميم أبرار أحمد. Maleo: سِمَة ووردبرس نظيفة للشركات" تصميم CreAtive Web Themes. sweet: "تصميم موقع بواجهة مسطّحة ملونة" تصميم Crystina Style. كيف نشأت التصاميم المسطّحة؟سيخبرك كل خبير بالأزياء أن التوجهات تأتي وتعود كل س من السنوات، وأن التصاميم المسطّحة لا تختلف عن ذلك، فهي توجه قديم يعيش شبابه من جديد. تعود أصول التصاميم المسطّحة إلى الأربعينات والخمسينات من القرن الماضي حسب أغلب المصادر. في ذاك الوقت كان قد نشأ شيء يُدعى النمط السويسري (Swiss Style). إنّه توجّه في تصميم المطبوعات يبدو حديثًا جدًّا إذا نظرت إليه بعيون عام 2015 بعض الأمثلة متاحة هُنا. كان التصميم يعتمد بكثرة على خطوط sans-serif، وتخطيط شبكيّ، وفصل جيد بين العناوين والمحتوى، وبساطة مطلقة. لِمَ التصميم المسطّح موجود الآن؟أحد الأسباب حقيقة أن التوجهات نحو موضة معينة تعود كلّ س من السنوات، لكن لِمَ آن أوان التصاميم المسطّحة؟ بالنظر إلى إجابات الخبراء التي سأذكرها، يمكنني أن أرى ثلاثة أسباب، وهي: يكتسب المستخدمون معرفة كبيرة بكيفية عمل الوِب.انتشار الأجهزة الذكية.التصورات الحديثة في تقنيات الوِب.لنأخذها كل واحدة على حدة، ونشرح ما يمكن أن يتبع التصاميم المسطّحة في المستقبل القريب. التصميم المسطّح والمستخدمونرافقتنا العديد من واجهات المواقع مدة طويلة. فمثلاً، القوائم، وترويسات المواقع، ومنطقة المحتوى، ونماذج الوِب، والأزرار، ومربعات الاختيار، وأزرار المشاركة/التحديث للشبكات الاجتماعية، وغيرها. يعرف الناس هذه الأشياء جيدًا، ويعرفون ما تفعل وكيف يتعاملون معها. لكن عندما ظهرت هذه العناصر لأول مرة، لم يعرف أحد ما هي أو كيف يستخدمها. بصرف النظر عن أن تصميم المواقع ككل كان في بداياته، كانت هناك حاجة لتوضيح كيفية التعامل مع كل هذه الأشياء الجديدة للمستخدم. فمثلاً، كان يجب أن تبدو القائمة كشيء يمكن النقر عليه بالفأرة، وأن يكون لمربع النصّ نصٌّ يقول "أدخل اسمك هنا"، وهكذا. وبدون ذلك، لم يكن بإمكان أحد أن يستنتج كيف يتفاعل مع المواقع. ولكن الأمر مختلف هذه الأيام. فكلما عرف المستخدمون أكثر، تكون الحاجة لأن نوضح لهم من خلال النصوص والتلميحات أقل. المستخدمون واعون كفاية ليدركوا الأمر بأنفسهم. وهنا يأتي دور التصاميم المسطّحة. يسمح التوجّه نحو البساطة في التصاميم المسطحة فقط بالحدّ الأدنى من العناصر. ورغم أنها تعتمد بكثرة على معرفة المستخدم ببعض الأمور، إلا أنه يمكنها التملّص من هذا الأمر لأن المستخدمين هذه الأيام يمكنهم التأقلم بسهولة. يبدو هذا جليًّا في بعض إجابات الخُبراء: التصميم المسطّح والهواتف النقّالةكان التوجه الذي سبق التصميم المسطّح وانتشر بكثرة – المدعوّ بالتصميم المحاكي للواقع التقليديّ - يعمل جيدًا قبل ظهور الأجهزة النقّالة، لكن – فجأة – صارت هذه الأجهزة قوية بما يكفي لتعرض هذه المواقع كما يفعل الحاسوب الشخصيّ، وشائعة بما يكفي لدرجة أن صار من الممكن أن يحمل أي شخص هاتفًا ذكيًّا في جيبه. والآن سيطرت الأجهزة المحمولة على عالم الوِب، حيث تفيد التقارير أنّ الهاتف النقّال هو الجهاز الرئيسيّ أو الوحيد المستخدم للاتصال بالإنترنت بالنسبة لـ 60% من مستخدمي الإنترنت. لقد عنى هذا الوضع لمصممي الوِب شيئًا واحدًا، وهو أنه صار عليهم التكيّف وإيجاد طريقة للتأكد من أن عملهم يمكن عرضه في أيّ مكان وعلى أيّ جهاز، لكن القول أسهل من العمل؛ فقد كانت هناك المئات من الأنواع المختلفة من الهواتف النقالة، بمواصفات مختلفة، وبشاشات عرض وأحجام مختلف، والتصاميم التقليديّة – بعناصرها واقعيّة المظهر – لا يمكنها التعامل مع هذا الأمر. هنا جاء دور التصاميم سريعة الاستجابة، والتي يمكن بها تسهيل كل شيء بقوّة، لكن يمكن في نفس الوقت جعل كل شيء جذّابًا. ولهذا صار التصميم المسطّحُ الحلًّ الذي احتاجه الجميع. التصميم المسطّح وتقنيات الوب الحديثةفي النهاية، لنلقِ نظرة على ما كان يحدُث في تقنيات الوِب ككُل، وما له من أثر على التصميم المسطّح. لقد كانت حلول HTML5 و CSS3 و Javascript الحديثةُ المسمارَ الأخيرَ في نعشِ التصاميم التقليديّة، والتي جعلت التصاميم المسطّحة قابلة للتحقيق. مع التطورات الحديثة صار بالإمكان عمل الكثير باستخدام النصّ البرمجيّ بدلًا من استخدام أدوات معالجة الصور أو بناء الحركات يدويًّا. ولهذا، فما كان في السابق حِكرًا على المحترفين الماهرين في استخدام أدوات مثل Photoshop، يمكن الآن تحقيقه بالاستخدام الجيد لتقنياتCSS و HTML. ما التالي فيما يتعلق بالتصاميم المسطّحة؟سواءٌ أحببناها أم لا، ففكرة التصاميم المسطّحة – وهي فكرة جعل الأشياء تبدو كما لو كانت منبسطة على سطح واحدٍ مستوٍ - هي الموضة الدارجة. وشأنها شأن أي توجّه شائع، ستتيح المجال لأشياء أخرى جديدة في يوم ما. ولكن الغالب أنّ القواعد الرئيسيّة التي تبني التصميم المسطّح سترافقنا لوقت طويل. إذًا ما الذي سيحدُث للتصاميم المسطّحة بالضبط؟حسنًا، ليست "بالضبط" بالطريقة الصحيحة للتفكير بالأمر، حيث لا يُمكِن التنبؤ بشيء بالضبط، لكن هناك مسلكين محتملين علينا أن ننظر إليهما: تطوّر التصاميم المسطّحة إلى شكل جديد، أو التغيّر التامّ والذهاب في اتجاه مختلف كليًّا. إن تطور التصاميم المسطّحة هو الاحتمال الأرجح، على الأقل خلال السنوات القليلة القادمة. الطريقة التي تسمح بها التصاميم المسطّحة للمستخدم أن يتفاعل مع الموقع ستستمر في التحسُّن، وجعل الأشياء أكثر بساطة وأكثر بداهةً في نفس الوقت. هذا سيجعل العديد من واجهات المواقع شبيهة ببعضها، لكن – بشكل عام – تصعُب رؤية هذا كأمر سلبي. عن كون التصاميم المسطّحة ستنكمش لتتيح المجال لشيء جديدكليًّا، حسنًا، تخمين ما يمكن أن يكون ذاك الشيء أمر صعب نوعًا ما. لكن السناريو الأرجح هو ما حدث بالفعل مرات عديدة في تاريخ تصميم الوِب، وهو أن معايير تصميم الوِب تذهب في اتجاه مختلف كليّة. وقد يعني هذا رمي التوجه نحو البساطة، والواجهات ذات البعدين، والتصميم المسطّح بأكمله جانبًا، وكل ذلك من أجل إتاحة المجال لتوجّه معاكس لهذا بالكامل. إذا كنت سأشارك رأيي الخاص حول هذا الأمر، فسأقول بأن التصاميم المسطّحة ستبقى على المدى القريب (مهما كانت هذه المدة، ربما سنتين إلى خمس سنوات). لكن بعد هذا، سنرى نقلة أخرى نحو شيء مختلف كليًّا، كما كان يحصل طوال هذه السنوات وحتى الآن. ما رأيك؟ هل التصاميم المسطّحة معيار تصميم مواقع وُجِدَ ليبقى؟ أخبرنا برأيك في التعليقات. ترجمة -وبتصرّف- للمقال: Is Flat Design a Web Design Standard That’s Here to Stay? 10 Designers Chip In.