Things end users care about but programmers don't
instadeq.com
instadeq.com
Also, if anyone is using a RAD for developing the software for a customer, never, ever, ever, show the customer that a button or any other widget can be easily shown or not, moved, resized etc. on the panel, or be prepared to be asked a layout change like twice a day, of course for free since it's just 5 seconds of clicking. Seriously, sometimes it's much better for users to believe that the UI is some sort of black magic that cannot be touched otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of.
(0) Some good research has been done in the past about how much information the user can be shown before the amount of it ends up distracting from the problem; iirc probably IBM was involved; I was told about that in the mid-end 90s but it likely dates from the previous decade.
I think if you're having trouble managing the workload of UI changes it's a project management/process problem, your client should know how much it interrupts feature development, so that they can weigh up the cost.
While I understand where you're coming from as I've been there, the article was about exactly this line of thinking. You don't care about the minor UI change but the customer does, and they're the ones using the software. Who's issues are really more important?
I am sure you can come up with an example of a pressing development issue that would trump the UI change, but is that really 100% of your time? I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user. We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.
Actual workflow changes, where customers ask for UI changes that make some task easier or faster, are valuable and, at least in my experience, these are very different from the requests you get when a customer realises that UI changes are (by themselves) quick and easy. You can ask for ways that you can improve or speed up their work without them needing to know you can move a that label two pixels to the right in a matter of seconds (which in reality will take hours of back and forward as its never quite right).
> I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user.
The types of UI changes GP talked about (moving a button a few pixels) is not the kind of thing that causes an end user task to be more or less frustrating.
> We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.
But talk to enough of them and you'll see that bikeshedding about pixel positioning is almost never something you want the customer to be doing.
True, the discussion brought to mind a couple projects where the customer/user were the same person. I should have mentioned that, sorry.
IBM discovered that the level of details changes the type of information they got. A couple pieces of paper with hand drawn UI would get great comments on work flow. If you move to more and more realistic simulations of the real environment the comments focused more and more on trivial details and less on the big picture - if the UI looked like it was complete and ready to ship the comments would be about moving things a pixel (never to a different part of the screen even if the screen was designed to put things that belong together apart), or changing the shade of colors.
This is about a situation where you are being asked to contribute, but not giving the contribution wanted.
It's not that discussions on such topics are pointless, but rather that they are of relatively minor importance in the grand scheme of things.
When I ask someone for an opinion on my mock up and they give one it isn't bike shedding. That different mock ups will get a different response is interesting, but no response is bike shedding even if some responses are useless.
Isn't that related to the famous "duck"? That is, something completely useless added to a project (like a UI widget that does not contribute to the functionality) still very noticeable so that it will act as a sacrifical goat, saving other stuff the developers don't want to be messed with by upper management bikeshedders.
That would probably also something for this list.
https://www.interaction-design.org/literature/topics/progres...
This is exactly correct, except maybe for the very last phrase (usually, I think users just put up with the dumbed-down software and just complain about how it doesn't do exactly what they want, and when someone suggests an alternative that has more configuration options, they reject it, saying that they don't want to deal with all those configuration options).
We saw this on Linux desktops with the KDE-GNOME war, and this is with users who are generally considered to be more technically inclined than your average Windows user. Gnome users would complain about options and features being removed, KDE users would point out that KDE has all these features and lots of configurability, and complaining Gnome users would reject it saying it's too complicated and they don't want to deal with all those configuration options. Somehow, the idea of simply leaving the options at the defaults (except the one or two they wanted to change) was completely incomprehensible to them.
Users don't really want freedom of choice. They want something that reads their mind.
Now, config files! Thousands of options, quite happy to hack on that. You know why? Because I can diff against the default and get a birds-eye-view of what's different. I'm not sure if KDE's settings are all text files underneath, but that's the issue. If there were a settings dialog somewhere saying "here's what's different to the default, out of all the KDE settings", that would help a lot. Otherwise it's just too hard to keep track of. This would help on GNOME too, but in the absence of that, simply having fewer settings is a kind of reassurance that there aren't many you've changed and forgotten about.
A separate point, but running default settings is also sticking to the "happy path". It's more well-tested, and I've learned I shouldn't change too many settings different from the defaults, even if they are officially supported, because things aren't as well tested - even if everything official works, third-party things tend to make assumptions that are violated.
I think this is the classic example of "things programmers think users want but don't". There's a literal translation from if-statements -> command-line flags -> checkboxes/radiobuttons. It's easy to implement, and users don't want it, because users don't use applications by thinking about the if-statements used to implement them.
Half of these items should simply be fixed or implemented, and don't correspond to "options" at all.
No joke: I've retired a product where this kind of support was a substantial enough issue to negate profitability when all other factors were taken into consideration.
This wasn't a project management issue (as other posters have suggested), but a problem with the commercial model of the product: fundamentally the pitch over-promised to a degree that the product couldn't be run profitably.
Beyond this it also damaged our ability to work on more profitable and strategic areas. Opportunity cost is harder to quantify but it was obviously still a factor in the decision to retire the product.
The context is really important, otherwise Photoshop, Logic, or any ERP wouldn’t have users.
Also I disagree with the part regarding the UI. It’s the customer money. If they want to prioritize futile details it’s their choice, just bill accordingly. It’s your job to inform them what it’s important to keep there project on track and that changing the UI will move the deadline for example.
[0]: https://www.folklore.org/StoryView.py?story=Calculator_Const...
So the the moral here is "if you work for Steve Jobs, let him do the designs."
This blog post also covers other good reasons why user options are often not the right choice: https://garethrees.org/2013/06/13/options/
In the worst case you can even bill them about it - or even impose a limit to the number of times they can apply minor changes within a day etc.
I agree that sometimes good communication (or good results anyway) means keeping some things from customers who are not technical because they might misunderstand them, but obfuscation of every detail of development is probably not the best way to work with someone who isn't a developer, no?
A good example of this is: Reflection Workspace vs Putty
I know which one i'd choose (between the two, assuming cygwin wasn't an option). There absolutely is such a thing as too much. Although with Putty, I'd never complain about its simplicity -- it has just enough.
Just google the user docs for "Reflection Workspace" if you've never used it. Maybe there are more uses to it, but for the work place I mentioned above, it was 100% just a means of connecting with ssh.
The reason? The pressure in the past from co-founders or stakeholders to 'get things out the door quickly' and to get a quick and dirty MVP out there. This often meant lack of time to consider these small details (or even to backload them into the system later for v1.0).
Also ironically, we've had professional UX and CX designers work on my software creations who have cut a lot of these things off the interface and functionality as 'unnecessary cruft'.
I would also add to the list under Colours/Formatting, that a lot of 'dark mode' designs out there that are considered fashionable just have too low a colour contrast or too small a font to make it readable my someone like me with degrading eyesight.
This adds cost and worsens UX. It has less to do with making the app look attractive from the user’s perspective than with designer ego and satisfying the brand-over-all-other-concerns product owner types. Usually there’s little discussion of features that will be missed so the widgets can work worse, but design flair should, properly, be part of the discussion of what your velocity may look like.
[edit] I suspect some of the motivation for designers here is a combo of selling designs to clients or product owners, who are easily flattered that they need this kind of thing, and their version of résumé-driven-development—that is, highly-custom trendy screenshots probably “pop” a lot better in a portfolio than a better-functioning app that looks more ordinary.
I think you hit the nail on the head here. The designers that have worked on my site seem to be focused on screens that they can add to their Dribble portfolio rather than getting the job done in an efficient way for my users.
Meanwhile lots of successful sites don’t follow design trends the way every designer and startup seem to want to, and others do spend a lot of money fucking up their UI but not in a trendy or attractive way, particularly, and are successful nonetheless.
I suspect “minimum viable design” is much cheaper and more straightforward than a lot of what’s being treated as necessary to attract users, and has less to do with following trends or cute animations or whatever than simply appearing to have been updated some time later than 2005.
As a UX designer, that pains me. The only "unnecessary cruft" I've ever removed was stuff the CEO asked for but tested abysmally with users. We launched it, then quietly removed it a month or two later after they were able to show it off to whomever they were trying to impress.
I tend to always put a description in small print under a button or option (or use a hover tooltip) to explain what a certain button will do when clicked (e.g. a button labelled "Assign Checklist", then underneath "Clicking this will assign a brand new checklist to the employee(s) you nominate". Or perhaps under an entry field for a mobile phone number, I specify in small print that the number should include the international dialling code etc.).
These are examples of things that two different designers said to remove completely so the interface could be 'cool and clean' with minimal distractions. We did see an uptick in support queries about a few things after users inadvertently selected something at the wrong time or entered things incorrectly and wondered why they couldn't send text messages etc.
On the flipside, there were a few screens with 4 or 5 lines of explanatory lines at the top or bottom that we removed and had nearly nil impact, or that users preferred. So I can see the necessity of lessening the things that users will read, but sometimes, I wish designers would go a little deeper and see when something that doesn't look as 'pretty' is still useful to keep.
Won't happen until/unless dedicated design folks have to provide support for their creations. I don't particularly care what looks cool/clean/etc - after having done this for > 20 years, and constantly having to be the one who ends up fielding support issues - either directly from users, or via intermediate help desks - I generally have a pretty good idea of what will confuse or help many types of audiences. That's based on thousands of hours of dealing with common questions, weird hardware setups, language barriers, display issues, network speeds, etc.
The design team doesn't play a role in supporting the product/service/users, but somehow manages to get ultimate authority on how everything should look. hrm....
Frankly, I agree with you. The designers should have a stake in it. At the last place I worked, all designers received a daily report of costumer feedback gathered through the site. We attended monthly reviews of feedback and CSAT and summaries of customer care cases from the month, highlighting top trends and issues that the support staff were handling. We even had representatives from the support team attend our daily standups to raise issues and report back on our progress handling previous issues to the support team so they could be informed when customers asked about things. We even had goals around CSAT that impacted our bonuses. I used to read every single comment we received and even took the time to test and narrow down issues before working with a dev to find the root cause. We fixed some very nasty, but unusual bugs that way.
It comes down to the org: how mature is it with regards to CX and is everyone willing to make the effort to make it a priority?
That really takes a dedication and long-term view that doesn't seem present with most orgs. A non-long-term view also impacts a lot of the actual software too - I'm working with a large enterprise company right now that has rather immense challenges - UX is so low down on the list right now. And yet... they keep getting new customers, and, from what I've seen, it's because their UX is still better than that of their competition, which is truly ... shocking.
But maybe it was a bit of a bubble in a sense. Neither I nor the other designers I knew would take a job at a place that didn't understand an appreciate the value of UX (unless that job was specifically to help change that), so that might be it. We didn't just want to be a mockup monkey spitting out pretty designs.
For a designer, this is really painful to read. But I do agree to some extent. Though it is a little bit more complicated than how you put it.
> Won't happen until/unless dedicated design folks have to provide support for their creations.
This is partially true. The way I work is that I always provide "the best" solution I can think of. I always explain the reasoning behind it. But then it all comes down to the client.
You either have a solution that covers all edge cases, is extendable and works for the use case but usually isn't very cool. But the client "knows" that design sells. So they want something that "pops" and can serve as marketing material on its own. And at that moment it is about the pricing. If you charge hourly, you can iterate however long you want, you can have calls where you argue about usability and long term sustainability of your designs. But if you charge per project, at one point you will decide that you've done enough because it is no longer very cost-effective to continue like that. And you deliver what the client wants and what makes them happy.
And this is where the whole conversation turns almost philosophical. Should you deliver something that is good for the product, but the client is not satisfied (and probably won't recommend you in the future)? Or do you make your client happy, but deliver a sub-par experience? (This happens less and less as I progress and charge more for my work, but still happens from time to time).
You can argue that prioritizing product should deliver better long term results. But there are too many variables. There will be changes in the product that will make your solutions obsolete, or the implementation is not right and the promised result won't be delivered. Or the functionality of your designs change drastically, but the solution stays the same. So statistically, betting on a satisfied client is working better than on good product experience.
You can argue about usability all you want, or you can be part of a longer term process of measuring actual usage and make adjustments after actual users are using it. Between heat maps, click tracking, watching engagement numbers, A/B testing, etc, you can determine if goals are being hit. Are users falling away? Test out alternative UX, see what helps, commit to that. Lose the designer "this is what works best" attitude (not saying you have this, but enough I've worked with do). Help your client help their clients/users.
It's not how most design is thought of - at least in web projects. It's "design" up front - hey, we're using figma - look how awesome all this is! - we can 'design' for tablets and mobile and desktop!. But all the questions about "what happens here" and "how do I deal with a text label that was designed for 20 characters when most of the text data is 30+ characters?" - these get ignored after a client "signs off" on design, and making things "just work like what was approved already!" becomes an ongoing nightmare.
"Look - we did all this hard work of deciding how this should work - you need to just make it work now!" - I've been on the receiving end of these a few times. It's not really all that 'hard' to make decisions when you don't have to implement them. 1-2 years in to my software career, I thought this was a problem with me - I wasn't quite good enough with a piece of software to know how to implement XYZ, etc. This goes back to early VB days, and has compounded with web stuff - someone draws a static 2d picture, and this is supposed to somehow be a gold-standard for how every live interaction should 'feel'. After a couple years of this, I realized it's far less me (although a bit - I'm not perfect), but mostly the process itself, but it's what everyone still does.
If you want 'design' to serve the product/service, it needs to be an ongoing part of the process and budget, and take in to account everything that's learned when users actually use it. If devs need to react to changing use cases, the actual UI and UX may need to be adapted as new information is measured and learned.
I have to agree with you on the examples you gave, those sound like things that were useful to users. It would have been nice if the designer, in wanting to make something "cool and clean", found a way to make those elements belong to the overall design aesthetic, instead of simply removing them. That's the lazy way. The hard things that requires real talent is making utility elements feel sexy.
In the latter case, the product is aligned with the need to sell the system, since the person who pays doesn’t use it.
If so, I recommend a consumer-facing job the next time you chsnge.
I'm afraid there never was any golden age in software.
> The pressure in the past from co-founders or stakeholders to 'get things out the door quickly' and to get a quick and dirty MVP out there.
That's been true since Day 1 of software development. Certainly in all of my career.
I try to get the program being able to be useful informative, easy for data entry, etc. After that - if I get the time - I can go onto enhancing other features like the style sheet (now that you got a good idea of what styles it utilizes its much easier to optimise the CSS to make it skin-able.)
Integrations and import/export is a pretty nebulous thing, and if you are interacting with some proprietary system you are always needing to maintain the export/import code to stay compatible (not that easy). Depending on the format you may run into licensing issues to get interoperability, in others some of the local dev or external use tech might not be mature enough to implement well or correctly.
"Just put an undo on it." "Detailed and up to date guides in text with screenshots at each step and highlights"
Yeah. sigh If the development and team is mature these things will eventually happen. But then comanies fall back when they are riding high on just maintenance and loose the experienced members; then new devs that come in are so overwhelmed on the legacy codebase they just re-write from scratch, picking some bits to reimplement, and loosing a lot of others.
Then again,
you put a knowledgeable developer in to the planning process and they would surprise you "We could reorder this entry process here and cut more than half the time on data entry", "That report on the old system is redundant, here's why" and "have you ever thought of doing this cool feature? Because that would be so easy implement..."
I have been here. Retro fitting a skinning / theming system afterwards invites all kinds of trouble as well. Ideally I would like to design for these customizations in a general sense from the start without spending unnecessary resources on implementing more than just a single style. At the very least, all configurable things should be injected into modules rather than be hard coded all over the place. Things like colors, fonts, language, and the like are obvious candidates, and if you have something for those properties, adding more later on might be easier anyway.
But I am not sure how to sell this type of investment, though. In my experience, the aim is to get the product to the customer as fast as possible for the first couple of versions because we need to have paying customers to afford any further development.
Just to name a few of the major ones:
* Screen-Reader Support
* Alt-text for images
* Sensible zoom behaviour
* Options for keyboard input (instead of relying on mouse)
* Colour-blind & high-vis color schemes (Though "change color of things" covers that, at least)
Funny side-effect is that implementing this stuff very often (I'd even say almost always) makes the product better for your non-disabled/non-handicapped customers as well.
Basic accessibility tool support is not a feature, it just becomes a part of the frontend workflow when you get into it.
My flow is basically:
- Develop some frontend stuff
- Check that I can use it with only keyboard
- Check that it looks OK at 200% zoom
- Run Devtools + axe audit
- Fix any issues found
Of course there are odd cases such as complex custom components that are really hard to get right, but mostly it's quite easy and goes fast.
Just an interesting Side-note: features customers REQUEST and features customers CARE ABOUT are not the same.
People are great at telling what they like or don't like when you show it to them, but they're not always great at telling you how to improve it.
I can't find the source now, but I've come across a story of a game in which players were complaining that the shotgun was too weak. The game devs solved this problem by... increasing the reload time on the sniper rifle, and the complaints went away. The players could correctly tell that there was a problem, but incorrectly diagnosed the best solution (assuming the devs were right in their decision).
Here are some random articles going over this argument in more detail:
https://www.appcues.com/blog/dont-give-users-what-they-want
https://www.nngroup.com/articles/first-rule-of-usability-don...
https://uxplanet.org/stop-asking-users-what-they-want-21e9ba...
Yes, there isn't a specific accessibility category mentioned, but they did include a lot of accessibility items indirectly. "Good contrast", "Automatic contrast of text if I pick a dark/light background", are mentioned in color, those are 100% accessibility. And some are mentioned in UX, "Support touch gestures and mouse", and "Keyboard shortcuts".
EDIT: I wouldn't say they're 100% accessibility, though. I think it actually supports my point that even when you aren't thinking about accessibility, the accessibility features still aid your average user.
https://camo.githubusercontent.com/b25f31e420c078114a2abee62...
More here: https://github.com/alphagov/accessibility-community-notes-an...
* Supporting screen-readers often makes it easier to scrape the site / app (not an 'average' use-case, I realize, and maybe even something the site / app owner wants to discourage) and to copy-paste.
* Supporting screen-readers also makes it easier to switch to 'text-only' or 'de-clutter' modes.
* Supporting (good) keyboard input can make things faster even for people with the option of using a mouse.
* Alt-text is useful if on a slow internet connection and images don't load, or even to describe an image you maybe didn't understand. It also usually gets copy-pasted out if you do a ctrl-a ctrl-c, so you have context of what images were shown where in the text.
* Video subtitles are useful for you to be able to choose to watch a video without sound.
* If your app / site can be used by someone with mental impairments, it's easier for all users.
Most web accessibility stuff does not involve adding disability-specific aid such as sign language, or braille, or ramps. For websites, you can get at least 50% of the way by just following the basic web standards, which I think is self-evidently beneficial.
Note: I am not arguing that the cost-benefit is necessarily in the company's best interest. I.e., I am not saying that including an accessibility feature is beneficial enough to the average user that it's worth the cost of development. I am merely claiming that adding an accessibility feature almost invariably does bring some benefit to other users. However, I will say I think that programmers and companies do routinely underestimate the benefits and overestimate the costs of actually developing these basic accessibility features.
If users want that, they tend to be enterprise customers, and you can charge money for your software. That's good for the programmer :-)
Users who want AD integration also want (generalizing a bit, of course):
* Audit logs
* Metrics export to common BI tools
* APIs
* Separate billing address
* Role-based access control
* a way to sync data between different environments
... and so on. It's amazing how much work you as a programmer could spend "enterprisifying" a simple application.
I kinda wish for better tooling to make enterprise-ready applications, so that many of these things are less effort.
Having a decent integration layer is important: I'm about to spend my Christmas "enjoying" Apache Camel installs to get up to speed there, and it's probably wise to move all auth out to something like Keycloak so that it's just "done" and federation back to AD is config, not code.
As to getting data synching between environments, well... that gets fun all by itself...
Number/date formatting to the right locale
As a programmer, using locales for number pisses me off too; in Poland, the decimal separator is a comma instead of a dot. Beyond me being used to the dot, this causes me no end of grief when entering numbers, because a combination of system locale and preferences of particular software makes it unpredictable.
There are benefits to universalization and standardization; dates and numbers are obvious targets.
Fuggly means fucking ugly, or so I have always thought. Is that not how you are using it? It would be odd to call something "ugly and fucking ugly."
I mean, I think most programmers care about these things and want them too, but people (programmers and end users, but especially end users) tend to drastically underestimate how much they actually cost.
I've contracted for a small dev contracting shop, and it's amazing how, when customers come with a long wishlist of things they want a piece of software to do, these customers quickly "stop caring" about most of these features when they see actual dollar amounts next to each line item.
For most software it would be better to focus on making more core features or making those features better over all of the small (as in usefulness) but large complexity improvements.
Recently I have spent two days working on my personal project's esthetics and polish and was amazed at how gratifying it was to work on that.
As programmers we have the privilege knowledge of knowing which esthetic enhancements are the less costly. Take the time to get these low hanging fruits, it will make users and yourself so much happier!
And as a freelancer, I keep remembering this time when we were developing a complex simulation software for a big client, and that was a 6-12 months development, with little to show as intermediate step. But when we started showing plots (of straight lines! extrapolations that did not make any sense!) clients were really pleased with our "progress" and kept asking for UI improvements. They marveled at our ability to predict when two lines would cross...
Of course parsing CSV will never go well
- universal undo (depending on what kind of operations you're running and how large your databases are, this can be a really weird problem. How do you "undo" a one way operation on 5-10 Gigabytes of data that takes several hours to run?)
- optional cascade deletion (Does your app allow references in formulas anywhere? Have fun trying to automatically rewrite those formulas in a user-predictable way)
- translated to my language (AKA, hire a translator that speaks that language)
- works with the database and version we use (more on this in a second)
- WYSIWYG editor that behaves like Word (Hahahaha, Slack)
- etc...
None of these are "ridiculous" in the sense of, "we could never do that." Many of them are significant asks.
To pick one example, I've worked in enterprise environments that allowed on-premise installs with customer-specific databases. It is a serious pain in the neck. Every time you want to do anything interesting with a data format, you have to figure out what which clients support it, what connectors they're supplying you, and how you can hack consistent file-locking and modification times onto someone's outdated WebDAV client.
And honestly -- we've gone to customers and said, "hey, we could get features out earlier if you switched to an industry-standard infrastructure", and a lot of customers are very happy to make that tradeoff. The big thing to remember is that customers are using your app to solve a problem. That's what matters. End users do care about this stuff, but only if it doesn't get in the way of allowing them to solve their problems.
The language used in the list is a bit flippant, so "Undo everywhere" could seem unreasonable if you interpret that as "users generally request undo features for most actions" and not literally any conceivable thing you can think of regardless of whether or not it makes sense needs to be undone. You immediately jumped to databases, which instead offer a wide range of security and and protection mechanisms to prevent accidental deletions instead. People pay good money for regular database backups because being able to recover from a mistake or failure is important to people, on account of people constantly making mistakes. Even GMail has undo for sending emails now (it just waits half a minute before it actually send the email).
Obviously some of these are silly. "Use this color from here" is a joke (nothing you do will please everyone). "Deploy on exotic configurations/platforms" is almost a joke, but there is always someone who asks when you'll get around to porting your autocad program to the iWatch.
The problem is that this is absolutely not clear to many end users and devs. I have actually dealt with 8 of the 10 formatting wants in the past year, and none are as simple as they sound.
E.g. "using the fonts I use in Office" can be expensive to impossible if you want to properly license the fonts for server use. "No .00 for integers" sounds trivial, but what about ".0000004" when you also implement "No weird .0000004 formatting anywhere". Solveable, but you may need to change the types and not use floating point in some other parts of your application or round the numbers (when?). "The right locale" to use for formatting might change over time in subtle ways due to updates and political/regional changes. Emojis look different in each browser, so you use images: now they look "wrong" in iOS and you probably can't use the Apple Color Emoji font icons due to licensing, etc.
>Not only that, but "behaves like word" is probably meant to be a class of things users want rather than a single thing.
No! Some users might literally find "this behavior is not 1:1 the same as in Word" and if you word ;-) it that way at least someone will understand it as such.
Failing to deliver 100% on such "easy" functionality is often not an option, so just hope that you planned enough time/budget for all the little issues or explain it very well.
To show you I'm at least somewhat speaking from at least some limited experience, I'll also mark features with a check (/) where I or people next to me at a workplace have maintained or implemented these features and found that they weren't trivial to do. For a few, I've also included one sentence descriptions of why they're not a 1-day project.
My point with this is not to imply that any of this is impossible, just that it isn't free. The question you always need to ask when looking at features on this list is, "how many of these are more important than the core functionality that the client actually cares about?"
And it's not that developers don't care this stuff. I would happily rework our entire app at my current company to have one unified UX everywhere and to add emoji support and play with margins and padding and add a custom dark mode. It would be an enormously fun project. None of our customers would care about it.
-----
- Change color of things
- Import/export color themes
- Automatic contrast of text if I pick a dark/light background
- Automatically generate color for large number of items
- Use the fonts I use in Office (/) (Most of these fonts are proprietary, and you can't trust the system to expose them. This problem gets a lot more "fun" when you're dealing with multiple languages)
- WYSIWYG editor that behaves like Word (Again, Slack -- it wasn't just that their editor was unwanted, it was buggy and it didn't work, because WYSIWYG editors are hard)
- Emoji support
- Dark theme (how long did Apple take to add this again?)
- My Theme
- Company Branding
- Integrate with system accounts (/)
- Use accounts/permissions from Active Directory (/) (this one isn't too bad, it just takes time, and setting up a testing environment is a huge pain in the neck. It also needs to be optional, because not all of your clients use Active Directory)
- Import from Excel/CSV (/) (Handling misshapen input is hard, clients are extremely creative with how they will break your importer)
- Import from email/email attachment
- Export to PDF/Image (/) (Text complicates things, there is no single right resolution to use)
- Record a short video (/) (Clients want time limits, not space limits, but time limits are unreliable because different mobile devices all record in different resolutions. Clients start using custom recording software that outputs in formats you didn't expect. You discover that browsers are actually very picky about the video formats they'll play, and the only way around that is to transcode videos on the server. This turns out to be wildly expensive.)
- Send as email (/) (BCC rules and sending limits are different for different infrastructures)
- Send as PDF attachment on an email (/) (compression becomes extremely important because of the above)
- Import/attach images (/)
- Use image as background but stretch the right way (based on what?)
- Customizable keyboard shortcuts (/) (not all input devices give the same input codes for the same keys)
- Undo everywhere
- Multiple undo (I'd like to see how the "delay" trick works with this)
- Copy and paste (/) (arbitrary data types in tables make this hard, your table cells have to handle conversions from every data type, including dumb conversions like "I pasted an emoji into a date field". It becomes impossible to deprecate old data types because they need to be updated to handle conversions from new data types)
- Templates (/) (this is just a big thing to build, there's nothing particularly complicated about it. It's like saying, "image editing". Yeah, that's a feature.)
- Video guides that stay up to date
- Screenshots that adapt to my custom setup (how would this work?)
- Translated to my language (/) (you need translators, also hope you're not dynamically concatenating any strings inside of your application, because different languages have different grammar. The proper way to do this is to never write a string and to always call into a parameterized function to get your strings. And in general, writing messages that are easy to translate requires some degree of training.)
- Sorting everywhere (/) (lazy-loaded lists hate this)
- Filtering everywhere (/) (lazy-loaded lists hate this)
- Cascade deletion (/) (see the formulas problem I mentioned before)
- Preview things (/) (see the expensive data operations I mentioned before)
- Progress bars for slow/async operations (/) (Very rarely do you know how long an expensive operation will take. You usually end up guessing)
- Deploy on exotic configurations/platforms (they're called exotic for a reason)
- Deploy on old/unsupported versions (what does this even mean?)
- Deploy on what we have (/) (I already talked about this above)
- Deploy/Run without internet connection (/) (This makes deploy processes about 10 times longer, and makes patching very difficult, because you can't install for the client. You have to trust them to get everything right, and they won't)
- Handle Excel, CSV, JSON, XML (/) (mentioned above)
- Handle malformed versions of all of the above (/) (mentioned above)
- Integrate with obscure/outdated software/format (/) (mentioned above)
- It should work on my old android phone browser/IE 11 (/) (Babel is not a one-click solution to this problem. We support IE 11 of course, but it does eat up a lot of testing time.)
- Works with the database and version we use (/) (mentioned above)
That's an edge case that you'd need to make sure the UX team have thought about and designed a dialogue in to the undo feature to warn users before they do a one-way operation. That's a common feature in most enterprise apps.
Saying no to a feature because there's an edge case that makes it hard is exactly what the article is talking about - that's a strong signal that the developers don't care about what the users need.
No, I can guarantee that if I went and asked any of the clients at my current company whether they wanted universal undo or the next core feature that we're working on, none of them would choose universal undo.
That's the point that the original commenter was getting at:
> I've contracted for a small dev contracting shop, and it's amazing how, when customers come with a long wishlist of things they want a piece of software to do, these customers quickly "stop caring" about most of these features when they see actual dollar amounts next to each line item.
Of course users want this stuff when they think it's free, but it's not free. Once they realize that it's not free, they very quickly come up with very different priority lists. Being honest about which features are hard, and which features will result in delays, is an unpleasant but important part of caring about users.
Case in point, universal undo matters for creative applications like Blender, Gimp, Photosop, Audacity, etc... For how many people are the lack of features like custom branding or dark modes showstoppers in Gimp? And even if it would be nice to have those, are there enough users for whom its a showstopper to justify ignoring existing users who want something focused on their needs?
I'm not arguing that there's never a context where you'd work on stuff on this list, I'm arguing that the list isn't free, and because of that should be prioritized alongside other features and maintenance based on user research.
You can still fake your undo like gmail does before it sends email. I prefer that over a confirmation dialogue, that users are trained to click through without reading anyway.
Eg you should be able to undo changes to your restaurant order, as long as they haven't started preparing the meal.
Some of trying to 'unsaying' something in Skype. Fake 'unsending' an email only works because we tolerate latency.
That is the wrong shock collar; undo the purchase.
Like that colors feature set would need a fairly sophisticated color theme system, you would have to force designers to work with a set of theme color names vs raw color values along with a design system and you would need a fairly sophisticated color linter to automatically catch things like "Don't place similar colors close to each other"
There are things you can do to make it easier. You can provide settings for specific elements (for example, HN has "topcolor" in user settings). If you're doing a web app, keep the markup simple so that one can use per-domain user stylesheets (try inspecting the markup of a HN page). If you're doing a Windows app, use native controls so they can be themed by the OS. But these decisions constrain what product and graphics designers can do, so you need buy-in from the other parts of your team.
If you want to see a customization nightmare, look at the theming options in blender: the devs diligently expose every color used by the UI there. The list is massive.
If someone gets all of this right in a generic library, I'll tip my hat to them.
You can never just look at a feature and state that it's objectively too expensive without looking at the impact of the feature as well.
Only point I disagree with is when you say "If the feature costs millions and will result in hundreds of millions in extra sales..." It's never that assured that a feature will bring any extra revenue. I actually spent a ton of time in the 00s porting an enterprise software app to the preferred DB of a huge potential client. It was a months long project, and the client ended up not buying the product in any case, and their DB choice was rare enough that it wasn't a big win in the broader market.
A lot of these items, like photo cropping/resizing, aren't hard per se. They're just harder than they should be, particularly to nail every detail. And it's often tangential to the core business.
The main culprit is Excel which does its quirks (localized for one!) to the exported CSV because it knows better.
If there was an investment model in which funding feature development would yield a return from future sales, i feel more companies would move forward with these requests.
If you're using dark mode to save battery on a laptop it's not working.
This hasn't been true of LCD displays for years. They now use LED backlighting, and the backlighting is dynamic (it varies in brightness depending on what'd displayed, and changes across the display too).
>If you're using dark mode to save battery on a laptop it's not working.
This is only true if your laptop is circa 2005.
Cheap laptops today like the HP Pavilions of the world still use fixed-backlight LCDs as well.
1. Software should be free of bugs. At the very least, updates should not introduce new bugs.
2. Software shouldn't phone home. Ever. If I want to submit a bug report I will submit one through the usual OS channels, and I will give my feedback through your feedback button.
3. If you are a web service don't ever popup banners/tips/chat windows/whatever. Put links to them and I will click on them if I want. If you pop up a modal asking for my e-mail address I am leaving immediately.
4. Assuming you are doing well on #1, you shouldn't need to release updates on an hourly cadence. If there is a security vulnerability release a fix ASAP, but for new features bundle them together and release annually for mature software or quarterly/semiannually for software that is still being finished.
I mean having a color scheme that is pleasant to look at is nice, but I would rather you just use my system settings in the first place. What I care about is stability and that the software puts my interests, as a user, first.
1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence.
2. I agree that this should be 100% opt in. I'm fine with an initial prompt asking me for anonymous usage data, then get out of my face. Obviously there are reasonable exceptions for some types of software, but in general, agreed. How do you feel about license checking though? It's trivially easy to rip off software with no server side management.
3. Meh. No one would ever click them. They're annoying, but I've handed my email (with a +<company> appended) over to certain companies for certain coupons. I think a banner is fine.
4. Yearly? I enjoy getting small updates frequently for many types of apps. Being able to iterate on specific features can be good for both sides, and large releases put a big burden on the dev org.
Like most things, it depends. Some software should remain stable for a good amount of time, but if e.g. slack wants to make minor changes every few weeks that are mostly transparent I really don't care (the WYSIWYG debacle is really a management failure.)
Also, #1 is unreasonable. There _will_ be bugs, and now you're proposing they be accumulated for a year before release.
I worked on medical device software for more than a decade and we had a release schedule shorter than a year.
Not the author, but I took this statement to mean no major bugs which actually prevent utilization of the core system. Not necessarily no bugs that aren't fringe or easy to work around or cosmetic only. If the app in question is an alarm clock, the thing better alert me on time every time. Bugs that interfere with that core function are unacceptable. But if the font of the clock is off for one second every midnight, it wouldn't rise to that level. I imagine that threshold varies from person to person.
>Software should be free of bugs. At the very least, updates should not introduce new bugs.
But sure, who wouldn't agree with you? Who doesn't strive for that? Bugs happen, even big ones, to the best of us.
If the clause
> Thou shall not push any major bugs
appeared in your employment contract, would you sign it?
Windows is egregious for this, I'll be typing away and a window pops up and I hit a key and now I've just cancelled something that was running the the background and was ready for the next step :(
It was a long time since I looked but I think there was a registry setting to override this but it's quite rare to see that done.
This is the ideal, especially since it could make software usable indefinitely. Sadly platforms change out from underneath apps, even apps carefully written to use only officially sanctioned APIs. And even Microsoft's years-long efforts at backward compatibility have failed to keep many apps running.
I don't think it's possible without walking back the rolling releases in favor of discrete, infrequent upgrades--at least as a long-term support option.
it sounds weird
So, basically you're writting feature X, then you have no feedback on it for e.g 3? 6? 10? months?
you can ship ready & internally tested features with bug fixes.
I'm sure my software has plenty of bugs, the trouble is I don't know where they are.
What I do have is a no known bugs policy. When I or a customer find a bug then that is a higher priority than adding new features.
Stop what you are doing and read either (or both) The Phoenix Project or The DevOps Handbook.
TL;DR: smaller, more frequent deploys are safer, less likely to introduce bugs, provides faster feedback for better learning, and require built in automated testing, quality checks, and solid telemetry. It makes lives better for developers, qa, ops, product, the company, and customers. This is not "not move fast and break things."
Pick one. If you can't collect data, it is expensive to identify and fix bugs.
That said, I would much rather that your software just doesn't crash in the wild. Ship less often. Either test internally or do a developer preview/nightly build if you need to crowdsource the quality control. Take some pride in shipping software that is good!
I love — love — weekly/biweekly/monthly release schedules with any software I use. As a user, it gives me the impression that the software is being actively worked on, and to me that's very important. I don't care if the updates are minor, to the point of simply fixing typos. I like them, and want them frequently.
I can also speak from the perspective of a developer. If you develop a new feature, why the hell would you wait for weeks/months to bundle it with other stuff, when you can release it whenever it's done and have your users start reaping its benefits right away? That way, they can also start giving you feedback much faster.
This is why I love web browsers - honestly, every time a new Chrome/Firefox build is released, I update right away, and I read the release notes as well. In contrast, we use some enterprise software at work, and it comes out with a new version once a year, full of new features and bug fixes. I hate that. I hate that I have to wait for up to a year or more to get my hands on features I could have gained value from much sooner if the developers were on top of their game.
I'm not saying you should release new features without testing and documenting them thoroughly. But the whole "bundling" approach is terribly wrong and misguided in my opinion.
But constant changes can be a hassle for a lot of reasons. One pretty recent example from our shop was that a third-party service change combined with some vague wording in one of our "start here" docs for new hires led to subtly broken development environments. More often, the changes just randomly make documentation somewhere between difficult-to-interpret and nonsensical.
It also increases the cognitive load for less-frequent users. This has caused me to switch tools out of frustration. ("I'm already relearning this part of my workflow, may as well try something else and see if it sucks less...")
And that's before we get to new bugs, locally-inopportune deprecations, broken integrations, forced on-the-fly workflow modifications and all the other negative externalities of change.
The nicest way to avoid this is to not surprise people - let folks opt in to/roll out changes on their schedule. (With reasonable deadlines, of course, whatever that means in context.)
If I'm using an app, it already does what I want. An update might introduce a bug, so I can't use the app anymore. An update might remove an important feature from the app, and force me to spend time and effort searching for an alternative (particularly annoying if I've paid for it). These sorts of things happen frustratingly often.
For every app on every platform, I would like an LTS option which gets security fixes for a year with NO feature updates.
Yes, you can even get your medical scanner in any color you want. One of GE's standard designs is an MRI scanner painted to look like a spaceship, a coral reef, or a hippo:
https://www.gehealthcare.com/products/accessories-and-suppli...
https://www.flickr.com/photos/gehealthcare/sets/721576294887...
Users have different kinds of obscure hardware configurations. Some programmers may choose to assemble their PC for performance instead of buying an off-the-shelf Macbook, but users will often buy random crap offered by laptop manufacturers, because it looked nice or was cheap - and the cheap stuff is often cheap because of weird/substandard hardware on board.
- The same thing should have the same color everywhere
- Good contrast
is at odds with:
- WYSIWYG editor that behaves like Word
If you give users the option to use all bold Comic Sans, someone will do just that - and other users they share their work with will have to bear the brunt of reading it. Silly example, but it goes to show that you really can't have it all. For every user that cares about one of these things, there's 9 others for whom having to read, understand and decide not to care about it makes the program more complicated than it needs to be.
The average user won't even know what most of this list means.
An important skill for senior developers is to be able to talk about technical things to non-technical people, and not to dismiss the opinions of users based on their lack of technical knowledge.
Aside from that you've conflated two unrelated requirements.
Some of the best guidance for the use of color written in plain, easy to understand language: https://designsystem.digital.gov/design-tokens/color/overvie...
Should be mandatory reading for anyone with any hand in designing a user interface.
I did that when I had my first Amiga. For a while, when I bought a new Computer, I configured Windows back to "classic mode".
After the umpteenth time, it just gets tiring. These days I don't even change the desktop background anymore.
I'd much rather the developer make sensible choice to begin with, so that I don't have to think about it.
Maybe I should look into Vagrant. Even installing extra "developer fonts" on every computer I might develop with is too straining to me.
> [all things color scheme]
A decent color scheme is enough. People don't change it much, if at all, unless they're bored, so I wouldn't go out of my way to support it. Main use cases are, arguably, light and dark mode, and supporting an OS-global switch if one exists. Tips about assigning colors to things are spot-on, though; consistency and discernibility turns color into a powerful communication tool.
> WYSIWYG editor that behaves like Word
Yes please. In some ways, I'm sad that ActiveX/whatever the way to embed Word on your webpage was died. People really shouldn't keep reinventing their own WYSIWYGs on pages, each with slightly different behavior or interface. That said, this would probably be handled best by a set of guidelines or a library from Microsoft, instead of having to connect to actual Word.
> Number/date formatting to the right locale
In my personal opinion, locales should die, and everyone should switch to dot as decimal separator and ISO-8601, respectively. But I'm fully aware the general consensus seem to be different :/.
> Tell me what this does before I click on it
That's what tooltips are for. Harder on mobile, but there's no excuse for web developers who don't include them.
> Support touch gestures and mouse
Support touch gestures and mouse and a stylus, simultaneously, as separate things. Because they are separate. A pen/stylus on a 2-in-one computer (e.g. Microsoft Surface or Dell Latitude lines) is a huge productivity booster if it's supported. It rarely is. I'm constantly hunting for software that does it right, but there's very little of it, and I have not yet seen a single web application capable of handling a stylus (even though technically, the APIs for that are there).
Examples of correctly handling a pen vs. other modalities: without having to switch modes or active tools, allow me to draw with a pen, select with one finger, pan with two fingers, and select with a mouse.
> UX
The entire section is spot-on.
I consider tooltips to be the Norman Doors of software. Users can't figure it out? Slap more words on it!
Are they for teaching, or reminding, or clarifying? There are far better ways to do all of these. The people that need them don't know where they are or how to make them appear. The people that don't need them trigger them by accident and get frustrated they don't go away. When someone does figure out the pattern, they waste a couple minutes moving their mouse very slowly across every square inch of the screen in search of more. Even if there are more tooltips to be found, it's like reading a few sentences from the manual in random order.
I don't think I've ever seen a case where tooltips were the best solution.
Ableton Live (a DAW) has an interesting solution for this: There are no tool-tips at all. Instead, you can open an 'info' box in the corner of the window/screen that instantly shows a quick explainer and relevant keyboard shortcuts for the control you're currently pointing at (and its name), without obscuring anything.
It's not perfect (e.g. there's no way to hyperlink to more information in the on-line help), but on top of being easily discoverable and put-away-able, it can do another nifty thing: For controls that are user-configurable, the 'info' text is user-editable as well. It's like source code comments, but for the GUI. E.g. instead of "Macro 3", you can have: "Glitches the wubs. Don't forget to wax the sidechain!"
Tooltips, and the forgotten art of ellipsis, promising a dialog instead of a potentially destructive action. I've met UX designers that have never heard of them.
(BTW, I know for sure that pattern is a thing on Windows. Does MacOS follow similar guidelines here?)
"The ellipsis character (…) means a dialog or separate window will open and prompt the user for additional information or to make a choice."
https://developer.apple.com/design/human-interface-guideline...
2005:
"An ellipsis character (…) after a menu item indicates to the user that additional information is required to complete a command.
http://www.idemployee.id.tue.nl/g.w.m.rauterberg/lecturenote...
1995:
"The ellipsis character (…) after a menu item means that the command needs more information from the user before the operation executes."
http://interface.free.fr/Archives/Apple_HIGuidelines.pdf
1987:
I couldn't quickly find a PDF I could link to (on archive.org it's "currently on loan"), but AFAICT it says essentially the same thing.
So the guidelines are super consistent. How strictly they've been followed is a more difficult question. Here's a screenshot of GS/OS (to which the 80s version of the HIG is supposed to apply) where they got it wrong: https://en.wikipedia.org/wiki/Apple_GS/OS#/media/File:AppleI...
Ditto on Macintosh System 1: https://archive.org/details/mac_Paint_2
Once I reach the settings menu, it took me a while to figure out what I could click on and what I couldn't. The buttons are not buttons, they're just text. In fact, everything is text[2], only the context ("Live chat" vs "YouTube, a Google Company") suggests that something is clickable.
Why?
It's the customer who doesn't want to spend money or the product owner who needs to be mindful of the budget spend.
So a better title would be: 'things end users would really enjoy but don't actually feel is worth spending money on'. Because if those users would actually think these are valuable things, they would pay for them and you bet that programmers will implement them. They are also users and fairly nitpicky ones.
This is so important to me when deploying frameworks and whatnot; I don't want to ever spend an hour battling nginx or httpd to move it into a fake directory.
The medium (code) should align with the message (experience).
Long to short, not a single user wake up and think "Today I want to use a product based on Technology X, Y and/or Z."
* WYSIWYG editor that behaves like Word
YES.
Searching for "O'Brien" and coming up with no hits because it's in there as "O'brien" is a slap in the face. It's a clear signal that the programmer believes the user should serve the computer instead of the other way around.
Lookin' at you, Linux filesystems...
In the gui it's always been case insensitive.
The fact that the linux filesystem allows you to have a file named "o'brien.txt" and another file called "O'Brien.txt" is a completely different matter than case insensitive filtering.
Otoh, at least they let you call the file "O'Brien.txt"... How many incompetent programmers suddenly decide that because an apostrophe is a part of SQL syntax, it's prohibited to include apostrophes in names? (or prohibit them when they aren't preceded by a backslash, which is just weird. the thinking behind that logic is unfathomable. it doesn't actually make a string safe to include in sql, simply because at some point in its lifetime, all apostrophes grew unwanted backslashes)
> but our tools make it really hard to provide
That's why we build web apps nowadays...
No snark intended. Often a product that solves a real huge pain point has it's own sharp-ish edges too.
(Got my start in the 90s but didn't stay there)
IT:
Your app can magically talk to servers on the internet from behind my Firewall without my IT being capable to whitelist respective servers.
Average users prefer WhatsApp and Instagram over good messengers. I honestly don't know why such bad software is still relevant.
I know you need to keep your designers employed and doing work but please stop.
We have many different apps and we have 3 different versions of the UI right now because we're slowly redoing the frontend for all of them as we roll them out over several years.
What a massive waste of money and time. Some of these apps don't even have enough users to warrant the reskin!
> Automatic contrast of text if I pick a dark/light background
These are not preferences, these are minimum requirements. Programmers should care about this.
If I want it to behave differently than it does, I’ll go looking, and the answer is “you gotta upgrade” then I will. But not a moment before.
Nothing need prompt you while you are trying to use it.
The os should prompt you not every app in their own schedule and with their own ui.
There should be a site that catalogs anti-patterns and nuisances in applications so we can publicly see the outcry over stupid stuff.
If you're not, pay for your software, then disable the setting.
In neither scenario is there an excuse for entitled laziness.
So far as weird numerics are concerned, it's astonishing how complacent the microcomputer world is about that.
I think that 0.1+0.2 = 0.3000000000000004 or whatever it is is a distraction from "it just works" and if we want to offer more functionality to the "non-professional programmer" we should do something about it.
Mainframes have had decimal numeric types from the very beginning since the people involved realized that fuzzy math meant you cut checks for the wrong amount. In the micro world there was the time that Apple had an Integer basic which schools thought wasn't good enough, so they licensed a basic with (bad) floating point from Microsoft.
The people who care about numerics tend to be people who care about performance, those people can deal with the weirdness but they don't want to give up any performance for it at all.
Outside of scientific computation, machine learning, statisticd, etc there is seldom legitimate use for floating point.
Nothing to do about performance I think. Either float is exactly right. Or, it is abused and is 100% entirely wrong.
Right now Javascript specifically is to blame -- for its insane choice of making floats its only and default number type. This is a problem with Javascript only though. If you use Java or C# or go or pretty much any language except Jabascript and type "float" the problem is the programmer not the language.
Javascript math on integers within +/- 10^20ish produces integers and works as expected. It's true that division produces a fraction, so if you're expecting 2's complement integer truncation (absolutely the kind of "funny math" that users in this context are expected to hate) you won't get it.
I don't see this as such a terrible design choice. The alternative is python's equally crazy menagerie of almost-but-not-quite-hidden numeric types waiting to bite you in unexpected ways.
No, it's not. Python and JS aren't the only two approaches to numbers, even among dynamic languages (Schemes numeric tower, which favors exact types, is another.)
Nah. JS is particularly bad on this point, but every language that has not been a special purpose langauge for the narrow domains where float-first makes sense that has made the premature optimization of defaulting decimal literals with fractional parts to floats and/or not providing language level arbitrary-precision decimal and rational types—which is a lot of languages, many more broadly influential than JS (C, for one) are too blame.
I don't disagree with the broad strokes but wanted to point out that graphics is another area where it's useful.
And lots of mathy stuff with practical applications. Audio could be another.
I've seen large company pricing teams do amateur stuff like use floats for their prices because the rational number types are not first class citizens. This probably comes from CPUs not having something like it in their ASM code. They all work with ints, floats and vectors of the two, probably thinking people could just use integers when they need something like a rational number type.
An integer addition (or subtraction) can be done in 1 clock cycle; multiplies will take 3; and division takes far longer, think 20 cycles or more. Fixed point additions are the same as integer additions, while multiplies and divisions both take a multiply and a division (although you can convert one of them to a shift if it's binary fixed point).
Floating point additions are more expensive than integers (due to the need of normalization), taking about 3 cycles. But multiplies also take about that amount of time, and you can do a fused multiply and add in the same amount of time, 3-4 cycles. Divisions, like integers, are more painful, but they're actually faster than integer division: a floating point division is going to be closer to 10 cycles, since you have less precision to worry about.
For rational arithmetic, you essentially have to run a GCD algorithm to do the normalization steps. Even if this were implemented with special hardware, it would be on the same order as an integer division operation in terms of latency. An addition or subtraction would cost a GCD, 4 multiplies, and an addition, while multiplication and division are cheaper at a GCD and two multiplications each.
In summary, if you're looking at the cost of doing a dot product, it's 4 cycles per element if integer or floating-point; 5-25-ish if fixed; and 50+ for rational (assuming hardware acceleration; pure software is an order of magnitude slower). It's telling that the recommendation for solving rational equations is to either convert to integers and do integer linear programming, or to do a floating-point approximation first and then refine in the rational domain.
A final note is that integer division is much more rarely vectorized than floating-point division, so fixed and rational arithmetic are not going to see benefits from vectorization on current hardware.
So what? If you have both rationals and floats (and maybe arbitrary-precision decimals in between) as first class citizens, and give literals the most natural exact type unless a modifier to select floats is used, there's no unnecessary footguns.
Also, zero shouldn't test as false in conditional statements, that's what we have booleans for (sorry, lisp friends nodding along until this moment, the empty list shouldn't be falsy either: just false, and None/nil).
You can't cut a check for 0.3 pennies.
Disrespectfully, No. Please die, IE. Please.
But otherwise, I think the spirit of this is pretty accurate, if only that parenthetical at the top were perhaps more emphasized or explained.
Anecdotally, working for crm-adjacent services, there was just a firehose of things customers (and our own sales/customer-facing teams) wanted to implement for the sake of "customization." And especially some of the customer asks were incredibly QoL-based and reasonable (shocking, I know), but the reality was that the roadmap was being pushed ever along, management and sales want new features to polish up for leads and investors, and we simply lacked the manpower to sufficiently cover both sides of that coin. Now that speaks more to failures in the org structure and leadership than anything (imo), but I think it's not dissimilar at many places, both small and large.
Long edit complete.