A note is a post that is typically short, plain text, and written/posted quickly.
Displaying an individual note (tweet/status update) on its own permalink page is a common pattern.
- Barnaby Walters has a collection of annotated screenshots here, including examples from:
- Facebook (Web UI)
- Twitter (Web, Mac App)
There are certain UI elements which are common to most implementations. These include:
- Profile photo (often with rounded corners)
- Full Name (often emboldened)
- Auto–linked URLs, usernames and #tags
- Dates (sometimes relative, almost always the option to see real date)
Autolinking and embedding
Various sites/solutions auto-link and/or auto-embed URLs and other linkable things in notes.
- auto-link URLs directly
- even better: if the URL is to a known person, use their name as the link text and perhaps include a small icon of their face before their name.
- auto-link @-names to Twitter profiles
- even better: auto-link @-names to individual's indieweb sites and show their full name instead of Twitter handle. Obviously keep @-names in note content when POSSEing to Twitter.
- auto-embed GIF/JPG/PNG URLs with <img src>, hyperlinked to the original
- auto-embed MOV/OGV URLs with <video src>, hyperlinked to the original
- auto-embed Youtube URLs with the equivalent Youtube <iframe src> embed (algorithmically convertible)
You can use the CASSIS
auto_link function to do all the above (except the "even better" enhancements) automatically to a piece of plain text.
- auto-linking URLs through URLs shorteners (please don't break the web)
- cluttering image/video embeds with extra text (e.g. name/title from destination)
Compare for example:
Less Common Aspects
- username/nickname - as well as the full name, there’s often a silo-specific nickname/alias
- URL to their indieweb home page
- posting application/tool
- posting location - aka geo
Location (AKA Geo) of notes is somewhat rare and not very well done. Nonetheless, there are questions, use-cases, and examples.
- What's the point of posting a note/tweet with location information? (one that's not a checkin)
- What does it do for me (as the user posting it)?
- And what does it do for people reading my notes/tweets?
- Why is it interesting/useful to anyone?
Related but different: checkins, events, photos with location.
Use-cases for posting geo / post location information with notes:
- location specific service provider help
- meetup in non-home city - specifically expressing being in the same (non-home) city
- explicit I'm not home - indication of being in a non-home city
- "help!" if you're in trouble - geolocating it would be useful
- uncommon but urgent use-case.
- though in a "help" situation it's faster to simply *type* where you are etc. than wait for geo location information to come-up, confirm, etc.
- because geo information is so often "invisible" - it requires extra UI steps to make it work = extra time = not going to do it in an emergency
- worse - devices get geo information wrong all the time - and having it be wrong in an emergency would be particularly bad
- basically, lack of trust for device geo = not going to use it in a help situation
- if you don't know where you are and need help, then some (even possibly error-prone) geo information may be better than nothing
- but now we're talking quite a bit of an edge case.
- artificial precision - Twitter in particular links names of cities like "Paris, Paris" [sic] to a Google map with lat/long of 8 decimal digits precision!
Past Example when Twitter used to show a map on tweet permalinks of the location:
Typical silo notes implementations display most whitespace written in their posting interfaces. E.g.
Facebook status updates are notes (no post title) that preserve sequential space characters and line breaks.
Google+ posts are similarly just notes (no post title) that also preserve sequential space characters and line breaks.
Twitter now has multiple implementations that preserve white space characters in presentation:
- Twitter.com (as of ~2013-03-13)
- e.g. https://twitter.com/hotdogsladies/status/4809602603
- based on a test ( Tantek 18:13, 15 April 2013 (PDT) ), when posting to Twitter.com, Twitter's server
- preserves simple linebreaks
- preserves multiple spaces between words
- preserves spaces at the start of a line
- but collapses multiple linebreaks into a maximum of one blank line between lines.
- Twitter iOS client (previously: Tweetie)
Encoding - analysis of the above tweet:
- View Source: The linebreaks are encoded as
character entitites, without any visible line breaks in the code.
- View Selection Source (FF) and Inspect Element (FF, Safari): The linebreaks appear to be simple "carriage return" characters (
\r, ASCII 13), showing visible line breaks in the code.
- In either case, the visual presentation of the whitespace characters is achieved using CSS:
Due to the expectations set by dominant silo implementations, any note authoring/composing UI should preserve line-breaks, blank lines, and multiple space characters when writing/authoring, displaying/presenting, and ideally, when syndicating (POSSE).
Especially now that even Twitter has set consistent expectations from its posting UI, there's a strong case that a user switching from Twitter to an indieweb note posting UI would expect whitespace and linebreaks to "just work".
Obviously indieweb implementations would have to preserve white-space in posting UI to storage to display round-trips. Then in the presentation they could either:
- a. <br/> substitutions - Indieweb implementations could (are any already?) automatically insert
<br> tags for linebreak whitespaces (similarly to auto-linking URLs in notes). But this wouldn't handle multiple sequential space characters.
- b. white-space:pre-wrap - Alternatively (preferably) indieweb implementations should use
white-space:pre-wrap similar to how Twitter does.
Thus b. white-space:pre-wrap seems to be the logical choice for indieweb implementations.
- tantek.com Falcon notes as of 2013-105 (retroactively supported in storage & styling back to 2013-001) preserve whitespace, present it, and POSSE it to Twitter which then preserves the whitespace when copying it to Facebook, e.g.:
There are some interesting use cases to preserving white space, in particular line breaks.
Besides the obvious use-cases of poetry, paragraphs, and lists, there is for example, chess games (and moves!)
This leads us to the use case of indieweb spectator correspondence chess. That is, two players could play a chess game just by posting moves on their own indieweb sites as replies to each others' moves.
Perhaps chess moves (and resulting board state) could be posted as a special kind of note post type (a game-move or game-turn?) and then POSSE'd to Twitter with whitespace intact.
If the move is response to a move on another indiewebsite, then in addition to using webmention for move completion notification, the POSSE'd response move could also indicate with Twitter's in-reply-to-status-id the POSSE'd tweet of the previous move. See how to POSSE a comment/in-reply-to/rel-syndication for details of how to do this.
Such public posting of moves would also allow for anyone to jump in and attempt to play a next move by posting a reply move. The player of the previous move would then receive multiple webmentions and could decided which move (or both) to reply to in turn.
Since notes are such a ubiquitous content posting type (Thanks to Twitter), it's no surprise that subtypes of notes are evolving for representing additional structure or types of information. Let's document them as they emerge.
Health Fitness Tracking
Tags: fitbit, pedometer, physical activity
Syntax: number-of-steps #steps anything-extra
Syntax: number #bmi
picoformats are the broader effort to briefly and readably structure information in pure/plain text form.
When displaying a note, it is customary to just display the note content and no explicit note title.
While this is fairly straightforward for a site itself (which often has its own post type information, perhaps even as an additional class name on the h-entry like
h-as-note), for sites that display h-entrys from elsewhere it helps to have an algorithm to determining when is a note a note and should thus be displayed as such.
Note Type Algorithm
Summary: if the name of the h-entry is essentially the content of the entry, it's a note, just display the content (and no explicit name/title).
Algorithm for a parsed h-entry
- set the tname to trim(name)
- set the tcontent to trim(content)
- if the tname == tcontent, then it's a note, return.
- if the tname ends with an ellipsis ("..." or "…") then
- drop the ellipsis character
- if the tname is a prefix of tcontent, then it's a note, return
- otherwise it's not a note