از کیت UI تا سیستم طراحی

تجربه سینمای آنلاین پیچک

هنگامی که در ابتدای سال 2017 برای اولین بار به فکر ایجاد سیستم تحویل طرح به کد خودمان بودیم، بسیاری قبلاً در مورد آن صحبت می کردند و حتی برخی نیز آن را انجام می دادند. با این حال، تا به امروز اطلاعات کمی در مورد تجربه ساخت سیستم‌های طراحی کراس پلتفرم وجود دارد، و هیچ دستور العمل واضح و اثبات شده‌ای برای توصیف فن‌آوری‌ها و روش‌هایی برای چنین تبدیل فرآیند اجرای طراحی به یک محصول در حال کار وجود ندارد. و از "مولفه های موجود در کد" اغلب به معنای چیزهای بسیار متفاوت هستند.

در همین حال، این شرکت سال به سال کارکنان خود را دو برابر کرد - لازم بود بخش طراحی مقیاس‌بندی شود و فرآیندهای ایجاد و انتقال طرح‌بندی برای توسعه بهینه شود. ما همه اینها را در «باغ‌وحش» پلتفرم‌هایی که نیاز به پشتیبانی دارند ضرب می‌کنیم و شباهتی از هیاهوی بابلی به دست می‌آوریم که به سادگی قادر به «انجام عادی» و ایجاد درآمد نیست. توسعه پلتفرم ها اغلب به صورت موازی پیش می رفت و عملکرد یکسانی می توانست با تاخیر چند ماهه بر روی پلتفرم های مختلف منتشر شود.


مجموعه های طرح بندی جداگانه برای هر پلت فرم

به طور سنتی، ما با مشکلاتی شروع کردیم که یک سیستم طراحی به حل آنها کمک می کرد و الزامات طراحی آن را تدوین می کرد. علاوه بر ایجاد یک زبان بصری یکپارچه، افزایش سرعت چیدمان و توسعه، و بهبود کیفیت کلی محصول، یکپارچه سازی طراحی تا حد امکان حیاتی بود. این امر ضروری است تا توسعه عملکرد در همه پلتفرم‌های ما به طور همزمان امکان پذیر شود: وب، iOS، Android، تلویزیون هوشمند، tvOS، Android TV، Windows 10، xBox One، PS4، Roku - بدون اینکه روی هر کدام به طور جداگانه کار کنید. و ما این کار را کردیم!

طراحی → داده

هنگامی که توافقات اساسی بین بخش های محصول و توسعه حاصل شد، ما نشستیم تا یک پشته فناوری را انتخاب کنیم و جزئیات کل فرآیند - از طرح بندی تا انتشار را بررسی کنیم. برای خودکارسازی کامل فرآیند انتقال طرح به توسعه، گزینه تجزیه پارامترهای مؤلفه را مستقیماً از فایل‌های Sketch با طرح‌بندی بررسی کردیم. مشخص شد که یافتن کدهای مورد نیاز و استخراج پارامترهای مورد نیازمان، کاری پیچیده و خطرناک بود. اولاً، طراحان باید در نام‌گذاری تمام لایه‌های کد منبع بسیار مراقب باشند، ثانیاً، این فقط برای ساده‌ترین مؤلفه‌ها کار می‌کند، و ثالثاً، وابستگی به فناوری شخص دیگری و ساختار کد طرح اولیه Sketch، آینده کل را به خطر می‌اندازد. پروژه ما تصمیم گرفتیم که اتوماسیون را در این زمینه کنار بگذاریم. به این ترتیب اولین نفر در تیم سیستم طراحی ظاهر شد که ورودی آن طرح‌بندی‌های طراحی و خروجی داده‌هایی است که تمام پارامترهای اجزا را توصیف می‌کند و طبق متدولوژی طراحی اتمی به صورت سلسله مراتبی مرتب می‌شوند.

تنها کاری که باید انجام شود این بود که داده‌ها را کجا و چگونه ذخیره کنیم، چگونه آن‌ها را به توسعه منتقل کنیم و چگونه آن‌ها را در توسعه در همه پلتفرم‌هایی که پشتیبانی می‌کنیم تفسیر کنیم. شب از کار افتاد... نتیجه جلسات منظم کارگروه متشکل از طراحان و رهبران تیم از هر پلت فرم، توافق بر سر موارد زیر بود.

ما به صورت دستی تصویر را به عناصر اتمی تجزیه می کنیم: فونت، رنگ، شفافیت، تورفتگی، گرد کردن، نمادها، تصاویر و مدت زمان انیمیشن ها. و از این دکمه‌ها، ورودی‌ها، چک باکس‌ها، ویجت‌های کارت بانکی و غیره را جمع‌آوری می‌کنیم. به سبک‌های هر یک از سطوح، به جز آیکون‌ها، نام‌های غیر معنایی اختصاص می‌دهیم، مثلاً نام شهرها، نام پوره‌ها، پوکمون، ماشین. مارک ها ... فقط یک شرط وجود دارد - لیست نباید قبل از پایان تمام شود - نمایش باید پیش برود! شما نباید با معناشناسی غرق شوید، به طوری که برای مثال مجبور نباشید یک دکمه وسط بین "کوچک" و "متوسط" اضافه کنید.

زبان تصویری

برنامه‌نویس‌ها باید در مورد نحوه ذخیره و انتقال داده‌ها به شیوه‌ای که مناسب همه پلتفرم‌ها باشد فکر کنند، و طراحی باید عناصر رابط را طراحی می‌کرد که می‌توانستند خوب به نظر برسند و به طور مؤثر در کل ناوگان دستگاه‌های پشتیبانی‌شده کار کنند.

قبلاً ما قبلاً موفق شده بودیم اکثر عناصر طراحی را در یک برنامه برای ویندوز 10 "تست" کنیم ، که در آن زمان یک پلت فرم جدید برای ما بود ، یعنی نیاز به رندر و توسعه "از ابتدا" داشت. با ترسیم آن، توانستیم اکثر اجزا را آماده و آزمایش کنیم و بفهمیم که کدام یک از آنها قرار است در سیستم طراحی Eevee آینده گنجانده شوند. بدون چنین جعبه شنی، چنین تجربه ای تنها از طریق تعداد زیادی تکرار در پلتفرم هایی که از قبل کار می کردند به دست می آمد و این بیش از یک سال طول می کشد.

استفاده مجدد از اجزای مشابه در پلتفرم‌های مختلف تعداد طرح‌بندی‌ها و آرایه داده‌های سیستم طراحی را به میزان قابل توجهی کاهش می‌دهد، بنابراین طراحی باید یک مشکل دیگر را حل می‌کرد، که قبلاً در شیوه‌های طراحی و توسعه محصول توضیح داده نشده بود - مثلاً چگونه، آیا می توان از دکمه تلفن و تبلت دوباره در تلویزیون استفاده کرد؟ و با اندازه فونت ها و عناصر در چنین پلتفرم های مختلف چه کنیم؟

بدیهی است که لازم بود یک شبکه مدولار کراس پلتفرم طراحی شود که اندازه متن و عناصر مورد نیاز ما را برای هر پلتفرم خاص تنظیم کند. به عنوان نقطه شروع برای شبکه، اندازه و تعداد پوسترهای فیلمی را که می‌خواهیم در یک صفحه نمایش ببینیم انتخاب کردیم و بر این اساس، قانون ساخت ستون‌های شبکه‌ای را تنظیم کردیم، مشروط بر اینکه عرض یک ستون برابر باشد. به عرض پوستر

اکنون باید تمام صفحه های بزرگ را به یک اندازه چیدمان بیاوریم و آنها را در یک شبکه مشترک قرار دهیم. Apple TV و Roku در اندازه 1920x1080 طراحی شده اند، Android TV - 960x540، تلویزیون های هوشمند، بسته به فروشنده، یکسان هستند، اما گاهی اوقات 1280x720. هنگامی که برنامه رندر می شود و در صفحه نمایش فول اچ دی نمایش داده می شود، 960 در 2 ضرب می شود، 1280 در 1,33 ضرب می شود و 1920 همان طور که هست خروجی می شود.

با صرف نظر از جزئیات خسته کننده، به این نتیجه رسیدیم که به طور کلی همه صفحه‌ها، از جمله صفحه‌نمایش تلویزیون، از نظر عناصر و اندازه‌هایشان، توسط یک طرح‌بندی پوشش داده می‌شوند، و همه صفحه‌های تلویزیون یک مورد خاص از شبکه عمومی کراس پلتفرم هستند. و از پنج یا شش ستون تشکیل شده است، مانند یک تبلت یا دسکتاپ متوسط. کسانی که به جزئیات علاقه دارند، در نظرات بروند.

رابط کاربری واحد برای همه سیستم عامل ها

اکنون، برای ترسیم یک ویژگی جدید، نیازی به ترسیم طرح‌بندی برای هر پلتفرم، به علاوه گزینه‌های سازگاری برای هر یک از آنها نداریم. کافی است یک طرح و سازگاری آن را برای همه سیستم عامل ها و دستگاه های با هر عرض نشان دهید: تلفن ها - 320-599، هر چیز دیگری - 600-1280.

داده → توسعه

البته به همان اندازه که دوست داریم به یک طراحی کاملا یکپارچه دست یابیم، هر پلتفرم ویژگی های منحصر به فرد خود را دارد. حتی اگر هم وب و هم تلویزیون هوشمند از پشته ReactJS + TypeScript استفاده می‌کنند، برنامه تلویزیون هوشمند روی کلاینت‌های قدیمی WebKit و Presto اجرا می‌شود و بنابراین نمی‌تواند سبک‌ها را با وب به اشتراک بگذارد. و خبرنامه های ایمیل کاملاً مجبور به کار با طرح بندی جدولی هستند. در عین حال، هیچ یک از پلتفرم‌های غیر html از React Native یا هر یک از آنالوگ‌های آن استفاده نمی‌کنند یا برنامه‌ای برای استفاده از آن ندارند، زیرا از کاهش عملکرد می‌ترسند، زیرا ما طرح‌بندی‌های سفارشی، مجموعه‌هایی با منطق به‌روزرسانی پیچیده، تصاویر و ویدیوها داریم. بنابراین، طرح رایج ارائه سبک های آماده CSS یا کامپوننت های React برای ما مناسب نیست. بنابراین، ما تصمیم گرفتیم که داده ها را در قالب JSON انتقال دهیم و مقادیر را به صورت انتزاعی توصیف کنیم.

پس اموال rounding: 8 برنامه ویندوز 10 تبدیل به CornerRadius="8"، وب - border-radius: 8px، اندروید - android:radius="8dp"، iOS - self.layer.cornerRadius = 8.0.
ویژگی offsetTop: 12 یک کلاینت وب مشابه در موارد مختلف می تواند به عنوان تعبیر شود top, margin-top, padding-top یا transform

اعلامی بودن توصیف همچنین به این معناست که اگر پلتفرم از نظر فنی نتواند از یک ویژگی یا ارزش آن استفاده کند، می‌تواند آن را نادیده بگیرد. از نظر اصطلاح، ما نوعی زبان اسپرانتو ساختیم: برخی از آندروید، برخی از SVG، برخی از CSS گرفته شده اند.

اگر در یک پلتفرم خاص نیاز به نمایش عناصر متفاوت دارید، ما توانایی انتقال داده های تولیدی مربوطه را در قالب یک فایل JSON جداگانه پیاده سازی کرده ایم. به عنوان مثال، وضعیت "در فوکوس" برای تلویزیون هوشمند تغییر موقعیت متن زیر پوستر را دیکته می کند، به این معنی که برای این پلت فرم، این جزء در مقدار ویژگی "تورفتگی" حاوی 8 نقطه تورفتگی مورد نیاز است. اگرچه این زیرساخت سیستم طراحی را پیچیده می‌کند، اما درجه آزادی بیشتری را به ما می‌دهد و این فرصت را به ما می‌دهد که خودمان «ناهمسانی» بصری پلتفرم‌ها را مدیریت کنیم و گروگان معماری‌ای که ایجاد کرده‌ایم نباشیم.

پیکتوگرام ها

شمایل نگاری در یک محصول دیجیتال همیشه یک پروژه فرعی حجیم است و ساده ترین نیست و اغلب به یک طراح جداگانه نیاز دارد. همیشه گلیف های زیادی وجود دارد، هر کدام از آنها اندازه ها و رنگ های مختلفی دارند و پلتفرم ها معمولاً به آنها در قالب های مختلف نیاز دارند. به طور کلی، دلیلی وجود نداشت که همه اینها را در سیستم طراحی قرار دهیم.

گلیف ها در قالب برداری SVG بارگیری می شوند و مقادیر رنگ به طور خودکار با متغیرها جایگزین می شوند. برنامه های مشتری می توانند آنها را آماده استفاده - در هر قالب و رنگی دریافت کنند.

پیشپرسور

در بالای داده‌های JSON، ابزاری برای پیش‌نمایش مؤلفه‌ها نوشتیم - یک برنامه JS که داده‌های JSON را به سرعت از طریق نشانه‌گذاری و ژنراتورهای سبک خود ارسال می‌کند و تغییرات مختلفی از هر مؤلفه را در مرورگر نمایش می‌دهد. اساساً، پیش‌نمایش دقیقاً همان کلاینت برنامه‌های پلتفرم است و با همان داده‌ها کار می‌کند.

ساده ترین راه برای درک نحوه عملکرد یک جزء خاص، تعامل با آن است. بنابراین، ما از ابزارهایی مانند Storybook استفاده نکردیم، بلکه یک پیش‌نمایش تعاملی ایجاد کردیم - می‌توانید لمس کنید، اشاره کنید، کلیک کنید... هنگام اضافه کردن یک جزء جدید به سیستم طراحی، در پیش‌نمایش ظاهر می‌شود تا پلتفرم‌ها چیزی برای تمرکز روی آن داشته باشند. اجرای آن

اسناد

بر اساس داده‌های ارائه شده به پلتفرم‌ها در قالب JSON، مستندات اجزا به طور خودکار تولید می‌شوند. فهرستی از خواص و انواع مقادیر ممکن در هر یک از آنها توضیح داده شده است. پس از تولید خودکار، می توان اطلاعات را به صورت دستی روشن کرد و یک توضیح متنی اضافه کرد. پیش نمایش و مستندات در سطح هر مؤلفه به یکدیگر ارجاع داده می شوند و تمام اطلاعات موجود در مستندات در قالب فایل های JSON اضافی در دسترس توسعه دهندگان است.

منسوخ کننده

یکی دیگر از ضروریات، امکان جایگزینی و به روز رسانی اجزای موجود در طول زمان بود. سیستم طراحی یاد گرفته است که به توسعه دهندگان بگوید کدام ویژگی ها یا حتی اجزای کامل را نمی توان استفاده کرد و به محض اینکه دیگر در همه پلتفرم ها استفاده نمی شوند، آنها را حذف می کند. هنوز کار "دستی" زیادی در این فرآیند وجود دارد، اما ما هنوز ایستاده نیستیم.

توسعه مشتری

بدون شک پیچیده ترین مرحله، تفسیر داده های سیستم طراحی در کد تمامی پلتفرم های مورد پشتیبانی ما بود. برای مثال، اگر شبکه‌های مدولار در وب چیز جدیدی نیستند، توسعه‌دهندگان برنامه‌های موبایلی بومی برای iOS و Android قبل از اینکه بفهمند چگونه با آن زندگی کنند، سخت کار کردند.

برای چیدمان صفحه‌های برنامه‌های iOS، از دو مکانیسم اساسی ارائه‌شده توسط iviUIKit استفاده می‌کنیم: چیدمان رایگان عناصر و طرح‌بندی مجموعه‌ای از عناصر. ما از VIPER استفاده می کنیم و تمام تعاملات با iviUIKit در View متمرکز است و بیشتر تعاملات با Apple UIKit در iviUIKit متمرکز است. اندازه‌ها و چیدمان عناصر بر اساس ستون‌ها و ساختارهای نحوی مشخص شده‌اند که بر روی محدودیت‌های اصلی iOS SDK کار می‌کنند و آنها را کاربردی‌تر می‌کند. این به خصوص زندگی ما را هنگام کار با UICollectionView ساده کرد. ما چندین بسته بندی سفارشی برای چیدمان ها نوشته ایم، از جمله موارد بسیار پیچیده. حداقل کد کلاینت وجود داشت و به صورت اعلامی درآمد.

برای تولید استایل ها در پروژه اندروید، از Gradle استفاده می کنیم و داده های سیستم طراحی را به سبک هایی در قالب XML تبدیل می کنیم. در همان زمان، ما چندین ژنراتور در سطوح مختلف داریم:

• پایه ای. داده های اولیه برای مولدهای سطح بالاتر تجزیه می شود.
• منبع. دانلود تصاویر، آیکون ها و سایر گرافیک ها.
• جزء. آنها برای هر مؤلفه نوشته شده اند، که توضیح می دهد چه ویژگی هایی و چگونه آنها را به سبک ترجمه کنید.

انتشار برنامه

پس از اینکه طراحان یک جزء جدید را ترسیم کردند یا یک جزء موجود را دوباره طراحی کردند، این تغییرات به سیستم طراحی وارد می شود. توسعه دهندگان هر پلتفرم در حال تنظیم دقیق تولید کد خود برای پشتیبانی از تغییرات هستند. پس از این، می توان از آن در اجرای عملکرد جدید در جایی که به این کامپوننت نیاز است استفاده کرد. بنابراین، تعامل با سیستم طراحی در زمان واقعی رخ نمی دهد، بلکه فقط در زمان مونتاژ نسخه های جدید رخ می دهد. این رویکرد همچنین امکان کنترل بهتر بر فرآیند انتقال داده را فراهم می کند و عملکرد کد را در پروژه های توسعه مشتری تضمین می کند.

نمایش نتایج: از

یک سال از زمانی که سیستم طراحی به بخشی از زیرساخت حمایت از توسعه سینمای آنلاین Ivy تبدیل شده می‌گذرد، و ما می‌توانیم در حال حاضر برخی از نتایج را بگیریم:

• این یک پروژه بزرگ و پیچیده است که نیاز به منابع اختصاصی ثابت دارد.
• این به ما اجازه داد تا زبان بصری بین پلتفرمی منحصر به فرد خود را ایجاد کنیم که اهداف سرویس ویدیوی آنلاین را برآورده می کند.
• ما دیگر پلتفرم های عقب مانده بصری و عملکردی نداریم.

پیش نمایش اجزای سیستم طراحی Ivy - design.ivi.ru

منبع: www.habr.com