Platform timelines examples: six traps and real entries

If you're looking for platform timelines examples, this page gives two kinds. The six patterns below are hypothetical, not documented events at named services; each shows how an entry can go wrong and how to label it defensibly. After them come real entries for named services, written with the labels the patterns call for.

In the six patterns, every example is a type, not an instance. No service is named, no date is real, and the names of features are placeholders. The point is to make recurring labeling problems in social media platform histories legible without presenting an undocumented event as fact. The real entries use only dates that a university timeline documents.

What to take away

Hypothetical pattern one: the staged rollout

A feature is released to one region, then to invited users elsewhere, then to everyone with a certain account type, then generally. The press notices at stage two. The company's own history page gives the date of stage four. Most timelines pick one of these and call it the launch.

A defensible entry records the stages it can document and marks the rest as unknown. "Available to some users from around this period; general availability documented by this date; earlier stages reported but not confirmed." It is longer than a single date, and it is the only version that is true for every reader.

Hypothetical pattern two: the retroactive name

A capability existed under one name, was renamed, and now goes by the second name. Accounts written after the rename use that second name for the entire history. So the timeline claims the thing existed years before anything with that name did.

Readers who search the second name in contemporary sources find nothing and conclude the timeline is wrong. It is not wrong; it is anachronistic, a different failure.

The fix is to date the name separately from the thing. "The capability, then called X, from this period; renamed Y at this later date." A changelog, where one survives, is the best source for both. It was written at the time by people who used the current name.

Hypothetical pattern three: the acquisition with five dates

One company buys another. There is the date the deal was agreed, the date it was announced, the date regulators cleared it, the date it closed, and the date the acquired product was folded into the buyer's. Any of these can be years apart from the others. A timeline that says "acquired in" has chosen one without saying which.

The entry should name the event it is dating. "Announced" and "closed" are different facts, and a reader who needs one cannot use the other. Where only one date is documented, say which it is; where the type is unknown, say that too.

Hypothetical pattern four: the feature that came back

A capability is removed, then reintroduced under a new name years later, and the reintroduction is reported as an innovation. Timelines built from coverage record two launches and no removal, because removals get little coverage and the second launch's coverage does not mention the first.

The fix requires a contemporary source for the removal, which is usually a complaint thread rather than an announcement. Users notice removals; companies do not announce them. The internet culture archives page describes where such threads survive and how far their dates can be trusted.

Hypothetical pattern five: the policy with two dates

A terms change is published on one date and takes effect on another, and the enforcement that people notice begins on a third. A timeline entry that says the policy "changed" on the publication date is technically right and practically misleading, because nothing changed for anyone that day.

Record all three where known. Where the entry has room for one, use the effective date and label it. The publication date is a fact about a document. The effective date is a fact about users. The enforcement date is a fact about behavior, and it is the hardest to document and most often what the reader wants.

Hypothetical pattern six: the version that was not a release

Software carries version numbers, and version numbering has conventions that vary by company and by era. A timeline that lists versions as events is listing labels, some of which corresponded to a public release, some to an internal build, and some to a renumbering that shipped nothing. The number is not the event.

Date the release, not the version, and treat a version number as a name that helps locate the release in a changelog. Where a version was never publicly released, it does not belong on a timeline of what users experienced, though it may belong on a timeline of what was built.

The pattern across the examples

The fixes are all labeling. None requires better sources than most timelines already have; they require saying what the source established. That is the rule the platform timelines page treats as the whole discipline.

Real entries, labeled

The Ego Media timeline published by King's College London is a good test bed, because it gives dates at different levels of precision and says what each one is. Written up with date types, a few of its entries look like this:

Each line names the event, gives the date at the precision the source supports, and says which kind of date it is. That is the whole method in practice.

Two cases with no fix

Some entries cannot be made right, only honest. A capability that a service had, undocumented, before anyone wrote about it has no date. It can only be entered as "present by" the date of the earliest surviving mention.

The stored-connection feature that the early social networks page treats as the defining capability was often added quietly to a system that had existed for years without it. So "the system launched" and "the system became a social network" are separate entries, and the second is usually undocumented.

The same applies to standing signals: a verification mark or a count whose meaning changed under an unannounced policy, described under online status and identity, has a history that no timeline can recover. The change was never dated by anyone who could see it.

Common questions

Should every entry really carry a date type?

Every entry that could be misread without one, which is most of them. The type costs a word and saves a correction.

What if my sources disagree?

Enter both, with what each rests on. An averaged date is a third claim nobody made.

Why are all the examples hypothetical?

Only the six patterns are. A real example of a trap would carry a real company's real dates for a mistake, and this site does not assert those without contemporary evidence, which for most of them is missing or contested. The real entries above use dates a published university timeline documents, at the precision it gives.