Showing posts with label CMS. Show all posts
Showing posts with label CMS. Show all posts

Why So Many Info Tips Are Bad (and How to Make Them Better)

Mike's Notes

Another excellent article from Kate Kaplan that I can use to configure the CMS Engine (cms).

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The NN/g Newsletter
  • Home > Handbook > 

Last Updated

23/03/2026

Why So Many Info Tips Are Bad (and How to Make Them Better)

By: Kate Kaplan
The NN/g Newsletter: 23/01/2026

Kate Kaplan specializes in applying human-centered design and research practices to enterprise UX challenges. With over 15 years in UX, Kate has extensive experience in both conducting research and helping teams understand and apply user insights to overall business strategy.

Summary:

Information tips can clarify complex UIs, but they should not hide essential information, trigger redundant information, or disrupt the current workflow.

Information tips — those helpful little messages triggered by tapping or hovering over a question mark (?) or info (i) icon — can help users make faster decisions and increase the understandability of UI elements. But in practice, they’re often overused, misapplied, or bloated with unnecessary content. When info tips hide essential instructions or bury users in redundant explanations, they create confusion rather than clarity.

In This Article:

  • What Is an Info Tip?
  • Representing Info Tips in User Interfaces
  • The Problem with Info Tips
  • Pitfalls of Bad Info Tips
  • Pitfall #2: Hiding Critical, Task-Assistive Information
  • Pitfall #3: Interrupting the Task Flow

What Is an Info Tip?

An information (info) tip is a brief, contextual message designed to offer supplemental information about a specific interface element or step in a workflow.

It’s typically activated by hovering over or clicking on a small icon — often a lowercase i or a question mark — and is attached to a specific element within the interface (e.g., a text field, icon, button, label).

✅ An example of a useful info tip from the Ease Employment Benefits Portal: Clicking on the ? icon reveals a concise explanation about why specific data is collected and how it’s used.

Info tips can be revealed through two primary patterns:

  • Tooltips, which appear on mouse- or keyboard-hover gestures within desktop sites
  • Popup tips, which are similar to tooltips, but are triggered by clicking or tapping an element’s associated icon

Both types serve the same core purpose: providing extra context to those who need additional clarification or guidance without overwhelming the interface with text.

Representing Info Tips in User Interfaces

The i Icon: General Information

The encircled lowercase i icon is broadly understood to indicate optional, helpful information.

In our icon-related research, participants interpreted the i icon primarily as representing an option for “more information” and expected it to reveal supplemental information such as:

  • Definitions
  • Additional details or brief explanations
  • Promotional terms

This makes the i icon a good fit for general information or nice-to-know guidance, but not urgent or error-related content. It is a solid choice for representing info tips that support user understanding without interrupting flow.

The ? Icon: Help and Support

The encircled question-mark icon (?) is also used frequently to trigger info tips. In our research, it was more strongly associated with help and support than with general supplemental information.

People expected this icon to lead to:

  • FAQs
  • Customer-support contact information
  • Help content or tutorials

However, when placed directly next to a specific interface element (such as the form field label in the example above) the ? icon is also an effective trigger for contextual help about a specific element. The key is proximity: When the icon is close to what it refers to, users interpret the help as local and relevant, rather than global or generic.

The Problem with Info Tips

Unfortunately, info tips are often abused as band aids in the interface, used to:

  • Cram in explanations that should’ve been designed into the UI
  • Hide critical instructions in the name of a “clean” interface
  • Offload poor labeling or UX copywriting onto the user

Info tips are not a catch-all solution for decluttering the interface by sweeping essential content into a hidden layer. Nor should they be used to bury large amounts of information that disrupt users’ flow when revealed — what we call the “jump scare” scenario, where a user expects a quick tip but gets an entire modal or screen takeover instead.

But info tips aren’t inherently bad. When well-implemented, they offer concise, helpful, and contextual information that improves usability without cluttering the interface.

Well-crafted info tips can:

  • Clarify jargon or technical terms
  • Explain why specific data is requested
  • Guide users to locate needed information
  • Reassure users about data usage

However, a good rule of thumb is to assume that most users will never see the info tip. Those who do have extra motivation for seeking them out are confused, stuck, or need clarification or reassurance. That’s why info tips should deliver clear, in-the-moment guidance that directly supports the user's immediate task.

Pitfalls of Bad Info Tips

Info-tip misuse generally falls into three categories:

  • Wasting users’ time: Displaying obvious, redundant, or irrelevant information
  • Hiding critical information: Burying essential guidance or constraints most users will need upfront
  • Interrupting the task flow: Using intrusive patterns such as modals or overlays that take users away from the task at hand

Pitfall #1: Wasting Users’ Time

Every info-tip interaction — even just that one small click or hover — incurs a small but real interaction cost. Redundant or obvious tips waste users’ time and undermine trust.

Don’t use info tips for:

  1. Marketing fluff
  2. Restating visible content or instructions
  3. Reexplaining the obvious

Info-tip icons like the i or ? signal to users that something might be unclear or needs elaboration. When they instead reveal generic marketing fluff, users can feel misled and frustrated.

❌ Doodle.com: The info tip displays marketing information (The quickest way for two people to meet) to further sell the Schedule 1:1s feature.

Info tips also waste time when they restate what’s already perfectly clear in the interface. These tips give the illusion that additional explanation exists, but deliver only repetition.

❌ State.gov: Clicking the i icon next to the City of Birth form field triggers the message: Enter the city of your birth. These tips simply repeat what's already on the screen, making users feel like there's more to learn when there isn’t.

❌ In this example, a ? icon next to Paper Type appears promising. Users might expect guidance on how to choose between options like Satin, Gloss, or Uncoated. Instead, it produces an obvious, unhelpful message: Choose your preferred paper type from the options below.

Pitfall #2: Hiding Critical, Task-Assistive Information

Info tips should not be used to bury essential instructions, constraints, or legal disclaimers. Doing so turns important guidance into a game of hide-and-seek and could even be a deceptive pattern in some cases.

Avoid putting in info tips:

  • Constraints or rules
  • Form-field limitations (e.g., character limits)
  • Legal agreements or disclaimers
  • Complex instructions or explanations

Complex instructions that help users make decisions should be visible, not hidden in a tip. People need to reference these explanations while completing tasks, not break their flow or current view to search for guidance.

❌ U.S. Find a Grave Index: These complex explanations for proceeding with a simple task are too overwhelming for an info tip. If a task truly requires this much upfront guidance, the information should be integrated directly into the interface, where it’s always visible and easy to reference.

Instead of hiding complex instructions in an info tip, it’s more effective to display key information at the primary level of the interface. When users must weigh multiple options or make nuanced choices, surfacing that guidance upfront enables quick comparison without disrupting task flow.

✅ Microsoft Test and Learn: The design provides clear, inline explanations for the various output types (Result Grid, Trend Chart, and Category Impact) without requiring multiple clicks or hovers to reveal. This approach helps users compare outputs and quickly make an informed decision without having to hunt down hidden descriptions.

Additionally, any constraints, rules, or limitations for inputs should be displayed on the primary level.

❌ USPS.com: The form field hides character constraints within an info tip. This information should be displayed on the primary level. If the form fails due to unseen constraints, users are left frustrated and rework is required.

Pitfall #3: Interrupting the Task Flow

People expect clicking an information icon to reveal brief, helpful messages that they can reference in the context of their current workflow — not modal windows or full-page takeovers of walls of text.

Don’t surprise users with:

  • Overly complex, verbose content
  • Modals or overlays that block their task
  • New pages that take them away from the workflow

When possible, ensure that info tips are displayed inline or adjacent to the relevant element. Obscuring the current step or view of the interface makes it harder for users to connect the guidance with the task at hand.

❌ CapitalOne mobile site: Clicking the i icon next to About payment options replaces the current view with several explanations of the different amount options. While the information is useful, the pattern disconnects users from the content they need to reference while comparing options.

Modals and full-page overlays are jarring when used for info tips. Keeping the guidance adjacent to the element it supports allows users to maintain context and better understand the relevance of the information.

❌ GSA.gov (1 of 2): Users are likely to expect that clicking the i icon next to First & Last Day of Travel will reveal a brief definition of the term as defined in the travel policy.

❌ GSA.gov (2 of 2): Instead, clicking the icon triggers a darkened overlay that obscures the workflow and a surprising modal dialog at the top of the page.

Even more disruptive is launching an entirely new page from what appears to be a simple info-tip icon. This approach not only obscures the context but also forces users to abandon their task.

❌ Nextdoor.com (1 of 2): The site displays a ? icon next to the Sign-in code field label. Users are likely to expect that clicking the icon will display a brief description of what a signin code is or where to find it.

❌ Nextdoor.com (2 of 2): Instead, clicking the ? icon next to the Sign-in code field launches a new page containing a full explanation of two-step verification. The information about where to find the signin code is buried within the verbose content.

Conclusion: Use Info Tips Wisely

Info tips can enhance clarity when they offer just-in-time, supplemental guidance within the context of the current workflow.

Do:

  • Use info tips for supplemental content
  • Keep them short, contextual, and easy to dismiss
  • Represent them with familiar icons (i or ?)
  • Assume users who activate them need quick, in-the-moment guidance

Don’t:

  • Hide essential or frequently needed information
  • Use info tips as a crutch for poor labeling or dense layouts
  • Trigger popups or overlays that hijack the user’s focus or flow

When thoughtfully implemented, info tips reduce confusion and increase user confidence. But they should always serve the user’s goals, not the designer's desire to declutter at all costs.

Using Google Blogger API v3

Mike's Notes

On a Sandy Beach is a publication of Ajabbi Research.

Changes needed

Enable other people at Ajabbi Research to also contribute to On a Sandy Beach using the Workspaces for Research UI.

It looks very straightforward. This job will be done once the Workspaces for Research are available for researchers to use.

Preparation

Last year, all existing blog posts were reformatted.

New setup

The Pipi CMS Engine (cms) will format, store in a database, and export content to On a Sandy Beach, hosted on Google Blogger, using the Blogger API ver 3.

Either XML/Atom or JSON can be used.

Steps

  1. Import the existing blog posts into the CMS Engine via the Blogger API
  2. Reformat every post (see 4th resource link below)
  3. Store in the CMS database
  4. Render posts
  5. Export back to Blogger via the Blogger API.
  6. All future posts will be created by a human using a workspace, transferred to the CMS Engine, processed, and then published to Google Blogger.

Notes

Here are some initial notes taken from the Google Blogger API documentation and other sites, tweaked using Gemini and rewritten by Grammarly.

These notes will be presented using slides at tomorrow night's online Open Research Group meeting.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

09/02/2026

Using Google Blogger API v3

By: Mike Peters
On a Sandy Beach: 07/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Blogger supports manual import and export of blog content via the Blogger dashboard or the Blogger API. The export file format for both methods is Atom, an XML-based format that includes all posts and comments. 

Blogger API for Import/Export

Developers can use the Blogger API (v3 is the current version) to programmatically manage blog content. The export file generated via the manual process uses the same Atom format as the API's feed requests. 

Key Points for API Use

  • Authentication: All operations for private data (including import/export) require authentication, typically using OAuth 2.0.
  • Format: The API uses REST APIs and JSON for standard operations. The specific import/export functions rely on the raw XML/Atom format described in the developer guides.
  • Functionality: The API allows retrieving, creating, updating, and deleting posts, comments, and pages, enabling the creation of custom import/export tools. For example, you can use API clients for Python, Java, or Node.js to manage content programmatically.
  • Custom Import Scripts: Developers can write scripts (e.g., in PHP or Python) to import content from other sources into Blogger via the API, which involves parsing the source data and making POST requests to Blogger API endpoints. 

For detailed API documentation, refer to the Blogger API Developer site.

REST

The Blogger API is a RESTful interface provided by Google that allows developers to integrate Blogger content and functionality into their own applications. It enables programmatic access to resources such as blogs, posts, comments, pages, and users via HTTP requests and JSON. 

Key Features and Concepts

  • Resources: The API revolves around five core resource types:
    • Blogs: The central container for all content and metadata.
    • Posts: The primary published content items, meant to be timely.
    • Comments: User reactions to specific posts.
    • Pages: Static content (e.g., about me, contact info).
    • Users: Represents a non-anonymous person interacting with Blogger, as an author, admin, or reader.
  • Operations: Developers can perform various operations on these resources, including list, get, insert (create), update, patch, and delete.
  • Authentication:
    • Public Data: Requests for public data (e.g., retrieving a public blog post) only require an API key.
    • Private Data: Operations involving private user data (e.g., creating a post, editing a comment) must be authorised using OAuth 2.0 tokens.
  • API Version: The latest recommended version is Blogger API v3. Support for the older v2.0 API ended on September 30, 2024, so applications must be updated to continue functioning. 

How to Access the API

Google recommends using their client libraries, which handle much of the authorisation and request/response processing for you. Libraries are available for a variety of programming languages: 

  • Go
  • Java (get started with the Java client library)
  • JavaScript
  • .NET (install the Google APIs NuGet package)
  • Node.js
  • PHP
  • Python (install the client library using pip install google-api-python-client)
  • Ruby 

Alternatively, you can interact with the API directly using RESTful HTTP requests. The Google APIs Explorer tool lets you test API calls in your browser. 

  • Pipi API Engine (api)  using CFML
  • BoxLang API using BX

For full documentation and developer guides, visit the official Blogger API documentation site on Google for Developers. 

Older Data API (v1/v2) Format: Atom XML 

The previous versions of the Blogger API relied heavily on the Atom Publishing Protocol (AtomPub) and Google Data API feeds for managing blog content. The API used standard HTTP methods (GET, POST, PUT, DELETE) to transport Atom-formatted XML payloads. 

Important: Support for the v2.0 Google Data API ended on September 30th, 2024, so applications must use the latest version to continue functioning. 

Exporting and Accessing Feeds via XML

Blogger still uses Atom XML for blog syndication and content backup: 

  • Public Blog Feed: Every Blogger blog has a public Atom feed, typically at an address like yourblogname.blogspot.com/feeds/posts/default or://yourblogname.blogspot.com.
  • Content Backup: Users can back up their blog's posts and comments as a single .xml file from the Blogger dashboard.

    • Sign in to Blogger.
    • Select your blog.
    • Go to Settings > Manage Blog.
    • Click Back up content and Download XML file. 
    • This downloaded file is in a specific Atom format for import and export. 

REST in the Blogger API

The supported Blogger operations map directly to REST HTTP verbs, as described in Blogger API operations.

The specific format for Blogger API URIs are:

  • https://www.googleapis.com/blogger/v3/users/userId
  • https://www.googleapis.com/blogger/v3/users/self
  • https://www.googleapis.com/blogger/v3/users/userId/blogs
  • https://www.googleapis.com/blogger/v3/users/self/blogs
  • https://www.googleapis.com/blogger/v3/blogs/blogId
  • https://www.googleapis.com/blogger/v3/blogs/byurl
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/bypath
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/search
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments/commentId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages/pageId

The full explanation of the URIs used and the results for each supported operation in the API is summarised in the Blogger API Reference document.

Examples

List the blogs that the authenticated user has access rights to:

  • GET https://www.googleapis.com/blogger/v3/users/self/blogs?key=YOUR-API-KEY

Get the posts on the code.blogger.com blog, which has blog ID 3213900:

  • GET https://www.googleapis.com/blogger/v3/blogs/3213900?key=YOUR-API-KEY

REST from JavaScript

You can invoke the Blogger API from JavaScript using the callback query parameter and a callback function. When the browser loads the script, the callback function is executed, and the response is passed to it. This approach allows you to write rich applications that display Blogger data without requiring server-side code.

The following example retrieves a post from the code.blogger.com blog, after you replace YOUR-API-KEY with your API key.

<html>
  <head>
    <title>Blogger API Example</title>
  </head>
  <body>
    <div id="content"></div>
    <script>
      function handleResponse(response) {
        document.getElementById("content").innerHTML += "<h1>" + response.title + "</h1>" + response.content;
      }
    </script>
    <script     src="https://www.googleapis.com/blogger/v3/blogs/3213900/posts/8398240586497962757?callback=handleResponse&key=YOUR-API-KEY"></script>
  </body>
</html>

Data format

JSON (JavaScript Object Notation) is a common, language-independent data format that provides a simple text representation of arbitrary data structures. For more information, see json.org.

Blogger API operations

You can invoke a number of different methods on collections and resources in the Blogger API, as described in the following table.

Operation Description REST HTTP mappings
list Lists all resources within a collection. GET on a collection URI.
get Gets a specific resource. GET on a resource URI.
getByUrl Gets a resource, looking it up by URL. GET with the URL passed in as a parameter.
getByPath Gets a resource by looking it up by its path. GET with the Path passed in as a parameter.
listByUser Lists resources owned by a User. GET on a user owned collection.
search Search for resources, based on a query parameter. GET on a Search URL, with the query passed in as a parameter.
insert Create a resource in a collection. POST on a collection URI.
delete Deletes a resource. DELETE on a resource URI.
patch Update a resource, using Patch semantics. PATCH on a resource URI.
update Update a resource. PUT on a resource URI.

The table below shows which methods are supported by each resource type. All list and get operations on private blogs require authentication.

Resource Type Supported Methods
list get getByUrl getByPath listByUser search insert delete patch update
Blogs N Y Y N Y N N N N N
Posts Y Y N Y N Y Y Y Y Y
Comments Y Y N N N N N N N N
Pages Y Y N N N N N N N N
Users N Y N N N N N N N N

On a Sandy Beach, database version 2 is underway

Mike's Notes

In May, after manually reformatting every page and post of "On a Sandy Beach," I wrote.

"A blogging module needs to be built and added to Pipi 9 CMS. This could then be used to create blog posts using an underlying database, which could be modified to be more useful."

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

28/09/2025

On a Sandy Beach, database version 2 is underway

By: Mike Peters
On a Sandy Beach: 28/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The datamodel version 2 to support blogging is now being built. It is designed to support On a Sandy Beach. Yesterday, this Blogger post index was scraped and imported to initially populate the database.

In future, the blogging module will also support other blogs/newsletters, including the Ajabbi Research Monthly Newsletter, which begins next month in October on Substack.

The new database and blogger will be synced while other jobs are completed, including;

  • The tags need consolidating
  • The same tags will form a topic map and be used across Ajabbi
  • etc

Data Model version 1 (current)

  • Mike's Note
  • Resources
  • References
  • Repository links
  • Date Updated
  • Title
  • Page Url
  • Author
  • Source publication
  • Date Created
  • Author description
  • Body of the article
  • Tags
  • Comments

Data Model version 2 (now being built)

  • Title
  • Page Url
  • Site-wide Navigation
  • Site-wide Breadcrumb
  • Mike's Note
  • Author
  • Source publication
  • Date Created
  • Author description
  • Body of the article
  • References
  • Further Reading (replacing References)
  • Articles
  • See Also (cross-links to Ajabbi.com website pages, replacing Repository URL)
  • External Links (replacing Resources)
  • Keywords (replacing Tags)
  • Sharing
  • Updated
  • Forum (replacing Comments)

The internal control hierarchy of Pipi

Mike's Notes

I'm writing up some notes on current work driven by a teaching customer.

i18n

  • For Languages, a 3-letter string is added. e.g. eng for English and mri for Maori.
  • For Writing Scripts (alphabets), a 4-letter string is added for the script. e.g. latn for Latin.
  • For Locales, a 2-letter capitalised string is added. e.g. eng-GB for English spoken in the UK, eng-US for English spoken in the United States.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/04/2026

The internal control hierarchy of Pipi

By: Mike Peters
On a Sandy Beach: 02/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi is a self-organising system. Self-regulating constraints are operating on internal models. There are numerous internal hierarchies of control within Pipi, with properties that are inherited, including multi-inheritance.

Examples include;

  • Class packages: eg, namespace
  • Nested systems: eg, Account > Deployment > Deployment Object > Publication > Website > Workspace
  • Schema, ontologies, etc: eg, SNOMED, MovieLab
  • Design systems: eg, Account > Design System > Component > Design Token

Descriptions

Pipi Nest

Each account can only be in a single nest

  •  <pipi major version><pipi edition><account type>

Account

Every customer or user has an account, which is opened when they sign up.

A customer account has these properties;

  • One account type.
  • Contains one or more deployments.

Account types:

Each account type comes with different options. Enterprise has the most options, and Individual has the least.

  • DevOps (paid).
  • Enterprise (paid).
  • Individual (free).
  • Pipi (paid)
  • Researcher (paid)
  • SME (paid).
  • Temp (free)

Deployment

A deployment has these properties;

  • One deployment tenancy type.
  • One language.
  • Contains one or more deployment objects.
  • Can contain other deployments to create global settings for an account (Enterprise or DevOps).

Deployment tenancy types:

  • Exclusive tenancy
  • Shared tenancy
  • Multi-agent

Deployment Object

A deployment object has these properties;

  • One deployment object type

Deployment Object Types:

Used by the administrator through configuration settings.

  • Billing
  • Datasource
  • Folders
  • Permission
  • Plugin
  • Publication
  • Usage
  • Users and Groups
  • etc

    Publication

    All publications are created by the Content Management System (CMS).

    A publication has these properties;

    • One publication type.
    • It can be combined to build a whole system.
    Publication Types
    • Code
    • CSS
    • Database
    • Deployment
    • Email Newsletter
    • Notebook (Jupyter, etc)
    • PDF
    • Website
    • XML
    • etc

    Website

    A website has these properties;

    • One language. 
    • One website type.
    • Can be combined with other websites (to become a multi-language website).
    Website types
    • API (Endpoints)
    • Docs (like JavaDocs)
    • Help
    • Website (standard)
    • Wiki
    • Workspace (enterprise applications)
    • etc

    Example

    ASCI internal names are automatically provided by Pipi. A customer can choose different public names for URLs.

    An example control hierarchy;

    Pipi Nest > Account > Deployment > Deployment Object > Publication > Website > Workspace.

    Inheritance Internal name Examples
    Pipi Nest Pipin Nest:
    <pipi major version><pipi edition><account type>
    9ae
    Account <ASCI characters> ajabbi
    Deployment <Account>-<4 Digit>-<Locale> ajabbi-0001-eng-latn-uk
    Deployment Object <Deployment>-<ObjectType> ajabbi-0001-eng-latn-uk-pub
    Publication <Deployment Object>-<Publication Type> ajabbi-0001-eng-latn-uk-pub-cde
    ajabbi-0001-eng-latn-uk-pub-dta
    ajabbi-0001-eng-latn-uk-pub-wbs
    Website <Domain> wiki.example.com/eng-latn/
    blog.example.com/en-nz/
    en.example.com/uk/
    workspace.example.com/eng/

    UX Copy Sizes: Long, Short, and Micro

    Mike's Notes

    This definition of copy sizes from NNGroup is great. I am adding it to the Pipi Content Management System Engine (cms) internal schema.

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library > Subscriptions > NNGroup
    • Home > pipiWiki > Engines > CMS Engine
    • Home > Repository > Schema > NNGroup > UX Copy Sizes

    Last Updated

    30/05/2025

    UX Copy Sizes: Long, Short, and Micro

    By: Taylor Dykes
    NNGroup: 16/05/2025

    Summary:

    Better target user needs by understanding the three sizes of copy: long-form, short-form, and microcopy.

    Content terms like long-form, short-form, and microcopy are often used interchangeably, but are ill-defined and don’t mean the same thing. Knowing the differences between these types of copy and when and how to design them effectively will create written information that better supports user needs.

    Content vs. Copy: What’s the Difference?

    Before discussing different copy lengths, let’s define the difference between content and copy.

    • Content is everything that goes into a digital interface, regardless of media format.
    • Copy is a subcategory of content encompassing all the user-interface text written by the organization (not by the user).

    Diagram of digital content types—Copy, Audio, Video, User-generated, and Images—inside a large circle. Film, Print Media, and Television appear outside.


    Content is an all-encompassing term that includes copy and all the other elements of digital interfaces, such as videos, audio, and images.

    While it might be easy to distinguish between copy and content along media formats, it can be harder to distinguish between user-generated content and copy. Essentially, any content not designed by the publishing platform for that platform is user-generated content.

    In this definition, reviews, comments, and social posts all count as user-generated content. For example, an Amazon review is not copy because it is not created by the platform; instead, someone from outside — the user — created this content.

    Now that we’ve established the differences between copy and content, let’s review how copy length impacts the user experience.

    Long-Form Copy

    Long-form copy is 3 or more paragraphs that form a coherent and continuous unit.

    Writers should use long-form copy when additional detail, complexity, or context needs to be communicated to the user. When used correctly, the expanded word count allows writers to elaborate and include every detail users might need to know to accomplish their tasks.

    When people think of long-form copy, they often think of using it for blog posts, news, or educational articles. However, long-form copy can also be used for:

    • Policy descriptions
    • Product or technical documentation
    • Help and support pages
    • Reports or case studies
    • Product pages
    • About us pages
    • Proposals and grants

    Long-form content is becoming increasingly rare online, due to an ever-decreasing user attention span. But it will never go extinct, as it is the only copy type capable of delivering complex, detail-rich information on topics like multistep processes or troubleshooting advanced technical problems. In addition, users sometimes read for a more comprehensive understanding when the topic is significant to them (also called the commitment pattern). Giving bite-sized information in such a situation might create distrust.

    Another reason why long-form copy will likely always have a place online is its ability to aid search-engine optimization (SEO). Long-form copy can naturally hold many keywords, increase user engagement time, and assist internal linking, which help improve a site’s SEO.

    A multi paragraph page describing a hospital system's history of treating orthopedic conditions, what sets them apart, and their continued research.


    This landing page for a hospital system’s orthopedic offerings uses long-form copy to insert keywords (such as Maryland, Washington D.C., and Virginia) to increase its  ranking on the search-engine results page.

    Long-form copy doesn’t easily grab user attention. Unlike the other copy lengths, long-form copy requires time, attention, and mental energy to read thoroughly. This factor has caused long-form copy to become increasingly uncommon outside of articles.

    To help users quickly get the gist from long-form copy, good content designers and writers include short-form copy and microcopy to format, structure, and break up text. For example, the long-form copy might include microcopy like headings and subheadings, or short-form copy in an accordion’s answer to a frequently asked question. While long-form copy often comprises short-form and microcopy, it still reads as a cohesive unit to users.

    Short-Form Copy

    Short-form copy is 2–3 paragraphs focused on communicating one main idea.

    Short-form copy is used when a single idea or main point needs to be conveyed quickly, often in a way that grabs the user's attention. Writers use short-form copy to help users find information or quickly understand important ideas and messages that, if buried in long-form copy, might be missed.

    Some examples of short-form copy include:

    1. Onboarding tutorials
    2. Longer summaries
    3. Product descriptions
    4. Detailed mission statements

    Short-form copy has become the default way for communicating information to audiences. Since reading long-form copy requires too much user effort and attention, writers must consider how they might fit detailed information into a short-form format. Strategically breaking up text or organizing it innovatively can communicate a lot of information in scanning-friendly short-form copy.

    Page showing the different types of blood donation. Under the headings for two types is a single paragraph and short blurbs of information.


    The American Red Cross used short-form copy within cards to structure information that had likely been presented as a long-form article in the past.

    Short-form copy is the middle ground between long-form and microcopy; it’s short enough to scan but long enough to convey a whole idea. It won’t overwhelm users but may provide enough information to help them find something or make an informed decision, so they won’t need to read long-form copy on the same topic.

    However, UX writers should avoid prematurely defaulting to this happy medium. Even if users are more likely to scan or even read the short-form copy in its entirety, short-form copy won’t help them comprehend the information if the topic’s complexity is better suited for long-form.

    Short-form copy is also not a replacement for microcopy, even if it can create a more complete picture of a topic. Users want specific takeaways instantly, and that’s better suited for one-to-two sentence microcopy.

    Microcopy

    Microcopy is the smallest copy size: fewer than 3 sentences.

    Microcopy is used when a writer needs to quickly inform, influence, or encourage interaction for the user’s next step. Because of its size, microcopy is the copy that is most easily processed by users (through scanning or screen-reader voice-over). Good microcopy will prevent errors, encourage clicks, and educate users.

    Examples of microcopy include:

    1. Link and button labels
    2. Form-field instructions
    3. Input-control labels
    4. Page titles and meta descriptions
    5. Error messages
    6. Tooltips

    Microcopy often makes up most of the written information in the experience. Designers favor microcopy because it allows them to guide users efficiently without disrupting the flow of an interaction. Users appreciate microcopy because it’s easy to skim and scan as they navigate, helping them quickly understand what to do without being overwhelmed by large amounts of text.

    The homepage of IBM. There are taglines, buttons, link labels and summaries on this page.


    IBM.com:  Each text snippet in this screenshot is an example of microcopy.

    While much of the copy in an interface is microcopy, microcopy alone cannot create a complete experience. Microcopy needs other UI elements, images, videos, input controls, and a mix of short- and long-form to create an effective experience. Microcopy isn’t meant to be the primary focus of a website; it’s there to guide, support, and influence users toward the main content or action.

    Copy Sizes: In Brief

    Long-Form Copy

    Definition

    • 3+ paragraphs that form a coherent and continuous unit

    When to Use

    • For detailed or complex information
    • When users want more thorough knowledge
    • To aid SEO

    Examples

    • Policy descriptions
    • Product or technical documentation
    • Help and support pages
    • Reports or case studies
    • Product pages
    • About us pages
    • Proposals and grants 

    Short-Form Copy

    Definition

    • 2–3 paragraphs that communicate one main idea 

    When to Use

    • For succinctly communicating important and relatively detailed information
    • For breaking down long copy into scannable units

    Examples

    • Onboarding tutorials
    • Longer summaries
    • Product descriptions
    • Detailed mission statements

    Microcopy

    Definition

    • Fewer than 3 sentences

    When to Use

    • To guide users in an interface
    • To quickly communicate a critical point

    Examples

    • Link and button labels
    • Form field instructions
    • Input control labels
    • Page titles and meta descriptions
    • Error messages
    • Tooltips

    Conclusion

    There are so many types of text in digital interfaces that it’s easy to confuse their definitions or forget how they differ. Taking the time to learn or refresh the scopes of UX copy can help writers choose the best approach for the experiences they’re designing.