Hacker News Reader

Comment by Aissen | Hacker News Reader

> I could see some of them shaking their heads and looking at each other. They were very obviously bothered that they had not seen this before.

To me this looks like engineers that had foreseen the problem but were promptly ignored by UX people. Or maybe the other way around.

View on HN

IMO, this is a great example of why show me don't tell me is vital in product creation. Here, the folks empowered to make the change saw the problem with their own eyes. They may indeed have heard or speculated about this issue previously. But there's a fundamental difference between someone saying something, filtered through language, organizational priorities, etc. and making that realization on your own.

Related, this is a part of why good data viz is so powerful: it allows others to quickly and independently reach the same associations and conclusions. A real-world example: a data viz of game beta test user data shows player deaths in an area with no enemies. Curious. Linking over to video from an affected player just before the death reveals a level design error: a tunnel wall wasn't made solid. This allowed players to "fall out" of the level, causing the game to kill them. The development team relayed that before they had these tools, there would often be a back-and-forth with the level designers ("no, that can't be right!"). But now they'd just call them over, show them, and the level designer would get a bit pale and run back to their desk ("brb, gotta fix that NOW!").

While I completely agree with your point that there are things that are better shown then described, it doesn't seem that difficult to say, "The home button is positioned such that it is too easy to accidentally hit it."

Plus all one would have to do is actually use the pen for drawing. It doesn't take an artist actually using it to understand how that's a problem.

I'm sure they did draw on it. But, there's a difference between drawing to make sure drawing works and drawing because that's your job. In the first, people would be more likely to say "oh I brushed the home button". In the second, they're much more likely to suffer a critical flow interruption.

They had plenty of feedback on numerous ms forums of people asking for a way to disable or rebind home button, they ignored all of it.

Currently the only way to influence it is to delete registry key

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SurfaceHomeButton]

and kill all physical buttons completely.

Stop saying they ignored it.

A) The product hasn't even shipped yet. That may be an option or made into one in an early update.

B) There may be a technical limitation to disabling or rebinding it (e.g. without impacting either other buttons, or the behavior of actual keyboard buttons).

Rather than single out engineer and UX guys, it would be more accurate to say that some person(s?) foresaw the problem, and their concerns were dismissed by someone above them.

That's all baseless speculation. In fact in Microsoft's culture decisions like that are almost entirely made by individual contributors working with trios of front-line managers/leads (dev/test/pm).

yes, famous corporate 'mistakes were made, but not by me'

Reply on news.ycombinator.com