This article exists as a living reference for how we structure AppSheet content on the OCM Asesorias blog. It intentionally uses a wide range of markdown features so we can validate typography, spacing, and the overall reading experience.

If a future change ever makes this page look strange, it’s a strong signal that our layout or markdown pipeline needs another pass. We’ll keep this page updated as we evolve the design.

1. Headings and hierarchy

Clear hierarchy keeps long technical content skimmable. We typically follow this structure:

1.1 Article-level outline

H1 – Page title (comes from the frontmatter, not the markdown body).
H2 – Major sections such as Architecture, Performance, or Deployment.
H3 – Subsections for patterns, checklists, or concrete examples.

1.2 Example subsection

When to create a new H2

The topic changes enough that you would bookmark it separately.
You can describe the section in a short, clear sentence.
You expect readers to jump directly to it from search or internal links.

When an H3 is enough

You’re still inside a single flow (for example, “Sync Optimization”).
You just need to split concepts, steps, or cases within that flow.

2. Inline text styles

We keep inline styling simple and purposeful:

Bold draws attention to outcomes, metrics, or decisions.
Italic adds emphasis to a single word or short phrase.
~~Strikethrough~~ is reserved for deprecated patterns or anti-patterns.
inline code is used for AppSheet expressions, column names, or configuration keys.

We also support footnotes for deeper explanations that would otherwise distract from the main narrative.[^footnote-example]

[^footnote-example]: In real articles we use footnotes sparingly—typically for version caveats, experimental features, or links to long-form docs.

3. Lists and task lists

Lists make troubleshooting and implementation steps easier to follow.

3.1 Bulleted lists

We use bulleted lists for unordered information such as options, constraints, or symptoms:

Symptoms of a slow AppSheet backend.
Columns that are good candidates for virtual columns.
Views that you might want to split into separate slices.

3.2 Numbered steps

We use numbered lists for processes that must be followed in order:

Capture the current baseline (sync times, error rate, key user flows).
Apply a single optimization such as virtual column refactoring.
Deploy to a limited test group.
Re-measure and compare results.

3.3 Task lists (GFM)

When tracking a small checklist in an article, we can rely on GitHub-flavoured task lists:

Explain inline text styles.
Demonstrate bulleted and numbered lists.
Show task list rendering.
Hook this article to a real AppSheet sample app.

4. Callouts and blockquotes

Blockquotes let us highlight tips, warnings, or mental models without adding new components. We follow a consistent pattern where a short label appears in bold at the start of the quote:

Pro tip: When an AppSheet view feels “slow” to users, start by profiling sync times rather than rewriting expressions. Often the real issue is a heavy initial sync caused by overly broad slices.

Warning: Avoid adding virtual columns for every small transformation. Each virtual column recalculates on sync, so a large table with many heavy expressions can quickly become a bottleneck.

Mental model: Treat your AppSheet backend as a set of read-optimized, well-indexed views rather than a raw mirror of your transactional tables.

5. Tables

Tables are ideal for comparing patterns or summarizing decision rules concisely.

Pattern	When to use it	Example metric to watch
Slice-based filtering	Different cohorts see different subsets of the data	Active rows per slice
Virtual column pre-computation	Expensive expressions reused across many rows/views	Calculation time per sync
Security filters	Restrict data at the source, not in the UI	Rows returned per user
Summary tables / rollups	Aggregations needed across multiple dashboards	Refresh frequency vs. staleness

We avoid overly wide tables; three or four columns usually keep things legible on both desktop and mobile.

6. Code and expression blocks

We treat AppSheet expressions and configuration snippets as code. This keeps them visually separate from the narrative and easier to copy.

6.1 Simple expression

IF(
  [Status] = "New",
  "Pending Review",
  [Status]
)

6.2 Filter using a slice-like condition

AND(
  [Is Active?] = TRUE,
  [Created At] >= (TODAY() - 30),
  IN([Owner Email], LIST(USEREMAIL(), "ops@your-team.com"))
)

6.3 Pseudo-configuration sample

sync:
  mode: "background"
  prioritize_views:
    - "Daily Overview"
    - "Exceptions Dashboard"
  max_rows_per_table: 2000
logging:
  enabled: true
  channel: "Analytics"

Code blocks should always be copy-pasteable as-is; avoid including commentary inside the snippet itself.

7. Mixed content and images

Sometimes we need to blend multiple structures inside a single section: narrative, list, code, and an illustration.

Start with a short paragraph that sets context.
Follow with a compact list of actions or checks.
Add a small code or expression block if there’s something concrete to copy.
Optionally include a diagram or screenshot for visual learners.

For example:

Simple dashboard layout showing cards for sync health, top errors, and slowest views

Note: In production articles we prefer real screenshots of AppSheet views, annotated lightly, rather than abstract diagrams.

8. Putting it all together

When we write production AppSheet articles, this is the pattern we aim for:

Sharp title and lede that clearly states who the article is for and what outcome they get.
Short “What you’ll learn” summary with 3–5 bullets, so readers can quickly decide whether to commit 5–10 minutes.
Well-structured body using the heading, list, and callout patterns shown above.
Actionable CTAs at the end that match the reader’s intent: subscribe for updates, or schedule a consultation if they want hands-on help.

The rest of the blog should feel consistent with this article. If a layout or markdown change makes this page look off, it’s a good sign we should revisit the design before shipping it to paying clients and busy AppSheet builders.

AppSheet Insights

Get the latest AppSheet tactics