Live data from Hacker News

When users never use the features they asked for

web.eecs.utk.edu

201–210 of 228 posts

Re: When users never use the features they asked for

#201

Earlier quoted context omitted.

I wonder how many of these feature requests are because the client does not understand how the software should be used? It could be that it is not designed to solve there problem, and having purchased it they are trying to get some utility from it. Would not be the first time that had been forced to use a system that was not suitable.

This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your…

See this comment in the thread for more of the same attitude.

https://news.ycombinator.com/item?id=28704103

Re: When users never use the features they asked for

#202

Earlier quoted context omitted.

Yea, we were a consumer electronics company that mostly was subcontracted out to make components or complete hardware. I remember working on products for Denon, Crestron, Roku, Samsung, LG, Direct TV, Microsoft, HP, Nintendo, Sony and Audiovox (and their subsidiaries--Monster etc), and in Europe, One For All brand. It was honestly pretty exciting. Regarding web services, like I said, we had a library of these wavefor…

Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers. Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.

I think you hit the nail on the head with that.

Re: When users never use the features they asked for

#203

Earlier quoted context omitted.

Yeah I was definitely right to quit, my career has been pretty great since then. But I did get a lot out of the few years I worked there, even though a lot of it sucked. It was my first proper job and they’d basically let me work on anything I wanted to, even though I was incredibly green and was just figuring it all out as I went. I definitely fit a lot more experience and learning into those years than you’d reason…

I be also had a job early in my career where I was basically allowed to work on anything that interests me and 20 years later I’m still relying on that experience. Maybe this is something every junior should do - try a bit of everything and see what you like.

That's why I think a good consulting agency can be a great first place to work. Lots of projects, hopefully different technologies, perhaps international clients with travel. Then once you know what you like and specialize a bit in it, it's easier to step to some product company as a senior.

Plus, in my experience consulting companies are more focused in employee well-being as it's their only asset.

Re: When users never use the features they asked for

#204

Earlier quoted context omitted.

One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.

I would run from that product.

You would never know that this was happening.

Re: When users never use the features they asked for

#205
post #187
post #133

This happened to me so many times. Like when multiple users asked me to add monitor brightness dimming when the sky is covered with clouds in the Location Mode of my app for controlling monitors: Lunar ( https://lunar.fyi ) Turns out cloud cover reported by weather APIs isn't a good predictor of the ambient light. The feature was so useless (and expensive because weather APIs are not cheap) that it never made it into…

> expensive because weather APIs are not cheap Just FYI, you can get free hourly (or 30/15 minute, I forget) cloud coverage data from the likes of EUMETSAT (and equivalent US/asian agencies).

Thanks for the info! I'll keep that in mind for future projects.

Since then I also found Open Meteo (https://open-meteo.com/en/docs) to be a nice alternative for smaller projects.

Re: When users never use the features they asked for

#206

This is relevant perhaps 10% of the time. The other 90%, the devs have absolutely no idea how to actually perform the task the user of the software is trying to do, don't talk to customers, don't dogfood it, often don't even understand the industry, and the result is a horrible UI which forces people to severely adjust their existing processes to fit the software. Then if course the devs complain about "the stupid us…

Not to mention international address forms which expect you to scroll all the way to U for Brits and Americans. I understand the the alphabetical listing is the most internally-consistent way to display to the users, but either putting duplicate entries for the most popular countries at the top of the list or providing a text field that suggests the normalized country as you type ought to be the go-to, not a purely alphabetic dropdown menu.

Re: When users never use the features they asked for

#208

Earlier quoted context omitted.

Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers. Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.

I think you hit the nail on the head with that.

I'm pretty sure about that, especially since One For All is a brand dedicated to universal remotes.

If I had to take another guess, I would even nail it down on him having been employed by a company called Universal Electronics, which produced a series of universal remotes called "JP1 remotes" in hardware hacker circles (see for example http://www.hifi-remote.com/files/help/The%20WHAT%20and%20WHY...) and also acted as an OEM for a lot of other companies, so their tech could be found in various remotes of different brands.

[edit] I was slightly wrong. He was working for Zilog (which sold their universal remote business to Universal Electronics Inc. in 2009 however) and probably involved with a cool-named product called "Crimzon RC Blaster": https://www.zilog.com/docs/ir/PB0171.pdf

Re: When users never use the features they asked for

#209

Earlier quoted context omitted.

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…

On the topic of lost source code... we had a few blessed binaries that were vital to building System 8 and System 9 at Apple. There was a single build machine that could generate these binaries from other object code but the source was long gone. Oh please oh please old Quadra 700, don't give out on us! Those days are over right? Surely nothing like that is happening with OSX...

That's awesome. :-) ]

Re: When users never use the features they asked for

#210
post #159

Earlier quoted context omitted.

One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.

A quick way to teach users never to click that button again, I'd say.

If they'ed rather not click the button than get you to fix the button, clearly they don't need a working button.
Post reply on HN