يتم طرح مصطلح واجهة المستخدم أو واجهة المستخدم كثيرًا عندما يتعلق الأمر بتطوير التطبيقات. أول شيء يراه العميل عند فتح تطبيق هو كيفية تصميم التطبيق ، ومن المنطقي أن هذا جانب من جوانب تطوير الويب مهم للغاية. يمكن لواجهة مستخدم بسيطة وسهلة الاستخدام زيادة معدلات التحويل لتطبيق الويب بنسبة 200٪ تقريبًا. واجهة المستخدم هي جزء لا يتجزأ من عملية تطوير البرمجيات.
نظرًا لأنه يرتبط في الغالب بما يراه العميل ، يتم تطوير واجهات المستخدم بواسطة مهندسي الواجهة الأمامية. العديد من أطر العمل الأمامية - مثل React.js و flutter والمزيد ، تجعل تطوير واجهات المستخدم الجميلة أمرًا بسيطًا وفعالًا. ومع ذلك ، يمكن أن يكون التطوير التقليدي عملية طويلة ، خاصة عندما يتعلق الأمر بالتحديثات. غالبًا ما تتطلب متاجر التطبيقات مثل متجر Apple ومتجر Google play من المطورين الخوض في عملية طويلة إذا كانوا يريدون تنفيذ أي تغييرات رئيسية في واجهة المستخدم. هذا هو المكان الذي يمكن أن تحدث فيه SDUI ، أو تطوير تطبيقات واجهة المستخدم التي تعتمد على الخادم ، فرقًا.
يمكن أن تكون واجهة المستخدم المعتمدة على الخادم أو التطوير المستند إلى الواجهة الخلفية مغيرًا للعبة ، والطريقة التي تعمل بها مشابهة جدًا لكيفية تعامل المتصفحات مع لغات مثل HTML و CSS. ولكن قبل أن ندخل في كيفية عمل SDUI ومزاياها ، دعنا نلقي نظرة على الواجهة الخلفية أو واجهة المستخدم المدفوعة بالخادم في الواقع.
ما هي واجهة المستخدم التي يحركها الخادم؟
تشير واجهة المستخدم الخاصة بالتطبيق أو الخدمة إلى شكلها وشعورها. يجب أن يهتم مصمم واجهة المستخدم بكيفية عرض الجوانب الفردية للتطبيق ، والجماليات ، واستجابة صفحة الويب على أجهزة متعددة. هذا لأنها منطقة الشاشة الرئيسية التي يتفاعل فيها المستهلكون مع الموقع.
يتم تعريف واجهة المستخدم لموقع الويب من خلال كود HTML الخاص به. يمكن للعملاء تلقي هذا الرمز بسرعة عندما يزورون موقعًا يستخدم تطوير واجهة المستخدم من جانب الخادم. عندما يستخدم المستخدمون مثل هذا التطبيق ، يتم تحميل الموقع والتصميم و CSS وجافا سكريبت والمواد الموجودة في الموقع أثناء الطلب الأصلي.
في التطوير التقليدي لتطبيق الهاتف المحمول ، يقوم المبرمج بتصميم وحزم تصميم واجهة المستخدم ومظهرها في دورة الإصدار. يتم تحميل حزمة البرامج إلى متاجر التطبيقات مثل متجر Google play ، حيث تتم مراجعتها قبل إتاحتها للتنزيل من قبل العملاء. يتم جعل واجهات المستخدم الخاصة بهذه التطبيقات تفاعلية من خلال فصل واجهة المستخدم عن المحتوى الذي تقدمه. غالبًا ما يتم تنزيل المعلومات من خادم أو واجهة خلفية ودمجها في واجهة المستخدم ، على الرغم من أن واجهة المستخدم هي أحد مكونات رمز التطبيق. هذه هي الحالة المعتادة لدورة الإصدار في حالة التحديث.
ضع في اعتبارك الحالة التي يحتاج فيها المطورون إلى إضافة بعض التعديلات الرئيسية لواجهة المستخدم إلى التطبيق. كما ذكرنا أعلاه ، يجب أن يمر المطورون بدورة إصدار كاملة لإدخال هذه التغييرات. وذلك لأن المنطق الذي يملي كيفية عرض المعلومات مدمج في الشاشة الرئيسية للبرنامج. بعد إجراء التحسينات اللازمة في دورة الإصدار هذه ، يجب أن يخضعوا لجولة أخرى من المراجعة والاختبار والموافقة على متجر الألعاب. إذا كان يجب إصدار تطبيقك على كل من نظامي iOS و Android ، فيجب إكمال دورة الإصدار مرتين. قد تكون هذه عملية طويلة ، وستحتاج على الأرجح إلى مطورين منفصلين للنظامين الأساسيين لأنهما بحاجة إلى الترميز بلغات مختلفة. بحلول الوقت الذي تصل فيه التغييرات الطفيفة في واجهة المستخدم إلى المستخدمين بعد دورة الإصدار ، قد يستغرق الأمر شهورًا.
الاختلاف عن التقديم من جانب العميل
يستفيد التطوير التقليدي من التقديم من جانب العميل. هنا ، يتم استرداد تصميم الصفحة و CSS و JavaScript بعد أن يقوم العميل بتقديم طلب. في بعض الأحيان ، لن يتم تضمين محتوى معين ، مما يجبر JavaScript على تنفيذ طلبات إضافية للحصول على القدرة على إنتاج HTML الضروري.
هذا النهج له مزاياه ، لكنه يواجه المشكلة المذكورة أعلاه عندما يتعلق الأمر بالتحديثات. ومع ذلك ، يمكن أن يكون مفيدًا في بعض الأحيان. إذا تم تغيير جزء صغير فقط من موقع الويب عند استخدام العرض من جانب العميل ، على سبيل المثال ، فلن تحتاج الصفحة بأكملها إلى إعادة العرض. يتأكد عرض واجهة المستخدم من جانب العميل من أن جميع البيانات الضرورية قد تم تحميلها بالكامل. نتيجة لهذا ، تصبح واجهة المستخدم من جانب العميل سريعة جدًا وسريعة الاستجابة. يجعل العرض من جانب العميل من الممكن أيضًا إشراك المستخدمين بشكل تفاعلي.
للعرض من جانب الخادم ، من الضروري الاحتفاظ بالبرنامج النصي نفسه على جانبي التطبيق والعميل ، مما قد يؤدي إلى ارتفاع تكاليف التشغيل وتأخير التطوير. توفر تطبيقات العميل سهلة الاستخدام درجة عالية من الأداء. ولكن بمجرد اكتمال تحميل نصوص JavaScript الضرورية. لذلك ، قد تكون هناك بعض مشكلات الأداء أثناء استخدام الهواتف المحمولة واتصال إنترنت بطيء في مثل هذه التطبيقات. يمكن أن يؤدي تنوع الأجهزة المحمولة المتاحة اليوم أيضًا إلى صعوبة التنبؤ بكيفية عمل العرض من جانب العميل. ينشئ المطورون واجهة مستخدم من جانب العميل بمساعدة مكتبات مثل Ember.js و backbone.js والمزيد.
مزايا واجهة المستخدم المعتمدة على الخادم
لا يبدو المنتج النهائي لواجهة المستخدم التي يحركها الخادم مختلفًا عن واجهة المستخدم من جانب العميل. إذن ما هي المزايا التي تقدمها SDUI؟
تحديثات سريعة
تتمتع SDUI بالعديد من المزايا عندما يحتاج المطورون إلى إجراء تحديثات على أحد التطبيقات. قد تستغرق دورة إصدار التحديث الجديد ما يصل إلى أسابيع. يمكن تسريع هذا باستخدام SDUI. يحتاج المهندسون فقط إلى استخدام الواجهة الخلفية أو ترقية من جانب الخادم. لا يحتاجون إلى اختباره لأنهم لا ينشئون أي رمز جديد. لن تضطر دورة الإصدار أيضًا إلى إرسال الإصدار المحدث من التطبيق إلى متاجر التطبيقات مثل متجر Google play. لذلك لا يلزم الحصول على موافقة من Apple أو Google. يمكن الآن إجراء التغييرات التي كانت تستغرق شهورًا أو أسابيع في غضون ساعات أو أيام. تنعكس هذه التعديلات في دورة الإصدار على كل من تطبيق iOS وتطبيق Android حيث يتم إجراء التغييرات على الخادم مباشرة.
أسهل في التنفيذ
عادةً ما تكون الإستراتيجية الخلفية أو المستندة إلى الخادم أبسط إذا كان المطورون يقومون بإنشاء صفحة ويب ثابتة. كما لا يتعين عليهم القلق بشأن مخاوف تحسين محركات البحث المحتملة لأن موقع الويب ينشئ HTML ثابتًا ، مما يمكّن محركات البحث من رؤية المواد الخاصة بهم. من خلال تقليل العمل على المتصفح ، فإنك تقلل أيضًا من فرصة حدوث أخطاء غير متوقعة.
فهرسة أسهل لوسائل التواصل الاجتماعي
على غرار برامج زحف محركات البحث ، تواجه روبوتات الوسائط الاجتماعية مشكلة في تحليل مواد JavaScript. على سبيل المثال ، لا تدعم بطاقات Twitter التقديم من جانب العميل. يمكن أن يكون نهج العرض من جانب الخادم هو الأفضل إذا كانت مشاركة الشبكات الاجتماعية مكونًا مهمًا في خطة التسويق الخاصة بك. يعد عرض التطبيق المستند إلى الخادم أقل تعقيدًا وأكثر أمانًا أيضًا. دعونا نلقي نظرة على هذا بالتفصيل.
تقليل التعقيد
في ظل ظروف معينة ، يمكن أن يكون استخدام الواجهة الخلفية أو تطوير واجهة المستخدم المدفوعة بالخادم أقل تعقيدًا بكثير من أقسام الواجهة الأمامية والخلفية. من منظور المطور ، فإن تطوير واجهة المستخدم المعتمدة على الخادم يقلل من الإجهاد المعرفي. دون الحاجة إلى التفكير في بيئتي برمجة ، قد يركز المطور أكثر على القيمة المضافة للتطبيق الذي يقوم بإنشائه. يقلل التخلص من الازدواجية بشكل كبير من تعقيد هذه التطبيقات أيضًا. لا يلزم تحديد برنامج واجهة برمجة التطبيقات الخلفية وبرنامج واجهة المستخدم نظرًا لأنه يتم التعامل مع منطق التحقق في مكان واحد.
حماية
لا يجعل تطوير واجهة المستخدم المعتمدة على الخادم مواصفاته مرئية للمتصفح ولا يقدم سوى البيانات الدقيقة اللازمة لتغيير واجهة المستخدم. عند مقارنتها بالسيناريو حيث ينقل المبرمجون البيانات المناسبة لجهة اتصال معينة لواجهة المستخدم ، فهذه استراتيجية تطوير أكثر أمانًا في جوهرها. نتيجة لذلك ، لن تكشف نقاط نهاية واجهة برمجة التطبيقات عن الكثير من المعلومات لمتصفح جافا سكريبت. هذا يجعل الأمر أكثر صعوبة لحدوث اختراق أو خرق للبيانات. هذا مهم للغاية للحفاظ على سمعة الشركة وحيوي لمنطق العمل.
فرق مكدسة كاملة
غالبًا ما يتم تقسيم فرق التطوير إلى فرق مختلفة. يتطلب هذا قدرًا معينًا من تكامل أجزاء البرنامج المختلفة بمجرد الانتهاء من المكونات الفردية. يمكن أن يتسبب الفصل الصارم بين الواجهة الأمامية والخلفية في حدوث قدر من الانفصال بين الفرق ، حيث تتطلب المجالات المختلفة معرفة متخصصة. هذا يجعل الأمر أكثر صعوبة بالنسبة للمطورين للنظر في منطق الأعمال الكامل من طرف إلى طرف لأنهم مسؤولون فقط عن جزء واحد.
إذا كنت مهندسًا متكاملًا ، فسيكون التعامل مع هذا أسهل بكثير. يمكن فهم العيوب أو الفوائد المحتملة لمكونات واجهة المستخدم بسهولة. يمكن لفرق المكدس الكاملة تنفيذ تطوير واجهة مستخدم يعتمد على الخادم ، ويمكن تقليل الحاجة إلى التكامل إلى حد ما.
عيوب واجهة المستخدم التي يحركها الخادم
على الرغم من أن استخدام الخلفية أو التقديم المستند إلى الخادم يبدو وكأنه مفهوم مباشر ، إلا أن عمق الفكرة يزداد جنبًا إلى جنب مع تعقيد التطبيق ومنطق الأعمال ، إلا أن بعض العيوب الرئيسية المرتبطة بواجهات المستخدم التي يحركها الخادم هي:
يعد وقت التحميل
يتمثل العيب الأساسي في العرض الذي يعتمد على الخادم في أن الخادم أو الواجهة الخلفية ينشئان صفحة ويب جديدة لكل اتصال مع عميل. يجب بعد ذلك منح العميل حق الوصول إلى هذه الصفحة مرة أخرى. قد يؤدي هذا النشاط إلى نقص الاستجابة وزيادة كبيرة في أوقات التحميل. على الرغم من أن العرض الخلفي أو جانب الخادم مفيد لإنشاء مواقع HTML ثابتة ، إلا أنه يمكن أن يبطئ عرض صفحة الويب أو عرض الشاشة الرئيسية في التطبيقات الأكثر تعقيدًا بسبب مكالمات الخادم العادية.
أغلى
يجب أن تحصل على خادم أو واجهة خلفية بدون خادم لبدء تشغيل تطبيق يعتمد على الخادم ، مما يؤدي إلى زيادة تكاليف التشغيل. يمكن أن تكون العملية باهظة الثمن وتستهلك الكثير من الموارد لأن العرض الذي يعتمد على الخادم ليس هو المعيار لصفحات الويب جافا سكريبت. قد تجد الشركات الصغيرة صعوبة في تجنيب الأموال لمثل هذه الخوادم.
عدم التوافق وحجم HTML أكبر
التقديم من جانب الخادم غير متوافق مع بعض أدوات وبرامج الجهات الخارجية. تحتوي التطبيقات التي يديرها الخادم أيضًا على حجم HTML أكبر نتيجة لظروف الترطيب المتكاملة. يجب أن يؤخذ هذا في الاعتبار لأنه خطر محتمل إذا تم تطبيقه بشكل غير صحيح.
تاريخ واجهة المستخدم التي يحركها الخادم
كانت أجهزة الكمبيوتر ضخمة ومكلفة ومستخدمة بشكل أساسي من قبل الشركات الكبرى خلال الستينيات والسبعينيات. نظرًا لأنه كان من غير العملي بالنسبة لكل مستخدم أن يكون لديه جهاز كمبيوتر بعرض الغرفة ، تم إنشاء تقنية حاسب مركزي ، مما يسمح لعدة أشخاص باستخدام نظام كمبيوتر. ثم تم تسليم واجهة المستخدم ، التي تم إنشاؤها باستخدام مخرجات حسابات الأوامر الطرفية ، إلى الشاشات لعرضها. أصبحت هذه المحطات الطرفية أول العملاء الرقيقين. تم تسمية العملاء الرقيقين بهذا الاسم نظرًا لقوتهم الحسابية المحدودة للغاية واعتمادهم على جهاز خارجي لإنتاج واجهة المستخدم.
تم إنشاء الكمبيوتر الشخصي نتيجة لتطوير المعالج الدقيق في أواخر السبعينيات ، مما أدى إلى انخفاض كبير في سعر وحجم أجهزة الكمبيوتر. تم تنزيل التطبيقات وتشغيلها على متصفح كل مستخدم على حدة. كان الكمبيوتر الشخصي عبارة عن كمبيوتر مستقل تم تجهيزه بجميع المكونات اللازمة لعرض واجهة المستخدم. كانت محطات العمل المستقلة بالكامل هذه أول عملاء كثيفين.
يمكن أن تتمتع مواقع الويب أو التطبيقات التي يتم عرضها باستخدام متصفح الويب بالكثير من مزايا العميل الرقيق بفضل التوافر الواسع للإنترنت في التسعينيات. يمكن لأي شخص لديه متصفح ويب ، بالإضافة إلى خدمة الإنترنت ، استخدام القدرات الحسابية التي كانت موجودة بشكل مركزي على أجهزة كمبيوتر مخصصة تُعرف بالخوادم. باستخدام HTML ، وهي لغة ترميز قياسية ، أنشأت الخوادم تطبيق واجهة المستخدم ونقله إلى متصفح الويب الخاص بالمستخدم. كان لا بد من إعداد متصفحات الويب على كل مستعرض بعيد ، ولكن كانت احتياجات أداء أقل بكثير وكانت في الغالب قادرة على حل المشكلات التشغيلية للمؤسسة.
بدأت الهواتف المحمولة في التقدم ولديها القدرة على تنفيذ التطبيقات بشكل مستقل في العقد الأول من القرن الحادي والعشرين. عند استخدام هاتف محمول كعميل رفيع لعرض صفحات الويب ، كان على الخادم أو الواجهة الخلفية نقل تطبيق واجهة المستخدم بالكامل إلى الهاتف عبر الإنترنت ، تمامًا كما فعل مع أجهزة الكمبيوتر الشخصية. ومع ذلك ، في هذا الوقت ، كانت شبكات الهاتف المحمول بطيئة. لذلك كان من المحبط تصفح صفحات الويب.
عندما ظهر iPhone لأول مرة في عام 2007 ، أحدث ثورة في ما يمكن عمله بهاتف ذكي. وصل iPhone مع مجموعة كاملة من البرامج المثبتة بدلاً من مطالبة المستخدمين بالحصول على البرامج من خلال مواقع الويب أو التطبيقات. قدمت Apple متجر التطبيقات ، واعتمد Android متجر Google play ، مما يسمح للمطورين الخارجيين بإنشاء تطبيقات. قدمت هذه التطبيقات تجربة مستخدم فائقة الجودة لأن كل ما هو مطلوب لإظهار واجهة المستخدم تم تضمينه في التطبيق ويمكن استخدامه بدون خدمة الإنترنت.
تناوب توزيع البرامج بين العملاء النحيفين والسميكلين في الأربعين عامًا الماضية ، مع التطبيقات الأصلية ، وهي عملاء كثيفون ، وتهيمن على الهاتف المحمول. تم تمديد بعض مزايا الجهاز العميل الرقيق لتشمل التطبيقات الأصلية بواسطة SDUI. باستخدام استراتيجية تطوير SDUI ، يمكن للخوادم التحكم في أجزاء من واجهة مستخدم التطبيق الأصلي وإرسالها عبر الويب إلى الهواتف الذكية للمستخدمين. يمكن تعديل واجهة المستخدم داخل تطبيق أصلي بسرعة دون الحاجة إلى تثبيت إصدار جديد من البرنامج.
الأطر والأدوات للتطوير الذي يحركه الخادم
بينما ينفذ الخادم عرضًا يحركه الخادم لتطبيق ما ، يتم تنفيذ العرض من جانب العميل بواسطة المستعرض. هناك العديد من الأطر المتاحة حاليًا ، ومن أكثرها استخدامًا:
إنه إطار عمل JavaScript UI مجاني ومفتوح المصدر يمكن دمجه مع بعض الأدوات الأخرى لإنشاء بيئة تطوير متكاملة للتطبيقات عبر الإنترنت.
إنها مجموعة أدوات JavaScript تتيح إنشاء عناصر تطبيق واجهة مستخدم قابلة لإعادة الاستخدام وتكوينها البسيط لإنشاء برامج ضخمة وقابلة للتطوير بدرجة كبيرة.
- الزاوي
Angular Universal هي أداة تطوير خلفية أو تعتمد على الخادم.
واجهة مستخدم تعتمد على الخادم و AppMaster
اليوم ، يمكنك إنشاء تطبيق وبرامج حتى مع خبرة تشفير قليلة جدًا أو معدومة تقريبًا. هذا ممكن بمساعدة الأنظمة الأساسية والأدوات التي لا تحتوي على كود . تسمح هذه الأنظمة الأساسية للمطورين وغير المبرمجين بإنشاء تطبيق برمجي باستخدام واجهات المستخدم والتكوين بدلاً من برمجة الكمبيوتر التقليدية. جعل عدم وجود رمز تطوير البرامج أسهل وأكثر سهولة في الوصول إليها.
أصبح هذا ممكنًا بمساعدة الأنظمة الأساسية غير المشفرة مثل AppMaster. باستخدام AppMaster ، يمكنك الآن تصميم تطبيق حتى بدون خبرة في البرمجة. لا تحتاج أيضًا إلى القلق بشأن حقوق التعليمات البرمجية المصدر التي تقوم بإنشائها - فستكون ملكًا لك. يمكن أيضًا إنشاء هذا الرمز بسرعة.
تتيح إستراتيجية AppMaster التي تعتمد على الخادم إمكانية تحديث التطبيق في الوقت الفعلي. يمكنك الوصول إلى أجهزة الأجهزة مثل أجهزة iPhone و iPad مباشرة باستخدام واجهة مستخدم خلفية أو واجهة مستخدم تعتمد على الخادم. يصل تطبيقك إلى السوق أسرع 10 مرات تقريبًا من استخدام التطوير التقليدي وتحديثات واجهة المستخدم. يمكنك الاستفادة من فائدة تطوير واجهة المستخدم المدفوعة بالخلفية باستخدام AppMaster.
استنتاج
يعتمد السؤال الأخير حول ما إذا كان التطوير المستند إلى الخادم مناسبًا لتطبيقك على وظائفه. إذا كان تطبيقك ديناميكيًا ويحتوي على العديد من العناصر ، فقد تكون SDUI فكرة جيدة بالنسبة لك. بخلاف الفوائد المذكورة أعلاه ، فإنه يساعد أيضًا مواقع الويب والتطبيقات في تصنيفات تحسين محركات البحث. من المهم فهم مزايا وعيوب تطوير واجهة المستخدم التي تعتمد على الخادم قبل تنفيذها. تحتاج SDUI إلى المزيد من الموارد في بعض الأحيان ، ويجب أن تكون في وضع يسمح لك بتزويدها إذا كنت تستخدم نفس الموارد.
إذا كنت ترغب فقط في إنشاء موقع ويب ثابت ، وتريد تحميله بسرعة ، فقد يكون استخدام تطوير أبسط من جانب العميل أفضل بالنسبة لك. في النهاية ، يجب عليك تقييم احتياجات تطبيقك ومنطق العمل الذي تقوم بتنفيذه وتحديد ما إذا كان التطوير الذي يعتمد على الخلفية أو الخادم مناسبًا لك.
