HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
Voted — this is exactly the right direction for the client, and I'd push it a step further: rendering forms and views with React/DOM is also the opportunity to shed the Eclipse/Expeditor shell and make the desktop client genuinely modern, not just re-skinned. The two go naturally together.
One thing worth flagging early, because it's where this will either succeed or stall: behavioural fidelity. React draws the presentation beautifully, but something still has to execute the real Notes behaviour — computed fields, hide-when, @formula, LotusScript events (PostOpen, QuerySave, QueryModeChange), embedded views, layout regions, rich text/CD. Optimise purely for modern-responsive and you lose fidelity with legacy designs; optimise purely for fidelity and you stay locked into 20-year-old layouts. The sellable path is React-by-default for forms authored to be responsive (perhaps gated by a new form property), with a guaranteed compatibility path for fixed-position designs — "new by default, old guaranteed", not either/or. DRAPI already gives you a natural data/schema backend to feed it.
And one extension to consider: a shared React rendering layer wouldn't just modernise the desktop client — it could also benefit Nomad Web, which today renders to a canvas and therefore struggles with accessibility (screen readers, tab order, true reflow). With the European Accessibility Act now in force, a DOM-based rendering path becomes a compliance lever as well as a UX one. Desktop client first, but the same investment could pay off across surfaces.
HCL please explain to me how an idea with 24 votes (and counting) gets the status of "planning to implement" and ideas with over hundreds of votes have status "assessment", "future consideration" or "no plans to implement" ?
all roads lead to nowhere. it seems
This is the right direction — and it's the piece that's been missing. Rendering Notes applications with modern React components is a genuine redesign of the presentation layer, not a port. It's worth being explicit about the difference: Nomad recompiles the existing client to run in a browser (same engine, same UX, relocated), whereas this replaces the rendering layer with something web-native — responsive, accessible, CSS-controllable, with room for proper modern controls.
This is also what should finally deliver on IDEAMLCT-I-8 ("Drastically improve the look and feel of the Notes client"), which was recently closed as "Shipped" on the back of 14.5.1. A colour change and a template restyle on the same Eclipse client didn't close that idea — an approach like this one would. NTS-I-2976 is the real vehicle; I-8 was just moved, not delivered.
One strong argument for prioritizing it now: AI has changed the cost equation. Re-architecting a legacy rendering layer used to be the classic "not easy, not cheap" objection — but AI meaningfully accelerates this kind of modernization and lets it be done with a smaller team and a shorter timeline than even two years ago. HCL is already investing heavily in AI across Domino; pointing some of it inward, at the layer every user touches every day, is the highest-leverage place it could go. Please resource this properly.