Results table UX: one-click cleaned-details inspection and lightweight sorting

[szTheory]

Context

There are two related bits of friction in the results table today:

1. Clicking a completed file reveals metadata categories, but every category starts collapsed. Answering the basic question—“what did ExifCleaner remove?”—can require opening several more sections individually.
2. The existing Name, Type, Size, Before, and After headings look like natural sorting controls, but the table currently remains in drop/discovery order.

This issue is a request for feedback on a small, inspection-focused refinement. The goal is not to turn ExifCleaner into a file manager or a generic data grid.

Job to be done

After cleaning one file or a large batch, users should be able to:

• understand what was removed after one intentional click;
• inspect what metadata remains when they need to;
• surface files by name, type, size, or metadata counts;
• retain the context of nested folder drops;
• do all of this without adding permanent toolbar or settings clutter.

Leading proposal: removed-first details

Keep the current compact table and one-expanded-file model.

When a completed row opens, immediately show the removed fields:

14 metadata fields removed · 2 still present       Copy report

LOCATION
− GPSLatitude                  40.7128…
− GPSLongitude                −74.0060…

CAMERA
− SerialNumber                12345…

TIME
− DateTimeOriginal            2026:…

› Still present after cleaning (2)

The proposed behavior:

• Removed fields are visible immediately, grouped beneath quiet category headings.
• Categories are no longer another layer of collapsed accordions.
• Fields remaining after cleaning sit behind one secondary disclosure.
• Long results retain the current internally scrolling panel.
• “Copy all” could become “Copy report” and include clearly labelled removed and still-present fields.
• Only one file remains expanded at a time.

Important wording detail: the current comparison knows whether a metadata key remains after cleaning, but does not yet prove that its value is unchanged. The UI should say still present, not unchanged, unless value-level comparison is added later.

Empty and error states should remain explicit:

• No removable metadata was found
• No fields were removed · 8 still present
• Existing processing, verification, and write failures remain truthful error panels rather than successful-looking reports.

Leading proposal: sortable existing headers

Make the existing headings the controls:

NAME ▲      TYPE      SIZE      BEFORE      AFTER

No new toolbar or filter row.

Proposed behavior:

• Clicking a heading sorts; clicking again reverses direction.
• Only the active heading displays a restrained caret.
• Original drop/discovery order remains the default.
• Sorting is stable and is not remembered across launches.
• Folder sections remain in place; files sort within each folder rather than flattening the entire source tree.
• Loose files sort as their own block.
• The expanded file remains expanded after reordering.
• Pending, unavailable, and failed values always sort last.
• Before/After sorting should become available only when the batch is complete, preventing files from jumping while the user is inspecting them.

Suggested semantics:

• Name: case-insensitive natural order (IMG_2 before IMG_10)
• Type: normalized extension, then name
• Size: numeric file size
• Before: metadata-field count before cleaning
• After: metadata-field count remaining after cleaning

#302 separately discusses whether Size should show the original, cleaned, or both values. This proposal should not preempt that decision.

Why this shape?

Alternatives considered:

• Expand all: smaller change, but still requires an extra action for every file.
• Open every current category by default: immediate, but noisy and gives removed and remaining metadata equal visual weight.
• Side inspector: powerful for forensic review, but likely too much layout and responsive complexity for this focused utility.
• Modal details: interrupts scanning and separates the report from its row.
• Filters/search/column settings: useful in full file managers, but premature here.

The removed-first panel plus sortable existing headings appears to solve the common jobs with very little new chrome.

Feedback requested

1. When opening a completed file, do you primarily care about what was removed, what remains, or both equally?
2. Would removed fields appearing after one click be clearer than the current collapsed category accordions?
3. Should sorting preserve each folder section, or should it rank every file across the entire batch?
4. Which sorts would you actually use: name, type, size, highest metadata count before cleaning, or lowest remaining count afterward?
5. Would “metadata removed” be more useful as a visible table column than either Before or After?
6. Is the existing batch footer enough for an overview, or would a later summary such as “GPS removed from 8 files” be valuable?

Concrete examples of how you inspect a real batch would be especially helpful.