Platform timelines updates: how to date what you saw

Two people can describe the same website on the same afternoon, disagree completely about what it looks like and what it can do, and both be telling the truth. That fact breaks most attempts to write platform history, and it is the first thing to settle when you document platform timelines updates.

What to take away

Why one service is many services

A large platform is not one artifact that changes on a date. Several mechanisms pull it apart at any given moment:

The accurate unit of platform history is not "the site changed on this date" but "this change reached this population by this date, as observed here".

Facebook, Instagram, YouTube, TikTok and X are the ordinary cases here. Each has to be dated surface by surface — desktop, mobile app, mobile web — and population by population, rather than as one site that changed.

The announcement is not the change

Announcements are written by the party with an interest in how the change is received. They describe intent, they are sometimes edited after publication without a note, and they frequently describe a limited test in the language of a launch. They are excellent evidence of what a company said and poor evidence of what users experienced.

Facebook's Reactions are a worked example. The company officially rolled them out worldwide on February 24, 2016, six reactions in all: Like, Love, Haha, Wow, Sad and Angry. If you first saw them on another day, that is not a contradiction — February 24, 2016 is the worldwide rollout, and your own note dates the day your account received them.

Keep at least four dates apart, because collapsing them is the most common error in this kind of writing:

A timeline that shows one column of dates has already thrown away the information that makes it checkable.

Documenting a change you saw yourself

First-hand observation is the strongest material for recent platform history, and it is worthless if not recorded properly. When you notice something, write the date in ISO 8601 form (YYYY-MM-DD) with your time zone, then the platform surface (web, which app, which version if visible), the operating system, and your country.

Add whether you were logged in, roughly how old the account is, and a full screenshot rather than a crop. The crop removes the interface details that let someone else identify the build.

Then write down what you saw instead of interpreting it. "The reshare button no longer shows a count" is an observation. "They removed public counts" is a conclusion that needs many more observations from many more accounts.

Two things make the note checkable later. A screen recording that keeps the system clock in frame dates a behavior that a still image can only assert, and a hash of the file — SHA-256 is the usual choice — taken when you first store it lets anyone confirm the file has not been altered since.

Reversals deserve their own entries

Features come back. Interfaces get rolled back after complaint. A setting disappears, reappears in a different menu, and is later removed for good. If a timeline overwrites the old entry each time, the pattern becomes invisible and the page starts to look untrustworthy to anyone who remembers otherwise.

Record a reversal as a new event that points at the earlier one, and leave the earlier one intact. The same rule applies to your own corrections: keep the previous value, the new value and the reason, so a reader can see the difference between a page that was wrong and a platform that changed.

What you can state without hedging

Some claims survive all of this. If you captured the page, you can state that a service's published terms said a specific thing on a date, and web archiving services such as the Internet Archive's Wayback Machine and archive.today exist to make that checkable by someone who was not there.

A given interface existed if you have a dated screenshot with enough context. A change was announced, if the announcement is archived. You personally could not find a feature on a stated setup on a stated day.

What does not survive is the sentence people most want to write: that on a certain date, everyone's experience of the site changed. Almost nobody's experience of a large service changes on a date, and a history written as though it did will be contradicted by the first reader who was there.

Where the corroborating captures come from, and what each kind of collection can and cannot support, is set out in the internet culture archives platforms comparison, which weighs migration against emulation as the two available repairs. For structural background on how a service's design shapes what happens on it, see the working brief on platform timelines platforms, which sets out forwarding, attribution, persistence, identity and ordering.

Common questions

Isn't a company's own changelog authoritative?

It is authoritative about the company's account of itself, which is worth having and worth citing as exactly that. It is not a record of what users could do, and it usually omits tests, quiet removals and regional gaps.

In practice the company's own account turns up in three places: the release notes attached to each app store update, the help centre article for the feature, and any developer or newsroom post about it. Note which one you used and the day you read it, because all three are edited in place.

Someone remembers a feature I can find no trace of. Are they wrong?

Not necessarily. Experiments and regional builds mean unrecorded features are ordinary, not exotic. Record the recollection as a recollection, note that you could not corroborate it, and leave it open.

How precise should a platform history be?

As precise as the evidence and no more. Writing a day where the evidence supports a season is false precision, and the reader cannot tell a documented day from a filled column. A range with a stated basis is more useful than a single date with none, and it will not have to be quietly retracted later.