Hacker News new | past | comments | ask | show | jobs | submit login
Things end users care about but programmers don't (instadeq.com)
406 points by marianoguerra 37 days ago | hide | past | web | favorite | 245 comments



I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" (0), shuts down and uninstall the software then chooses an easier one that forces mostly predefined options on a dumbed down panel, only to complain later that it can't do this and that therefore a more powerful one is needed. Rinse, repeat:^)

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.


> otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of.

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.


Even if the customer is the user, these "move the button to the left by two pixels" type of requests are very common and really aren't important. I've seen users do this because it makes them feel like they have input and I've seen these types of requests turn into serious bikeshedding. They never actually make any difference to how they use the product, but these tasks end up taking a lot of time (that as GP said, the customer typically doesn't want to pay for because its a small change).

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.


The assumption that the client is the user doesn't hold true in many projects. In fact, letting the client mess up the layout may ruin a UI that was carefully validated with the the user.


"The assumption that the client is the user doesn't hold true in many projects."

True, the discussion brought to mind a couple projects where the customer/user were the same person. I should have mentioned that, sorry.


That's a fair point. My comment was imagining a project where the customer was the user/users.


I can't say I've ever seen one of those! (Except for B2C, but that's a different case)


As I recall - from the mid-90's so my memory is probably a bit wrong...

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.


What you're describing is called bikeshedding. I'd bet people generally feel like it's easier to "contribute" to a drawing than to something that looks more concrete, like a demo or semi-functional mockup.


No, bike shedding is different. Bike shedding is a pointless contribution to something just to prove you thought about it.

This is about a situation where you are being asked to contribute, but not giving the contribution wanted.


This is incorrect. Bikeshedding[1] applies when people prefer to discuss less complicated issues rather than those of a higher priority (which are more complicated).

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.

[1] https://en.wiktionary.org/wiki/bikeshedding


Bike shedding is when you discussion irrelevant issues. If I ask you what do you think of about this shade of red for my bike shed your answer isn't bike shedding. If I ask you if I can build a bike shed and you tell me only if it is red that is bike shedding.

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.


"Bike shedding is a pointless contribution to something just to prove you thought about it."

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.


Well some applications have a 'simple' mode per default and then let the user switch to 'advanced'.

That would probably also something for this list.


In interaction/UX design this is called progressive disclosure, and is explained on a strategic level here:

https://www.interaction-design.org/literature/topics/progres...


>I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" (0), shuts down and uninstall the software then chooses an easier one that forces mostly predefined options on a dumbed down panel, only to complain later that it can't do this and that therefore a more powerful one is needed.

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.


For me I don't like having to keep track of what's default and what's not. What if I change a default, things change unexpectedly somewhere as a result, and I'm not able to work out what change it was due to? Fewer options decreases the odds of this happening. Other good approaches are highlighting settings that are different from the default. Many UIs do this, but unfortunately it's hard to get a birds-eye-view.

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.


You bring up a good point: it would be nice to be able to quickly see what options are different from defaults, whether in graphical or text form. I don't know of any UI (for a desktop environment) that does this, however, but I do like the idea. I do believe I have seen this kind of thing for more specialized products or programs. I will point out though that with Linux desktops, the defaults are different by distro, though still this shouldn't matter; it shouldn't be that hard to have a "master" config file and then be able to diff it, or have a UI panel that does this in a more user-friendly manner.


There's a medium to be reached. It's to give a clean starting point, and make options intuitive to discover and useful to implement. At the risk of drawing the ire of the anti crowd, Mac OS X does this marvelously well.


I'm very anti-Apple, but it's foolish to think that there isn't anything at all to be learned from how they do things. Same goes for Microsoft.


> all those options in a configuration panel

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.


> ...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. ... otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of.

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 user looks at it saying "uh... too complicated"

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.


Once, I had to organize a meeting to propose a big reorganization of the supervision of our main software. There were some functional changes et some UI changes. I was inpired by the story about Steve Jobs and the calculator. I have brought a prototype where I could change fonts (size, boldness, italics, color), some text and tooltips. This meeting was a success. The stakeholders were happy to have influenced the UI. All the functional changes were accepted. No further roundtrip.


For those who haven't seen it, I believe reacweb is referencing this [0].

[0]: https://www.folklore.org/StoryView.py?story=Calculator_Const...


But in the end it doesn't sound like they shipped the configurability features, just the Jobs UI.

So the the moral here is "if you work for Steve Jobs, let him do the designs."


I might alter it slightly to say "If you work for someone that thinks they're Steve Jobs, let them do the designs".


Will definitely result in managerial approval of the design, but not necessarily a good design.


In all companies I’ve worked, managerial approval of a design (or feature) was far more important to obtain than a measurably good one. It’s called HIPPO: HIghest Paid Person’s Opinion.


In addition, every additional setting multiplies the number of states your application can be in, and the combinatorial explosion of states is mostly not well-tested. If you set even a handful settings to non-default values, it's likely that you are running the application in a totally unique configuration that's not used by any other developer or user. If you encounter bugs, you're liable to get the "Idk, it works on my machine" response.

This blog post also covers other good reasons why user options are often not the right choice: https://garethrees.org/2013/06/13/options/


Create a separate "Power Users" configuration program. Everyone loves being a power user.


So that's how gnome-tweaks happened. I was always confused why there were a bunch of settings you had to install another package to change.


They tried this with KDE. It didn't go over well. Everyone just complained about all the configuration options.


Isn't this a matter of communicating well with the customer? You make a very reasonable point here and it's clear to me that applying minor tweaks too often is disruptive and ends up accumulating costs. Surely the customer can be made aware of that?

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?


>>The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated"

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.


Yeah, but showing the user the GUI early is important because otherwise you are risking to build the wrong tool. End users usually only understand the GUI not a specification.


There are ways of supporting extensive configuration without showing all options at once. Firefox config is one good example, vlc’s strategy is not my favorite but it works, “advanced…” buttons are another.


[flagged]


Apple's software is the worst when you need to configure something. Especially on iOS. Most people tend to use the default because usually they can't find, let alone configure the settings.


I think generally their mantra is to choose sensible (though that's debatable) defaults, and minimise the ability to configure at all. Of course, that drives some people insane, and even if you generally like it, you're totally stuck if they make a choice you don't like. Same goes for hardware -- I really like macOS, but if Apple started, oh I don't know, releasing laptops with non-functional keyboards, I have nowhere else to go.

I get more frustrated by the lack of communication of activity/failure states though. So much of their software on both iOS and macOS will give you nothing more than a spinner to indicate activity, then if something goes wrong will just...fail silently. Even informing the user that something failed is despairingly rare.


> minimise the ability to configure at all

Yep. What users want is "Freedom from Choice". See also: The Paradox of Choice.

And that's one of the fundamental value propositions of the Apple brand: we have fussed the details so you don't have to.

And that approach has interesting failure modes.


Right, so one programmer says features are confusing and shouldn’t be done because they’re in the user’s face. Another says that it’s confusing to hide them.

Sense a pattern here?


Not all users are the same, is the moral of the story here.


Apple software is simply dumbed down defaults with hidden settings (most of the time settings are also not that useful)


This article is a good reminder. When I started out my programming career many years ago, these things were fundamental in the way I created software, however things seem to have gone downhill in recent years.

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.


My experience is a lot of money gets burnt making designs match some on-brand design that looks awesome in mockups but is worse for the user than just using the platform default GUI widgets with maybe some light color theming. Worse if they decide to customize widget behavior too (guaranteed to be worse than default—may look cool but there will be jank, broken state, and more) or do any special snowflake navigation crap when some normal and platform appropriate pattern would do.

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.


> 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.


I know we’ve been busy declaring victory over all those old-timer print designers who’d transitioned to web & software, and hailing the rise of the “digital native” designer for like the whole past decade or so, but to me it looks like they’re all trying to make posters rather than software.


On the other hand, ignore the last fashions in UI design at your peril. Users will consider your website or app "dated" and adoption will suffer.


Basically irrelevant on platforms other than the web—no iOS user will think you app is dated because it looks like the apps Apple makes, ditto Windows, Android, and so on—and even there I’ve seen this repeated as folk-wisdom but have never seen anyone back it up with data, nor go a step farther and find out exactly how trendy and how expensive a GUI needs to be for a given audience not to bounce (it seems, surely, this would not be constant)

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.


> 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'.

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.


Sorry, I didn't mean it as a general swipe at all designers, and I am sure you are great at what you do. Specifically I am talking about the advice such as "Tell me what this does before I click on it" in the article.

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.


> 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....


> Won't happen until/unless dedicated design folks have to provide support for their creations.

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 seems somewhat of an anomaly, but maybe it's not - it just hasn't been the norm on most projects I've been on - both as a freelancer and working at small companies, large companies and agencies.

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.


A bit of an anomaly from an organizational perspective, but as UX designer it didn't like anything usual. Every designer I knew in my professional circle, though, wouldn't even bat an eye at it, it was taken for granted that you'd be very attentive to user feedback, after all that's your job! Advocate for the user. What are you wasting your time with if not that?

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.


I'll share the sentiment with @nkrisc.

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.


> 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.

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.


No swipe interpreted, it pains me because it's absolutely true! But there's a lot of people out there that fancy themselves UX designers (hey, that's what everyone's hiring). No true Scotsman, erm, UX designer would do something for the reason that it's "cool and clean," that could be a side effect of a good design. There are some very talented designers out there who make some very beautiful designs... that would look great on Dribbbbbbbble but confuse their core audience/customer base.

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.


I have to ask who pays for these systems? Is it the end user, or some business person in an organization?

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.


Unfortunately, as a business grows it will often transition from selling to the former to the latter, because "some business person" has a bigger wallet available to them then the actual end users.


Depends entirely on the industry you work in.


> When I started out my programming career many years ago, these things were fundamental in the way I created software, however things seem to have gone downhill in recent years.

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.


Sure, but those pressure vary quite wildly across industries and companies. I've had some roles where I felt I could actually treat this as a craft and feel proud of my results. There have been plenty of others where the drive to ship absolutely as soon as possible is the primary motivator. Usually in those instances it's where I've been brought into projects already running behind towards a due date and compromises had to be made. Those happen to be sequential for me, but I don't think it's a case of things actually being better in the good ol' days so much as that's when I had fewer other responsibilities and could spend much more of my time focused on the actual code rather than the dozens of other directions my attention is being demanded. I put out fires more than I create things at this point.


There's no golden age in time, but for most people there is a golden age in their lifetime.


A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinning and things. Other bits sound nice but are back-end hell or licensing hell to implement.

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've found that Undo isn't something you can bolt on after the fact, you need to design with it in mind from the start. I've had very good outcomes with that approach.


Undo can be bolted on after the fact, but only if you had the presence of mind to either do event sourcing or if your application state isn't too big to store all your state centrally.


Why would Undo be any harder to add post-hoc than any other feature? Encapsulate each action, codify its opposite, and push it onto the undo stack.


"Encapsulate each action and codify its opposite" is exactly the hard part of this. Too much code is written assuming it has access to the entire state of whatever it's modifying and doesn't have to worry too much about side effects.


Most new features don't require changes to the logic of every existing feature.


Absolutely. See the meme of how IDA Pro doesn’t (didn’t) have undo for evidence of this.


> A lot of those are nice additions, maybe in the third or fourth generation of the application when you got the data structure nailed down you can look at skinning and things

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.


I'm quite sad that accessibility is not mentioned at all, because I'd say it is THE CLASSIC feature that many users pine for but developers frequently overlook.

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.


What percentage of customers actually request accessibility features such as screen reader support? I agree that every application should strive to be accessible for screen readers and the lowest common denominator but if the project manager had to prioritize features to develop, they'd choose features that majority of customers are requesting such as the things mentioned on the list.


100% of all gov customers.

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.


> they'd choose features that majority of customers are requesting

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...


> I'm quite sad that accessibility is not mentioned at all...

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".


Fair enough; I am glad that those are mentioned, at least.

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.


Do you have any examples of accessibility features improving the experience for the average user? Websites with poor text contrast (or ultra-thin fonts) come to mind.


I refer often to this poster from the Microsoft Inclusive Design Toolkit:

https://camo.githubusercontent.com/b25f31e420c078114a2abee62...

More here: https://github.com/alphagov/accessibility-community-notes-an...


* If it's easier to see with poor vision, it's also easier to see with normal vision / projected on a projector / over someone's shoulder on their screen / on a phone or tablet.

* 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.


Also known as "Things end users care but not enough to pay anyone to work on it, rather than on your application's core domain. Which they are not exactly willing to pay for either, but that's a different story."


> Use accounts/permissions from Active Directory

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.


Enterprise tooling probably needs to make event sourcing out of the box easy to do, with metrics being either a real time stream they can tap into, or an ETL process fed by that stream.

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...


Not just Enterprise customers in the "the Enterprise is the customer" sense - if you work as a software dev in an enterprise then your users want to be able to use their normal password, and not create a new one for your app.


Basically, SOC II certification. Having that significantly increases the opportunity to sell into enterprises, because they don’t need to do a lot of security audit work before buying.


    Number/date formatting to the right locale
Uh,... maybe. This may work well for most people, but at least allow me the option of setting up my own format. I happen to live in a locale where the "official" locale-specific formats for numbers and money are almost never used by real people (because they're ugly and fuggly.) So it gets pretty annoying when LibreOffice only recognises it's own list of locales and will only apply the "official" formats. As a result, you can count on the fingers of one head the number of people here who will use "Format > Money". They'll rather use some number format that looks the way locals all expect things to look.


Seconded. If anything, I'd personally prefer the date to be ISO 8601, because that format is unambiguous and universally readable everywhere people use the Gregorian calendar.

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.


> ugly and fuggly

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."


Just out of curiosity: do you mind sharing which locale/area this is?


ZA


Umm, I want a pony too?

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.


This list could be titled "Nice things users like but could live without"

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.


I want to say, as a programmer I used to overestimate how much it costs and underestimate how much it mattered to the end client.

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...


Most of these things are not ridiculous asks and a lot of them do seem like they are truly underserved but programmers compared to the mildly tech literate end users.

Of course parsing CSV will never go well


> Most of these things are not ridiculous asks

- 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.


You're cherry picking. At the risk of cherry-picking myself, there were 10 formatting wants. 9 of those are reasonable and you chose the 1 that was difficult. Not only that, but "behaves like word" is probably meant to be a class of things users want rather than a single thing. It's basically saying that users want things to behave the way they're used to behaving, which is a very valid design consideration.

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.


>At the risk of cherry-picking myself, there were 10 formatting wants. 9 of those are reasonable and you chose the 1 that was difficult.

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.


I kept the list short because I didn't want to have a long comment, but if you want my full list, I'll attach the things I don't think are trivial.

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)


How do you "undo" a one way operation on 5-10 Gigabytes of data that takes several hours to run?)

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.


> 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.


The lack of universal undo, a.k.a. non-destructive editing, has been a showstopper for a lot of would-be GIMP and Audacity users for a decade or more. Literally none of the other features matter because using the software is not an option. But obviously it wouldn't top the list of requested features if you polled the current users for whom it's not a showstopper.


This should still be handled by talking to potential users (why don't you use GIMP) and evaluating the cost-benefits of supporting those 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.


> - 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?)

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.


In some cases, universal undo really isn't possible. As an example, what if the app activates a shock collar for dog training purposes? A delay isn't acceptable, and undoing is impossible. This is a real product, there's more than one on the market.


That is not what undo is for. Undo is for data changes without physical side effects. You might just as well have asked to undo printing a page when the printed page is in the printer's output tray. People have enough common sense to understand that this is irreversible. This is less obvious for an action that only changes data that is displayed on a screen.


A good rule of thumb: whenever you could tell a human valet 'sorry, I changed my mind', you should be able to tell the computer.

Eg you should be able to undo changes to your restaurant order, as long as they haven't started preparing the meal.


Yes. Obviously the fake doesn't work when latency is critical.

Some of trying to 'unsaying' something in Skype. Fake 'unsending' an email only works because we tolerate latency.


> what if the app activates a shock collar for dog training purposes?

That is the wrong shock collar; undo the purchase.


They aren't crazy, but they do end up creating more complexity than you would think. My pet theory is the stuff you see skipped over in many programs that seem simple actually generate a lot of complexity when programming, so engineers tend to avoid adding them as a path of least resistance thing.

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"


The colors feature set specifically strikes me as extremely difficult to implement. Using "your" color palette would require a standard for color palette usage names which would have to be meaningful across multiple different design ideologies (HIG, Material, etc.). And then on top of that it would have to prevent contrast issues? That is significantly more difficult to do in any sane way than that feature list suggests.


It's amazing what lengths people go to in order to get custom colors and fonts: they'll decompile apks and upload new ones with a custom colors.xml; they'll root their phone and change the colors in the OS; or they'll install a binary of unknown providence where someone else did this.

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.


A long time ago, I worked on a consulting engagement where the customer representative struggled to get direction from their higher-ups and made us implement a automatic color palette based on a company logo the uploaded. We easily extracted the main colors via imagemagick and then created a color palette from those by driving me colors with different hues etc. It was frustrating to not move forward on the actual business processes that the app was supposed to fulfill, but so much fun.


This sounds like a library instead of something everyone ought to implement.


Getting such a library right is hard. Semantics and usage of colors in a palette are hard to generalize and there's almost always the odd extra colors that are needed to highlight something domain specific in a custom control. Also, some themes rely on gradients and mutiple subtle variations of hues and saturation to highlight boundaries, imply an ordering or prioritization, etc...

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.


I agree, A lot of the features in the list are things that should be implemented in the UI library / OS layer not in the specific application layer.


I'm not arguing they are "ridiculous" asks. But many of them are certainly expensive asks. I mean, just take one simple one for starters, "Works with the database and version we use". Depending on the size and complexity of the software that can easily be a multi-million dollar project.


Absolute cost is much less important than cost-benefit. If a feature will cost millions and result in no increase in sales or profit then you say no to it. If the feature costs millions and will result in hundreds of millions in extra sales then it should be a very high priority.

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.


I agree with you, and that is pretty much my whole point: all features have a cost, so you need to look at what the real benefits of these are, instead of throwing out a giant list of wants and saying "end users care about these things but programmers don't."

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.


Funny you mention CSV because my mind immediately thought of that as relatively easy, compared to dealing with Excel. Fortunately a good chunk of users don't even understand the difference between the two.

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.


In my experience it is better to support parsing some CSV formats compared to none at all. The UI should make transparent what format is expected.

The main culprit is Excel which does its quirks (localized for one!) to the exported CSV because it knows better.


How much of that is the cost vs. the idea that they are funding product enhancements that the vendor will profit from with other customers.

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.


Paid features come with shares? You bet more companies would go with it. I can’t see the developers being thrilled with the idea though.


Surprising how much of it is about color. As a user, I don't really care what color anything is, even if it's nasty like Discord. I want a dark theme, but it's mostly because it lets me save battery and doesn't glow in my bed at night.


Dark themes only save battery power on devices with displays that have per pixel lighting (eg oled like a modern iPhone). If the background lighting is fixed like an led or lcd display then the thing that impacts your battery is the brightness level, and most users can view a light theme at lower brightness than a dark theme.

If you're using dark mode to save battery on a laptop it's not working.


In fact on lcds black consumes a tiny bit more power because polarizing the lc foil takes a little bit of power. But I doubt you can measure the difference through the noise of normal computer operation.


On a phone, it has added roughly 4 hours of battery life at night. I'm not a big fan of dark theme, but only started using it for the battery conservation.


>If the background lighting is fixed like an led or lcd display

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.


My business class just-retired-to-k3s-duty laptop was manufactured in 2014 and has a LCD. That was only 5 years ago. Fixed backlight, no light ambience sensor.

Cheap laptops today like the HP Pavilions of the world still use fixed-backlight LCDs as well.


I think some people are more sensitive to these things than others. If you aren't then it's probably worth getting someone who is involved in the project.


depends on the segment the application is in, in data visualization/dashboards it matters a lot more.


Honestly this article misses my main request as a user:

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.


I don't feel this list is very reasonable. At least, it's far too dogmatic.

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.


> 1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence.

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.


That seems like a pretty generous interpretation of

>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?


Corollary for #3 on desktop: Don't steal focus!

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 :(


You know, this was one of the things that made me feel that I made the right choice in moving to Linux, years ago: I realized that focus was under my control. My current WM even has an option to disable focus stealing, but it's not necessary because the software defaults to respecting you. That, and I realized that all windows could be resized, regardless of whether it even made sense (Ever seen an okay/cancel dialog maximized? It's hilarious.). The system put the user in control. So I stayed:)


It's actually quite difficult to popup a Window in the foreground. Usually the taskbar icon indicates it wants focus but focus stays where it was.

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.


OS X/macOS isn't much better. If I wrote my own GUI window manager I wonder if I'd even put in modal dialogs and the like. The ones that don't respond to keyboard presses and remain on top are the worst.


> 1. Software should be free of bugs. At the very least, updates should not introduce new bugs.

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.


Breakage due to OS upgrades is one thing. But at least make sure that the software doesn't do anything obviously bad. For example, I was dealing with a "security product" (basically something that profiles activity on the OS looking for malware activity) that we were required to roll out, and come to find out it reliably corrupts the RPM package database on both CentOS 7 and Amazon AWS Linux 2, whenever the OS is rebooted (assuming the software is set to start on boot). Things like this are unacceptable.


Enterprise software is a different beast, since the users are not the purchasers and not consenting to use, and so their concerns don't matter.


I mean, any API call to an external server can be considered "phoning home". What is your specific definition? I think submitting bug reports only through official channels is pretty lame. Most of the 'official channels' don't really provide much meaningful info to developers, there's limited support for custom debug/logging/etc. So your point 1 and point 2 are basically at odds.


>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.

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.


None of these are going to happen. We all want but free software, but that is impossible . not is a goal we all strive for though. While you may not want ET to phone home, most other people do. For a variety of reasons. Upgrade checks, analytics, etc. As much as I hate ads, links will never cut it.


>At the very least, updates should not introduce new bugs

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.


> release annually

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."


> Software should be free of bugs. Software shouldn't phone home

Pick one. If you can't collect data, it is expensive to identify and fix bugs.


I specifically said no phoning home _without asking_. It is fine to have an automated process to submit bug reports if you feel your software is so buggy that it needs it. Any competent OS will also have an automated method for submitting crash reports back to the maintainers (ex, apport)

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!


Disagree very, _very_ strongly on number 4.

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.


I understand the feeling, and used to share it more before I became a bitter old man with corporate responsibilities and a hatred of all spontaneity and joy.

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.)


I dread updates.

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.


Sounds like you would be a prime candidate for a 'nightly' or 'developer preview' style release. Let the eager technically competent types give you feedback on the new features as you write them, provide feedback/bug reports etc, and when the new release is actually done push it out en masse.


Users don't care about most of this. Custom colors? Tell that to Apple's customers who seems to have no problem using a non-customizable OS. Running on obscure hardware configurations? Users don't have those, programmers do. Company branding? That's not a user request. Touch gestures? Who made this up? Not users.


Agree 100% it depends on the software but you cannot choose the color of your professional tools in general. Your Bulldozer and medical scanner don't come in purple, sorry.


You can always customize it. Professionals paint their tools all the time, since you don't want someone taking your drill home from the job site. Every Genie lift rental has the rental company logo bigger and brighter than the Genie logo.

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...


I stand corrected,thanks. However the scanners are targeted towards patients, and brand customization is understandable for clients. You however see my point : for adults, having a precise or dependable MRI is more important than having it in purple or branded for xyz hospital.


Yet Apple was built on paying attention to details that the rest of the industry ignored.


> Running on obscure hardware configurations? Users don't have those, programmers do.

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.


- Some words or identifiers should always have a specific color

- 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.


You mean "Things end users care about but can't afford"?


It's not that programmers don't care about this. It's simply that with today's tools this is $1E7 to 1E8 to implement all of these decently for any application.


Early Windows (probably up to and including XP) did a lot of these things right. But now Microsoft is starting to go against their own recommendations.


These are mostly things that programmers who are also end users care about. I haven't run into a single non-technical user who cares about customizable colors, dark mode, exporting to CSV/JSON/whatever else, customizable shortcuts etc.

The average user won't even know what most of this list means.


Enterprise users love excel import/export. Potentially CSV as well.


So do enterprise developers. If I can use the "well they can do that in excel" defense to avoid implementing a feature, I will.


Maybe as far as "I want to see this table in Excel". And that too for very specialized roles and use cases.


It might be more specific to the program the blog belongs to, which looks like a live dashboard for data. If you have a dashboard on some giant monitors all over your HQ, customizable colors & branding will matter a lot.


Users do care about things like that if you ask them in non-technical language. "Would JSON export be important to you?" is the same question as "Do you want to be able to download and backup your data?" but each question will get quite different responses in most cases.

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.


No, I don't think end users care the smallest jot about what format their data gets exported in for backup, just so long as they can re-import it (otherwise it's not really a backup, is it?) The only time I can think of that they might care or have an awareness that formats matter is if said data is being transported between different applications where there is some pre-existing standard (e.g. BeerXML in the world of brewing caculators.)

Aside from that you've conflated two unrelated requirements.


I am building a data visualisation software. Colors is all they are asking for and the hardest to implement in a "satisfy all constraints" way.


Similar as we devs like to use grep on text files there are uses that want to manipulate data in Excel, so they want your app to output into CSV or import from CSV if it can apply for your app.


Power users certainly use CSV files when uploading to other systems. Banks allow export of transactions as CSV files. Web shop import CSV files for prices.


Color is huge! There are so many half-baked trends in color that look great for people on large screens with wide color gamut and young eyes, that in less than ideal conditions are completely illegible.

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.


Do users really care about being able to customize the design (themes or more fine grained)?

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.


I'd agree with only some of the suggestions.

> [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.


> That's what tooltips are for. Harder on mobile, but there's no excuse for web developers who don't include them.

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.


> 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.

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!"


> That's what tooltips are for.

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.


Oh yes, the ellipsis. As the self-proclaimed member of the Order of the Ellipsis, I use every opportunity available during UI design sessions to ensure this knowledge isn't forgotten.

(BTW, I know for sure that pattern is a thing on Windows. Does MacOS follow similar guidelines here?)


2019:

"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


All of these things can be had in the software you want - just need to ask for it up front and pay a sufficient amount of money and accept a longer timeline. Some of these things are surprisingly expensive, even when they seem simple. It is entirely plausible that, after discussing prices, the response from client is 'actually... can you just make me a CLI thingy that spits out a csv?'


Have you seen the settings of the current version of YouTube? First of all, it took me a good ten minutes to find them, because now I have to scroll down on the Account screen to reach it, and there is no indication that this screen is scrollable.[1] No scrollbar visible until you start scrolling. Nothing peering up from the bottom end. No drop-shadow at the bottom. It just looks like the the last option on the page is Turn on Incognito.

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?

[1]: https://andai.tv/img/youtube.png

[2]: https://andai.tv/img/youtube2.png


I still see retail sites crippled by poor search choices, such as requiring the customer to understand how the retailer categorizes its inventory before it will search for anything, or by showing the union of the matches to each term, so that adding terms, in an attempt to narrow the search, broadens it instead.


This reads like a list of decent but non critical enhancements to many programs. The funny thing is, myself and most programmers I know love working on things like this but most of the time it is not the programmer who is calling the shots on what his time should be spent on.

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 reads like a list of decent enhancement that separates a good program from a great one. Some of them are really hard, but many are just the spit and polish that makes a good program a great one.


Users will pay a premium for high quality software. Just ask Panic, 1Password, BBEdit, and—until very recently—macOS and iOS.


Only Mac and iOS (and sometimes Linux) guys pay premium for software. Windows and Android users only pay for games, sadly.


> Can be mounted on a path that is not the root of the domain.

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.


UX is tough. So tough it has it's own speciality field. Programmers are not UX'ers. That's fine. We can't be accountable for everything. We would however benefit from a better sense of empathy for users, as well as a more holistic view of "the product."

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."


Isn't that what pay is for? If you care about something but your programmer doesn't, then you pay them to start caring about it?


In theory, but it turns out that most software products are most significantly just systems of social control. The economics of it don't work out; I can't pay the military industrial complex to value my life. I don't have that kind of money.


This is a great list and I want to add that the “simple” ones are a lot harder when third party integrations are involved. Or even dependencies on other teams in a sufficiently large org. It takes a certain mentality and commitment to look beyond “programming” problems to address these scope/not-my-job issues.


This is the true one:

* WYSIWYG editor that behaves like Word


> Case-sensitive/insensitive filtering.

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...


How often do you search the Linux filesystem case sensitively? I couldn't tell you how to use `find` to search case sensitively (use -iname to match a name case insensitively) and tab completion works case insensitively on my computer (maybe it's some configuration I picked up two decades ago? dunno).

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)


The filesystem is not a search facility. If you want a fuzzy search utility, get a fuzzy search utility. The filesystem itself should distinguish between letter cases, in case the user wants to.


It depends a lot on a type of app, business users usually don't care much about color palettes and having a dark themes available, and worry much more about how streamlined is the workflow for their particular needs.

> but our tools make it really hard to provide

That's why we build web apps nowadays...


Didn't OS/2 bake a bunch of those things into the operating system where they belong? Why don't we use it? Multiple "Product of the year" awards (I've seen 4 in a row but cannot confirm). I'm still a fan.


Another title is "Things users will struggle through, because your product fixes a critical, fundamental issue for them"

No snark intended. Often a product that solves a real huge pain point has it's own sharp-ish edges too.


Spelling my surname properly. Computers can't do it. They just say "oh, let's capitalise the first letter and make the rest small". Makes me sad.


Speak for yourself. This reads like an enumeration of the traits of a stereotypical arrogant 'programmer' from the 90s.

(Got my start in the 90s but didn't stay there)


From 1st hand experience let me add

IT:

Your app can magically talk to servers on the internet from behind my Firewall without my IT being capable to whitelist respective servers.


How are multiple export formats, configurable deployments/platforms, and consistent UX things programmers don't care about?


Yes, sometimes when you use new updated ... these things go missing in other places so it becomes painful to retrain to the next version.


This title is awful. Plenty of programmers care. It just takes a lot of work to get a project to this level of done.


There are probably comments on HN to back this up. When features like these are removed for no good reason from various sites or products, often there's a comment out there complaining about it at some point.


... and also things they don't want to pay for.


This list looks more like what programmers care about as end users.

Average users prefer WhatsApp and Instagram over good messengers. I honestly don't know why such bad software is still relevant.


if programmer.have_time() and programmer.very_well_paid(): implement_things_users_care_about()


End users don’t care that you want to refresh your design every year.

I know you need to keep your designers employed and doing work but please stop.


This a thousand times. So many app redesigns. Every time I open Spotify they moved the search option somewhere else. On Gmail for Android you have to guess which is the "mark as unread" button now. The train app for my country is still a bugged mess, but now they added one of those monochrome vector humans that everyone has in between loading screens to mask sluggishness. I'm starting to think UI design is the next bullshit job


This is exactly what we do at my current job, and it's infuriating to everyone but the management asking for it.

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!


And if you redesign, please, pretty please, keep your URL structure intact. Having links being invalided every two years is jut a pain.


I'm sick of the meme that programmers aren't end users too. I use software as much as any non-programmer does.


But you probably use very different software, in different ways. Do you think your non-technical relatives want to spend a single second in a CLI?


Yet here we all are, using a browser, the most bog-standard piece of kit on a given computer.


> Good contrast

> Automatic contrast of text if I pick a dark/light background

These are not preferences, these are minimum requirements. Programmers should care about this.


Here’s something users don’t care about. Your next version. You’re a fucking text editor. You do not get to update, ever. Not “remind me later,” not “skip this version,” never. How fucking dare you throw an update prompt or a release notes screen when I’m trying to use a tool to do a job. It’s unconscionable arrogance to think a change to an already-complete piece of software is worth an interruption like that.

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.


None garbage environments handle updating software in a unified fashion that is entirely separate from usage.

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.


Yep, which makes it even more annoying when package manager-sourced apps still bug you about updating. For example Chromium on my arch install today popped up a dialog saying ‘there is an update but this Chromium install can’t update itself’. Yes thank you Google, that is intentional!


Another good reason to use Firefox. I never have this problem.


“Hey we came up with some new ways to try and solve the kinds of problems this tool is designed to solve” isn’t worth a note? “Hey the version you’re using now won’t work with the new version of the OS you’re using but we fixed that”? “Hey, we fixed a pile of long-standing bugs”? You don’t wanna know about any of those?


It's not great when a modal update notification pops up some X milliseconds after opening a productivity tool, after the required network request has completed. By that time you might be half way through typing something, or just about to click something in the interface.


This is the main issue. It's not that the information is unwelcome, it's that the delivery of said information interrupts workflow. Notepad++ has been particularly annoying me lately with this one. They removed the option to disable auto update a while back, need to see if it has returned.

There should be a site that catalogs anti-patterns and nuisances in applications so we can publicly see the outcry over stupid stuff.


Adjacently, release software through the OSs you target. Stores, pkg managers, whatever.


If you're using an open source editor, compile it without the update check.

If you're not, pay for your software, then disable the setting.

In neither scenario is there an excuse for entitled laziness.


As a dev I care about many of those things and feel like a voice in the wilderness.

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.


Floating point has a specific purpose in computing, where you deal with measurement, and don't know the scale. Adding one nanometer to a light year (to get back exactly a ligh t year) is actually a useful feature in numerical physical computation.

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.


> insane choice of making floats its only and default number type

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.


> 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.)


The alternative is static types.


> Right now Javascript specifically is to blame

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.


Javascript is by no means uniquely bad. Far too many languages make float/double much easier to find and use than decimal types. If your decimal type is buried in the standard library that's not really any better than being in a third-party library. Java won't even let you use arithmetic operators on decimal types!


> Outside of scientific computation, machine learning, statisticd, etc there is seldom legitimate use for floating point.

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 think anything that wants to approximate physical reality finds the float useful. The real problems is when people use floats for human accounting and casual measurements like 0.1cm


This happens because 'rational' or fixed point floating point number types are not a first class number type along with float and integer in all popular programming languages.

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.


Rationals are computationally nasty. Even if you have hardware acceleration, they are going to be slow. Here's why:

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.


> Rationals are computationally nasty. Even if you have hardware acceleration, they are going to be slow

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.


What is nasty; brittle ad hoc code that tries to bend binary floats and or integer types to do the work rationals.


I entirely agree with you: the default numeric type in computing should be the numeric tower, with floats chosen on an opt-in basis where their properties are useful.

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).


I mean the type system should just reject using integers in conditionals all together.


I like dynamic type systems well enough, they have their place. Clearly what you say should be true of a static type system.


A broken string library is not a bug in floating point.

You can't cut a check for 0.3 pennies.


> It should work on my old android phone browser/IE 11

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: