Live data from Hacker News

When users never use the features they asked for

web.eecs.utk.edu

71–80 of 228 posts

Re: When users never use the features they asked for

#71
post #14

A metaphor for this situation (building exactly what customers ask for) could be the car Homer Simpson designed ("The Homer"). https://simpsons.fandom.com/wiki/The_Homer Not that all users are equal to Homer, but what they think they want and what they actually need are very different. It's better to get more detail on the problem, then present a series of possible solutions to evaluate and iterate on.

Went down the rabbit hole from your link:

> > It is a parody/exaggeration of the Edsel, a similarly disastrous automobile designed by Ford Motor Company.

Points to https://en.m.wikipedia.org/wiki/Edsel:

It has a "Design controversies" section that's very relevant to today:

> Complaints also surfaced about the taillights on 1958-model Edsel station wagons. The lenses were boomerang-shaped and placed in a reverse fashion. At a distance, they appeared as arrows pointed in the opposite direction of the turn being made. When the left turn signal flashed, its arrow shape pointed right, and vice versa

https://en.m.wikipedia.org/wiki/Edsel#/media/File%3A1958_Eds...

Why is it relevant? Related thread from 3 days ago about blinkers with the exact same design flaws , but in 2021: https://news.ycombinator.com/item?id=28661282

Re: When users never use the features they asked for

#72
post #46

Earlier quoted context omitted.

Yeah sounds like the lesson here is that nobody reads the update messages.

If quantum scientists thought the slit experiment was exciting, they should study IT user preferences and be amazed how depending on the mode of communication/observation, customers will both scrutinize every letter you write while simultaneously not reading it at all, will know every wrong pixel of your UI but not know where the button for "Thing" (labeled "Thing") is, and how anything you make is somehow the best w…

This comment made my day.

Users not knowing what they want but knowing that they want it is a useful phrase.

Re: When users never use the features they asked for

#73

I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…

This is why changelogs and release notes are not optional or tucked away in a dark corner. And users who request features need to be notified (actively, specifically) that something they requested or a bug they hit was resolved or addressed. I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.

changelogs and release notes don't get read. unless you're sending personal emails to the users who requested the feature, the experience in the essay here is the only way: make it automatic or turned on by default.

and if it's not good enough to be automatic or enabled by default, then keep iterating until it is.

Re: When users never use the features they asked for

#74

Earlier quoted context omitted.

Jira takes the biscuit with their text editor. Always changing and hard to make sense of. Recently ctrl-enter and enter actions were swapped!

My favorite thing about their text editor is that it will delete all of your changes with no option for recovery if you accidentally hit the escape key. I also like how this has been an open issue for many years on Jira, but they refuse to change it for some reason (or at least that's the state of it the last I checked about a year ago. Thankfully, I don't have to use any Atlassian products anymore.)

I HATE that! too many times my vim muscle memory has cancelled out of a long comment or issue description :(

Re: When users never use the features they asked for

#75

Microsoft didn't run automatic code analysis tools as part of their code review process until 2017? What on earth was wrong?

They wrote a bunch of them (StyleCop among others) for C#. And Intellisense which relies on being able to analyze code all kinds of ways. I find it hard to believe they didn't.

Re: When users never use the features they asked for

#76
It's a great story - thanks for sharing. People don't want to offend other people, so normally you not gonna get negative feedback when talking to someone face-to-face.

Also for the code review tool - it's a sort of "consultant issue". I work on the floor and probably overworked (and maybe stressed). Then a random person shows up with an "improvement" pretending to be of some use to me. Thanks, but you should ask me first what needs to be improved in my day-to-day job. That only causes negativity. Not sure if this was the case, but close enough.

Re: When users never use the features they asked for

#77

I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…

This is why changelogs and release notes are not optional or tucked away in a dark corner. And users who request features need to be notified (actively, specifically) that something they requested or a bug they hit was resolved or addressed. I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.

That's great advice, but it's untrue that nobody reads changelogs.

I read them religiously for software I'm passionate about as a user, and when I solo'd a product for a decade I was regularly surprised how familiar some of my customers were with mine (most often when they had dedicated IT resources or were similarly small boutique outfits themselves). I've also managed large, custom enterprise projects where subject matter experts on the other end relied on them (in addition to other channels of communication).

What drives me nuts is how some companies decided to water them down. e.g. Windows Update's long list of "security related update" where you have to google KB's to find out what they are, and another company that just always puts in "various fixes and improvements".

Re: When users never use the features they asked for

#78

Before the launch of the XBOX 360, the company I worked for was one of their suppliers, and without going into enough detail to make me identifiable, the management of our two companies had arrived at sort of a stalemate: We didn't want to tell them exactly how our algorithms worked, and they didn't want to tell us exactly what they were doing with them-- think of it like a data compressor where, we don't want them t…

The worst programming experience of my life related to lost source code. I was working for a place that had a service running from a Java app that was customized for each customer, about 200 copies of roughly the same app. There was source control at some point, and when a new customer was being on boarded they’d just make the customizations they required, compile the app, and deploy it. By the time I worked there (y…

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!

Re: When users never use the features they asked for

#79

Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…

One automated thing I've been really wanting to add to our code review process is copied code detection, where a piece of code is very similar to code somewhere else in the product (though likely not part of the current review).

Obviously there's cases where this is code smell, but plenty of times it isn't. It's not something that you would want to block shipping. But if you do want to ship code like this, you should do so with the reviewer(s) fully seeing where it came from, to make sure everyone agrees that's the best way.

No one has implemented a bot for us that would add such comment for use but I do think it would be a huge win.

Re: When users never use the features they asked for

#80

I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…

To clarify, was he not aware that the new feature had already been released? Or did he think the "old way" was the new feature (and that he'd simply been blocked before), thus suggesting that the urgency of his ticket was unnecessary?
Post reply on HN