Use pointer cursor instead of hand cursor when hovering over button

[Shomnipotence]

- What it looks now

normal cursor

Hand Cursor when hovering over the button

Although we know that these buttons are essentially hyperlinks, we still want to erase this distinction.It should use a normal pointer cursor in the button like apps developed with other frameworks.

Including Sidebar Item

Menu Item

Tabs

Explorer

Statusbar Item

- What it should be

When hovering over the button, it should be a normal cursor, like in other apps.

For example, setting the left navigation item of the app

Most of the itmes have Highlight , so the hand pointer is uesless All the apps built by WinForms,WPF,UWP or WinUI3,Qt or other frames did not have this bug(may you think that it is a feature)

[gjsjohnmurray]

I think the hand cursor is intended as a hint that you can drag the activity bar icons, for example to reorder them or move them to the side panel.

[Shomnipotence]

I think the hand cursor is intended as a hint that you can drag the activity bar icons, for example to reorder them or move them to the side panel.

What is the reason of hand cursor on Menu Highlight Item？

[isidorn]

I somewhat agree with this but let's keep this issue open as a feature request to gather more feedback fyi @sandy081

[gjsjohnmurray]

By changing the pointer it's more obvious when the pointer is over an actionable menu item. When over a disabled one the pointer remains an arrow. This is consistent with what happens when pointing at action buttons in the UI.

[Shomnipotence]

By changing the pointer it's more obvious when the pointer is over an actionable menu item. When over a disabled one the pointer remains an arrow. This is consistent with what happens when pointing at action buttons in the UI.

Most of the itmes have Highlight Status , so the hand pointer is uesless

All the apps built by WinForms,WPF,UWP or WinUI3,Qt or other frames did not have this bug(may you think that it is a feature)

[gjsjohnmurray]

VS Code's behaviour in this area is consistent with how the GitHub web UI behaves for me.

[sandy081]

Agreed with @gjsjohnmurray. Its consistent now across VS Code to use hand cursor for all items those are clickable.

CC @misolori

[Shomnipotence]

@misolori I don't think all the clickable items should use hand cursor.

It's inconsistent with Windows' default behavior, buttons are not hyperlinks, this is an app not a website.

[gjsjohnmurray]

this is an app not a website

https://code.visualstudio.com/blogs/2021/10/20/vscode-dev

[Shomnipotence]

this is an app not a website

https://code.visualstudio.com/blogs/2021/10/20/vscode-dev

Yes I know. But Outlook is a website, too. And the Office Online.

[miguelsolorio]

In the past, we've discussed whether we should drop the hand cursor and the team consensus was that it's still needed for the web but on desktop, we need to ensure we still have hover feedback as an alternate. I can bring this up again in our UX Sync.

[Tyriar]

Maybe we should change it only for context menus and the top menu? The pointer elsewhere in the UI is a good thing imo and a big change.

[Shomnipotence]

Maybe we should change it only for context menus and the top menu? The pointer elsewhere in the UI is a good thing imo and a big change.

the explorer has highlight，so it does not need hand cursor

[EFLKumo]

I think it is better to do something else like adding GUI for launch.json instead of arguing on this trivial issue.

[Shomnipotence]

I think it is better to do something else like add GUI for launch.json instead of arguing on this trivial issue.

I am agree with “GUI for launch.json”, but I think the cursor is important,too.

[Shompinice]

I agree with you, this exacerbates the widespread UI inconsistencies on Windows. All this is telling users: this software is a front-end developed by the web, this software is Win32, this software is UWP, this software is developed for a very long time...

[miguelsolorio]

Brought this up in our ux sync today and the consensus was:

• We should explore this in the next iteration, early on
• Revisit areas that don't provide hover feedback
• Show underlines for blue links (since the pointer was the main feedback)
• Read the OS guidelines for mac/win/linux to see if there are guidance
• Possibly keep things consistent across platforms

So we'll start exploring this in our next iteration. Here's a demo of it working in misolori/promising-mammal-pointer

https://user-images.githubusercontent.com/35271042/183965999-b25dc53c-a18c-4e36-942b-966b7375de70.mp4

[Shomnipotence]

今天在我们的用户体验同步中提出了这一点，共识是：

• 我们应该在下一次迭代中尽早探索这个
• 重新访问不提供悬停反馈的区域
• 显示蓝色链接的下划线（因为指针是主要反馈）
• 阅读 mac/win/linux 的操作系统指南，看看是否有指南
• 可能保持跨平台的一致性

因此，我们将在下一次迭代中开始探索这一点。这是一个在misolori/promising-mammal-pointer中工作的演示

CleanShot.2022-08-10.at.08.48.45.mp4

This is a great start!

But in this earliest version I need to point out (though I know this is just an early demo of yours):

In macOS, the search box does not have a hover highlight effect. On Windows and macOS, there is no hover change for normal buttons (there used to be a Reveal effect during the Windows 10 Creators Update)

@misolori

[isidorn]

Assigning this back to the backlog since we will not have time in September to think about this. Also unassigning myself so design ca drive this. I personally think both options are fine.

[Shomnipotence]

Assigning this back to the backlog since we will not have time in September to think about this. Also unassigning myself so design ca drive this. I personally think both options are fine.

I think the design study is over based on @miguelsolorio 's feedback, the conclusion is clear, we should use the default cursor instead of the hand cursor in the hover effect on the desktop

[Shomnipotence]

Brought this up in our ux sync today and the consensus was:

• We should explore this in the next iteration, early on
• Revisit areas that don't provide hover feedback
• Show underlines for blue links (since the pointer was the main feedback)
• Read the OS guidelines for mac/win/linux to see if there are guidance
• Possibly keep things consistent across platforms

So we'll start exploring this in our next iteration. Here's a demo of it working in misolori/promising-mammal-pointer

CleanShot.2022-08-10.at.08.48.45.mp4

I don't know why the assignment was removed, I think the conclusion of the design study is clear that this is a change that must be made.

[gjsjohnmurray]

I don't know why the assignment was removed

@Shomnipotence it has been reassigned to @daviddossett because @miguelsolorio has left the team.

[Shomnipotence]

I don't know why the assignment was removed

@Shomnipotence it has been reassigned to @daviddossett because @miguelsolorio has left the team.

I don't think it's necessary, the design research is over, the conclusions have been made, and it's time for the developers to perform.

[Tyriar]

@Shomnipotence the issue is still open and assigned, so it's valid. I understand you're passionate about this, but try to keep in mind that every comment results in notifications being sent to many people.

[Ryutaku]

After paying attention to this topic for a long time, what was the final conclusion regarding this topic? When will the cursor transition from the hand cursor back to the normal pointer cursor when hovering over tab pages, the left toolbar, and the menu bar?

[Ryutaku]

When the mouse hovers over the menu bar, left toolbar, and tab pages, the cursor displayed as a hand shape makes me very uncomfortable and unfamiliar.

[daviddossett]

No updates here yet. It's in the backlog an we'll revisit this when we have more bandwidth.

[crizzo-xerox]

The issue I have with the hand cursor is it blocks the tooltip and I have trouble reading it.

[kachkaev]

If I understand correctly, there is a simple rule for the web, which can be extended to desktop apps too. If it’s a link with an href, use a hand cursor. If it’s an interactive element that changes something on the current page, the cursor should be a default pointer arrow, a drag hand, resize arrows etc. Most on-page elements have hover styles which communicate their interactivity anyway. A flickering hand duplicates this information (which adds noise), but also creates an impression that an element has some href to copy or open in a new tab.

Can I ctrl+click it to open the result in a new tab? Can I right click and copy the URL?

• yes → Hand
• no → Something else (default arrow, drag hand, resize arrows, question mark, etc)

Most elements in VS Code cannot be opened ‘in a new tab’ (i.e. an external app such as browser), so I guess that the cursor should not change to hand.

---

UPD: Also found this:

Microsoft’s design guides talk about weak affordance:

Text and graphics links use a hand […] pointer […] because of their weak affordance. While links may have other visual clues to indicate that they are links (such as underlines and special placement), displaying the hand pointer on hover is the definitive indication of a link. To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else.

Apple’s Human Interface Guidelines states that the hand cursor should be used when “the content is a URL link”.

W3C User Interface guidelines says the same thing again with “The cursor is a pointer that indicates a link”.

From "Buttons shouldn’t have a hand cursor" by Adam Silver

Source

[westerlind]

This is of course just my opinion, but I think that as VS Code is a desktop app, it should behave like a desktop app. Meaning that it does not matter how web sites normally works.

The standard in desktop apps for all the big operating systems is that there is only a hand cursor when hovering something that is intended to be understood as a link, and that means that it is almost always something that does not look like a button, but is just text that might have a different color and/or be underlined to indicate that it's a link, and it is something that is expected to most likely open a web page, or at least lead to "somewhere else", possibly opening a different app, or in some cases open a folder in the file browser of the OS for example.

I don't know why this should be any different in VS Code. The behaviour that everything clickable is treated as if it was a link is just confusing and feels out of place, and doesn't help the user to understand the behaviour of the application either, as it's different from almost all other applications they will be using.

Someone could of course say that everyone is very used to how the web works, and that this might make sense because of that. But even while browsing the web you will not in any web browser I have seen get a hand cursor while hovering the tabs or the buttons in the toolbar, or menu items. The web browser itself distinguishes between what is a desktop app and what is a web site. So it still doesn't make any sense from the perspective of being familiar to the user.

You can of course run it as a web app too these days, and I guess that there might be more arguments for it to behave like a web site then, but it's still primarily a desktop app and a desktop app should behave like a desktop app to avoid creating unnecessary friction for the user.