3 ms·
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 soluti
by snth 5y ago
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 5y agoI 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.
- paulryanrogers 5y ago> 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 5y agoI 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 5y agoAs 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.
- ssss11 5y agoIt 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