Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1940 Ideas

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Bring back quicksearchPlanned

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.

Extend custom_display_format functionality to get Excel like field display/edit possibilitiesPlanned

The SF and data domains offer little possibilities to control the presentation of numbers. I thought the custom_display_format extenders would be the solution but I found some shortcomings that make them less useable in practice. I discussed this with Thinkwise people: The current behaviour is as intended but they think the following would be a good improvement.Simple example for a currency datatype NUMERIC(18,3) where users normally want to see only 2 decimals but the extra decimal is needed for calculation accuracy. By using an extender with "€ 0.00" format for the domain you get the following behaviourPositive:Display with 2 decimals is correct and third decimal is used for rounding up/down correctly An entered number with 3 decimals is correctly stored in the underlying tableNegative:When EDITING data there is no way to see the third stored decimal When EDITING it is not possible to edit the existing number; you have to clear the field and reenter the complete numberThe behaviour is the same in grid and form screens. We would expect behaviour like e.g. Excel:Display data using the Extender. They are called custom_display_format for a reason I think. Possibility to edit the exact stored dataWithout this behaviour the introduction of the extender seems of little use; the same could be achieved using an expressions field. But a task would be required to edit data and this is what we want to prevent.An extra improvement would be if the scope of the extender could be specified on a lower level than a domain. Then you would get the possibility to present and edit the same table field in multiple ways; the exact data for the finance department and in another screen rounded numbers for sales but still the possibility to edit the exact number.