من مجموعة واجهة المستخدم إلى نظام التصميم

تجربة سينما آيفي على الإنترنت

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

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


مجموعات تخطيط منفصلة لكل منصة

تقليديًا، بدأنا بالمشكلات التي سيساعد نظام التصميم في حلها وصياغة المتطلبات لتصميمها. بالإضافة إلى إنشاء لغة مرئية موحدة، وزيادة سرعة التخطيط والتطوير، وتحسين جودة المنتج بشكل عام، كان من الضروري توحيد التصميم قدر الإمكان. يعد ذلك ضروريًا حتى يصبح تطوير الوظائف ممكنًا على جميع منصاتنا في وقت واحد: Web وiOS وAndroid وSmart TV وtvOS وAndroid TV وWindows 10 وxBox One وPS4 وRoku - دون العمل على كل منها على حدة. وقد فعلنا ذلك!

التصميم → البيانات

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

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

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

لغة بصرية

لقد تُرك المطورون للتفكير في كيفية تخزين البيانات ونقلها بطريقة تناسب جميع الأنظمة الأساسية، وكان على التصميم تصميم عناصر الواجهة التي يمكن أن تبدو جيدة وتعمل بفعالية عبر أسطول الأجهزة المدعومة بالكامل.

في السابق، تمكنا بالفعل من "اختبار" معظم عناصر التصميم في تطبيق لنظام التشغيل Windows 10، والذي كان في ذلك الوقت منصة جديدة بالنسبة لنا، أي أنه يتطلب العرض والتطوير "من الصفر". ومن خلال رسمه، تمكنا من إعداد واختبار معظم المكونات وفهم أي منها كان من المفترض أن يتم تضمينه في نظام تصميم Eevee المستقبلي. بدون مثل هذا الصندوق الرملي، لا يمكن الحصول على هذه الخبرة إلا من خلال عدد كبير من التكرارات على منصات عاملة بالفعل، وقد يستغرق هذا أكثر من عام.

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

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

نحن الآن بحاجة إلى جعل جميع الشاشات الكبيرة بنفس حجم التخطيط وملاءمتها في شبكة مشتركة. تم تصميم Apple TV وRoku بحجم 1920 × 1080، وAndroid TV - 960 × 540، وأجهزة التلفاز الذكية، اعتمادًا على البائع، هي نفسها، ولكن في بعض الأحيان 1280 × 720. عندما يتم عرض التطبيق وعرضه على شاشات Full HD، يتم ضرب 960 في 2، ويتم ضرب 1280 في 1,33، ويتم إخراج 1920 كما هو.

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

واجهة مستخدم واحدة لجميع المنصات

الآن، لرسم ميزة جديدة، لا نحتاج إلى رسم تخطيطات لكل منصة، بالإضافة إلى خيارات التكيف لكل منها. يكفي إظهار تخطيط واحد وقدرته على التكيف لجميع المنصات والأجهزة بأي عرض: الهواتف - 320-599، كل شيء آخر - 600-1280.

البيانات → التطوير

بالطبع، بقدر ما نرغب في تحقيق تصميم موحد تمامًا، فإن كل منصة لها ميزاتها الفريدة. على الرغم من أن الويب والتلفزيون الذكي يستخدمان حزمة ReactJS + TypeScript، إلا أن تطبيق Smart TV يعمل على عملاء WebKit وPresto القديمين، وبالتالي لا يمكنه مشاركة الأنماط مع الويب. والنشرات الإخبارية عبر البريد الإلكتروني مجبرة تمامًا على العمل مع التخطيط الجدولي. في الوقت نفسه، لا تستخدم أي من الأنظمة الأساسية غير HTML أو تخطط لاستخدام React Native أو أي من نظائرها، خوفًا من تدهور الأداء، نظرًا لأن لدينا الكثير من التخطيطات المخصصة والمجموعات ذات منطق التحديث المعقد والصور ومقاطع الفيديو. لذلك، فإن المخطط الشائع لتقديم أنماط CSS جاهزة أو مكونات React غير مناسب لنا. لذلك قررنا إرسال البيانات بتنسيق JSON، مع وصف القيم في شكل تعريفي مجرد.

لذا الملكية rounding: 8 يتحول تطبيق Windows 10 إلى CornerRadius="8"، الويب - border-radius: 8px، ذكري المظهر - android:radius="8dp", آي أو إس - self.layer.cornerRadius = 8.0.
ملكية offsetTop: 12 يمكن تفسير نفس عميل الويب في حالات مختلفة على أنه top, margin-top, padding-top أو transform

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

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

الصور التوضيحية

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

يتم تحميل الحروف الرسومية بتنسيق SVG المتجه، ويتم استبدال قيم الألوان تلقائيًا بالمتغيرات. يمكن لتطبيقات العميل أن تستقبلها جاهزة للاستخدام - بأي تنسيق ولون.

معاينة

علاوة على بيانات JSON، قمنا بكتابة أداة لمعاينة المكونات - تطبيق JS الذي يمرر بيانات JSON بسرعة من خلال مولدات العلامات والأنماط الخاصة به، ويعرض أشكالًا مختلفة لكل مكون في المتصفح. في الأساس، المعاينة هي نفس عميل تطبيقات النظام الأساسي تمامًا وتعمل مع نفس البيانات.

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

توثيق

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

مستنكر

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

تطوير العميل

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

لتخطيط شاشات تطبيقات iOS، نستخدم آليتين أساسيتين توفرهما iviUIKit: التخطيط الحر للعناصر وتخطيط مجموعات العناصر. نحن نستخدم VIPER، وكل التفاعل مع iviUIKit يتركز في العرض، ومعظم التفاعل مع Apple UIKit يتركز في iviUIKit. يتم تحديد أحجام العناصر وترتيبها من حيث الأعمدة والهياكل النحوية التي تعمل بالإضافة إلى قيود iOS SDK الأصلية، مما يجعلها أكثر عملية. أدى هذا إلى تبسيط حياتنا بشكل خاص عند العمل مع UICollectionView. لقد كتبنا العديد من الأغلفة المخصصة للتخطيطات، بما في ذلك تلك المعقدة جدًا. كان هناك حد أدنى من رمز العميل وأصبح تصريحيًا.

لإنشاء أنماط في مشروع Android، نستخدم Gradle لتحويل بيانات نظام التصميم إلى أنماط بتنسيق XML. في الوقت نفسه، لدينا العديد من المولدات من مختلف المستويات:

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

إصدارات التطبيق

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

نتائج

لقد مر عام منذ أن أصبح نظام التصميم جزءًا من البنية التحتية الداعمة لتطوير سينما Ivy عبر الإنترنت، ويمكننا بالفعل استخلاص بعض الاستنتاجات:

• هذا مشروع كبير ومعقد يتطلب موارد مخصصة ثابتة.
• وقد سمح لنا ذلك بإنشاء لغتنا المرئية الفريدة عبر الأنظمة الأساسية والتي تلبي أهداف خدمة الفيديو عبر الإنترنت.
• لم يعد لدينا منصات متخلفة بصريا ووظيفيا.

معاينة مكونات نظام تصميم Ivy - design.ivi.ru

المصدر: www.habr.com