Computing desk
< January 22	<< Dec \| January \| Feb >>	January 24 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 23

Usability

Why does usability score so low on most commercial software products? Or to put it another way, why is its importance so low when it comes to their end users? I was recently on vacation, and I noticed that the hotel staff were complaining about the usability of their in-house systems (the door key cards weren't issuing correctly and were cancelling the cards out), the rental car staff were complaining about the usability of their reservation systems (the system issued a car with the wrong license plate, which meant the correct car could not be picked up), restaurant staff were complaining about the low usability of their POS systems (their system did not put the drink orders through), uber and doordash drivers were complaining about the low usability of their rideshare and ordering platforms (delivery addresses and GPS didn't match), etc. Please do not reply with "confirmation bias". There is obviously something wrong with the way software is designed and it permeates the entire enterprise system. And as if that wasn't enough, I was at Costco today and the same thing happened at the tire center (reservation was deleted from the system). Viriditas (talk) 00:48, 23 January 2024 (UTC)[reply]

If there is more here to confirmation bias, it is likely due to priority differences between the consumer and employee. Companies usually prioritise the experience of customers over their employees as customers are the ones who the company wants to bring back for their wallets. If a customer has a bad experience, they are likely to find a better company to buy from. If an employee has a bad experience, then toughen up buddy. This translates into software: if a customer has a bad experience using the software, then that is a serious issue, but if an employee has difficulty with the software, it is not as bad. —Panamitsu (talk) 01:52, 23 January 2024 (UTC)[reply]

Yes, exactly. This confirms what a high-level employee at a five star hotel told me. Viriditas (talk) 02:23, 23 January 2024 (UTC)[reply]

I wouldn't classify these problems as usability issues. They are plain errors (aka bugs). The prevailing approach to reducing such errors is by repeated testing and fixing. The examples are of in-house systems, possibly custom-built, which are hard to test extensively before they are deployed. The question is perhaps more why such errors are not promptly fixed. The software company that built them may have gone belly-up, and the software may be a legacy system that no one knows how to maintain. --Lambiam 11:05, 23 January 2024 (UTC)[reply]

Alternatively the software may be the cheapest that management believes (based on a salesman's spiel) will do the job. Once bought it is hard for management to back out and admit to a wrong decision. Martin of Sheffield (talk) 11:15, 23 January 2024 (UTC)[reply]

Sometimes the software may be excellent, but over-complex for the actual task involved. I worked for an engineering and maintenance company that bought an expensive, advanced and doubtless well-programmed business suite in order to use its stock management module to replace a simpler procedure using spreadsheets, despite my advice (as one who would need to consult its records) that to enter all of the system-required data properly would require extra personnel.

Just as I predicted, the existing warehouse staff found entering all the data too onerous, so the stock records rapidly became unreliable and deficient, and the new system was quietly abandoned. {The poster formerly known as 87.81.230.195} 176.24.47.60 (talk) 11:53, 23 January 2024 (UTC)[reply]

I am nearing retirement in commercial project development. Over the past 40 years, I've been a developer on many projects from entertainment to stock control to accounting to command and control to health equity research and much more. I see the same thing time and time again. A company will hire a group of developers. Half (or more) of the developers spend the entire time arguing about what programming language to use, what framework to use, what repository to use, etc... A few of them will develop the project to the best of their ability, making decisions based on what they think should be done. Because of the isolation behind all the layers of management and bickering, they don't have the luxury of discussing issues with the potential clients. Then, when the project is released, the development staff is fired and replaced with sales people. Any usability issues are fixed with training and documentation. True bugs are fixed by logging the complaint, hiring a long line of contractors to come in, say that the programming langauge is wrong, the framework is wrong, the repository is wrong, cash a check and leave. Eventually, some companies will rehire one of the original developers to fix the bug and then go away, never to talk about it for threat of lawsuit. So, if you experience issues with a product, it isn't a surprise. That is how the developement world is set up. In the end, everyone just points at the guys who developed it and blame them, but they were fired long ago, so they don't care. 12.116.29.106 (talk) 13:34, 23 January 2024 (UTC)[reply]

I first heard this story 25 years ago. Are you telling me that the software development process hasn't changed a bit in all this time? What about lessons learned? This is surprising to me, but I suppose if I think about it for any length of time, it's the same situation in every other sector. Institutionalization and "the way things have always been done". Incrementalism, inertia, and bureaucratic, top-down hierarchies are to blame. Viriditas (talk) 21:00, 23 January 2024 (UTC)[reply]

Sounds about right. Commercial software is developed (perhaps not in the first instance, but eventually) by teams of programmers who may not be familiar with the product (one among many they support) based on specifications negotiated between project managers (who are no more familiar with it that the developers) and the client's accountants (to keep the price down), on behalf of middle managers (because no one dreams of getting the actual users involved in something so complicated as working out what they need). Software development may have moved on; commercial and human realities haven't.

The best software is developed by people who need it for themselves and have the skills to do it (eg Linux and many open-source products); the best software I developed was done for myself, or for the people I could actually sit alongside to watch and talk to. -- Verbarson ^talk_edits 21:51, 23 January 2024 (UTC)[reply]

I agree. I've written a lot of good stuff for myself. Also, it is best if one person does the whole thing and sticks with it for the lifetime of the project. In my career I worked on two small programs written in BASIC, but otherwise I either started from scratch (doing everything), or looked at their existing program and started over from scratch. You are so familiar with it if you have done it all yourself. (Also, I can find my bugs a lot easier than I can find bugs written by others.) Now, my daughter is a software developer, but she works only on certain aspects of projects already written by others. Bubba73 ^{You talkin' to me?} 22:20, 23 January 2024 (UTC)[reply]

Linux and many open-source products are famously criticized on usability terms. When this is raised, many developers counter by encouraging the user to fix it. The user won't so the usability flaws and the user discomfort continue until the user abandons the program.

Just today I was reading CUPS:

Starting with Red Hat Linux 9, Red Hat provided an integrated print manager based on CUPS and integrated into GNOME. This allowed adding printers via a user interface similar to the one Microsoft Windows uses, where a new printer could be added using an add new printer wizard, along with changing default printer properties in a window containing a list of installed printers. Jobs could also be started and stopped using a print manager, and the printer could be paused using a context menu that pops up when the printer icon is right-clicked.

Eric Raymond criticised this system in his piece The Luxury of Ignorance. Raymond had attempted to install CUPS using the Fedora Core 1 print manager but found it non-intuitive; he criticised the interface designers for not designing with the user's point of view in mind. He found the idea of printer queues not obvious because users create queues on their local computer but these queues are actually created on the CUPS server.

He also found the plethora of queue-type options confusing as he could choose from between networked CUPS (IPP), networked Unix (LPD), networked Windows (SMB), networked Novell (NCP) or networked JetDirect. He found the help file singularly unhelpful and largely irrelevant to a user's needs. Raymond used CUPS as a general topic to show that user-interface design on Linux desktops needs rethinking and more careful design.

--Error (talk) 00:17, 25 January 2024 (UTC)[reply]

Software crisis is written as if it were a thing of the past. Agile software promises to keep the developers closer to the user needs and to deliver something that at least approaches them unlike the bureaucratic waterfall model. --Error (talk) 00:17, 25 January 2024 (UTC)[reply]

It has been promising that since 2001. --Lambiam 13:23, 30 January 2024 (UTC)[reply]

Another factor may be that there are so many programmers now that the talent is spread thinly. Bubba73 ^{You talkin' to me?} 20:26, 23 January 2024 (UTC)[reply]