עיצוב מחודש של אתר - שיעור רביעי - אתרים מונעים דינאמית ועל ידי בסיסי נתונים

דף הבית

דף פירוט מדריכים

עיצוב מחדש של האתר - דף השיעורים

שיעור רביעי-אתרים מונעים דינאמית ועל ידי בסיסי נתונים

עיצוב מחודש של אתר - שיעור רביעי
אתרים מונעים דינאמית ועל ידי בסיסי נתונים

ההחלטה על מי, מה ומתי הקבוצה תזמון זה הכל מי הרג את החתול? תעשה את החישובים תעשה את זה מודולרי התיווך בין העיצוב וההנדסה

בעיות עם הכנסת נתונים תוסיף מכונת פיתוח תשיג את חתימת האישור הזו תהליך ההפקה המקל הסגול כמה מחשבות לסיום השורה התחתונה

מאת לוק נולאנד
בימים האחרונים שמענו את שריל ואת כלב מדברים על עיצוב מחדש של אתרים מנקודת המבט
של ההנהלה, גם מצד הלקוח וגם מצד חברת העיצוב. היום נסתכל על עיצוב מחדש מתוך
החפירות.
כמנהל הפקה, אני מוצא את עצמי מתווך לעיתים קרובות, מוודא שהמעצבים והמהנדסים,
כמו גם הרעיונות שלהם, מצליחים לעבוד יחד. בכדי לעשות את זה אני לא רק צריך להבין מה
כל אחד עושה (ואיך הם עושים את זה), אני גם צריך להיות זה שמצליף עם השוט. בזמן
שהמפיק (כמו שריל) מנהל את כל האופרציה כמו מצביא, מנהל ההפקה הוא יותר כמו מפקד
בשדה הקרב, ששולט על הפרטים בכדי לוודא שמנצחים במלחמה ושאף אחד לא נפגע במהלך
הדרך.
אבל מספיק עם הפגישות האלו, מספיק עם הדיפלומטיה. הגיע הזמן להיכנס לעניינים ולעשות
משהו!
טוב, כמעט.
כמו הרבה דברים בחיים, אתרים דינאמיים הם לא כזה דבר ברור ויבש כמו שהם נראים.
התיאוריה של אתרים דינאמיים היא שבמקום לעדכן מאות עמודים, אתה רק משנה כמה
חתיכות (כמו כותרות עיליות ותחתיות ושוליים). ההבטחה: תיקון מהיר כאן, גיזום קטן שם,
ו...הנה! האתר שלך מוכן. אבל במציאות, יש הרבה יותר חתיכות שצריכות תשומת לב ממה
שחשבת בהתחלה. כשמתחילים להסתכל באמת מגיעים בסוף ל-50 חתיכות מודולריות
שצריכות לעבוד טוב אחת עם השנייה ולהיות הגיוניות.
אבל אל תדאג. עד סוף השיעור היום תהיה מצויד ברשימת דברים שיעזרו לך לעצב מחדש את
האתר שלך, ולא משנה כמה שזה מסובך.
ועכשיו - לעבודה!

ההחלטה על מי, מה ומתי
מה אתה מנסה לעשות?
לפני שאתה מפשיל את השרוולים שלך, תחליט מה עומד מולך. האם זה עיצוב מחדש פשוט של
האתר הקיים או השקה של מוצר חדש לגמרי (שיפוץ כללי לכל האתר הקיים)? והאם זה אתר
מקורי לחלוטין או ערבוב של אתר החברה ואלמנטים מגורמים חיצוניים?
עיצוב מחדש קשה בפני עצמו, אבל הוא קל בהרבה מאשר השקה של מוצר חדש. אולי תצטרך
להתמודד עם שילוב תוכן חדש, אבל רוב העבודה היא ויזואלית וממשקית. עשה את העיצוב
מחדש, תן לכולם לבדוק את זה במשך יום שלם או יותר - בכדי לוודא שכל הגרפיקות
עקביות, שכל טבלאות הניווט נכונות, שהכל עובד על כל הפלטפורמות - וזה מוכן. נחמד
ופשוט.
השקה חדשה של מוצר צורכת הרבה יותר QA (בקרת איכות), לא רק במושגים של בעיות
הפלטפורמות הרגילות, אלא במושגים של תוכנה חדשה שמשתמשים בה בכתיבת הקוד. כך
שישנם יותר דברים שצריך לשקול. האם כל הקוד התומך שייך לאתר, או שיש אלמנטים
נוספים שנרכשו, כמו רכיבי צ'אט או חיפוש?
אם כל החלק האחורי של האתר שייך לחברה שלך, יש לך שליטה על איך שזה נראה. אבל בדרך
כלל חלקים מרכיבי הצ'אט או החיפוש לא שייכים לך ואין לך שליטה עליהם, במיוחד אם
החלקים האלו הונדסו בצורה לא טובה מההתחלה (כתובים בשפת תכנות ארכאית, לא
בתבניות וכולי). בדרך כלל החוזה לתוכנות כאלו כולל איזה משפט כמו "אין הינדוס חוזר"
(מה שאומר: גם אם תצליח להבין איך עובד מבנה ההפניות המוזר, אסור לך לשנות דברים
בקוד בכדי שהוא ייראה יותר כמו איך שאתה רוצה). כך שלפני שאתה מתחיל, כדאי שתדע מול
מה אתה עומד, ותחליט על ההמשך בהתאם.

הקבוצה
המשימה הבאה היא הערכת הצוות שלך. מי הם ומה הם יודעים? האם זו חברה חיצונית של
מעצבי רשת או שאתה מסדר את הדברים בתוך החברה שלך? ואם זו עבודה פנימית, האם
הצוות מורכב מאנשים חדשים או מאנשים שכבר מכירים את האתר ואת הקוד שלו ואת
בעיות ההפקה שלו? האם זה איש אחד? חמישה אנשים?

תזמון זה הכל
מתי אתה ממש חייב ומוכרח שהאתר הזה יתחיל לרוץ? כל צעד מהתהליך תלוי בתאריך היעד
הסופי הזה. האם זה שבועיים מהיום? (אוי, לא...) . אם יש לך מזל, נתנו לך לפחות חודש.
אפילו אם כך, אתה צריך שהעיצוב הסופי יהיה מוכן בסוף השבוע הראשון. זה כולל דברים
כמו החלטה מה המעצב עומד לעשות כדי שתוכל לכתוב את ה-HTML שלך בהתאם, ובדיקה
עם המהנדסים שהם יודעים על הסקר היומי (או מה שזה לא יהיה) שהחלטתם להוסיף ברגע
האחרון. תקדיש את השבוע השני להפקת ה-GIF ים וה-HTML ואת השבוע השלישי להשגת
האישורים הסופיים. תחילת השבוע הרביעי צריכה להיות מוקדשת לתיקונים האחרונים
ולהזזת הכל לשרת הפיתוח בכדי לעשות מבדקים ובדיקות איכות. ואז, כשנגמר החודש, זה
חי. נשמע קל מדי, אני יודע. (שים לב שהשתמשתי הרבה במילה "צריך").

מי הרג את החתול?
בחברה בניו אורלינס באוקטובר האחרון, אחד המרצים סיפר סיפור על עיצוב מחדש של אתר
שהוא עשה ללקוח שהיה חייב שיהיה חתול משולב בכל עמוד. "אל תשאל שאלות" הלקוח אמר,
"פשוט תשים אותו שם". כך שהוא והצוות שלו עבדו על האתר בערך חודש, ואז בפגישה
האחרונה הופיע איש חדש: ראש החברה. זה שיש לו את המילה האחרונה. כמובן שהוא אמר,
"אני אוהב את האתר, אבל תעיפו את החתול המטומטם." זה חשוב ביותר שתוודא שאתה
עושה את כל המאמצים למען האיש הנכון.

תעשה את החישובים
לבסוף תשאל את עצמך, "מה האופציות שלי?" תשקול את כל הפקטורים שהזכרתי בכדי להגיע
לתשובה. כמו ששריל אמרה, העיצוב מחדש שלך יכול להיות מהיר יותר, זול יותר או טוב
יותר, אבל לא שלושתם יחד. עם צוות של שני אנשים, שאף אחד מהם לא ראה את האתר קודם,
עיצוב מחדש פשוט יחסית ייקח בערך שלושה שבועות. אבל אם העיצוב מחדש כולל רכישת
אלמנט חיפוש, לוח הזמנים של שלושה שבועות לא יספיק. אתה צריך או יותר אנשים או יותר
זמן. אולי פגישה לא נעימה (או עם מנהל הפרוייקט או אפילו עם הלקוח) צריכה להיקבע. אבל
עדיף לך להיות מציאותי מההתחלה. או שתמצא את עצמך שלושה ימים לפני ההשקה המתוכננת
עם שני אנשים שעבדו יותר מדי שזוחלים על הרצפה ממאמץ להתאים תבניות שאי אפשר
להתאים אותם לחיפוש סוג הדברים שממנו צומחים אחר כך אולקוסים.

תעשה את זה מודולרי
בעודך עובר לשלב ההפקה של האתר, תעשה את העמודים שלך (מאמרים, אלמנטים, ודפים
אחרים) מודולרים. אני מתכוון ממש ממש מודולרים. תעשה דברים שיכולים לעמוד בפני
עצמם, חתיכות שיכולות להיות "קונטיינרים" - אלמנטים שיוודאו שהעמוד שורד גם אם
רכיב הכרחי בתוכו לא עולה.
עכשיו, אם אתה מתמודד עם אתר מונע דינאמית או אתר מונע ממאגר נתונים (או כל אתר
למעשה), קובץ משותף לכל הכותרות העיליות והתחתיות יקל על החיים שלך. תעריך את זה
כשמגיע הזמן לשנות את גודל הגופן, הלוגו העיקרי, צבע הקישורים, טבלת הניווט או את
הצהרת הזכויות בתחתית העמוד. אפילו אם יש לך כותרת שונה לכל חלק באתר, עדיין רצוי
לחלק את קבצי הכותרות האלו - זה יכול להיות ההבדל בין שינוי של חמישה קבצים או חמש
מאות.
יש כמה דרכים לגשת לזה - שתי השיטות הטובות ביותר הן XSSI (אם אתה משתמש באפאצ'י
ובדפי HTML ממשיים) או פרמטרים (אם אתה מתמודד עם תבניות וקוד) XSSI.
מתאים רק כל עוד העמודים עוברים חלוקה על ידי השרת. תגדיר את קובץ הראש שלך
(HEADER) (שמתחיל בתווית ה<HTML> ועובר דרך איזה סוג של אלמנט ניווט בו אתה
משתמש לאורך האתר) ותכניס את זה למסמכים במקום להדפיס את תוויות הגוף והניווט
שלך לכל עמוד. החיסרון של XSSI: זה לא יעבוד אם העמודים לא עוברים חלוקה על ידי
השרת (כלומר, הם מופקים מהקוד ולא נקראים כעמוד). אם זה המקרה, תן לקוד לשלוח את
האלמנטים הדינאמיים (תוכן, שם משתמש וכולי) לתבנית כפרמטרים, ואז תגיש את העמוד.
בתשעה מקרים מתוך עשרה, אני מעריץ גדול של תבניות, במיוחד בגלל שהם מאפשרות לצוות
ההפקה שלך לשנות דברים בלי לדעת C או ++C או איזה סוג של שפה שלא תיהיה, בה
משתמשים לבניית האתר. אבל הכל תלוי בהרכב הצוות שלך. אם אתה איש ההפקה היחיד וזה
מקל לך על החיים שכל ה-HTML במקום אחד (בקוד) מאשר במקום אחר (בתבנית) ואתה יודע
או יכול ללמוד במהירות את שפת התכנות של הקוד, זה אולי הגיוני יותר לשים את הHTML
שלך בקוד. היתרון הוא שאתה לא צריך להכין הרבה תבניות. החיסרון הוא שאתה צריך לדעת
C או פרל או מה שלא יהיה, וכך גם האיש הבא שיפיק את האתר (כך שאם אתה מחפש בטחון
בתפקיד שלך, זאת אולי דרך פעולה טובה דווקא).
מה שמביא אותנו לדילמה של "עמודים" (קבצי HTML), לעומת CGI (סקריפט) וחוסר תפקוד
של התוכן. דפי HTML ממשיים עובדים מעולה כשאתה צריך לתקן עמוד אחד בכל פעם, על
בסיס של כל מקרה לגופו, ואתה לא מסתמך על מאגר נתונים שיתן לך נתונים. אבל מה אם אתה
עובד על אתר שמונע ממאגר נתונים, עם מספר אינסופי של עמודים? תשכח מזה - אתה צריך
CGI. תוציא את כל האתר שלך מהקוד, או תן ל-CGI שלך לדבר אל דפי התבניות עם
הפרמטרים. השינויים של עמוד אחד כל פעם עדיין יכולים להיעשות, אבל תלוי בתנאים
ובפרמטרים שבקוד (מאשר בקבצים הממשיים של ה-HTML). הדרך בה אתה בוחר תלויה
לחלוטין ביכולות של הצוות שלך.
אחד היתרונות לעשיית ה-HTML שלך בקוד מתרחש כאשר אתה כותב את אותו HTML שוב
ושוב (כמו פתיחת טבלה, סגירת טור, כזה סוג של דברים). אתה יכול להקל לעצמך על החיים
על ידי פונקציות/רוטינות כתיבה שעושות את ה-HTML בשבילך. אני עבדתי לא מזמן על אתר
כתוב ב-C בו התוכן הגיע ממאגר הנתונים. כל העמודים היו עם אלמנטים דומים מאוד,
והעיצוב היה מאוד חזק על טבלאות. כך שבמקום להדפיס כל הזמן <tr></tr> בכדי לסגור
טור ולהתחיל חדש, כתבתי פונקציה שנקראת ()new_row שפשוט הדפיסה את הסגירה
והפתיחה של כל טור בטבלה בשבילי. הגישה הזו ממש חוסכת זמן כשאתה צריך לשנות כל תא
עם פרמטרים של גופן, גודל, צבע הרקע, רוחב שורה וכולי . אבל כשאתה עובד עם קיצורים
כאלו, תוודא שאתה מתעד הכל בכדי שאנשי הפקה אחרים יוכלו לעשות שינויים מאוחר יותר
בלי להתבלבל לגמרי מהקצרנות שלך.
עוד רמזים: אחרי שסיימת את הפריסה שלך, תעשה די-באגינג (בדיקת שגיאות לקוד) על ידי
שימוש קודם באקספלורר, ואח"כ תבדוק את זה בנטסקייפ. אם זה לא עולה בנטסקייפ, אבל
עולה באקספלורר, סימן שהבעיה היא בטבלה שלא סגורה כמו שצריך איפה שהוא (נטסקייפ לא
יעלה טבלה ללא תוויות סגירה, אבל אקספלורר הרבה יותר גמיש - אתה לא צריך <td/> כל עוד
שיש לך <td> חדש). אם הדף שלך לא עולה גם בנטסקייפ וגם באקספלורר, סימן שמכלא מסוים
הוצף או שמשהו דפוק בקוד (פוינטר לא במקום, סוג כזה של דבר). ואם שום דבר לא עולה,
אבל אתה בטוח שה-HTML שלך נכון, תנסה לשים <td></tr></table/> בסוף קבוצת טבלאות
הטריק הזה לפעמים פותר את הבעיה.

התיווך בין העיצוב וההנדסה
משהו שאני חושב שלא מתייחסים אליו לעיתים קרובות מספיק הוא התפקיד הדיפלומטי שלך
בין המעצב והמהנדסים. על ידי יצירת התקשורת בין שני המחנות, אתה מוודא שכל תהליך
ההפקה והעיצוב מחדש עובד ושכולם יכולים עדיין לשבת באותו חדר ביחד אחרי שהפרוייקט
נגמר. המעצב בטח לא יודע C, המהנדס לא יודע פוטושופ. זה התפקיד שלך לוודא ששניהם
מבינים, לפחות באופן כללי, את המגבלות של הצד השני, וגם שכולם מתקשרים עם כולם
בצורה הכי אפקטיבית, אם לא הכי שמחה.
בכדי להיות המגשר, אתה צריך לדעת את החומר, כדי שתוכל לדעת מתי אנשים מנסים לעבוד
עליך. נאמר שהמעצב שלך מגיע עם ממשק משתמש (UI) חדש שצריך להיכנס לתבנית או לקוד.
תעשה את הפריסה של ה-HTML ואז תיקח את זה למהנדס. בעודך נותן לו אותו, תבקש
הערכה גסה של כמות הזמן שזה ייקח להכניס את זה. אלא אם כן זה ממש המון חומר עיצובי
או שהמהנדס עושה מיליון דברים אחרים באותו זמן, הערכת הזמן שלו צריכה להיות בערך
יומיים, מכיוון שזו עבודה על משהו קיים ולא כתיבת קוד חדש לגמרי (מה שיכול להיות קשה
להעריך). אם אתה מקבל תשובה כמו "אני לא יודע" או "לפחות שבוע", דבר עם המנהל של
המהנדס בכדי לברר עם מה עוד המהנדס הזה מתמודד. רוב המהנדסים שאני עבדתי איתם היו
ממש חביבים, אבל מדי פעם אתה עובד עם מישהו שעובד על החומר שלו עצמו, או לא יודע מה
הוא עושה, או מרגיש שהוא "מעל" לעזור לך או למעצב.
באותו מטבע, אני מכיר מעצבים שחושבים שכל מה שהם מעצבים, לא משנה כמה שזה לא
ריאליסטי לרשת, זה בדיוק מה שהם יראו באתר. כל אחד צריך לדעת שהרשת היא "תן וקח"
אולטימטיבי במה שנוגע לעשיית משהו שבאמת עובד. עם כבוד ותקשורת, מה שהמעצב עיצב,
מה שהמהנדס קידד, ומה שאיש ההפקה החליט יראה ויתנהג בסופו של דבר כמו שכולם רצו.

בעיות עם הכנסת נתונים
כשאתה מקבל תוכן לאתר שלך מגורם שלישי דרך לווין, רוב הסיכויים שצפויות לך כמה
הפתעות קטנות שהמעצב שלך לא חשב עליהן. למרבה המזל, יש גם סיכוי שמפתח מאגר הנתונים
שלך יכול לרשום איזה שהוא קוד שיגרום לדברים להראות יותר כמו איך שהמעצב שלך
התכוון שהם יראו. אבל ישנם גם מקרים בהם הכנסת המידע תיכשל ולכן אתה צריך לעצב גם
לקראת זה.
המפתח הוא לצפות את הבלתי צפוי. לדוגמה, בוא נעמיד פנים שאתה עובד על אתר בורסה.
האם אתה מקבל מידע שנכנס לשלושה מקומות דצימליים או רק שניים? איך יופיע "כלום"?
כאפסים? כלום? XX ? איך זה ייראה אם הכנסת המידע תיפול? אם הכל עוצב בצורה
מודולרית, אתה צריך להראות תא טבלה ריק. אבל בתסריט הזה, הגולשים שלך יצטרכו יותר
אינפורמציה. ואז מה - הודעה שאומרת שהכנסת המידע נפלה? האם תספק הודעת "סליחה על
הבעיות הטכניות" או הודעה תפורה אחרת? ואיפה תופיע ההודעה הזו? נסה לתכנן לקראת
הסיוטים הגרועים ביותר שלך.

תוסיף מכונת פיתוח
שלא כמו קוד, שנבדק על שרת עבודה לפני המעבר לשרת חי, דברים שמגיעים ישר ממאגר
הנתונים בדרך כלל לא נבדקים, וכל בעיה היא בעיה חיה. בגלל זה אתה חייב שתהיה לך מכונת
פיתוח שממש מתפקדת-בדיוק-כמו-אתר-חי (יותר על זה בחלק הבא).

תשיג את חתימת האישור הזו
אתה מוכן סוף סוף להראות למעצבים ולאנשי ההנהלה גרסה גסה לפני שאתה משלב את
העיצוב החדש. אז איך אתה עושה את זה? להתחלה, כדאי שתוודא שכולם מבינים מה שהם
רואים. זה חשוב שאנשים יבינו שמכיוון שזה אתר דינאמי/מבוסס על מאגר נתונים, אין "גרסה
מלאה" שאתה יכול להראות להם - עד שאתה מחבר את כל החלקים, מה שיש לך זה רק דמי.
אבל בכדי לעזור לכולם לדמיין איך זה יראה ויעבוד, תבנה חיקוי של המסכים השונים
שהגולשים יעבדו איתם, ותמלא אותם במידע לדוגמא. תקבל ביקורת, תעשה את השינויים
הנחוצים, תראה את זה שוב, ואז, כשיש לך חתימת אישור, תתכונן לעשות את זה.

תהליך ההפקה
אחרי שהתחלת לשנות את כל התבניות, הדפים, או הקוד, תראה את זה רק לאנשים שיכולים
להכניס באופן מנטלי את כל האלמנטים היפים של העיצוב שיגיעו. פעם עשיתי עבודה שעירבה
שבועות של 100 שעות ו-72 תסריטים ובנייה מחדש של כל העיצוב והפריסה בקוד שהפעיל את
כל האתר (בכדי להביא אותו למצב מבני בו כל הטבלאות ברוחב הנכון, האלמנטים מודולרים,
והכל עובד ביחד). כשהראיתי את זה לאחראי, הוא איבד שליטה לחלוטין וצרח שזה נראה
נורא, שאני לא יודע מה אני עושה, וכולי. העניין הוא שעשיתי את הטעות ואמרתי לו שאנחנו
עומדים בזמנים ואז הראיתי לו את האתר בלי שום גרפיקה חדשה. הגרפיקות במקרה הזה,
היו החלק הקל, עניין של כמה שעות להכניס אותן וזהו. יומיים אחר כך הראיתי לו את אותו
האתר בדיוק, עם הגרפיקות, והוא אהב את זה. כך שרק אם אתה רוצה להיות במצב בו אתה
זקוק למשקה חזק בשעה 10:30 בבוקר, עדיף לחכות עד שכל האלמנטים נמצאים במקומם,
אפילו אם זה אומר שמישהו יחכה עוד יום או יומיים עד שכל חפץ מונח במקומו.
בעודך מסיים את עבודת ההפקה שלך, כדאי שתעביר אותה לשרת פיתוח למבדקים וניסיונות
(אם זה לא כבר נמצא שם). הדבר החשוב לגבי שרת הפיתוח הזה הוא שהוא צריך לעבוד
בדיוק כמו ששרת חי עובד, ממאגר הנתונים ועד הספריות, מסל ה-CGI ועד הדרך שבה
הHTTP מורכב... הכל. ככה, כשזה מגיע לשלב בקרת האיכות, אין שום "אוי, זה יעבוד על
האתר החי אחרי שנכנס הסקריפט של זה וזה", או- "טוב, החלק הזה של מאגר הנתונים בעייתי
על השרת הזה, אבל באתר החי זה ייראה טוב." זה בדיוק הפוך מכל הקונספט של מבדקים.
כמה שאתה יותר מתקרב להשקה, ככה אנשים יירצו יותר להתערב בעבודה, אם זה עיצוב,
קוד, מה שלא יהיה. זה בדיוק הזמן בו אתה צריך להזכיר לכולם את הקונספט של שלב
הסיום. חוץ מתיקונים של דברים שלא עובדים, ברגע שהגעת לשלב סיום הקוד, שום דבר חדש
לא יטופל עד הפעם הבאה שעובדים על האתר. זה מונע מדברים לעלות לאתר החי לפני שהם
נבדקו כראוי, או נשקלו מספיק. חוץ מזה, שינויים קטנים שמשנים את האתר קלות על בסיס
יומיומי מעצבנים את הגולש. כך שתעשה כל מה שאתה יכול בכדי למנוע "CODE-SLURPEE "
(מונח אמיתי- המצאה של סאן, שנאמר עליו שהוציא מוצר שהגיע לשלב סיום הקוד, אבל
חפצים חדשים לא הספיקו להופיע בתוכנה על בסיס יומי).
בכדי שסיום יהיה סיום, אתה צריך שיהיה לך מקל סגול.

המקל הסגול
בזמנו, למנהלת ההפקה שלנו, פאם, היה מקל סגול באורך מטר על השולחן שלה (מתחת
לגודזילה וליד בקבוק ודקה של סוון), בו היא השתמשה בכדי להצביע על אנשים, לפעמים
אפילו לתופף איתו על השולחן, בעודה שואלת איך משהו מתקדם. בעיקרון, זה היה איום
ויזואלי בסגנון "אם לא תעשה את מה שאתה אמור לעשות, תקבל את המקל הסגול". למרות
שרק בנאדם אחד אי פעם חטף את המקל הסגול (וזה היה מסיבה טובה מאוד). האיום של
המקל עבד. אני מעלה את העניין בעיקר בכדי להזכיר לך שכשאתה עמוק בתהליך העיצוב מחדש,
איש ההפקה הוא מנהל הפרוייקט שבחפירות. אתה צריך להדגיש את החוקים, הקווים
המנחים, ותאריכי היעד. אתה חייב לבדוק ולבדוק שנית את הכל. אתה צריך להיות האיש הרע.
אתה צריך להיות דיפלומטי, כן, אבל לא סמרטוט.

כמה מחשבות לסיום
כן, קל לשנות דברים באתר דינאמי. זה רק שינוי קטן פה, שינוי קטן שם. אבל תחשוב על
הניסיון של הגולש. תחשוב על עקביות ויזואלית. העברת דברים ושינוי יכולות עלול לבלבל
את הגולש (יום אחד טבלת הניווט נמצאת מצד שמאל ולמחרת היא מצד ימין). תחשוב על כמה
שזה מעצבן אותך כאשר חברה משנה את הממשק המשתמש של התכנה שלה ממנוע אחד לשני.
שלא לדבר על שינויים של הרגע האחרון, לא מתוכננים, שמסתכנים בשבירת משהו מודולרי.
דברים שיבעטו לך בתחת: תוכנות של גורמים חיצוניים, מדריכים חדשים והפניות חדשות. די
עברנו על כל העניין של תוכנות של גורמים חיצוניים, אבל לא דיברנו על מדריכים והפניות
חדשים. נאמר שאתה נותן שם חדש לחלק של האתר שלך בעיצוב מחדש. ונאמר שאתה גם משנה
את שם הספרייה (כדי ששורת ההפניה(URL) תקבל את השם של החלק החדש). לפעמים הכל כל
כך משתנה שאפילו עם הפניה מלאה לחלק המקורי, קשה למצוא אותו. כך שתוודא שאתה
מספק את ההפניות הנחוצות לאנשים ששמו אותך במועדפים שלהם, ואל תשתמש בהפניות
שגורמות לכך שזה יהיה בלתי אפשרי למצוא תוכן ישן.
ואף פעם אל תשתמש בעורך WYSIWYG HTML כשאתה עושה את העיצוב מחדש שלך. כמות
הזבל שהם מוציאים תגרום לך לכל כך הרבה עבודה נוספת - לחזור ולנקות - שזה באמת לא
שווה את זה. אם אתה רוצה שזה יעשה כראוי, תעשה את זה בעצמך.

השורה התחתונה
לא משנה מה אתה עושה בכדי להתכונן, העיצוב מחדש אף פעם לא מתקדם יפה כמו שתכננת.
שום כמות של פגישות, תאריכי יעד מחושבים בקפידה, סיומי קוד, או חתימות אישור לא
ישנו את העובדה שתהיה שם עד 2 בבוקר בלילה שלפני, בודק ובודק שנית את החומר בפעם
האחרונה לפני שזה עולה חי. בחלק מזה אפשר להאשים את השינויים הבלתי נמנעים של הרגע
האחרון. אבל יותר מהכל, זה פשוט פקטור הפרנויה שמחזיק אותך שם עד הרגע האחרון -
ובאמת לא כדאי שתנסה להיפטר ממנו, כי זה מה שגורם לך להיות כל כך טוב.
אבל אף פעם אל תעריך שאתה עומד בפני עיצוב מחדש קל, בגלל שאם היה כזה דבר, לא היינו
כותבים על זה שיעור. ואתה לא היית מקבל את כל הכסף לעשות את זה.
בהצלחה!
בשיעור הבא: רוסה שרידן, כרגע מנהלת פרוייקטים בוויירד דיגיטל, עברה יותר ממה שצריך
בעיצובים מחדש (ויש לה את הצלקות להוכיח את זה). בחלק האחרון של האנטומיה של
העיצוב מחדש, רוסה מגלה את הדרכים הטובות ביותר להישאר מאורגנים ולתכנן לעתיד
בעודך מלכלכך את ידיך בדפי האתר שלך.