posts

From IndieWeb
(Redirected from implied post types)

A post or posts may refer to individual pieces of content published on an indieweb site such as notes, articles, responses, or the act of creating the aforementioned content (present tense), or Posts about the IndieWeb.

In list form:

Why

Why you should publish posts on your own site: see why.

How

How to publish a post.

Types of Posts

Experience has shown that there are different types of posts on IndieWeb sites. Publishing and display interfaces for these different types vary. Below are a few types of posts that IndieWeb community members are currently publishing.

Sometimes these types are referred to as post kinds instead. WordPress is an example of an CMS with a difference between types and kinds, where post kinds match with the IndieWeb post types. See the Post Kinds Plugin for more information.

Roughly ordered by apparent/anecdotal indieweb posting frequency across different sites / implementations (Most of these are also cross-linked from Category:PostType):


Being explored, looking for markup patterns to standardize, worthy of consideration for post type discovery:


Posted by only three indieweb sites, analyze markup for patterns to document as "How to"

Posted by only a couple of indieweb sites so far

Posted by only one indieweb site so far:

Posts of various types may also be implicit mentions of other posts by linking to them, but the difference only matters to the receiver — i.e. there is no dedicated UI for people to publish a “mention” of something.

Indieweb community members are working on publishing these real soon now, or there exists related prior art:

Merely gleams in various eyes:

Inferring Post Type

It is sometimes necessary to detect what type of post a piece of content belongs to. Out of this need Post Type Discovery has been created. It outlines an algorithm where a type can be assigned to a post based on what sort of parsed properties it contains.

New Post Types

In general, we should avoid creating new post types.

Both individually and as a community. Simpler is better and all that.

The key is whenever you think you have something new to post, try posting it as your simplest existing post type, which are likely just notes, maybe with tags, e.g. what User:Waterpigs.co.uk does with steps, and User:Sandeep.io does with tags as well. Then document here on the wiki why/how that doesn't work if you run into problems.

One reason why re-using an existing post type might "not work" is that you really want to present it differently, provide a specific UX for a particular type of posts differently from any existing post type. This is the *primary* reason that should drive any desire to create new post types.

If there's no reason to present a different UX, then you likely shouldn't be thinking about a new post type.

And even if you do want to present a different UX, consider simply using the existence of specific properties (e.g. in-reply-to for replies) to drive the presentation of a different UX, rather than creating a new post type.

If you get that far, step one, document real world examples of such new UX (even from silos) with screenshots/mockups embedded on this wiki.

After you've documented existing UX of a post type, see if you can find something similar in ActivityStreams's similar concept of "object types", and thus re-use their name/terminology.

Related Sessions

Related IndieWebCamp discussion sessions:

Pieces of a Post

At a minimum, indieweb posts should have:

  • permalink URL
  • contents of the post
  • date published of the post

and likely:

  • author of the post - even if it's self-evident from the domain.

and perhaps:

  • avatar of the author of the post

All marked up with h-entry+h-card naturally.

Additional pieces

Additional information about the post:

  • date updated
  • name - (AKA "title") of a post (articles typically have titles)
  • location - (AKA "geo") that the post was created or published from, e.g. tweet location. This can be different from the location that a post is about, e.g. photos of a location, Instagram locations are "locations" that the photos are of, Wikipedia uses the geo microformat on pages to indicate location information about the subject of the page, even checkins (which are usually posted at the location, but sometimes after e.g. postsq).
  • changes - specifically, notable content updates since original publishing, ideally marked up with <ins> and <del> and then styled to be apparent.
  • using - tool or application that was used to author / publish the post.

link-preview for the content referenced by a reply/bookmark/like/...

Footer sections

Footer sections. Posts sometimes have footers with links, references etc. Here are few known footer sections with a real-world indieweb example in the wild of each.

  • More information or explanations about things in the post
    • Glossary — definitions of jargon, rare, or unusual terms or phrases used in the post
    • Footnotes — a mix of explanations and or citations, perhaps a superset of References below.
  • Similar clusters of links to one or more posts related to the current post
    • Previously - links to previous posts by the author on the same or similar subjects. E.g. [1]
    • References - explicit list of citations supporting the post, from inline hyperlinks in the post, and/or [number] references inline in post text.
    • Further Reading - links to author chosen articles that may provide additional detail or depth of information about specific topics in the post [2] [3]
    • Related Reading - typically algorithmically (though sometimes manually) chosen short list of posts usually by the same author that may be "of interest" to the reader of the current post, often more tangentially related rather than directly relevant like further posts. [4]
    • Elsewhere - a list of links to POSSE syndicated copies of the post on other services. E.g. [5]
    • Elsewhere of this Translation - a list of links to POSSE syndicated copies of a post which is a translation of another post.
    • Translations - links to translations of the post. E.g. [6]
  • Responses to the post
    • comments - a list of comments (in time sequence order) about or replying to the post. E.g. [7]
    • Referencing Articles / Mentions - other discussions / articles spawned as a result of (after) the post, or other related reading that cites the post. A that reader already took the time to read it and have the post in mind as context, may want to read articles that build upon it. E.g.: [8], [9]
    • likes/favorites - primarily on silos but capturing here as something that indieweb community members have expressed an interest in implementing on their own posts [10]
  • Automatically generated navigation by topic or time
  • ... have a different section in the footer of your posts? Add it here with a link to a real world example.


Marking up these footer links.

  • Footer section links should be marked up with h-cite+h-card by default (see exceptions below)
  • Exception: maybe "local only" comments can be just h-entry+h-card, while normal comments via Webmention are mere copies of their originals and thus should be marked up with h-cite. See comments for details.
  • Exception: some clusters of reactions also have more specific suggested markup, see their pages for guidance

Inline and other references

Some post to other post or page references are inline in a post or elsewhere but not in a separate footer per se.

Posting practices

IndieWeb community members' thoughts on some of the details of how they post and why:

Post design

There's many ways to style and display posts, on their own on permalink pages, as part of a stream (e.g. a home page or feed), and in a collection in an archive.

Here are some posts about post display design:

Testing

Here are some tools for testing indieweb posts:

Differentiation in feeds?

Should post kinds be differentiated in RSS (etc.) feeds, which may of course include posts of multiple different kinds? As XML-based formats, both RSS and Atom would be suitable candidates for the inclusion of a namespace for the purpose of identifying the kind of an item, and this could provide valuable features to feed consumers (e.g. facilitating easy filtering). I know of course that the same functionality ought to be able to possible via parsing for relevant h- classes, but that's a heavyweight solution to what feels like it ought to be a simple problem (and isn't compatible with many existing XML manipulation tools, which are often geared towards simpler e.g. XPath parsing). I know that RSS isn't "hip", but it's not going anywhere... - Dan Q

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=posts&oldid=96412#Inferring_post_kinds_from_properties"