Page MenuHomePhabricator

Cursors are not consistent across the filters display and search areas
Open, Needs TriagePublic

Description

Based on that feedback, cursors are not consistant accross the active filter area display and the search field.

Cursor should should be a default one on all areas, except:

  1. when hovering as active filter (boxes with the X), use a pointer cursor
  2. when hovering the hamburger, use a pointer cursor
  3. when hovering the search field, use a text cursor

Tested on Firefox and Chromium, last version, on Ubuntu.

Event Timeline

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJun 11 2018, 1:49 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
jmatazzoni added a subscriber: Pginer-WMF.

I changed @Trizek-WMF's items above to a numbered list so I could refer to them by number. Also I'm copying @Pginer-WMF, who dreamed up this system, since I'm sure he'll have ideas.

#1: For the tags, I don't see why a grab hand is the right choice. What can you grab? Clicking on these (when not over the X) causes the menu to open and scroll to where the user is. So a pointer hand would seem to be the right thing. It's true that we have TWO possible actions inside the same element, since you can also click on the X (which does have a tooltip). But I still think the pointer is correct, since there is no doubt that the tag is clickable.

#2: Yes, I'd agree that hovering over the hamburger should cause a pointer hand. Let's be crystal clear, however, that the text cursor is appropriate for the rest of the search field—every place except the hamburger—as you indicate in #3.

jmatazzoni updated the task description. (Show Details)

For #1, it is apparently possible to grab items:


(Cursor is not visible on the screenshot, but was cursor:move.)
Anyway, #1 is not important and could be pointer.

Pointer cursor makes sense for both the tags and the menu icon.

The dragging seems to be inherited from the standard behaviour (@Volker_E may know more details), but it does not seem to have any use (it does not seem possible to reorder the tags). So it may be better to disable the dragging, and at the very least not to encourage it by means of the cursor.

  1. For the active filter items (tags), the default in OOUI is the text insert cursor, cause you can edit them inline. You can also grab them, but that functionality is not useful to expose more on RCFilters IMHO.

    I'd propose to let them remain with the text insert cursor or change them to pointer in this case. There's a small glitch though, an upstream OOUI issue, where the grab curser is visible on the most outer edge of the TagItems, we
  1. Agreed, I was thinking the same several times on RCFilters, hamburger should have pointer and
  2. Input field should remain as text input cursor.

Ping Moriel when ready

Joe has updated the task description based on Volker and Pau inputs. Aren't we ready? :)

Vvjjkkii renamed this task from Cursors are not consistant across the filters display and search areas to v9aaaaaaaa.Jul 1 2018, 1:04 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from v9aaaaaaaa to Cursors are not consistant across the filters display and search areas.Jul 2 2018, 2:53 PM
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.
Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 2 2018, 11:00 PM
Catrope renamed this task from Cursors are not consistant across the filters display and search areas to Cursors are not consistent across the filters display and search areas.Oct 2 2018, 1:03 AM
Catrope updated the task description. (Show Details)
Trizek-WMF updated the task description. (Show Details)Oct 2 2018, 3:22 PM
Catrope moved this task from Needs Discussion/Analysis to FY 2019-20 on the Growth-Team board.
Catrope added a subscriber: Catrope.

This is a substantial enough issue that we should prioritize fixing it.

Change 465308 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] RCFilters: Apply pointer cursor on Hamburger menu

https://gerrit.wikimedia.org/r/465308

Change 465308 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Apply pointer cursor on Hamburger menu

https://gerrit.wikimedia.org/r/465308

@Trizek-WMF - please review especially the pointer cursor behavior. Some additional

  1. when hovering the hamburger, use a pointer cursor
  2. when hovering the search field, use a text cursor

Both are in place (checked in production).

Regarding

  1. when hovering as active filter (boxes with the X), use a pointer cursor

There is a pointer for sure but the spatial interval where the cursor is changing from default to pointer and then to text is really small, see the screenshots:


And with the pointer cursor, it's still possible to grab filter labels and drag them with no resulting effect.

@Trizek-WMF - please review especially the pointer cursor behavior. Some additional

  1. when hovering the hamburger, use a pointer cursor
  2. when hovering the search field, use a text cursor

Both are in place (checked in production).

I have those too.

Regarding

  1. when hovering as active filter (boxes with the X), use a pointer cursor

There is a pointer for sure but the spatial interval where the cursor is changing from default to pointer and then to text is really small
And with the pointer cursor, it's still possible to grab filter labels and drag them with no resulting effect.

I had to really pay close attention to get it. That's only on a few pixels below the label.

I mostly have a text pointer when I hover the label, meaning that I can select the text. If I try to select the text, I have an unexpected move cursor. Cursors are not consistant with the possible actions an it should be fixed.

Ok, it's getting a bit more complex again.
The reason the cursor was put to 'text insert' aka 'text' upstream was to provide users a clue, that they can edit those tags.
The draggability and the text editing functionality were getting into each others way. Draggable tags are draggable on the whole tag area, while text edit functionality should be shown by text cursor only on the label, not for example on the close icon.
Compare https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#TagMultiselectWidget-very-long-item and its siblings.

How much the dragging and editing cursor indication makes sense in the specific case of Special:RecentChanges is not fully clear to me? My insights would say, that both things don't belong here and a pointer cursor for all the area would probably make more sense (also disable dragging completely).
For this decision, I'll defer to @Mooeypoo and @Catrope for historical perspective and more full-project awareness insights.

Thanks, @Trizek-WMF and @Volker_E - the issue seems to need an additional look. I've moved it to 'Incoming"column, so we can discuss it in our planning/triage meeting.

I'm not sure to understand the relevance of having a test cursor as well, especially on an item you can't edit. In the context of the filters, the only action you can take is to move the filter, click on the filter to open them in the menu, or click on the cross to remove them. It is actually not possible to edit them.

I'm also for the pointer-only option. That would save time and energy. Also, that task is not urgent at all. This is pure cosmetic considerations.

kostajh assigned this task to Volker_E.Nov 1 2018, 2:41 PM
kostajh edited projects, added Growth-Team, OOUI; removed Growth-Team (Current Sprint).
kostajh added a subscriber: kostajh.

@Volker_E we're marking this as "External" for Growth team because our understanding is that the remaining issue (T196900#4698655) should be fixed upstream in OOUI. Please unassign yourself and/or let us know if you feel this is not in scope for OOUI. Thanks!

kostajh moved this task from Inbox to External on the Growth-Team board.Nov 1 2018, 2:41 PM