בפרוייקט פליי.גו של מכון וויצמן השתלבנו במהלך רחב של הפיכת מחקר פנים ארגוני לסטארטאפ
נתבקשנו ליצור את הצד הויזואלי בסימולטור המדגים כיצד שפת התכנות של פליי.גו פועלת בזירת הבית החכם. תרומתנו בהקשר לאפיון חווית המשתמש היא התובנה שהמשתמש בסימולציה הוא המשקיע שצריך בזמן קצר להבין את המורכבות והייחוד של הפיתוח הייחודי אותו הם משווקים
נתבקשנו ליצור את הצד הויזואלי בסימולטור המדגים כיצד שפת התכנות של פליי.גו פועלת בזירת הבית החכם. תרומתנו בהקשר לאפיון חווית המשתמש היא התובנה שהמשתמש בסימולציה הוא המשקיע שצריך בזמן קצר להבין את המורכבות והייחוד של הפיתוח הייחודי אותו הם משווקים
מחקר מקדים של ממשקים דומים בארגון, איסוף חומרים במידה וישנו מוצר קיים
Smart home simulators are turning into 3d environments today
https://www.youtube.com/watch?v=lx9Ziqi162I
https://www.youtube.com/watch?v=lx9Ziqi162I
Back than, these where the common simulators, we offered a playful approach
ניתוח קהלי יעד ומחקר של צרכי המשתמשים, בכלים איכותניים ו/או כמותניים
השתלבנו בפעילות הקיימת והתבססנו על מחקר מקיף שלהם. תרומתנו - דיוק המסרים וניתוח היבטים בצרכי המשתמשים
תרומתנו, מעבר לעיצוב , לפיתוח ולהתממשקות עם התוכנה שפותחה במכון וויצמן, היתה למקד את הצוות בהבנה כי קהל היעד המשמעותי בשלב זה הם המשקיעים איתם הם נפגשים. מכאן שהמשחקיות והפשטות בהעברת המסרים בנוגע למורכבות התוכנה אותה הם משווקים הנחו אותנו בקביעת חווית המשתמש הרצוייה. הדיוק לגבי הזירה שבה יפעל הסימולטור הובילה אותנו לקבוע את חווית המשתמש המדוייקת עבור הלקוח שלנו
תרומתנו, מעבר לעיצוב , לפיתוח ולהתממשקות עם התוכנה שפותחה במכון וויצמן, היתה למקד את הצוות בהבנה כי קהל היעד המשמעותי בשלב זה הם המשקיעים איתם הם נפגשים. מכאן שהמשחקיות והפשטות בהעברת המסרים בנוגע למורכבות התוכנה אותה הם משווקים הנחו אותנו בקביעת חווית המשתמש הרצוייה. הדיוק לגבי הזירה שבה יפעל הסימולטור הובילה אותנו לקבוע את חווית המשתמש המדוייקת עבור הלקוח שלנו
גיבוש קונספט חווית משתמש במשימת הדמו
מול משקיעים פוטנציאליים. הצגנו עטיפה גרפית שתהפוך את הדמו לנגיש וקומוניקטיבי יותר. הוספנו את התובנה כי דמו ויזואלי ייחזק את הפרזנטציה שלהם בהקשר היזמי כי מה שנהוג בהקשר אקדמי או מה שהיה מקובל עד אז כסימולציה מספקת של התוכנה - לא יספיק בהקשר היזמי
(user flow/use case) אפיון תרחישי שימוש
Smart Home Demo Graphical Model Requirements
1. Basic Capabilities
1.1. The Graphical Model for the demo is used to show in a graphical way the behavior of a smart home, focusing on scenarios that require one room at this point. It allows to Play Out - e.g., show how the smart home functions when LSC diagrams are added and executed. It also allows to create new LSCs through Play In - e.g., manipulation / interaction with the objects in order to create LSC diagrams.
1.2. The canvas should be able to be maximized to a full screen, but should also fit well within approximately ¼ of the screen.
1.3. The smart home is depicted by a single room, with all required objects, but will include necessary additions to allow graphically depicting people entering the house and car’s arriving at the house, in which the room is.
1.1. The Graphical Model for the demo is used to show in a graphical way the behavior of a smart home, focusing on scenarios that require one room at this point. It allows to Play Out - e.g., show how the smart home functions when LSC diagrams are added and executed. It also allows to create new LSCs through Play In - e.g., manipulation / interaction with the objects in order to create LSC diagrams.
1.2. The canvas should be able to be maximized to a full screen, but should also fit well within approximately ¼ of the screen.
1.3. The smart home is depicted by a single room, with all required objects, but will include necessary additions to allow graphically depicting people entering the house and car’s arriving at the house, in which the room is.
2. Additional capabilities
2.1.1. We would like to add captions or another means to focus viewer attention on the changes that occur at each point.
2.1.1. We would like to add captions or another means to focus viewer attention on the changes that occur at each point.
אפיון פונקציונלי מלא
3. Connectivity
3.1. Model to PlayGo tool - the Model should send information to PlayGo, so that PlayGo can update necessary charts and react. Model should notify PlayGo on:
3.1.1. Click
3.1.2. Right-click
3.1.3. Selections or object manipulations to PlayGo, so that PlayGo can update necessary charts and react.
3.2. PlayGo tool to Model - the PlayGo tool should be able to send to the Model the difference changes in object states to display graphically.
4. Objects
The following section describes the required objects, their properties and their possible actions.
An object needs
1. A graphical representation, if not marked + / *, then we should be able to change it from the code.
2. An icon for each graphical representation (an ico file, for the same image, not specially drawn icons).
3. Property should also have a graphical representation (and when possible to create easily an icon file, e.g., light on, light off, it is a nice to have), if marked with + should also have ability to set graphically from a nice menu or visualization).
4. Some actions (marked with *) need to have some ability to select/change/manipulate via a menu/or other interface.
For example, if a person can enter the house, it may be dragging the person into the house that will generate a communication event that the person enters the house, and it may be an explicit menu. We would like to have more graphical natural interfaces then menus, when possible.
3.1. Model to PlayGo tool - the Model should send information to PlayGo, so that PlayGo can update necessary charts and react. Model should notify PlayGo on:
3.1.1. Click
3.1.2. Right-click
3.1.3. Selections or object manipulations to PlayGo, so that PlayGo can update necessary charts and react.
3.2. PlayGo tool to Model - the PlayGo tool should be able to send to the Model the difference changes in object states to display graphically.
4. Objects
The following section describes the required objects, their properties and their possible actions.
An object needs
1. A graphical representation, if not marked + / *, then we should be able to change it from the code.
2. An icon for each graphical representation (an ico file, for the same image, not specially drawn icons).
3. Property should also have a graphical representation (and when possible to create easily an icon file, e.g., light on, light off, it is a nice to have), if marked with + should also have ability to set graphically from a nice menu or visualization).
4. Some actions (marked with *) need to have some ability to select/change/manipulate via a menu/or other interface.
For example, if a person can enter the house, it may be dragging the person into the house that will generate a communication event that the person enters the house, and it may be an explicit menu. We would like to have more graphical natural interfaces then menus, when possible.
5. Scenarios
5.1. LightOn: When someone enters the room, the light turns on.
5.2. LightOff: When someone exits the room, the light turns off.
Q: What if two people enter and only one exits?
5.3. LightPreventDark: When there is someone in the room, the light should not turn off. (when somone exits, forbid smarthome changes light state to off, until the body count changes to zero)
5.4. ACStartOnHot: When the temperature is too hot (over 28 degrees celcius), the smarthome starts the AC.
5.5. ACStopOnCold: When the temperature is too cold (less then 26 degrees celcius) the smarthome stops the AC.
Q: What if the person in the room leaves the room and the AC is on?
5.6. ACCloseOnEmpty: When someone leaves the room, close the AC.
Q: Should the AC start when there is no one in the room?
5.7. ACPreventStartEmpty: when the temperature raises, never open the AC when the room is empty (this will be modified later when adding car scenarios).
5.8. BlindsCloseForCool: when the AC starts and it is very sunny, close the blinds [to save energy].
5.9. BlindsOpenForLight: when it is sunny outside but the blinds are closed, and the light is on, open the blinds and close the light.
5.10. CarApproachesCoolHouse: when car is approaching the house and will reach it in 10 minutes, open the AC [to cool the house]. (this will not work until ACPreventStartEmpty is modified).
5.11. ACPreventStartEmptySometimes: when the temperature raises, never open the AC when the room is empty, unless the car is approaching.
5.12. CarApproachesLights: when car is approaching and will reach the house in one minute, open the blinds if it’s sunny, or the light if it’s not.
5.13. ACAndTime: Avoid turning the AC on and off every 5 minutes. (Note: this chart has a bug in current PlayGo implementation).
5.14. ACAndBaby: when someone with a baby enters the room, if the temperature is less than 30, close the AC (avoid AC if not really necessary), and until the person with baby leaves, or temperature is over 30, do not start AC.
5.15. Vacation: when the calendar has a vacation start event, until vacation ends, at 8am open the blinds, turn on the radio for half an hour, at 2pm, close the blinds, at 6pm, open the light, close light at 9pm.
5.16. LightOnSilentMobile: if it’s dark outside (e.g., after 8pm) and the phone has an incoming sms and it’s on silent, make the room lights blink [to draw attention to phone].
6. System states
The system has two main states, and it would be good to have a GUI icon that shows which state we are in, and allows switching between them.
6.1. Play In - In this state new scenarios are created.
6.2. Play Out - In this state existing scenarios are executed.
5.1. LightOn: When someone enters the room, the light turns on.
5.2. LightOff: When someone exits the room, the light turns off.
Q: What if two people enter and only one exits?
5.3. LightPreventDark: When there is someone in the room, the light should not turn off. (when somone exits, forbid smarthome changes light state to off, until the body count changes to zero)
5.4. ACStartOnHot: When the temperature is too hot (over 28 degrees celcius), the smarthome starts the AC.
5.5. ACStopOnCold: When the temperature is too cold (less then 26 degrees celcius) the smarthome stops the AC.
Q: What if the person in the room leaves the room and the AC is on?
5.6. ACCloseOnEmpty: When someone leaves the room, close the AC.
Q: Should the AC start when there is no one in the room?
5.7. ACPreventStartEmpty: when the temperature raises, never open the AC when the room is empty (this will be modified later when adding car scenarios).
5.8. BlindsCloseForCool: when the AC starts and it is very sunny, close the blinds [to save energy].
5.9. BlindsOpenForLight: when it is sunny outside but the blinds are closed, and the light is on, open the blinds and close the light.
5.10. CarApproachesCoolHouse: when car is approaching the house and will reach it in 10 minutes, open the AC [to cool the house]. (this will not work until ACPreventStartEmpty is modified).
5.11. ACPreventStartEmptySometimes: when the temperature raises, never open the AC when the room is empty, unless the car is approaching.
5.12. CarApproachesLights: when car is approaching and will reach the house in one minute, open the blinds if it’s sunny, or the light if it’s not.
5.13. ACAndTime: Avoid turning the AC on and off every 5 minutes. (Note: this chart has a bug in current PlayGo implementation).
5.14. ACAndBaby: when someone with a baby enters the room, if the temperature is less than 30, close the AC (avoid AC if not really necessary), and until the person with baby leaves, or temperature is over 30, do not start AC.
5.15. Vacation: when the calendar has a vacation start event, until vacation ends, at 8am open the blinds, turn on the radio for half an hour, at 2pm, close the blinds, at 6pm, open the light, close light at 9pm.
5.16. LightOnSilentMobile: if it’s dark outside (e.g., after 8pm) and the phone has an incoming sms and it’s on silent, make the room lights blink [to draw attention to phone].
6. System states
The system has two main states, and it would be good to have a GUI icon that shows which state we are in, and allows switching between them.
6.1. Play In - In this state new scenarios are created.
6.2. Play Out - In this state existing scenarios are executed.
שלב הבדיקות - ראה תיעוד של הדמו בפעולה
