I support the OP. If the article provides value then who cares if it is an ad? You think companies write great content and open source libraries and all that stuff for fun? It's all an ad to use their services.
> The problem with offering configured components is that they are rigid and inflexible. They hinder the consumer from... e.g., subbing your own <Button /> component for the one provided, removing elements from the component, using your styles/theme/tokens, etc....
> We want our experiences to be tightly integrated or native to our product rather than some foreign appendage (think Pendo, Appcues, Intercom), and achieving that comes with a need for control of presentation and behavior.
Having been on both the embedded-solution-provider and integrator-user sides of this:
The trite answer is - however much you think configured components are holding you back, it's better than iframes!
The longer answer is - the more degrees of freedom you as an embedded-solution-provider give to the integrator-user, the more you are trapped into your existing UI designs, and are forced to break your users' code if you ever need to introduce design drift. On the scale of things that give the provider's UI/UX designers and frontend devs aneurysms, it goes from:
- we need a design that can take any primary color of any level of saturation
- we need a design that can also take any font size and font face and not fall apart
- we need a design where our nesting assumptions can and will be radically changed by every downstream partner
- all of the above, and it needs to be fully backwards-compatible to any old code that might have customized these things
OP's article is advocating that embedded-solution-providers should invest in all four steps from day one. That's simply not realistic for SaaS business that need to deliver and improve continuously. Steps 1 and 2 are often sufficient, and that's firmly within the realm of configurability.
That said, there are exciting mitigations here. https://caniuse.com/mdn-css_types_length_container_query_len... / https://developer.mozilla.org/en-US/docs/Web/CSS/length#cont... has just landed across major browsers mere months ago, and finally makes it possible to ensure that no matter how someone constrains or re-nests your nested components, you can still apply CSS that ensures your designers' intentions. And you can develop frameworks that "phone home" with how your component is being used in the wild - though to do this thoughtfully with data protection is very possibly a startup in and of itself.
But one of my favorite programming memes https://www.youtube.com/watch?v=5qHHm7ooavo (warning: intentionally dangerous audio levels) applies more than ever. As an embedded-solution-provider, know what you're getting into, and make sure that not only your economics make sense but also your ability to maintain the morale of your team and clients alike.
galaxyofdoom|2 years ago
Secondly, OP is the co-founder of the company pretending an ad is an article. Kind of gross he didn't mention that.
ponyous|2 years ago
danjoredd|2 years ago
Ironic
jemmyw|2 years ago
rsrsrs86|2 years ago
btown|2 years ago
> We want our experiences to be tightly integrated or native to our product rather than some foreign appendage (think Pendo, Appcues, Intercom), and achieving that comes with a need for control of presentation and behavior.
Having been on both the embedded-solution-provider and integrator-user sides of this:
The trite answer is - however much you think configured components are holding you back, it's better than iframes!
The longer answer is - the more degrees of freedom you as an embedded-solution-provider give to the integrator-user, the more you are trapped into your existing UI designs, and are forced to break your users' code if you ever need to introduce design drift. On the scale of things that give the provider's UI/UX designers and frontend devs aneurysms, it goes from:
- we need a design that can take any primary color of any level of saturation - we need a design that can also take any font size and font face and not fall apart - we need a design where our nesting assumptions can and will be radically changed by every downstream partner - all of the above, and it needs to be fully backwards-compatible to any old code that might have customized these things
OP's article is advocating that embedded-solution-providers should invest in all four steps from day one. That's simply not realistic for SaaS business that need to deliver and improve continuously. Steps 1 and 2 are often sufficient, and that's firmly within the realm of configurability.
That said, there are exciting mitigations here. https://caniuse.com/mdn-css_types_length_container_query_len... / https://developer.mozilla.org/en-US/docs/Web/CSS/length#cont... has just landed across major browsers mere months ago, and finally makes it possible to ensure that no matter how someone constrains or re-nests your nested components, you can still apply CSS that ensures your designers' intentions. And you can develop frameworks that "phone home" with how your component is being used in the wild - though to do this thoughtfully with data protection is very possibly a startup in and of itself.
But one of my favorite programming memes https://www.youtube.com/watch?v=5qHHm7ooavo (warning: intentionally dangerous audio levels) applies more than ever. As an embedded-solution-provider, know what you're getting into, and make sure that not only your economics make sense but also your ability to maintain the morale of your team and clients alike.