Skip to main content
Open

Make multiple Search code screens independent, like all other screens

Related products:Software FactoryUI/UX
  • September 23, 2026
  • 4 replies
  • 92 views
Thinkwiser
Forum|alt.badge.img+2

Current behavior
When multiple instances of the same screen are open in the Software Factory, they work independently. Search code is the only exception, because its instances share state:

  1. Open Search code and search for term X.
  2. Open a second Search code screen and search for term Y.
  3. Return to the first screen and click Search again.

The first screen now shows the results for Y, and its search term has changed to Y.

Why this is a problem
Users learn from the rest of the platform that each screen instance keeps its own context. Search code breaks that expectation without any visual indication. A user who opens a second Search code screen to compare results, or to keep an earlier search at hand, silently loses the first one and may act on results they did not ask for. Even if this is intended, from a user's perspective it is indistinguishable from a defect.

Proposal
Make behavior consistent (orthogonal) across the platform:

  • Preferred: each Search code instance keeps its own state (search term, filters, results), just like other screens.
  • Alternative: if shared state is a deliberate design choice, make it explicit. For example, reuse the existing Search code screen instead of opening a new instance, or clearly indicate that the instances are linked.

What matters most is predictability. Either all screen instances are independent or none are, with no silent exception for a single screen.

Context
I originally reported this as a bug. It was closed as intended behavior, with the suggestion to submit it as an idea, which is why I am posting it here.

4 replies

Remco Kort
Administrator
Forum|alt.badge.img+2
  • Remco Kort
  • Administrator
  • October 2, 2026
Updated idea statusNew→Open
Moderator

Have you tried MCP? Mcp basically makes code search obsolete. It’s far superior, although a bit slower. I believe we should invest in making MCP optimal for code search purposes. 

Jeroen van den Belt
Administrator
Forum|alt.badge.img+10

To get a complete picture of your idea, a few questions on how you'd picture this:

  1. Changing a search: In a screen that already has results, what should happen when you adjust the term or settings? Should the results be replaced, should the new search open in a new screen, or should the search be locked once it has results?

  2. Previous search string: This field currently lists your last five searches. Should a search from one screen show up in this field in another screen, or would you no longer need this field? If you'd keep it:

    • Should the same term with different settings appear as separate entries?
    • Picking an entry now only fills in the term and settings. Should it also show the earlier results?

  3. Retention: How long should searches and their results be kept? Until a certain number is reached, for a certain time, until you close the screen, or until you remove them yourself?

Thinkwiser
Forum|alt.badge.img+2
  • Thijs
  • Author
  • Thinkwiser
  • October 14, 2026

My feedback.

  1. I think the terms and settings should apply to the search results of the screen instance that contains them. After changing the term and/or setting en hitting the search button again, the search results in the screen instance should be overwriiten as SF does now.
  2. Previous search terms and settings would be fine as they are, model-wide and not specific to a screen instance, I think. I mostly use them after opening a new session, e.g., the next day, to go back to where I was.
  3. Until a certain number, e.g., 10,  has been reached, I think.

 

Terms & ConditionsAccessibility statement