Experiences from projects that moved to client-side human services (CSHS) with the BPM UI Toolkit (Spark) - the positives and the traps:
What got better: page transitions without server round trips (validation, wizards, master-detail all in the browser), responsive layouts out of the box (Bootstrap grid, phone / tablet breakpoints), far fewer custom coach views (tables with sorting / paging / inline editing, tab sections, modals, charts, file uploaders exist), formulas and control events replacing scripts, a consistent look without CSS work, and developers who know Bootstrap / jQuery become productive fast. Playback and debugging with browser tools instead of the server Inspector.
What to watch:
- Big coaches with many controls render slowly (question 1405) - page tables, lazy tabs, output text instead of input controls for display.
- All data goes to the browser: keep sensitive fields out of tw.local unless the coach needs them; load details on demand with Service Calls.
- Control addressing and events are a new skill (me / page / ${}, the difference between on change and on input); standardise a small style guide.
- Versioning of the toolkit: upgrading SYSBPMUI in an app can change control behaviour (labels, sizes, events); test after every toolkit upgrade and pin snapshots.
- Server logic must live in service flows; teams coming from heritage services tend to put too much in client scripts (no tw.system there).
- Some enterprise controls are missing (tree, rich grid features, complex date rules) - plan for two or three custom coach views per project and keep them small.
- Accessibility and printing need explicit attention (the toolkit is reasonable, custom views often are not).
Verdict: for new work CSHS + UI Toolkit is the default and heritage services should not be started any more; the investment is the UI skill set and a house style toolkit (header, footer, variants, validation helpers) that every app reuses.
References