←back to thread

917 points cryptophreak | 1 comments | | HN request time: 0s | source
Show context
squeedles ◴[] No.45761639[source]
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

replies(22): >>45761688 #>>45761787 #>>45761946 #>>45762556 #>>45763000 #>>45763132 #>>45763419 #>>45763515 #>>45764215 #>>45765589 #>>45766183 #>>45766281 #>>45768514 #>>45769691 #>>45771196 #>>45771307 #>>45771846 #>>45772026 #>>45773411 #>>45773951 #>>45776266 #>>45779651 #
duxup ◴[] No.45763132[source]
It always amazes me how even just regular every day users will come to me with something like this:

Overly simplified example:

"Can you make this button do X?" where the existing button in so many ways is only distantly connected to X. And then they get stuck on the idea that THAT button has to be where the thing happens, and they stick with it even if you explain that the usual function of that button is Y.

I simplified it saying button, but this applies to processes and other things. I think users sometimes think picking a common thing, button or process that sort of does what they want is the right entry point to discuss changes and maybe they think that somehow saves time / developer effort. Where in reality, just a new button is in fact an easier and less risky place to start.

I didn't say that very well, but I wonder if that plays a part in the endless adding of complexity to UI where users grasp onto a given button, function, or process and "just" want to alter it a little ... and it never ends until it all breaks down.

replies(7): >>45763322 #>>45763345 #>>45764270 #>>45764775 #>>45765654 #>>45766997 #>>45771204 #
graybeardhacker ◴[] No.45764775[source]
I always tell clients (or users): "If you bring your car to the mechanic because it's making a noise and tell them to replace the belt, they will replace the belt and you car will still make the noise. Ask them to fix the noise."

In other words, if you need expert help, trust the expert. Ask for what you need, not how to do it.

replies(2): >>45765143 #>>45766520 #
rkunal ◴[] No.45766520{3}[source]
It is a common misconception that the "expert" knows the best. Expert can be a trainee, or may be motivated to make more for its organisation or have yet to encounter your problem.

On the other hand, if you are using your car for a decade and feel it needs a new belt - then get a new belt. Worst case scenario- you will lose some money but learn a bit more about an item you use everyday.

Experts don't have your instincts as a user.

replies(2): >>45766995 #>>45767302 #
hobs ◴[] No.45767302{4}[source]
If you don't trust the expert then why are you asking them to fix your stuff? It's a weird idea that you'd want an idiot to do what you say because you know better.
replies(2): >>45768531 #>>45771318 #
1. aidenn0 ◴[] No.45768531{5}[source]
In this case, it's at least partly because the expert has access to a lift...