Hacker News new | ask | show | jobs
by vincnetas 2099 days ago
Has any of commenters read the article? Looks like everyone talks about using bleeding edge tech in startup and how its bad, but this article is about building a bleeding edge product and how difficult is to sell such product (probably because everyone know that using bleeding edge products is dangerous :) )
8 comments

Not even about bleeding edge products. It's a lengthy article about the pitfalls of entering a market with no market validation, which the author slapped lipstick on and gave this sexy title.
I had my first startup fail in the late 2000s because we built a sales prediction software that sounded cool, but nobody actually wanted. We even had a large paid pilot with a major auto manufacturer, but they didn't renew when it turned out that none of their employees had actually used the software.

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

Someone on HN once said “It’s hard to tell people the solution to a problem they don’t have”. Building software that solves a problem that the intended users don’t understand that they have is also a real problem.
Yeah, creating problems in people for which you conveniently sell solutions is the job of marketing.

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?

I should clarify that I see nothing wrong in solving a problem people don’t realize they have, and to be fair, this is what startups often do. However, many/most developers see marketing and sales as something unnecessary, eg. “How hard can it be”. And they realize that it’s pretty damn hard when it’s already too late.
April Dunford's "Obviously Awesome" is new(ish) and very good on this topic.
I agree. Look at the landing page [0].

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.

[0] https://www.contrast.app/

Yeah, as someone who might use this product I feel like the landing page should be a long post on “how it works”. Frontend engineers are going to be very big stakeholders on this and I need to know, down to the bone bits how does it’s thing.
That was my take too - they built something nobody wanted, and it failed.
Exactly, its a classic we have a solution, but not a problem-to-solve let alone a product (yet).

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

I read the article before coming to read the HN response to it. I haven't read beyond your top-of-the-thread comment.

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.

I’m sensing some attitude issues just reading this, to be completely honest.

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?

Web accessibility is a legitimate issue that every front-end developer needs to care about.
It is a legitimate issue.

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.

For everything you think someone else needs to care about, there are probably a 1000 other things as well.

It's not necessarily if people care but what they care more.

You have solved the problem of the considerable "extra" effort that web accessibility requires? Less than that, to be honest I'm not interested. If you have, well, extraordinary claims require extraordinary proof. Would you say that you have extraordinary proof?

Reading this back to myself, I think that I sound like an asshole, but it's my honest thought process fwitw.

> You have solved the problem of the considerable "extra" effort that web accessibility requires?

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/

It's true. The challenge is developing in a way that covers the wide range of human disabilities (e.g. vision to cognitive). WCAG will continue to evolve to try and capture the full range. That range of disabilities is why manual testing with a screen reader and a keyboard is the current best solution for uncovering edge cases where a website, or mobile app, is inaccessible.
> 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

Link?

Dealing with Canvas is painful. I recently ran into a weird image distortion issue on Samsung Internet Browser 12 (I guess it's based on the Chrome engine) when drawing a video frame to a canvas context using `drawImage`.

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

I don't have an answer for you, except to say that getting <video> and <canvas> elements to play nicely with each other across all browsers and devices is pretty much guaranteed to damage your day, week, or even your month.

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

One month is about right when you add it all up. Not fun.

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.

Haven't had a chance to look at the code yet, but how did you address responsiveness? It took us a long time when writing chart.js to get that working well on with different browsers, devices, and screens (high resolution screens require extra code)
First: chart.js[1] is an excellent library. If people need to add chart infographics to their website I strongly recommend they use a dedicated charting tool (like chart.js) rather than my library.

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

jQuery community has lots of different extensions. I searched 'jquery canvas' and this popped up: https://projects.calebevans.me/jcanvas/docs/text/

I'm not sure you have a 'product' you just have a library.

There are a number of excellent libraries ('products' - I use the terms interchangeably) dedicated to making development with the <canvas> element a lot easier; they all have a strong basic use case because coding scenes using the native Canvas API is very low-level, repetitive and easy to get wrong. Some of my favourites include Fabric.js, Konva and Pixi.js.
have you tried understanding how to find developers who has the problem in the first place? I think that you might get more traction that way.
Also the "bleeding edge product" in the article is some kind if analytics system that tells you the adoption rate of "components" (web widgets? Not sure) in your system. This might not exactly be what you think of when you hear bleeding edge, so take this article with a grain of salt.
Yeah, I read the piece and couldn't believe that this was the "bleeding edge" product they were referring to. At one point they call it "niche" themselves, which is a more accurate description.

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

That doesn’t really let you know how many components are custom and how many come from the design system.
It's actually hilarious. So many people enjoy sharing their opinion on the headline rather than the content of the article.
Sometimes people just want to talk about a certain topic, regardless of the article's contents. The headline just gives them a convenient excuse.
As 'CPLX says, for many of us the article itself is just a discussion prompt. Quite often (I'd say half of the time), the tangents and off-topics in the HN discussions are way more insightful and interesting than the submitted article.
Almost all of the time I submit something, that's exactly why: I want to read the HN comments, but there aren't any yet!
Which makes me wonder, why people insist on having a headline AND an article in 2020?

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 headline is there to make you want to click on it and view the article.

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)

That got me thinking of an idea for a startup: let's build a service that allows people to broadcast headlines with no content (since no one reads the articles anyway), and then other people can reply to the headlines. To make sure that authors stick to the rules, we'll limit the length of each headline to 140 characters. Side benefit: users can post their headlines via a single SMS message.
Let's build a service that allows people to broadcast headlines with no content and then generate the content based on the comments or the responses.
I made a sketch of it on a napkin: https://imgur.com/UHLAdxQ
I thought I was so clever and was going to reply "you've invented Twitter!" and then I read the rest of your comment, and realized that was your point. Damn it.
In case it wasn't clear, this was tongue-in-cheek. This service exists, it's called Twitter.
Hacker News is a popular forum where participants engage in freewheeling conversations using headlines as a discussion prompt.
Thanks for this comment! I usually read the comments before the article and though it would be a Captain Obvious advicicle with snarky comments as are the comments here. So I wasn’t even considering reading it.

Glad someone took the time to read the damn article lol

Interesting reading by the way.

I actually started reading the article, which sparked my interest at start, but then faded away. so I thought: "This is going to be one of these articles where the comments are more interesting than the piece itself" and came here, just to find the excellent: "did any of the commentators even read the article?"
Is this actually someone just testing what % of people read the article before commenting?

It does make me wonder, given the deceptive nature of the title and obviously emotive topic of whether devs should use bleeding-edge tech...

OT but classic HN not to read the article and only comment on the headline. I feel this part of the guidelines makes it hard to address, when I really just want to say "RTFA before commenting" to some ridiculous comments that would make no sense if the poster had actually read the article.

> Please don't comment on whether someone read an article.

https://news.ycombinator.com/newsguidelines.html

Sometimes I read comments first before deciding to read article.