One column layout your whole team actually uses

Three people on a team export the same folder listing and produce three different spreadsheets. Same files, same tool, same afternoon. One has the path column second, another has it last, a third does not have it at all. Somebody then merges the three by hand.

The columns are not the interesting part of that story. The interesting part is that a column layout is a decision somebody made once and nobody wrote down.

A layout is three things, not one

People think of a column set as a list of ticked boxes. It is actually three separate pieces of information, and the reason team layouts drift is that most tools only remember the first:

1. Which columns. The obvious one. Name, size, codec, duration, loudness.
2. In what order. Name first, then whatever the reader scans for next. A layout for checking deliveries puts codec and frame rate near the left. A layout for chasing disk space puts size there.
3. At what width. A path column at 90 points is useless. Codec at 300 is wasted space. Width is what decides whether the thing is readable without horizontal scrolling.

Drop order and width and you have not saved a layout, you have saved a checklist. The recipient still has to rebuild the arrangement, and they will rebuild it slightly differently.

Order has a second job

On screen, column order is a convenience. In an export it is structure.

A CSV is consumed by something: a spreadsheet with formulas that reference column D, a script that indexes fields by position, an import mapping in another system. All of those break when the order changes, and they break quietly — the file still parses, the columns still have headers, the numbers just land in the wrong place.

Which is why the order you see and the order you export have to be the same thing. If they are two separate ideas held in two places, they will eventually disagree, and the disagreement shows up in the file rather than on the screen where you could see it.

Making the layout a file

In FileLister a column set is saved as a preset, and a preset exports as a small JSON file:

{
  "columns" : [
    { "id" : "name",              "width" : 380 },
    { "id" : "videoCodec",        "width" : 150 },
    { "id" : "videoFrameRate",    "width" : 70  },
    { "id" : "durationSeconds",   "width" : 90  },
    { "id" : "integratedLoudness","width" : 110 },
    { "id" : "relativePath",      "width" : 260 }
  ],
  "name" : "Sponsor delivery check"
}

The array order is the column order. Each entry carries its width. Importing it reproduces the arrangement, not an approximation of it.

Because it is a text file of a few hundred bytes, it goes wherever your team already keeps shared things. In the project repo next to the delivery spec. In the shared drive with the brand assets. Attached to the email that describes the job. It diffs cleanly, so a change to the standard layout is reviewable.

Layouts worth having

Three or four cover most work. They are not general-purpose — each one exists to answer a particular question quickly.

Delivery check. Name, codec, frame rate, dimensions, duration, loudness, true peak. Everything the spec constrains, in the order the spec lists it, so reading across a row is the same motion as reading down the spec.

Handover manifest. Name, relative path, size, modified date, SHA-256. What somebody needs to confirm they received what you sent. Path before size, because the recipient is looking for structure rather than volume.

Archive audit. Name, path, size, created, modified, kind. Wide path column, because the whole point is where things are.

Photo delivery. Name, dimensions, DPI, colour profile, camera, lens, date taken. Nothing about video, nothing about hashes.

The temptation is to build one layout with forty columns that covers all four. It is a bad idea for the same reason a spreadsheet with forty columns is: the useful information is there but nobody can see it, and the export is unreadable in anything but a spreadsheet.

Arranging without dragging headers

Dragging column headers is the obvious way to set an order and a poor place to store one. Header positions are a property of a window, they are easy to disturb, and in several frameworks — including SwiftUI's table — the drag order is not persisted at all, so the arrangement is gone by the next launch and was never available to the export in the first place.

FileLister keeps the arrangement somewhere it can be read back: the Choose & Arrange Columns panel (⌘J) lists the columns you are showing, in order, with each width shown in points beside it. Dragging a row there sets the order, and that order is what the table draws and what every export writes — CSV, TSV, Excel, JSON, HTML, PDF, Markdown and Copy as Table alike.

Widths follow the same route. Resize a column in the table and the number updates in the panel; save the preset and the width goes with it.

Distributing it

The workflow that holds up in practice:

1. One person builds the layout properly once — columns, order, widths — against a real folder rather than an empty one, because widths only make sense with content in them.
2. Save it as a preset, export it, and put the JSON where the team already looks.
3. Everyone imports it. One click applies the whole arrangement.
4. When it needs to change, one person changes it and re-exports. The diff shows what moved.

Older preset files that predate widths still import; they simply carry no width information and leave the current widths alone. That matters if you have a stack of layouts saved from an earlier version and no appetite for rebuilding them.

Why this is worth ten minutes

The cost of not doing it is not dramatic. Nobody loses a file. What happens is that three spreadsheets arrive in slightly different shapes, someone reconciles them, and a formula that referenced column D quietly reads the wrong field for a week.

Standardising the layout removes an entire category of that. It also makes the exports comparable over time, which is the thing you discover you wanted eight months later when you are trying to work out what changed between two deliveries.