Community
Participate
Working Groups
Currently there is a problem with Platform visibility in new project creation. The Combo doesn't do a good job of presenting the various options, and as a result, a given platform selection might be made when a more appropriate platform was available but not seen by the user. The platform options should be presented in a single selection list, which would do a much better job at displaying the possible options.
This should be fixed in the next release (2.x/3.0).
(In reply to comment #1) > This should be fixed in the next release (2.x/3.0). > I should have been more specific with version numbers. In this case I was referring to Dali specific versions, so Dali 2.x/3.0 or WTP 3.x.
Created attachment 103874 [details] proposed patch - HEAD The patch works around bug 119321 by extending the DataModelSynchHelper. At a later date we could push this fix to DataModelSynchHelper, but to do that changes how the api is used so probably not a good idea to do for RC4.
This is a major adopter request to change the current platform selection control from a Combo to a List. Everything would work identically as before regarding preference driven platform defaults, and the List would enforce the same constraints as the Combo (There is always a selection, only one item can be selected, etc). So, the only "change" associated with this change is the fact that the combo contents are displayed in a list, which provides for the visibility of the platforms (other than the initial Generic default). The priority of this bug has escalated as a result of bug 235517. We want to ensure that users are aware of the available platforms. The change is straight-forward, low-risk, and isolated to project creation and JPA Properties. There are only a few use cases to test with this change, so it has been well tested without any problems. I approve this change and request PMC approval. I understand that this fix may have minor implications to adopters, and as such I am open for discussion on the timing on this change.
(In reply to comment #4) > I understand that this fix may > have minor implications to adopters, and as such I am open for discussion on > the timing on this change. > Just wanted to clarify that the adopter impact I am speaking of is one of documentation (due to the combo -> list appearance. It should not impact adopters in any functional way.
Approving since this is an adopter request and per comment 4 its a low-risk and well tested fix. Please post this change in the relevant newsgroups and mailing list for other adopters to react.
Can we have "before" and "after" screenshots attached to the bug? I still cannot understand why an adopter should have problem selecting the JPA runtime from a Combo. This UI feature is similar to the Server Runtime selection, which is again done in a Combo.
Kate ... do you know if this impacts any documentation (screen shots) we (wtp or adopters) care about? Seems like it would be a minor discrepancy, if any ... but, I'd be the last to know.
It shouldnt be much of a problem for the docs but I'd have to see a screen cap before confirming that (I'm not familiar enough with the GUI to picture it in my head). Like Kaloyan my main concern is consistency with other GUIs.
Created attachment 104022 [details] Before change.
Created attachment 104024 [details] After change.
(In reply to comment #7) > Can we have "before" and "after" screenshots attached to the bug? > Attached some screenshots. > I still cannot understand why an adopter should have problem selecting the JPA > runtime from a Combo. This UI feature is similar to the Server Runtime > selection, which is again done in a Combo. > The main difference between our Platform concept and the Server Runtime selection is that for us a Platform is mandatory (no platform, no functionality). We did think about keeping this as a combo with an initial default of <None> like the Server Runtime selection, but in our case we would have to enforce a platform selection (unlike Server Runtime). Beyond the validation and button enablement/disablement, with some of the new Facet configuration UI, it is much easier to bypass specific facet configuration, but by having a default <None> option, we would have mandatory configuration at that point. So, that would probably be fine, and in theory would work, but it makes this change a little more complex, and less isolated in that we have to rely on the new Facet functionality working correctly in all of those cases.
I am sorry, Neil, but I would not approve this change for Ganymede. It really breaks UI consistency and I don't see any benefit in it. The list widget may look good for you with three elements, but how about if in an adopter's product the contents of the list is bigger? Will the widget expand or will a scroll bar appear? Shall this keep the usability benefit that you hope introducing with this change? Regarding the default value... What's wrong with the current one - Generic? If the user wants different Platform he would certainly notice that the widget is a Combo and like any other Combo it gives him a choice. I don't see any difference from user's perspective in the way a Platform and an Implementation Library is chosen. If you think that the JPA facet page needs better design, we could consider making an UI walk-through with the UI Experts group. You will have valuable feedback and make the changes in the post-Ganymede release. I feel that RC4 is not the right moment...
(In reply to comment #13) > I am sorry, Neil, but I would not approve this change for Ganymede. It really > breaks UI consistency and I don't see any benefit in it. The list widget may > look good for you with three elements, but how about if in an adopter's product > the contents of the list is bigger? Will the widget expand or will a scroll bar > appear? Shall this keep the usability benefit that you hope introducing with > this change? I don't think it is likely that there would be a large number of platforms, but I could see the need to change it to a table at some point once platform versions become an issue. > > Regarding the default value... What's wrong with the current one - Generic? If > the user wants different Platform he would certainly notice that the widget is > a Combo and like any other Combo it gives him a choice. I don't see any > difference from user's perspective in the way a Platform and an Implementation > Library is chosen. Generic would stay the default value. It's true that in many cases the user will notice the combo and look at their options. This is just trying to cover the case where a user doesn't notice the options.
I agree with Kaloyan's judgment here. Normally we'd "do anything" a major contributor/adopter wanted ... but, this seems going too far (especially this late).
My 2 cents on the ui suggestion is that I prefer the combobox since it: a) is the common ui used everywhere else for selcting something b) its compact (the list is "bulky" in comparison c) it can be extended with a ... button to get a more informative/complex dialog for configuring/selecting the right platform d) ...and users does know how to click a combobox arrow in my opinion
Re-examine for next release.
Re-targeting this to the 2.2 (Galileo) release. The current platform selection UI will eventually need to be changed to a solution that can handle the scalability issue related to multiple platform versions. Base platforms are likely to be limited in overall number, with a growing number of versions associated with a given platform. This issue will not be problematic until there are multiple versions of various platforms, which will start to become an issue in Dali 2.2. Picture 3 platforms each with 2 versions, plus the Generic Platform. This would put 7 items in the current combo, with platform versions sure to grow much larger in the future. A Table is one possible solution, offering a scalable way to handle the growing number of platform versions and without adding the complexity of a Tree (which would be necessary if the number of base platforms was going to be large as well). This would be one column for Platform and one for Version.
Ran out of time for this in 2.2.
Since "future" doesn't seem like it is considered P1.
