Search Ideas

Top-level ideas can be structured any way you as author want them to be. (Any idea at any level can, but top-level ideas are presumably where articles could live.) The structure of any particular idea can be different from the structure of the discussion as a whole.

#2725 and #2711 are implemented as of 34fc694.

Proposed solution: ideas with pending criticisms could be archived automatically if they haven’t had any activity in the past 30 days, say.

Sanctimonious/preachy

I implemented #2659 and it’s much better now. In addition, there is now automated archiving (#2704) and manual archiving (#2711). Archived ideas live on a separate page, so the main page is faster.

I went ahead and implemented this feature since it was a good suggestion.

You can edit your discussion here.

This is not applicable anymore.

Now that diffs are formatted, they don’t omit unchanged lines anymore.

Proposed solution: allow people to archive ideas. Maybe only their own.

That could just annoy people and cause them to unsubscribe from emails.

Could do it only for ideas with pending criticisms. If they have pending criticisms, how important can they be? This has the added benefit of creating an incentive for proponents of ideas to address criticisms.

People might just forget to do this.

This requires manual action. Could mean a lot of work depending on the discussion.

Proposed solution: ideas could be archived automatically if they haven’t been revised or criticized in 90 days, say.

This problem will surface rarely – users would have to hit cmd + f immediately upon opening the page. For most users, by the time they start typing, the page is already fully loaded. So this seems like a small price to pay in exchange for discussion pages that always render faster.

Now that parts of the page are purposely and visually disabled (see #2694), users may not expect everything to be working 100% during a loading state.

I now purposely prevent interactions with buttons and gutters, and gray them out, until the page is fully loaded. So instead of broken hover effects and interactions, the user gets intentionally disabled elements, and this intentionality is communicated to them.

Once the page is fully loaded, buttons and gutters are enabled and visually restored.

Since the browser’s loading indicator remains visible until then, this behavior shouldn’t violate user expectation.

That means duplicate functionality; anytime I customize Devise in the future, I’ll have to remember to adjust this one method as well.

I could extract discussions#show into a new, separate StreamController or something like it. That controller would not use Devise.

Then again, I’d want to redirect users to the sign-in page (and then ideally back to where they were trying to go).

Duplicate of #2677/#2683.

While ideas load, cmd +f won’t work.

I could render the first ~10 top-level ideas immediately and only render the rest as turbo frames off screen. By the time the user scrolls down, they should all be loaded.

Yes, it would be even worse than #2677 (see criticism #2681), where only top-level ideas were turbo frames.

Too many requests when there are enough top-level ideas.