Pitch: Making a move a move

Conor Muirhead
Conor Muirhead
When I move something from one place to another I have a few expectations for how it'll work:

  • It's no longer in the old place (If I wanted that I'd use copy)
  • If I gave folks the old address, and they try to use it, it'd be nice if they were just pointed to the new place
  • If I moved it out of someone's reach, to a place they can't access, they shouldn't be able to see it, or comment on it anymore
  • The item's event history would reflect that it was moved here from elsewhere


Right now, we break expectations

Because moving something actually means copying to a new location and then putting the old version in the trash, we're breaking expectations. Here's how:

  • ❌ Trashed things are fully accessible, viewable, and commentable
  • ❌ People going to the old address land on the old trashed version (hidden behind a "view this" link) with a banner including a subtly phrased link to the new location in "another Basecamp"
  • ❌ Copy+Trashed recordings act as a redirect for 30 days, but then they're deleted, and then finally incinerated
  • ❌ The old thing can still be seen and commented on by people who can't see the actual thing in its new location

There are many scenarios where this sucks, but here's a common one we've hit:
Before: two sources of truth, leftover data, broken unreads 108 KB View full-size Download

--- More detailed description of the major issues...

Parallel versions of the same thing exist, and can progress independently
  • When you move a message, we actually put it in the trash, and make a copy of it in the new location
  • Because the "old version" is still around (both in the trash, and at the old URL) people can continue to do things with it—like comment, edit, move, etc.
  • When someone comments on the old version...
    • ...it generates more unreads that are hard to clear (see the next issue below)
    • ...the new, actual location of the thread doesn't get the new comment

Unreads are all screwed up
  • Clicking on the unread takes you to a screen that tells you the thing moved
  • Because the content isn't shown, you never "read" it, so it persists in your Hey!
  • Following the link to the new location doesn't clear the existing unread either
  • You can mark it as read by manually clearing it using the "x" or by clicking the "view this" link in the moved notice and scrolling down to see the recording the unread was generated for

Data lingers in the old location for 30 days...and then suddenly disappears
  • If someone accidentally posted something to the wrong location, and (understandably) thought they fixed it by moving it, they'd be mistaken
  • The old version continues to be accessible (albeit behind an extra click) via the old URL, and via the trash—which everyone can see
  • Because the old version is in the trash, it will eventually be emptied and then incinerated, thus breaking any existing links that previously worked to redirect people to the new thing

Events and timelines don't explain that something was moved
  • The Latest Activity screen says things were "reposted", not moved
  • The detailed event logs say that things were trashed and copied, not moved


What should we do about it?

In short, there are three things we need to change to meet expectations and resolve the major issues described above:

  1. New "redirect" status for the original recording that mostly behaves like "deleted"
  2. Re-issue unreads as appropriate
  3. New "moved" event type so we can accurately describe an item's history

That scenario above looks more like this after these changes:
After: Redirect sends everything to single source of truth, no leftover data, unreads work 90.2 KB View full-size Download

--- More detailed description of the proposed solutions...

1. New "redirect" status for the original recording
  • Doesn't show up in the trash
  • Doesn't accept comments
  • Doesn't get incinerated, ever
  • Doesn't retain any content or descendant recordings
  • Does have a stable URL that serves as a redirect
  • Does revoke unreads and events from menus and timelines

2. Re-issue unreads as appropriate
  • If someone had an unread for the old spot, we re-issue an unread for the new spot
  • Unreads for a project you can't access aren't shown, if you get access, they show up

3. New "moved" event type so we can accurately describe an item's history
  • Timeline entries in the new location indicate that the item was moved to the project
  • By-the-minute log entries show the item as being moved from previous location

Making the above three changes would resolve the major issues we have with our current move implementation. This mostly requires programming work, but a bit of design support along the way would likely be necessary.