د UI-کټ څخه ډیزاین سیسټم ته

Ivy آنلاین سینما تجربه

کله چې د 2017 په پیل کې موږ لومړی د خپل ډیزاین څخه د کوډ تحویلي سیسټم رامینځته کولو په اړه فکر وکړ ، ډیری دمخه یې په اړه خبرې کولې او ځینې یې حتی دا ترسره کول. په هرصورت، تر نن ورځې پورې د کراس پلیټ فارم ډیزاین سیسټمونو جوړولو تجربې په اړه لږ څه پیژندل شوي، او هیڅ روښانه او ثابت شوي ترکیبونه شتون نلري چې ټیکنالوژي او میتودونه تشریح کړي چې د ډیزاین پلي کولو پروسې دا ډول بدلون په مخکې کاري محصول کې. او د "کوډ کې اجزاو" لخوا دوی ډیری وختونه خورا مختلف شیان معنی لري.

په ورته وخت کې، شرکت په کال کې خپل کارمندان دوه چنده کړي - دا اړینه وه چې د ډیزاین ډیپارټمنټ اندازه کړي او د پراختیا لپاره د ترتیبونو رامینځته کولو او لیږد پروسې اصلاح کړي. موږ دا ټول د پلیټ فارمونو "ژوبڼ" لخوا ضرب کوو چې ملاتړ ته اړتیا لري، او موږ د بابلیون پانډمونیم بیلګه ترلاسه کوو، کوم چې په ساده ډول د دې توان نلري چې "دا په نورمال ډول ترسره کړي" او عاید تولید کړي. د پلیټ فارمونو پراختیا اکثرا په موازي ډول پرمخ ځي، او ورته فعالیت په مختلفو پلیټ فارمونو کې د څو میاشتو ځنډ سره خوشې کیدی شي.


د هر پلیټ فارم لپاره جلا ترتیب سیټونه

په دودیز ډول، موږ له ستونزو سره پیل وکړ چې د ډیزاین سیسټم به د دې ډیزاین لپاره اړتیاوې حل او چمتو کولو کې مرسته وکړي. د یو متحد بصری ژبې رامینځته کولو سربیره، د ترتیب او پراختیا سرعت زیاتول، او په ټولیز ډول د محصول کیفیت ښه کول، دا اړینه وه چې ډیزاین د امکان تر حده متحد شي. دا اړینه ده چې د فعالیت پراختیا زموږ په ټولو پلیټ فارمونو کې په ورته وخت کې ممکنه شي: ویب، iOS، Android، سمارټ تلویزیون، tvOS، Android تلویزیون، وینډوز 10، xBox One، PS4، Roku - پرته له دې چې هر یو په جلا توګه کار وکړي. او موږ یې وکړل!

ډیزاین → ډاټا

کله چې د محصول او پراختیا څانګو ترمنځ بنسټیز تړونونه پای ته ورسیدل، موږ د ټیکنالوژۍ سټیک غوره کولو لپاره ناست یو او د ټولې پروسې توضیحات کار کوو - له ترتیب څخه خوشې کولو پورې. پراختیا ته د ډیزاین لیږد پروسې په بشپړ ډول اتومات کولو لپاره ، موږ د ترتیب سره د سکیچ فایلونو څخه مستقیم د اجزاو پیرامیټونو پارس کولو اختیار وپلټئ. دا معلومه شوه چې د کوډ ټوټې موندل چې موږ ورته اړتیا درلوده او د پیرامیټونو استخراج چې موږ ورته اړتیا درلوده یو پیچلي او خطرناک کار و. لومړی، ډیزاینران باید د سرچینې کوډ د ټولو پرتونو په نومولو کې خورا محتاط وي، دویم، دا یوازې د ساده اجزاوو لپاره کار کوي، او دریم، د بل چا په ټیکنالوژۍ پورې تړلی او د اصلي سکیچ ترتیب د کوډ جوړښت ټول راتلونکی له خطر سره مخامخ کوي. پروژه موږ پریکړه وکړه چې پدې سیمه کې اتوماتیک پریږدو. په دې توګه لومړی کس د ډیزاین سیسټم ټیم کې راڅرګند شو، د هغه ان پټ د ډیزاین ترتیبونه دي، او محصول هغه معلومات دي چې د اجزاوو ټول پیرامیټونه بیانوي او په ترتیب سره د اټومي ډیزاین میتودولوژي سره سم ترتیب شوي.

یوازینی شی چې باید ترسره شي دا وه چې چیرته او څنګه ډیټا ذخیره کړو، دا څنګه پراختیا ته انتقال کړو او څنګه یې په ټولو پلیټ فارمونو کې چې موږ یې ملاتړ کوو په پراختیا کې تشریح کړو. ماښام ناوخته پای ته ورسیده ... د کاري ګروپ د منظمو غونډو پایله چې ډیزاینران او د هر پلیټ فارم څخه ټیم رهبران پکې شامل وو په لاندې ډول موافقه وه.

موږ په لاسي ډول بصري په اټومي عناصرو کې تجزیه کوو: فونټونه، رنګونه، روڼتیا، شاخصونه، ګردي، شبیهونه، انځورونه او د متحرکاتو لپاره موده. او موږ له دې بټونو، ان پټونو، چک بکسونو، د بانک کارت ویجټونه او نور راټولوو. موږ د هرې کچې سټایلونو ته غیر سیمانټیک نومونه ورکوو، پرته له شبیهونو، د بیلګې په توګه، د ښارونو نومونه، د نیمفس نومونه، پوکیمون، موټر. برانڈونه ... یوازې یو شرط دی - لیست باید مخکې له مخکې ختم نشي، سټایلونه څنګه پای ته رسیږي - شو باید لاړ شي! تاسو باید د سیمانټیکونو سره لرې نه شئ، نو تاسو اړتیا نلرئ د مثال په توګه د "کوچني" او "متوسط ​​​​" تر منځ منځنۍ تڼۍ اضافه کړئ.

بصری ژبه

پراختیا کونکي د دې په اړه فکر کولو ته پاتې شوي چې څنګه ډیټا ذخیره او لیږد په داسې طریقه وکړي چې ټول پلیټ فارمونه مناسب وي ، او ډیزاین باید د انٹرفیس عناصر ډیزاین کړي چې کولی شي ښه ښکاري او د ملاتړ شوي وسیلو په ټوله بیړۍ کې مؤثره کار وکړي.

مخکې، موږ دمخه د وینډوز 10 لپاره په غوښتنلیک کې ډیری ډیزاین عناصر "ازموینه" کړې وه، کوم چې په هغه وخت کې زموږ لپاره یو نوی پلیټ فارم و، دا دی، دا د "له پیل څخه" وړاندې کولو او پراختیا ته اړتیا لري. د دې په رسم کولو سره، موږ وکولی شو ډیری برخې چمتو او ازموینه وکړو او پوه شو چې کوم یو باید په راتلونکي Eevee ډیزاین سیسټم کې شامل شي. د داسې سینڈ باکس پرته، دا ډول تجربه یوازې د پخوا په کاري پلیټ فارمونو کې د ډیری تکرارونو له لارې ترلاسه کیدی شي، او دا به له یو کال څخه ډیر وخت ونیسي.

په مختلف پلیټ فارمونو کې د ورته اجزاو بیا کارول د ډیزاین سیسټم د ترتیبونو شمیر او د ډیټا لړۍ د پام وړ کموي ، نو ډیزاین باید یوه بله ستونزه حل کړي ، چې دمخه د محصول ډیزاین او پراختیا په عملونو کې ندي بیان شوي - څنګه ، د مثال په توګه ، ایا د تلیفونونو او ټابلیټونو لپاره تڼۍ په تلویزیونونو کې بیا کارول کیدی شي؟ او موږ باید په داسې مختلف پلیټ فارمونو کې د فونټونو او عناصرو اندازو سره څه وکړو؟

په ښکاره ډول، دا اړینه وه چې د کراس پلیټ فارم ماډلر گرډ ډیزاین کړي چې د متن او عنصر اندازې تنظیم کړي چې موږ د هر ځانګړي پلیټ فارم لپاره ورته اړتیا لرو. د ګریډ لپاره د پیل ټکي په توګه، موږ د فلم پوسټرونو اندازه او شمیره غوره کړه چې موږ غواړو په یوه ځانګړي سکرین کې وګورو او د دې پر بنسټ، موږ د گرډ کالمونو جوړولو لپاره یو قاعده جوړه کړه، په دې شرط چې د یو کالم عرض مساوي وي. د پوسټر عرض ته.

اوس موږ اړتیا لرو چې ټول لوی سکرینونه ورته ترتیب اندازې ته راوړو او په یو عام گرډ کې یې فټ کړو. د ایپل تلویزیون او روکو د 1920x1080 په اندازې کې ډیزاین شوي، د Android تلویزیون - 960x540، سمارټ تلویزیونونه، د پلورونکي پورې اړه لري، ورته دي، مګر ځینې وختونه 1280x720. کله چې اپلیکیشن وړاندې کیږي او په بشپړ HD سکرینونو کې ښودل کیږي، 960 په 2 سره ضرب کیږي، 1280 په 1,33 سره ضرب کیږي، او 1920 تولید دی لکه څنګه چې دی.

د ستړي کونکي توضیحاتو پریښودو سره ، موږ دې پایلې ته ورسیدو چې په عمومي ډول ټول سکرینونه ، په شمول د تلویزیون سکرینونه ، د عناصرو او د دوی اندازې له مخې د یو ډیزاین ترتیب لخوا پوښل شوي ، او ټول تلویزیون سکرینونه د عمومي کراس پلیټ فارم گرډ ځانګړې قضیه ده ، او پنځه یا شپږ کالمونه لري، لکه د اوسط ټابلیټ یا ډیسټاپ. څوک چې د توضیحاتو سره علاقه لري ، په نظرونو کې لاړشئ.

د ټولو پلیټ فارمونو لپاره واحد UI

اوس، د نوي فیچر رسمولو لپاره، موږ اړتیا نلرو د هر پلیټ فارم لپاره ترتیبونه رسم کړو، او د هر یو لپاره د تطبیق اختیارونه. دا کافي ده چې یو ترتیب او د هر ډول پلیټ فارمونو او وسیلو لپاره د هغې تطبیق وړتیا وښیې: تلیفونونه - 320-599، نور هرڅه - 600-1280.

ډاټا → پراختیا

البته، څومره چې موږ غواړو یو بشپړ متحد ډیزاین ترلاسه کړو، هر پلیټ فارم خپل ځانګړي ځانګړتیاوې لري. که څه هم دواړه ویب او سمارټ تلویزیون د ReactJS + TypeScript سټیک کاروي، د سمارټ تلویزیون ایپ په میراثي ویب کیټ او پریسټو پیرودونکو چلیږي او له همدې امله نشي کولی د ویب سره سټایلونه شریک کړي. او د بریښنالیک خبر لیکونه په بشپړ ډول مجبور دي چې د جدول ترتیب سره کار وکړي. په ورته وخت کې ، هیڅ یو غیر html پلیټ فارمونه د عکس العمل اصلي یا د دې کوم انالوګ کارولو یا کارولو پلان نلري ، د فعالیت له خرابیدو ویره لري ، ځکه چې موږ ډیری دودیز ترتیبونه لرو ، د پیچلي تازه منطق ، عکسونو او ویډیوګانو سره راټولونه. له همدې امله، د چمتو شوي CSS سټایلونو یا عکس العمل اجزاو وړاندې کولو عام سکیم زموږ لپاره مناسب ندي. له همدې امله، موږ پریکړه وکړه چې معلومات د 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

د توضیحاتو اعالمیه هم پدې معنی ده چې که چیرې پلیټ فارم تخنیکي پلوه ملکیت یا ارزښت ونه کاروي ، نو دا کولی شي له پامه غورځوي. د اصطلاحاتو په شرایطو کې، موږ یو ډول اسپرانتو ژبه جوړه کړه: ځینې یې د Android څخه اخیستل شوي، ځینې یې د SVG څخه، ځینې یې د CSS څخه.

که په یو ځانګړي پلیټ فارم کې تاسو اړتیا لرئ عناصر په مختلف ډول وښایئ، موږ د جلا JSON فایل په بڼه د اړونده ډیټا تولید لیږدولو وړتیا پلي کړې. د مثال په توګه ، د سمارټ تلویزیون لپاره د "تمرکز" حالت د پوسټر لاندې د متن موقعیت کې بدلون امر کوي ، پدې معنی چې د دې پلیټ فارم لپاره دا برخه د "انډینټ" ملکیت ارزښت کې به د 8 انډیټیشن ټکي ولري چې ورته اړتیا لري. که څه هم دا د ډیزاین سیسټم زیربنا پیچلې کوي، دا د آزادۍ اضافي درجې راکوي، موږ ته فرصت راکوي چې پخپله د پلیټ فارمونو بصری "متفاوت" اداره کړو، او هغه جوړښت ته یرغمل نه شو چې موږ جوړ کړی.

انځورګري

په ډیجیټل محصول کې عکس العمل تل یو لوی وي او نه ساده فرعي پروژه ، ډیری وختونه جلا ډیزاینر ته اړتیا لري. دلته تل ډیری ګلیفونه شتون لري، هر یو یې ډیری اندازې او رنګونه لري، او پلیټ فارمونه معمولا په مختلفو بڼو کې ورته اړتیا لري. په عموم کې، هیڅ دلیل شتون نلري چې دا ټول د ډیزاین سیسټم کې واچوي.

ګلیفونه د SVG ویکتور بڼه کې بار شوي، او د رنګ ارزښتونه په اتوماتيک ډول د متغیرونو سره بدل شوي. د پیرودونکي غوښتنلیکونه کولی شي دوی د کارولو لپاره چمتو کړي - په هر شکل او رنګ کې.

مخکتنه

د JSON ډیټا په سر کې ، موږ د اجزاو لیدو لپاره یوه وسیله لیکلې - د JS غوښتنلیک چې د JSON ډیټا په الوتنه کې د دې مارک اپ او سټایل جنریټرونو له لارې تیریږي ، او په براوزر کې د هرې برخې مختلف تغیرات ښیې. په لازمي ډول ، مخکتنه د پلیټ فارم غوښتنلیکونو په څیر ورته مراجعه ده او د ورته معلوماتو سره کار کوي.

د دې پوهیدلو لپاره ترټولو اسانه لار چې یوه ځانګړې برخه څنګه کار کوي د هغې سره متقابل عمل دی. له همدې امله، موږ د Storybook په څیر وسیلې نه کاروو، مګر یو متقابل مخکتنه جوړه کړه - تاسو کولی شئ لمس، اشاره وکړئ، کلیک وکړئ ... کله چې د ډیزاین سیسټم کې نوې برخې اضافه کړئ، دا په مخکتنه کې ښکاري ترڅو پلیټ فارمونه د تمرکز کولو لپاره یو څه ولري کله چې پلي کول.

لاسوند

د JSON په بڼه پلیټ فارمونو ته چمتو شوي معلوماتو پراساس، د اجزاوو لپاره اسناد په اوتومات ډول تولید کیږي. د ملکیتونو لیست او په هر یو کې د ارزښتونو احتمالي ډولونه تشریح شوي. د اتوماتیک نسل وروسته، معلومات په لاسي ډول روښانه کیدی شي او د متن توضیحات اضافه کیدی شي. مخکتنه او اسناد د هرې برخې په کچه یو بل ته کراس حواله شوي، او ټول معلومات چې په اسنادو کې شامل دي د اضافي JSON فایلونو په بڼه پراختیا کونکو ته شتون لري.

سپکاوی کوونکی

بله اړتیا د وخت په تیریدو سره د موجوده برخو بدلولو او تازه کولو وړتیا وه. د ډیزاین سیسټم دا زده کړل چې پراختیا کونکو ته ووایی چې کوم ملکیتونه یا حتی ټولې برخې نشي کارول کیدی او ژر تر ژره یې لرې کړي ځکه چې دوی نور په ټولو پلیټ فارمونو کې نه کارول کیږي. په دې پروسه کې لاهم ډیر "لاسي" کار شتون لري، مګر موږ لاهم ولاړ نه یو.

د پیرودونکي پراختیا

بې له شکه، ترټولو پیچلې مرحله د ټولو پلیټ فارمونو په کوډ کې د ډیزاین سیسټم ډیټا تفسیر و چې موږ یې ملاتړ کوو. که ، د مثال په توګه ، په ویب کې ماډلر ګریډونه څه نوي ندي ، نو بیا د iOS او Android لپاره د اصلي ګرځنده غوښتنلیکونو پراختیا کونکو دمخه سخت کار کړی مخکې لدې چې دوی پوه شي چې څنګه ورسره ژوند وکړي.

د iOS اپلیکیشن سکرینونو ترتیب کولو لپاره، موږ د iviUIKit لخوا چمتو شوي دوه اساسي میکانیزمونه کاروو: د عناصرو وړیا ترتیب او د عناصرو راټولولو ترتیب. موږ VIPER کاروو، او د iviUIKit سره ټول تعامل په لید کې متمرکز دی، او د Apple UIKit سره ډیری تعامل په iviUIKit کې متمرکز دی. د عناصرو اندازې او ترتیب د کالمونو او ترکیب جوړښتونو شرایطو کې مشخص شوي چې د اصلي iOS SDK محدودیتونو په سر کې کار کوي ، دوی ډیر عملي کوي. دا په ځانګړي توګه زموږ ژوند ساده کوي کله چې د UICollectionView سره کار کوي. موږ د ترتیب لپاره ډیری دودیز ریپرونه لیکلي دي ، پشمول خورا پیچلي. لږترلږه د پیرودونکي کوډ شتون درلود او دا اعلاناتي شو.

د Android پروژې کې د سټایلونو رامینځته کولو لپاره ، موږ ګرډل کاروو ، د ډیزاین سیسټم ډیټا په XML ب formatه سټایلونو ته واړوو. په ورته وخت کې، موږ د مختلفو کچو ډیری جنراتورونه لرو:

• بنسټیز. د لوړې کچې جنراتورونو لپاره د ابتدايي معلوماتو ډاټا تجزیه کیږي.
• سرچینه. انځورونه، شبیه او نور ګرافیک ډاونلوډ کړئ.
• اجزا. دوی د هرې برخې لپاره لیکل شوي، کوم چې تشریح کوي کوم ملکیتونه او څنګه یې په سټایلونو کې وژباړي.

د غوښتنلیک خپرول

وروسته له دې چې ډیزاینرانو یوه نوې برخه جوړه کړه یا موجوده یو له سره ډیزاین کړ، دا بدلونونه د ډیزاین سیسټم ته تغذیه کیږي. د هر پلیټ فارم پراختیا کونکي د بدلونونو ملاتړ کولو لپاره د دوی کوډ نسل ښه تنظیموي. له دې وروسته ، دا د نوي فعالیت پلي کولو کې کارول کیدی شي چیرې چې دې برخې ته اړتیا وي. پدې توګه ، د ډیزاین سیسټم سره تعامل په ریښتیني وخت کې نه پیښیږي ، مګر یوازې د نوي ریلیزونو راټولولو په وخت کې. دا طریقه د ډیټا لیږد پروسې ښه کنټرول ته هم اجازه ورکوي او د پیرودونکي پراختیایي پروژو کې د کوډ فعالیت تضمینوي.

پایلې

دا یو کال دی چې د ډیزاین سیسټم د زیربنا برخه شوه چې د Ivy آنلاین سینما پراختیا ملاتړ کوي، او موږ دمخه ځینې پایلې ترلاسه کولی شو:

• دا یوه لویه او پیچلې پروژه ده چې دوامداره وقف سرچینو ته اړتیا لري.
• دې موږ ته اجازه راکړه چې خپله ځانګړې کراس پلیټ فارم بصري ژبه رامینځته کړو چې د آنلاین ویډیو خدماتو اهداف پوره کوي.
• موږ نور د لید او فعال پلوه وروسته پاتې پلیټ فارمونه نلرو.

د Ivy ډیزاین سیسټم اجزاو کتنه - design.ivi.ru

سرچینه: www.habr.com