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

الأعضاء
  • المساهمات

    17
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

14 جيدة

1 متابع

  1. بالطبع، فالحركة البسيطة غير المبالغ فيها تضفي جمالية وحياة لصفحة الويب، أما الحركات المبالغ فيها فتعكر صفو الهدوء الذي يعيشه القارئ وتشتته ع الغرض الأساسي الذي وجدت لأجله الصفحة. وشكرًا لمرورك
  2. الناس ليسوا مهتمين بشراء سرير؛ إنّ ما يريدونه هو أن يناموا في الليل قريري العَين ومُرتاحين. قد لا يمانع البعض في النوم على لوح من الخشب إذا كان هذا يعني أنهم سيفيقون نشيطين. هذا ما يجعلنا (كمسوقين) في مشكلة حقيقيّة نحتاج لحلّها. على الرياديين أن يذهبوا إلى أبعد من مجرد بناء منتج؛ عليهم أن يسوّقوا لما سيسمح مُنتجهم للزبائن بفعلَه. إذا لم يفعلوا هذا، فمن الواضح أنهم ليسوا من ذوي الخبرة. وهذا ما لخّصته المستثمرة 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.
  3. يكثر الحديث هذه الأيام عن أنماط تصميم البرمجيات، ومن الأسئلة الأكثر شيوعًا "كيف يمكنني استخدام النمط الفلاني مع التقنية (التكنولوجيا) الفلانيّة؟". أما في حالة 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.
  4. قبل أن نذهب إلى الموضوع الرئيسيّ للمقال، سأعطيك لمحة قصيرة عن مشاكل التصميم التي قد تواجهها. لقد اشتكى لي أحد زبائني بأن بعض الصفحات تفتح ببطء شديد. وعندما أقول ببطء شديد، فإنني أعني ذلك! فقررت أن أصحح تلك الصفحة (بعمل 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.
  5. عمل أطر مفرغة -أو تصاميم مبدئيّة- أثناء التصميم لا يكلف شيئًا تقريبًا، ولكن يمكنه أن يحقق عائدًا ممتازًا. ورغم أن العديد من المصممين يبدؤون برسم "سكِتش" في ذهنهم، ومن ثمّ يضعونه في برنامج فوتوشوب أو حتى يبدؤون بكتابة الأكواد مباشرة، بينما يبدأ آخرون على الورق. نعم، هو الورق العادي الذي تعرفه، والذي تكتب عليه بالقلم. يبدو هذا كتقنية عمرها عشر سنوات، ولكن حتى الآن ما زال أفضل المصممين في هذا العالم يستخدمونه لصالحهم. سيوفر عليك عمل تصميم مبدئيّ الكثيرَ من الإحباط في المراحل اللاحقة من تطوير المشروع، حيث يؤكّد بأنه ليس هناك أشياء عليك التراجع عنها أو إعادة تصميمها. إذا قمت بعمل تصميم أوليّ بطريقة سليمة، فبإمكانك أن تبيت مرتاح البال بأنك لن تضطر مستقبلًا لإعادة التصميم من البداية. إن ما تعنيه الأطر المفرغة هو وضع أفكار التصميم على الورق لكلّ من صفحات الموقع. في الغالب ستتشارك كل الصفحات ببعض العناصر، ولهذا فستكون الصفحة الأولى أكثر صعوبة في التصميم، بينما ستكون بقيتها أقل صعوبة، حيث تكون قد حصلت على فكرة مبدئيّة عن النمط العام للتصميم. أبق في بالك أن هذه العناصر مهمّة لأيّ تصميم. عندما تقلّب بين الصفحات، سيكون على المستخدم أن يقدر على التعرف على الصفحة وأن يعلم أنه لم يغادر الموقع ويذهب إلى موقع آخَر. أبق دائمًا على التنقلات والأقسام المهمة (المحتوى، الشريط الجانبي، ذيل الصفحة) في نفس المكان، ولكن هذا صار شائعًا كما لو أنه دليل للمبتدئين في التصميم، لذا لننتقل إلى أمور متقدمة أكثر. الأطر المفرغة – نظرة عامةلكي تكون قادرًا على استخدام إطار مفرغ، فأنت بحاجة إلى معرفة كيف يعمل. ما يفعله الإطار المفرغ بسيط، فهو يُظهِر الشكل العام للوقع والمكونات الرئيسيّة على الورق. يمكنك أن تستخدم أشكال مختلفة كصناديق وحاويات لرسم المحتوى فيها، وتنقلات، وعناصر وظيفيّة أخرى. قد تسأل نفسك، لم نستخدم الأشكال؟ الإجابة بسيطة: لأنها تسمح لنا بأن نركّز على التصميم أكثر وان ننسى الأكواد والتوافقية بين المتصفحات والصور وما إلى ذلك. إنه تصميم بسيط ونقيّ. الصورة من 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.
  6. تتطور أدوات التصميم المبدئي (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.
  7. استكشف الأفكار باستخدام ورقة وقلمإنّ استخدام الورقة والقلم طريقة جيدة لبدء عمل سير الاستخدام ورسم السكتشات (جمع سكِتش 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.
  8. إن آخر ما تريد سماعه من المستخدم لديك عند دخوله إلى موقعك لأول مرة هو "لحظة، ما الذي علي أن أفعله هنا بالضبط؟!" يمكن أن يكون تصميم عناصر الانتقالات أمرًا شائكًا، وخاصة إذا تركته للأخير بجعلها العنصر الأخير الذي ستقوم بتحسينه عند الاقتراب من الانتهاء من المشروع بأكمله. إنّ توجّهًا كهذا لا يمكن أن ينتهي نهاية حيدة، وهو بالتأكيد ليس الطريق السليم لتصميم عناصر التنقلات. إن التحدي هنا هو أنّ تصميم عناصر التنقلات لا يتعلق فقط بالقوائم التي ستستخدمها وأين ستضع تلك القوائم. يجب أن يبدأ هذا التوجه قبل ذلك بكثير. في الواقع، يفترض أن تعمل عليها منذ اليوم الأول في الوقت الذي تخطط فيه لتصميمك التالي. ولهذا، فما ستقرأه هنا هو دليل موجز: أساسيّات تصميم عناصر التنقلات. أول ما سنركز عليه هنا هو فصل الأشياء الضرورية للتنقل السليم عن غير الهامّة. ونبدأ بما يلي: إن الانطباع الأول هو ما يحدد النجاح أو الخسارةلدى كل منا موقع في العلامات (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.
  9. تُستخدَم قواعد البيانات العلاقيّة منذ وقت طويل. لقد اكتسبت قواعد البيانات من هذا النوع شُهرة بفضل أنظمة إدارتها التي تستخدم النموذج العلاقيّ بشكل جيّد للغاية، وهو النموذج الذي أثبت نفسه كطريقة رائعة للتعامل مع البيانات وخاصة في التطبيقات ذات المهام الحرجة. سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (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 هذه الأيام كحزمة تطبيقات من خلال مدير الحزم المبدئيّ للعديد من أنظمة التشغيل بسهولة. أنواع البيانات التي تدعمها PostgreSQLbigint: عدد صحيح من 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.
  10. لطالما اعتُبِر تصميم صفحة البداية فنا في ذاته، كما تعتبر الأنشطة الأخرى التي تؤدي إلى بناء تصميم موقع كامل. وبطريقة ما، يجب أن يكون بالإمكان جعل واجهة البداية عملًا قائمًا بذاته، عملًا يحقق أهدافه الخاصّة. رغم أن هذه الأهداف لها ارتباط مباشر للهدف العام للموقع ككل، إلّا أنه يفترض بها أن تكون مركّزة أكثر. أعلم أن هذا قد يبدو مُبهمًا نوعًا ما، ولذا -لأوضح الأمور- لنلقِ نظرة على ثماني خرافات تتعلق بتصميم صفحة البداية يفترض على الجميع أن يعرفها. الخرافة الأولى: يجب أن تبدو صفحة البداية جميلةبالتأكيد لا أحد يستمتع بالنظر إلى صفحة بداية قبيحة، ولكن مع هذا، فجمال صفحة البداية ليس نهاية الحكاية. وبعبارة أخرى، تركيزك على عمل صفحة تسرّ الناظرين لهو أمر غير كافٍ للوصول بك إلى إسعاد زبونك (على المدى البعيد على الأقل). هناك أمر واحد يهمّ أكثر بكثير من المنظر الجذاب لصفحة البداية، وهو قدرة هذه الصفحة على تحقيق هدفها الرئيسيّ. يجب أن يكون لكل صفحة هدفها الخاص بها، وهو الهدف الرئيسيّ الذي من أجله وُجِدَت هذه الصفحة، لذا من أهم مهامك الرئيسيّة عند العمل على تصميم أن تحدد هذا الغرض. يمكنك أن تجرب الإجابة على السؤال التالي لجعل عملك أسهل: ما الأمر الرئيسيّ الذي ترغب أن يقوم به زوارك عند رؤيتهم لصفحة البداية لديك؟ فمثلًا، هل الهدف هو التسجيل قائمة بريدية أو نظام اشتراكات معين؟ أو قد يكون الهدف هو الذهاب إلى المدونة والتفاعل مع المقالات هناك؟ قد يكون الهدف هو الاطلاع على المنتجات أو الخدمات التي يوفرها الموقع؟ مهما كان هذا الهدف، ضعه نصب عينيك عند العمل على تصميم صفحة البداية. إذا كانت النتيجة جميلة (تسرّ الناظرين)، فهذه ميزة تكميليّة. إن أحد أفضل الأمثلة على تصميم الواجهة الرئيسيّة بالتركيز على الأهداف على الإنترنت هو موقع 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.
  11. لقد صار التصميم الماديّ (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.
  12. منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (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.
  13. إنشاء منتج ذي قيمة يتطلب الحصول على تغذية راجعة ذات قيمة. يحدّد من تتحدّث معه منذ البداية الكثير من الأمور. حيث بدأت أنا وشريكي المُؤسّس قبل بضعة أسابيع في اختبار المنتج الثاني لشركتنا في المرحلة التجريبية بيتا (beta) داخليًّا. إنّ منتجنا الأول Exist في طور بيتا العلنيّ (أي في الطور التجريبيّ الذي يمكن لمن هم خارج فريق العمل الوصول إليه) منذ عام تقريبًا. لقد وقعنا في الكثير من الأخطاء التي تعلمنا منها الكثير. نحن نعلم ما علينا فعله بطريقة مختلفة هذه المرّة، وهو ما سيسمح لنا بارتكاب أخطاء أخرى. فيما يلي بعض الدروس التي أرغب بمشاركتها. انتقِ مستخدميك بعنايةكان خطأنا الأكبر في اختبار النسخة التجريبية بيتا اختيارُ المستخدمين الخطأ. حاولنا حماية ثقتنا الهشّة بأنفسنا ودعَونا فقط الناس الذين كنا نعرفهم. كنّا نأمل بالحصول على تغذية راجعة صريحة (ولكن مؤدبة) لمساعدتنا في تحسين المنتَج دون أنّ نجد أنفسنا غارقين في بحر من الإحباط قبل أن نُطلق مُنتَجنا حتّى. لقد صدمتنا الحقيقة أكثر: لم نتلقَّ أيّة تغذية راجعة مُطلقًا. لم نحصل على التغذية الراجعة التي كنّا بحاجة إليها لأننا لم نكن نتحدّث إلى مستخدمين مهتمين. لقد كان "المستخدمون" لدينا مجرد أشخاص لديهم خمس دقائق ليساعدونا فيها وليس لديهم أيّ اهتمام حقيقيّ بإخبارنا بما أرادوا عمله بمنتجنا. لماذا؟ لأنّهم لم يكونوا بحاجة إلى منتجنا. لم نكن نحلّ أيّة مشاكل تواجههم. لم يعرفوا قيمة المنتَج ولم يتواجدوا لمدّة طويلة. أغلبهم اختفوا بعد أوّل ولوج لهم، والبعض رجعوا مرّة في الشهر في أفضل الحالات. لا تضيّع الوقت مع مستخدمين لا تخدمهم. لن تحصل على التغذية الراجعة التي تحتاجها من أناسٍ ليسوا بحاجة إليك. القيام بالأمر بالطريقة الصحيحة: اختر مستخدمين من السوق الذي تستهدفه.من أجل منتَج جديد، عليك البحث عن مستخدمين يعانون من المشكلة التي تُحاول حلّها، ولديهم حاجة، وراغبون في أن يستثمروا للحصول على قيمة. وبينما تبني أعمالك مع الوقت، يصير هذا أسهل بكثير. نركّز في منتجنا الثاني على نفس الزبائن الذين بنينا لهم مُنتجنا الأوّل، ولهذا فلدينا بالفعل مجموعة مستهدفة يمكننا الحصول على مختبرين لنسخة بيتا منها. عندما تبني علاقة مع أناس يستخدمون منتَجك، فهم أقرب لأن يكونوا مهتمين بمشاريع أخرى تعمل عليها. يمكنك أن ترى هذا في مشاريع أخرى أيضًا. عندما كانت Basecamp ما زالت تُعرف باسم 37aSignals، كانت لديها منتجات تستهدف نفس قاعدة المستخدمين. من الأسهل بكثير إيجاد مختبري بيتا –وفيما بعد مستخدمين يدفعون لقاء الخدمة– من كمّ المستخدمين الذين يعرفونك ويثقون بك بالفعل. إذا كنت في بداية مشروعك الأول، فلن تكون لديك ميزة قاعدة المستخدمين الموجودة بالفعل، ولكن يمكنك بناء جمهور بطرق أخرى. قبل أن نُطلق Exist للعموم بستة أشهر، بدأت في مدونتنا سلسلة مقالات دوريّة تُركِّز على الأخبار والمنتجات الجديدة في المجال الذي يختصّ فيه المُنتج. وبينما كنت أكمل هذه السلسلة كلّ أسبوع، أنشأنا أرشيفًا للمحتوى المتعلق بالسوق الذي نستهدفه وطورنا جمهورًا من الناس المهتمين بهذه المواضيع. لقد أنشأنا قائمة بريديّة لمن ينتظرون Exist لإبقاء الزبائن المحتملين على اطلاع على تقدمنا، ولقد استطعنا باستخدام رسائل البريد الإلكتروني المتعلقة المتعلقة بالتحديثات وبإنشاء محتوى يهتمون به أن نُنشئ علاقات مع الكثير من الزبائن حتى قبل أن يستخدموا منتجنا. وفي في المراحل اللاحقة من اختبار بيتا، استطلعنا قائمة المنتظرين لدينا لنجد الناس المهتمين بمنتجنا والذين يقدّرون قيمته. وبتأمل الأمر، كان يجب أن نأخذ هذه الخطوة قبل هذا بكثير. طلب التغذية الراجعة كلما حصلت على تغذية راجعة مبكرًا كلما كان هذا أفضل. تحصل الأفكار الجيدة على فرصتها، وتُصمَت الأفكار الضعيفة. عدم فهم المستخدمين جيدًا أمر خطير. من دون الفهم الجيد لن تعلم الاتجاه الأفضل لمنتجك ولا تعلم لمَ يُغادر الزبائن (أو لماذا يبقون). التغذية الراجعة هي الحلّ. من السهل أن تشعر أنك تزعج الناس، وخاصة في المراحل المُبكّرة من المُنتج. ولكن كأيّ شيء آخر في هذه الحياة، لن تعلم حتّى تسأل، والناس عادة يكونون مستعدين للمساعدة أكثر مما تتصور. أن تتوقّع من الزبائن أن يعطوك تغذية راجعة دون طلب منك توقُّعٌ مبالغٌ فيه. أنت مسؤول عن بدء الحوار. القيام بهذا الأمر بالطريقة الصحيحة: اسأل كثيرًا، وبطرق مختلفةالتحدّث مع زبائنك في الوقت الحقيقيّ (إمّا وجهًا لوجه أو عبر سكايب) من أفضل الطرق التي وجدتها تكشف عن تغذية راجعة مفيدة. عندما تتحدث إلى مستخدم وجهًا لوجه بهذه الطريقة، فيمكنك أن تتعمّق أكثر في الصغائر التي يقولها وأن تدعه ينطلق بالحديث عن هذه الخفايا. هذه هي الطريقة الأمثل في الحصول على صورة متكاملة عن كينونة هذا المستخدم، وكيف يناسب مُنتَجُك حياتَه. لكن أحيانًا لا تكون هذهِ التغذيةَ الراجعةَ التي تحتاجها. عندما رغبنا أن نعلم ما هي الأجزاء الأكثر شعبية في منتجنا، أرسلنا استبيانًا لكل المستخدمين عبر البريد الإلكترونيّ. لم يكن هذا مباشرًا بقدر المكالمات الحيّة، ولكننا استطعنا جمع معلومات من مستخدمين كُثُر في وقت قصير، وتمكنّا من السؤال عن الأمور التي نرغب بمعرفتها بالضبط. أحيانًا ترغب فقط بتقييم عام وواضح عن منتجك أو خدمتك. يمكنك في هذه الحالات أن تستخدم سؤالًا بسيطًا مثل: "هل تنصح صديقًا باستخدام منتجنا؟"، أو بسؤال مستخدميك كيف يقيمون خدمة الزبائن بعد أن تحل مشكلتهم. يجب أن تعتمد طريقة طلبك للتغذية الراجعة على طبيعة التغذية الراجعة التي تريدها. التزم بتوجّه واحد رئيسيّ للتغذية الراجعة في الأيام الأولى لمشروعك. تقليل الاستجابات وانزعاج المستخدمين يمكن أن يحدثا إذا شعروا أنك تُرسل إليهم طلبات كثيرة. لا ترسل استمارات تُزعِج فيها المستخدمين في نفس الشهر الذي تقوم فيه بجهد لعمل مقابلات تطوير. التغذية الراجعة المركزة المستمرة هي ما يُنشئ انطباعًا ذا معنى. الاستماع إلى الأقليات الصاخبة؟عندما تبذل جهدًا كبيرًا للحصول على تغذية راجعة، فإن أيّ قدر قليل منها يبدو كذهب خالص. قد يوقعك هذا بسهولة كبيرة في فخ الأقليّة الصاخبة (vocal minority، وهي الأقليّة التي تعبّر عن آرائها باستمرار). تجد بأن عددًا من المستخدمين يطلبون ميزة معينة فكرت ببنائها، وفجأة تبدأ بالظنّ بأنّ كلّ المستخدمين يريدونها بالتأكيد وتحدّثك نفسك بأنه من الواضح أنهم لم يتمكنوا من إخبارنا بذلك وحسب، ولهذا تُقرّر بناءها وإضافتها. والأسوأ من هذا أن هناك ميزة معينة لم تفكر ببنائها، فيأتيك ستة أوسبعة مستخدمين ويسألون عنها في نفس اليوم. وتكتشف لاحقًا أنك بدأت تبني ميزة جديدة دون اطلاع كافٍ على الوضع العام. من السهل أن تنقضّ على شيء وتبدأ بالعمل عليه شاعرًا أنه عاجل أو مطلوب، مع أنه ليس كذلك. يبدو هذا سخيفًا، لكننا جميعًا معرضون لذلك. لعمل شيء يريده الناس، أثبت أولًا أنهم يريدونه بحقّ. تأكّد من صحّة الفرضيات التي تعتمد عليها قبل أن تشرع في البناء. التغذية الراجعة هي أفضل وسيلة لبناء فرضيات حول ما قد ترغب به غالبية المستخدمين. يمكنك بعدها أن تقوم بالمزيد من التطويرات المتعلقة بالزبائن لترى إن كانت تلك الفرضية ستصمد. إذا صمدت الفرضيًة، وكانت غالبية المستخدمين لديهم نفس الشعور، فيمكنك عندئذ أن تبدأ بالبحث في أعماق الأمر، لتجد السبب الذي يدفعهم للرغبة بهذه الميزة تحديدًا، وكيف يمكنك حلّ تلك المشكلة بالنسبة لهم (الأمر يتعلق بالاحتكاك وليس بالميزة). لدى بناء مُنتجنا الجديد، نستخدم كلا من Help Scout والوسوم (tags) للتغذية الراجعة لنبقى على اطّلاع دائم بعدد الطّلبات التي تصلنا حول كل خاصّيّة. من السهل والسريع إضافة وَسم (tag) عندما ترد على زبون، ورؤية عدد الطلبات على كل وسم تسهل اختيار ما سيتم عمله لاحقًت دون أن تغرق في طلبات الأقليّة الصاخبة تلك. إنّ التغذية الراجعة جزء متعدد الأوجه من أجزاء بناء شركة. سواءٌ كنت تحصل على تغذية راجعة أكثر من اللازم، أو كانت لديك تغذية راجعة مربكة أو متضاربة، أو لم تكن تحصل على تغذية راجعة على الإطلاق، فلستَ وحدك. اختر زبائنك بحرص، واطلب تغذية راجعة باستمرار، ودائمًا تأكد من الفرضيًة قبل تطبيق ما تتلقاه من الزبائن. القول أسهل من الفعل، ولكن التحسينات التي أقوم بها في التعامل مع التغذية الراجعة للزبائن جعلتي أفضل في بناء أفضل منتج للمستخدمين. ترجمة -وبتصرف- للمقال: Talking to Your Very First Customers.
  14. ليست جودة عملك هي ما يحدّد مدى نجاح مشروعك؛ بل ما يحدّد مدى نجاحهِ جودةُ تواصلك مع العميل. بجدّ! فكر بالأمر كما يلي: لقد حققت أفضل إنجاز عملت عليه طوال حياتك بتصميم شعار (logo)، أو ببرمجة تطبيق، أو بكتابة مقال أو إعلان. هذا العمل يجمع كلّ مهاراتك وخبراتك ومعرفتك وعلمك وشغفك. ولكن فيما بعد، تعرض عملك على زبون ولا يعجبه مطلقًا. ليس هذا وحسب، بل يقولون لك أنّ هذا ليس ما أراده أصلًا، وأنّ عليك إعادة بدئه من الصفر، وأنّه يرغب بالاتصال بك هاتفيًّا في الساعة السابعة من صباح اليوم لمناقشته (لم يتبق حتّى ذلك الوقت أكثر من بضع ساعات). لن أقول بأنّي حذرتك، وذلك لأننا جميعًا عرضة لنتائج كهذه عندما لا نتواصل بشكل فعّال. بغض النظر عن مدى جودة عملك، فعليك فهم احتياجات العميل، والتعبير عن سبب كون العمل الذي تعرضه عليهم هو المطلوب لتلبية احتياجاتهم. عدا ذلك، فلا قيمة لعملك بأكمله. إذا كان التواصل الجيد أساس المشروع الناجح، فماذا بإمكانك أن تفعل لضمان حدوث ذلك؟ تحديد ما يُفترض تسليمه بدقّةإذا لم يكن كلا الطرفين واضحين فيما يتعلق بما يفترض تسليمه، والعملية المطلوبة، والجدول الزمني، ومن المسؤول عن كل جزء – كتابيًّا، وقبل الحديث عن المال – فأنت تقفز في مياه لا تعلم مدى عمقها. عليك أيضًا أن تعلم مدى معرفة العميل بما سيكون مسؤولًا عنه. على سبيل المثال: إذا كنت تبني موقعًا له، فهل يعلم كيف يستخدم نظام إدارة محتوى (CMS)؟ إذا لم يكن العميل يعرف ما تفعله، فعليك أن تفهّمه ذلك بطريقة بسيطة (عدا ذلك، لن يقدّر قيمة ما تقدّمه له). وضّح خبراتكلا يكفي أن تخبر العميل بأنك تستطيع إنجاز العمل. عليك أن توضّح لمَ أنت الشخص المناسب للقيام بهذا العمل، وكيف ستحل المشكلات التي يواجهها، وكيف ستوصله إلى أهدافه. قم بهذا في وقت مبكّر قدر الإمكان، بحيث يبدأ بأخذك بعين الاعتبار كخبير وليس فقط كعامِل مُستأجَر. حدّد أهدافك ونجاحاتك بدقّةما أهداف المشروع؟ وكيف سيتم قياس مدى النجاح؟ بغض النظر عن ما تفعله، سيغذّي هذا التواصلُ أيّةَ مناقشات أثناء العمل على المشروع. يريد العملاء نتائج قبل أيّ شيء آخَر؛ حدّد بدقة ما يعني هذا. التواصل الأسبوعيّبالنسبة للمشاريع طويلة الأمد، تواصل مع عميلك مرة واحدة أسبوعيًّا على الأقلّ. بيّن ما وصلت إليه، وما أتممته، وما المميز، وما المطلوب أن يفعله العميل الآن أو الأسبوع القادِم. هذا سيبقي الأمور في مسارها، وإذا خرج شيء ما عن مساره، فمن الأفضل تصحيح المسار في أسرع وقت. التزم بالمطلوبإذا كانت مهمة ما غير مدرجة في "المتطلبات" (deliverables)، فلا يُفترض بك أن تُنفّذه مجانًا. كن لطيفًا ولكن حازمًا عندما يطلب عميل شيئًا ما خارج نطاق المطلوب. أحيانًا يكون خطأً من العميل بحيث لا يكون عارفًا بخفايا الموضوع، وأحيانًا يكون محاولةً للحصول على أكثر مما يدفع مقابله. تأكّد من وجود خطّة لما بعد المشروع أيضًا؛ إذا كان العميل راغبًا في أن تقوم بالمزيد من العمل بعد انتهاء المشروع، فكيف سيتم الأمر؟ حدّد خط انتهاء لكل مشروع، ليس فقط من حيث وجود تاريخ ونهاية محدّدة للمشروع، بل وحتى وجود فرصة للعمل مستقبلًا (بالمشروع، أو بالتعاقد، إلخ). ضع حدودًاإذا كان المشروع يتطلب الكثير من التواصل الحيّ، فأعلِم العميل متى تكون بالعادة متاحًا، ومتى لا تكون مشغولًا بالعمل. فمثلًا، يمكنك تحديد ساعات عملك من الساعة العاشرة صباحًا وحتى الخامسة مساءً بتوقيت جرينيتش، من يوم الإثنين وحتى الخميس. إذا راسلك أو تواصل معك خارج هذا الوقت، فستكون قد أخبرته مسبقًا بأنك غير متاح. اعلم أنك إذا استجبت للبريد أو المكالمات خارج هذه الأوقات، فأنت تظهر له أنك لا تحترم الحدود التي وضعتها، وبهذا لا يلتزم هو أيضًا. أعد صياغة طلباته وأفكاره بلغتك الخاصّةعندما يسأل العميل عن شيء ضمن حدود العمل، فأكّد بالضبط ما يريد عمله بلغتك الخاصّة. هذا يعطيه فرصة أخرى ليتأكد مما إذا كان هذا ما يريده حقًّا. هذا يجنبك سوء الفهم، ويجنبك كذلك الطلبات الهشّة (حيث يمكن أن يغيّر رأيه). تحدّث عن خبراتكليس عليك أن تكون هجوميًّا، ولكن إذا طلب العميل شيئًا تعلم أنّه غير صحيح أو أنه لن يساعده على تحقيق أهدافه، فأعلمه بذلك. يدفع العميل لك لأنك الخبير، ولأن رأي الخبير له وزنه. استمع بشكل جيّدمن المذهل مقدار ما يمكنك تعلمه عن طريقة تقديم عمل رائع لعميلك عندما تستمع إلى ما يريد قوله. وأكثر من هذا، استمع لما وراء ما يقوله [أو كما نقول، اقرأ بين السطور]، لأنّه يمكن أن يفتقر العميل للبلاغة الكافية للتعبير عنه. فمثلًا، إذا كان عميل ما يريد 100 صفحة من المسجلين لمجلته، فما يريده بالفعل هو المزيد من المسجّلين، وهو ما سيزيد من مبيعات منتجه. اسأل "لماذا؟" للوصول إلى احتياجاته الحقيقيّة. وحتى مع وجود تواصل مثاليّ، فلا يمكنك أن تضمن استجابة مثاليّة من كلّ العملاء. يمكن أن لا يقوموا بالأمر ضمن حدود الجدول الزمنيّ، أو حتى أسوأ من هذا، كأن يتوقفوا عن التواصل نهائيًّا. في هذه الحالات، عليك أن تتذكّر أنه حتى إن لم يكن العميل يتصرف بمهنيّة ويلتزم بما عليه فعله في المشروع، يتحتم عليك أن تكون متحضّرًا وخدومًا. شخصيًّا وجدت أنه في غالب الأوقات إذا توقف العميل عن الاستجابة، أو إذا لم يلتزم بالمواعيد، فهذا بسبب أمرين: 1) هناك شيء شخصيّ يحدث في حياته (ولا يمكنك عمل شيء حيال الأمر)، أو 2) أو أنّه مرتبك أو مُرهَق أو مشغول جدًّا، أو لا يعرف كيف يفعل المطلوب منه. في هذه الحالة، كل ما يمكنك فعله هو أن تعرض عليه المساعدة – ليس بالقيام بشيء خارج نطاق العمل، بل بتوضيح شيء ما مجدّدًا أو بأن تعرض عليه أن يسلّم العمل الذي يقوم به إلى شخص آخر. فمثلًا، معظم عملاء مشاريع تصميم المواقع يتكاسلون عن إضافة وتعديل محتوى مواقعهم. إذا حدث هذا معي، فأول ما أفعله هو أن أقترح عليهم كاتب محتوى أو محرّرًا أو مساعدًا عن بُعد ذي خبرة ليساعدهم في وضع المحتوى في الموقع. إنّ أولئك الذي لا يُرهَقون أثناء كلّ مشروع وذلك لأنّ عملاءهم يطلبون أشياء "خاطئة" أو "غبيّة" يعلمون أن التواصل الجيد من البداية وحتى النهاية هو ما يجعل المشروع ناجحاً وممتعاً بالفعل معًا. العمل الذي تقوم به لعميلك مهمّ، ولكن الطريقة التي تتواصل بها معه عن العمل لها نفس الأهميّة. ترجمة – وبتصرف – للمقال How Communication Determines A Project’s Success.
  15. إذا كنت قد عشت على وجه الأرض لمدة، فمن المؤكد أنك تذكر هذه الصور المتحركة المبتذلة التي تقول "الموقع قيد الإنشاء" والتي استُخدِمَت في أواخر التسعينات. لقد أحببناها، أليس كذلك؟ على أيّة حال، لقد حصل الكثير لتصميم المواقع منذ ذلك الحين. وهكذا بالنسبة للرسوم المتحركة على الوِب، حيث لم تعد هذه الحركات مبتذلة هذه الأيام، بل أنها – على ما يبدو – وجدت مكانها بين أدوات وآليات التصميم الأخرى. فلنلقِ نظرة إذًا على كيفيّة استخدام الرسوم المتحركة بفعالية، والمكان الذي تشغله في عالم تصميم المواقع الحديث. دور الحركات في الوِب الحديثقد يبدو هذا مفاجئًا في البداية، لكن عندما يتعلق الأمر بالفوائد الأساسيّة التي يمكن للحركات الجيدة أن تُضفيها، فلا شيء تغير خلال العقد الماضي، وذلك بالأساس لأن العقل البشري ما زال يعمل بنفس الطريقة تقريبًا، بغضّ النظر عن توجهات التصميم الأكثر شيوعًا هذه الأيام. فعلى سبيل المثال، أُثبِتَ أن هذه الحركات تُساعدنا على فهم ما يحصل على الشاشة، وما العنصر الأكثر أهميّة الذي علينا أن ننتبه إليه. لماذا؟ لأن هذه هي الطريقة التي يعمل بها دماغُنا. آلاف السنوات من التطور جعلتنا ما نحن عليه، وجعلتنا نعير انتباهنا للحركة. عدا ذلك، لم نكن لننجو من هجمات المفترسين في اماضي عندما كنّا نعيش في الكهوف. ولهذا، فمن المثير للاهتمام – حتى في عصر التصاميم المسطّحة والبسيطة – أنّ الحركة ما زالت تحتفظ بمكانها، وما زال بالإمكان (والمفروض أن يتم) بكل تأكيد استخدامها لإثراء تجربة المستخدم وجعل تصاميمنا مفهومة أكثر. إن الشيء الوحيد الذي تغير هو الشكل الذي يمكننا أن نستخدمه به بفعالية. لا تبدو الحركات الجيدة في 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.