User Tools
20170612_ui_gra_telco_mm_review
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
20170612_ui_gra_telco_mm_review [2017/06/19 06:20] tmatsuzawa |
20170612_ui_gra_telco_mm_review [2017/06/24 03:27] tmatsuzawa |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| * Takashi Matsuzawa | * Takashi Matsuzawa | ||
| - | * The document should describe which part of it is mandatory and which parts are optional/selectable (e.g. I understand that 2 windows up/down layout is just one example of OEM profile - though it is very good that we have one example OEM profile and demo homescreen/window manager is written for it anyway.) | + | * The document should describe which part of it is mandatory and which parts are optional/selectable (e.g. I understand that 2 windows up/down layout is just one example of OEM profile - though it is very good that we have one example OEM profile and demo homescreen/window manager is written for it.) |
| - | * Regarding the API calls apps make, the document (or manual document) should clarify them into the following two categolies, so that audience can know which part is AGL specific. | + | * Regarding the API calls apps make, the document (or manual document) should clarify them into the following two categories, so that audience can know which part is AGL specific. |
| * API calls/actions that ordinal wayand-ivi apps will do (not specific to AGL) | * API calls/actions that ordinal wayand-ivi apps will do (not specific to AGL) | ||
| - | * API calls/actinos that are specific to AGL | + | * API calls/actions that are specific to AGL |
| * Graphics toolkits (e.g. Qt or others) here are expected to hide such API details from application developers or not, including AGL additions? | * Graphics toolkits (e.g. Qt or others) here are expected to hide such API details from application developers or not, including AGL additions? | ||
| + | |||
| + | * Takashi Matuszawa | ||
| + | * I think the spec should describe what are the concepts that are shown to the end-user and the actions (use-cases) that are provided. And vendors can freely implement their HMIs but providing what the spec specifies. | ||
| + | * e.g. | ||
| + | * HMI should provide following set of applications. | ||
| + | * 1) "all applications" | ||
| + | * 2) "currently running applications" (subset of 1, multiple can exist) | ||
| + | * 3) "currently visible applications" (subset of 2, multiple can exist) | ||
| + | * 4) "currently active application" (subset of 4, only 1 almost can exist) | ||
| + | * And HMI should provide actions as follows | ||
| + | * Show list of all applications, and optionally allow | ||
| + | * Select (make active) one of them. | ||
| + | * Show list of currently running applications, and optionally allow | ||
| + | * Select (make active) one of them. | ||
| + | * Quit one of them. | ||
| + | * Show currently visible applications, and optionally allow | ||
| + | * Select (make active) one of them. | ||
| + | * Quit one of them. | ||
| + | * HMI spec should describe if there are class of applications that needs special treatment and what they are | ||
| + | * e.g. | ||
| + | * Navigation | ||
| + | * Audio | ||
| + | * HMI spec should describe common operations (if there are any, as AGL HMI standard feature) | ||
| + | * e.g. | ||
| + | * "back" operation | ||
| + | * Press "back" button | ||
| + | * Swipe screen to right | ||
| + | * (what button/gesture is bound to "back", and how this "back" is interpreted may be implementation specific?) | ||
| + | |||
| + | |||
20170612_ui_gra_telco_mm_review.txt · Last modified: 2017/06/26 00:48 by tmatsuzawa
Page Tools
