diff --git a/src/app/compare/[slug]/page.tsx b/src/app/compare/[slug]/page.tsx new file mode 100644 index 0000000..1cf6b29 --- /dev/null +++ b/src/app/compare/[slug]/page.tsx @@ -0,0 +1,49 @@ +import { notFound } from "next/navigation"; +import { compareNav } from "@/lib/compare-nav"; +import Link from "next/link"; + +export function generateStaticParams() { + return compareNav.map((c) => ({ slug: c.slug })); +} + +export default async function ComparePage({ + params, +}: { + params: Promise<{ slug: string }>; +}) { + const { slug } = await params; + const comparison = compareNav.find((c) => c.slug === slug); + if (!comparison) notFound(); + try { + const Content = (await import(`@/content/compare/${slug}.mdx`)).default; + return ( +
+ + ← All Comparisons + + +
+

+ Try BugDrop free +

+

+ Add screenshot-powered bug reporting to any site in under a minute. +

+ + Install GitHub App + +
+
+ ); + } catch { + notFound(); + } +} diff --git a/src/app/compare/page.tsx b/src/app/compare/page.tsx new file mode 100644 index 0000000..35e05a5 --- /dev/null +++ b/src/app/compare/page.tsx @@ -0,0 +1,30 @@ +import Link from "next/link"; +import { compareNav } from "@/lib/compare-nav"; + +export const metadata = { + title: "Compare — BugDrop", + description: "See how BugDrop compares to other feedback tools.", +}; + +export default function CompareIndex() { + return ( +
+

Compare

+

+ See how BugDrop compares to other feedback tools. +

+
+ {compareNav.map((c) => ( + +

{c.title}

+

{c.description}

+ + ))} +
+
+ ); +} diff --git a/src/app/sitemap.ts b/src/app/sitemap.ts index d18d987..a9d9748 100644 --- a/src/app/sitemap.ts +++ b/src/app/sitemap.ts @@ -14,5 +14,9 @@ export default function sitemap(): MetadataRoute.Sitemap { { url: `${base}/use-cases/open-source`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 }, { url: `${base}/use-cases/internal-tools`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 }, { url: `${base}/use-cases/client-projects`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.6 }, + { url: `${base}/compare`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.8 }, + { url: `${base}/compare/userback`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 }, + { url: `${base}/compare/canny`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 }, + { url: `${base}/compare/sentry-user-feedback`, lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 }, ]; } diff --git a/src/components/nav.tsx b/src/components/nav.tsx index 5fa9839..472bd0a 100644 --- a/src/components/nav.tsx +++ b/src/components/nav.tsx @@ -13,6 +13,9 @@ export function Nav() { Use Cases + + Compare + + + +``` + +You can adjust the accent color, border radius, and other CSS custom properties to match the client's brand. This makes the widget feel like a natural part of the staging site rather than an afterthought. + +## Streamlining the Review Process + +With BugDrop on every staging site, client review rounds become structured and efficient. All feedback lives in GitHub Issues, each with a screenshot and device context. You can prioritize and assign tasks directly from your existing workflow, close issues as you resolve them, and give clients visibility into progress. The days of searching through email threads and Slack messages for that one piece of feedback about the mobile navigation are over. diff --git a/src/content/use-cases/internal-tools.mdx b/src/content/use-cases/internal-tools.mdx index 512829f..4e2b1a7 100644 --- a/src/content/use-cases/internal-tools.mdx +++ b/src/content/use-cases/internal-tools.mdx @@ -1,14 +1,49 @@ # Internal Tools -Internal dashboards, admin panels, and developer tools rarely get formal QA. Bugs pile up because reporting friction is too high. +Internal dashboards, admin panels, and developer tools rarely get formal QA. They are built quickly to serve internal needs, iterated on by small teams, and almost never have dedicated testers. Bugs pile up quietly because reporting friction is too high — nobody wants to stop what they are doing, open Jira, write a ticket, take a screenshot, upload it, and fill out required fields just to report that a chart is rendering the wrong date range. -## How BugDrop Helps +## The Problem with Internal Bug Reporting -Embed BugDrop on your internal tools and your team can report issues in seconds — click the feedback button, capture what's wrong with an annotated screenshot, and the issue lands in your team's GitHub repo. +Most teams rely on informal channels to report internal tool issues. Someone posts a screenshot in Slack with "this looks wrong." Someone else replies "yeah I saw that too." A week later, the thread is buried and the bug is forgotten. When teams do use formal issue trackers for internal tools, the tickets tend to be vague — "analytics dashboard is broken" with no screenshot, no browser info, and no indication of which specific widget or data point is wrong. + +The people using internal tools are often not engineers. Product managers, operations staff, and customer support teams interact with admin panels and reporting dashboards daily, but they do not have the technical vocabulary to describe frontend bugs precisely. They know something looks wrong, but explaining whether it is a rendering issue, a data issue, or a layout issue in a way that helps an engineer reproduce it is difficult. + +The result is a steady accumulation of small bugs that erode trust in internal tools, push teams back toward manual processes or spreadsheets, and create a death-by-a-thousand-cuts experience for everyone in the organization. + +## How BugDrop Solves This + +BugDrop eliminates reporting friction by embedding a feedback button directly on your internal tools. One script tag on your admin panel, analytics dashboard, or developer tool, and every team member can report issues in seconds. They click the button, see the widget open with a screenshot already captured, type a quick description, annotate the screenshot to highlight the problem, and submit. A well-formatted GitHub issue appears in your team's repo with the description, annotated screenshot, browser info, and screen dimensions. + +No training sessions. No workflow documentation. No extra accounts. + +### A Typical Scenario + +Picture a product manager reviewing the weekly metrics on your team's analytics dashboard. She notices that the revenue chart for Q1 is showing a negative value that does not match the spreadsheet export. She clicks the BugDrop button in the corner, types "Q1 revenue chart shows -$12K but export shows +$48K," circles the offending chart in the annotation tool, and submits. Two minutes later, the engineering team has a GitHub issue with her description, a screenshot of the exact chart state, her browser version, and her screen resolution. The engineer can immediately see which chart component is affected and start investigating — no Slack thread, no follow-up questions, no lost context. ## Why It Works for Internal Tools -- **No training needed** — the widget is self-explanatory -- **Screenshots capture context** — no more vague tickets -- **System info included** — browser version, screen size, and OS are captured automatically -- **Categories** — reporters can tag issues as Bug, Feature, or Question +- **No training needed** — the widget is self-explanatory with a clear button, a text field, and a submit action; anyone who can use a web browser can report a bug +- **Visual context with screenshots** — annotated screenshots eliminate ambiguity; reporters show exactly what they see, not what they think they see +- **System info auto-captured** — browser version, operating system, screen size, and viewport dimensions are included with every report, which is critical for debugging layout and rendering issues +- **Categories for triage** — reporters select Bug, Feature, or Question, allowing the engineering team to filter and prioritize without reading every submission +- **Works behind VPN** — BugDrop is entirely client-side; the widget runs in the user's browser and communicates with GitHub through BugDrop's backend, so it works on internal networks without any special network configuration +- **Dismissible button** — power users who do not need the feedback widget can dismiss the button, keeping it out of the way for team members who prefer to file issues directly + +## How to Set It Up + +Add the widget to your internal tool with a script tag. Here is an example with dark theme configuration, which is common for developer tools and dashboards: + +```html + +``` + +The dark theme matches the visual style of most internal dashboards and admin panels, so the widget feels like a natural part of the interface rather than an add-on. + +## A Low-Cost Quality Investment + +Internal tools do not need a full QA team to improve. They just need a way for the people who use them every day to report what is wrong without friction. BugDrop turns every team member into a tester — and because the reports include screenshots and system info, the engineering team can act on them without the usual back-and-forth. diff --git a/src/content/use-cases/open-source.mdx b/src/content/use-cases/open-source.mdx index 35dac18..d60f8b1 100644 --- a/src/content/use-cases/open-source.mdx +++ b/src/content/use-cases/open-source.mdx @@ -1,14 +1,49 @@ # Open Source Projects -Collecting structured bug reports from an open source community is hard. Users file vague issues, forget system info, and rarely include screenshots. +Collecting structured bug reports from an open source community is one of the most persistent challenges maintainers face. Users file vague issues with titles like "it's broken" or "doesn't work for me," forget to include system information, and rarely attach screenshots. Maintainers then spend more time triaging and requesting additional context than actually fixing bugs. For projects that depend on volunteer effort, this wasted time is especially costly. -## How BugDrop Helps +## The Problem with Traditional Bug Reporting -BugDrop adds a feedback button directly to your project's demo or documentation site. When a community member finds a bug, they click the button, describe the issue, a screenshot is captured and they can annotate it, and a well-formatted GitHub issue is created in your repo. +Most open source projects rely on GitHub issue templates to guide reporters through providing useful information. In theory, templates prompt users to include their browser version, operating system, steps to reproduce, and expected versus actual behavior. In practice, many community users skip the template entirely, delete the placeholder text, or fill it in with one-liners that leave maintainers guessing. + +Even well-intentioned reporters struggle. Describing a visual bug in words is inherently difficult. "The sidebar overlaps the main content on mobile" could mean a dozen different things depending on the viewport width, browser, and which sidebar element is involved. Without a screenshot, the maintainer has to reproduce the issue blind — often on a different operating system or browser than the reporter is using. + +The result is a growing backlog of issues that are difficult to act on, frustrated maintainers who feel like they spend all their time asking clarifying questions, and frustrated users who feel like their reports disappear into a void. + +## How BugDrop Solves This + +BugDrop adds a lightweight feedback button directly to your project's demo site, documentation pages, or any web-based interface. When a community member encounters a bug, they click the button, type a short description, and a screenshot of the current page is automatically captured. The reporter can then annotate the screenshot — circling the broken element, drawing an arrow to the misaligned text, or highlighting the area that looks wrong. Once they submit, a well-formatted GitHub issue is created in your repository with the description, the annotated screenshot, and automatically captured system information. + +There is no signup, no account creation, and no friction. The reporter never leaves your site. + +### A Typical Scenario + +Imagine a user browsing your project's documentation site. They notice that a CSS transition is broken on the code example tabs — clicking between tabs causes a flash of unstyled content. With BugDrop embedded on the docs site, the user clicks the feedback button in the corner, types "Tab switching flashes unstyled content," and the widget captures a screenshot of the exact state of the page. The user circles the tab area in the annotation tool and submits. Thirty seconds later, you have a GitHub issue with a clear description, a visual reference, and the user's browser and OS information — everything you need to investigate and fix the bug without a single follow-up question. ## Why It Works for OSS -- **No account required** — users don't need to be GitHub members to report -- **Low friction** — one click to start, no forms to fill out -- **Auto-formatted** — issues follow a consistent template -- **Free and open source** — BugDrop itself is MIT licensed +- **No account required** — users do not need a GitHub account or any account at all to report issues, which dramatically lowers the barrier for community members who are not developers +- **Low friction** — one click to open the widget, a short description, and submit; the entire process takes under a minute +- **Auto-formatted** — every issue follows a consistent structure with description, screenshot, and system info, so your issue tracker stays organized +- **Free and open source** — BugDrop itself is MIT licensed, so there is no cost and no vendor lock-in for your project +- **Screenshots with annotations** — reporters can circle, arrow, and highlight exactly what they see, eliminating the ambiguity of text-only descriptions +- **System info captured** — browser name and version, operating system, screen resolution, and viewport size are included automatically +- **Feedback categories** — reporters can tag their submission as a Bug, Feature request, or Question, helping you triage without reading every issue + +## How to Set It Up + +Adding BugDrop to your documentation or demo site takes a single script tag: + +```html + +``` + +Replace `your-org/your-repo` with your GitHub repository. The widget appears as a small feedback button in the corner of the page. + +## Public and Private Repos + +BugDrop works with both public and private GitHub repositories. For public repos, issues are visible to the community. For private repos, issues are only visible to collaborators — useful for projects that want to collect feedback from a public demo site but keep their issue tracker private during early development. diff --git a/src/lib/compare-nav.ts b/src/lib/compare-nav.ts new file mode 100644 index 0000000..8c79598 --- /dev/null +++ b/src/lib/compare-nav.ts @@ -0,0 +1,23 @@ +export interface CompareLink { + slug: string; + title: string; + description: string; +} + +export const compareNav: CompareLink[] = [ + { + slug: "userback", + title: "BugDrop vs Userback", + description: "Open-source GitHub-native alternative to Userback's visual feedback platform.", + }, + { + slug: "canny", + title: "BugDrop vs Canny", + description: "Lightweight bug reporting vs feature request management — different tools for different needs.", + }, + { + slug: "sentry-user-feedback", + title: "BugDrop vs Sentry User Feedback", + description: "Screenshot-first bug reports vs error monitoring feedback — complementary tools.", + }, +]; diff --git a/src/lib/docs-nav.ts b/src/lib/docs-nav.ts index 3753cca..51264a1 100644 --- a/src/lib/docs-nav.ts +++ b/src/lib/docs-nav.ts @@ -8,5 +8,10 @@ export const docsNav: DocLink[] = [ { slug: "installation", title: "Installation" }, { slug: "configuration", title: "Configuration" }, { slug: "styling", title: "Styling" }, + { slug: "javascript-api", title: "JavaScript API" }, + { slug: "version-pinning", title: "Version Pinning" }, + { slug: "ci-testing", title: "CI Testing" }, + { slug: "security", title: "Security" }, + { slug: "self-hosting", title: "Self-Hosting" }, { slug: "faq", title: "FAQ" }, ];