5 ms·

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

by c3534l 7y ago

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.

jmiserez 7y ago
>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.
danShumway 7y ago
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)

by c3534l 7y ago

jmiserez 7y ago

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

danShumway 7y ago

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)