Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1877 Ideas

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Bring back quicksearchOn the backlog

In previous iterations of the Thinkwise GUI you could perform an action called quicksearch. How it worked:Bring focus to a specific column (in the grid) Type what you want to search  First match of your search gets selected/highlighted. Can we please have this back?Why Quicksearch is valuable (and missed)1. Strong productivity gain for keyboard usersQuicksearch enabled fast, uninterrupted workflows:No mouse interaction requiredNo modal dialogs or filter configurationImmediate feedback while typingFor users who work with data grids all day, this shaved seconds off every lookup — which adds up quickly.2. Ideal for exploratory and ad‑hoc searchingQuicksearch was perfect when:You don’t know the exact valueYou just want to jump to something that looks rightYou don’t want to define a full filter for a one‑off checkCurrent alternatives (filters, column search fields) feel heavier for this use case.3. Lower cognitive load than filteringQuicksearch required almost no mental overhead:Focus columnTypeFirst match selectedCompared to:Opening filtersChoosing operatorsApplying / clearing filtersThis made it especially useful during conversations with users or while debugging data.4. Excellent for large datasetsIn grids with many rows:Scrolling is inefficientSorting doesn’t always helpFilters can be overkillQuicksearch acted as a “jump to value” mechanism, not a data‑reduction mechanism — a subtly different but very useful interaction.5. Consistency with legacy behavior & muscle memoryMany long‑time Thinkwise users built muscle memory around this feature.Its removal:Breaks established workflowsIncreases friction when moving to Universal UIMakes Universal UI feel like a regression in this specific area, despite its overall improvements6. Complementary, not a replacement, to filteringQuicksearch didn’t replace filters — it complemented them:Filters = structured, intentional selectionQuicksearch = fast navigation and orientationBoth serve different user intents and can coexist.

Arie V
Community Manager
Arie VCommunity Manager

Ability to hide Domain element based on logicOpen

We often have situations (especially on status fields) were a user is only allowed to use certain element values or to move it from one element to one other element. The availability of a given element would be based on User permissions or current status (for example: if current status is A, you can only change it to B, and if current status is B you can only change to A or C, but not D). The current ways of resolving these situations feel like workarounds, which should not be necessary for such a straightforward request in a platform called low code. Suggested solutions I have heard are:Create two (or more) similar Domains with similar, but not all, Elements and determine in the Layout procedure which one to show. This basically means adding (sort of) duplicate domains, which is ugly and risky from a maintenance perspective... Use a Lookup to a Table or View with Pre-filters. This is more effort, clutters the Data Model and is probably worse in performance than a Domain with Elements...A possible solution that comes to mind is the ability to set in the Layout procedure when to show/hide certain Elements. It would be good enough if somehow the Layout procedure recognizes Domain with Element type of fields and we can write logic on each individual Element within that Domain.  How do you like this idea? If you have other suggestions than the Layout procedure to fix this: let's hear it!