יום שני, 23 במרץ 2009

לרצות פשוט

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

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

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

החלטתי לצאת לבדיקה קצרה בה אני אגש אל האתרים עצמם, וכך אולי אני אוכול לגבש דעה בנוגע בנוגע למה קהל היעד שלי מעדיף.

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

אבל בהסתכלות על אתרי המתכנתים, ניתן לראות מגמה הפוכה, כאשר מסתכלים על התמורותב אתר webmaster מגלים דווקא אתר מורכב, ובמקום תפריט עליון מהיר לכל הפעולות באתר, האתר החליט להוריד את הקטגוריות למטה ולתת לגולשים לחפש אותם.
חשוב לי להדגיש שכאשר התרחב השינוי ב-webmater לי אישית היה נורא קשה להישאר בו, ובמקום אתר שניתן לקחת ממנו מידע מצאתי בו אתר עמוס ומסורבל להפליא.

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

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

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

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

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

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

בניגוד למה שציפיתם, אני אלך על הדרך הראשונה, כי שינוי בתפיסות נהוגות לא בא מלשאול אנשים את דעתם, אלא להציג להם פשוט אפשרות שונה.

גלישה פשוטה לכולם.

יום שישי, 6 במרץ 2009

בניית תשתית לאתר

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

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

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

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

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

התבנית Model-View-Controller
או בקיצור MVC, תבנית בהנדסת תוכנה המחלקת את היישום לשלושה חלקים, ובעזרת דימוי אני אציג את שלושתם.

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

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

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

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

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