R
Rob Fitzpatrick
Guest
I believe the will always be value in a character-mode DB monitor, so I'm not suggesting replacing promon with a GUI tool or a web tool. I'm not opposed to such UIs in principle but the character promon client shouldn't go away and shouldn't stagnate. I would like to see some investment in making promon use more productive: larger, more data-rich screens; better automation; better menu structure; overall better usability and discoverability of features. The current promon UI design shows its age. It was made at a time of small, fixed-geometry physical terminals (green screen). Today's workplace reality is variable-geometry virtual terminals (e.g. putty, proenv) on large physical monitors. The current UI (mostly) tries to fit within 80 x 25, but for some screens that just isn't enough. And as new DB features are added that require existing screens to squeeze in even more data (like partition IDs and tenant names/IDs), trying to stay within green-screen dimensions just doesn't seem to be a sustainable goal. Some design thoughts: restructure the menus eliminate "main" vs. "R&D"; have one unified menu structure for access to all functions eliminate hidden menu items separate db algorithm settings (e.g. APW settings, etc.) from promon UI settings (page length, etc.) eliminate redundant screens, e.g.: 1 1 vs. R&D 1 4 1 (user list) 4 1 vs. R&D 1 6 1 (lock table) 5 vs. R&D 2 1 (activity) M vs. R&D 5 (defaults/options) increase the screen sizes would enable more data-rich screen layout and permit future enhancements that necessitate adding more data to existing screens would prevent line-wrapping that currently causes readability issues (e.g. promon 1 (user control), promon 3 (block access)) would permit the creation of screen that just aren't viable today in the existing small format (e.g. table and index CRUD stats displays, and other VST views) eliminate the 9999-line page limit (the lock table can have more records than this) allow some mechanism (e.g. via startup params or a config file) to allow user UI customizations (e.g. page length, pause and sampling intervals, etc.) to persist across promon sessions improve the promon automation story today's promon automation: undocumented UI keystrokes are fed in via input redirection current promon scripts are cryptic, are full of UI directives, cannot contain comments, are stateful (i.e. you must know which menu you're in to know how to navigate to a given screen) suggested new promon automation: give each screen a unique ID or name also show the ID/name on that screen, and in the menu that called it, to aid script-writing a new promon script would consist of line items, where each line is one of three types: a screen ID/name a control directive (set the page length, sampling interval, working area, etc.) a comment benefits of this automation change: script logic would be decoupled from menu layout, freeing PSC to change menu layout in the future without breaking scripts scripts would not be cluttered with UI directives (e.g. P, T, etc.) comments and screen names would allow scripts to be more self-documenting, making them easier to read, write, and debug Final thought: there would have to be some kind of legacy mode that keeps the current UI layout, to avoid breaking existing scripts, buying time for them to be recreated with the new format.
Continue reading...
Continue reading...