Here's an interesting philosophical question for developers:
Is it more important for a solution to be correct but it feels broken to the user
or
Technically not a correct solution but the user feels like it works.
Here's an interesting philosophical question for developers:
Is it more important for a solution to be correct but it feels broken to the user
or
Technically not a correct solution but the user feels like it works.
@BrodieOnLinux as the story goes, apple engineers working on the ipod didnt like the true random shuffle it did so they programmed a "smart shuffle" algorithm (i think its called "genius" or something now) that makes it much less likely to pick songs that are from the same artists/genres as ones already played. so less randomness to make it feel more random
@BrodieOnLinux i wish there was more "correct but feel wrong" though, i am a very very very technically minded person and i cant stand when software oversimplifies things to the point where you feel limited in what you can do with that software
@BrodieOnLinux I'm reminded of the times when KDE's fancy shutdown screen would fail if the nvidia drivers got updated so you would have to sudo reboot. It wasn't KDE's fault, they were just using QT's APIs, and it wasn't QT's fault because it was nvidia's drivers that were failing to function, and, though it was nvidia's fault, they didn't care. KDE *could* have provided a fallback option that would allow you to reboot if their fancy screen didn't work but fuck you for requesting that feature.
@BrodieOnLinux i'm voting option 2 bc ultimately programs are made for the users, but it's more complicated than that
a "perfect" program that disregards the user's needs is sterile, but a program that's made with no rigor is unsustainable. at the end of the day, "dirty" solutions are important when necessary to adhere to the user's expectations, but that has to be modeled into a more rigorous framework at some point in the horizon
@BrodieOnLinux feels like a backend developer versus frontend developer question
@BrodieOnLinux
This is going to sound like a fudge, but
when a developer I wanted to start from the technically correct implementation
with work on improving the UI with regards to intuitiveness, discover-ability or other visible aspects guided by user feedback being ongoing.
User-centric design is important to me but in the sense of making the UI better respect expectations (principle of least surprise) and physical world analogies where applicable.
@BrodieOnLinux
On a more serious note it tends towards a false dichotomy because if something is sufficiently broken on a technical level this will eventually surface as a some inconsistency for the user.
However I have (say) defo stored submitted user data in an "incorrect" flattened interim representation prior to processing into "correct" (e.g. relational database or hierarchical structured) data but that can happen behind the scenes.
But that is more about abstraction/frontend/backend.
@BrodieOnLinux Users are not going to want to use software that feels wrong, no matter how 'correct' it is.
Emphasis on technically; implications being that it works 'as a solution'.
Here's what came to mind for me. Wrong at the time according to the RFCs was http://domain.TLD - sure, DNS is flexible, but don't do that. Proper "form", instead of the canonical domain as the host is: http://hostname.domain.TLD, and although there weren't any hard and fast rules, hostnames like www for one of them newfangled website thingies was usually the most correct choice, with others like www2 in common use. Originally, FTP servers access anonymously (and seamlessly as such) via web browsers were accessed designating the protocoal as follows: ftp://ftp.domain.TLD (hostname "ftp"). Later, or nowadays, most are served via HTTP anyway, so we see things like https://ftp.domain.TLD whereas back when the various protocols were part of the scheme - gopher:// and years later a very little known one that Microsoft basically buried, but worked very well if your skype client was running in the background on your workstation was, skype://@handle - Now that, was pretty kewl.
It's not often that we run across a site that comes up not found and then discover that the A or AAAA RRs actually point to the formerly most correct www hostname, but who actually types all that in nowadays - especially since the consumer, er... "user feels like it works" better to just type in ibm.com and leave the protocol to autodetermination as well as any such actual hostname.
So... yeah, Make the user feel like it works is really (usually) better than making the user do it in a technically correct method - Unless you're not really interested in selling whatever it is you're trying to sell ;)
@BrodieOnLinux for cybersecurity, better be correct than user friendly ans sorry
@BrodieOnLinux sounds like a trick question tbh. Because if it's wrong then it's wrong, and eventually user will realize that
@rustynail Not necessarily, you may decide to fix a bug in your application that users feel like is how the application should be working
@BrodieOnLinux actually yeah, the famous bugs people rely on so you break the userspace when you fix them
@BrodieOnLinux a secret KDE vs GNOME vote I take it 😅
@BrodieOnLinux If it feels broken to the user, you’re doing it wrong. If it is broken in the code, you’re also doing it wrong.
@BrodieOnLinux I suspect that people may have different understandings of "correct" here. Some people are pointing to things like the iPod shuffle, which is a well defined thing that doesn't risk the application crashing or losing the user's data.
@BrodieOnLinux It depends on what you mean by 'wrong'. A program that computes neutron flux for nuclear reactors must be as correct as possible and screw the UI. A game has to feel right even if it fails to accurately mirror real physics.
@BrodieOnLinux If it is wrong then it is not doing what is should be doing. Fake loading screen is one example but a fake sorting filter could be another.
Also note that a solution that is correct but looks wrong is still correct i.e. it does what the functionality said it should be doing thus it is correct.
But maybe you were referring to how the implementation feels to devs?
I subscribe to works well and feels correct. If you're not taking pride in your work to the extent of making it the best that it can be, then why are you in this line of work?
@BrodieOnLinux I think it's a weird question to ask: the solution for the first one is to refine the design or implement the missing part so it feels better and the solution for the second one is depreciation long term because I assume we mean something that prevents other things that WOULD also feel wrong
One has a path for improvement (first), second asks you to redo things because it has to imply other things would feel wrong long term
@BrodieOnLinux I click on whatever is the Gnome approach.