“But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we. Adoption was bleak and feedback was dry—silence in startups is not golden.”
Making something nobody wants is a classic startup mistake. I resolved not to make it again and read a great deal about market validation and building products.
I have one recommendation for those reading this thread: Steve Blank's "Four Steps to the Epiphany". It contrasts Product Development (focusing on a product with no customers) vs Customer Development (focusing on customer problems and building software around those). Honestly you don't even need the whole book, there's a PDF with the first couple chapters floating around [1]. I had a bunch of "holy shit, that's exactly what I did wrong" moments while reading it.
Eric Ries' "Lean Startup" is also an excellent book on this topic.
[1] http://web.stanford.edu/group/e145/cgi-bin/winter/drupal/upl...
As for building a solution to "a problem that the intended users don’t understand that they have", I'll agree that this may not be a good thing for a startup to do - but when I see how basic research is being defunded and drowned in red tape, and people saying that startups are the new, distributed R&D departments, I feel the middle has fallen out. When startups do a greedy gradient descent, and academia struggles doing science, who's going to work on solving problems that require solutions one or two steps beyond what the intended audience can understand? FLOSS community? What about outside software?
First off, they hijack your scroll wheel and present you with some Apple-esque website that is very slow and doesn't work properly. > "Remote, component-driven, and obsessed with speed." I think not.
Second, they show zero screenshots of the service or what the benefits are to using it. > "Handoff reimagined." Yea, okay... Nice slogan, now show me before I move on!
No wonder they're having issues convincing new customers. They think they're selling a space ship when really they only need to improve their website copy.
The article resonated deeply with me, because I know just how the author feels. I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites. I can see the problem, and some of the solutions - but other developers are simply not interested. I've marketed the product to the best of my abilities, written blog posts about why I think this is an important issue. I've even tried to engage with people supposedly interested in overcoming the failing to help me make the product even better ... <crickets-chirping> ... nothing.
The harsh truth is you can't market a solution to a problem that nobody else believes is a problem in the first place.
I've posted links to my product on a number of occasions to HN, both as 'Show HN' threads and in comments. Engagement has been minimal. My most upvoted comment on HN was a contribution to a thread about octopuses. Maybe HN is trying to tell me that I would be better off developing a standup comedy routine? Whatever. Unlike the author and his company, I'll not be pivoting away from my product in the near future: I just need to find new ways to shove its existence into people's faces.
Link?
Like you, I've had to do a lot of coding and experimentation to get responsiveness working the way I think it should work. Much of it runs off the idea of drawing everything to a hidden canvas and then copying that canvas's contents over to the displayed canvas as the last step in the display cycle. I tried to mimic this functionality on the CSS object-fit property[2]. If you're interested in the code, you can find it here - https://scrawl-v8.rikweb.org.uk/docs/source/factory/cell.htm...
The other thing I've done is to introduce relative positioning for drawing stuff on the canvas. The native Canvas API drawing functions expects coordinates etc to be in absolute value pixels; my library allows coders to define positions and dimensions in String percentage values which will update (via dirty flags) each time a change in the canvas dimensions is detected.
Caveat: my library has not been tested (as far as I'm aware) across a wide variety of browsers and devices. I expect there will be plenty of improvements to be made once that happens.
[1] - https://github.com/chartjs/Chart.js
[2] - https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit
Since you've made Canvas your focus, I'm curious if you've seen this or have any ideas. Here are a couple reports I found online.
This one shows exactly what I see (note: this is not my post), and I was able to "fix" it using the technique in the question. I'm not particularly happy with that solution so I'm still working to understand what's going on.
https://stackoverflow.com/questions/63911732/javascript-canv...
Here's another report that seems related, although there's no mention of interaction with the video element.
https://forum.playcanvas.com/t/samsung-internet-browser-canv...
My Google searching bought me to this posting about Samsung Internet's Video Assistant feature (Nov 2019). My gut feeling is that the Video Assistant is possibly getting in the way of your code executing as expected? https://www.xda-developers.com/samsung-internet-10-2-stable-...
Thanks for the suggestion. I have only found this to be an issues with version 12 and on. I have examples from version 9 & 11 that work as expected (both before and after video assistant was introduced). And I'm able to reproduce the issue with the video assistant turned off.
Of course, none of that is to say it's not related to the video assistant in some way. I just don't have evidence of that yet.
I'm not sure you have a 'product' you just have a library.
If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons.
> I can see the problem, and some of the solutions - but other developers are simply not interested.
Developers are constantly marketed all kinds of solutions. You, the library author, have a responsibility to convince developers that the problem you’re working on is legitimate. If that’s not getting across, that’s on you.
> Maybe HN is trying to tell me that I would be better off developing a standup comedy routine?
Why would anyone want to take you or your work seriously after reading something like this?
It's not necessarily if people care but what they care more.
But it also doesn't cause the developer enough pain to register as a priority. The market is telling you something: it either isn't painful enough to spend money on, or you're not reaching the right people. IMO, you can sell to developers, but you have better luck selling them something that feels like it gives them a superpower, e.g. React is an easy sell because:
1. Reactive binding burns away a lot of imperative state-changing code
2. Facebook branding implies it is industrial-strength
And even then, React costs them their time to learn, build on, and ship. If it's their company's time, then they're not going to value it the same way.
Reading this back to myself, I think that I sound like an asshole, but it's my honest thought process fwitw.
Have I 'solved' web accessibility for the <canvas> element? No. Have I coded up a JS canvas library that has, as one of its central aims, the idea that <canvas> elements can, and should, be made accessible? Yes - that's what I'm attempting to do. It is a work-in-progress; I guarantee that my solutions can be improved on: Rome wasn't built in a day.
> Would you say that you have extraordinary proof?
The results of my efforts to date can be seen on the library's home page. Criticisms and suggestions on how to make things work better are always welcome! https://scrawl-v8.rikweb.org.uk/
"As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product."
Yeah, and I've never met anyone who cared to be honest. And if you do care, your answer is usually a quick "git grep" away.
It only creates a confusion when most people don't bother reading articles when the headline is strong enough to inflict a response. It has become a tool to say something and deny saying it.
The article serves two purposes. It's primary job is to be a scaffolding for delivering advertisements to the reader. The secondary purpose is to be a word soup that makes the article appear in search results related to some popular topic.
That's it. Many people don't realize that the job of a headline is not to be truthful, accurate, or even sensible. It only has one job to do: make you click through, so that ads can be shown to you. Similarly, the job of a news article isn't to inform you about anything, but to keep you scrolling until the end, so that you may see more ads along the way. That's why you don't see the Inverted Pyramid anymore[0].
That's modern journalism in a nutshell.
--
[0] - https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
Glad someone took the time to read the damn article lol
Interesting reading by the way.
It does make me wonder, given the deceptive nature of the title and obviously emotive topic of whether devs should use bleeding-edge tech...
> Please don't comment on whether someone read an article.