User Tools

Site Tools


20170612_ui_gra_telco_mm_review

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
20170612_ui_gra_telco_mm_review [2017/06/19 06:20]
tmatsuzawa
20170612_ui_gra_telco_mm_review [2017/06/26 00:48] (current)
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
 +        * Rear-camera
 +    * 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.1497853204.txt.gz · Last modified: 2017/06/19 06:20 by tmatsuzawa