This sounds neat! Do you have a site that describes how it's added to an existing project?

Congrats on shipping!

Here's some quick feedback -- hope it's useful:

1. Is the little bug icon sufficiently visible? I'm not sure...

2. Do visitors automatically know what to do with the bug? You have a tooltip, but do all visitors know what "Spotted a bug?" means?

3. [more of a suggestion; perhaps it does this already] Would be great if the bug position pulled in a CSS class or the content surrounding the "dropped" bug -- to give more context to the site owner.

The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports, or the "my neighbour is a spy for the government and I have proof" reports (real types of reports for a browser company, for example, which surely exist for other places users think that "is" the internet like Facebook).

I agree that reporting bugs can be hard, but the amount of spam that follows an effective open form, of craziness to uselessness, outweighs the useful bug reports.

Having two types of reports: one which is a simple screenshot taker with the ability to draw a circle over what is wrong, and one which is a more detailed report, would be useful.

Some LLM that filters out what is a useless report be a useful report would be good, too.

I love the UI concept. Being able to point at a broken thing rather than try to uniquely describe the position/state/path to a broken thing is smart!

Hooooever, "bug" could be a bit ambiguous to a lot of people. Looks like in a real deployment, you have a little tooltip that says "Spotted a bug? Drag me there!". That makes sense to developers and the like... but those are also the sorts of people most likely to write a good bug report anyway. The people most unlikely to write a bug report are the sorts of people who will read "spotted a bug" as "there is an insect... game?... on this site?".

"Issue" or "Problem" would be better, but keep the bug graphic! It's cute. :)

Why not a video snippet? Why a note?

I won't report bugs in paid software/services because it's not my job, I'm not paid for it, I'm user of the service, not free workforce so they can reduce amount of QA staff or skip it completely. Give me a discount and then maybe, just maybe I'll think twice about reporting something. Bugs renders your soft unusable? Fine, there is plenty of competition out there who will do it right.

Not a fan of made-up testimonials, but otherwise it looks nice. How do you prevent spam?

You write that "reporting bugs is usually a terrible experience". I find bugs ALL THE TIME, and yet, when I even try to find a way to contact ANYONE, let alone a developer, they leave no door open at all. No method, no form, no contact name, no nothing. I (along with many, I presume), actually want those companies to excel. I WANT to let them know what to fix. But, they just don't want to hear about it. Really sad I think.

There's the other side of the coin of reporting bugs besides initial friction: if the user feels like the bug reports end up in a black hole, then they will disincentivized from doing so.

What happens after the user files a bug from their point of view? Is there a follow-up, or is it like throwing a message in a bottle?

Nature takes the path of least resistance. In my experience, especially people. Make it easy people will use it, make it difficult and they won't.

It's the reason apple became apple, even though I don't think the iPhone is intuitive today.

For many corporations, there are probably perverse incentives against making it easy to report bugs.KPI of reported bugs as an indicator of software quality, for example.

Reporting bugs is work, and is a two-way street: if submission is a black hole (possibly with some scripted replies from someone uninvolved in fixing bugs), then bugs will not be reported.

I imagine it's been quite difficult to educate users to use this tool?

Kindle made it easy to report errors in ebooks, but I always found myself wondering if the errors I was flagging were even being looked at.

Here's a quick bug report: I didn't know how I can check out the app you built. There were no links in your post. Only "Bugdrop.app", the name. I tried Googling it and it turns out Bugdrop.app is your actual domain. You should point that out: Bugdrop.app => https://bugdrop.app/

On macOS .app is the standard extension for any installed app.

What made you go with this design choice instead of Google's "Feedback" button that lets you take a screenshot?

Okay but what have you built?

Love this! That said, wanted to try it on your website, can't report a bug that the bug reporting doesn't work on Safari MacOS... the submit button does not do anything.

Love this! That said, wanted to try it on your website, can't report a bug that the bug reporting doesn't work on Safari MacOS... the submit button does not do anything.

I had really simple feedback form in my Android app that was just text area and submit button. Then some ashole tester from Google put @ in it and suddenly I'm collecting PII. It was easier to just remove the feedback form.

this sounds like a vital improvement.

Every bug I encounter in my favorite game I do not report because they want:

* My email, yet again.

* A long form

* A bug description rather than a narrative of what I experienced

And that is why companies use telemetry. As privacy advocate I still let telemetry to be collected as long as it is transparent. And I can filter it if there is something too disturbing.

Just this week I was working on something similar but specifically for users who have disabilities, so they can more easily report issues to site owners. I also combined general annotation capability so other users (of my browser extension) can read their comments. And also compatibility with Hypothesis (https://github.com/hypothesis, https://hypothes.is), also using the W3C Web Annotation spec. I hadn't thought of the drag-and-drop bug metaphor; I like it. I had also considered recording mouse and keystroke events up until the time that the bug is marked, and then bundling those events (sanitized) with the bug report for more precise repro steps, but of course that's a bigger ask for the opt-in.

Or just use post hog or clarify to have sessions and check them? That helped me to find bugs without reporting.

The other method I used is to have audit logs, identify when there are errors in certain steps.

The problem with bug reporting is that they rarely seem to get fixed. I used to do a lot more bug reports. But you often hear back nothing, and then the bug is never fixed, even if it would be an easy fix. These days, I don't often report bugs.

The most I have tried with reporting bugs in a mobile app is going to settings and seeing if there’s a bug report button or something like that. Not worth the effort considering the low probability of it being even looked at.

Any involvement in reporting / fixing bugs is development. Why do app developers think their customers need to be or want to be developers?

What other industry relies on its customers as implicit developers?

Making bug reporting easier means an intentional push to foist more of Development's work upon customers and a bias towards more bugs.

BUG OR FEATURE?

If you can't tell, then we can understand why Knuth call it "the art" of computer programming, as in the artist's uncertainty of creation as compared to the engineer's confidence.

The fact that half the SW industry prefers to avoid a distinction between bugs and features— as in bugs that don't get reported are regarded as features— shows the profligate laziness and opportunism of so called Software Engineering.

AI is a stunning example of a global industry built by computer technologists who don't care about understanding their own work, and lack the creative and social spark to conduct themselves as artists.

Just listen G. Hinton babble philosophically for 10 minutes and you will grasp the magnitude of incompetence at work.

I love this. Especially the sane pricing.

Only thing I would add is after submit it should allow you to enter an email address or something so that (a) the user can get updates on the progress of fixes; and (b) be contacted if the dev needs more info.

> screenshots, browser info, even console logs if they hit an error.

Possibly disclosing sensitive information (which the user may not realize).

Bugdrop won't work for most users, since they don't real tooltips.

1. I load https://bugdrop.app/

2. The site days 'try bugdrop' and points to the left bottom corner.

3. I click the bug. Nothing happens.

On further inspection, there is sometimes a tooltip that tells me clicking won't work and I need to drag the bug over the part of the UI that failed, but I didn't read that when I first used it and I won't use it a second time.

If you submit a really detailed bug report, such as one where the problem was reproduced under a debugger, it becomes a "the reason you suck" speech. This really upsets some dev teams. The usual responses of the "turn it off and on again" and "reinstall" don't make the complaint go away.

There are two bugs in Firefox I'd like to report, but it's futile. One is that, launched on Ubuntu, Firestorm does disk I/O for about three minutes on launch. During that period it can't load complex pages, although it loads ones without Javascript fine. The other, again on Ubuntu, is that it freezes when large text boxes are being filled in. This only happens on some sites.

FYI, there’s a bug with the bug, it doesn’t move on mobile

> Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects.

Maybe people could combine this reporting solution with a bug capture solution I built a few weeks ago? It's a web-based screen recorder which allows a user to gather together several different areas of the screen into one place, add a talking head of themselves and demonstrate/explain the problem they've encountered. The resulting video could be added to the bug report. I built the tool because showing the problem is always better than trying to explain it in words.

Tool: https://kaliedarik.github.io/sc-screen-recorder/ GitHub repo (it can be forked, self-hosted, etc): https://github.com/KaliedaRik/sc-screen-recorder

Sounds like a great idea.

I have found that users don't give feedback, positive or negative, until they encounter some extreme (usually negative).

I have found the best way to encourage feedback, is to make it dirt simple. Just a text entry field, with some way to respond, so you can follow up.

Most of the work needs to be on my end.

This is a huge problem in Apple iOS land where the only way to leave feedback and tons of apps is to leave a review on the app store and then watch Apple delete it immediately

I really like how some indie games have put in a widget for feedback. Press F11 or something, click an emoji face, optionally add a description, and click send. The game takes care of sending a screenshot, game state etc. (It tells you it's doing this in the interface)

Working at google taught me to not bother. An android bug I filed the month that I joined was closed a part of "bug bankruptcy" seven years later, having never been triaged. Why bother? When I was quitting - a year after that, the actual bug still existed.

When I encounter a bug, I will almost never report it either, I’ll hope that someone else will or the developer will notice themselves while using their product.

Reporting a bug is work. If it is certain that the bug will be fixed upon reporting this work may be worth doing for selfish (or non selfish) reasons, but I almost never have confidence that it is.

I agree. Bug trackers should be easy to use. I wish Debian and ffmpeg would have better bug trackers.

The worst example I ever experienced was finding an actual flaw within some software with Trac as a version control system - somehow DD-WRT comes to mind - and I submitted a bug report with full reproducibility workflow and everything I could imagine. Essentially, the platinum standard for submitting a bug report in software development.

It was immediately rejected.

The reasoning? “Did not identify the relevant code in which the error occurred”.

Like… WTF????

Edit: confirmed as DD-WRT. I’ve never submitted another bug report to them again. And I’ve submitted hundreds of reports to other projects all over.

I love this, and I'm so glad it has resulted in more people filing bugs. That said, there is a larger problem going on here that has yet to be addressed by the software industry as a whole. And that is that "bugs" (and "filing" bugs) is a very complex thing. It's not just one thing, it's many, many things. And until we face that and provide a holistic solution for "it", it will continue to be an existential problem.

Here's a selection of the different kinds of complexity with "bugs":

- Type. Is it a backend or frontend bug? A network bug or an infrastructure bug? An internal or external bug? Is it a "not considered a bug" bug? Is it a bug in documentation, training, intuitiveness, etc? A product- or feature-specific bug? A location-specific bug? A user-specific bug?

- Context. Is the user even capable of giving you enough context and information for this bug report to be usable? If so, is automatic? If not, will the user simply give up reporting when this becomes difficult?

- Communication. How does the user even report a bug? (I regularly try to file bugs with every tech product I use - because they are constantly riddled with end-user bugs - but I spend hours trying to dig up some way to contact the company to report the bug, and when I finally can contact someone, they refuse to even take my bug report, because it's not one of the read-from-the-script-customer-service responses/actions. And if the user does eventually get in contact with the company, is the developer (or anyone else) even capable of communicating with this user to get more information or inform them of a fix?

- Visibility. Quite often, users will experience bugs, and maybe one report comes in about them. This is then captured by customer service or someone else, and maybe they file a ticket. But then for each subsequent request, they just tell the customer they will record it and then.... don't send it to anyone, because they've already sent one such bug and assume it's being fixed. So the developers have no idea how often this bug is actually happening. Often when bugs are reported the devs aren't informed at all.

- Impact. Is it just affecting a single user, once or twice, in a niche setting? Is it affecting the same user all the time? Is it affecting a subset of users? All users? Is it affecting all users, but core functionality still works? Is it significantly affecting core functionality? Is it affecting core functionality but there's bigger issues going on so it's actually less of an impact? Are the developers even capable of understanding the impact? (how many of you know exactly how much each specific function affects the business?)

- Prioritization. We all have ticketing systems full of hundreds of tickets that sit in the backlog never to be fixed. They're annoying, or difficult, or unsexy, or they're not a new feature. Sexy bugs get prioritized, unsexy bugs sit in the trash heap.

- Fixability. Even if all of the rest is provided for... how difficult or easy is it for a developer to fix? Is the developer capable of contextualizing it and making use of the information? Do some of them have difficulty reproducing it, while others don't? Do they have all the training needed on all the systems involved in order to effectively triage/investigate/troubleshoot? Are they given dedicated time each development cycle to fix bugs? Are they even able to track down who is responsible for "fixing" the bug, what with the modern mess of interdependent microservices and siloed development teams? Will they be implementing regression tests to make sure it doesn't come back? Are you rewarding them for this work, in addition to the rewards for "sexy work" (new features implemented, cost saved)?

Yes, getting users to file more bugs is fantastic! But that is quite literally the tip of the iceberg.

I think it's cool you built and shared it - grats on shipping.

But you (or your users) are about to learn a few truths about bugs and users :)

Foremost: unless your users pay for the product, there's a downside to easy bug reports - the vast majority will be useless, no matter how easy it is. Granted, that's true for paid products too, but at least you can bake the cost for dealing with that into the price of goods.

It's absolutely great while you're building traction. Even the most inane post has usually a kernel of truth. It's becoming a problem as you are clear on where you're heading, and the cost of dealing with them outpaces their value.

At that point, you either start stochastic sampling (annoying your users who write well thought-out reports, and who are your multipliers), or you spend a fortune to slog through everything. That's when you start writing the "feedback suite" backend :)

The response is usually the problem.

If I file a bug I get either:

1) nothing

2) a reasonable response that may or may not include resolution

3) a shared debugging journey that takes three hours of my life

Number 3 devs mean well and have admirable commitment…but I’d rather not sign up for an epic trek to throw a ring into mountain doom. I just want to point out an issue and provide some basic info.

So these days the only thing I do for the most part is send crash logs.

Most companies don’t have a user accessible way to file bugs. Often, you have to call support, speak to a muppet, then convince them that your issue is real and they’ll file it. Trust me, I find bugs in products all the time and I actually try to file bug reports, but it’s rare that I can.

Some of this is because one of the worst bug-related metrics is “customer found bugs.” This means that your developers missed it during unit testing and your test team missed it during system and final testing. Nobody actually wants customers to be able to file bug reports because they make the team look bad.

I use to report bugs all the time with details of the bug and what I was doing and if possible how to cause it. But then when you encounter the same bugs years later doing some very common task that you momentarily forgot to do your work around for, it made me wonder why I was wasting my time reporting it. These days I rarely report bugs unless it is brand new software released a few weeks ago at most, or a brand new release of older software with a new bug. If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed. So why waste the time? Im not getting paid for it, it likely won't be fixed, and 49/50 bugs I encounter are things that seem impossible to miss with any real QC.

Doing decent bug reports as a user most of the time it feels like following the turnip truck to town picking up turnips that fell off the truck, giving them to the farmer, but knowing they will likely be thrown in the trash because they didn't care about them to start with. If they did they would have made sure to not overload the truck to start with and not be obviously dropping so many turnips on the side of the road and leaving them there.

In 2022 and 2023, I made a push to find and fix bugs in OpenZFS using static analysis tools. I found many obscure bugs. One was a theoretical issue that should have affected big endian systems and been an annoyance for users, but there were no bug reports saying anyone had been affected. After I opened a PR with a fix, people told me that they had been affected, but did not think it was worthwhile to file a bug report. This surprised me. This is the PR:

https://github.com/openzfs/zfs/pull/13968

Built in fun mini game: How far can you get the bug to move (only counting after you release your mouse) without the popup appearing. Multiple clicks are allowed.