จาก UI-kit ไปจนถึงระบบการออกแบบ

ประสบการณ์การชมภาพยนตร์ออนไลน์ของ Ivy

เมื่อต้นปี 2017 เราคิดครั้งแรกเกี่ยวกับการสร้างระบบการนำส่งแบบ Design-to-Code ของตัวเอง หลายคนพูดถึงเรื่องนี้แล้ว และบางคนถึงกับทำมันเลย อย่างไรก็ตาม จนถึงทุกวันนี้ ยังไม่ค่อยมีใครรู้เกี่ยวกับประสบการณ์ในการสร้างระบบการออกแบบข้ามแพลตฟอร์ม และไม่มีสูตรที่ชัดเจนและผ่านการพิสูจน์แล้วที่อธิบายเทคโนโลยีและวิธีการในการเปลี่ยนแปลงกระบวนการดำเนินการออกแบบให้เป็นผลิตภัณฑ์ที่ใช้งานได้อยู่แล้ว และ "ส่วนประกอบในโค้ด" มักจะหมายถึงสิ่งที่แตกต่างกันมาก

ในขณะเดียวกัน บริษัทก็เพิ่มจำนวนพนักงานเป็นสองเท่าทุกปี - จำเป็นต้องปรับขนาดแผนกออกแบบและปรับกระบวนการสร้างและถ่ายโอนเค้าโครงเพื่อการพัฒนาให้เหมาะสม เราคูณทั้งหมดนี้ด้วย "สวนสัตว์" ของแพลตฟอร์มที่ต้องได้รับการสนับสนุน และเราได้รับความคล้ายคลึงกับความโกลาหลของชาวบาบิโลน ซึ่งไม่สามารถ "ทำตามปกติ" และสร้างรายได้ได้ การพัฒนาแพลตฟอร์มมักจะดำเนินไปพร้อมๆ กัน และฟังก์ชันเดียวกันนี้สามารถเผยแพร่บนแพลตฟอร์มต่างๆ ได้โดยใช้เวลาหลายเดือน


ชุดเค้าโครงแยกกันสำหรับแต่ละแพลตฟอร์ม

ตามเนื้อผ้า เราเริ่มต้นด้วยปัญหาที่ระบบการออกแบบจะช่วยแก้ไขและกำหนดข้อกำหนดสำหรับการออกแบบ นอกเหนือจากการสร้างภาษาภาพที่เป็นหนึ่งเดียว การเพิ่มความเร็วของเค้าโครงและการพัฒนา และปรับปรุงคุณภาพของผลิตภัณฑ์โดยรวมแล้ว สิ่งสำคัญคือต้องรวมการออกแบบให้มากที่สุดเท่าที่จะเป็นไปได้ นี่เป็นสิ่งจำเป็นเพื่อให้การพัฒนาฟังก์ชันการทำงานเป็นไปได้บนทุกแพลตฟอร์มของเราพร้อมกัน: เว็บ, iOS, Android, สมาร์ททีวี, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - โดยไม่ต้องทำงานแยกกัน . และเราก็ทำได้!

การออกแบบ → ข้อมูล

เมื่อบรรลุข้อตกลงพื้นฐานระหว่างแผนกผลิตภัณฑ์และฝ่ายพัฒนาแล้ว เราก็นั่งลงเพื่อเลือกกลุ่มเทคโนโลยีและหารายละเอียดของกระบวนการทั้งหมด - ตั้งแต่เค้าโครงไปจนถึงการเปิดตัว เพื่อให้กระบวนการถ่ายโอนการออกแบบไปยังการพัฒนาเป็นไปโดยอัตโนมัติอย่างสมบูรณ์ เราได้สำรวจตัวเลือกในการแยกวิเคราะห์พารามิเตอร์ส่วนประกอบโดยตรงจากไฟล์ Sketch ด้วยเลย์เอาต์ ปรากฎว่าการค้นหาชิ้นส่วนของโค้ดที่เราต้องการและการแยกพารามิเตอร์ที่เราต้องการนั้นเป็นการดำเนินการที่ซับซ้อนและอันตราย ประการแรก นักออกแบบจะต้องระมัดระวังอย่างยิ่งในการตั้งชื่อทุกเลเยอร์ของซอร์สโค้ด ประการที่สอง สิ่งนี้ใช้ได้กับส่วนประกอบที่ง่ายที่สุดเท่านั้น และประการที่สาม การพึ่งพาเทคโนโลยีของผู้อื่นและโครงสร้างโค้ดของเค้าโครง Sketch ดั้งเดิมจะเป็นอันตรายต่ออนาคตของทั้ง โครงการ. เราตัดสินใจละทิ้งระบบอัตโนมัติในพื้นที่นี้ นี่คือลักษณะที่บุคคลแรกที่ปรากฏในทีมระบบการออกแบบ ซึ่งอินพุตคือเลย์เอาต์การออกแบบ และเอาต์พุตคือข้อมูลที่อธิบายพารามิเตอร์ทั้งหมดของส่วนประกอบและเรียงลำดับตามลำดับชั้นตามวิธีการออกแบบอะตอมมิก

สิ่งเดียวที่ต้องทำคือจะจัดเก็บข้อมูลที่ไหนและอย่างไร วิธีถ่ายโอนข้อมูลไปยังการพัฒนา และวิธีตีความข้อมูลในการพัฒนาบนแพลตฟอร์มทั้งหมดที่เราสนับสนุน ตอนเย็นไม่อิดโรย... ผลการประชุมเป็นประจำของคณะทำงานซึ่งประกอบด้วยนักออกแบบและหัวหน้าทีมจากแต่ละแพลตฟอร์มมีข้อตกลงดังต่อไปนี้

เราแยกวิเคราะห์ภาพเป็นองค์ประกอบอะตอมมิกด้วยตนเอง: แบบอักษร สี ความโปร่งใส การเยื้อง การปัดเศษ ไอคอน รูปภาพ และระยะเวลาสำหรับภาพเคลื่อนไหว และเรารวบรวมจากปุ่ม อินพุต ช่องทำเครื่องหมาย วิดเจ็ตบัตรธนาคาร ฯลฯ เรากำหนดชื่อที่ไม่มีความหมายให้กับสไตล์ของระดับใด ๆ ยกเว้นไอคอน เช่น ชื่อเมือง ชื่อนางไม้ โปเกมอน รถยนต์ แบรนด์... มีเงื่อนไขเดียวเท่านั้น - รายการไม่ควรหมดก่อน สไตล์สิ้นสุดอย่างไร - โชว์ต้องไป! คุณไม่ควรหลงไปกับความหมาย เพื่อที่คุณจะได้ไม่ต้องเพิ่มปุ่มตรงกลางระหว่าง “เล็ก” และ “กลาง” เป็นต้น

ภาษาภาพ

นักพัฒนายังต้องคิดถึงวิธีจัดเก็บและถ่ายโอนข้อมูลในลักษณะที่เหมาะกับทุกแพลตฟอร์ม และการออกแบบก็ต้องออกแบบองค์ประกอบอินเทอร์เฟซที่อาจดูดีและทำงานได้อย่างมีประสิทธิภาพทั่วทั้งกลุ่มอุปกรณ์ที่รองรับ

ก่อนหน้านี้ เราได้จัดการ "ทดสอบ" องค์ประกอบการออกแบบส่วนใหญ่ในแอปพลิเคชันสำหรับ Windows 10 แล้ว ซึ่งในเวลานั้นเป็นแพลตฟอร์มใหม่สำหรับเรา กล่าวคือ จำเป็นต้องมีการเรนเดอร์และการพัฒนา "ตั้งแต่เริ่มต้น" ด้วยการวาดภาพ เราสามารถเตรียมและทดสอบส่วนประกอบส่วนใหญ่ และทำความเข้าใจว่าส่วนประกอบใดควรจะรวมไว้ในระบบการออกแบบของ Eevee ในอนาคต หากไม่มีแซนด์บ็อกซ์ ประสบการณ์ดังกล่าวจะเกิดขึ้นได้ผ่านการทำซ้ำจำนวนมากบนแพลตฟอร์มที่ใช้งานได้อยู่แล้วเท่านั้น และการดำเนินการนี้อาจใช้เวลานานกว่าหนึ่งปี

การใช้ส่วนประกอบเดียวกันซ้ำบนแพลตฟอร์มที่แตกต่างกันจะช่วยลดจำนวนเลย์เอาต์และอาร์เรย์ข้อมูลของระบบการออกแบบได้หลายครั้ง ดังนั้นการออกแบบจึงต้องแก้ไขปัญหาอีกหนึ่งปัญหา ซึ่งก่อนหน้านี้ไม่ได้อธิบายไว้ในแนวทางปฏิบัติของการออกแบบและพัฒนาผลิตภัณฑ์ - อย่างไร สำหรับ เช่น ปุ่มสำหรับโทรศัพท์และแท็บเล็ตสามารถนำกลับมาใช้ซ้ำบนทีวีได้หรือไม่ และเราควรทำอย่างไรกับขนาดของฟอนต์และองค์ประกอบบนแพลตฟอร์มต่างๆ ดังกล่าว?

แน่นอนว่าจำเป็นต้องออกแบบตารางโมดูลาร์ข้ามแพลตฟอร์มที่จะกำหนดขนาดข้อความและองค์ประกอบที่เราต้องการสำหรับแต่ละแพลตฟอร์ม เพื่อเป็นจุดเริ่มต้นสำหรับตาราง เราเลือกขนาดและจำนวนโปสเตอร์ภาพยนตร์ที่เราต้องการเห็นบนหน้าจอใดหน้าจอหนึ่ง และด้วยเหตุนี้ เราได้กำหนดกฎสำหรับการสร้างคอลัมน์ตาราง โดยมีเงื่อนไขว่าความกว้างของหนึ่งคอลัมน์จะเท่ากัน ตามความกว้างของโปสเตอร์

ตอนนี้เราจำเป็นต้องทำให้หน้าจอขนาดใหญ่ทั้งหมดมีขนาดเค้าโครงเดียวกันและจัดวางลงในตารางทั่วไป Apple TV และ Roku ได้รับการออกแบบในขนาด 1920x1080, Android TV - 960x540, Smart TV ขึ้นอยู่กับผู้จำหน่ายจะเหมือนกัน แต่บางครั้งก็ 1280x720 เมื่อแอปแสดงผลและแสดงบนหน้าจอ Full HD 960 จะถูกคูณด้วย 2, 1280 จะถูกคูณด้วย 1,33 และ 1920 จะถูกส่งออกตามที่เป็นอยู่

ข้ามรายละเอียดที่น่าเบื่อ เราได้ข้อสรุปว่าโดยทั่วไปแล้วหน้าจอทั้งหมด รวมถึงหน้าจอโทรทัศน์ ในแง่ขององค์ประกอบและขนาด ครอบคลุมอยู่ในรูปแบบการออกแบบเดียว และหน้าจอโทรทัศน์ทั้งหมดเป็นกรณีพิเศษของตารางข้ามแพลตฟอร์มทั่วไป และประกอบด้วยห้าหรือหกคอลัมน์ เช่นเดียวกับแท็บเล็ตหรือเดสก์ท็อปทั่วไป ใครสนใจรายละเอียดเข้าไปที่คอมเมนต์ได้เลย

UI เดียวสำหรับทุกแพลตฟอร์ม

ตอนนี้ เพื่อวาดฟีเจอร์ใหม่ เราไม่จำเป็นต้องวาดเลย์เอาต์สำหรับแต่ละแพลตฟอร์ม รวมถึงตัวเลือกความสามารถในการปรับเปลี่ยนสำหรับแต่ละแพลตฟอร์มด้วย การแสดงเค้าโครงเดียวและความสามารถในการปรับตัวสำหรับทุกแพลตฟอร์มและอุปกรณ์ทุกความกว้างก็เพียงพอแล้ว: โทรศัพท์ - 320-599 ทุกอย่างอื่น - 600-1280

ข้อมูล → การพัฒนา

แน่นอนว่า แม้ว่าเราต้องการบรรลุการออกแบบที่เป็นหนึ่งเดียวอย่างสมบูรณ์ แต่ละแพลตฟอร์มก็มีคุณสมบัติที่เป็นเอกลักษณ์ของตัวเอง แม้ว่าทั้งเว็บและ Smart TV จะใช้สแต็ก 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 แยกต่างหาก ตัวอย่างเช่น สถานะ "อยู่ในโฟกัส" สำหรับสมาร์ททีวีจะกำหนดการเปลี่ยนแปลงตำแหน่งของข้อความใต้โปสเตอร์ ซึ่งหมายความว่าสำหรับแพลตฟอร์มนี้ ส่วนประกอบนี้ในค่าของคุณสมบัติ "เยื้อง" จะมีจุดเยื้อง 8 จุดที่ต้องการ แม้ว่าสิ่งนี้จะทำให้โครงสร้างพื้นฐานของระบบการออกแบบมีความซับซ้อน แต่ก็ให้ระดับความอิสระเพิ่มเติม ทำให้เรามีโอกาสจัดการ "ความแตกต่าง" ที่มองเห็นได้ของแพลตฟอร์มด้วยตัวเราเอง และไม่ต้องเป็นตัวประกันกับสถาปัตยกรรมที่เราสร้างขึ้น

รูปสัญลักษณ์

การยึดถือในผลิตภัณฑ์ดิจิทัลนั้นเป็นโครงการขนาดใหญ่เสมอและไม่ใช่โครงการย่อยที่ง่ายที่สุด ซึ่งมักต้องใช้นักออกแบบแยกต่างหาก มีร่ายมนตร์อยู่มากมาย แต่ละอันมีหลายขนาดและสี และแพลตฟอร์มมักจะต้องการมันในรูปแบบที่แตกต่างกัน โดยทั่วไปไม่มีเหตุผลที่จะไม่ใส่ทั้งหมดนี้ลงในระบบการออกแบบ

สัญลักษณ์ถูกโหลดในรูปแบบเวกเตอร์ SVG และค่าสีจะถูกแทนที่ด้วยตัวแปรโดยอัตโนมัติ แอปพลิเคชันไคลเอนต์สามารถรับแอปพลิเคชันเหล่านั้นพร้อมใช้งาน - ในรูปแบบและสีใดก็ได้

เปรดพรอสโมเตอร์

นอกเหนือจากข้อมูล JSON แล้ว เรายังเขียนเครื่องมือสำหรับการดูตัวอย่างส่วนประกอบ ซึ่งเป็นแอปพลิเคชัน JS ที่ส่งข้อมูล JSON ได้ทันทีผ่านตัวสร้างมาร์กอัปและสไตล์ และแสดงรูปแบบต่างๆ ของแต่ละองค์ประกอบในเบราว์เซอร์ โดยพื้นฐานแล้ว การแสดงตัวอย่างจะเป็นไคลเอนต์เดียวกันกับแอปพลิเคชันแพลตฟอร์มและทำงานกับข้อมูลเดียวกันทุกประการ

วิธีที่ง่ายที่สุดในการทำความเข้าใจวิธีการทำงานของส่วนประกอบเฉพาะคือการโต้ตอบกับส่วนประกอบนั้น ดังนั้นเราจึงไม่ได้ใช้เครื่องมือเช่น Storybook แต่สร้างการแสดงตัวอย่างแบบอินเทอร์แอคทีฟ - คุณสามารถสัมผัส ชี้ คลิก... เมื่อเพิ่มส่วนประกอบใหม่ให้กับระบบการออกแบบ จะปรากฏในหน้าตัวอย่างเพื่อให้แพลตฟอร์มมีบางสิ่งที่ต้องเน้นเมื่อใด ดำเนินการมัน

เอกสาร

จากข้อมูลที่ให้กับแพลตฟอร์มในรูปแบบของ JSON เอกสารสำหรับส่วนประกอบจะถูกสร้างขึ้นโดยอัตโนมัติ มีการอธิบายรายการคุณสมบัติและประเภทค่าที่เป็นไปได้ในแต่ละรายการ หลังจากการสร้างอัตโนมัติ คุณสามารถชี้แจงข้อมูลได้ด้วยตนเองและสามารถเพิ่มคำอธิบายข้อความได้ การแสดงตัวอย่างและเอกสารประกอบมีการอ้างอิงโยงถึงกันในระดับของแต่ละองค์ประกอบ และข้อมูลทั้งหมดที่รวมอยู่ในเอกสารประกอบจะพร้อมใช้งานสำหรับนักพัฒนาในรูปแบบของไฟล์ JSON เพิ่มเติม

ผู้คัดค้าน

ความจำเป็นอีกประการหนึ่งคือความสามารถในการเปลี่ยนและอัปเดตส่วนประกอบที่มีอยู่เมื่อเวลาผ่านไป ระบบการออกแบบได้เรียนรู้ที่จะบอกนักพัฒนาว่าคุณสมบัติใดหรือแม้แต่ส่วนประกอบทั้งหมดไม่สามารถใช้งานได้ และลบออกทันทีที่ไม่ได้ใช้บนทุกแพลตฟอร์มอีกต่อไป กระบวนการนี้ยังคงมีแรงงาน “คน” จำนวนมาก แต่เราไม่หยุดนิ่ง

การพัฒนาลูกค้า

ไม่ต้องสงสัยเลยว่าขั้นตอนที่ซับซ้อนที่สุดคือการตีความข้อมูลระบบการออกแบบในโค้ดของทุกแพลตฟอร์มที่เรารองรับ ตัวอย่างเช่น หากกริดแบบโมดูลาร์บนเว็บไม่ใช่สิ่งใหม่ นักพัฒนาแอปพลิเคชันมือถือแบบเนทีฟสำหรับ iOS และ Android ก็ทำงานหนักก่อนที่จะพบว่าจะใช้ชีวิตอย่างไรกับมัน

ในการจัดวางหน้าจอแอปพลิเคชัน iOS เราใช้กลไกพื้นฐานสองประการที่ iviUIKit มอบให้: การจัดวางองค์ประกอบฟรี และเค้าโครงของคอลเลกชันองค์ประกอบ เราใช้ VIPER และการโต้ตอบทั้งหมดกับ iviUIKit จะเน้นไปที่มุมมอง และการโต้ตอบส่วนใหญ่กับ Apple UIKit จะเน้นไปที่ iviUIKit ขนาดและการจัดเรียงองค์ประกอบจะถูกระบุในแง่ของคอลัมน์และโครงสร้างวากยสัมพันธ์ที่ทำงานอยู่เหนือข้อจำกัด iOS SDK ดั้งเดิม ทำให้องค์ประกอบเหล่านั้นใช้งานได้จริงมากขึ้น สิ่งนี้ทำให้ชีวิตของเราง่ายขึ้นโดยเฉพาะเมื่อทำงานกับ UICollectionView เราได้เขียน Wrapper แบบกำหนดเองหลายรายการสำหรับเลย์เอาต์ รวมถึงอันที่ค่อนข้างซับซ้อนด้วย มีรหัสไคลเอ็นต์ขั้นต่ำและกลายเป็นการประกาศ

ในการสร้างสไตล์ในโครงการ Android เราใช้ Gradle เพื่อเปลี่ยนข้อมูลระบบการออกแบบให้เป็นสไตล์ในรูปแบบ XML ในเวลาเดียวกัน เรามีเครื่องกำเนิดไฟฟ้าหลายระดับในระดับต่างๆ:

• ขั้นพื้นฐาน- ข้อมูลดั้งเดิมสำหรับเครื่องกำเนิดไฟฟ้าระดับสูงกว่าจะถูกแยกวิเคราะห์
• ทรัพยากร- ดาวน์โหลดภาพ ไอคอน และกราฟิกอื่นๆ
• ส่วนประกอบ- เขียนไว้สำหรับแต่ละองค์ประกอบ ซึ่งจะอธิบายคุณสมบัติและวิธีการแปลให้เป็นสไตล์

การเปิดตัวแอปพลิเคชัน

หลังจากที่ผู้ออกแบบได้วาดส่วนประกอบใหม่หรือออกแบบส่วนประกอบที่มีอยู่ใหม่ การเปลี่ยนแปลงเหล่านี้จะถูกป้อนเข้าสู่ระบบการออกแบบ นักพัฒนาของแต่ละแพลตฟอร์มกำลังปรับแต่งการสร้างโค้ดเพื่อรองรับการเปลี่ยนแปลง หลังจากนี้ จะสามารถนำไปใช้ในการใช้งานฟังก์ชันใหม่ๆ ในกรณีที่จำเป็นต้องใช้ส่วนประกอบนี้ ดังนั้นการโต้ตอบกับระบบการออกแบบจึงไม่เกิดขึ้นในแบบเรียลไทม์ แต่เกิดขึ้นเฉพาะในเวลาที่มีการรวบรวมรุ่นใหม่เท่านั้น วิธีการนี้ยังช่วยให้สามารถควบคุมกระบวนการถ่ายโอนข้อมูลได้ดีขึ้น และรับประกันการทำงานของโค้ดในโครงการพัฒนาไคลเอนต์

ผลของการ

เป็นเวลาหนึ่งปีแล้วที่ระบบการออกแบบกลายเป็นส่วนหนึ่งของโครงสร้างพื้นฐานที่รองรับการพัฒนาโรงภาพยนตร์ออนไลน์ของ Ivy และเราสามารถสรุปได้บางส่วนแล้ว:

• นี่เป็นโครงการขนาดใหญ่และซับซ้อนซึ่งต้องใช้ทรัพยากรเฉพาะอย่างต่อเนื่อง
• สิ่งนี้ทำให้เราสามารถสร้างภาษาภาพข้ามแพลตฟอร์มที่เป็นเอกลักษณ์ของเราเองซึ่งตรงตามวัตถุประสงค์ของบริการวิดีโอออนไลน์
• เราไม่มีแพลตฟอร์มที่ล้าหลังทั้งด้านการมองเห็นและการใช้งานอีกต่อไป

การแสดงตัวอย่างส่วนประกอบของระบบการออกแบบ Ivy - design.ivi.ru

ที่มา: will.com