Ah, yes. The classic “works on my device” argument.
Edit: from testing with zbarimg on my laptop: Basic, Camo, Neon (inverted), Glass, Blocks, Alien all seem to work reliably. Not sure what the problem is with some others, but maybe they’ll also work with some tweaking (Mondrian seems simple enough! maybe contrast issues?)
Edit 2: for codes that will definitely be scanned using a camera [1], some styles can work because phone camera isn’t perfect. E.g. if you slightly blur Dots, it works with zbarimg, which also means it would work if you slightly move around your phone.
[1]: Screenshots are used sometimes! E.g. for importing TOTP codes into a password manager, etc.
I used python so it's annoying to install, and I need to work on the readme, but I snoop the command line so pbipaste > foo.jpeg works as expected. there's also a copy command
More importantly it's sad and bad when a obvious negative comment is at the top of a front-page Show HN, that misrepresents and then deigns to provide recommendations against this nascent beautiful project that needs our support. Effectively shutting down the experience and enjoyment for incoming audience, and for the creator.
That is a very bad thing and should not be tolerated. Speak up against it.
OP is being respectful and merely points out an issue: the codes generated don’t work with some devices. If you want a code that works with everything, you can’t do too much customization.
It’s a very okay thing to point out and there isn’t much negativity in it. I agree that we should support projects like this, but being dismissive of real issues is not the way.
No; top comment: "don't use it" because "I tested on <my setup>" and <it failed> - you don't see the problem?
It is OK to point out, but not to dissuade others from using, you see? Especially on a Show HN for a cool project where some good person has clearly poured their passion into it. You got to stand up for that stuff. Bring the positivity, man! Frame real issues in the correct (qualified and personal) light, not proclaiming a blanket recommendation, way to go.
I get how making such quick generalizations can serve you well as an engineer, but when people's work is involved it pays to think about it a bit more! :)
Example of respectful: I tried this, super cool, and I encourage everyone to give it a try. For my setup (details), I could only get 10 to work <more details if you want>, but that might just be me. All around super awesome project, love it!"
Example of truly awesome comment if you want to be a super star: I tried this, super cool, and I encourage everyone to give it a try. For my setup (details), I could only get 10 to work <more details if you want>, but that's probably just me! edit: Thinking about it some more, I realized it might be because my device uses an outdated lib<something> and I just updated that and I got 19 of them to work! I checked <the qr code scanning app>'s GitHub and saw they also hadn't updated this dependency. So I opened an issue, and let them know about this, here's the link: <gh issue>. All around super awesome project, love it!"
You get the idea?
Few word mantra: contribute and build, not deplete and discourage.
The problem here is that it cannot possibly work robustly. It does what it does by trampling all over the error correction codes and using out of spec pixel shapes.
This is not the sort of problem that will go away once the technology matures. It is fragile by its very nature.
It is absolutely OK to recommend against it on that basis.
I don't think you're right about that, how could it work at all? Are you even sure how it works? I was able to scan all 21 perfectly, less than 1 second each, on iOS 18 a couple of inches from retina display. I have no idea how it works, but it seems pretty robust to me.
I know people can't do it on some Android phones, and apps. Okay. But still seems pretty good and not a fundamental flaw. Absolutely not OK to blanket recommend against trying that. Why limit anyone? Just encourage everyone to try for themselves. Get more data. Premature to make these negative recommendations on 1 test. Rather than short-circuiting further curiosity and exploration, expand it!
You were scanning a screen, which is perfectly flat, has no crumbling and no smudges. You are using a high resolution camera close to a high resolution screen, on a relatively large QR code. You have a best case scenario, and if that's all you care about, you'll be happy with it.
For now, anyway. If you are using the same scanner implementation that the author used to check their results, then the good results you are seeing are due to the generation algorithm being tuned to work with that particular implementation. But there's no guarantee that the implementation will stay the same in some future iOS. Say Apple makes some change, to better recognise bleached codes or something, and then suddenly some of the drop shadows are interpreted as 1's instead of 0's. They could do that, because that wouldn't require changing anything for codes that follow the spec. But it might break that pretty, pretty code that you just put on a million milk cartons.
> I know people can't do it on some Android phones, and apps. Okay. But still seems pretty good and not a fundamental flaw.
Might not seem like one to you, since you've got a shiny iPhone running the latest iOS, maybe fundamentally it actually is? They're pretty and all, but accessibility and not being ableist is kind of a thing?
I know we can't all have shiny things but does that mean everyone must miss out? Why forbid pre-2018 droids using this pretty square, or everyone else if they can't? If a18n is lowest common denominator to you, well not holding double standards is kind of a thing, right?
I see your point! But there’s an issue specific to QR codes here.
See, if you generate a code and it works for you, you generally expect it to work for other QR readers as well. If all you want to create a QR code for yourself to use (say, to deactivate an alarm with a code, or a Wi-Fi code for your guests to connect maybe, this should be fine. However, things like this will inevitably be used in production, and it would be really bad if, say, a QR code gets printed on a million copies of something and turn out to only work for some users.
I agree that we should support new projects and not choke them down with overly negative commentary. However, piling up positivity doesn’t help either: your second example doesn’t feel genuine to me, more like a spam review in app store or something. I love the sandwich approach in your first one though!
How about this: “Cool project! Some styles are really nice, I didn’t know you can make QR codes like this ever work. However, when I tried reading them with [app name] scanner app, only a few styles actually worked for me. Perhaps it works with other scanners, but this one has [99M+] downloads last month [/ active user base or something]. So if you want to use those be sure to check it works everywhere, and maybe stick to more plain styles? I also hope this gets addressed in the qrframe itself – perhaps tweaking the contrast in styles [X] and [Y] a bit would help.”
It is still way too fluffy IMO, but much more substantial. It is harder to write, of course.
I think you're underestimating the importance of positivity. But aside from that: really? the one where the guy technical deep dives to solve some problem, seemed like a spam review to you, in the context of HN? How do you figure?
They're both genuine from me, one way I might write one. I feel sorry for you that you didn't feel that genuine emotion, or see the utility, but I'm glad you got something from it, hopefully it can help you write better ones in future!
Just curious: have you done many Show HN's yourself? You might be finding it hard to empathize with the uniqueness of that without having some experience doing it.
Regarding the drafts: first one's not really sandwich as much as genuinely owning "maybe this is my setup" (total correct), and expressing love for this cool project.
I like your one, it's a good start. I think focusing clearly on your test set up and expressing positivity is enough. Making recommendations or suggestions runs the risk of making too many unfounded assumptions about intended use, and clouding the market with unfounded restrictions when in reality you don't have the research to back that up. So, temper your pronouncements to the quality of your data, I guess, otherwise you might come across as gratuitously negative or fault finding, as OP here, even if not in "tone" per se, then in harmful effect (authoritative dismissal dimming engagement, etc).
Another way to say it might be: don't overestimate your ability to see real limitations, while underestimating your ability to harm a project or creator with the same.
These ideas, are they all really so shocking? If so, glad I could help bring a bit more light to the Show HNs by prompting some reflection!! :)
In this case, the builder actually agreed with the feedback. You had no reason to call it “poosey”, in fact that’s a stupid word to even have in your vocabulary.
Hahaha! No. What would you know? In fact, that word is perfect for the meaning I expressed. What do you think it means?
The creator can do what he wants, it doesn't change the principles.
Just like I do what I want, and you have no ability to judge my reasons, nor pretend you can judge a word is stupid for someone to use or not - besides yourself.
So maybe turn all those judgment attempts on yourself because you are getting your personal boundaries all wrong, is that something you do a lot? Hahahaha!
Hahahahaha! :) So it's totally okay for you to try that, but no one can say anything back, is that right? You don't think you're a little biased? Might that not be the definition of the disrespect you pretend to be against but try to throw at others? Huh, here's a tip: if you can't take it, don't dish it out. Hahaha! :)
I tested it with my phone and got similar results: I got only 9 out of the 21 QR codes to work. I don't know why you think such a finding should not be mentioned here.
I think it should be mentioned but without the "so I'd recommend against using", because that's wrong. Also, specify OS, surface, time, etc for better test!
> "so I'd recommend against using", because that's wrong.
Someone's opinion is not "wrong". It may be misinformed, it may be different than yours, but you can't just assign a "correctness" value to something subjective just because you disagree with it.
No, that's not it, but I get why you read it like that. By "wrong" I mean the lifting his personal test/opinion to the level of a general "recommendation", in effect discouraging others from exploring, and harming the creator. That is one wrong here. You get it?
Edit: from testing with zbarimg on my laptop: Basic, Camo, Neon (inverted), Glass, Blocks, Alien all seem to work reliably. Not sure what the problem is with some others, but maybe they’ll also work with some tweaking (Mondrian seems simple enough! maybe contrast issues?)
Edit 2: for codes that will definitely be scanned using a camera [1], some styles can work because phone camera isn’t perfect. E.g. if you slightly blur Dots, it works with zbarimg, which also means it would work if you slightly move around your phone.[1]: Screenshots are used sometimes! E.g. for importing TOTP codes into a password manager, etc.