HTML5 לעומת מודעות מותאמות

דיון בנושא אפליקציה לנייד

מייקל מאהוף
מיכאל מאהומו

מבוא

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

עושר בתכונות

נקודה: התכונה 'מודעות מותאמות' יכולה לעשות יותר

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

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

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

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

זה נכון שהרבה תכונות בתוך האפליקציות לא זמינות באפליקציות HTML5. לא משנה עד כמה מיומנויות ה-Web-fu שלכם חמות, אם האפליקציה תקועה בארגז חול ללא ממשק API של המצלמה, היא עדיין לא תצלם בקרוב! למרבה המזל, אתם לא צריכים להיות בארגז החול הזה. אם אתם צריכים שאפליקציית האינטרנט שלכם תוכל לצלם תמונה, תוכלו ליצור אפליקציה מקורית, שכזו עם תצוגת אינטרנט מוטמעת שמספקת את רוב ממשק המשתמש. כך פועלת מסגרת PhoneGap בקוד פתוח: היא משלימה את הפער על ידי חשיפת תכונות מקוריות כשירותי אינטרנט, שהרשת מציגה קריאה באמצעות ממשק API סטנדרטי של רשתות. כשיוצרים אפליקציה היברידית כזו, אפשר גם להשתמש בתכונות הפלטפורמה האלה, כמו ווידג'טים, התראות וכוונות.

יצירת אפליקציה היברידית בשילוב עם אתרים באינטרנט היא כמעט לא פתרון אידיאלי. היא מוסיפה מורכבות והיא חלה רק על אפליקציות אינטרנט שעוטפות כאפליקציות מקוריות, ולא על אתרים מסורתיים שהגישה אליהם מתבצעת מדפדפן לנייד. אבל ייתכן שלא יהיה צורך במשך זמן רב. תקני האינטרנט מתפתחים במהירות, ודפדפנים ניידים מודרניים ממשיכים לעמוד בקצב. אחסון אופליין, מיקום גיאוגרפי, גרפיקה על קנבס והשמעת וידאו/אודיו נהנים מתמיכה נרחבת בקרב smarpthones מודרניים, למשל. כבר יש תמיכה במצלמה – החל מ-Android 3.1 אפשר לצלם תמונות וסרטונים באמצעות תקני אינטרנט. הדפדפן האחרון ל-iOS תומך ב-WebSocket לסטרימינג דו-כיווני, וגם בזיהוי כיוון המכשיר.

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

היעד של מודעות מותאמות הוא נושא שזז במהירות, אבל האינטרנט מצמצם את הפער הזה.

ביצועים

נקודה: מודעה מותאמת פועלת מהר יותר

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

נקודה נגדית: זמני הריצה באינטרנט מהירים הרבה יותר היום, וממילא רוב האפליקציות לא צריכות את המהירות

יהיה קל לומר שהאינטרנט הפך למהיר יותר בשנים האחרונות. V8, מנוע ה-JavaScript שמגיע עם Chrome, היה פיתוח חשוב בביצועי אינטרנט כשהשקנו אותו, ומאז הוא רק הפך למהיר יותר:

תרשים ביצועים של V8

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

תרשים בד ציור מואץ של חומרה

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

עדיין לא כל הפיתוחים במחשבים עשו את דרכם לכל הפלטפורמות לנייד, אבל המגמות מצביעות על כך שהם בדרך. חשוב גם לציין שרוב האפליקציות לנייד אינן משחקים תלת-ממדיים מתקדמים, אלא מבוססות על מידע בסיסי: חדשות, דואר, לוחות זמנים, רשתות חברתיות וכו'. מומלץ להיכנס לכמה אתרים מהנייד, כמו GMail, Amazon ו-Twitter, ולוודא שהביצועים באינטרנט לנייד יותר טובים. כשמדובר במשחקים, ניתן כבר להשתמש במשחקים בסיסיים באמצעות בד ציור 2D, ו-WebGL מתחיל להופיע בניידים - ראו Firefox 4. עד שתרחבו את התפוצה, יש משפחה הולכת וגדלה של frameworks שמקבצים אפליקציות WebGL לאפליקציות מקוריות שיכולות להפיק תועלת מ-OpenGL, כמו ImpactJS.

חוויית המפתחים

נקודה: קל יותר לפתח את Native

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

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

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

קודם נדון בטכנולוגיה העיקרית. זה נכון שסטנדרטים באינטרנט נוצרו במקור בעידן שבו האינטרנט היה בעיקר על מסמכים, ולא אפליקציות, כש-JavaScript נוצר ונפרס תוך 10 ימים בלבד! אבל הם הוכיחו שיש להם יכולות מתקדמות הרבה יותר מכפי שציפו – מפתחי אתרים למדו למנף את החלקים הטובים ולטפל בחלקים הגרועים, בעזרת דפוסים שכיום מתאימים לתכנון ניתן להתאמה. בנוסף, הסטנדרטים לא עומדים במקום, והמאמצים כמו HTML5 , CSS3 ו-EcmaScript Harmony משפרים את חוויית המפתחים. אם אתם מעדיפים את C++ או Java, או אם JavaScript הוא נושא לדיון דתי, וזה תלוי גם בבסיס הקוד שלכם מדור קודם. אבל אנחנו בהחלט יכולים לכלול את JavaScript כמתמודד רציני בימים אלה.

הצד השני לפיצול של דפדפן/זמן ריצה הוא העובדה שכל הסביבות האלה קיימות מלכתחילה. פתחו אפליקציה ל-Android ב-Java, ונתקלתם ביציאה מלאה ליעד C לצורך תמיכה ב-iOS. עליכם לפתח אפליקציית אינטרנט פעם אחת והיא תפעל ב-Android וב-iOS, שלא לדבר על WebOS, BlackBerry, Windows Mobile ו... ובכן, זו התיאוריה בכל מקרה. בפועל, אם אתם רוצים לקבל את החוויה הנכונה, תצטרכו לבצע התאמות בכל פלטפורמה. אבל תצטרכו לעשות גם את זה במקור, ברוב מערכות ההפעלה לנייד יש גרסאות שונות ומכשירים שונים.

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

מראה ומרגישים

נקודה: המותג 'Native' מתאים את המראה והתחושה של הפלטפורמה

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

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

נקודה נגדית: לאינטרנט יש מראה ואווירה משלו, וניתן גם להתאים אישית את ממשק האינטרנט לפלטפורמות שהכי מעניינות אתכם

כפי שהוסבר בחלק הקודם, הדרך של פיתוח אתרים היא לכתוב גרסה בסיסית ש-"one size fits all", ואז לשפר אותה בהדרגה. השיפור הזה מבוסס בדרך כלל על תכונות, אבל אפשר גם לשפר אותו על ידי טירגוט לפלטפורמות החשובות ביותר. זהו סוג של 'זיהוי דפדפן', שלפעמים מתעלמים בו בקרב קהילת האינטרנט, בעיקר כי יש כל כך הרבה דפדפנים אפשריים. אבל אם אתם רואים שתיים או שלוש פלטפורמות עם עדיפות גבוהה מאוד, ואתם מוכנים להשקיע מאמץ נוסף כדי לעמוד בהשוואה לחלופות מקוריות, זו עשויה להיות הדרך שלכם.

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

יכולת גילוי

נקודה: קל יותר לגלות אפליקציות מקוריות

מנגנוני הפצת אפליקציות, כמו Android's Market ו-App Store של Apple, הפכו לפופולריים ביותר בשנים האחרונות, והם כוח מניע עיקרי בכל תעשיית המכשירים הניידים. כל מפתח יכול לשלוח את האפליקציה המקורית שלו לזירת המסחר, שבה המשתמשים יכולים לגלות אותה באמצעות שילוב של גלישה, חיפוש וקבלת המלצות. בנוסף, אם עשיתם את העבודה כמו שצריך, התגובות והדירוגים המוארים ישכנעו את המשתמשים ללחוץ על לחצן ההתקנה החשוב.

נקודה נגדית: למעשה, קל יותר לגלות אפליקציות אינטרנט

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

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

מונטיזציה

נקודה: ניתן לייצר הכנסות ממודעות מותאמות

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

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

נקודה נגדית: תמיד אפשרו לייצר הכנסות באינטרנט, וההזדמנויות גדלות.

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

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

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

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

מסקנות

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

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

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