Industry
Part of How to build platform timelines that survive review
Platform timelines research: searching under old names
Platform timelines research often fails on names: how to build a name ledger, search each name in turn, and log what each search found or missed.
A feature is easiest to lose under its own name. Search for what a thing is called today and you find nothing from before the rename, then conclude it did not exist or that the sources are missing. The fix is a name ledger, built while you read.
What to take away
- Contemporary sources use contemporary names, so the name you know is often the wrong search term.
- A name ledger records every name a thing has carried and roughly when, built up as sources are read.
- Search under each name in turn, and log what each search found and what it did not.
- A documented absence is a finding. An undocumented one is a gap the next researcher has to re-open.
- Treat a rename announcement as reported, not as proof of an effective date.
Why the current name finds nothing
Platform timelines research meets a vocabulary problem before it meets a source problem. Feature names, the service name and the behaviors around it change constantly, and each change hides part of the record from a search.
Documentation, help pages and the platform rules operators publish are primary source material in the strict sense: made at the time, for a purpose other than describing the past. They carry the name in use then. The same vocabulary problem under social media slang applies to product names too.
Later writing behaves differently. Operator histories apply retroactive names, and retrospectives repeat the consensus story. A search that lands mainly on these layers finds the modern name and misses the original record.
| Source kind | The name it tends to carry | Its trap |
|---|---|---|
| Developer documentation and changelogs | The name in use at the time | Edited in place, so the live page shows the current name |
| Help and support pages | Contemporary names for things | Same in-place editing, and support pages lag features |
| Terms and policies | The name the operator uses now | The published date and the effective date differ |
| Coverage | How the thing was described when it was noticed | Later than the event, and copied by later coverage |
| Operator histories | Retroactive names | Tidy dates and silent omissions |
| Retrospectives | The consensus name | Consensus built by copying |
| Participant memory | Names as remembered now | Dates, and anything the participant did not see |
Source kinds and their traps
Source kind
- Developer docs
- Capability by version
- Help pages
- What users could do
- Terms
- Operator rights claimed
- App listings
- Client release dates
- Coverage
- Something was noticed
- Operator histories
- What operator remembers
- Retrospectives
- The consensus story
Establishes
- Developer docs
- Edited in place
- Help pages
- Edited in place
- Terms
- Effective date differs
- App listings
- Client is not service
- Coverage
- Later, inherited framing
- Operator histories
- Retroactive names
- Retrospectives
- Consensus by copying
Its trap
- Developer docs
- Help pages
- Terms
- App listings
- Coverage
- Operator histories
- Retrospectives
Building the name ledger
A name ledger lists, for each thing being researched, every name it has carried and roughly when. It is built up as sources are read. The ledger is itself a finding, and one that most timelines never record.
- Write today's name in the first row.
- Read the first source and note every name it uses for the thing, the service and the behavior.
- Add each new name with the source that used it and that source's own date.
- Record the capture date as well wherever a capture was used.
- Search under each name before reading further sources.
- Return to the ledger whenever a source uses a name you have not seen.
Keep it in a simple spreadsheet, such as Google Sheets, with one row per name. The ledger and the research log can sit in the same file.
A worked example: Twitter and X
A name ledger for Twitter can include X as a search term. Elon Musk announced a planned change from Twitter to X in posts on Twitter on July 23, 2023. Log that narrowly as an announcement, not as proof that the change took effect across every product on that date.
| Name | Source | Source's own date | Note |
|---|---|---|---|
| Platform documentation capture | Capture date recorded | The name in use when the capture was made | |
| X | Posts announcing a planned change | July 23, 2023 | Announcement only |
Use the date type "reported" for that dated statement. Then look for later captures of platform documentation or app listings before recording an effective date. The date types for timeline entries explain why the two are never the same field.
Searching under each name
Take each name in the ledger and search it against each source kind. Start with the Internet Archive's Wayback Machine: enter the page's exact address, inspect available captures around the date in question, and record the capture date as well as the page's own date.
Nearly all of the best sources are edited in place. A help article or terms of service document describes the current state and overwrites the previous one, usually with no visible version history. A page at the same address may carry a different name from the one you are searching.
The archive kinds described under internet culture archives capture documentation pages unevenly: popular pages often, developer pages sometimes, terms pages rarely.
Search the thing by what it did as well as by what it was called. A description can find a record that a name misses, and a description that works belongs in the ledger as one more way the thing was referred to.
For one platform, a starting set shows how different records carry a name. Meta for Developers' Instagram Platform Changelog records platform updates. Instagram's Terms of Use, marked effective January 4, 2022, record policy text. Apple's App Store version history for Instagram records listed app releases. Instagram's October 6, 2010, blog post "Introducing Instagram" records what the service said at the time. Note which name each one used.
Logging what each search found
For each name searched, record the source kind, the result and the date you last checked. Keep disagreements between sources as disagreements, with what each rests on.
- The name searched and the source kind it was searched in.
- What turned up, with the source's own date and any capture date.
- What did not turn up. A documented absence tells the next researcher where not to look again.
- The date the entry was last checked.
Where two sources disagree about a name, keep both rows. The disagreement is data: it shows which source kinds carried which name, and a later reader may settle it with a capture you did not find.
A log in this form can be handed to someone else, who can reproduce the check, add a name or dispute an entry without redoing the work. The method for dating what you saw picks up where the log leaves off.
Where renames stop helping
For the earliest period, the sources that carry contemporary names mostly do not exist. There was no documentation because no developers were building against the service, no terms because no lawyers, and no app listings because no app stores. Coverage was thin because the press was not looking.
The early social networks record is mostly participant memory and personal collections. The ledger still applies, but its output is full of documented absences. A researcher who is honest about that will produce fewer entries than one who is not, and each entry will be one a reader can check.
