←back to thread

917 points cryptophreak | 3 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 #
1. patrakov ◴[] No.45772026[source]
While working for one of the previous companies, I hit a regrettable counterexample for the point in the article.

Developers built a web UI for creating containers for the labs, taking the advice from this (then future) article too literally. Their app could only build containers, in the approved way. Yet, not all labs were possible to run in containers, and the app did not account for that (it was a TODO). Worse, people responsible for organizing the labs did not know that not all labs are compatible with containers.

Lab coordinators thus continued to create containers even in cases where it didn't make sense, despite the explicit warning "in cases X, Y, Z, do not proceed, call Alexander instead".

So if you make one button you better make that it is always the right button. People follow the happy-but-wrong path way too easily if there is no other obvious one.

replies(1): >>45772059 #
2. nemomarx ◴[] No.45772059[source]
Having to read a label and go out of the tool to do something else is basically impossible UX, yeah. You'll never get users to do that, and little in line warnings also won't work unless you block the buttons at the same time I think.

In this example I wonder if the tool was too "MVP" and they didn't evaluate what minimum viable would mean for the users?

replies(1): >>45772118 #
3. patrakov ◴[] No.45772118[source]
In this case, the product owner had a wrong idea of what's minimum viable, and his idea was faithfully implemented, plus a warning in the app to call me in specific incompatible cases.

Later the missing pieces were added, we had "two buttons" and the resulting user confusion because they did not know and could not be taught whether a container makes sense for a particular lab.