Stop rendering Social Shares on deep dives

Author: webstackdev

_TODO.md

@@ -141,6 +141,8 @@ The text, diagrams, and images in this work are licensed under CC BY-NC 4.0
 All code samples in this article are licensed under the MIT License. Feel free to use, modify, and distribute them in any project.
 ```
 
+- When someone's already given their email address, the Download CTA should just have a download button - not require them to sign up again
+
 ## Search
 
 - How do we handle the keywords in the long form / pdf files from a search perspective? Can we return the result in the search results if the short form content is not returned in the search results, and highlight it somehow in the search results to show that it is gated content? And clicking on its link takes the user to the Download page for that item?
@@ -166,6 +168,26 @@ https://mermaid.js.org/config/directives.html
 
 - Focus-visible / active handling on ToC nav items
 
+- Style "Share to Mastodon" modal in src/components/Social/Mastodon/client/index.ts
+
+- There's a pretty long delay when you push the Content Switcher to go from short to deep dive, what's causing it? It should be fast - maybe it's a prefetch issue, prefetch on page load
+
+- Suggestions on improving table layout for better visual experience
+
+- Cap callout length at 80% or 90% of the column so they're not longer than any text
+
+- Consider adding a trim outline to tables
+
+- Social share shouldn't appear on deep dive
+
+- Themepicker and search icon are too big in non-squished header. Logo too - the initial presentation should be smaller.
+
+- Search box in header should have blue outline, not highlight
+
+- Contact page Uppy file upload not displaying. Submit button is huge on Contact page.
+
+- Hero animation not loading on home page.
+
 ## List Component
 
 - Task list checked variant Markdown in dark theme is awkward, it has a dark shadow

src/components/Content/Layout/index.astro

@@ -28,6 +28,8 @@ export type Props = {
 }
 
 const { author, article, path, readingTime, section } = Astro.props
+
+const isDeepDive = section === 'Deep Dive Articles'
 ---
 
 <MarkdownLayout
@@ -80,24 +82,15 @@ const { author, article, path, readingTime, section } = Astro.props
     slot="after-content"
   >
     <WebMentions url={`https://www.webstackbuilders.com${path}`} />
-    <div class="flex flex-col gap-6">
-      <div class="flex flex-col sm:flex-row sm:justify-start sm:items-center gap-2">
-        <h2
-          class="text-lg font-semibold"
-          id="article-share-title"
-        >
-          Share this article
-        </h2>
-        <p class="text-content-active text-sm sm:text-right sm:ml-6">
-          Found this helpful? Share it with others who might benefit.
-        </p>
+    {!isDeepDive && (
+      <div class="flex flex-col gap-6">
+        <Shares
+          url={`https://www.webstackbuilders.com${path}`}
+          title={article.data.title}
+          description={`Read "${article.data.title}" on Webstack Builders`}
+        />
       </div>
-      <Shares
-        url={`https://www.webstackbuilders.com${path}`}
-        title={article.data.title}
-        description={`Read "${article.data.title}" on Webstack Builders`}
-      />
-    </div>
+    )}
   </section>
 
   {/** SLOT: related-content */}

src/content/articles/alert-fatigue-reduction-triage-actionable-alerts/index.mdx

@@ -41,10 +41,10 @@ Before you can fix alert noise, you need to know what you have. Most teams can't
 
 Export your alert definitions and firing history. Prometheus/Alertmanager stores this in rules files and the `ALERTS` metric. Datadog and PagerDuty have API endpoints for historical data. You want at least 90 days of history to capture weekly and monthly patterns.
 
-For each alert, capture: alert name, firing frequency over the last 90 days, action rate (percentage of firings that required human intervention), owning team, and whether a runbook exists. The action rate column is the most important and the hardest to populate—you'll need to cross-reference alert firings with incident tickets or on-call logs.
-
 <Newsletter />
 
+For each alert, capture: alert name, firing frequency over the last 90 days, action rate (percentage of firings that required human intervention), owning team, and whether a runbook exists. The action rate column is the most important and the hardest to populate—you'll need to cross-reference alert firings with incident tickets or on-call logs.
+
 ### Step 2: Classify by Action Rate
 
 Once you have the inventory, sort by action rate. This single metric tells you more about alert usefulness than anything else.
@@ -72,9 +72,23 @@ But an alert that fires constantly and gets ignored isn't a lesson learned—it'
 
 The talking points that work:
 
-- "This alert fired 47 times last quarter. How many of those were real problems?" (Usually: zero or one.)
-- "Would you notice if this alert stopped firing tomorrow?" (Usually: no.)
-- "If we delete this, what's the worst case?" (Usually: we'd notice the problem some other way, slightly later.)
+<List
+  variant="chevron-list"
+  items={[
+    {
+      lead: '"This alert fired 47 times last quarter. How many of those were real problems?"',
+      text: "(Usually: zero or one.)",
+    },
+    {
+      lead: '"Would you notice if this alert stopped firing tomorrow?"',
+      text: "(Usually: no.)",
+    },
+    {
+      lead: '"If we delete this, what\'s the worst case?"',
+      text: "(Usually: we'd notice the problem some other way, slightly later.)",
+    },
+  ]}
+/>
 
 <Callout type="danger">An alert with a 5% action rate is not "coverage"—it is noise that makes your 95% action-rate alerts harder to notice. Delete it or fix it.</Callout>
 
@@ -94,8 +108,6 @@ Alert counts grow naturally. Someone adds an alert during an incident, another g
 
 Establish a cadence: monthly reviews of which alerts fired most and what their action rates were, quarterly reviews of whether alerts still make sense given how your system has evolved. Every alert needs an owner—encode it in a label. Orphaned alerts are the first candidates for deletion.
 
-Counter the growth with a deletion budget: every quarter, each team must delete or significantly improve 10% of their alerts. It's aggressive enough to force real decisions, but sustainable enough that teams don't feel like they're dismantling their monitoring.
-
 <Download
   resource="alert-fatigue-reduction-triage-actionable-alerts"
   title="Download the Alert Fatigue Reduction Guide"
@@ -116,6 +128,8 @@ Counter the growth with a deletion budget: every quarter, each team must delete
   ]}
 />
 
+Counter the growth with a deletion budget: every quarter, each team must delete or significantly improve 10% of their alerts. It's aggressive enough to force real decisions, but sustainable enough that teams don't feel like they're dismantling their monitoring.
+
 ## The Results
 
 Remember the system I inherited? Forty-seven alerts per day, forty-four requiring no action—a 6% action rate. MTTA had drifted to 12 minutes. On-call satisfaction was 4/10.

src/content/articles/alert-fatigue-reduction-triage-actionable-alerts/pdf.mdx

@@ -9,12 +9,13 @@ tags: ["reliability-and-testing", "prometheus"]
 featured: true
 ---
 
-*[SLO]: Service Level Objective
-*[SLI]: Service Level Indicator
-*[MTTR]: Mean Time To Recovery
+*[DataDog]: Observability platform
 *[MTTA]: Mean Time To Acknowledge
-*[PagerDuty]: Incident management platform
+*[MTTR]: Mean Time To Recovery
 *[OpsGenie]: Incident alerting service
+*[PagerDuty]: Incident management platform
+*[SLI]: Service Level Indicator
+*[SLO]: Service Level Objective
 
 # Alert Fatigue: From 200 Alerts to 5 Pages
 

src/pages/contact/index.astro

@@ -3,7 +3,7 @@ import contactData from '@content/contact.json'
 import PageLayout from '@layouts/PageLayout.astro'
 import ContactPage from '@components/Pages/Contact/index.astro'
 
-const pageTitle = 'Contact Us'
+const pageTitle = 'Contact Me'
 const pageDescription = 'Connect with Webstack Builders to discuss your infrastructure needs, request an engagement proposal, or ask questions about platform engineering services.'
 const prefilledProjectType = Astro.url.searchParams.get('type') ?? ''
 ---

src/pages/deep-dive/[...slug].astro

@@ -24,12 +24,14 @@ const author = await getEntry(article.data.author)
 
 const articleBody = article.body ?? ''
 const readingTime = article.data.readingTime ?? getReadingTimeLabel(articleBody)
+// If section const value is changed, update the ContentLayout usage of the value
+const section = 'Deep Dive Articles'
 ---
 
 <ContentLayout
   author={author.data.name}
   article={article}
   path={`/deep-dive/${article.id}`}
-  section="Deep Dive Articles"
+  section={section}
   {...readingTime && { readingTime }}
 />

src/pages/services/index.astro

@@ -11,7 +11,7 @@ const services = allServices
   .filter(service => !service.data.isDraft)
   .sort((a, b) => a.data.order - b.data.order)
 
-const pageTitle = 'Our Services'
+const pageTitle = 'My Services'
 const pageDescription = 'Flexible options from full-time capacity to one-off assessments — all month-to-month with no long-term lock-in.'
 const path = '/services/'
 ---