Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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

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

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.

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.

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

That is the wrong shock collar; undo the purchase.

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.

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.

Reply on news.ycombinator.com