6 ms·

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

by et2o 7y ago

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

novok 7y ago
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"
- lkschubert8 7y ago
  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.
  - cbhl 7y ago
    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.
  - ajmurmann 7y ago
    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.
  - michaelmrose 7y ago
    This sounds like a library instead of something everyone ought to implement.
    - gmueckl 7y ago
      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.
    - novok 7y ago
      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.
drewrv 7y ago
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.
hn_throwaway_99 7y ago
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.
- onion2k 7y ago
  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.
  - hn_throwaway_99 7y ago
    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.
danShumway 7y ago
> 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.
- eru 7y ago
  > - 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.
  - blotter_paper 7y ago
    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.
chopin 7y ago
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.

by et2o 7y ago

novok 7y ago

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"

lkschubert8 7y ago
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.
- cbhl 7y ago
  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.
- ajmurmann 7y ago
  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.
- michaelmrose 7y ago
  This sounds like a library instead of something everyone ought to implement.
  - gmueckl 7y ago
    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.
  - novok 7y ago
    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.

drewrv 7y ago

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.

hn_throwaway_99 7y ago

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.

onion2k 7y ago
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.
- hn_throwaway_99 7y ago
  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.

danShumway 7y ago

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

eru 7y ago
> - 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.
- blotter_paper 7y ago
  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.

chopin 7y ago

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.