Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    navigating with up\down arrow keys in a grouped grid

    Hello Isomorphic,
    When the user uses the up\down arrow keys to navigate a grouped grid, when reaching a group (i.e. arrow down from the last item in one group or up from the first item in a group), the group is not highlited or selected in any way.
    Also there is no way to control this using CSS bc no element in the group item HTML gets an alternative style.

    This can be demonstrated easily in your gridHeaderSummary showcase: https://www.smartclient.com/smartcli...dHeaderSummary

    I could not find any grid property which controls that behavior - is there one?
    If not, then I think the 'Selected' modifier should be added to the groupNode style when the group row is selected in this way (and probably also when clicked-on with the mouse, but that is less problem because the user can see the impact of clicking on the group when it opens\closes).


    We are using SmartClient v12.1p_2021-08-18 but the problem is visible also on latest build.

    Thanks in advance

    #2
    Hi Gedri
    We agree there should be some visual indication available.

    The "Over" modifier would typically be applied in this case as, for normal rows in a grid, Over styling does double duty to indicate both keyboard selection and rollover.
    It appears this is essentially disabled for these rows at present - we have a developer taking a look and will follow up when we have more information for you

    Regards
    Isomorphic Software

    Comment


      #3
      Yes, the Over modifier will be most appropriate.
      Thanks.

      Comment


        #4
        We've made a change to ensure the Over styling shows up when the user rolls over, or keyboard-focuses over a group header node.

        The change will be present in nightly builds going forward (dated Dec 16 or above)

        Note that it does require that the grid have a specified groupNodeBaseStyle [and appropriate "Over" suffixed variants defined in CSS]
        If the grid just has groupNodeStyle defined that is a static style which won't show statefulness.

        A part of this change was ensuring that the standard "Flat" skins [Tahoe etc] have appropriate Over styled css but if you're using a custom skin you may need to modify it to ensure "Over" styling is shown for group nodes within your grids

        Regards
        Isomorphic Software

        Comment


          #5
          Thank you Isomorphic.
          Looking at the same showcase and checking the new functionality, I notice 2 UI inconsistencies in the behavior.

          When the last item in the first group is selected and you click the arrow-down, the highlight **moves** to the second group and no other row is selected - this is perfect!

          But,
          1. if you click the arrow down key once again (to move the focus to the first item in that group) and then key-up once to move back to the group row - now both the group row and the first item in it are highlited - I suspect this is a bug.
          Hitting the arrow-left\right keys at that point will collapse\expand the group - suggesting that the focus is really on the group row (as expected) and seems like the first item in the group still showing as selected is just a UI glitch (i.e. the bug).
          Click image for larger version

Name:	2021-12-18_174725.png
Views:	227
Size:	43.0 KB
ID:	267044
          2. at the same scenario, if you now move the mouse over the grid rows, the group highlight will disappear and the row where the mouse is over will show the highlight instead.
          That seems expected, but if you now use the left\right arrow keys, you will see that the group collapse\expand - indicating that it is still the selected row in the grid, although it is not showing any highlight and the first item in that group appears selected...
          Click image for larger version

Name:	2021-12-18_175427.png
Views:	205
Size:	48.8 KB
ID:	267045

          Both these problems brings me to think that perhaps marking the group row as selected rather than just 'Over' would have been a better approach, but of course I will leave it to you to consider and decide the most appropriate solution base on your experience and judgment.

          Thanks again
          Gil

          Comment


            #6
            Hi Isomorphic,

            Did you have a chance to look at my last reply to this post?
            It's not very urgent, but I just want to check it did not go unnoticed...

            Thanks
            Gil

            Comment


              #7
              Hi Gedri
              Thanks for following up, and yes we saw your post

              The first effect you see whereby both the top record in a group and the group header appear with different styles of highlighting when moving up out of the group via an arrow-up keypress is due to the fact that the group header node is not selectable, but is keyboard focusable. As you move up, you are not deselecting the top row in the group (so it continues to show selected appearance) but you are giving keyboard focus to the group header node, so it shows "over" styling.

              The second effect where a mouseMove yanks the "Over" styling from the keyboard focused row to put it under the mouse is also a known / understood behavior. Since the "Over" styling is doing double duty to indicate keyboard focus and mouse position it needs to update when the user moves their mouse to continue to behave as expected. However, without a separate Focused type style you do lose the keyboard-focus indication on the group node.

              Both of these behaviors are known and longstanding ListGrid behaviors around keyboard navigation and unselectable rows. Your feedback on the user experience for these interactions has been forwarded to the design team, and we'll be considering whether we want to make changes here. As you say, we don't consider this very urgent issue but we are aware of it!

              Thanks
              Isomorphic Software

              Comment


                #8
                Understood.

                I just want to stress my point about the discrepancy between moving via arrow-down from the last item in a group to the next group item (which now behaves as one would expect) and moving via arrow-up from the first item in a group to it's own group item which doesn't feels right - in both cases you are moving from a selectable item to a non-selectable item (the group row) so the inconsistent behavior is not understood.

                Anyway, leaving this to your design team consideration.

                Thanks
                Gil

                Comment

                Working...
                X