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
Of course parsing CSV will never go well
- universal undo (depending on what kind of operations you're running and how large your databases are, this can be a really weird problem. How do you "undo" a one way operation on 5-10 Gigabytes of data that takes several hours to run?)
- optional cascade deletion (Does your app allow references in formulas anywhere? Have fun trying to automatically rewrite those formulas in a user-predictable way)
- translated to my language (AKA, hire a translator that speaks that language)
- works with the database and version we use (more on this in a second)
- WYSIWYG editor that behaves like Word (Hahahaha, Slack)
- etc...
None of these are "ridiculous" in the sense of, "we could never do that." Many of them are significant asks.
To pick one example, I've worked in enterprise environments that allowed on-premise installs with customer-specific databases. It is a serious pain in the neck. Every time you want to do anything interesting with a data format, you have to figure out what which clients support it, what connectors they're supplying you, and how you can hack consistent file-locking and modification times onto someone's outdated WebDAV client.
And honestly -- we've gone to customers and said, "hey, we could get features out earlier if you switched to an industry-standard infrastructure", and a lot of customers are very happy to make that tradeoff. The big thing to remember is that customers are using your app to solve a problem. That's what matters. End users do care about this stuff, but only if it doesn't get in the way of allowing them to solve their problems.
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.
Some of trying to 'unsaying' something in Skype. Fake 'unsending' an email only works because we tolerate latency.
Eg you should be able to undo changes to your restaurant order, as long as they haven't started preparing the meal.
That is the wrong shock collar; undo the purchase.
The language used in the list is a bit flippant, so "Undo everywhere" could seem unreasonable if you interpret that as "users generally request undo features for most actions" and not literally any conceivable thing you can think of regardless of whether or not it makes sense needs to be undone. You immediately jumped to databases, which instead offer a wide range of security and and protection mechanisms to prevent accidental deletions instead. People pay good money for regular database backups because being able to recover from a mistake or failure is important to people, on account of people constantly making mistakes. Even GMail has undo for sending emails now (it just waits half a minute before it actually send the email).
Obviously some of these are silly. "Use this color from here" is a joke (nothing you do will please everyone). "Deploy on exotic configurations/platforms" is almost a joke, but there is always someone who asks when you'll get around to porting your autocad program to the iWatch.
The problem is that this is absolutely not clear to many end users and devs. I have actually dealt with 8 of the 10 formatting wants in the past year, and none are as simple as they sound.
E.g. "using the fonts I use in Office" can be expensive to impossible if you want to properly license the fonts for server use. "No .00 for integers" sounds trivial, but what about ".0000004" when you also implement "No weird .0000004 formatting anywhere". Solveable, but you may need to change the types and not use floating point in some other parts of your application or round the numbers (when?). "The right locale" to use for formatting might change over time in subtle ways due to updates and political/regional changes. Emojis look different in each browser, so you use images: now they look "wrong" in iOS and you probably can't use the Apple Color Emoji font icons due to licensing, etc.
>Not only that, but "behaves like word" is probably meant to be a class of things users want rather than a single thing.
No! Some users might literally find "this behavior is not 1:1 the same as in Word" and if you word ;-) it that way at least someone will understand it as such.
Failing to deliver 100% on such "easy" functionality is often not an option, so just hope that you planned enough time/budget for all the little issues or explain it very well.
To show you I'm at least somewhat speaking from at least some limited experience, I'll also mark features with a check (/) where I or people next to me at a workplace have maintained or implemented these features and found that they weren't trivial to do. For a few, I've also included one sentence descriptions of why they're not a 1-day project.
My point with this is not to imply that any of this is impossible, just that it isn't free. The question you always need to ask when looking at features on this list is, "how many of these are more important than the core functionality that the client actually cares about?"
And it's not that developers don't care this stuff. I would happily rework our entire app at my current company to have one unified UX everywhere and to add emoji support and play with margins and padding and add a custom dark mode. It would be an enormously fun project. None of our customers would care about it.
-----
- Change color of things
- Import/export color themes
- Automatic contrast of text if I pick a dark/light background
- Automatically generate color for large number of items
- Use the fonts I use in Office (/) (Most of these fonts are proprietary, and you can't trust the system to expose them. This problem gets a lot more "fun" when you're dealing with multiple languages)
- WYSIWYG editor that behaves like Word (Again, Slack -- it wasn't just that their editor was unwanted, it was buggy and it didn't work, because WYSIWYG editors are hard)
- Emoji support
- Dark theme (how long did Apple take to add this again?)
- My Theme
- Company Branding
- Integrate with system accounts (/)
- Use accounts/permissions from Active Directory (/) (this one isn't too bad, it just takes time, and setting up a testing environment is a huge pain in the neck. It also needs to be optional, because not all of your clients use Active Directory)
- Import from Excel/CSV (/) (Handling misshapen input is hard, clients are extremely creative with how they will break your importer)
- Import from email/email attachment
- Export to PDF/Image (/) (Text complicates things, there is no single right resolution to use)
- Record a short video (/) (Clients want time limits, not space limits, but time limits are unreliable because different mobile devices all record in different resolutions. Clients start using custom recording software that outputs in formats you didn't expect. You discover that browsers are actually very picky about the video formats they'll play, and the only way around that is to transcode videos on the server. This turns out to be wildly expensive.)
- Send as email (/) (BCC rules and sending limits are different for different infrastructures)
- Send as PDF attachment on an email (/) (compression becomes extremely important because of the above)
- Import/attach images (/)
- Use image as background but stretch the right way (based on what?)
- Customizable keyboard shortcuts (/) (not all input devices give the same input codes for the same keys)
- Undo everywhere
- Multiple undo (I'd like to see how the "delay" trick works with this)
- Copy and paste (/) (arbitrary data types in tables make this hard, your table cells have to handle conversions from every data type, including dumb conversions like "I pasted an emoji into a date field". It becomes impossible to deprecate old data types because they need to be updated to handle conversions from new data types)
- Templates (/) (this is just a big thing to build, there's nothing particularly complicated about it. It's like saying, "image editing". Yeah, that's a feature.)
- Video guides that stay up to date
- Screenshots that adapt to my custom setup (how would this work?)
- Translated to my language (/) (you need translators, also hope you're not dynamically concatenating any strings inside of your application, because different languages have different grammar. The proper way to do this is to never write a string and to always call into a parameterized function to get your strings. And in general, writing messages that are easy to translate requires some degree of training.)
- Sorting everywhere (/) (lazy-loaded lists hate this)
- Filtering everywhere (/) (lazy-loaded lists hate this)
- Cascade deletion (/) (see the formulas problem I mentioned before)
- Preview things (/) (see the expensive data operations I mentioned before)
- Progress bars for slow/async operations (/) (Very rarely do you know how long an expensive operation will take. You usually end up guessing)
- Deploy on exotic configurations/platforms (they're called exotic for a reason)
- Deploy on old/unsupported versions (what does this even mean?)
- Deploy on what we have (/) (I already talked about this above)
- Deploy/Run without internet connection (/) (This makes deploy processes about 10 times longer, and makes patching very difficult, because you can't install for the client. You have to trust them to get everything right, and they won't)
- Handle Excel, CSV, JSON, XML (/) (mentioned above)
- Handle malformed versions of all of the above (/) (mentioned above)
- Integrate with obscure/outdated software/format (/) (mentioned above)
- It should work on my old android phone browser/IE 11 (/) (Babel is not a one-click solution to this problem. We support IE 11 of course, but it does eat up a lot of testing time.)
- Works with the database and version we use (/) (mentioned above)
That's an edge case that you'd need to make sure the UX team have thought about and designed a dialogue in to the undo feature to warn users before they do a one-way operation. That's a common feature in most enterprise apps.
Saying no to a feature because there's an edge case that makes it hard is exactly what the article is talking about - that's a strong signal that the developers don't care about what the users need.
No, I can guarantee that if I went and asked any of the clients at my current company whether they wanted universal undo or the next core feature that we're working on, none of them would choose universal undo.
That's the point that the original commenter was getting at:
> I've contracted for a small dev contracting shop, and it's amazing how, when customers come with a long wishlist of things they want a piece of software to do, these customers quickly "stop caring" about most of these features when they see actual dollar amounts next to each line item.
Of course users want this stuff when they think it's free, but it's not free. Once they realize that it's not free, they very quickly come up with very different priority lists. Being honest about which features are hard, and which features will result in delays, is an unpleasant but important part of caring about users.
Case in point, universal undo matters for creative applications like Blender, Gimp, Photosop, Audacity, etc... For how many people are the lack of features like custom branding or dark modes showstoppers in Gimp? And even if it would be nice to have those, are there enough users for whom its a showstopper to justify ignoring existing users who want something focused on their needs?
I'm not arguing that there's never a context where you'd work on stuff on this list, I'm arguing that the list isn't free, and because of that should be prioritized alongside other features and maintenance based on user research.
Like that colors feature set would need a fairly sophisticated color theme system, you would have to force designers to work with a set of theme color names vs raw color values along with a design system and you would need a fairly sophisticated color linter to automatically catch things like "Don't place similar colors close to each other"
There are things you can do to make it easier. You can provide settings for specific elements (for example, HN has "topcolor" in user settings). If you're doing a web app, keep the markup simple so that one can use per-domain user stylesheets (try inspecting the markup of a HN page). If you're doing a Windows app, use native controls so they can be themed by the OS. But these decisions constrain what product and graphics designers can do, so you need buy-in from the other parts of your team.
If you want to see a customization nightmare, look at the theming options in blender: the devs diligently expose every color used by the UI there. The list is massive.
If someone gets all of this right in a generic library, I'll tip my hat to them.
You can never just look at a feature and state that it's objectively too expensive without looking at the impact of the feature as well.
Only point I disagree with is when you say "If the feature costs millions and will result in hundreds of millions in extra sales..." It's never that assured that a feature will bring any extra revenue. I actually spent a ton of time in the 00s porting an enterprise software app to the preferred DB of a huge potential client. It was a months long project, and the client ended up not buying the product in any case, and their DB choice was rare enough that it wasn't a big win in the broader market.
A lot of these items, like photo cropping/resizing, aren't hard per se. They're just harder than they should be, particularly to nail every detail. And it's often tangential to the core business.
The main culprit is Excel which does its quirks (localized for one!) to the exported CSV because it knows better.