[snth]

I agree with this article that the UX of the software I have to use for work is terrible, and it's very frustrating and demotivating. But their proposed solution at the end- internally developed software, seems to be the worst offender. The worst software I have to use tends to be internally developed, poorly documented, supported, and designed copies of widely used software like bug trackers, project management tools, CI systems, etc. The justification for reimplementing these internally is often security, scalability, or integration requirements though, not UX.

[jaclaz]

I agree while disagreeing, it depends greatly, some anecdata.

In the old days of DOS, circa 1992, I worked in a construction company, a program to make public works accounting was bought (at a very dear price BTW).

It soon became evident that the programmers had (maybe) read a couple of (theoretical/outdated) books on that particular type of accounting whilst they never spoke with an experienced accountant, let alone ever done any accounting themselves.

When the program crashed - actually because of an overflow when we reached on a site works for more than Lire 9,999,999,999 - and some two years of accounting had to be recreated manually (imagine 12-14 people scribbling day and night for one week) because we needed to recreate on paper the progress report to get paid as soon as possible (the software company people were on holidays for the month), we decided to become "independent".

We found a freelance programmer that started working side by side with one of our most expert accountants, and he created (if I recall correctly in three months time or so) a simple/rough program (mind you those were dbase III/Clipper days, no program was actually "refined" from a UX viewpoint) that simply worked.

We kept using it until the late '90's switching to a (hardly better) commercial program in Windows 2000 times.

The original clipper program had its own little quirks and you needed to learn a number of combo-keys to work with it, but once got the hang of it, it was much faster to use than any windows based program.

Same thing happened to me with a hotel managing software, the old software had been originally written by someone who had a cash register maintenance business and actually knew how the actual operations are carried in practice, when it was needed to switch to more modern software (mainly because of some changes in the Laws) I tested some 5-6 of the most common professional (commercial) softwares around, and while 3-4 of them were simply jokes, of the 2 remaining we didn't actually choose the "better" one, but rather the "less worse" one.

And still a number of "common enough" operations are incredibly complicated/take too much time when compared to what the old one could do.

I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.

[travisjungroth]

> I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.

I don't think this is new. I think it's a long standing issue and a huge issue. I worked on home appraisal software and I regret not learning more about the job up front. After like 2 years of developing the app and getting approximately nowhere in the market, the software team actually went on an appraisal. It was eye-opening.

I've also seen the "expert in the room" hired twice and neither time worked (small sample size). I think you need more info in the brain of the dev team, and to have solutions bounced off a bunch of users. One expert ends up as kind of a silo.

[jaclaz]

Sure, there are several issues in the process (hence it is so difficult) the expert(s) must be actually expert (not that easy[1]) and the software house programmer(s) and manager(s) need to be open-minded and willing not to take the (usual) shortcuts.

[1] this is a pet peeve of mine, but at my age I can see the difference between seniority (common enough) and experience (quite rare).

[snth]

That's interesting. I guess the problem software I'm thinking of is all written by software engineers for software engineers, so the "detachment" issue isn't as severe. There is some, since we work in different parts of the business. The main issues I see are that 1) a small in-house team working on internal tools doesn't have much hope of putting in the time and resources of a whole company developing the same thing for public customers 2) once a company funds an internal tool, there is usually a lot of pressure (or even a mandate) to use it, even if there are better choices 3) the in-house team is also constrained to use our other in-house tools as dependencies, whether they're better or worse than other choices.

I can see the advantage to developing something in-house if there aren't options that meet some special need, I just personally haven't seen it work out much. Maybe because of the size of companies I've worked at. I've definitely written helpful software for myself and my own team.

[paulryanrogers]

> it was much faster to use than any windows based program.

In retail and later as a software engineer I've seen that expert systems need keyboard shortcuts. Ideally the fewest possible for the hottest paths. Yet for onboarding you need the most obvious and relatable UI. Windows apps can be both if well designed. Console and terminal based apps generally cannot pack as much into the UI and most folks don't know them before joining.

[oblak]

I was so impressed the first time I saw a relative use their government mandated accounting software for DOS. That woman was going through forms faster than me doing mortal kombat 3 combos. Not sure that would be possible these days with remote databases and such.

[jaclaz]

As I see it, the paradigm that Windows (actually the programmers working on windows programs) broke was the centrality of keyboard.

In windows (or more generally GUI) you usually need to constantly move your hands from keyboard to mouse (to click a button and "go ahead") and then back to keyboard to type soimething, then mouse again, etc.

I believe this is only due because of the choices of the programmers that used some "default" modes.

To give you an example the good ol'Dos program I was talking about used Enter to confirm data typed in a field AND move to next field, to go back to a previous field it was Ctrl+Enter, then you had to press F8 to confirm the whole form and exit to the main menu or F10 to confirm the whole form AND go to the next form of the same type.

When you got to a field like "state" or "country", that need to match an existing database, windows programs mostly have a drop down list (and you need the mouse to open the drop down list and scroll down until you find the one you want), the old program allowed to either enter the two-three letter country id (like IT for Italy, DE for Deutschland, etc.) OR to type the first few letters and then autocomplete with - if I recall correctly - F4.

Dates could be typed without separators, i.e. 22082021 and when you pressed enter the field would be automagically formatted to 22/08/2021, currently in lots of programs (or web sites) you have to click and then a calendar pops up, and you have to click three times for day/month/year, some "smarter" ones have a button for "today" but that, for a field like "date of birth" makes no sense whatever.

This latter is a pet-peeve of mine but 3/4 to 7/8 of all web shops, including those that are clearly national only have a drop down list for countries that invariably starts from Afghanistan, which possibly represents 0,0000000001 % of the orders.

Then you have "tabs", on a huge screen 1024*768 or higher resolution the actual form is a tiny window, and you input name/surname/birthday/address, etc. on it, then you have to switch (why?) to another tab to enter (say) fiscal data and to yet another one to add notes.

Of course there are also better UI's, but the large majority is as I described above.

[oblak]

Taking the time to develop an application that is usable with a kbd/mouse is a tough sell, even when not dealing with mobile apps. Some people want to do it, but does it bring more money? No... so we, don't do it unless someone does it on their own time.

[ssss11]

It might depend on the internal talent, but, ERP vendors are always going to be incentivised to deliver “just good enough” software and then sit back and take in the cash.. so I’d think with an internal team you _may_ have the opportunity to do better