Hiding archived and junked cards from search + command prompt

I understand that you’re working on incorporating filtering and searching, so this request may be duplicative.

That said, I would love for archived cards to be hidden from both search and the command prompt by default, so that I can create cards with impunity and archive them to get them out of my hair, where currently junked and archived cards both appear in the results list.

This comes up when I create cards with similar titles for specific situations – I’m cluttering the Command Prompt and search with every addition.

Of course I understand that archiving is a parent-relative notion. If there are multiple parents, this may not make sense — and furthermore, the card shouldn’t necessarily be ‘hidden’ globally if it’s archived from its parent. To that end, perhaps ‘archiving’ is the wrong mechanism for what I’m asking for here — but hopefully the use case is clear from the above. Happy to comment further.

Hi @tekacs,

Firstly, junked cards should not be showing up in the command prompt, that is a bug and we will be addressing that in the next patch.

Once that is fixed, would that solve your use case? Since you could just junk cards that you would no longer like to see.

Thanks @tobias. I think that Junk isn’t quite a fit for what I have in mind. Let me see if this makes sense at all.

One of my structures looks like this:

Tasks -> Tasks 07/2020 -> <some card here>

When a task is either complete or no longer relevant, I currently archive the card. This means that I can still easily view the full list in context (by adjusting filters to show archived cards), but they don’t appear by default.

At least today, it seems that adjusting the ‘Kept’ filter on the left doesn’t enable me to view Junked cards in context (and I suspect that it never would, because interaction with those cards is fundamentally different). I would like to Keep the card, so that I can have the ability to view and tweak no-longer-relevant cards in context.

Of course there certainly exist cases in which I archive a card from a single parent whilst keeping it under another and perhaps there is a third mechanism which would be most appropriate here — but as it stands, Junk and Archive both give me semantics that aren’t quite right.

So I think the main issue is reconciling single-player flows with what you want when you are collaborating.

With junking, that is for cards you just don’t want anymore, but it only applies to you.

Archival applies in context, but applies to everyone in that context. The idea being that if we are in a shared “Tasks” card, we’re probably archiving it because that task card is “finished”, and so do it for everyone so that each person in “Tasks” doesn’t need to archive it themselves.

The issue here though is that just because a card is ready to be “archived” in a specific context doesn’t mean that you (or anyone else collabing) doesn’t want to see it in 1. other contexts 2. the home screen 3. other views we add in the future.

Would it suit your use-case if we hid any cards from the home-screen / global search if every parent it was in had it archived?

Yes, that’s exactly what I would expect and have in mind.

I very much have cases where a card is archived relative to one parent and not to another — in those cases, I wouldn’t want it to be hidden. In cases where it’s archived relative to all parents however, I think of that card as ‘hidden in context’ and so expect to only see it when I turn on a filter that shows archived cards in a narrower context.

If it were hidden from home, global search and also the Link/Parent lists (for finding cards to link to/parent under) then that would solve this for me.

To present one other option, if you’re changing the tree to be opt-out in the upcoming update.

It’d be a little more work, but I’d be willing to hit ‘unindex’ whenever a card should no longer show up in global search or in the Link/Parent dialogs.

Alternatively, you could unindex it from the tree when it was archived relative to all of its parents, achieving the same as the above approach whilst making it explicit.

Changing unindex to actually mean unindex is an interesting idea. However, my issue with this becomes: how do you find a card that you have previously unindexed? It’s not in the Junk (obviously), but it’s not in global search either. At that point it kinda seems like it has become junking but with extra steps.

Well perhaps in a similar way to viewing an archived card today? If there were a filter that you could toggle, like the ‘Archived’ filter today, then you could explicitly search for cards that had been taken out of the default index?

Another use case I would have for explicit un-indexing is cards transient notes.

For example:

‘Jane Doe > Note about investor intros’

The title is generic and the card is transient — it’s nested in a context where I can tell what that it refers to Jane Doe, but without unindexing I would prefer to name it

‘Jane Doe > Note to Jane Doe about investor intros’

The reason being that if I hit Cmd+K, ‘investor’ will now bring up the very generic looking card name ‘Note about investor intros’.

I would much prefer to unindex that transient card.

Another use-case here. :slight_smile: I have a setup like this:

Food > Restaurants in San Francisco > {Chinese, Thai, Indian, ...}

Each of those child cards contains a Markdown list of the restaurants of that type in SF.

Unfortunately, they’re all called ‘Thai’, ‘Indian’, etc. When I move from here to NYC (which I’ll likely do soon), those will all be confusing once I make cards on the path:

Restaurants in NYC > {Chinese, Thai, Indian, ...}

For now, I’ve named all of those cards ‘Chinese SF’, ‘Thai SF’, ‘Indian SF’, …

I would prefer to simply ‘archive’ all of them when I move, removing them from search.

I /wouldn’t/ archive ‘Restaurants in San Francisco’, so if I wanted to find them again, I’d jump to that parent card and look at its children.

There’s a search question here too, which relates to Ranking by recency/context in the Command Prompts

Thanks for laying all these out! Really helps to build out features when we understand exactly how you might use them.

Will definitely keep all these in mind, and try to address them as we move forward with any changes to this behavior.

1 Like