האם כתיבת אפליקציות (Apps) היא דרך קלה להתעשר?

שאל אותי מישהו, לא מזמן, למה אני לא כותב אפליקציה או שתיים \"סתם כדי לעשות כמה אלפי שקלים מהצד\". לא חשבתי על זה בכלל. הוא אמר: \"אם הייתי יודע לתכנת – הייתי עושה קצת כסף מהסיפור הזה, לפני שייגמר\". התחלתי לתהות: האם באמת מספיק לדעת לתכנת ו\"לזרוק\" אפליקציה לאפ-סטור על מנת לקבל כמה אלפיות? הרי אפליקציות מגוחכות כגון \"I am Rich\" (אפליקציה של מסך בודד עם תמונת יהלום, שנמכרה ב 1000$ ליח\') הצליחו להעניק לבעליהם \"כסף קל\" (לכאורה).

זה פשוט מכרה זהב!

איי שם ב 2008, כחודש לאחר השקת ה App Store של אפל, היו כבר כשישים מליון הורדות (!!) ל ~3000 האפליקציות שבחנות.

סכום מדהים של כ 9 מיליון דולר בחודש אחד (מתוך 30 מיליון דולר הכנסות סה\"כ) התחלק בין 10 המפתחים המובילים[א]. הבהלה לזהב החלה.
תוך שנה אחת היו באפ סטור כ 55,000 אפליקציות מאושרות. אם לוקחים את זמן הלמידה של פיתוח על פלטפורמה חדשה + זמן הפיתוח עצמו – ברור שזה מספר מדהים.

למה כולם רצים, כל-כך מהר, לכתוב אפליקציות באפ-סטור?
זה לא ברור?? בואו ניקח סתם לדוגמה אפליקציה שהאחיינים שלי אוהבים, Temple Run:

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

האמת היא שהאפליקציה פותחה ע\"י זוג נשוי, עם עוד גרפיקאי שעזר להם:

קית\', נטלי וקיריל (מימין לשמאל). מקור: gamespot.com

…והאפליקציה מחולקת היום בחינם. מה יותר נחמד מזה?

רוצים עוד סתם דוגמה? ידידה שלי הכירה לי לפני שנה וחצי משחק קטן שנקרא \"ציפורים כעוסות\". כמה סדרת המשחקים הזו הרוויחה? – אין לי מספרים מדויקים, אבל הנה כמה נתונים: משחקים בסדרה הורדו לפחות 200 מיליון פעם, לפחות 12 מיליון פעמים בתשלום (יש גם גרסת חינם). בשנת 2011 רוביו (החברה שכתבה את המשחק) הכניסה 106 מיליון דולר, כאשר 67 מיליון מהם הם רווחים (אחוז רווח גבוה מאוד). ההכנסות כוללות גם מכירה של האפליקציה, אבל גם תמלוגים על צעצועים, בובות, סרטים, פריטי לבוש, כלי מטבח ועוד הממותגים עם \"ציפורים כעוסות\", המהווים כ30% מהכנסות החברה וצפויים לגדול. נראה שהחברה הזו מיצתה את הרווחים עד תום.

\"מלחמת הכוכבים של הציפורים הכעוסות\" – מותג בתוך מותג. מתי אמרתם שיהיה שת\"פ עם ג\'אסטין ביבר וליידי גאגא?!

זה קפיטליזם אכזרי!

מעניין להכיר גם את הצד השני של הסיפור הנוצץ. שימו לב לזה:
25 חברות / מפתחים – אחראים לכ 50% מההכנסות באפ-סטור (מקור), כל השאר (כ 199,975 חברות / מפתחים) – אחראים ל 50% השני. (מזכיר לכם במשהו את מבנה ההון במשק הישראלי?!)

יש ייתרון ברור מאוד לאפליקציות שנמצאות ברשימת ה \"100 המובילות\": היכולת, ממעמדן הגבוה, \"להמליץ\" על אפליקציות אחרות של אותו מפתח וכך לסייע מאוד למכירות. כשיש באפ-סטור כ 700,000 אפליקציות, קשה מאוד להתבלט. כשמייקרוסופט ניסתה למשוך מפתחים לפתח עבור Windows Phone 8, היא קראה: \"בואו לפתח עבור חנות אפליקציות כמעט ריקה\" – וזכתה להיענות רבה ביותר.

הכנסה ממוצעת לאפליקציה היא מעט יותר מדולר-וחצי לאפליקציה (שאינה משחק) או כ 90 סנט למשחק. משחקים נמכרים בפחות. ע\"פ Vision Mobile (בדו\"ח המלא), אחד מכל 3 מפתחי אפליקציות \"חי מתחת לקו העוני\" – כלומר, מפסיד על האפליקציה שכתב. כשביעית נוספים מרוויחים מהאפליקציות 500$ עד 1000$ לחודש – שזה סכום נמוך למדי, אם אתה מתכנת במדינה מערבית. סה״כ כמעט חצי לא מרוויחים ״כסף טוב״, לפחות ברמת התשלומים הישירים על האפליקציה.

בואו נחזור ל 2 ה Block Busters שלנו ש\"הצליחו בגדול\":
Temple Run – אמנם מכרה כ 40,000 יחידות ב 99 סנט, אבל אז המכירות החלו לצנוח. בראשית היא השתחלה ל \"50 האפליקציות הנמכרות\" – אך היא לא החזיקה שם מעמד זמן רב. המפתחים היו זריזים מספיק בכדי לשנות מודל כלכלי לפני שהיא תצא מרשימת ה Top 100 (אליה מגיעים באפ-סטור בדפדוף, אל השאר מגיעים בחיפוש) והחלו לחלק אותה בחינם.
כנראה שהמודל החינמי התאים יותר לקהל היעד – שהוריד הפעם 46 מיליון עותקים.
המפתחים הוסיפו למשחק אופציה לרכוש בכסף אמיתי, מטבעות שמסייעים להתקדם במשחק (מה שנקרא \"in-game purchase\"). כ 2% מהשחקנים שהורידו את האפליקציה בחינם, אכן קנו כאלו מטבעות – מודל שהוביל את האפליקציה לרווחים האדירים שהיא מרוויחה כיום. כדרך אגב, אפל גובה 30% גם על ה in-game purchases, והיא דורשת את הסכום גם כאשר לא נעשה דרך המנגנונים שלה – מה שהיה הרקע למריבה האחרונה עם מייקרוסופט.

ציפורים כעוסות – היא האפליקציה ה 52 (!!) של חברת Rovio. החברה כתבה 51 אפליקציות שלא הגיעו להיות Block Busters, ואולי אפילו הפסידו. לא יודע מה אתכם, אבל אני קצת הפסקתי לכעוס על זה שיש \"ציפורים כעוסות\" בכל פינה – אחרי ששמעתי את הסיפור הזה. אני מניח שגם אני הייתי \"סוחט כל מה שאפשר מההצלחה\", לו הייתי מגיע אליה לאחר כ\"כ הרבה ניסיונות.

כלכלת אפליקציות

הנה כמה מספרים:

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

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

כלומר – אפליקציה יקרה יותר = סיכון גבוה יותר.

משחקים הם לרוב פחות רווחיים, לפחות ברווחים ישירים, מה שנרחיב לגביו בהמשך.

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

מעניין לציין, שע\"פ Vision Mobile, התחום הרווחי ביותר הוא פיתוח אפליקציות עסקיות עבור פלטפורמת RIM (בלאקברי), יכול להיות שזה דומה למקרה בו גם מפתחי Cobol מרוויחים יפה…

השפעת האפ-סטור

עם ההצלחה של האפ-סטור, נוצרו בעיות חדשות למפתחי האפליקציות: שברגע שיש 700K אפליקציות שונות, קשה מאוד להתבלט. ישנו כבר תחום שלם של SEO באפ-סטור (לינק לדוגמה) וסדנאות / יועצים (כובעים לבנים וכובעים אפורים) שיסייעו לכם לקדם את האפליקציה שלכם בתוך החנות. למפתחים עצמיים, זה לא כ\"כ שונה מקידום אתרים אצל גוגל – כך שהמגמה מתקבלת בהבנה.

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

לשימוש באפ-סטור יש בעיות נוספות:

\"מתג המוות\" של אפל – אפל יכולה להסיר מיידית אפליקציה, מבלי לתת הסבר מנומק. זה לא קורה הרבה – אך כשזה קורה, זה יכול לכאוב מאוד למפתח האפליקציה שזו פרנסתו. כנ\"ל לגבי אי-אישור של אפליקציה מסיבה כזו או אחרת.
העמלה שאפל גובה על כל אפליקציה או רכישה בתוך האפליקציה, כ 30%, יכולה להיות מחיר גבוה מדי לחלק מהעסקים, בעיקר לגדולים. העיתון הכלכלי המצליח Financial Times הבין שעבורו 30% זה ההבדל בין \"רווחי\" ל\"לא-רווחי\". אפל לא נותנת הנחות.
FT הסירו את האפליקציה שלהם מהאפ-סטור ועברו ל Mobile Web, שם אין עמלות.
לאפ-סטור יש מערכת דירוג / Review יחידה – עובדה זו מסייעת לצרכן לערוך השוואות, אך מצד שני אפליקציה שמסיבה כלשהי לא ״עוברת מסך״ במערכת הדירוג של החנות – עלולה להיפגע מאוד. בעולם שלפני האפ-סטור, אפליקציה הייתה יכולה למצוא סוג דירוג / ביקורת שמחמיא לה.
מחסור באנליטיקס – כשנקודת המכירה / פרסום היא בידי המפתח, הוא יכול לאסוף מידע דיי מדויק על התנהגות הצרכנים – מידע חשוב מאוד מבחינה שיווקית / הגדרת מוצר. אפל מספקת מידע בסיסי ביותר, גוגל מספקת יותר. כל מיני פתרונות 3rd Party מנסים בדרכים שונות ומשנות להשיג אנליטיקס על האפליקציות שלכם. קצת מידע: לינק1, לינק2.
עדכונים דחופים – אם יש לי בעיית אבטחה קריטית באפליקציה עסקית, הייתי רוצה להגיש תיקון ברגע שהוא מוכן. אם אני משתמש באפ-סטור של אפל – זה אישור של אפליקציה לכל דבר, ויכול לקחת גם שבוע. רק הלקוחות הגדולים ביותר של אפל מצליחים \"לזרז\" ולו במעט את התהליך. כנ\"ל אם אני רוצה לעבוד ע\"פ ה Lean Startup ולשחרר גרסאות באופן תדיר מאוד.
תמיכה – דוחות על תקלות גם הם מוגבלים למה שפלטפורמת האפ-סטור מספקת, וזה לרוב לא הרבה.

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

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

מודלים לרווחים מאפליקציה

מכירת אפליקציות – הלקוח משלם בזמן הקנייה על האפליקציה.
Freemium – יש 2 גרסאות לאפליקציה: גרסה \"Lite\" עם מגבלות / פרסומות המחולקת בחינם + אפליקציה עם יכולות מלאות בתשלום. Freemium היא דרך להתמודד עם החשש של הלקוחות מתשלום על אפליקציה שהם עוד לא ניסו.
פרסום – פרסומות בתוך האפליקציה. פרסומות יכולות לבוא עד כמה-שאפשר כשירות (כמו למשל ב Waze) ולא דווקא \"לתפוס חצי מסך\". מודל זה נפוץ במיוחד באנדרואיד.
In-App purchases – האפליקציה בחינם/תשלום נמוך כאשר לקוחות שרוצים יותר – משלמים על השירות. התשלום יכול לעשות עבור \"כסף משחק\" (לרוב במשחקים), תוכן נוסף (כתבות, מפות) או שירות חד-פעמי שהאפליקציה מספקת. ניתן לראות היום מודל זה גם באפליקציות עסקיות: סוג של גבייה ע\"פ שימוש.
Mobile-Payments או M-Payments – לקיחת עמלה על עסקה שהאפליקציה סייעה לקיימה: ארוחה במשלוח, מוסיקה, הזמנת שירות וכו\'. טכנולוגיית NFC מרחיבה את האפשרויות עבור תחום זה.
מינויים (subscription) – ניתן להוריד את האפליקציה בחינם, אך יש לשלם דמי-שימוש.
קידום לעסק חיצוני – האפליקציה לא מניבה רווח ישיר כלל, אך היא מגבה את העסק שעומד מאחוריה. דוגמה: אפליקציה עם פרטים על רכבי מאזדה (לא ניתן לרכוש רכב באפליקציה). זה מודל נפוץ בקרב עסקים.

נתון חשוב ומעניין הוא שאפליקציות לאייפד נמכרות בממוצע בכמעט פי-5 מאפליקציות לאייפון – למרות שההשקעה איננה גדולה יותר בכמו מידה. העניין הוא שמשתמשי Smartphone משווים את המחיר ל״1$״ – מספר שאפל השליטה, בעוד באייפד נוטים במידה חלקית להשוות את המחירים לאלו של תוכנה על מחשב נייד (Laptop) – הכל עניין של תפיסה.

נתונים רבים נוספים על כלכלת אפליקציות תוכלו למצוא כאן: http://www.visualisations.visionmobile.com

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

—-

[א] ככל הנראה היו ל 10 המפתחים האלו יותר מ10 אפליקציות.

Posted with Blogsy

על חנויות אפליקציה (App Stores)

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

האגדה על מכירה ויראלית (\"כל קונה יספר ל 3-4 חברים ותגיעו למיליון מכירות בחודש\") – לא ממש עובדת.
איש מכירות ייקח מכם בערך 50$ למכירה, מה שישאיר אתכם עם 48$- לעסקה, במקרה הטוב.
פרסומות (שלטי חוצות, עיתונים, רדיו) יעלו עשרות אלפי דולרים, אולי יותר. ספק אם תוכלו לכסות את ההוצאות
נניח שכבר הייתה לכם שיחה אקראית ב\"סנטר\" ועניינתם מישהו באפליקציה, אבל הוא מפחד להתקין על המכשיר מן קובץ ipa[א] ממישהו שהוא לא ממש מכיר!

אם אפל הייתה מספקת רק SDK, ואומרת למפתחים: \"אתם יכולים להפיץ את האפליקציה איך שאתם רוצים! אנחנו לא מגבילים אתכם בכלל\" – ספק אם מישהו היום היה מתרגש מ\"דגם חדש של הטלפון ההוא שנקרא אייפון\".

העסקה (נוסח אפל)

נניח שהיה בא מישהו ומציע לכם את העסקה הבאה:

אני אמכור עבורכם את האפליקציה. אם היא טובה, היא יכולה להימכר בעשרות אלפי, מאות אלפי או אולי מליוני עותקים.
אני אגבה מחיר צנוע: 30% מסכום המכירה. כלומר: 30 סנט לעסקה (לאפליקציה של דולר) – לא תמצאו עסקה טובה יותר!
הסיכון שלכם – מזערי. תשלום של 99$ לשנה בכדי להיכנס לעסקה.
אני אבצע את הפעולה הכספית מול הלקוח, בצורה מאובטחת, במדינות שונות, מול חברות אשראי שונות – אתם תקבלי ממני העברה בנקאית של 70% מסך המכירות (החלק שלכם) בסוף החודש.
אני מתווך מהימן ביותר – לקוחות מרגישים טוב מאוד לרכוש ממני אפליקציות.
אני מתווך מאוד ממוקד: מי שיראה פרסומת לאפליקציה שלכם, הוא רק לקוח פוטנציאלי רלוונטי (עם חומרה מתאימה). לא עוד \"פרסומת לטמפונים שמשודרת לגבר בן 60\".
אם אתם רוצים לשווק את האפליקציה שלכם בחינם – אדרבא, אני אפילו לא אקח עמלת מכירה.

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

הצמיחה במכירות אפליקציות למובייל. מקור: http://kpcb.com/insights/2012-internet-trends-update
CAGR היא גדילה שנתית ממוצעת (במקרה זה אכן נראית כמו טיל).

האפ סטור, אגב, הופיע רק עם ה iPhone 3G – הדגם השני של האייפון, באמצע 2008. למשתמשי הדגם הראשון לא היה אפ-סטור. אם אתם תוהים \"כיצד זה ייתכן?\" – קראו את הפוסט הזה.

בעקבות ההצלחה המטאורית של האפ-סטור של אפל החל לצוץ חנויות מקבילות אצל המתחרים הישירים: Android Market (שאח\"כ הפך ל Google Play), חנות של נוקיה בשם Nokia Store (לשעבר Ovi), מייקרוסופט עם Windows Phone Store.

איך זה עובד?

אפ סטור היא לא רק \"חנות\": זהו ערוץ שלם של הפצה, תשלומים ותמיכה.
על מנת להוסיף אפליקציה לאפ סטור של אפל, יש לעבור תהליך אישור לאפליקציה.
המפתח יכול לשחרר גרסה מוקדמת של האפליקציה בהפצת \"ad-hoc\" לצורך בדיקות תקינות / שימושיות / בדיקות-ביטא למספר מצומצם של מכשירים שהוא יודע את ה Unique Id שלהם. משתמשים של מכשירים אלו בלבד יכולים למצוא את האפליקציה ולהוריד אותה. על מנת לצאת ל\"תפוצה מלאה\" – על האפליקציה לקבל את האישור של אפל.

כשמפתח מגיש את האפליקציה שלו לבדיקה – ~~עליו להגיש את ה source code עצמו~~. תיקון: רק ה binaries נארזים ועל פהם יש static analysis. מסמך NDA דו-כיווני מבטיח שאפל לא תחשוף את הקוד ומצד שני אסור על המפתח לחשוף את ההערות שהוא קיבל מאפל על הקוד שלו, או לפרסם את הסיבה בגינה אפל פסלה את האפליקציה. מסך ברזל קטן, אם תשאלו אותי.
תהליך האישור כולל כנראה כלי Static Analysis אוטומטיים ומרכיב מסוים של בדיקה אנושית. בעבר, התהליך ארך מספר שבועות – אולם מאז הוא התייעל וכיום הוא לוקח לרוב פחות משבוע. בסוף התהליך האפליקציה מאושרת ומשוחררת לאפ-סטור או נדחית עם פירוט הדחייה והצעות לתיקונים – למפתח האפליקציה.

על מה פוסלים אפליקציות? לאף אחד אסור לומר! בכל זאת התגנבו ידיעות על הסיבות הבאות:

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

האפ סטור של אפל בגרסתו הראשונה. מקור: techCrunch

שינוי פרדיגמה

מעבר להצלחה המיידית – נוצר כאן שינוי פרדיגמה משמעותי. רבים מייחסים את ה\"חדשנות\" של אפל לשימושיות הטובה של המכשירים שלה, למוצר הבסיס. אולי דווקא המוצר המקיף (\"Whole Product\") שהוא המכשיר + האפ-סטור או חנות התוכן iTunes הם אלו שבהם טמונה ה\"חדשנות\" המשמעותית-יותר של חברת אפל.

מצד הלקוח: האפ-סטור מאפשר חווית קנייה פשוטה, מהירה ומהנה – ישר מהמכשיר. חוויה שגורמת למשתמש iDevice לקנות יותר.
מצד הספק: האפ-סטור הוביל לכך שאפשר להרוויח מאפליקציות קטנות מאוד שמפותחות ע\"י מפתחים בודדים (איך בדיוק מרוויחים – אולי בפוסט המשך). המתווכים הקלאסיים – נעלמו, ואיתם הוצאות רבות הקשורות להפצה. אפליקציות קטנות => פשטות שימוש => חוויות שימוש טובה יותר של ה Whole Product. אפל טיפלה בכל שרשרת הערך של המוצרים שלה, בלי להשאיר אף חלק ל\"יד המקרה\". הכל הרמוני, seamless, ומוכן לשימוש. דוגמאות נוספות:

אפל איננה ספקית תוכן, אך על מנת שהמוצר שהיא מוכרת (חומרה/תוכנה) יצליח: היא נכנסה לביזנס, יצרה את iTunes, ועשתה את הבלתי-יאמן כשהחתימה חברות מוסיקה גדולות על הסכמים למכירת שירים ב 1$ (עוד בימי ה iPod). חברה אחרת יכלה בקלות \"לחתום על כמה הסכמים עם שותפים\" ולקוות לטוב.
iCloud שירות האכסון / סנכרון בין מכשירים. למי שיש יותר ממכשיר אחד קל מאוד להבין מדוע זה \"נדרש\".

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

Chrome Store – עבור Plugins לדפדפן הפופולרי.
Mac App Store ו Windows 8 Store – אפ סטור למחשבים שולחניים. אם הקונספט עובד היטב למכשירי מובייל, למה שלא יעבוד גם למחשבים שולחניים?
App Stores אלטרנטיביים. בעולם האנדרואיד, היכן שיש חופש ופחות שליטה מרכזית, צצו כ +20 AppStores שונים כמו ה Amazon App Store למכשירי קינדל (תוכן הוא הביזנס העיקרי של אמאזון), אפאיה, LG World או Samsung Apps. יש גם אלטרנטיבות \"מחתרתיות\" לעולם ה iOS, \"מחתרתיות\" כי בסוף הם מפנות לאפ סטור של אפל להורדה.
App Store ל HTML5 apps, כמו זו של מוזילה או OpenAppMarket.
ספקיות הסלולר, בפעם המי-יודע כמה, ובאיחור שגרתי מנסות לחזור למרכז הבמה עם אפ-סטור משלהן: Vodafone, Horizon ואחרים.
App Store קהילתי מסביב לתחום עיסוק מסויים כמו ה SAP Store, לאפליקציות עסקיות (בעיקר סביב מערכות סאפ).
App Store ארגוני המשמש לתוך הארגון.

המעניין מכולם, עבורי, הוא ה Enterprise App Stores, בהם מנסים ארגונים להפיץ תוכנות שהארגון קנה בין העובדים. לארגונים יש כמה נקודות כאב (pain points) ייחודיות:

הארגון קנה \"רשיון רוחבי לכל העובדים\" בסכום גבוה – אבל עובדים רבים לא מודעים לכך ולא משתמשים בתוכנה.
תהליך הרכש בארגון, אפילו לסכומים קטנים, הוא מייגע. מה שהייתי יכול לקנות online בחמש דקות עם כרטיס אשראי עלול לקחת חודש או יותר, כשהוא עובר במערכת הרכש של ארגון גדול.
ניהול רשיונות (מבחינה חוקית + כספית) הוא אתגר לארגון, ש App Store הוא נקודת כניסה נוחה שיכולה לסייע מאוד.

ספקי תוכנה ארגונית כבר מספקים בימים אלו \"App Store ארגוני\" ואפילו גוגל הכריזה על הפצה של Play גם כחנות ארגונית סגורה (SaaS).

אין כמובן מניעה מאפליקציה להפיץ עצמה במספר רב של App Stores, כל פעם תחת חוזה קצת אחר. גם אם אפליקציה תופץ ב 20 App Stores שונים – זה עדיין שבריר ממספר המפיצים / מפרסמים שחברות היו צריכות לנהל עימן קשר עד לא מזמן, בכדי להפיץ תוכנה.

סיכום

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

ישנם חסמי כניסה נמוכים יותר כך שמפתחים בודדים / חברות קטנות יכולים להתחרות בחברות גדולות יותר. ~~אי אפשר~~ קשה יותר \"לשלוט\" בערוצי ההפצה, כפי שחברות גדולות נהגו לעשות, כדי לפגוע בתחרות.
קל יותר, למשל, למכור באמריקה תוכנה שנכתבה בסין – הגבולות הגיאוגרפים מטשטשים אפילו יותר.
התוכנה צריכה לעשות רושם ראשוני חיובי ומייד – אחרת המשתמש יחזיר אותה (החזרה תוך רבע שעה ב Google Play) או בכלל לא יקנה אותה (אם ה screenshots לא נראים לו).

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

—

[א] IPhone Application = ipa

שיקולים בעיצוב אפליקציות מובייל

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

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

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

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

The Hotzone – האזור בו אצבע המשתמש חופשיה ועלולה להקיש (tap) בטעות. כדאי להרחיק את האזורים הלחיצים ממנה. מקור: http://answers.oreilly.com/topic/1802-designing-iphone-apps-the-rule-of-thumb/

חשבו היכן ניתן לצמצם, לא היכן ניתן לעשות יותר

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

"פרויקט התאמה" קוראים לזה, Mobile Adaptation או Mobile Enablement ומנסים, בעזרת צוות של כמה מפתחים ואיש UI חסר מזל, "לדחוס" את האלמנטים הגרפיים ממסך של "22 למסך של "4.
בעוד ב Desktop יש עכבר שהוא כלי הצבעה דיי מדויק, במובייל אזורים לחיצים צריכים להיות גדולים בהרבה – מה שמותיר מקום מועט אפילו יותר לתוכן שעל המסך.

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

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

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

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

מה ניתן היה לעשות אחרת?

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

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

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

ככלל אצבע, לאפליקציית מובייל טובה לרוב יהיו:

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

אם אתם נתקלים באפליקציה מובילית שלא שונה מהאפליקציה השולחנית באף אחד ממימדים אלו – זהו סימן אזהרה ברור. אפשרי בהחלט שאיש ה UI שלכם מקובע, או בכלל לא מבין את השוני שנובע מעצם אפליקציות המובייל. שקלו לאתגר אותו, לחשוב ולעלות שאלות על האופן של השימוש בפליקציה תוך כדי עמידה במסדרון או ביקור אצל לקוח.חשבו לדוגמה על ההבדל בין אאוטלוק ל Mail ב iPhone: כמה עשרות, אולי מאות, פונקציות של אאוטלוק לא מצאו מקבילה בגרסת המובייל? בכל זאת, השימוש באפליקציה הוא נוח למדי ומתאים למרחב רחב מאוד של משתמשים.
דוגמה נוספת: חשבו על המקלדת של המובייל מול מקלדת של Desktop, איפה כל כפתורי ה F-masheu? כיצד ביטלו את כפתור ה del (מחיקה ימנה) וניתן להסתדר רק עם מחיקה שמאלה[ב]?

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

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

הקלדה היא מאמץ מוגבר – שמור עליה

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

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

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

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

ססמאות בנייטיב אפ – במערכות ווב שדורשות הקלדת משתמש / סיסמה, דבר מקובל הוא לייצר מעטפת (למשל PhoneGap) שתשמור את הסיסמה ב Secured Storage של המכשיר. יכולת זו בלבד מצדיקה שימוש ב PhoneGap ופיתוח Hybrid App.

אל תצפה ממשתמש לנווט במסך של 4 אינץ'

חיפוש – הוא סוג הניווט המועדף. ללא פירורי לחם (breadcrumbs) ובטח ללא עץ ניווט. רשימת הפריטים האחרונים / הנפוצים יכולה להיות גם נקודת פתיחה טובה (חשבו על ה App Store).

שמור קצת מידע בצד ליום סגריר (connectivity issues)

אלו אלמנטים שקצת יותר קשורים למימוש הטכני מאשר להגדרת השימושיות per se.

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

Offline הוא לא "לוקסוס". זוהי יכולת דיי בסיסית (בעיקר עבור Web) – כיום, רוב האפליקציות המובייל הארגוניות נכתבות עבור אנשים בשטח: אנשי מכירות, נהגים, יועצים. כנראה אלו הם אלה שזקוקים להן הכי הרבה. ראיתי כמה פעמים ששומרים את היכולת לתפקד Offline לשלב מאוחר ביותר בפיתוח המוצר, תחת ההרגשה שמסתתר פה פיתוח יקר וגדול. Offline מלא היא כמובן בעיה, אך יכולת Offline בסיסית כגון לקבל מסך אחרון (ולא 404) ולקבל הסבר יפה שצריך רשת – אם מנסים לעשות פעולה, הוא פיתוח מינימלי שיכול להשפיע רבות על חווית השימוש באפליקציה. יש קובץ manifest כחלק מ HTML5 שעושה עבורכם את רוב העבודה. הייתי שוקל ברצינות לכלול "נפילה רכה ל Offline" שכזו, כבר בגרסה הראשונה. לפחות אם מדובר באפליקציה שתשרת אנשים מחוץ למשרד.

סיכום
בקיצור: כל אלו הן נקודות שכדאי לשים לב אליהן. סוג חשיבה שכדאי לאמץ במובייל.
נסו לשים לב כיצד אפליקציית המובייל שאתם מפתחים משתלבת בחשיבה זו ונסו לעבוד עם מאפיין ה UI על מנת לשפר את השימושיות שלה. הימים בהם מפתחי אפליקציות "לא צריכים להבין כלום בשימושיות" הולכים ונמוגים…

בהצלחה!

—-

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

הרצאה בנושא פיתוח ווב למובייל בפורום אנשים ומחשבים

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

הנה הלינק למצגת בה השתמשתי.

עברתי עליה והוספתי עליה notes בעברית על מנת לעשות אותה קריאה גם למי שלא היה בהרצאה.
יש להוריד (file->download) את קובץ ה PPT בכדי לקרוא את ה notes. אמרו לי אם אתם נתקלים בקשיים.

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

טרנדים חמים בתחום ה Web וה Mobile – חלק 1

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

HTML5 + CSS3
לא ניתן לדבר על עולם הווב והמובייל בשנה האחרונה מבלי לדבר על HTML5. זה יהיה כמו לדבר על מבנים גבוהים בת\"א… מבלי להזכיר את מגדלי עזריאלי. זהו המובן מאליו.

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

אלמנט פחות מביש, ואפילו דיי שימושי, היא היכולת לייצר תג (\"Badge\") שמציין את האלמנטים של HTML5 שהאתר שלכם משתמש בהם – ולפרסם זאת. ללא התג – יהיה קשה למדי לדעת במה השתמשתם, אבל ככל שהוא מופיע בעוד ועוד אתרים אנו מקבלים את התחושה ש HTML5 \"כבר כאן\" והגיע הזמן לשקול ולהשתמש בו.
יש בו גם אלמנט של Gamification: כל פעם שהוספתם יכולת-בסיס של HTML5 אתם מקבלים עוד \"אייקון\". מי יודע – אולי יתפתח בכם צורך בלתי-נשלט \"להשלים את כל הסריה\". עצם העובדה שאחד הסמלים ב Badge מסמל CSS3, שאינו חלק ממטריית התקנים [1] של HTML5 – היא עובדה זניחה. לא ניתן לפרט שולי שכזה להפריע בקמפיין מוצלח.

מעבר לקידום המכירות, שמשמעותו לדעתי יחסית זניחה, הסיבה העיקרית להצלחת HTML5 היא עקשנותו של סטיב ג\'ובס לא לתמוך ב Flash על המכשירים של אפל. אתרים שרצו ליהנות מקהל היעד החדש נאלצו לחפש אלטרנטיבה לפלאש (או Silverlight או Java Applets – מכשירי אפל לא תומכים באף אחד מהם) – ו HTML5 היה האלטרנטיבה הנראית היחידה. מאותו הרגע HTML5 התקדם בקצב מסחרר, הן בצד האתרים שמשתמשים בו והן בצד התמיכה מצד הדפדפנים. גוגל (+Chrome for Android 4) ומייקרוסט (Windows 8 Metro Experience) שהחליטו גם הן להפסיק לתמוך ב Flash – סגרו סופית את הגולל ופתחו את דרך המלך ל HTML5.

ציון תאימות ל HTML5 עבור דפדפנים שולחניים. מקור: html5test.com

ציון תאימות ל HTML5 עבוד דפדפנים לסמארטפונים. מקור: html5test.com

קוריוז קטן הוא זהות הדפדפן עם התמיכה הטובה ביותר ב HTML5 נכון ליום זה (הנתונים משתנים מרגע לרגע). מנחשים??
לא Chrome של גוגל, לא ספארי ובטח לא Internet Explorer שמתשרך הרבה מאחור. דווקא Maxthon, הדפדפן הסיני מבוסס IE (במקור) זוכה לציונים הטובים ביותר. בעלות משותפת עם גוגל היא אולי הסבר שירגיע כמה מהקוראים מהפחד \"הסינים באים\" [2].

בואו נעבור לכמה טרנדים חמים ואולי פחות מוכרים מ HTML5:

עיצוב סתגלן Responsive Design
עקרון זה מדבר על בניית אתר אינטרנט (לרוב תוכן שברובו סטאטי) שיודע \"להתאים את עצמו\" לכל מכשיר ומצב. גם משתמש בדפדפן שולחני על מסך \"24 וגם מכשיר מובייל עם מסך \"3 – יוכלו לצפות באתר בהנאה.

איך עושים את זה? התבוננו למשל באתר הבא: http://mobilism.nl/2012 ממחשב שולחני / לפטופ. עכשיו לחצו על הכפתור, בפינה העליונה של החלון, שגורם לחלון של הדפדפן לא להיות maximized והתחילו להצר את רוחב החלון של הדפדפן עוד ועוד. שימו לב אילו שינויים חלים באתר ומתי. הנה עוד דוגמא.

המימוש המקובל לעקרון זה הוא שימוש ב CSS media Queries – מנגנון שמאפשר לכם לכתוב אתר ב HTML פעם אחת והתאים קובצי CSS שונים לטווחי רזולוציה (או Orientation) שונים. מכיוון ש CSS3 הוא דיי חזק – אתם יכולים לשנות את העיצוב בצורה דיי דרמטית: Layout, תמונות, רקעים ועוד.

CSS Media Queries, אגב, סובל כיום ממגבלה והוא יוריד את כל התמונות של כל המצבים על מכשיר iPhone למשל. ניתן להימנע מבעיה זו ע\"י התערבות ב JavaScript או בצד השרת על מנת לטעון רק את הקבצים שבשימוש.

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

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

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

הגדירו baseline של החומרה / סט היכולות הכי מצומצם בו תרצו לתמוך.
בנו אפליקציה עם פונקציונליות ושימושיות טובה מספיק בכדי להיות בעלת ערך, על בסיס ה baseline שלכם. לרוב הפיתוח יעשה על הרזולוציה הקטנה ביותר שאתם מתכוונים לתמוך בה.
העשירו את האפליקציה שלכם ביכולות נוספות (לרוב אלה יהיו שיפורי – נוחות, לא פונקציות קריטיות לעבודה) על בסיס חומרה זמינה: יותר מסך = יותר פרטים או קיצורי דרך זמינים. קיומו של GPS יכול להיתרגם למידע מותאם למקום או defaults חכמים יותר. יותר זיכרון או כוח עיבוד יכול להיות autocomplete שיחסוך הקלדה למשתמש וכו\'.

עקרון משנה, שגם הוא נפוץ, נקרא \"Mobile First\": כאשר אתם מתכננים אפליקציה אל תתחילו בעיצוב ל desktop כי אם ל mobile ובתור עקרון. יש בכך 2 יתרונות:

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

ספרייה שהיא בגדר \"חובה\" לפיתוח בשיטת ההעשרה המדורגת היא Modernizr – סיפרית JavaScript שמזהה יכולות של המכשיר ו/או הדפדפן בו אתם רצים: תומך ב colors input של HTML5 או לא תומך. תומך ב SVG או לא. יש GPS או לא.

הניסיון לעשות חישוב \"זהו אייפון 4 ולאייפון 4 יש GPS\" הוא אולי סביר בעולם ה iOS – אך חסר כל סיכוי בעולם ה Android בו יש כל-כך הרבה מכשירים.

JavaScript Micro-Frameworks
בכדי להכיר לכם את הטרנד הזה, אתחיל בדוגמא ספציפית למדי. הכירו נא את Zepto.js – מתחרה חדש שקם ל jQuery.
jQuery, כפי שאתם יודעים, הוא סטנדרט דה-פאקטו. זו ספריה מהירה, יציבה ובעלת קהילה ענקית ופעילה. ישנם מאות פלאג-אינס ל jQuery. היו לה מתחרות, אך jQuery יצאה מול כולן כשידה על העליונה.

מדוע אם כן שמישהו ישתגע ויחליף את jQuery שהוא כבר אוהב ומכיר? למה להחליף סוס מנצח?
אם תתבוננו ב Zepto, היא נופלת מ jQuery בכמעט כל פרמטר אפשרי:

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

אבל… בעוד jQuery מספקת קובץ בגודל 78K בגרסת ה minified (גודל ה GZip הוא פחות רלוונטי) – Zepto עושה הכל ב 6K בלבד – פחות מעשירית!

השוואת הגודל של ספריות נפוצות ל DOM Selection, במצב קוד מקור, מצומצם ומצומצם + דחוס. מקור: webappers.com

מה שעושה את ההבדל הוא הזיכרון המצומצם של מכשירי המובייל. מכשיר אייפון למשל, לא ישמור ב cache קבצים (javaScript, CSS או תמונות) שגדולות מ 25K בזיכרון. \"בזיכרון\" = לאחר הפריסה של קובץ ה Gzip.
ההבדל בין Zepto.js לבין jQuery היא היכולת להיות ב cache של דפדפן במכשיר מובייל. האלטרנטיבה היא להביא את הקובץ, כל פעם, ברשת 3G יקרה ואיטית.

Zepto.js היא רק דוגמא אחת לטרנד הולך וגובר בו מוחלפות ספריות \"שלמות ועשירות\" (כגון jQuery Mobile, QT Touch או מקרה הקצה – Sencha Touch), בספריות קטנות ויעודיות שעושות \"רק דבר אחד\", עושות אותו באופן ממוקד וטוב, ועושות אותו למובייל. \"סופסופ לא צריך לתמוך ב Internet Explorer\", נאנחו לרווחה מפתחים רבים והחלו לכתוב ספריות פשוטות יותר למובייל. עם הצגת שיתוף הפעולה בין מייקרוסופט לנוקיה ייתכן שדברים יישתנו.

MicroJs, הוא לדוגמא, אתר שכולו מוקדש לאיסוף ספריות שכאלו – ויש כבר עשרות רבות.

עמוד הבית של microjs.com

ביטוי אחר של מגמה זו היא היכולת שנותנות ספריות מסויימות ל\"ארוז\" ולהוריד רק פונקציות מסויימות. הנה דוגמא מ Modernizer והנה דוגמא מ jQuery UI. שמועות (מקור) אומרות שגם jQuery יציגו יכולת כזו בקרוב. נשמע לי כמו תגובה לתחרות מ Zepto.js. תגובה שיכולה להיות דיי מוצלחת, לדעתי.

עדכון: יום לאחר שפירסמתי את הפוסט נשאר לי קובץ התמונה, Zepto.png שמוצג למעלה, על שלוחן העבודה. במקרה הבחנתי שמדובר בקובץ בגודל 76K. בעזרת דחיסה פשוטה ל Jpeg באיכות גבוהה הקובץ הפך ל 18K. אני יודע שחלק לא קטן מקוראי הבלוג משתמשים במכשירי מובייל ולכן מעתה, אני אשתמש בתמונות בפורמט JPEG ולא ב PNG.

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

בהצלחה!

—————–

[1] HTML5 אינו תקן אחד אלא רשימה של כמה וכמה תקנים המתארים יכולות חדשות לדפדפנים שאינן תלויות זו-בזו. לדוגמא \"HTML5 סמנטי\" שמאפשר מבנה תגים שמתאר את התוכן בצורה יותר טובה או \"Web Workers\" – היכולת להשתמש ביותר מ thread אחד כדי לבצע חישובים ברקע. HTML5 היא פשוט השם הקל לתאר את אסופת כל היכולות השונות.
נ.ב. דרך קלה לדעת איזו יכולת נתמכת איפה היא להשתמש באתר המצוין http://caniuse.com/

[2] להזכיר: זה שאתה לא מפחד, לא אומר שלא רודפים אחריך.