تبسيط عملية النقل من Sketch إلى Visual Studio Code باستخدام Indigo.Design

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

وهذا هو سبب أهمية وجود طريقة سلسة لنقل الكرة من أحد أعضاء الفريق إلى آخر.

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

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

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

اليوم ، سنلقي نظرة على سبب حدوث ذلك وكيف يمكن لوكالتك حل المشكلة مع مكونين إضافيين ومنصة سحابية للنماذج الأولية من Indigo.Design.

أين يتم تسليم المصمم-المطور بشكل خاطئ؟

أولاً ، ما يجب أن نسأله حقًا هو:

لماذا يعتبر تسليم المصمم-المطور مشكلة كهذه؟

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

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

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

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

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

لذا ، حقًا ، أصبح تسليم المصمم والمطور مسألة وقت يمكن أن نضيعه؟

"

هل المصمم هو الذي يجب عليه وضع خط أحمر لكل شيء حتى يعرف المطور كيفية تحويل التصميم إلى واقع؟

أو:

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

لا أحد يفوز في أي من السيناريوهين. وستتخلص من هوامش ربحك في هذه العملية.

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

إذن ما هو الجواب؟

تحسين تسليم المصمم والمطور باستخدام Indigo.Design

إنه ليس مثل Indigo.Design هو أول منصة لمحاولة حل مشكلات التسليم لفرق البرمجيات. قدم كل من InVision و Zeplin حلولهما الخاصة.

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

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

ومع ذلك ، مع منصات مثل InVision و Zeplin ، لا يزال يتعين على المطورين فحص كل عنصر وترميزه يدويًا بناءً على المواصفات المستخرجة. هذه المنصات أيضًا لم تنشئ جسرًا سلسًا بين Sketch و Visual Studio Code.

لذلك ، إذا أراد المصممون والمطورون العمل بأكبر قدر ممكن من الكفاءة مع بعضهم البعض ، فقد طور Indigo.Design إجابة لمشكلتهم:

الخطوة 1: التصميم في Sketch

هناك شيء واحد فقط في هذه المرحلة يجب أن يتغير من أجل المصمم. سيظل التطبيق والصفحات والتدفق مصممين كالمعتاد داخل Sketch ، باستخدام مكونات من Indigo.Design UI Kit.

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

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

يمكن الوصول إلى هذا من Plugins menu > Indigo.Design > Publish Prototype :

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

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

الخطوة 2: العمل في Indigo.Design Cloud

من السهل إدخال الآخرين إلى السحابة. سيأخذهم الرابط المقدم إلى سحابة التجربة حيث يمكن مراجعة التصميم:

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

هناك ما هو أكثر من برنامج التعاون هذا على الرغم من ذلك. يمكن أيضًا تحرير النموذج الأولي من السحابة.

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

انقر فوق "تحرير النموذج الأولي" للدخول إلى محرر Indigo.Design:

بمجرد تحديد الشاشة ، يمكن للمصمم إضافة نقطة فعالة لإنشاء تفاعل جديد في التطبيق.

يمكنك أيضًا استخدام محرر Indigo.Design لفحص مواصفات واجهة مستخدم التطبيق:

يؤدي التمرير فوق عنصر إلى الكشف عن مواصفات التباعد النسبية. يؤدي النقر فوق عنصر إلى إظهار المزيد من التفاصيل:

يمكن للمطور أيضًا تحرير أو نسخ CSS المكتوبة والمُخرجة بطريقة نظيفة من هذه اللوحة أيضًا. (على الرغم من أنه لا ينبغي عليهم ذلك ، كما سأشرح في الخطوة التالية).

هل ترى ما أعنيه بشأن توفير الوقت للمصممين في إنشاء المواصفات؟ بمجرد دفع هذا التصميم إلى سحابة Indigo.Design ، يتم إنشاء المواصفات تلقائيًا.

الخطوة 3: بناء في Visual Studio Code

الآن ، لنفترض أن تصميمك جيد بما يكفي لبدء التطوير. يعد نقل النموذج الأولي لـ Indigo.Design إلى Visual Studio Code بنفس سهولة الانتقال من Sketch.

استرجع رابط السحابة الأصلي المقدم من المكون الإضافي Indigo.Design في Sketch. إذا لم يكن لديك بعد الآن ، فلا بأس بذلك. يمكنك استعادته من شاشة المكتبات في Indigo.Design:

كل ما على المطور فعله الآن هو تثبيت ملحق Indigo.Design Code Generator. هذا ما يمكّن Visual Studio Code من التحدث مباشرة إلى Indigo.Design لاسترداد النموذج الأولي.

بمجرد إعداد الامتداد ، سيقوم المطور بما يلي:

افتح غلاف التطبيق الذي تم تطويره بالفعل. ثم ، قم بتشغيل Indigo.Design Code Generator. هذا هو المكان الذي ستدخل فيه رابط السحابة:

سيكشف هذا عن نافذة منبثقة بها تصميمات التطبيقات التي تعيش في السحابة بالإضافة إلى المكونات الفردية التي تتكون منها.

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

بالنقر على "إنشاء أصول التعليمات البرمجية" ، ستتم إضافة المكونات المحددة إلى Angular كـ HTML و CSS مقروءتين ودلاليين.

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

ملاحظة حول هذه العملية

من المهم الإشارة إلى أن سير عمل Sketch - cloud - Visual Studio Code لا يعمل فقط مع التكرار الأول للتصميم. يمكن للمطورين البناء بينما يعمل المصممون من خلال التعليقات مع العملاء أو دراسات قابلية الاستخدام مع المستخدمين - وهو أمر تضعه شركة Indigo.Design في الاعتبار.

لذلك ، لنفترض أن المصمم نقل واجهة مستخدم نموذج تسجيل الدخول من خلال Indigo. أنشأ التصميم والمطور الكود لتحريك الأشياء.

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

في غضون ذلك ، تلقى المصمم رسالة من العميل لإعلامه بضرورة تنفيذ تسجيل دخول عام جديد من خلال Google. مما يعني أن UX يجب أن يتغير.

عندما يكون التحديث جاهزًا ومزامنة النموذج الأولي مع Indigo.Design ، يرسل المصمم رسالة إلى المطور لإعلامه بالتغييرات. لذلك ، أطلق المطور Visual Studio Code Generator مرة أخرى. ومع ذلك ، عند إعادة إنشاء شاشة تسجيل الدخول ، يقومون بتحديد "عدم التجاوز" في ملف TypeScript. بهذه الطريقة ، يمكنهم الحفاظ على الكود الذي كتبوه أثناء استيراد HTML و CSS الجديدين في نفس الوقت.

يمكن للمطور بعد ذلك إجراء أي تعديلات ضرورية بناءً على التصميم المحدث.

يتم إحتوائه

أنشأ Indigo.Design عملية تسليم فعالة وخالية من الأخطاء للمصممين العاملين في Sketch والمطورين الذين يعملون في Visual Studio Code.

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

كما قال جيسون بيريس ، نائب الرئيس الأول لتطوير المنتجات لشركة Indigo.Design:

مع إنشاء رمز Indigo.Design ، يتم تجنب كل هذه الأخطاء بنسبة 100٪. لا يتم الحفاظ على روح التصميم فحسب ، بل يتم إنشاء HTML و CSS بجودة بكسل مثالية بحيث لا يكون المطور في موقف مؤسف حيث يضطر إلى مطابقة التصميم يدويًا.

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