1. SORTING BEHAVIOUR. There is a bug in the sorting behaviour in 'Recipes' and 'Packages' as on the first click it order A-Z, on the second click it order the list Z-A, and on a third click it orders the list with no a clear rule. 2. TOOLTIPS In 'Recipes' and 'Packages' the tooltips for 'All recipes', 'Tasks', 'All packages' are missing. 3. BROUGHT BY INFO In 'Recipes' and 'Packages' the 'Brought by' columns should only display one recipe or package. If an item is brought by more than one recipe/package, additional ones display in a persistent tooltip (at present the persistent tooltip appears at double click and shows the same content already displayed in the table). We may revisit the double click interaction in a later phase. 4. INCLUDED RECIPES TABLE TABS The 'Included recipes' table in the 'Recipes' is not displaying the 'group' column (the order should be: 'Name', 'Brought by', 'Group' and 'Included') 5. RECIPES INCLUDED BUTTON (top right corner) In the 'Recipes' screen, the included recipes information is included within a button that opens the 'Included recipes' tab (minor).
(In reply to comment #0) > 3. BROUGHT BY INFO > In 'Recipes' and 'Packages' the 'Brought by' columns should only display one > recipe or package. If an item is brought by more than one recipe/package, > additional ones display in a persistent tooltip (at present the persistent > tooltip appears at double click and shows the same content already displayed in > the table). We may revisit the double click interaction in a later phase. How should we choose which one recipe/package to display? Just the first in the brought in by list that we'll show in the Persistent Tooltip?
(In reply to comment #0) > 2. TOOLTIPS > In 'Recipes' and 'Packages' the tooltips for 'All recipes', 'Tasks', 'All > packages' are missing. I have a WIP patch for this, my current concern is that our data model doesn't include all of the information that's included in these tooltips in the design. I'm reluctant to play around with the data model at this late stage in the cycle, especially as it may affect parse speed, so I'm left wondering: Would people want to see a partial implementation of the tooltips for these notebook pages, or no implementation? Of course, after 1.2 we can play around with the data model and work out this information - it's just starting to look like a non-trivial patch to include during stabilisation period if we were to do so now.
(In reply to comment #1) > (In reply to comment #0) > > 3. BROUGHT BY INFO > > In 'Recipes' and 'Packages' the 'Brought by' columns should only display one > > recipe or package. If an item is brought by more than one recipe/package, > > additional ones display in a persistent tooltip (at present the persistent > > tooltip appears at double click and shows the same content already displayed in > > the table). We may revisit the double click interaction in a later phase. > > How should we choose which one recipe/package to display? Just the first in the > brought in by list that we'll show in the Persistent Tooltip? Hi Joshua, I find the double click interaction to display the persistent tooltip not intuitive and I'm a bit worried that the information will get missed. I therefore suggest to leave it as it is for now. I will post my suggestions on how to fix the tooltip issues for this release in the next comment.
(In reply to comment #2) > (In reply to comment #0) > > 2. TOOLTIPS > > In 'Recipes' and 'Packages' the tooltips for 'All recipes', 'Tasks', 'All > > packages' are missing. > > I have a WIP patch for this, my current concern is that our data model doesn't > include all of the information that's included in these tooltips in the design. > I'm reluctant to play around with the data model at this late stage in the > cycle, especially as it may affect parse speed, so I'm left wondering: > > Would people want to see a partial implementation of the tooltips for these > notebook pages, or no implementation? > > Of course, after 1.2 we can play around with the data model and work out this > information - it's just starting to look like a non-trivial patch to include > during stabilisation period if we were to do so now. I believe we need to solve 2 main issues on tooltips for tables: the way tooltips are displayed and the information they display. As there is no time to play with the data model at this stage, I would anyway recommend to display any information we have that may help users understand a bit more about what they are selecting. At present, only one tooltip is available in each table row (when available) and it's displayed on double click (as the 'on click' action is used to select the row). For this reason, for example, when users double click on a 'Recipe Name' in the 'Recipes Included' tab, the tooltip, instead of displaying more information about the recipe, displays the 'brought in by' information. Providing users with more information regarding a 'Recipe Name' is critical as it may be quite difficult for a non expert user to understand what each recipe refers to. For this reason, for the short term, I suggest to: 1. Display more information about 'recipes name' and any other information type which has more information attached, even if the data model is not optimised. We'll work on improving the way these information in the meanwhile. 2. Make the persistent tooltips in tables become standard tooltips and therefore appear on mouseover. As these tooltips won't display links, it will be ok for them to appear on mouseover on each table element and, at least, the mouseover interaction will be more intuitive than the double click one. Tooltips displayed on mouseover should appear next to the label they refers to. Any thoughts?
Are you proposing that the brought in by information *not* be displayed in the tooltip, or that it be displayed in addition to any extra recipe information we can show?
Hi Joshua, what I mean is that: Solution 1 (recommended): If we can make the persistent tooltips in tables become standard tooltips everywhere and therefore appear on mouseover, the 'brought in by' information should only display one recipe or package followed by '...' when the recipes has been brought in by more than one recipe or package. The rule would be to display the recipes or packages in alphabetical order (A to Z), and therefore only display the first one on the list. The remaining recipes will be displayed on a contextual tooltip that will appear only when users mouseover the 'brought in by XXXXX' label. If a recipe has been brought in by only one recipe or package the '...' won't be displayed. Solution 2 (not recommended): If the only way to display more information about each row is by double clicking on it and, more importantly, if we can only display one tooltip per row, we should probably display in the tooltip all information we have about the content of each row (Recipe name, brought in by, group...) divided in 'chapters' according to the type of information each table displays. I may need to design the tooltip if that is the case. Let me know if Solution 1 can be implemented.
(In reply to comment #0) > 1. SORTING BEHAVIOUR. > There is a bug in the sorting behaviour in 'Recipes' and 'Packages' as on the > first click it order A-Z, on the second click it order the list Z-A, and on a > third click it orders the list with no a clear rule. In my testing it's only the recipes table which exhibits this strange sorting, I've prepared a patch to fix this.
(In reply to comment #6) > Hi Joshua, what I mean is that: > > Solution 1 (recommended): If we can make the persistent tooltips in tables > become standard tooltips everywhere and therefore appear on mouseover, the > 'brought in by' information should only display one > recipe or package followed by '...' when the recipes has been brought in by > more than one recipe or package. The rule would be to display the recipes or > packages in alphabetical order (A to Z), and therefore only display the first > one on the list. The remaining recipes will be displayed on a contextual > tooltip that will appear only when users mouseover the 'brought in by XXXXX' > label. If a recipe has been brought in by only one recipe or package the '...' > won't be displayed. > > Solution 2 (not recommended): If the only way to display more information about > each row is by double clicking on it and, more importantly, if we can only > display one tooltip per row, we should probably display in the tooltip all > information we have about the content of each row (Recipe name, brought in by, > group...) divided in 'chapters' according to the type of information each table > displays. I may need to design the tooltip if that is the case. > > Let me know if Solution 1 can be implemented. I've been playing around with tooltips etc. this afternoon and whilst we can do the first solution it will require larger, more invasive, changes than I'm comfortable with making at this point in our release. We could probably figure out solution two for the imminent release without too much of a drastic change set.
Hi Joshua, Before I move into designing solution 2 than, can you please confirm: 1. We can only display one tooltip per row and not per information type (e.g. 'name', brought in by', etc...) 2. We can only display that information on double click. This behaviour is not intuitive and I would recommend to: - Solution A: Remove the behaviour according to which if users click anywhere in the row the checkbox is selected. In this case we can use the persistent tooltips for each information type (e.g. 'name', brought in by', etc...) and tooltip can be displayed on click (instead of double click). Users will still be able to select a recipe or package by selecting the checkbox anyway. - Solution B (not reccomended): We add an 'information icon' in a column on the table so that users will be able to click that icon instead of having to 'guess' there may be more information available on double click. Thoughts?
(In reply to comment #9) > Hi Joshua, > > Before I move into designing solution 2 than, can you please confirm: > 1. We can only display one tooltip per row and not per information type (e.g. > 'name', brought in by', etc...) The toolkit is capable of a tooltip per information type, but it's a more invasive change than I'd like to make to Hob at this late stage in the development cycle. > 2. We can only display that information on double click. This behaviour is not > intuitive and I would recommend to: > - Solution A: Remove the behaviour according to which if users click anywhere > in the row the checkbox is selected. In this case we can use the persistent > tooltips for each information type (e.g. 'name', brought in by', etc...) and > tooltip can be displayed on click (instead of double click). Users will still > be able to select a recipe or package by selecting the checkbox anyway. I just prototyped this solution so we can do this, certainly.
Status update: 1. is solved. 2. is under discussion and requires some design. 3. is yet to be fixed, 1D development 4. is yet to be fixed, 1D development 5. is yet to be fixed, 2D development I'd guesstimate that it'll take about 3D to review these patches.
Patches submitted for 1-4. 5 may take some work.
5 is definitely a minor issue. I could create a separate bug for it so it doesn't stop us from closing this one. If we don't get to fix 5 for this release, it's not a problem. Belen
(In reply to comment #13) > 5 is definitely a minor issue. I could create a separate bug for it so it > doesn't stop us from closing this one. That would probably be good, thank you.
1. Fixed in: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=35acc9edc815b715582570ba4baec0909f2bb81b 3. Fixed in: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=49cd60e3c3953a71fac816c01224efbfb970310c 4. Fixed in: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4cf1aa5ae467f7f16ab7f641319bf2404e666dd0
Patch developed for 5 but holding off until post 1.2
I've filed 2 under bug #2322
5 has been filed as bug #2323.
3 of the 5 points in the original report have been fixed for 1.2, the remaining two have been opened as separate bugs to be considered in the 1.3 timeframe.
per above comment
1. Verified, although the sorting behaviour of the different headings is still not nailed down. - the 'Included' heading puts the included items at the bottom on the first click, at the top on the second click. It should be the other way around (presumably, if I am sorting by 'Included', what I am interested in is the included items). We should have brought this up as part of point 1, so this is design's fault. Sorry about that. - In the Packages screen, the grouping by recipe causes some sorting issues (items are sorted within recipes, which results on a strange behaviour). We need to give some thought to how sorting should behave when items are grouped by a certain criteria (e.g by recipe). 2. Verified, although we should provide a visual hint about the fact that something is brought in by more than one item. We will consider this when reviewing the tooltips functionality for 1.3 4. Verified.
(In reply to comment #21) > 1. Verified, although the sorting behaviour of the different headings is still > not nailed down. > > - the 'Included' heading puts the included items at the bottom on the first > click, at the top on the second click. It should be the other way around > (presumably, if I am sorting by 'Included', what I am interested in is the > included items). We should have brought this up as part of point 1, so this is > design's fault. Sorry about that. > > - In the Packages screen, the grouping by recipe causes some sorting issues > (items are sorted within recipes, which results on a strange behaviour). We > need to give some thought to how sorting should behave when items are grouped > by a certain criteria (e.g by recipe). Sounds like we need a new bug for consistent sorting behaviour? Would you like me to file one with the above quoted comments?
Just did: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2346 (In reply to comment #22) > (In reply to comment #21) > > 1. Verified, although the sorting behaviour of the different headings is still > > not nailed down. > > > > - the 'Included' heading puts the included items at the bottom on the first > > click, at the top on the second click. It should be the other way around > > (presumably, if I am sorting by 'Included', what I am interested in is the > > included items). We should have brought this up as part of point 1, so this is > > design's fault. Sorry about that. > > > > - In the Packages screen, the grouping by recipe causes some sorting issues > > (items are sorted within recipes, which results on a strange behaviour). We > > need to give some thought to how sorting should behave when items are grouped > > by a certain criteria (e.g by recipe). > > Sounds like we need a new bug for consistent sorting behaviour? Would you like > me to file one with the above quoted comments?