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

בעד אפליקציית Desktop:

• אפשרות לספק ממשק משתמש עשיר יותר.
• אפשר לכתוב אותה בסביבה ה"טבעית" של ממשקי משתמש (למשל ב-.NET או למי שמתעקש ב-swing)
• חוסך עומס מהשרת (לעומת ממשק web שמעמיס על השרת גם את ייצור דפי ה-web).
• אפליקציית web "עשירה" דורשת ידע טוב ב-HTML/AJAX וטכנולוגיות נוספות, ולא תמיד יש בארגון אנשים שמכירים אותן.

• האפליקציה יכולה לרוץ באותו context/container כמו אפליקציית השרת. אין צורך ב-deployment נוסף או ניהול של התקנות.
• אם האפליקציה רצה באותו container אפשר לחסוך חלק מבעיות ה-interoperability וה-remoting (שקיימות למשל כאשר השרת ב-Java וה-client כתוב ב-.net)
• כשיוצאת גרסה חדשה, אין צורך לעדכן את כל העמדות, מספיק לעדכן את השרת.
• בעזרת כלים כמו GWT (כאשר כבר מכירים אותן) אפשר לבנות ממשק עשיר ודינאמי.
• מימוש יכולות ה-logging (לדעת מה המשתמש עושה, כדי לשפר את הממשק) הוא קל יותר, כי אפשר להסתמך על ה-log של השרת.

גנאדי

הי רמי,

יש משהו משותף לכל הפרויקטים האלה? מה מבין השיקולים מכריע אצלך לטובת ה-web?

גנאדי

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

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

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

זו תחושתי.

חד משמעית, פתרון וובי.

כי אנחנו כבר בשנת 2007.

ישנם שני יתרונות בולטים לאפליקצית Web:

1.  אין צורך בהתקנה
2.  יכולת לרוץ בכמעט כל פלטפורמה אפשרית

מבחינתי החיסרון (אולי לא הבולט, אבל הכואב) זה performance כאשר מדובר בכמות מידע רצינית.

אני לא בהכרח מסכים עם שאר הטיעונים:

על Desktop:

• אם האפליקציה היא לא גרפית מטבעה (במקרה כזה הדילמה Web/Desktop אינה קיימת), אפשר להגיע לממשק משתמש עשיר מספיק גם ב-Web (ולעיתים זה יהיה אפילו קל יותר למימוש).
• לדעתי HTML היא סביבה לא פחות טבעית לממשקי משתמש
• אם משתמשים ב-Ajax זה די מוריד את העומס הקשור לייצור דפים
• גם אפליקצית Desktop "עשירה" תדרוש ידע טוב בטכנולוגיות הרלוונטיות

על Web:

• אם עובדים עם Webservices רוב הבעיות Interoperability נפתרות. חוץ מזה ב-Web כל מה שיש לנו זה Http - שתמיכה בו קיימת בכל פלטפורמה המכבדת את עצמה.
• לגבי עדכונים: היום רוב אפליקציות Desktop יודעות לעדכן את עצמן (אפילו Windows !), ומצד שני אני גם לא מסכים שאין בעיות בשידרוגים של אפליקציות Web: אם חלק מהתוכן שמור ב-Cache (וזה די נפוץ) - זה בכלל לא טריוויאלי להפיץ גרסה חדשה.

צטט: marmor 2007-06-29 16:52:36

חד משמעית, פתרון וובי.

כי אנחנו כבר בשנת 2007.

מה הקשר לשנה בה אנו נמצאים?

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

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

כשאני כותב "כי אנחנו בשנת 2007", אני בעצם מקפל במשפט קצר את כל מה שהאחרים אומרים.

ולמה?

כי כשהעולם פונה לכיוון מסוים, כל כלי הפיתוח פונים איתו לכיוון הזה, כלי הבדיקות, מערכות ה-versioning, ההכשרות של הכ"א, וכו'.

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

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

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

לפני כעשר שנים נשכרתי להוסיף ללוטוס (דומינו+נוטס) תמיכה עברית ויזואלית.

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

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

טכנולוגיות חדשות של MICROSOFT כמו SilverLight מאפשרות לאפליקציות "desktop"  לרוץ בדפדפן (סביבת WEB). במקביל GOOGLE מפתחת MIDDLEWARE בשם Google Gears שיאפשר לאפליקציות WEB למהדרין (למשל GMAIL או קוראי RSS) לרוץ גם ב-disconnected mode

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

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

צטט: marmor 2007-07-01 16:21:06

כשאני כותב "כי אנחנו בשנת 2007", אני בעצם מקפל במשפט קצר את כל מה שהאחרים אומרים.

 

אם ההערה שלי הייתה לא במקום, אני מתנצל.

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