@levicki said in Do people actually like poor quality user interfaces?:
For a small number of choices (say less than 10) radio-buttons are superior because choices are all visible at the same time and you can just pick one while with a dropdown you need to perform an extra action (click on a dropdown) to even see the choices, and if the dropdown part is made too short another extra action (scroll) before you can see them all and make a choice.
We'll have to agree to disagree on this one. In my practical experience, 10 radio is pretty unweildy, and to fit on the limited screen real-estate available on mobile devices, and all those "responsive" frameworks handle repositioning them in a really clunky and ugly way by default. Furthermore, since most times I see radio buttons used, they "enable" a div full of additional options which could easily just be swapped out when the appropriate dropdown item is selected. Plus, using a drop-down makes data interchange with AJAX based sites which are backed by APIs a lot more straightforward and results in less server side code like
if (x) {...}
else if (y){...}
else if (z) {...}
Functional decomposition can make this somewhat sane, but I find people who like radio buttons, also like other archaic conventions like "single point of return", and 5000 line long functions, which re-use variables and rely heavily on in-line SQL with no business object layer.
Just my personal opinion I guess. There are sometimes compelling reasons to use them, but only for trivially short sets of choices (and I'm talking like 3 max).
@Gurth said in Do people actually like poor quality user interfaces?:
Not everyone knows this, and in any case, setting the focus on the most likely field a user will want to type into first is going to be quicker all round (except for the programmer, of course).
The downside of this is that there is no way to prevent the first character the user presses from instantly jumping to that field. Depending on the design, this could result in the browser scrolling passed a lot of content (usually describing how or why you're filling in the form, and in more cases than not, this violates the principle of least surprise. Most web users are familiar with the page metaphor, and stealing focus is IMHO "surprising"
Pressing the [Tab] key to advance cursor focus is a vastly more well known concept to most end-users than developers and designers are willing to beleive. I recall my days of developing Desktop Apps, where one of our most commonly reported (although trivial to fix) bugs was illogical tab ordering where the [Tab] key jumped focus all over the form in a random fashion because the original dev didn't set a logical tab order, but it just came out as an artifact of how the dialog was created, and the various deletes, repositioning and copy-pasting of controls.
Yes, I eventually wrote some MFC code to automatically fix tab ordering in a generic and consistent way, left to right, top to bottom, but remember this is was MFC where such things are stored in the dialog's resource file, and doing anything even remotely creative was as frustrating as installing a printer driver from the era, or getting your dial-up internet to work.
You'd battle with inaccurate documentation, different behavior between run-time versions and it still never really worked properly, especially where 3rd party controls commonly rolled their own focus behaviour within a custom-drawn control that managed cursor state whilst it had focus with some elongated state-machine that snatched WM_KEYDOWN for it's own purposes.
I'm just grateful that as programmers, we've moved on to a new, more brightly colored and somewhat less dreary hell, one that for me is a lot less soul destroying, and I think is improving, just sometimes in a bit of a misguide way. At least we now have a plethora of resources at our disposal to track down problems, and for the most part, mashing a misspelled, and vaguely coherent description of your roadblock leads to an almost instant article which at least has others who share your problem. Unfortunately, we're not quit at the point where it always yields a solution.