Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

2004 Ideas

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Bring back quicksearchPartially completed

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.

ThijsThinkwiser

Make multiple Search code screens independent, like all other screensOpen

Current behaviorWhen 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:Open Search code and search for term X. Open a second Search code screen and search for term Y. 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 problemUsers 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.ProposalMake 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.ContextI 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.

Native tag functionalityMerged

We often receive request from users to filter and organize data from different perspectives and dimensions. as responsibilities vary between users. For example, one user may be responsible for purchasing, while another focuses on planning.In addition, we are seeing a growing demand for different types of classifications, both among users and across different business entities. To avoid having to create a dedicated column for every new classification, we would like to provide users with more flexibility with the use of tags. We have noticed that this functionality is available in most modern web applications but is currently not supported in Thinkwise. While it is possible to display tags using an HTML column combined with custom CSS, extending this with functional behavior is not user-friendly. In such a setup, multiple tags (text) are stored and displayed within a single column, meaning that filtering is currently only possible using LIKE operators. This is not ideal from a performance perspective, especially when working with large master data tables. It would be valuable if Thinkwise offered native support for working with tags. This could potentially be achieved through a new domain or control type, allowing tag elements to be created and managed dynamically within the application. In the ideal scenario, users would be able to:Select one or more tags when filtering data. Create new tags directly from a grid or form. Click on tags to instantly apply a filter. Sort and group data based on tags. Manage tags dynamically without requiring database schema changes or additional columns.This functionality would improve usability, flexibility, and scalability, while reducing the need for customizations and additional database columns whenever new classification requirements arise. Example of the current solution using HTML and custom CSS: