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

מה זה Wix?

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

The post בניית אתר בוויקס או וורדפרס – מה עדיף Wix או WordPress לבניית אתר appeared first on SideCode.

וובינר אשר התקיים ב- 27.11.2016,  בנושא Offshore Services, והועבר על ידי גל מוסקוביץ, מנכ״ל GRapps.

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

הצגה וניתוח (Case Studies) של צוותי Offshore שהוקמו על ידי GRapps עבור לקוחותיה, מבנה הצוותים, הצגת עלויות,  הצגת המעטפת הכוללת הישראלית שמלווה את צוות הפיתוח עצמו.

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

נתראה בוובינר הבא!

The post וובינר GRapps – שירותי מיקור חוץ appeared first on SideCode.

מהו שרת?

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

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

אוקיי, אבל איך בונים שרת עבור אפליקציית מובייל?

בטח שמעתם מושגים כמו: פרוטוקולים, HTTP Requests, responses, JSON, Database, OAuth, API, REST API וכו׳. למעשה יש קונספט אחד שחשוב להבין, כאשר בונים שרת עבור אפליקציית מובייל, מה שבפועל בונים זה שפה בין אפליקציית המובייל והשרת, שפה ששניהם מבינים ושעוזרת להם לבצע אימות בין אחד לשני, העברת מידע מאחד לשני ותקשורת באופן כללי.

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

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

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

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

למה לא להשתמש בפתרון של שירות צד שלישי?

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

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

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

The post שרת עבור אפליקציית מובייל, למה זה נחוץ ? appeared first on SideCode.

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

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

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

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

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

אתם יכולים לקרוא על כך בהרחבה כאן: שרת עבור אפליקציית מובייל, למה זה נחוץ ?

איזו טכנולוגיית צד שרת טובה עבור אפליקציית מובייל?

ניתן לבנות צד שרת לאפליקציה על ידי כמעט כל הטכנולוגיות צד שרת שקיימות היום, ויש דיי והותר טכנולוגיות ושפות תכנות לבחור מתוכן: PHP, .NET, NodeJS, ג׳אווה, פייטון, Rails, ועוד טובים ורבים.

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

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

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

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

האם כדאי לפתח אפליקציית מובייל Native או היברידית?

בואו נדבר על ההבדלים לשנייה.

פיתוח אפליקציית Native אומרת שאתם הולכים לפתח שתי אפליקציות נפרדות באמצעות שתי טכנולוגיות ושפות נפרדות. אתם הולכים לבנות אפליקציית Native באמצעות ג׳אווה ואפליקציית iOS באמצעות Objective-c או Swift. מה שיצריך לפחות שני מפתחים עם יכולות פיתוח שונות מאוד אחת מהשנייה.

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

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

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

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

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

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

The post פיתוח אפליקציית Web או מובייל – באיזה טכנולוגיה כדאי לפתח אפליקציה? appeared first on SideCode.

שלב ראשון: זהו את הבעיה

״אבל יש אפליקציות אחרות כבר בחנויות שפותרות את אותה הבעייה״

שלב שני: מצאו את הפיתרון

שלב שלישי: יצירת מסמכי אפיון, ועיצוב חווית המשתמש (UX)

יצירת מסמכי אפיון

יצירת שרטוטי אפליקציה (WireFrames) או אבטיפוס (MockUps)

הפיכת השרטוטים לעיצוב

סט מסמכי תהליך האפיון, עיצוב וחווית המשתמש

אלו התוצרים אשר יהיו בידכם עם סיום שלב חשוב זה:

• מסמכי אפיון מפורטים
• שרטוטי עיצוב או Prototype
• מסכים מעוצבים

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

שלב רביעי: פיתוח גרסה ראשונה של אפליקציית המובייל

אם יש ברשותכם תקציב לכך, ההחלטה הטובה ביותר תהיה לפנות להשכרת שירותי חברה לפיתוח אפליקציות על מנת לבנות את האפליקציה שלכם. חברת פיתוח אפליקציות רצינית כנראה תוכל לפתח אפליקציה איכותית מאוד בפרק זמן קצר, במקרים רבים ה time to market הוא קריטי עבור היזם ולכן חייבים לתת לכך משקל ראוי. אם המוצר ייבנה על ידי חברה לפיתוח אפלקציות טובה, כנראה שייוקצה צוות שלם שיעבוד על המוצר, כאשר כל חבר צוות מומחה בתחום שלו. מומחי הפיתוח בחברות אלו מתמודדים יום יום עם אתגרים פיתוחיים מגוונים, חיים את התחום ואת הטכנולוגיות המעורבות, יודעים איך לעמוד בתנאים וההגבלות (המוגזמים לעיתים) אשר מכתיבה Apple ב- App Store והצוות יידע לנצל ידע זה לטובת האפליקציה שלכם לכל אורך תהליך הפיתוח.

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

יכול להיות שתחליטו לפתח גרסא ראשונה של האפליקציה בעצמכם, דבר שלגמריי אפשרי, אולם, קחו בחשבון שעל מנת לבצע זאת צריכים להיות לכם היכולות של Full Stack Developer (היכולת לכתוב קוד Front-end & Back-end )  – בנוסף, קחו בחשבון שלפתח אפליקציה בעצמכם הולך לגזול ממכם המון שעות. כמו כן, כנראה שתצטרכו גם אפליקציית iOS וגם אפליקציית אנדרואיד, וזה אומר לדעת המון שפות פיתוח. כמו כן, חשוב לדעת שבמידה ותמשיכו לשלב ב׳ באבולוציה של האפליקציה, יכול להיות שהקוד שלכם, היות ולפחות חלקו חובבניֿ (לא בטוח, רק אולי), יכול להיות שיגרור המון שעות פיתוח בשלב ב׳, אולי אפילו יצריך כתיבה מחדש. שורה תחתונה – אם אתם בעל ידע טכנולוגי ברמה גבוהה ומוכנים להרפתקאה, צללו פנימה, תהנו ותיצרו גרסה ראשונה של האפליקציה שלכם (MVP) ותממשו את האפיון על הצד הטוב ביותר, במידה ולא כנראה שעדיף שתשכורו שירותים של חברה מקצועית.

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

ברגע שהאפליקציה מוכנה, ואתם מרוצים מהמוצר, אתם יכולים וצריכים לשחרר לחנויות (App Store, Google Play, Amazon). שנייה לפני שתעשו זאת, וודאו ששילבתם באפליקציית המובייל לפחות כמה טכנולוגיות על מנת לקבל תובנות ופידבק מהמשתמשים, שילוב למשל של: Google Analytics, AppsFlyer, או כל כלי מצוין אחר שיתרמו לכם במעקב אחר התנהגות היוזרים באפליקציה, יעזרו לכם מאוד בניתוח הנתונים ובכך תוכלו ללמוד איך לשפר את המצור בגרסה השנייה שלו בהתאם ל KPIs (מדדי ביצוע) שהגדרתם מראש. בניתוח הנתונים, שימו לב לפיצ׳רים שמקבלים פידבק חיובי, מה הדברים הפחות טובים באפליקציה, אילו התנהגויות חריגות (לחיוב או לשלילה) אתם מזהים ועוד.

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

The post שלבי פיתוח אפליקציה – משלב הרעיון ועד לאפליקציית מובייל בחנויות appeared first on SideCode.

Now, I don’t judge anyone. Although, in my opinion the Lean UX is better for entrepreneurship. Let me explain my position in two examples.

Let’s take for example an X-training app and develop it with Lean UX:

1. The first step would be to create the stick figure, which shows exercises to the users. In this app, you don’t need to read about how to do it correctly – simply listen and watch.
2. Place the application in the market and get the feedback. During this time, you’re asking some questions. For example, is it easy to use, do you like the buttons or etc.
3. On these bases (consumer’s feedback), you’re improving the app and adding the setting to manage the time (for example). So, the users can set a time for the training. Perhaps, someone want to exercise 5 minutes, the others 30.
4. You show it to the public again and get the feedback. You are asking whether it’s comfortable to use and what else do you want to see in it.
5. For example, you get from the feedback that consumers do not like the stick man. So, the solution would be to change it on the girl/boy/monster (or users could pick someone on their taste).
6. Let’s say that you get the positive feedback from the last changes and there no any suggestions from the consumers. Thus, you accomplish the app with the nice boy’s/girl’s/monster’s expressions and the application is done.

If to summarize, you get the product that based on the consumers’ needs and preferences. Doubtless, it’s cordially deferent from the Agile UX methodology.

The approaches’ difference lays in the process. Let’s take the X-training app again and see what we get:

1. You create the app that based on the clients vision, analyze the market, test it, improve it and then get it to the public.
2. There are several professional teams, which work in the development process. Yes, there are developers, designers, marketers and oftenly it cost a lot to manage these teams.
3. Occasionally it happens that the app is not very popular, because it based on the client’s vision. So, you need to improve it. Thus, you manage the teams again and search for solution.

From these facts, you may conclude that Agile UX produces a more polished product and Lean UX produces multiple products of increasing polish. It’s the essential difference between the approaches.

Now, what’s make me to advocate the Lean UX? It’s that you get the product, which based on the consumers’ needs. So, what is good for the customers – get’s you more gain. Although, it’s only my opinion, you might have the other.

The post What’s the difference between Agile UX and Lean UX? appeared first on SideCode.