אז מה שונה?
אנחנו רגילים לכתוב אפיונים לתהליכי SAP, נכון? שדות, מבנים, תיאור פונקציונלי, ג'ובים ליליים וכל מה שביניהם. אבל מה קורה כאשר נדרש לעצב מסך? מה קורה אם אנחנו רוצים לספק חוויה חדשנית וזה גם אמור לעבוד על מכשירים ניידים?
בדרך כלל אפיון אפליקציית WebDynpro או דוח ALV (חס וחלילה) נכתב על ידי מיישם במודול הספציפי. במקרה הטוב את הדרישות מעבירים למפתח ABAP \ WebDynpro עם חוש עיצוב. אבל במקרה של SAPUI5 מדובר בבניית חווית משתמש (UX) ולא סתם עיצוב מסך, ולכן הדרך להצליח קצת שונה – אנחנו כבר נדרשים לצאת מהקופסה של SAP, לאפיין חוויה, להוריד שדות וכפתורים לא רלוונטיים, לחשוב בצורה שהיא User Oriented ולא Process Oriented.
ההבדל בין UX ו-UI
אלו שני מונחים שמלווים אותנו בשנים האחרונות – והפכו להיות מאוד מרכזיים בתחום מערכות מידע. אז בואו נבין מה ההבדל פעם אחת ולתמיד:
UI – ממשק משתמש, בעיקר עיצוב גרפי של המסך.
UI – ממשק משתמש, בעיקר עיצוב גרפי של המסך.
UX – חווית משתמש. הדמיית תהליך עבודה ואפיון פונקציונלי.
שלבי האפיון
- תגדירו את העיקר
מי הלקוח \ האוכלוסיה?
מה התצורה של האפליקציה?
האם היישום הולך להיות בשימוש במכשירים ניידים?
האם מדובר באפליקציה להצגת מידע בלבד או גם יצירה \ עדכון?
האם האפליקציה אמורה לעבוד ב-Standalone או רק דרך Fiori Launchpad?כל הדברים האלה מאוד חשובים בשלב בניית השלד האפליקטיבי. - הגדירו את המסכים ואת הניווט ביניהם
המרכיבים המרכזיים ביישום UI5 הינם מסכים – פירוט ברמת רשימת מכולת יכול מאוד לסייע בשלב הראשוני. ואם כבר מכינים רשימה של מסכים – אז אפשר לרדת לרזולוציה של הניווט (מאיזה מסך אפשר לנווט למסך אחר) – זה כבר Wireframeבסיסי. מפה מומלץ לרדת לרזולוציה של מידע המוצג בכל מסך ומסך – לפחות ברמת כותרת, זה יעזור גם לאיש UX וגם למפתח UI5. - תכינו Mockup
חשוב להניע את התהליך של אפיון הפתרון עם איש UX ולא מיישם SAP. לפי הנסיון שלנו – הערך המוסף של אנשי UX באפיון חווית משתמש ובניית אבטיפוס הינו אדיר. איש UX חוסך הרבה מאוד שאלות שעלולות להגיע ממפתח UI5 – ולרוב המיישם SAP לא יוכל לענות עליהן. בשלב בניית האבטיפוס מומלץ כבר לפרוס את השמות הטכניים על גבי ה-Mockup.
- תגדירו שדות \ מבנים \ קשרים
העקרון המוביל בבניית שירותי ODATA הוא פירוק של פונקציות מורכבות גדולות לפונקציות יותר "קלות" ששולפות כל פעם ישות אחת. לדוגמא, במקום פונקציה אחת שמביאה את כל פרטי דרישת הרכש בכמה מבנים יחד – כדאי לבנות פונקציה ייעודית לשורות ההזמנה, אחת לשותפים, אחת לשורות של הקצאת חשבון וכו'. לאחר מכן בונים תלויות וקשרים בין ישויות ואז קושרים את המבנים למסכים – ועל ידי כך משפרים את זמני התגובה ומפשטים את המורכבות מבחינת הנתונים. ODATA בנוי על ישויות, ולכל ישות ניתן לממש מתודות CRUD שונות, כך שהיישום שלכם הופך להיות מודולרי וקל יותר לבצע Reuse לחלקים שלמים במסכים.
- תגדירו RFC \ Search Helps
לא תמיד יהיו לכם תשובות לסעיף הזה בשלב הראשוני, אבל אם המיישם יכול להגדיר את מקורות המידע – הרווחתם. אם מדובר בהצגת מידע – מה שם הפונקציה השולפת? אם מדובר במסך הזנה וישנם שדות שהם שדות בחירה – מאיפה מביאים את הערכים? השמות הטכניים בשלב זה יכולים לסייע בבנייה נכונה של ODATA וגם יעזרו למפתחים להבין את תפיסת הפתרון.
לסיכום – הצוות המושלם לפרויקט UI5:
איש UX + מיישם + מפתח ABAP עם ידע ב-REST + איש UI5 (מצוות ALTERNO, כמובן).
איש UX + מיישם + מפתח ABAP עם ידע ב-REST + איש UI5 (מצוות ALTERNO, כמובן).
