Keeping Media Current When Screens Change

Monday, 08:40, at Greywater Utilities. The mail system was upgraded over the weekend, as announced. The upgrade moved the signature settings from a menu on the left to a gear icon on the right. By ten o'clock Ingrid on the desk has nine tickets, and all nine say some version of the same thing: "The video shows a button I don't have." The video is "Set up your e-mail signature", recorded in the spring, and it shows the old menu with complete confidence. The text steps under it are also wrong, and Ingrid fixes those in four minutes. The video takes until Thursday. That is because first somebody has to find out which of the other thirty clips in the knowledge base also show the mail system. Nobody has a list.

The expiry problem is that every picture and every video is a snapshot of a screen on a particular day. Screens change on a schedule set by somebody else. Media, in this series, means the photographs, screenshots and clips that sit beside articles in the knowledge base. Media is current when it still matches the screen the reader has in front of them. Keeping it current is not a documentation day. It is a short list, a naming habit, a line on the change record and a text fallback. This article is part of our Visual & Video Guides series, which covers choosing, making and keeping the pictures and videos in a help desk's knowledge base.

This article covers the expiry problem and why a wrong picture is worse than none, then which media expire fastest, in a table. Next come naming and versioning, the review trigger when a system changes, and the sweep for everything that changes without a record. We cover the text fallback that outlives the video, then retiring, re-recording or patching. We finish with the media register, a short war story, and the register template to copy.

The Expiry Problem

A video is a promise that the screen still looks like that, and a screenshot is the same promise in a single frame. Text describes; a picture asserts. When the screen changes, a text step that says "open the signature settings from the menu on the left" is slightly wrong. The reader, finding no such menu, looks around and usually finds the gear. A picture of the old menu is confidently wrong. The reader trusts the picture more than the words, because it is a photograph of the thing. So they look for the old menu, do not find it, and raise a ticket saying the video shows a button they do not have. A wrong picture does more harm than no picture. It does not just fail to help; it sends the reader to a place that no longer exists.

Screens change for reasons the knowledge base never hears about. Vendor-hosted systems update themselves on the vendor's schedule, sometimes with a note and sometimes with a new icon on a Tuesday. In-house systems change when the desk upgrades them, which is announced, and when a theme, a logo or a browser changes, which usually is not. Physical devices change when procurement buys the next model, and rooms change when facilities refits the panel. None of these events checks the knowledge base first. A video does not know it is out of date; it will show the old menu with total confidence until the server is switched off.

The loud failure is the "button I don't have" ticket, and the quiet one is worse. The reader who hits a wrong picture concludes that the knowledge base is wrong, not that one image is, and stops using it. They do not raise a ticket about that. They raise tickets about everything else, from then on, because the self-service route lost their trust on one screenshot. The general case, articles that nobody maintains, belongs to the knowledge base fundamentals series. This article is about the part of the article that goes wrong fastest and most visibly.

Which Media Expire Fastest

Not all media expire at the same rate, and the rate should decide how much of each kind the desk makes. The table below runs from the most fragile to the most durable. The pattern is simple. Anything that shows a screen expires when the screen changes, and screens change on somebody else's schedule. Anything that shows a physical thing expires when the thing is replaced, which is rare and usually known in advance.

Read the table before choosing a format, not after. The first row is the reason the format decision earlier in this series treats video as the format of last resort for anything on a screen. The last three rows are the reason phone photographs are the cheapest visual guides a desk can make. A photograph of a lever is good until the printer is replaced. A video of a vendor's web portal is good until the vendor has a meeting.

Naming and Versioning

Every media file carries the task in its name and a version number at the end. The number goes up every time the file is re-made: "set-up-email-signature-v1" is replaced by "set-up-email-signature-v2", not overwritten. The article points at exactly one version. The reason not to overwrite is that an overwritten file cannot be told from the one it replaced. So nobody can say which clip the article showed last month when the ticket was raised. A cached copy of the old one may go on being served to some readers for a while, and the change itself leaves no trace. A new version with a new number is a deliberate act with a date, and the register records it.

Use a version number, not a date, in the file name. A date in the name tells you when a clip was made, which is interesting to nobody. The version tells you which clip the article currently uses, which is the question every reviewer asks. The date goes in the register, in the "last checked" column, where it does the job of saying how stale the row might be. Both are needed, and they live in different places. The naming convention itself, task words, lower case, hyphens, version last, is set out in the cheap-production article in this series. Here the point is only that the number goes up, and that it starts at one, because the first version is the one nobody expects to replace.

Say in the article which version the reader is looking at and when it was last checked, in one line under the media: "Shows the current mail system. Last checked: [date]." That line is for the reader, who learns that the picture has been looked at recently and is likelier to trust it. It is also for the reviewer, who sees at a glance which articles have not been checked since the last upgrade. A picture with no checked date is a picture of unknown age, and the reader's safe assumption is that it is old.

The Review Trigger: When a System Changes

The cheapest moment to find an expired picture is the moment the change is made, because at that moment somebody knows the change happened and knows what it touched. Add one line to the change record: "Which knowledge base articles and media show this system?" and answer it from the register before the change goes in. The one-page change record that most small desks use is described in The One-Page Change Record. This is one more line on it, and it costs a minute, because the register can be filtered by the system it shows. Mail system: eleven rows. Review the eleven on the day of the change, flag the ones that broke, fix the text at once, and schedule the re-shoots.

Vendor-hosted systems change without a change record. For those the trigger is whoever reads the vendor's release notes, which is a duty assigned to a name and not a hope. Where the notes are vague or missing, the trigger is the first "button I don't have" ticket. In that case, the rule is that the first such ticket is treated as a signal about every piece of media showing that system, not as one person's problem. If you run QuerySolv, those tickets land in one queue whatever channel they came by. So the Monday-morning cluster is visible as a cluster rather than as nine separate complaints. In that setup, the search for the article's title finds all of them together. In any tool, the habit is to open the register at the first ticket, not the ninth.

The person who reviews is the article's owner, because an article with a name on it is an article somebody will actually open. The register's owner column copies the article's. The ownership rule, every article has a name on it and the name is a person rather than a team, is made in Ownership: Every Article Has a Name on It. Media inherits it. A screenshot owned by "the desk" is a screenshot that will be fixed by the next person to be shouted at about it, which is a system, but not a good one.

The Sweep for Everything Else

Some changes have no record and no release note. Examples include the browser updating its look, the theme changing, and a new logo arriving. Other examples are someone rearranging the shortcuts on the shared machines, or the sticker on the printer being replaced with a different model's. For those, the register gets a periodic sweep. Open each row, compare the media with the live screen or device for a few seconds, and either update the "last checked" date or flag the row. A row takes a minute. A hundred rows take an afternoon, which is more than a day's work for a one-person desk, so the sweep is split. Most-viewed articles come first, then the systems that changed most recently, then the rest in rotation, a few rows a week.

Bind the sweep to the article maintenance rhythm the desk already has rather than inventing a second one. The general approach, small regular passes instead of a documentation day that never comes, is in Maintenance Without a Documentation Day. The media sweep is a column on the same pass: when an article is reviewed, its media rows are reviewed with it. The register's job is to make sure the rows exist. That way, the reviewer knows there are three images in this article and not two, and that one of them shows a system that was upgraded last month.

The tickets are the other sweep. Once a month, search the last month's tickets for "video", "screenshot", "doesn't look like", "can't find the button" and the names of the systems with the most media. Read what turns up. Three tickets naming the same article in a month is a flagged row, whether or not anyone on the desk noticed a change. The requester is the only reviewer who checks every article every day. They report their findings as tickets, which is the format the desk is best at reading.

The Text Fallback That Outlives the Video

Every video has the full text steps under it, and every screenshot has a complete text step above it. The reason is this article's. When the screen changes, the text is fixed in minutes and the media is flagged in the register. In that case, a one-line note goes at the top of the article: "The video below shows the previous version of the mail system and is being re-recorded. The written steps are current." The reader who arrives in the gap, which can be weeks, gets a correct answer from the text and an honest warning about the picture. Without the text, the article goes blank the day the screen changes, and stays blank until someone has an afternoon.

The text fallback is also what makes the re-recording cheap, because the fixed text steps are the new script. The video script sheet from The Ninety-Second Video is edited to match the fixed steps. The clip is re-recorded from it in one take, and the version number goes up. A video with no sheet and no text is re-made from scratch, by someone who first has to work out what it showed. That is why those videos are not re-made and are instead quietly left wrong.

The same text serves the reader with the sound off, the reader on a phone and the reader who uses a screen reader. Those readers are the subject of Accessibility: The Reader Who Cannot Watch. One set of text steps under the media does three jobs at once. It is the fallback when the picture expires, the alternative when the reader cannot watch, and the thing search actually finds. It is also the thing most desks consider optional once the video exists. It is the only part that is not.

Retire, Re-record or Patch

A flagged row has three outcomes, and choosing between them is a thirty-second decision rather than a meeting. A small change, one button renamed or one icon restyled while the sequence stays the same, is patched. In that case, the single screenshot is re-shot from the clean capture. Or a line under the video says "the Save button is now labelled Apply" until the next re-recording. The article's checked date is updated. A large change, a moved menu or a different sequence of actions, means the clip is re-recorded from the corrected script sheet and the version goes up. A system that has been retired means the media is removed and the article is archived or rewritten, with the text kept until the last reader has gone.

• Patch when the sequence is unchanged and one label or icon has moved. In that case, re-shoot the one image, or add a one-line note under the clip, and update the checked date.
• Re-record when the sequence has changed: fix the text steps first, correct the script sheet, record one take, raise the version, update the register row.
• Retire when the system, the device or the room is gone, or when the media has had no views in a year. In that case, remove the file, keep the text, and close the register row.

Retire more than feels comfortable. Media that nobody has viewed in a year is costing a review every quarter and helping nobody. The text beneath it does the job for the one reader a year who turns up. Nobody has ever been grateful for an archived video. They have quite often been grateful that it was gone, usually without knowing why the article suddenly made sense.

The Media Register

The media register is a list with one row per photograph, screenshot or clip in the knowledge base. The row says which article the media sits in, what file and version it is, and what system or device it shows. It also says who owns it, what change would break it, when it was last checked, and its status. A spreadsheet is fine, kept where the knowledge base's other housekeeping lives. It is filled in at the moment media is published, which is the last line of the production checklist in this series. The register is the thing that turns "the mail system changed" into "these eleven rows" in a minute.

Starting from nothing takes an afternoon. Walk the knowledge base, article by article, and write a row for each picture and clip, with a status of "unchecked" for every one. That is because the inventory is not the review. Do not fix anything during the inventory; the point is the list. Then review in the order the sweep section gives, most-viewed first, and the status column fills in over the following weeks. A desk with two hundred images and no register has two hundred promises it cannot find, and the afternoon is how it finds them.

The "trigger" column is the one that earns its keep. It names the event that would break the row: "mail system release", "replacement of the reception label printer", "refit of meeting room two". It is what the change record's extra line filters on, what the person reading release notes scans for, and what facilities can be asked about once a year. A row with no trigger is a row that will be found by a ticket. A row with a trigger is found by the change, which is earlier and cheaper, and does not involve nine people in the chilled warehouse.

A Short War Story: The Signature Video at Ashgrove Housing

At Ashgrove Housing, Leah on the desk recorded "Set up your e-mail signature" as a ninety-second clip, and it was good. It was wrong within a quarter when the mail provider moved the setting. She found out from a cluster of eleven tickets and fixed it by re-recording it one Friday afternoon. The provider moved the setting again before the summer, and again in the autumn. Each time there was a cluster of tickets, forty-one across the year. Each time Leah gave up a Friday afternoon to re-record a clip for a task that had, on reflection, never needed a video. That was because it was four clicks and a text box. The fourth time, she made the text steps the article and put the clip under them with a "last checked" line. She added the mail system to a register with herself as owner and the provider's release note as the trigger, and asked the provider to add her to its release mailing list. The next move of the setting arrived as an e-mail on a Tuesday. The text steps were fixed before anyone noticed. The clip was retired, because nobody had watched it in two months. The lesson, which she wrote at the top of the register, was that the trigger is the release, not the tickets. She also wrote that the tickets had been the desk's only trigger for a year.

The Media Register Template

Copy the layout into a spreadsheet, one row per picture or clip, and fill in the first few rows from the articles the desk is most often asked about. The three routines underneath the table are the whole maintenance method: the change-record line, the sweep, and the ticket signal. The register is joke-free and should be boring; a register that is interesting is one with a lot of flagged rows in it.

MEDIA REGISTER — ONE ROW PER PICTURE OR CLIP
Kept at: _____________________   Register owner: _____________________

#   Article                      File (task-vN)                 Type          Shows (system / device / room)
__  ___________________________  _____________________________  ___________   ______________________________
__  ___________________________  _____________________________  ___________   ______________________________
__  ___________________________  _____________________________  ___________   ______________________________

    Owner          Trigger (what change breaks it)        Last checked   Status
    ____________   _____________________________________  ____________   [ ] current  [ ] flagged
    ____________   _____________________________________  ____________   [ ] re-making  [ ] retired
    ____________   _____________________________________  ____________   [ ] unchecked

Type: photo / screenshot / phone clip / screen video
Status: unchecked (inventoried, not yet reviewed) / current / flagged (wrong; text fixed; note on article)
        / re-making (new version in progress) / retired (file removed; text kept)

ROUTINE 1 — ON EVERY CHANGE RECORD
  [ ] filter the register by Shows = the system being changed
  [ ] review each row on the day of the change; fix text at once; flag media; schedule re-shoots
  [ ] add the row's trigger if it was missing

ROUTINE 2 — THE SWEEP (bound to the article review)
  [ ] most-viewed articles first, then recently changed systems, then the rest in rotation
  [ ] compare each item with the live screen or device; update Last checked or set Status = flagged
  [ ] retire anything with no views in a year; keep the text

ROUTINE 3 — THE TICKET SIGNAL (monthly)
  [ ] search last month's tickets: "video", "screenshot", "doesn't look like", "can't find the button"
  [ ] three tickets naming one article = flagged row, whether or not a change was noticed
  [ ] first "button I don't have" ticket on a vendor-hosted system = review every row for that system

WHEN A ROW IS FLAGGED
  [ ] text steps fixed first, same day
  [ ] one-line note at the top of the article: media shows the previous version; written steps are current
  [ ] patch, re-record or retire decided; version raised if re-made; register updated

Greywater's register took Ingrid one afternoon to build and listed sixty-three items, nineteen of which showed the mail system. The next upgrade was reviewed from the change record the week before it went in. On the Monday after, the upgrade produced one ticket, from someone who had printed the old article in the spring and kept it in a drawer. There is no register for drawers.

Frequently Asked Questions