style-guide הוא סט של סטנדרטים ועקרונות של המוצר עבור המפתחים והמעצבים. הסט מאפשר לשמור על אחידות העיצוב ולהקל על הפיתוח (ניתן לקרוא את ההגדרה המלאה בויקיפדיה). השימוש ב-style-guide איננו משהו חדש, והרבה מותגים שמכבדים את עצמם בונים סטיילגייד, כמו לדוגמה ה-style-guide של טוויטר המכיל כללים ברורים על צבע המותג, גודל האייקון ועוד.
אפשר להתרשם מעוד הרבה דוגמאות:
- 100 Brand Style Guides You Should See Before Designing Yours
- 21 Brand Style Guide Examples for Visual Inspiration
- 50 meticulous style guides
לחלק מהמותגים יש בנוסף (או -'רק') סטיילגייד עיצובי הבנוי בקוד.
יוצאת לדרך
בפרויקט חדש שאני חלק ממנו, היה חשוב לי ליצור מקום שבו יוכלו המעצבים והמתכנתים לראות את כל סוגי הצבעים שיש, את כל סוגי הכפתורים והאייקונים שקיימים באתר; מקום שבו יהיו מרוכזים הכללים המנחים ליצירת מבנה HTML סמנטי ויישום נכון של ה-css. בקיצור: style-guide.
יצאתי לדרך עם רצון מאוד ברור, הדרך הייתה דרך חתחתים, אבל בסופה הגעתי לתוצאה משביעת רצון (מבחינתי כמובן).
היות ואני על קו התפר בין עיצוב לתכנות התלבטתי לגבי אופן יישום ה-style-guide, אבל הכיוון הראשוני היה ללא ספק אחד שהוא דינמי וכתוב בקוד. עם ההחלטה הזאת יצאתי והתחלתי לחקור קצת איך עושים את זה.
קראתי הרבה מאוד פוסטים על style-guide. רובם מעניינים ומועילים מאוד, מביאה רק את אלה שהותירו בי רושם, עניין וכיוון:
- Eight Things You Need To Know About Design Systems
- Your guide to design systems from the world’s leading brands
- Creating Style Guides
- Creating A Living Style Guide: A Case Study
אחד הפוסטים שקראתי היה Style Guide VS. Live Style Guide: Differences and Approaches שדיבר על ההבדל בגישה בין style-guide חי שנמצא בתוך הקוד של הפרויקט, ובין זה שלא. נשמע לי נהדר שיהיה לנו משהו בתוך קוד ה-scss שלנו שיתקמפל איתו וייצר אוטומטית style-guide – ככה לא יהיה צורך לתחזק אותו והוא תמיד יהיה מעודכן. חלומי. עם ההבנה של מה שאני רוצה התחלתי לחפש כלים למימוש.
Living Style-guide
חזרתי לקרוא, וקראתי די הרבה על style-guide חי, ובעיקר על KSS שהיא ספרייה מבוססת רובי שמייצרת style-guide על ידי שימוש בתיעוד שנכתב בקוד הפרויקט.
- An In-Depth Overview Of Living Style Guide Tools
- Taking The Pattern Library To The Next Level
- 2 דמואים די דומים של style-guide שנוצרו בעזרת KSS, הראשון והשני
- פוסט של css-tricks שאיתו יצאתי לדרך: Build a Style Guide Straight from Sass
- במהלך העבודה אספתי עוד לינקים שימושיים לכתיבה של KSS:
- מדריך לשימוש ב: Generate Sass style guide with Grunt and KSS
- Frontend Style Guide Miniseries: Part Two: KSS Node ממליצה גם על החלק הראשון והחלק השלישי בסדרת הפוסטים הזו.
זה היה נשמע כל כך פשוט: התקנה, הגדרות והנה – יהיה לי style-guide מוכן, מבוסס על תבנית michelangelo. אבל חלומות זה משהו אחד, והמציאות שונה לגמרי…
נכנסתי לאתר הרשמי של KSS וניסיתי להתקין אותו דרך ההסבר בעמוד של ההתקנות, אבל לא נחלתי הצלחה רבה. הייתי ערוכה לקשיים בהתקנות – אחרי הכל, החלון השחור ואני לא ממש חברים (אפשר לקרוא על זה בפוסט שלי על תחילת דרכי ב-sass – ראו gif). חזרתי אל הפוסט של css-tricks ועברתי שלב שלב. הצלחתי חלק מההתקנות, חברים בעבודה עזרו לי עם המשך ההתקנות וההגדרות של ה-kss, והגעתי לשלב שבו יכולתי להתחיל להכניס תיעוד בקוד sass שלי.
לצערי, היות ולא הצלחתי לעקוב אחרי כל ההגדרות של ההתקנה אני נמנעת מלפרט איך עושים זאת. אבל את התובנות שלי של איך עובדים עם ה-kss אחלוק בשמחה.
Knyle Style Sheets – KSS – איך עושים את זה?
בגדול, ברפוזוטרי של KSS בגיטהאב יש הסברים איך לכתוב את התיעוד, וגם באתר של KSS יש עמוד של כללי כתיבה. התחלתי עם הדוגמה הנפוצה ביותר – תיעוד כפתורים. מאוד מצא חן בעייני שרואים את כל המצבים של הכפתורים (hover
, focus
וכו). אז איך כותבים את זה נכון?
לכל תיעוד יש מבנה של 3 חלקים:
חלק ראשון – כותרת:
והקוד:
// Buttons
חלק שני – המבנה הסמנטי של ה-HTML
והקוד:
//Markup: // <button class="common-button {{modifier_class}}">common-button</button> // <button class="common-button-1 {{modifier_class}}">common-button-1</button>
שימוש ב {{modifier_class}}
מאפשר כתיבה של מבנה HTML אחד, וע"י הגדרת modifier
אפשר ליצור מגוון של אפשרויות כמו מצבים של hover
או קלאסים שונים שנותנים וריאציות לכפתור. אני לא הצלחתי לשלב גם וגם (גם פסדו-קלאסים וגם קלאסים). בכלל, השימוש ב-modifier
לא זרם לי ולכן לא ארחיב עליו.
את ההגדרות ל-modifier
מציינים מתחת למבנה ה-HTML.
ניתן גם לספק הסבר על כל מצב:
// :hover - When user hovers over button. // :focus - When button is focused. // :disabled - disabled
חלק שלישי – ההרירכיה של החלק בתוך ה-style-guide
והקוד:
// Styleguide 2.1
יש משהו מוזר במיספור ובניווט הצדדי – אם נותנים ערך של 3 למשל, אז האלמנט שקיבל אותו יהיה ראשון בהיררכיה ואז נוצר מצב שיש לנו 3 ו-3.1 (כשבעצם 3 הוא לא כותרת או משהו מאגד, אלא הראשון ברשימה). אם, לעומת זאת, לא נותנים לאף אלמנט מספר ראשי, ורק מגדירים תתי מספרים (3.1, 3.2 וכך הלאה) אז יופיע המספר – 5 למשל – בתור כותרת בלי שום מלל לידו, והוא יהיה בלי תוכן.
* אפשר לתת גם היררכיה מילולית ואז היא צריכה להיות מקבילה להיררכיית התיקיות/קבצים שיש ב-scss.
הקוד השלם:
// Buttons // // A button suitable for giving stars to someone. // :hovered - Highlight the button when hovered. // :disabled - Make the button change appearance. // // Markup: // <button class="common-button {{modifier_class}}">common-button</button> // <button class="common-button-1 {{modifier_class}}">common-button-1</button> // // :hover - When user hovers over button. // :focus - When button is focused. // :disabled - disabled // // Styleguide 2.1
* הערה לגבי הקוד: היות ואני משתמשת ב-scss, כתיבת התיעוד היא בפורמט של scss, כלומר שני לוכסנים (//). ב css כותבים כמו הערות רגילות /*—*/
וככה זה נראה ב-style-guide שמיוצר בעזרת KSS:
סיימתי את התיעוד של הכפתורים ואת ההבנה של המבנה והחלטתי להמשיך הלאה. לאן? לאן שלבי רצה – הצגה של צבעים ואייקונים. כל כך רציתי פריסה יפה של הצבעים, אבל כגודל הרצון שיהיה יפה, כך גודל הסיבוכים והקשיים בדרך.
ב-scss אנחנו משתמשים במשתנים, מה שאומר שצבעים בפרויקט מוגדרים במשתנים, שאותם ה KSS לא ידע להמיר בקלות וליצור אזור של צבעים. התיעוד הרישמי של kss – גם זה שבאתר וזה שבגיטהאב – לא ממש ענה לי על השאלה, ואת הפתרון מצאתי ב-2 isuues-ים שונים: Include stylesheet source code into styleguide #50 וגם: Replace Sass variables in markup with actual values #45. שורה תחתונה – כדי להציג את הצבעים או את האייקונים נדרשתי לציין את השם שלהם שוב בהערות, מה שהפך את התיעוד בתוך קובץ ה-scss למאוד מאסיבי ולא ממש "חי", כי כל פעם שמשהו ישתנה בצבעים או באייקונים, צריך יהיה לזכור לשנות אותו גם בתיעוד. דבר נוסף לגבי האייקונים – אנחנו משתמשים בפונט-אייקון ליצירת אייקונים. מלכתחילה הפונט לא נמשך ל-style-guide והיה צריך לתת לו הגדרה נוספת כדי למשוך אותו. גם זה לא היה מספיק ברור מבחינת התיעוד.
// Colors // // #97007A - : Magenta // #424344 - : Grey // #28292A - : Dark grey // & more colors.... // // Markup:<div style="background-color:{{modifier_class}};" class="styleguide-color">{{modifier_class}}</div> // // Styleguide 1 $color--magenta: #97007A; $color--grey: #424344; $color--grey-dark: #28292A; & more colors....
ואייקונים:
// Icons // //icon-download - 1 //icon-dragndrop - 1 //icon-edit - 1 //icon-filter - 1 //icon-help - 1 //icon-search - 1 //icon-share - 1 // & more icons.... // // Markup: //<span class="{{modifier_class}}"></span> // // // Styleguide 1. $icon-download: \e906; $icon-dragndrop: \e907; $icon-arrow_back: \e908; & more icons....
KSS -שורה תחתונה
בגדול, היה נכון לכתוב פה מה כן אהבתי ומה לא, אבל אני לא מצליחה לשחזר כלום מהתהליך שהיה קל ונחמד ששווה לכתוב אותו בתור יתרון, ולכן אני נשארת רק עם רשימת חסרונות 🙁 בפוסטים שפרטתי למעלה יש יתרונות אבל בשבילי רבו החסרונות מהיתרונות:
- לטעמי, לא מספיק ידידותי למי שלא מספיק "מתכנת". ההתקנות היו לא מספיק קלות וזורמות. לא חשתי מספיק בנוח, לא עם ההתקנה ולא עם כתיבת התיעוד בתוך הקוד.
- אין מספיק דוקומנטציה איך לכתוב את התיעוד נכון בשביל לייצר את ה-style-guide
- בהתחלה חשבתי ששורות הקוד שאוסיף בתוך קבצי ה-sass יהיו דומות לכתיבה של הערה קצרה, אבל לאורך הדרך נוכחתי לדעת שלפעמים ההערה של התיעוד גדולה יותר משורות ה-css בפועל.
- הפריע לי שיש לי בתוך קבצי ה-scss חזרה רבה על משתני scss וגם די הרבה HTML. זה גם הוביל אותי למסקנה הבאה:
- תכלס, ה-style-guide הזה לא באמת חי, כי אם נשנה את מבנה ה-HTML ולא נשנה גם בתיעוד, ה-style-guide שלנו לא יהיה מעודכן. מה שהוביל אותי למסקנה הבאה – אולי style-guide חי הוא לא הפתרון הנכון עבורי.
שנייה לפני שממשיכים לתחנה הבאה, כמה קישורים שאספתי בחיפושיי אחר style-guide חי שיכולים להיות רלוונטיים למי שכן מעוניין:
- סקירה של כלים שונים ליצירת style-guide חי
- אוסף של כלים ליצירת style-guide
- עוד כלי ליצירת style-guide שיצר תוצר מאוד יפה בעייני (האתר שאליו הוא משוייך), אבל לא הבנתי איך הוא מתפקד ואיך בכלל להתקין אותו.
- אוסף של כלים שנתקלתי בהם, אבל לא השלמתי את תהליך ההתקנה או שוויתרתי עליהם מחשש שלא יתאימו לי או מחשש להתקנות מורכבות (כמו למשל שימוש ב-yarn שאני לא מכירה בכלל):
- patternlab
- catalog
- docz
- SC5 Style Guide למי מכם שירצה –מוסיפה פוסט תיעוד עליו
Static Style-guide
אז את ה-style-guide ה"חי" ומבוסס הקוד ניסיתי ולא הגעתי לתוצאה משביעת רצון, ולכן בצר לי פניתי לחברתי משכבר הימים – הפוטושופ!
יצרתי כמה קבצים שונים שכל אחד מכיל אלמנטים אחרים של style-guide. יצא נחמד, אבל לא מעוצב ויפה כמו סטיילגיידים אחרים שראיתי:
- Style Guides by Pro Designers
- Inside the web design style guides of 10 brands
- Design Style Guides to Learn From in 2018
- How To Create a Style Guide From Scratch. Tips and Tricks
הבעייה היא שה-style-guide שנוצר היה מאוד מאוד סטטי, וגם לא היה נוח להעתיק ממנו שמות של קלאסים או את המבנה של ה-HTML.
בשלב הזה זנחתי את העבודה על style-guide והתפניתי לעבודה על האתר עצמו.
אבל לא באמת הצלחתי לזנוח אותו….
style-guide ידני
כחודש אחרי ההתנסויות הקודמות שלי התפנה לי זמן, והחלטתי לכתוב style-guide לבד. בהתחלה היה נראה לי שמצאתי את הדרך הטובה ליצור style-guide, אבל עם ההתקדמות בעבודה נוכחתי לדעת שגם הפעם – הפתרון מדשדש ורחוק מלהיות מושלם 🙁
פתחתי לי סביבת עבודה ב-php-storm, משכתי אליה את הסטייל של הפרויקט והתחלתי להכניס אלמנטים, וגם קובץ css נוסף בשביל לסגנן את ה style-guide שלי. השתמשתי בדוגמאות שונות של style-guide שונים כדי ליצור לי מראה עיצובי בסיסי. בקובץ ה-HTML שיצרתי לקח לי זמן להגיע למבנה סביר של איזורים המכילים: אלמנט, תיאור קצר שלו ודוגמת קוד. ואז התחילו הבעיות:
- כדי להכניס לקובץ HTML קוד HTML שלא צריך להיות מתורגם לאלמנט צריך להפוך כל
>
ל->
וכל<
ל-<
/ לקח לי זמן בכלל לעלות על זה שזה מה שצריך לעשות. כדי לעשות את זה אוטומטית השתמשתי בעורך הטקסט של וורדפרס – כתבתי בעורך הויזואלי והעתקתי מתוך העורך טקסט. עקום, אבל עובד 🙂 . אז אמנם מצאתי פתרון אבל הוא ממש לא נוח, בטח לא כשמדובר על הרבה קטעי קוד. - היות ואת הסטייל משכתי דרך לינק קבוע והסביבה שלי הייתה מקומית, הפונט אייקון לא נטען.
הפעם לא חיכיתי לעוד מכשולים, וכשבידיי קצת פחות מיום של נסיונות ומורת רוח החלטתי לזנוח את ה-style-guide הידני.
באותו זמן, נתקלתי בפוסט בשם Why Design Systems Fail – שנכתב ע"י Jeremy Keith שנכח בכנס A List Apart בוסטון וסיכם את ההרצאה של Una Kravets. השם של ההרצאה קצת מטעה בעייני, כי Una לא באמת אומרת שלא תמיד צריך או ש-style-guide תמיד סופו להכשל, אלא שלא תמיד הוא אפקטיבי. דווקא בהרצאה שלה היא מפרטת את הדרכים איך כן להפוך אותו לאפקטיבי. ממליצה לצפות בהרצאה ולקרוא את הפוסט. בהתחלה תליתי תקוות בפוסט במחשבה שאולי, אולי, לא צריך את ה-style-guide ואני יכולה להניח לזה. אבל זה לא קרה, וחזרתי אל אפשרות אחרונה שנשארה לי, אחת ששמרתי לי לסוף וגם למישהו שיהיה פנוי לסייע לי, היות ושוב היה מדובר בהתקנות ולא רציתי לנסות לבד.
אבל סקרנותי וחוסר סבלנותי התגברו עלי: לא חיכיתי לעזרה ויצאתי לדרך!
Astrum style-guide
כבר בעמוד של המוצר, Astrum היה נראה לי ידידותי, והתוצאה הסופית בדמו נראתה מרשימה מאוד! ישבתי לראות את סרטון ההדרכה, ואפילו שהיה נראה שכל העבודה מתבצעת דרך החלון השחור, עדיין, מסיבה כלשהיא לא נלחצתי. פתחתי בראנץ' מהפריקט שעליו אני עובדת, פתחתי את הטרמינל (!!) והתקנתי את Astrum. בניגוד להתקנה וההגדרה של KSS, הפעם הסתדרתי ממש ממש לבד ותוך שניות הייתה לי תיקיית style-guide מוכנה, ועמוד ראשון בלי תוכן. עברתי שלב שלב במקביל לסרטון ההדרכה בצפייה שניה, וכך יצרתי את הקומופננטות, הגדרתי את כל ההגדרות הנחוצות למשיכת קבצי css, לכותרת, ועוד. אפילו הוספתי קובץ css נוסף לקסטם טיפה את המראה של ה-style-guide.
בגדול אני מאוד מרוצה מהתוצאה הסופית, אבל לא אכחיש – הכלי לא מושלם ולא אפוי עד הסוף. ייתכן שאם הייתי מנסה את Astrum ראשון אולי הייתי שוללת אותו כי לא הייתי שֹבֵעת קרבות ולמודת נסיון. וייתכן, מצד שני, שאולי הייתה נחסכת לי כל הדרך, אבל אין חכם כבעל נסיון.
על פניו נראה שיש עוד עבודה על Astrum, יש להם אפילו עמוד של Development Roadmap עם פירוט של פיצ'רים שהתווספו או כאלה שאושרו ובתהליך העבודה. אבל התגובה האחרונה שנכתבה שם ובפורום הייתה במאי 2018 ומאז שקט, כך שאני מקווה שזה לא נזנח…
Astrum – בקלות ובקיצור
ההתקנה הלכה ממש בקלות: בתוך הבראנץ' שלי, דרך חלון הטרמינל ב-php-storm הרצתי 2 פקודות אחת אחרי השנייה וזהו!
npm install -g astrum astrum init ./public/pattern-library
משם, כמו שאמרתי, הלכתי צעד צעד עם סרטון ההדרכה ומהר מאוד התמקצעתי והבנתי מה כל דבר מגדיר.
Astrum – פתיחה של קומפוננטה חדשה
astrum new branding/site-icons
- כל הפקודות שנכתבות מתחילות עם Astrum, ואחריו יכולה לבוא פקודה של new, או edit או delete.
- בדוגמה שלנו, branding הוא הכותרת של הקבוצה
- בתוך כל "קבוצה" ישנן קומפוננטות, ובדוגמה שלנו הקומפוננטה נקראת site-icon. לצורך העניין תחת branding יהיו גם הצבעים והלוגו.
כשאנחנו פותחים קומפוננטה חדשה אנחנו עושים כמה פעולות:
- נותנים שם לקבוצה
- יש לנו אפשרות להחליט על המיקום של הקבוצה בסך כל הקבוצות (וזה ישפיע על סדר ההופעה בניווט)
- נותנים שם לקומפוננטה שלנו
- שולטים על סדר ההופעה שלה בתוך הקבוצה (שוב- זה ישפיע על ההופעה בניווט)
- שולטים על הגודל שלה – רוחב מלא או חצי
- שולטים על צבע רקע לאזור של התצוגה וצבע רקע לאזור של הקוד.
- באופן אוטומטי נוצרת לנו תיקיה לפרויקט עם קובץ MD לתיאור כללי על הקבוצה וכן תת-תיקייה עבור הקומפוננטה שבתוכה קובץ MD שניתן לכתוב בו תיאור קצר על הקבוצה, וקובץ עבור קוד ה-HTML שלה.
ככה זה נראה אחרי שפתחתי כמה קבוצות וכמה קומפוננטות:
Astrum – עריכה ותוספות
אם רוצים לשנות משהו, ניתן לעשות זאת בקלות ע"י שימוש בפקודה של edit או עריכה בקובץ data.json
שנוצר. התלבטתי עם עצמי אם להביא דוגמאות והסברים איך לעשות כל דבר והחלטתי שלא, היות וזה באמת ממש ממש קל (אם אני הצלחתי – כל אחד יכול!), וגם יש רישום מאוד מסודר של הכל בעמוד בגיטהאב. אבל כן יש כמה דברים שלא היו בהדגמה ולקח לי (קצת) זמן ליישם ואותם אביא.
כמו שכתבתי קודם, אם רוצים לערוך קומפוננטה אפשר לעשות זאת בעזרת שורת הקוד:
astrum edit branding/site-icons
אבל לא הכל ניתן לערוך דרך הפקודה ויש דברים שניתן להוסיף או להחסיר רק דרך קובץ ה data.json
.
למשל, הסתרה של דוגמת הקוד: בתצוגה של הצבעים לא רציתי להציג את המבנה הסמנטי של ה-HTML אלא רק את הצבעים ואת שם המשתנה שלהם. כדי להוריד את התצוגה של הקוד, יש להוסיף הקוד הבא בקובץ data.json
בתוך ההגדרות של הקומפוננטה שלנו:
"options": { "sample_dark_background": true, "disable_code_sample": true }
מחיקה של קבוצה או קומפוננטה או שינוי סדר הופעה:
יש לעשות זאת דרך שורת פקודה – ולא ע"י עריכה של קובץ ה data.json
, ולא ע"י מחיקה של התיקיות.
Astrum – צבעים
כדי לייצר את הצבעים יש ב-Astrum שורת פקודה שונה כדי לייצר את המראה הזה לתצוגה של הצבעים
צריך לתת את הקוד הזה:
// the command line in the terminal: astrum new branding/color-palette --type colors // the output in the data.jason: "groups": [ { "name": "branding", "title": "Branding", "components": [ { "group": "branding", "name": "primary-palette", "title": "Primary Color Palette", "type": "colors", "colors": [insert here your colors] } ] }, ],
בקובץ data.json
יש להוסיף את הצבעים אותם רוצים שיוצגו, וככה זה נראה בתוצאה הסופית:
הבעיה היא שאני רציתי להציג לא רק את הצבעים ואת קוד ה-HEX שלהם, אלא גם את שם המשתנה שלהם. לכן לא השתמשתי באפשרות של Astrum ליצירת הצבעים אלא יצרתי קומפוננטה רגילה ובתוכה יצרתי אזורים בהם יש את הצבעים. הקוד בקומפוננטה נראה ככה:
<div class="custon-colors"> <div class="custon-colors-item"> <div class="custon-colors-example" style="background-color:#f7f8fc;"></div> <div class="custon-colors-details"> <p class="custon-colors-name">$main-color-light</p> <p>#f7f8fc</p> </div> </div> <div class="custon-colors-item"> <div class="custon-colors-example" style="background-color:#525f7f;"></div> <div class="custon-colors-details"> <p class="custon-colors-name">$main-color</p> <p>#525f7f</p> </div> </div> <div class="custon-colors-item"> <div class="custon-colors-example" style="background-color:#464f6c;"></div> <div class="custon-colors-details"> <p class="custon-colors-name">$main-color-darker</p> <p>#3d70b2</p> </div> </div> </div>
והנה התוצאה (כדי לסגנן את הקוביות הוספתי סטייל משלי):
Astrum – אייקונים
לאייקונים לא מצאתי בכלל רפרנס לאיך מציגים אותם. בדמו של Astrum יש דוגמה אבל היא לא מצאה חן בעייני. הלכתי שוב לראות מה אחרים עשו ומצאתי בסטיילגייד של mailchimp דוגמה מאוד נחמדה. וכך עשיתי 🙂
Astrum – מגבלות וחסרונות
- יצירת קומפוננטה של צבעים אינה אוטומטית, וזאת שכן – לא מספקת.
- כנ"ל לגבי יצירת ייצוג של אייקונים.
- אין אפשרות, כמו שיש ב-kss, להציג pseudo-class. במקרה של כפתורים למשל אין אפשרות ל"הקפיא" ולהציג מצב של
hover
אוfocus
. - לכל קומפוננטה יש קובץ MD שניתן לכתוב בו הנחיות או הערות חשובות. לא ניתן להשתמש בפורמטים של קובץ MD כי הן לא מיוצגות בסופו של דבר ב-style-guide.
- יש באג מעצבן של מעבר עכבר שיוצר גלילה על האזור הימני. כן, ב-Astrum יודעים עליו.
- אם יש 2 קומפוננטות ברוחב של חצי, ולאחת מהם יש תקציר ולשנייה לא – משהו ביישורים נדפק וזה לא נראה יפה.
Astrum – שורה תחתונה
אם מתייחסים ל-Astrum כמו אל תבנית וורדפרס סגורה, שמה שהיא נותנת מקבלים ושינויים אפשריים רק במסגרת האפשרית אז מתקבלת תוצאה די משביעת רצון. נכון יש חסרונות, אבל בגדול ובינתיים התוצאה שהתקבלה היא משביעת רצון עבורי. ימים יגידו אם ה-style-guide עמד במבחן הזמן ואכן היה אפקטיבי.
סוף דבר?
תם ולא נשלם מסעי ליצירת style-guide. מקווה שהייתי לעזר למישו. אשמח לשמוע תובנות נוספות על מה שגיליתי אני, וכמובן על עוד כלים אחרים!