تطوير موقع الشركة وصفحة هبوط المنتج

يشرح موقع الشركة من أنتم وماذا تفعلون، أما صفحة هبوط المنتج فتقود الزائر إلى إجراء واحد: تنزيل التطبيق أو فتح نسخة الويب أو إرسال طلب. وتعتمد النتيجة الجيدة على عدة قرارات هندسية: عنوان مستقل لكل لغة، وتخطيط من اليمين إلى اليسار للعربية، وتحميل سريع، وترميز صحيح لمحركات البحث، وتحليلات مضبوطة وفق قوانين بلد الجمهور، وتصميم مريح على الهاتف والحاسوب معًا.

موقع الشركة وصفحة هبوط المنتج: ما الفرق؟

يجيب موقع الشركة عن أسئلة مثل: من أنتم، وماذا تقدمون، وكيف نتواصل معكم؟ وفيه صفحات الخدمات وبيانات الشركة والوثائق القانونية والأسئلة الشائعة والمقالات. ويستخدمه الناس بطرق مختلفة: بعضهم يبحث عن وسيلة تواصل، وبعضهم يتحقق من الشركة قبل التعاقد، وبعضهم يصل من محرك البحث إلى مقال بعينه.

أما صفحة هبوط المنتج فتعمل بمنطق آخر، إذ لها مهمة واحدة: أن توصل الزائر إلى إجراء محدد. وفي حالة التطبيق يكون هذا الإجراء عادةً تنزيل ملف التثبيت، أو الدخول إلى نسخة الويب، أو إرسال طلب إذا كان المنتج يُباع عبر محادثة. وكل ما لا يخدم هذا الإجراء زائد على صفحة الهبوط.

تحتاج معظم الشركات إلى الاثنين: موقع الشركة يبني الثقة ويجلب زوار البحث، وصفحات المنتجات تحوّل الاهتمام إلى تثبيت أو طلب. وإذا كان المنتج لا يزال فكرة، فابدأ بسيناريو واحد كما نشرح في دليل نموذج أولي قابل للتطبيق MVP: من أين تبدأ.

مكونات صفحة المنتج

لصفحة هبوط التطبيق ترتيب شبه ثابت يساعد الزائر على أن يقرر بسرعة هل يناسبه المنتج أم لا. يمكن تعديله بحسب المهمة، لكن الصفحة تفقد معناها غالبًا من دون هذه المكونات.

1. الشاشة الأولى: ما المنتج، ولمن هو، وزر الإجراء الرئيسي.
2. شرح موجز للفائدة: أي مشكلة يحلها المنتج، وبماذا يختلف عن الطريقة المعتادة.
3. الواجهة: لقطات شاشة أو أمثلة حية على الهاتف والحاسوب.
4. الميزات: عدد قليل من القدرات المحددة بلا عبارات عامة.
5. المنصات: macOS وWindows ونسخة الويب وتطبيقات الهاتف، مع أزرار التنزيل والدخول.
6. الأمان والخصوصية: كيف تُعامل بيانات المستخدم.
7. الأسئلة الشائعة: إجابات قصيرة عما يمنع الزائر من اتخاذ القرار.
8. تكرار الإجراء الرئيسي أسفل الصفحة مع وسيلة لإرسال الطلب.

من الأفضل تجهيز نصوص هذه المكونات قبل بدء التصميم، ومن المريح كتابتها مع متطلبات الصفحة، كما نوضح في دليل كيف تُعد وثيقة متطلبات البرمجيات.

المواقع متعددة اللغات: عنوان مستقل لكل لغة

إذا كان الموقع موجهًا إلى عدة أسواق، فيجب أن تكون اللغات جزءًا من البنية منذ اليوم الأول. فالترجمة التي تُضاف قبيل دخول السوق تكسر التصميم في أغلب الأحيان، وتربك محركات البحث، وتضيف عملًا يدويًا مع كل تحديث.

وهذه قواعد توفر الوقت طوال عمر الموقع:

• تُحفظ النصوص منفصلة عن الشيفرة، مجموعة لكل لغة. يغيّر المطور التصميم ويغيّر المحرر النصوص من دون أن يعيق أحدهما الآخر.
• لكل نسخة لغوية عنوانها الخاص، بدلًا من تبديل النص داخل صفحة واحدة. وبذلك يرى محرك البحث النسخة الصحيحة ويعرضها لزائر البلد المناسب.
• تُبنى النسخ اللغوية من مصدر واحد بواسطة مولّد، فيصل أي تعديل في الجزء المشترك إلى كل اللغات دفعة واحدة ولا تتباعد النسخ.
• يُحفظ اختيار الزائر: إذا غيّر اللغة، فُتحت الصفحات التالية باللغة نفسها.
• توجد لغة احتياطية واضحة عند غياب الترجمة، بدلًا من فراغات في الصفحة.

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

اللغة العربية والتخطيط من اليمين إلى اليسار (RTL)

تُقرأ العربية من اليمين إلى اليسار، لذلك تُعكس الواجهة: القائمة وترتيب الأعمدة وسهما الرجوع والتقدم ومحاذاة النص. ومن الناحية التقنية يُضبط اتجاه الكتابة في الصفحة من اليمين إلى اليسار، وتُكتب الأنماط بخصائص منطقية مثل بداية السطر ونهايته بدلًا من اليسار واليمين، فيعمل التصميم نفسه بشكل صحيح في الاتجاهين.

ما يحتاج عادةً إلى عناية خاصة:

• الأيقونات التي تحمل معنى الاتجاه، كالأسهم وزر التالي ومؤشرات التقدم، تُعكس، أما الشعارات والصور فتبقى كما هي.
• النص المختلط: الأسماء اللاتينية وعناوين البريد والأرقام داخل الجملة العربية يجب أن تظهر بالترتيب الصحيح.
• الخطوط: للخط العربي ارتفاع أسطر وأوزان خاصة به، ولا يصلح له خط لاتيني.
• الحركات وشرائح العرض: يتغير اتجاه التمرير وظهور العناصر أيضًا.

يجب فحص النسخة العربية بالعين على شاشات حقيقية، لا بالاكتفاء بغياب الأخطاء في الشيفرة، فالسهم المقلوب أو رقم الهاتف المضطرب يظهر من النظرة الأولى.

سرعة التحميل

يقرر الزائر البقاء أو المغادرة في الثواني الأولى، كما تأخذ محركات البحث السرعة في الحسبان. ومعظم التأخير في المواقع التسويقية لا يأتي من الخادم، بل من الصور الثقيلة والخطوط والنصوص البرمجية الخارجية.

• الصور بصيغ حديثة وبعدة أحجام، فالهاتف لا يحتاج إلى صورة معدّة لشاشة عريضة.
• كل ما يقع أسفل الشاشة الأولى يُحمَّل أثناء التمرير.
• لا تُحمَّل إلا أوزان الخطوط المستخدمة فعلًا، ويظهر النص فورًا دون انتظار الخطوط.
• النصوص البرمجية لا تعطّل العرض: تظهر الشاشة الأولى قبل اكتمال تحميل الأجزاء التفاعلية.
• تُقلَّص الموارد الخارجية إلى الحد الأدنى، لأن كل واحد منها يضيف تأخيرًا ومخاطرة.
• تُخزَّن الملفات الثابتة مؤقتًا، ويتغير وسم الإصدار عند تحديثها ليحصل الزائر على النسخة الجديدة.

قِس السرعة على هاتف باتصال جوال متوسط، لا على حاسوب المطور وحده.

ترميز محركات البحث: hreflang وSchema.org وخريطة الموقع

لكي يعرض محرك البحث الموقع متعدد اللغات بشكل صحيح، يجب أن نخبره صراحةً بماهية كل صفحة. هذا جزء من العمل لا يراه الزائر، لكنه يحدد هل سيُعثر على الموقع أصلًا.

ومن المهم أيضًا التخطيط لعناوين نظيفة بلا امتدادات زائدة، ولإعادة توجيه الروابط القديمة إذا انتقل الموقع. ويفيد ترميز Schema.org بشكل خاص في قسم الأسئلة والأجوبة، إذ قد يعرض محرك البحث الإجابة مباشرة في النتائج.

التحليلات وقوانين بلد الجمهور

تُضبط التحليلات وفق قوانين البلدان التي يعيش فيها جمهور الموقع. ففي بعض الولايات القضائية، مثل الاتحاد الأوروبي، تلزم موافقة صريحة من الزائر قبل تشغيل أدوات القياس ووسوم الإعلانات. وفي غيرها يكفي إشعار بملفات تعريف الارتباط وسياسة خصوصية واضحة. ونتخذ هذا القرار معكم في بداية المشروع.

• تحدد قائمة بلدان الجمهور ما إذا كان المطلوب شريط موافقة أم إشعارًا فقط.
• حيث يشترط القانون الموافقة، لا تُحمَّل أدوات القياس ووسوم الإعلانات قبل موافقة الزائر.
• لا تُحمَّل نصوص التحليلات إلا من مصادر مسموح بها.
• تشرح سياسة الخصوصية ما الذي يُجمع ولماذا، بكل لغات الموقع.

هكذا تبقى التحليلات قانونية في كل سوق، وترون أي الصفحات والأزرار تقود إلى التنزيلات والطلبات.

ربط الصفحة بالتطبيق: التنزيل والدخول والطلب

صفحة هبوط التطبيق هي مدخل المنتج، لذا يجب أن تعمل أزرارها بلا أخطاء. وهناك ثلاثة سيناريوهات رئيسية.

أزرار التنزيل لنظامي macOS وWindows

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

الدخول إلى نسخة الويب

من لا يريد تثبيت أي شيء يحتاج إلى زر واضح للدخول إلى نسخة الويب. والمهم أن يقود الدخول والتسجيل إلى التطبيق نفسه، لا إلى حساب منفصل على الموقع التسويقي، وإلا صار للمستخدم حسابان وحدث الارتباك.

الطلب

إذا كان المنتج يُباع عبر محادثة، فيجب أن يكون نموذج الطلب قصيرًا، وأن تُفحص حقوله على الخادم، وأن يصل الطلب إلى الفريق فورًا. وبعد الإرسال يرى الزائر ما الذي سيحدث لاحقًا ومتى سيُتواصل معه.

التصميم المتجاوب ومثال JEEKSSHIRE 24

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

وهكذا بُني موقعنا نحن. تعمل الصفحة الرئيسية لـ JEEKSSHIRE 24 بالروسية والإنجليزية والصينية والعربية مع تخطيط من اليمين إلى اليسار، وتُبنى النسخ اللغوية بمولّد من مصدر واحد، ولكل نسخة عنوانها الخاص وhreflang وترميز Schema.org وخريطة موقع، مع تحليلات وأهداف للطلبات. وقد أنجز الفريق نفسه صفحتي هبوط Wallet وLegal مع التنزيل لنظامي macOS وWindows والدخول إلى نسخة الويب، وصفحة تطوير البرمجيات، وقسم الأدلة، وصفحة «الأجوبة».

إذا كنت تحتاج إلى موقع لشركتك أو صفحة لمنتجك، فاطّلع على طريقة عملنا في صفحة تطوير البرمجيات حسب الطلب، واقرأ دليل كيف تستلم مشروع البرمجيات لتعرف ما الذي تفحصه عند التسليم. ثم صِف مهمتك في نموذج الطلب: ما المنتج، وأي الأسواق يستهدف، وما الإجراء الذي يجب أن يقوم به الزائر.

صفحات App Store وGoogle Play: الخصوصية والشروط والدعم

إذا كان للمنتج تطبيق جوال، فالموقع لا يلزم للتسويق وحده. فمتاجر التطبيقات تطلب روابط لصفحات يجب أن تكون متاحة للعموم وتعمل دائمًا.

• سياسة الخصوصية: ما البيانات التي يجمعها التطبيق، ولماذا، وكيف يتحكم بها المستخدم. ويطلب رابطها كل من App Store وGoogle Play.
• صفحة الدعم: كيف يتواصل المستخدم مع الفريق وأين يجد إجابات الأسئلة الشائعة. وفي App Store يُذكر عنوانها عند النشر.
• حذف الحساب: إذا كان التسجيل ممكنًا داخل التطبيق، يطلب Google Play صفحة ويب يمكن للمستخدم فيها طلب حذف حسابه وبياناته.
• شروط الاستخدام: قواعد استخدام الخدمة، خاصة إذا تضمن التطبيق مدفوعات أو اشتراكًا.

يحسن إعداد هذه الصفحات بكل اللغات التي يصدر بها التطبيق، وإبقاء عناوينها ثابتة: فلا يجوز أن يقود الرابط في المتجر إلى صفحة خطأ بعد إعادة تصميم الموقع. ومن الأفضل مراجعة نصوص السياسات مع محامٍ. والتحضير للنشر جزء معتاد من تطوير تطبيقات الجوال.

كيف تعرض المنتج: لقطات الشاشة والفيديو والعرض التجريبي

يقرر الزائر خلال ثوانٍ، ولذلك يجب أن تظهر واجهة المنتج فورًا، لا أن توصف بالكلمات.

• لقطات شاشة للواجهة الحقيقية لا رسوم تجريدية. تحمل كل لقطة فكرة واحدة: ماذا يفعل المستخدم هنا.
• إطارات الأجهزة: الهاتف والحاسوب المحمول يوضحان فورًا المنصات التي يعمل عليها المنتج.
• فيديو قصير للسيناريو الرئيسي دون مقدمة طويلة.
• عرض تجريبي حي أو نسخة ويب يمكن فيها تجربة المنتج دون تثبيت.
• لقطات بلغة الصفحة: في النسخة العربية بواجهة من اليمين إلى اليسار.

لا تعرض ما ليس في المنتج: فالفجوة بين التوقعات والواقع تسبب خيبة أمل مباشرة بعد التثبيت. وإذا كان المنتج يعمل في المتصفح، فأفضل طريقة لعرضه أن تتيح الدخول إلى نسخة الويب. وهكذا مثلًا صُممت صفحتا Wallet وLegal: بجانب التنزيل لنظامي macOS وWindows يوجد دخول إلى نسخة الويب. وتُبنى مثل هذه المنتجات ضمن تطوير تطبيقات الويب.