[Withdrawn] SDL 0325 - Dynamic App List Sorting

[jordynmackool]

Hello SDL community,

The review of "SDL 0325 - Dynamic App List Sorting" began on November 25, 2020, and continues through December 15, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0325-Dynamic-App-List-Sorting.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#1098

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Jordyn Mackool

Program Manager - Livio
Jordyn@livio.io

[Akihiro-Miyazaki]

@jordynmackool -san,
Thank you for your cooperation as always.
However, since URL address is wrong, we can not access the proposal documentation.
Could you please remove "SDL-" from the file name.
Thank you.

[jordynmackool]

Hi @Akihiro-Miyazaki, thanks for letting me know. I have updated the link in my comment above. Please note that the proposals under review can also be found on this page: smartdevicelink.github.io/sdl_evolution/.

[joeljfischer]

1. I don't think the introduction is correct. You state:

This proposal is to clarify the SDL app icon display sequence and to present the dynamic app list sorting methods at the same time. By doing so, we can prevent unnecessary development for the Head Unit (HU) developers and improve usability by enhancing the visuality for users.

This proposal is not to clarify the app icon display sequence. As you note in the motivation, one is already defined. This proposal is to change the display sequence.

to present the dynamic app list sorting methods

Does this mean "to add built-in app list sorting methods and allow their configuration through the policy table"?

2. I don't think that the opening of the motivation is fair or correct. It says that there is no definition for the app icon ordering, but then explains the current definition, which is contradictory. It also says that it's unclear if the HMI developer is supposed to implement the ordering, but the answer to that is a clear, "yes, the HMI developer is supposed to implement the ordering they want."

A better motivation would have been to say that you think there should be a more sensible default ordering so that HMI developers who don't want to implement custom ordering don't have to, but to say that there is no definition and it's hard to know what to do is a simple documentation fix and doesn't require this proposal. I would recommend you update the motivation to more clearly explain why you want to make these changes (such as that you believe that Core should provide a better default ordering.)

As a result, the display order of icons changes every launch. Furthermore, it is very poor visuality and operability (usability) because it takes a long time for the user to find an app that s/he wants to use. In order to solve these problems, we propose to clarify the display order of the SDL app icon and improve the usability by presenting the SDL app icon display sequence and the dynamic app list sorting methods.

Again, this is not clarifying the display order, it is changing it. There is an important difference there. Clarifying would be making rules that match the current implementation. This changes the implementation.

3. Is there any way to keep the current behavior?

4. What happens if none of the policy table attributes are defined?

5. If the policy table updates with a new sorting order, should Core / HMI change the displayed order of the apps, or should it wait for a new ignition cycle to display the new order.

6a. What is the sub-ordering of appHMIType, i.e. does it order by appHMIType then is the order random after that?
6b. What if an app has multiple appHMITypes? Does it appear in the list multiple times?

7. I don't think that the ordering here is effective for the appHMIType grouping. Because applications can have multiple types (as noted in 6b), this will become confusing. Additionally, the groups are all still grouped together in one array in the UpdateAppList, meaning that the HMI still needs to separate them out on it's own for this to be an effective grouping. We're doing a lot of work here for very little gain.

8. I do not think this proposal should be accepted. I think that the existing system is adequate and it's simple for the HMI to sort as they choose through the UpdateAppList message and the HMIApplication structs it contains. At most, I believe that this proposal should change the default ordering method to alphabetical instead of effectively random and strip everything else out. This adds a lot of complexity for little gain.

[Jack-Byrne]

9. I wanted to point out that the priority fields in the policy table app_policies section use the following values, and do not use a numbered ordering system (1..n):

    <enum name="Priority">
        <element name="EMERGENCY" />
        <element name="NAVIGATION" />
        <element name="VOICECOM" />
        <element name="COMMUNICATION" />
        <element name="NORMAL" />
        <element name="NONE" />
    </enum>

If you would like for there to be a numbered ordering of the apps to take priority over the AppHMIType ordering, then i would suggest adding a new parameter to the app_policies section. Maybe "app_list_position"?

[Akihiro-Miyazaki]

@JackLivio -san,
Thank you for your comment.
What you say is like below?

app_list_sorting: {
    "sorting_pattern": "appHMIType",
    "appHMIType_sorting_list": [
        "NAVIGATION",
        "MEDIA",
        "MESSAGE",
        "INFORMATION",
        "COMMUNICATION",
        "SOCIAL",
        "PROJECTION",
        "REMOTE_CONTROL",
        "SYSTEM",
        "DEFAULT",
        "BACKGROUND_PROCESS",
        "TESTING"
    ],
    "app_list_position": [
        "EMERGENCY",
        "NAVIGATION",
        "VOICECOM",
        "COMMUNICATION",
        "NORMAL",
        "NONE"
    ]
}

If our recognition is wrong, could you please teach us the details.
Thank you.

[Akihiro-Miyazaki]

@joeljfischer -san,
2.
Thank you for your clarifying.
As you say,
"yes, the HMI developer is supposed to implement the ordering they want.", we would like to confirm it, could you please teach us the place.
Thank you.

If the 'app_list_sorting' information is not present, the list is sorted how it was previously sorted.

Dose this sentence answer to your question?

Since we considered to use allow list method, we did not consider that policy table attributes are blank.
However, we assume that the app which attributes are blank is the end of the list.

6a.
Could please teach us the sub-order?
My recognition is next sorting method when the apps have the same appHMIType.
If it is wrong, could you please teach us the details?
6b.
We will modify to add the sentence below.

When there are multiple appHMITypes set in one SDL app, the appHMIType with the highest priority is used, as the priority of that SDL app.

[Jack-Byrne]

@Akihiro-Miyazaki

I was thinking the new parameter be added to an App object in the app_policies section of the policy table.

The key is "app_list_position" and the value is any integer (0..N). The position would work similar to the position parameter for AddCommands and Submenus. 0 is top priority, higher numbers are lower priority.

        "app_policies": {
            "appID_12345": {
+              "app_list_position": 1
                "keep_context": false,
                "steal_focus": false,
                "priority": "NONE",
                "default_hmi": "NONE",
                "groups": [
                    "Base-4"
                ],
                "RequestType": [],
                "RequestSubType": []
            },

Apps that have this parameter would be sorted by that parameter value and placed in the front of the app list. Apps that do not have this parameter would be sorted by the sorting_pattern defined in app_list_sorting object and placed behind the apps that have do have the parameter.

I believe this concept is what was highlighted in the proposal in terms of giving priority to apps that had a specific position defined? This would be a way to have "featured" apps show first in the app list. Let me know if I am mistaken.

[joeljfischer]

@Akihiro-Miyazaki I will respond when all of my points have been responded to. I would request that you only respond when you have a full response to every point.

[Akihiro-Miyazaki]

@JackLivio -san,
Thank you for your details description.
We understood.

Our proposal was to use the "priority" parameter of "app_policies" in policy table as the sorting order.
However, since the "priority" parameter is used as the "AppPriority", we understood that this parameter can not use as the sorting order.
Therefore, you mentioned to add the new parameter as the sorting order instead of the "priority" parameter.

If our recognition is wrong, could you please teach us the details again.
If our recognition is correct, we can accept your suggestion.
Thank you.

[jordynmackool]

The Steering Committee voted to keep this proposal in review on 2020-12-01 to allow for conversations to continue on the review issue.

To ensure all open items are addressed and make the comments easier to follow, please respond to the open items in one comment moving forward.

[Akihiro-Miyazaki]

@joeljfischer -san,

We think your pointed out is correct.
Our proposal is to present the dynamic app list sorting methods which SDL Core will provide to HMI.

Also, we think the sentence "to add built-in app list sorting methods and allow their configuration through the policy table" is correct, too.

Since Applist is updated inevitably when policy table update or RAI is occurred, HMI will change the displayed order of the apps when the App menu screen is updated.
However, we also think it depends on the implementation of HU.

We are very sorry to forget adding the sentence "When there are multiple AppHMITypes set in one SDL app, the AppHMIType with the highest priority is used as the priority of that SDL app." in this proposal.

If this sentence is added in this proposal, when there are multiple AppHMITypes set in one SDL app, the AppHMIType with the highest priority is used as the priority of that SDL app.
Therefore, since it is likely to be displayed at the beginning of the appHMIType order, we think it will be easier to find the target app.

It depends on the state of No.2.
Since SDL Core has the multiple sorting methods, which increases the amount of implementation and is not necessary for OEMs who wants to implement their own sorting methods for apps.
However, since the SDL Core sends the sorthing applist to HMI just to specify how to order, which is useful for OEMs who wants to reduce the amount of HMI implemented.

[joeljfischer]

1. 👍 I would ask that this be changed to reflect the actual nature of this proposal and to clarify the language.k

2. Are you asking where it says this in documentation? If so, then it does not, which is why I said this could be a simple documentation update to state that HMI developers will need to implement an ordering system for app icons. That this is the current case should be clear based on the current state of the ordering and existing HMIs.

3. Yes, thank you.

4. I think this was answered by (3)

5. I don't think it does depend on the HU implementation, because you're saying that Core determines the ordering of the list in this proposal. Would another UpdateAppList be sent to the HMI with the expectation that it would update the app list?

6a. Yes, that is what I mean by sub-ordering. For example, is you have a group of apps [A, B, C, D, E] where A and B are MEDIA apps, would the ordering be [A, B]? And if the next time they connect, B connects first so that the order is [B, A, C, D, E] will the apps be ordered [B, A]? If so, I think this is a poor user-experience.

6b. Thank you for clarifying, but I think that is a very poor user experience. For example, if the priority ordering is [MEDIA, NAVIGATION, etc.] and an app such as LINE supports both MEDIA and NAVIGATION, then the app will not appear in the list of NAVIGATION apps, which may be confusing.

7. The main point of point 7 is that grouping apps by AppHMIType in Core provides very little gain because they're all presented in one list and the HMI still has to separate the apps. It provides very little gain compared to just having the HMI do all the work like it does now.

8. I'm sorry, I'm not following here. The amount of work that's being implemented to sort these on the HMI-side is minimal. Doing an alphabetical or AppHMIType sort on the HMI given the array of apps received is a small amount of work and allows HMI implementors to make it exactly how they want. The work and maintenance burden of this proposal is simply not worth it. As I noted, if this proposal were to change the default organization to be alphabetical and that's it, with no policy table / multiple sorting types, I would be in favor of it.

[Jack-Byrne]

9. Ok I think your understanding is correct. Requested revision to proposal is: Add new sorting position parameter (app_list_position) to app_policies section of the policy table. This will replace sorting by the existing policy field priority. Explained by comment here: [Withdrawn] SDL 0325 - Dynamic App List Sorting #1098 (comment)

[Akihiro-Miyazaki]

@joeljfischer -san,

5
We assume that when the screen is updated depends on the implementation of HU.
We also assume that when the order changes depends on the SDL Core implementation.

6a
We are very sorry that the order of the same appHMI Type is missing.
We will modify to add the sentence below.

If multiple SDL apps have the same AppHMIType set, sort them according to the order the SDL apps registered in the policy table.

6b
In this case, since the NAVIGATION is high priority than MEDIA, then the app will not appear in the list of MEDIA apps.
By the way, is there function to display one Type only?

[joeljfischer]

@Akihiro-Miyazaki I must ask you again to not respond to my points until you are ready to respond to every point. This conversation is too difficult to follow if you don't do this.

[jordynmackool]

To ensure all open items are addressed and make the comments easier to follow, please respond to the open items in one comment moving forward. To provide clarity of the current status of this proposal review, please see a summary of the items below:

Open items:

2. [Livio] Are you asking where it says this in documentation? If so, then it does not, which is why I said this could be a simple documentation update to state that HMI developers will need to implement an ordering system for app icons. That this is the current case should be clear based on the current state of the ordering and existing HMIs.

5. [Nexty] We assume that when the screen is updated depends on the implementation of HU. We also assume that when the order changes depends on the SDL Core implementation.

6a. [Nexty] We are very sorry that the order of the same appHMI Type is missing.
We will modify to add the sentence below. If multiple SDL apps have the same AppHMIType set, sort them according to the
order the SDL apps registered in the policy table.

6b. [Nexty] In this case, since the NAVIGATION is high priority than MEDIA, then the app will not appear in the list of MEDIA
apps. By the way, is there function to display one Type only?

7. [Livio] The main point of point 7 is that grouping apps by AppHMIType in Core provides very little gain because they're all presented in one list and the HMI still has to separate the apps. It provides very little gain compared to just having the HMI do all the work like it does now.

8. [Livio] I'm sorry, I'm not following here. The amount of work that's being implemented to sort these on the HMI-side is minimal. Doing an alphabetical or AppHMIType sort on the HMI given the array of apps received is a small amount of work and allows HMI implementors to make it exactly how they want. The work and maintenance burden of this proposal is simply not worth it. As I noted, if this proposal were to change the default organization to be alphabetical and that's it, with no policy table / multiple sorting types, I would be in favor of it.

Agreed upon revisions:

1. Update introduction to reflect the nature of the proposal and clarify language.

We think your pointed out is correct.
Our proposal is to present the dynamic app list sorting methods which SDL Core will provide to HMI.

Also, we think the sentence "to add built-in app list sorting methods and allow their configuration through the policy table" is correct, too.

9. Requested revision to the proposal is: Add new sorting position parameter (app_list_position) to app_policies section of the policy table. This will replace sorting by the existing policy field priority. Explained by comment here: #1098 comment

Closed items, no action needed:

3, 4

[jordynmackool]

The Steering Committee voted to keep this proposal in review on 2020-12-08 to allow for conversation to continue on the review issue. A summary of all discussion items can be reviewed in this comment.

[Akihiro-Miyazaki]

@jordynmackool -san,
10.
Why do you mention [In Review] SDL 0328 - Modernize Ubuntu Support V20 LTS #1103 in this proposal?
Is there anything related to our proposal?

[jordynmackool]

10. @Akihiro-Miyazaki tagging the 0328 proposal on this issue was a mistake, please disregard that notification.

[Shohei-Kawano]

@jordynmackool -san, @joeljfischer -san, @JackLivio -san
We received not only technical opinions but also fundamental opinions about the motivation of this proposal, so we discussed how to proceed internally.
As a result, we decided to temporarily withdraw this proposal.
Thank you for your review so far.

Once we have decided how to proceed, we will revise the proposal and propose it again.

[jordynmackool]

The Steering committee voted to withdraw this proposal at the request of the author in this comment. Once the author decides how to address the technical options / fundamental questions posted on this review issue, they will need to submit a new proposal.