Skip to main content

Idea pipeline (top 25)

1862 Ideas

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Non‑numeric visual indicators for tabs and menu itemsNew

 Currently, we allow numeric badges on tab pages and menu items. This works well for counts (e.g. number of records, open tasks).However, there are many situations where a number is not the right signal, but the user should still be visually alerted.The limitation of numeric badgesNumeric badges implicitly communicate:Quantity Work to be done BacklogBut sometimes the intent is different:“Something needs attention” “There is uncertainty or missing information” “This section contains an exception or warning”Using a number in those cases:Adds unnecessary cognitive load (“what does this number mean?”) Can be misleading (“do I really have 1 thing to do?”) Trains users to ignore badges if they are often not actionableProposal: Support symbolic / icon‑based indicatorsAllow tab pages and menu items to display non‑numeric indicators, such as:⚠️ Exclamation mark (attention required) ❓ Question mark (incomplete / unclear data) ⛔ Error icon (invalid or blocking state) ✅ Check icon (explicitly OK / completed) ● Dot indicator (something changed)These indicators would be data‑driven, just like numeric badges today.Why this is valuable1. Better alignment with user intentIcons communicate state, not quantity.This matches many real‑world business scenarios better than numbers.Examples:A tab contains inconsistent data → ⚠️ Required fields are missing → ❓ Validation failed → ⛔ Approval completed → ✅2. Faster visual scanningUsers don’t read numbers — they scan for patterns.Icons:Are recognized instantly Reduce interpretation time Draw attention without demanding actionThis is especially effective in:Complex screens with many tabs Role‑based applications where users need guidance Review or exception‑driven workflows3. Prevents notification fatigueNumeric badges can feel like “todo counters”. When everything shows a number, users start ignoring them.Symbolic indicators:Feel lighter Communicate importance, not volume Are less stressful and more selective4. Improves guidance without extra UIThis approach:Avoids adding extra columns, banners or messages Keeps the UI clean Uses existing UI real estate more effectivelyIt’s a low‑visual‑noise, high‑signal improvement.5. Backward compatible and complementaryThis would not replace numeric badges, but complement them:Numbers → “how many” Icons → “what kind of state”Developers choose the most appropriate signal per use case.Example use cases Customer screen “Details” tab → ✅ “Contracts” tab → ⚠️ (expired contract) “Documents” tab → ❓ (missing upload) Workflow‑driven application Menu item “Review” → ● (new activity) Menu item “Errors” → ⛔ (blocking issues) Master‑detail screens Child tab highlights issues without forcing users to open each tab Optional implementation direction (high‑level)Allow badge type to be: Numeric Domain with elements and Icon Icon visibility driven by badge logic / domain value Optional tooltip to explain the meaning

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Bring back quicksearchNew

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 possibilitiesOn the backlog

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.