Live data from Hacker News

Good software knows when to stop

ogirardot.writizzy.com

281–290 of 304 posts

Re: Good software knows when to stop

#281
post #131

Earlier quoted context omitted.

A variant of the first is the highly imaginative user who keeps coming up with new variations or expansions of their idea. It’s not malicious but it can be exhausting. Especially if you try to address their core need but their imagination doesn’t extend quite far enough to see how your effort would help, because they love their ideas.

I would describe those as a variant of the second, not the first. Those imaginative users may be polite, but they’re not understanding. While not rude, they are their own brand of entitled and high maintenance (I like your description of “exhausting”). One major reason I put them in the second category instead of the first is that the result is the same from my side, i.e. I interact with them as little as a I can. To…

[dead]

Re: Good software knows when to stop

#282

Earlier quoted context omitted.

> And the LFG system. The LFG system basically killed most social interaction in WoW. So if you played for that, you got excluded. They also sort of killed build diversity, but there was no build diversity in classic either, at least if you wanted to raid. The grinding... I don't miss it. That could have used toning down.

> The LFG system basically killed most social interaction in WoW. as someone who has played since 2004 with only a handful of month-long breaks, this is simply not true.

I played until (and including) WoTLK. The conversations outside my guild simply ... stopped.

Re: Good software knows when to stop

#283
post #59

> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…

> [...] I decide to take the time to explain [...]

Do you just explain or do you start by asking a question?

What I usually go with is _asking_ what they want to achieve. Because usually, the user describes features/functions/forms instead of explaining the business case. And while the user describes a business case (a thing that generates him money/...) it becomes obvious how/why to implement the request.

So often, people forget to just ask and listen.

Re: Good software knows when to stop

#284
post #59

> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…

> In contrast, if a user has been rude, entitled, and high maintenance, I may end up not even trying to reply in the first place because I know they’ll just be combative every step of the way,

get paid. Stop this nonsense. You shouldn't work for free it makes you disagreeable (I am the living proof).

> I guess the moral of the story is don’t be a prick to the people you’re asking something from.

This is your salary. That's how you get paid. In power. Power over what? "I am a latex maintainer". I'm not impressed. You're wasting your time. Show me your Ferrari instead.

Re: Good software knows when to stop

#285

Earlier quoted context omitted.

Classic represents a different design philosophy. One that still appeals today. It has nothing to do with nostalgia. Or games like Project Gorgon wouldn't be so appealing to people.

So we are back to what I said earlier :p People do not want "classic": people want a "good" game that has some specific characteristics

They wanted _classic_. There was an active vanilla underground private server scene. Those players all went back to Blizzard when Classic dropped.

Re: Good software knows when to stop

#286

Earlier quoted context omitted.

Sid Meier has talked about something similar: he likes to tell designers at Firaxis that "feedback is fact". That is, no matter how strongly you (the designer) believe that something is a good design, if the player says "this isn't fun" then that needs to be taken as the gospel truth. The players might not be able to explain why it isn't fun, and you might be able to tweak the design to make it fun, but what you can'…

What I’ve found is key to UI design is to take this a step farther. Users will often try to explain why it isn’t what they want and they will be wrong about the explanation.

Some phrase I heard a while back, I think it was from bill hader. "People are ALWAYS right when telling you something doesn't work. They're rarely right when telling you how to fix it."

Re: Good software knows when to stop

#287

Earlier quoted context omitted.

What I’ve found is key to UI design is to take this a step farther. Users will often try to explain why it isn’t what they want and they will be wrong about the explanation.

Some phrase I heard a while back, I think it was from bill hader. "People are ALWAYS right when telling you something doesn't work. They're rarely right when telling you how to fix it."

Exactly. Complaints are a Yes And situation. You have to improvise off of their cue but have fun with it or soon nobody will. Each loud user will try to pull the app in a different direction and it’ll end up being schizophrenic if you don’t stick to your own voice.

It’s really questions where I delight the users. They know something is wrong but they cannot articulate it so they assume it’s them and ask how to do something. Which tells you that the feature is missing or not discoverable. If four people ask you the same question it’s a bug not a feature and you should fix it.

Re: Good software knows when to stop

#288
post #205
post #47

We should normalize "finished" software products that stop feature creep and focus strictly on bug fixes and security updates. It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand. Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth of…

Excellent self-owning example: > Dropbox were perfect in 2012 You mean that dumb app that forced you to move files into a single folder instead of adapting to your workflow was prefect? Yeah, no, we shouldn't normalize that, we should push for improvements

Excellent self-owning example:

> You mean that dumb app that forced you to move files into a single folder instead of adapting to your workflow was prefect?

Users in 2012 were overwhelmingly of the cohort who's metaphor for doing work on a computer was the filesystem. You opened Files with Programs, worked on them, saved them. You wanted your latest Files on all your computers (1), and you wanted to Share them (2).

Unless users were on a system managed by a sysadmin there were only really two solutions for problems (1)&(2): you would Email the File (A), or you would copy it to a Floppy/CD/USB (B) and physically move it.

Note the caveat of "in absence of a sysadmin". So either on a school or corporate work environment, or if you happened to have a geek in your family/social group who did it as a passion project. Or y'know, if _you_ were the geek you could roll your own.

So of course when Dropbox was first introduced to a technical audience they didn't get it. See the infamous thread ;) https://news.ycombinator.com/item?id=8863

While you're there, note the tag line in the title of the post "Throw away your USB key"

Now rereading your comment it is clearly an example of exactly what OP was referring to:

> It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand.

If Dropbox did not "adapt to your workflow", then just _don't use Dropbox_.

Instead you attack it as "dumb" and demand it change...and those users for whom Dropbox _was_ perfectly adapted don't have their solution anymore.

Software doesn't have to be forever changing and chasing user growth; it's not a zero-sum game. The bits don't care if no one uses them. But _people_ care if you take away their bits.

> ...we shouldn't normalize that, we should push for improvements

Agreed, you should create a new solution and put it out there! Just as suggested by the post you've replied to :)

Re: Good software knows when to stop

#289
post #265

Earlier quoted context omitted.

What backlash against Adobe? I think you are mistaking comment section consensus for reality. People on forums and social media complain, but the comment section consensus is often dead wrong! There was no real backlash against Adobe. They added subscriptions and grew revenue. Some people grumbled online, but they paid, which means they don’t like the old model, they like the new one.

A company abusing monopoly power to screw over consumers doesn't prove that consumers like to be abused.

There is absolutely no monopoly in photo editing software. Entering this market is fairly easy with a new product. I wonder what market (in software or outside software) could you name as more competitive.

Re: Good software knows when to stop

#290
post #59

Earlier quoted context omitted.

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…

Due to the XY problem what they ask for often isn’t what they need. And what they yell about won’t make them happy. By and large I’ve gotten better feature requests out of looking at patterns of frequently asked questions and turning them into tasks instead of reacting to negative feedback.

[dead]
Post reply on HN