I became dissatisfied with both. The established commercial offerings had five- to six-figure license fees and the developer experience was not always optimal. The web browser as a platform also seemed not to be the main priority for these players. The open source libraries are essentially unmaintained and not suitable for commercial use due to the lack of support. Also the recognition performance is not enough for some cases - for a detailed comparison see https://strich.io/comparison-with-oss.html
Having dabbled a bit in Computer Vision topics before, and armed with an understanding of the market situation, I set out to build an alternative to fill the gap between the two worlds. After almost two years of on-and-off development and 6 months of piloting with a key customer, STRICH launched at beginning of this year.
STRICH is built exclusively for web browsers running on smartphones. I believe the vast majority of barcode scanning apps are in-house line of business apps that benefit from distribution outside of app stores and a single codebase with abundant developer resources. Barcode scanning in web apps is efficient and avoids platform risk and unnecessary costs associated with developing and publishing native apps.
Even weirder as I understand from other comments, that scan will fail without internet entirely due to licensing server being unreachable. Strong always-online single-player games vibe.
Monetizing these types of libraries based on performed transactions or active devices is pretty standard.
The internet connection is only required for the license check which occurs at initialization time, typically once per application session (in case of an SPA). One thing to consider is that with web apps, an internet connection is kind of a requirement anyway - with completely offline-capable PWAs being the exception. Typical barcode scanning apps will want to report or look up data associated with a scanned code from an API backend.
And yeah, I'm annoyed too when I'm stuck in a login queue when I want to play Diablo 4 in single-player mode.
Honestly I haven't seen it much. Yearly support/update fee of course, but this is new, very sad trend.
Online-only isn't ideal but I'd imagine the vast majority of use cases here are going to be always-online anyway (what are you going to do with the barcode value if not send it somewhere?)
Developers need to understand that connected to a network != path to the internet.
The developers site isn't even accessible from China: http://www.chinafirewalltest.com/?siteurl=strich.io
(Obviously you should pay for the product, but fuck anyone who builds a product that works entirely offline except for a license check)
In-browser webcam demo from the polyfill author: [2]
Making this a paid-per-scan and online-required library will have a hard time IMHO.
[0]: https://caniuse.com/mdn-api_barcodedetector
[1]: https://github.com/undecaf/barcode-detector-polyfill#readme
[2]: https://codepen.io/undecaf/pen/LYzXXzg
Edit: Just updated my post with the codepen from the polyfill author: https://codepen.io/undecaf/pen/LYzXXzg
It is butter smooth with EAN barcode when using the builtin webcam on my Macbook (720p on a 2019 MBP16)
If you're looking to only scan QR codes, https://github.com/nimiq/qr-scanner is a library I can recommend and which I've used in a previous project.
One thing the BarcodeDetector API does not give you is a UI for your barcode scanning. Basically it's your job to acquire an image and pass it to the API. With STRICH, you just provide an HTML element and the scanner will live in there, including controls for camera selection and flashlight (only on Android, unfortunately).
I've built software to run a warehouse before and we actually ran everything off a web app that was used both on the desktop and on mobile apps. We used barcodes for everything.
I'll be honest, this isn't a problem we ever had. Barcode reader hardware always seemed cheap, good, and worked as a keyboard as far as web apps were concerned, so integration was trivial. In fact we had more success with those than with camera based options because the hardware and software was simpler.
Where do you see the USP of this vs, say, phones with built-in barcode scanners, hand-held scanners, or finger mounted scanners?
Separately, I see your pricing is based on number of scans. How do you validate this? Do you have a server component? Does that require an internet connection, and do you see that limiting the market at all because of either offline use or rules around depending on external services?
I agree with you that dedicated barcode reader hardware performs well and can be quite cheap. Did you not find the keyboard-style integration limiting regarding integration in your app, basically having to design your app to accept keystrokes followed by <enter> (I think this is commonly referred to as "keyboard wedge")?
Regarding phones with built-in barcode scanners: I have some experience with Zebra TCx devices, which definitely work well, but they're quite expensive. Many companies, especially smaller ones, use employee devices and have programs that incentivize BYOD, like handing out annual cash payouts if you bring your own phone to work. Also some companies in logistics I've worked with rely on external partners (e.g. bike couriers) where you don't know what kind of device they'll use.
Regarding the pricing: the SDK periodically transmits the number of scans that the device performed to a cloud-hosted API. The license check is also online (https://strich.io/faq.html#faqDataTypes). For customers that require fully offline operation, there is a separate Enterprise license on offer.
We didn't. We were able to use regular <input> fields and handle input in all the ways we already knew how to support well. It had the added benefit that manual testing during development could also be done with the keyboard which meant we didn't need to give engineers any specialised hardware most of the time.
The flexibility also helped when we ran certain processes in the warehouse in different ways. We (engineering) learnt a while after we had put the system into action that sometimes people in the warehouse weren't using a phone with an attached or built-in scanner, but were sometimes using a Chromebook with a scanning gun. They'd use this for various bulk processing, or supervisors would use this because they worked mostly in the non-mobile tools or needed the productivity of a bigger screen and laptop over a phone.
I guess the overall thing here though was that we just never thought about barcode scanning because it never came up as an issue[^1].
> I have some experience with Zebra TCx devices ... but they're quite expensive. Many companies...BYOD... Also some companies ... rely on external partners ... where you don't know what kind of device they'll use.
This is a fair point. We didn't BYOD because these devices were in constant use in a busy warehouse and personal phones wouldn't have cut it in terms of reliability, but for more occasional use I get it. External partners BYOD'ing also makes sense.
I think we had some Zebra TCx devices, or if not something very similar. They were pricey, but for extensive usage at our scale, probably not far off price competitive with your pricing. We also only had a few for a specialised use-case, mostly we used cheaper devices without the built-in scanners, and laptop/desktop hardware when mobility wasn't as important.
> Regarding the pricing...
Good FAQ answers on that one. That's my concerns addressed there! Enterprise pricing for offline support makes sense. Periodic reporting also sounds reasonable.
[^1]: Except... that time someone left a barcode scanner with the trigger depressed on a desk once and because we made an API call on a scan, it brought down the site and database. Thankfully a quick fix and some protections and rate limiting solved it from ever causing an issue again, but a funny issue.
1) Since the library is meant to be used in a web app, how would the app be accessed without internet access? Also there is an Enterprise license which has completely offline operation, but this has been requested mainly for compliance and IT policy reasons.
2) Knowing what some of my competitors charge I disagree. I encourage you to send an email to the address listed on the page, and I will gladly send you the Enterprise factsheet. But yeah, maybe it's not for you and that's fine!
If a website still works when wifi is disabled, it's because the entirety of the application has been downloaded and cached by the browser; no further Network requests are needed—or invoked by something the user might want to do, like scanning another barcode.
If scanning a barcode requires a GET, POST, PUT etc. somewhere, it won't work offline.
If scanning a barcode only requires reusing a cached script/function/asset, it should work offline.
Progressive web app (PWA), or containered webapps like electron & co.
For a library like this, the only really appealing pricing model is a flat fee that buys unlimited use of the version I buy in perpetuity (even if that fee is several thousand dollars). I'm not, however, going to pay monthly forever for code that (1) you wrote once and is now static, (2) that you aren't hosting, and (3) that I need to integrate into my application myself. That feels like paying my car manufacturer a monthly subscription for heated seats [4].
If I need support I will happily pay you a support fee. Moreover, I cannot take on the liability of my app's bar code scanner ceasing working because you decide to close your doors and then the license won't reactivate.
[1]: https://github.com/mebjas/html5-qrcode
[2]: https://strich.io/comparison-with-oss.html
[3]: https://blog.minhazav.dev/research/html5-qrcode
[4]: https://www.theverge.com/2022/7/12/23204950/bmw-subscription...
It's a bit disingenuous to claim that I wrote the code once and it is now static (I wish!), but I see that you are not a fan of aubscription models and I understand that.
Unless the library code were in some way self-updating or had some server side component, I think it's disingenuous to call the library code embedded in my app anything other than static. I assume by "not static" you are referring to decision to continue improving it, which I think is great and affords you the ability to sell me a newer version.
https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Det...
On the other hand, that person would probably never have paid anyway. Also, as mentioned in the text, there are more interesting targets if you really want to get into it, which have the same problems.