אבני הבניין של האינטרנט: URL

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

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

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

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

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


פוסט זה הוא חלק מהסדרה: אבני הבניין של האינטרנט.

מבנה ה Universal Resource Locator

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

להלן מבנה ה URL הרשמי:

(1) סכמה
לרוב זהו שם הפרוטוקול כגון http או https[א], או אפילו ftp, git, gg או אחד מני רבים אחרים.
הסכמה יכולה לכלול Psuedo-Protocol שאלו בעצם שמות שנשמרו ע"י הדפדפן בכדי לגשת לפונקציונליות פנימית מבלי לבצע קריאת HTTP. לדוגמה:

• about:blank טוען דף HTML ריק. משמש לבדיקות ולאיתור זליגות זיכרון ע"י מתכנתי ג'אווהסקריפט. רשימת פקודות about בדפדפנים השונים.
• :javascript - בכדי להריץ פקודת ג'אווהסקריפט
• :data - בכדי לקודד מסמך (קצר) inline בתוך ה URL כגון:

data:text/plain, hello%20world!

השימוש העקרי של סכמה זו היא הטמעה של תמונות קטנות בתוך המסמך בכדי לחסוך roundtrips לשרת.

(2) //
המבטאים שמדובר ב URL בעל חלק היררכי.
למשל: mailto:name@example.com?a=b הוא URL תקני ללא חלק היררכי.

(3) פרטי החיבור
משמש לפרוטוקולים ספציפיים כגון ftp או Https.

(4) כתובת
הכתובת יכולה להיות מתוארת באחת מ 3 סכמות:

Hostname
כתובת ה hostname היא כתובת טקסטואלית שמשמשת כ alias ל IP Address. כתובות IP הן דינמיות ועשויות להשתנות לאורך הזמן. תהליך ההפיכה של הכתובת הטקסטואלית (hostname) לכתובת IP היא תהליך שנקרא DNS Lookup. שרת ה (Domain Name Servers (DNS שאליו פנינו כעת יקרא לשורה של DNS אחרים בכדי ללמוד על הכתובות, כל שרת DNS אחד בתורו יודע לפרש חלק מהכתובת.
לדוגמה, עבור הכתובת http://ynet.co.il תחילה קוראים לשרת ה ROOT כדי ללמוד על כתובת ה IP של שרת ה "il" (מפרשים את כתובת ה hostname מהסוף להתחלה). בשלב הבא תהיה פנייה ל DNS של "il" וללמוד ממנו את כתובת ה IP של שרת ה "co" ורק אז מקבלים את הכתובת ה IP של השרת של YNET בכבודו ובעצמו. כמובן ששרתי DNS שומרים cache, כך שסביר ששמות נפוצים יחזרו מה cache ולא יהיה צורך לפנות לשרתי DNS אחרים.

אתר יכול להוסיף לעצמו תחיליות ל hostname לצורך חלוקה פנימית. לדוגמה, לאחר שהדומיין ynet.co.il נמצא, ynet יכולים להפנות ל"תתי אתרים / אפליקציה" שלהם בשם mail.ynet.co.il או en.ynet.co.il.

התחילית www היא תחילית לכל דבר ממש כמו mail או en שכל שרת יכול לבחור אם להשתמש בה או לא. www הוא קיצור של world-wide-web ובשנות ה-90 זו הייתה קונבנציה מאוד מקובלת. אם אתם נגשים לאתר ללא תחילית www הוא לרוב פשוט יפנה אתכם לכתובת האתר עם התחילית. או שלא.
יש דיון ארוך שנים העוסק בשאלה האם נכון להמשיך בקונבנציה דיון1 דיון2, ללא שום מסקנה ברורה באופק.

כתובת IPv4
כתובת ה IP שמוזנת ידנית ע"י המשתמש, כך שניתן לדלג על ה DNS Lookup (בהנחה שכתובת ה IP לא השתנתה).
כתובת ה IPv4 מורכבת בעיקרה מ4 octets של 0-255, כגון 10.3.0.163. URL הכולל כתובת IPv4 יכולה להראות כך: http://10.3.0.163/yo#hey.

כתובת IPv6
פרוטוקול IP גרסה 6 נוצר בכדי להתמודד עם המחסור שנוצר בכתובות ה IPv4 הזמינות. בערך לפני כחצי שנה היו אמורות להיגמר כל כתובת ה IPv4 בעולם וכדי למנוע זאת היה מעבר מסיבי לכתובות ארוכות יותר שיספיקו לעוד מספר רב של שנים.
כתובת IPv6 מכילה 8 קבוצות של מספרים hexdecimal ארבע-ספרתיים כגון 2001:0db8:85a3:0000:0000:8a2e:0370:7334. על מנת לחסוך באורך הכתובת ניתן לכתוב את אותה הכתובת כ 2001:db8:85a3:0:0:8a2e:370:7334 או אפילו כ 2001:db8:85a3::8a2e:370:7334.

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

(5) Port
מספר בין 1-65536. הטווח 0-1023 שמור לרוב עבור מערכת ההפעלה ואין להשתמש בו כשאתם פותחים server socket. אם לא הוקלד ערך ב http - הערך יקבע על 80, וב https - יקבע על 443. כאשר יש שירות שנענה גם ל http וגם ל https, מקובל שמספרי הפורט יהיו עוקבים, למשל 5000 ו 5001.

(6) רשימה היררכית של Resources.
רוב הדפדפנים יקבלו גם "\" בתור ה Separator.
סטייה מהתקן על מנת "להקל" על המשתמש  - היא התנהגות נפוצה בקרב דפדפנים.

(7) Query String
אנשים נוטים להניח שהפורמט של Query Sting נדרש להיות key1=value1&key2=value2 – אבל זו סתם קונבנציה שהשתרשה במשך השנים והיא איננה מחייבת. לדוגמה: מותר להשתמש ב ? בתוך ה Query String בכדי לבצע separation בין ערכים.
פעם כתבתי קוד שהניח שיש רק ? אחד ב URL - וכך נכשל. שיחה קצרה עם המפתח שכתב את הקוד שגרם לכשלון למדה אותי על החוקיות של מבנה ה Query String.

בפועל Query String הוא BLOB ש:

• מיוצג בתווי ASCII. אם אתם רוצים באמת להעביר מידע בינארי (מותר) עליכם להשתמש ב Encoding שנקרא Base64.
• נתחם ע"י סימן ה # הראשון שמופיע.

Query String משמש לרוב על מנת להעביר פרמטרים לשרת. Query String הוא חלק לכל דבר ועניין מה URL כך ששינוי בתו יחיד בתוך ה Query String משמעו - URL אחר.

(8) Fragment ID

בניגוד ל Query String שמיועד לצד-השרת, ה FID מיועד לצריכה ע"י קוד צד-לקוח. קונבנציה מקובלת היא שה Fragment מתאר מיקום במסמך. לדוגמה: אם תבצעו inspect למסמך ותמצאו id של אלמנט ב DOM, תוכלו להוסיף אותו ל URL כ FID כך שמעתה הדפדפן יציג את הדף כאשר בראש המסך הוא יציג את האלמנט עם ה ID שצוין.

באפליקציות מודרניות משתמשים ב FID על מנת לתאר את ה State של האפליקציה, לדוגמה: איזה טאב נבחר ואיזה Panels הם פתוחים. אין מניעה לקודד state מורכב כ BLOB על ה FID. שינוי ה FID-בלבד ב URL לא יגרום לטעינה מחודשת של הדף אלא יזרוק event מסוג hashChange. ה FID לא אמור להישלח לשרת.

ע"פ התקן, אגב, לא אמורה להיות מגבלה על אורך ה URL אולם IE8 ו IE9 מוגבלים ל 2048 תווים, ודפדפנים אחרים מתירים פי 2 או 3 מכך (בזה אני מעודכן כמה שנים אחורה, אולי דברים השתנו...).

Relative URL

עוד נקודה אחרונה ורלוונטית היא היכולת להתייחס ל "URL יחסי", כלומר URL יחסית ל URL של ה Document (דף ה HTML) הנוכחי. URL יחסי אמור לעבוד מכל הבחינות בדיוק כמו URL מלא.

נניח שאני כרגע בכתובת

http://amazon.com/product/ref=fs_cl/index.html?w=1

URL יחסי שאינו מתחיל ב "/", למשל "gogo/a/b" שקול ל:

http://amazon.com/product/ref=fs_cl/gogo/a/b 

URL יחסי שמתחיל ב "/" למשל "gogo/a/b/" שקול ל:

http://amazon.com/gogo/a/b

כללי ה path הבסיסיים של unix תקפים כך שה URL היחסי "a/b/.." שקול ל

http://amazon.com/product/a/b

בהגדרה, URL יחסי הוא כזה שלא מתחיל בפרוטוקול (למשל http) וגם לא מכיל את האינדיקטור ל URL היררכי "//".

URL יחסי תקני הוא "www.walla.co.il//" - שמצביע לאתר וואלה עם הפרוטוקול שכרגע בשימוש בדפדפן (למשל ftp).
דוגמה אחרת היא ה URL היחסי "details#" - שהוא URL יחסי לכתובת הדפדפן הנוכחית עם FID בשם details. שימוש ב details# לא תגרום לדף להיטען מחדש (מכיוון שה FID הוא חלק ה URL הרלוונטי לצד-הלקוח בלבד).

אם תקלידו בדפדפן מודרני URL יחסי בכתובת, רוב הפעמים הוא יפנה אתכם לחיפוש (גוגל). URL יחסיים כן יעבדו אם יהיו לינק בתוך ה HTML markup.


שיהיה בהצלחה!



---

[א] Https הוא Http שמוצפן על גבי פרוטוקול שנקרא SSL (או בגרסה היותר חדשה: TLS). השימוש ב Http יעשה באתרים שמכילים מידע פרטי או מסווג (למשל קופת חולים או בנק). במערכות ארגוניות נהוג להשתמש בעיקר ב https משיקולי אבטחה.

פוסט רלוונטי (כולל כמה נקודות על Encoding של URL): http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding

מה חדש באופיס 2013?

כארכיטקט תוכנה, יוצא לי לעבוד עם חבילת אופיס דיי הרבה. יותר מאשר עם IDE. שימוש באופיס מתקשר לעתים לניתוק מהפרטים הטכנים, אבל בפועל אפשר לעשות הרבה עבודה טכנולוגית בוורד, PowerPoint ו Visio.

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

כללי

דבר ראשון שבלט לי (מלבד מראה מעודכן - שהיה צפוי) הוא הקביעה של SkyDrive כלוקיישן ברירת-המחדל לאכסון קבצים. יש פה אמירה.

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

• כרגע SkyDrive מספק 7GB אחסון בחינם, שזה יותר מכל מתחרה אחר - ככל הידוע לי. 
• האפליקציה של SkyDrive למובייל ולדפדפן מציגה היטב קובצי אופיס מכל הסוגים - שזה ייתרון לא קטן. 
• האפליקציה ל iOS, לפחות ע"פ Battery Doctor, צורכת כמעט חצי מתצרוכת החשמל של Google Drive: עוד בונוס קטן.

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

באופיס 2013 ניתן לעבור בין "מצב עכבר" (ריווחים קטנים) ו"מצב טאצ'" (ריווחים מוגדלים):

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

פ'יצרים שהוסרו
לחבילת אופיס 2013 יש מספר תכונות שהוסרו, הבולטות שבהן הן:

• Clip Art Organazier 
• SharePoint Workspace (לשעבר Groove) - אפליקציה לשיתוף קבצים.
• Office Picture Manager (אפליקציה עצמאית לעריכת תמונות) 

ככל הנראה רוב המשתמשים לא יבחינו בחסרונן.


אופיס RT
עבור חלונות 8 RT (המבוססת מעבדי ARM) יש גרסה מצומצמת של אופיס הכוללת: וורד, אקסל, פאוורפוינט ו OneNote (בולט בהעדרו: אאוטלוק). אופיס 2013 RT מסופקת ביחד עם מערכת ההפעלה Windows 8 RT, כלומר - כלולה במחיר. על פניה חבילת אופיס RT נראית אותו הדבר, אך בפועל יש מספר פיצ'רים קטנים שלא זמינים בה. ע"פ מה שהבנתי, לאופיס RT לא תהיה אפשרות להוסיף Plug-Ins.

וורד 

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

זוכרים את הבלונים הצבעונים של הערות כאשר אתם עושים Review למסמך?

בוורד 2013 ניתן להגיב על ההערות במקום לכתוב הערות אחת על השנייה:

נחמד מאוד!

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

וורד ו PowerPoint

הנה כמה תכונות המשותפות גם לוורד וגם לפאוורפוינט.

תוך כדי שאנו גוררים אובייקטים (תיבת טקסט, תמונה כו') יציעו לנו לעמד אותם לאובייקטים אחרים במסמך, או לשוליים ע"י הצוות קווים מנחים, מה שנקרא alignment guides. כפי שאתם זוכרים יכולת זו קיימת עוד באופיס 2010 (אולי אפילו 2007?), אבל בגרסה 2013 היא השתפרה מאוד ומזכירה קצת את הרמה של הפיצ'ר ב Visual Studio כאשר מסדרים פקדים ב WPF או Windows Forms. מאוד אפקטיבי.

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

Visio

אני צרכן כבד למדי של Visio בצורך יצירת תרשימי "Light UML" ו Marchitecture.
אני כ"כ רגיל לעבוד איתו שלפעמם אני משתמש בו, תוך כדי ישיבה, בכדי לסכם את תוכנה בצורת תרשים וטקסט. מכיוון שאני לא משתמש ב Templates המובנים (הם מסורבלים מדי לשימוש. יש לי סט צורות משלי) -  מאז גרסה 2003 לא היה שום שיפור שהיה משמעותי עבורי.

Visio 2010 (משמאל) מול 2013 (מימין). שימו לב לאיכות הצל והרקע ההדרגתי.

ממש שמחתי לראות שב Visio 2013, סופסופ, הטמיעו את מנוע הרינדור התלת-מימדי של Office 2007 לתוך Visio. התוצאות -  ניכרות.

Visio 2013 הוסיפה גם לצורות מרקם Gradient כתכונה טבעית, כך ששינוי הרקע שומר על ה Gradient. יש גם Themes משופרים ועוד כמה צעצועים ל"עיצוב אוטומטי" - אבל לא נראה לי שהייתי באמת משתמש בהם.

במשך השנים נוכחתי שתרשים יפה מסייע לשכנע אנשים לא פחות יותר מתרשים מדוייק או בעל UML-תקני יותר. היכולת "ליפיף" את התרשימים באמת הייתה חסרה לי, במיוחד עבור תרשימי "Markitechture". עבור השיפורים בתוכנת Visio - אני מחכה לגרסת 2013 בציפיה.

אאוטלוק

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

אקסל

לאקסל יש פיצ'ר מגניב חדש: אלגוריתם השלמה אוטומטית משופר שמזהה תבניות מתוכחמות יותר.
בדוגמה למטה: אקסל מזהה שעמודה D (שם מלא) מורכבת מעמודה A (שם משפחה) ו B (שם פרטי). כשערך שני מתאים לתבנית מוקלד לעמודה D - אקסל מציע להחיל את התבנית (בלחיצה על Enter) על כל הערכים בטבלה.

עד כמה משוכללות התבניות שאקסל מזהה? האם זה כולל גם Formatting משוכלל יותר? - אינני יודע לענות. בכל מקרה פיצ'ר זה יכול לחסוך עבודת copy-paste מייגעת במקרים מסוימים. נחמד.

סיכום

שאלת השאלות: האם שווה לשלם x דולרים עבור עדכון גרסת אופיס? יש לי הרגשה שגרסה 2013, לפחות עבורי, משפרת יותר מגרסאות קודמות.

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


עדכון (6/6/2013): לאחר ניסיון ממושך יותר באופיס 2013 יש לי שתי תלונות:

• קביעת SkyDrive כ Default הייתה נוחה לי בזמן נתון, כי אני באמת מנהל את רוב המסמכים שם. כאשר רציתי לעבוד עם דיסק מקומי בעיקר - זה נהיה דיי מטרד. בנוסף: כששומרים מסמך ב SkyDrive אופיס מחכה שהטעינה ל SkyDrive תסתיים. אני מעדיף לשמור מהר ושהסנכרון ייעשה ברקע.
• משהו ב selections של Visio 2013 דיי מרגיז: הוא לא מאפשר למתוח קו (או רץ) לתוך צורה - רק לתוך ההיקף שלה. לעתים רבות אני יוצר תרשימים "free style" ו"התיקון" הזה מאוד מפריע. עד כדי לחזור ל Visio 2007.

פיתוח למובייל: Native או Web? (חלק ב')

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

בחלק זה, אני רוצה להתבונן על האופציות העומדות לרשותנו לפיתוח אפליקציות Multi-Device וה Tradeoff הטכנולוגי בניהן.

Native או Web: הדילמה

"פיתוח Native" הוא המקבילה של Desktop Application בעולם המובייל, קרי אפליקציה המותקנת על המכשיר, רצה כקובץ בינארי ומשתמשת בפקדים של מערכת ההפעלה (בהגדרה גסה).

יתרונות עיקריים של פיתוח Native הם:

• Best User Experience בפיתוח ב Native קל יותר להגיע לשימושיות גבוהה. הרבה יותר קל להשיג אנימציה חלקה ותגובה מהירה, ולעתים יש דברים שפשוט לא עובדים בווב. מכיוון ששימושיות גבוהה היא ערך חשוב באפליקציות מובייל - זהו יתרון חשוב.
  
  חברות המושקעות בפיתוח לווב, מנסות להוכיח ש HTML5 "יכול הכל". סיפור משעשע הוא הסיפור של FastBook בו הציגה חברת Sencha אפליקציית מובייל עדיפה על אפליקציית הנייטיב של פייסבוק (לטענתם), על רקע טענות של צוקרברג על כך ש HTML5 עדיין אינה מספיק טובה.
  Sencha גם עורכת תחרות בשם HTML5isReady ברוח דומה.
  
  בכל מקרה, ניתן לומר בבירור שלאפליקציות נייטיב יש יתרון בתחום זה. בכדי להגיע בעזרת HTML5 לתוצאות של Sencha יש צורך במומחיות יוצאת-דופן בפיתוח ווב, בעוד בפיתוח נייטיב - תוצאות יפות הן המצב הכמעט-סטנדרטי.
• Full Access to OS APIs אמנם ניתן לגשת כיום בחלק מהמכשירים ל GPS או אפילו למצלמה מקוד JavaScript של אפליקציית ווב, אך עדיין יש סט גדול של יכולות הזמינות רק מקוד native על המכשיר: גישה לאנשי הקשר, חיבור לרשתות חברתיות עם פרטי בעל המכשיר, ניהול קבצים ועוד.
• App Store Distribution. הדרך הסטנדרטית לחפש אפליקציה למובייל היא כמובן דרך ה App Store של המכשיר - הזמינה רק לאפליקציית נייטיב. עבור חברה קטנה שמוכרת אפליקציות - גישה ל App Store היא הכרחית על מנת להפיץ את האפליקציה. עוד בנושא ניתן לקרוא בלינק לפוסט על חנויות אפליקציה.

לפיתוח אפליקציות Web יש כמה יתרונות חשובים משלהן:

• Easiest Multi-Platform Development קלות בפיתוח למספר מכשירים. שימו לב שאני אומר קלות ולא "פיתוח יחיד". זאת בשל קושי לבצע Full User Experience Reuse ובשל שכיחות הבאגים בדפדפנים מוביילים (בולט במיוחד: Android Browser על גרסאות אנדרואיד 2.3 ומטה).
• Full control on updates באפליקציות נייטיב אינני יכול לשלוט מתי/האם משתמשים מעדכנים את גרסת האפליקציה - כך שה Backend שלי צריך לתמוך בגרסאות שונות. אם יש לי עדכון קריטי (אולי עדכון אבטחה?) - בווב אשחרר אותו לכל המשתמשים מיידית. בנייטיב: תהליך האישור של חנות האפליקציות יכול לעכב אותי בכשבוע או יותר בשחרור השינוי הקטן ביותר. תכונה זו חשובה יותר לארגונים.
• Interoperability & Extendibility נקודה זו היא חסרת חשיבות כמעט ל Consumer אך חשובה מאוד ל Enterprises ועושה לעתים רבות את ההבדל: מכיוון שאפליקציות נייטיב רצות ב Sandbox - אין מודל קיים של Plug-in שארגון יכול להשתמש בו על מנת לבצע התאמות של אפליקציית נייטיב לצרכיו הספציפיים. מאידך גיסא הרחבות בווב (ב JavaScript) הן קלות מתמיד - ויש הרבה ידע ותשתיות קיימות. אלמנט נוסף שחשוב למחלקות ה IT הוא Branding: היכולת לצבוע את האפליקציה בצבעים והלוגו של החברה (כדי שיהיה ברור מעורבותה של מחלקת ה IT). לקוחות רבים דחו אפליקציות בגלל יכולת זו בלבד, סיבה שנראית כחסרת-חשיבות למי שלא מבין את הפוליטיקה הפנימית של ארגוני IT בארגונים גדולים.

פתרון הביניים: Hybrid

הפלא ופלא, אנשים יצירתיים חשבו על פתרון לשלב בין גישות ה Web וה Native במכשירי המובייל. בכלי הפתוח למערכות ההפעלה השונות ישנו פקד (פקד = control. ממש כמו כפתור או רשימה) שנקרא WebView ומהותו הוא הצגת תוכן וובי בתוך אפליקציית native.

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

• בתור התחלה: ניתן להפיץ את האפליקציה ב App Store, מכיוון שמעתה זו אפליקציית נייטיב לכל דבר.
• ניתן לשמור את קבצי ה HTML מקומית מבלי "לחלוק" Cache עם אפליקציות אחרות ולהבטיח טעינה מהירה יותר של האפליקציה.
• ניתן, ופה אולי היתרון יוצא-הדופן, לחשוף פונקציות של האפליקציה הנייטיב כ javaScript API כך שאפליקציית הווב תוכל להשתמש בהן - וכל להעשיר את אפליקציית הווב ביכולות ״נייטיב״. לדוגמה: חישובים שדורשים יעילות גבוהה (כמו פענוח הצפנה), גישה ל OS API כגון שליפת אנשי הקשר, הפעלת רטט, או גישה לתמונות שצולמו לאחרונה בעזרת המכשיר.

ישנם פתרונות סטנדרטיים, לדוגמה PhoneGap או MoSync, של Containers מוכנים-מראש לאפליקציות ווב הנקראים Hybrid Container או Hybrid Web Container. ע"י שימוש בפתרונות אלו, אתם יכולים להתמקד בפיתוח אפליקציות ווב (עם התכונות הנלוות של הווב) ורק "לארוז אותן" כאפליקציית נייטיב. PhoneGap מספקת Containers מותאמים למספר רב של מערכות הפעלה מוביליות, וחושפת JavaScript API אחיד ממערכות ההפעלה כך שתוכלו לכתוב אפליקציית ווב פעם אחת, ולגשת לשירותים של מערכת ההפעלה השונות מבלי להיות מודעים למערכת ההפעלה שמריצה את ה Container.

רשימת הנייטיב API ש PhoneGap חושפת עבור אפליקציות ווב, על פלטפורמות שונות. מקור: וויקיפדיה. (לחצו על התמונה להגדלה).

בואו נשווה את תכונות ההייבריד לאלו של אפליקציות נייטיב או ווב:

פיתוח בעזרת Framework הכולל Hybrid Container מספק יתרונות משני העולמות, הווב והנייטיב:

• גישה מלאה ל API של מערכת ההפעלה. אם זה לא API שמסופק Out of the Box ע"פ ה Framework, אני יכול להוסיף wrapper של קוד נייטיב החושף javaScript API בעצמי.
• הפצה של האפליקציה ב App Store.
• קלות בפיתוח Cross Platform (באופן חלקי: ייתכן ועלי לתחזק wrappers משלי)
• שליטה מלאה על עדכונים (חלקי: עבור חלק הקוד הוובי באפליקציה. עבור שינויים בקוד הנייטיב עלי לעדכן גרסה של ה container / native app).
• Interoperability / Extendibility (חלקי: רק עבור חלקי הקוד הוובי).
• ה User Experience יהיה עדיין נתון רובו ככולו ליכולות הווב, קרי HTML5/CSS3.

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

• את ההבדל מעל מערכות הפעלה שונות קשה להחביא, ו"ה javaScript API האחיד" מעל מערכות ההפעלה השונות לא מתנהג כ"כ יפה.
• ישנו פער זמנים בין הזמן בו משתחררת גרסת מערכת הפעלה (למשל iOS 6) לזמן בו משתחררת גרסת ה Container שתומכת בה. מדובר בחודשים. במקרי הקצה, פונקציונליות יכולה להישבר (תמיכה לאחור איננה הצד החזק של אפל, למשל) ולדרוש מכם לכתוב wrappers משלכם, ללא תלות ב Frameworks.
• ה Hybrid Frameworks מוסיפים Layer נוסף של תלות גם ברמת הבאגים והבעיות השונות. שוב סיבה לעקוף את ה Framework בכדי ליצור workarounds. איתור תקלה (האם היא באפליקציה שלכם, ב Hybrid Container או במערכת ההפעלה?) הופכת למשימה קצת יותר מורכבת. באג רציני דורש הבנה ב Internals של מערכת ההפעלה - כך שהניתוק ממערכת ההפעלה אינו מוחלט.
• עליכם להקים ולתחזק סביבת Build לכל הפלטפורמות שאתן רוצים לתמוך בהן, משימה שאיננה פשוטה למפתח הבודד. את ה custom native code שאתם מפתחים עליכם לתחזק לכל פלטפורמה (ואולי אף גרסאות שונות של מערכת ההפעלה) - כך שיש אלמנט של קוד כפול.

אינני רוצה ליצור את התחושה ש Hybrid Framework הוא פתרון לא-מוצלח. לפתרון Hybrid יש הרבה ערך ופוטנציאל והם יכולים להיות בסיס לפתרונות מצויינים - בעיקר כשמבינים את ה Tradeoffs שבאים איתם. הדבר העקרי לו כדאי להיות מודעים הוא פער גדול בין ציפיות גבוהות למדי ומציאות שאיננה כולה דבש. אחוז לא מבוטל של מפתחים מתחיל לעבוד עם Hybrid Container בציפייה ל Silver Bullet רק כדי לגלות שיש גם מורכבויות - ואז נוטש אותו.

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

Native Transformers

קטגוריה נוספת ואחרונה של כלי פיתוח מובייל עבור Multi-Device נקראת Native Transformers. נניח שהחלטתם ששימושיות וגישה למערכת ההפעלה חשובה מספיק עבורכם, והתחלתם לפתח נייטיב 6 גרסאות של האפליקציה עבור 3 מערכות הפעלה שונות (+ טאבלט / סמארטפון).

עבור iOS עליכם לפתח בשפת Objective-C ב XCode על גבי מחשב מק.
עבור Android אתם מפתחים בג'אווה על איזו סביבה שמתחשק לכם, וב Eclipse.
עבור Windows Phone / 8 אתם מפתחים בשפת #C על גבי VS2012 שרץ רק על גבי Windows 8.

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

כתבו הרבה קוד משותף, ומעט קוד ספציפי - ההבטחה של ה Native Transformers.

Native Transformers מבטיחים לעזור בנושא זה. הם מציעים לכם לכתוב פעם אחת את הקוד שיכול להיות משותף, בשפת ביניים (לרוב javaScript או וריאציות שלה), בעוד ה Native Transformer יקמפל קוד זה לקוד נייטב עבור מערכות ההפעלה השונות, וייצור לכם שלד של פרויקט בסביבה המתאימה ממנו תוכלו להמשיך. יתרה מכך, חלק מהפתרונות בנויים כך שתוכלו לבצע שינויים בקוד המשותף ולהעביר את התוצר לסביבות הפיתוח הספציפית (לדוגמה: iOS, Windows 8) מבלי למחוק / לפגוע בפיתוחים הספציפיים שכבר עשיתם. מבנה שדומה להורשה בו רק מחלקת האב משתנה ברגע שמקמפלים את הקוד המשותף.

מכיוון שמספר גדול של Native Transformers מתבסס על javaScript כשפת ביניים, לא נדיר למצוא פתרונות שיכולים גם "לקפמל" גרסאות HTML5, כלומר ווב.
תכונה נוספת מקובלת היא Designer מסוג WYSIWYG בו אתם יכולים להרכיב בשפת הביניים את ה UI הכללי ולקבל שלד מוכן של UI בפקדים של מערכת ההפעלה הספציפית.


בואו נשווה את ה Native Transformers לפתרונות שקרובים אליו ביותר, הרי הם פיתוח נייטיב על הרבה פלטפורמות מצד אחד, ופתרונות ה Hybrid מהצד השני:

ישנו מספר רב למדי (אני שמעתי על כ 10 ויותר) של Native Transformers, בעיקר בעולם ה Enterprise. השלושה הנפוצים ביותר הם כנראה:

• Appcellerator Titanium - הפלטפורמה המוכרת ביותר בקטגוריה זו.
• Adobe Air - בעיקר עבור תוכנות גרפיות / משחקים. מספר לא מבוטל של משחקים שאתם משחקים בסאמרטפון שלכם ונראים נייטיב לחלוטין נכתבו בעצם ב Air.
• Antenna - שחקן מרכזי בשוק האנטרפרייז.

כפי שציינתי קודם, כלי Native Transformers רבים משחקים בשוק האנטרפרייז ומציעים יכולות חיבור קלות למערכות עסקיות (למשל SAP או IBM), ספריות אבטחה מתקדמות או ספריות המסייעות לעמוד ברגולציות שונות.

ל Native Transformers יש כמה חסרונות:

• בדומה לפתרונות Hybrid - יש כאן תלות בשחקן צד שלישי, בקצב העדכונים שלו, האיכות שלו, היציבות הפיננסית שלו וכו'. התלות בספק ה Native Transformers גדולה משמעותית מהתלות בספק ה Hybrid Container, אותו קל יחסית "לעקוף".
• שפת הביניים, הספריות שלה ובעיקר כלי העיצוב הגרפי הם סביבה חדשה (ולא כ"כ סטנדרטית) שיש ללמוד - מה שהופך את ה Learning curver לגבוה, למרות ש Native Containers ממוצבים ככלי Productivity לפיתוח מהיר על מספר פלטפורמות. בכל מקרה עליכם לדעת לפתח נייטיב בכל הפלטפורמות ולהכיר מספיק טוב את מערכות ההפעלה - הרי ה Native Transformers יוצרים בסה"כ שלד דיי גס של אפליקציה שיש עוד לעבוד עליו.
• גודל ה binaries של האפליקציה גדל בצורה משמעותית. פי 10 הוא לא מספר חריג במיוחד. זה לא נשמע מעניין כ"כ בימנו, שהרשתות מאוד מהירות, אולם מערכות הפעלה מוביליות לא מרשות (משיקולי שמירה על סוללה) להוריד ב 3G אפליקציות מעל גודל מסוים (בימנו הגבול הוא 20-50MB, תלוי במערכת / גרסה). כלומר: ייתכן והאפליקציה שתיווצר, גם אם היא נראית פשוטה - לא תוכל להיות מותקנת ללא חיבור WiFi.
• פתרונות אלו הם לרוב מסחריים, ובעלי רישיונות יקרים מהממוצע.

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

הרבה אופציות. כיצד בוחרים?

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

לו הדילמה הייתה פשוטה, קרוב לוודאי שהפוסט לא היה מתארך כ"כ J.

סה"כ הקו המנחה הוא כזה: ארבעת הקטגוריות נמצאות על סקאלה: בצד אחד פתרונות ה Web (הכי זול לפתח Cross-Device, אבל חווית המשתמש הכי פחות אינטגרטיבית) ובצד השני האופציה לפתח נייטיב בנפרד על כל פלטפורמה.

עליכם לבחון את המוצר שלכם ולראות היכן הוא הכי מתאים. מה יותר חשוב לכם: עלות-פיתוח נמוכה או חווית שימוש עליונה?

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

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

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

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

לסיכום

עברנו על ארבעת הקטגוריות לפיתוח אפליקציות מובייל, Cross-Device והשוונו בניהן.

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

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

שיהיה בהצלחה!

דיסקליימר: החברה בה אני עובד, SAP, מוכרת גם כלי Native Transformers. לא התנסיתי בהם, אבל אני מניח שהם הטובים בקטגוריה.


----

[א] אני קצת מוטה לעולם הארגוני, כנראה. אפליקציות ל Consumer הן רובן נייטיב עדיין.

Posted with Blogsy

פיתוח למובייל: Native או Web? (חלק א')

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

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

סביר אגב, שהתשובה שתקבלו מאנשי המוצר תהיה: "iPhone בעדיפות ראשונה, iPad בעדיפות שנייה ומאוחר יותר נרצה כנראה לתמוך גם ב Android", שמשמעה בפועל הוא בד"כ: "אנו הולכים אחרי העדר, אנחנו לא ממש יודעים".

יש לנו כאן דילמה מהותית וכמעט חדשה:
עבור אפליקצייה שולחנית הבחירה בין אפליקצייה native לאפליקציית ווב היא ברורה וקלה יותר: הצידוק לאפליציית native הוא בעיקר צורכי גרפיקה / זמן אמת (משחקים / תוכנות גרפיות / כלי productivity) או כלים ספציפיים למערכת ההפעלה (למשל אנטי-וירוס). כל השאר - הלך לווב. מכיוון שמערכת ההפעלה "חלונות" הייתה מונופול בצד ה Client - הפיתוח נעשה בכלים מתאימים (Windows Forms/WPF) עם נישה קטנה של UI בג'אווה (או שפות VM אחרות) - בעיקר לכלי אדמיניסטרציה.

המונופול של Windows ו Intel אפשר תאימות גבוהה, כך שאפליקציה שפותחה לחלונות ונבדקה על מחשב Dell, רצה היטב גם על מחשב מכל דגם של HP או Lenovo.

אנו נראה שהדילמה בפיתוח למובייל דומה - אך שונה ומורכבת יותר.

באיזה מכשירים לתמוך? הרבה מכשירים, הרבה יצרנים.

BYOD

לפני שנה שוחחנו עם לקוח גדול שבחר להשתמש במערכת שלנו. 

"באיזה מכשירים אתם מתכוונים להשתמש?" - שאלנו. "משיקולי אבטחה, תהיה לנו מדיניות נוקשה של iOS[ב] בלבד! לא נרשה חיבור מכשירים אחרים למערכת".

"כמה נוח", חשבנו לעצמנו, "הנה לקוח שסגור על עצמו".

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

תופעה נפוצה מאוד בארגונים היום היא תהליך שנקרא Bring Your Own Device (או בקיצור BYOD) - בה לעובדים יש מכשירים בעלי יכולות שהם רכשו והם רוצים להשתמש בהם לצורך העבודה.

נכון לשנת 2013, BYOD הוא מיינסטרים

מ BYOD נהנים שני הצדדים: הארגון מפחית עלויות (מכשירים, הכשרה, חידוש מכשירים) בעוד העובדים יכולים לעשות יותר עבודה ובדרך שהם בוחרים. ניתן למצוא כיום גם מדיניות של Buy Your Own Device - בה הארגון מספק לעובדים תקציב בכדי שיקנו לעצמם מכשיר בעצמם וע"פ בחירתם (תחת מגבלות מסוימות) - סימן לחשיבות שיש לבחירת המכשיר ע"י העובד.

למורת-רוחם של גופי IT רבים, מדיניות BYOD היא לרוב איננה יוזמה של גוף ה IT אלא תגובה ללחץ ו"קביעת עובדות" מצד היחידות העסקיות (Line Of Business) בשטח.

המשמעות המעשית של BYOD היא הצורך לתמוך במגוון רחב של מכשירים, ללא יכולת של גוף ה IT להכתיב או לבחור את המכשירים, כפי שיכול היה במשך שנים להכתיב את חומרת ה PC או את הדפדפנים שבשימוש[ג]. דיי נדיר היה לראות עובד מחסן שמביא PC מהבית לעבודה ודורש לחבר אותו למערכות הארגוניות.

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

רוב מפתחי האפליקציות מתכננים לתמוך ב2 פלטפורמות או יותר

דיי ברור שפיתוח Native (ל iOS, אנדרואיד, בלאקברי, Windows 8, וכו') מספק את מירב האפשרויות לפיתוח האפליקציה - ביצועים טובים יותר ויכולת לגשת ליכולות ספציפיות של המכשיר וכו' - ממש כפי שאפליציית Windows Native יכולה לעשות יותר מאפליקציית ווב הרצה על חלונות. בניגוד למחשב השולחני, אם נכתוב אפליקציה native למובייל בטכנולוגיה מסוימת - נגיע לפחות מ50% מהמשתמשים. כדי להגיע לאחוז דומה של משתמשי "חלונות" (כ 90%), עלינו לפתח עבור 3 מערכות הפעלה שונות ובסביבות פיתוח שונות, מה שמכעט משלש את כמות ההשקעה - מכיוון שאלו מערכות הפעלה שונות.

לא דיברנו עדיין על עוד 2 מכפילים נוספים המשפיעים על "מספר הפלטפורמות בפועל":

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

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

• סמארטפון: iPhone (ו iPod Touch)
• סמארטפון: Anroid של סאמסונג (סדרות Note, Ace, Galaxy וכו')
• טאבלט: iPad
• סמארטפון: Windows Phone
• טאבלט: Windows 8 (הערה: Windows 8 ו Windows Phone הן מערכות הפעלה דומות, אך שונות).
• טאבלט: Amazon Kindle Fire (נפוץ בקרב משתמשים פרטיים).
• ? טאבלט אנדרואיד* - אולי Galaxy או Nexus
• ? סמארטפונים של יצרן אנדרואיד* נוסף. HTC, ZTE או מוטורולה הן המועמדות המובילות. 
• ? מכשירים של מערכת הפעלה רביעית. מתמודדות עיקריות: Tizen אולי BlackBerry 10 או FireFox OS.
• ? מסכים (כבר לא נכון לקרוא להם "טלויזיות" או "טלויזיות חכמות") המריצים מערכות הפעלה מוביליות לינק1 לינק2.

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

תחזית לפילוח מערכות ההפעלה המוביליות בשנים הקרובות

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

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

UX Reusability

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

לדוגמה: ה UX Guidelines של חלונות 8 אוסרות על אפליקציה להוסיף אלמנט חיפוש בשטח האפליקציה. החיפוש נעשה מתוך SideBar של מערכת ההפעלה (נקרא "Charm") גם כאשר מדובר בחיפוש בתוך-האפליקציה. למכשירי ה Windows Phone יש כפתור חיפוש פיסי בתחתית המכשיר.

משתמש שהתרגל לעבודה במכשיר יכול להיות מתוסכל מאפליקציה שלא מפעילה את החיפוש שלה בעקבות לחיצה על כפתור ה Search הפיסי או בצורה שאליה הוא רגיל.

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

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


בעולם השולחני היינו מעצבים UX יחיד עבור אפליקציית ווב הרצה על פלטפורמות שונות וזה היה בסדר, כלומר היינו יכולים לבצע שימוש-חוזר מלא ב User Experience שלנו.

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

הנה דוגמה לאפליקציית הווב של Financial Times, והדרך בה היא מציגה חיפוש על טאבלטים במערכות הפעלה שונות. בסקאלה שבין "UI כמו של מערכת ההפעלה" עד ל "UI עצמאי", FT בחרו גישת ביניים של "אזרחות טובה". האפליקציה בסה"כ נראית אותו הדבר על כל הפלטפורמות, מלבד אלמנטים שסותרים בצורה משמעותית את ה UX Guidelines של הפלטפורמות השונות[ד].

---

[א] Phablet - יציר הכלאיים בין טאבלט לאייפון. לרוב בעל מסכי "5 עד "7, שניתן לבצע מהם שיחות. דוגמה בולטת: סדרת ה Galaxy Note של סמסונג.

[ב] מערכת ההפעלה של מכשירי אפל: iPad, iPhone ו iPod Touch.

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

[ד] כדאי להכיר:

Apple UX Guidelines http://developer.apple.com/library/ios/ -

Android UX Guidelines http://developer.android.com/design/index.html

Windows 8 UX Guidelines http://msdn.microsoft.com/en-us/library/windows/apps/hh465424.aspx