loadUI 2.0 Stats Workbench feedback
Top ten gripes about the Statistics Workbench after intensive use of loadUI 2.0 Pro in an ecommerce setting.
1. There should be one button control to put all graphs in the statistics workbench in the same PRECISE zoom and range.
ONE. BUTTON.
EXACTLY IN SYNC.
Right now you can set two graphs to 'seconds' and one will scale to minutes and the other will auto-range to about a 25-second span as expected. I like the idea of having seconds-level resolution while seeing 5 minutes of data with by-second updates, but it REALLY needs it to be consistent across graphs. I suspect there's a bug in there somewhere, but while you're at it - make it so that humans using logic can comprehend the application.
2. There should be ONE button on each graph that selects it for deletion - NOT - clicking ANYWHERE on the graph 'tells' the UI that you're about to drag it to the garbage can. Drag and drop might have been a fun exercise for those learning JavaFX, but it's a truly silly 'feature' for a tool that's about precision.
This is made the app maddeningly difficult to manage when running tests through a Remote Desktop Connection into a controller that's co-located with the performance test environment. With the ENTIRE app looking to pick up click/drag and drop actions I can't get anything useful done without being
VERY
VERY
VERY
VERY
VERY
VERY
VERY
CAREFUL
about where I click on the screen. If I release the mouse at a time when the RDC connection "thinks" I didn't release the mouse click then suddenly the graph is ghosting under the mouse and is getting dragged all over the screen. Aside from being amazingly annoying, it can be
VERY
VERY
VERY
VERY
VERY
difficult to release - and sometimes it disappears altogether because the workbench 'thinks' I meant to drag it to the trash can.
3. User should be able to mouse over/right click on the graph legend to see *what* exactly is being traced. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
4. Zoom Tool needed: The user should be able to 'draw' (by click and drag) an X-Y grid/box over an area of a graph to zoom in (essentially 'breaking' zoom/follow sync with other graphs) to view an area in detail. Then, the 'Sync' button should snap the zoomed graph back to tracking with the baseline zoom/follow setting. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
5. Graphs should be re-sizable. Seriously. The children's toy UI for this app makes me want to slap the first European software designer I see. Fortunately there are only French Canadians in the office from time to time - and they merely rate an aggressive look to keep them in line. But seriously - again - there should be a button/control/handle to collapse/expand the graph to a Y-scale that's useful to the user (i.e. I want to see more graphs at once)
(see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
6. Graphs should be 0-scalable. Wow. Really? Do I have to state this 'out loud'?
7. Graphs should have an option to 'lock' the scale baseline (Y-axis start point) at the outset of the test run.
8. Monitors in the Components views should take the (unique) name given to them when they're created. I have four app servers that I'm monitoring via SNMP and the component drop-down doesn't show me WHICH app server I'm graphing.
THIS.
IS.
INSANITY.[/font:37638p7f]
Aside from the annoyance, it robs me of the chance to have stacked graphs where the style is aligned per app server across separate graphs (one for CPU, one for IO, one for disc, etc)
WE HAVE TO SHOW THESE GRAPHS TO OTHER USERS WHO NEED TO BE ABLE TO FOLLOW THE LOGIC EASILY.
THIS.
IS.
TOO.
DIFFICULT.
WITH.
LOADUI.
I had to invest a considerable amount of time extracting raw data and curating/graphing it in Excel to get an executive to look at any work product. Furthermore, it's IMPOSSIBLE to convince an operations manager that the Netscaler is misconfigured when EVERY CHART has a different color assigned to a particular app server.
These missing details exact a specific opportunity cost that robs loadUI of potential value as a tool to communicate to other working groups. The reporting is something I'm not even going to comment about here. I'll save that for another post. In short,
SPEED KILLS
CONSISTENCY MATTERS
9. There really need to be a split-pane view between the primary loadUI interface and the Stats Workbench. I spent a LOT of time just trying to get to the point where I could have *just* the right graph in view so that I could context-switch to the primary loadUI interface and make changes to the Generators.
MORE.
INSANITY.[/font:37638p7f]
Extra credit goes to putting the VU Gen controls directly on the Stats Workbench main view to control load drive while looking at graphs without switching app views/context. Dare I dream?
10. The Stats Workbench should manage JVM memory better. If it starts to run out of headroom - it should 'trap' and warn the user to either stop the test or some other action that will load data. I had a 35-minute run that was critically important - getting really good findings - on the day of a go-no-go decision. The Status workbench crapped out when I tried to generate a report, and after reloading the app the previous run data would not run/load so I 1) couldn't see the data, and 2) couldn't generate a report from the app. I was able to extract the raw data and graph in Excel - but again, this is time-consuming. I think there are bugs in this area that can and should be addressed.
1. There should be one button control to put all graphs in the statistics workbench in the same PRECISE zoom and range.
ONE. BUTTON.
EXACTLY IN SYNC.
Right now you can set two graphs to 'seconds' and one will scale to minutes and the other will auto-range to about a 25-second span as expected. I like the idea of having seconds-level resolution while seeing 5 minutes of data with by-second updates, but it REALLY needs it to be consistent across graphs. I suspect there's a bug in there somewhere, but while you're at it - make it so that humans using logic can comprehend the application.
2. There should be ONE button on each graph that selects it for deletion - NOT - clicking ANYWHERE on the graph 'tells' the UI that you're about to drag it to the garbage can. Drag and drop might have been a fun exercise for those learning JavaFX, but it's a truly silly 'feature' for a tool that's about precision.
This is made the app maddeningly difficult to manage when running tests through a Remote Desktop Connection into a controller that's co-located with the performance test environment. With the ENTIRE app looking to pick up click/drag and drop actions I can't get anything useful done without being
VERY
VERY
VERY
VERY
VERY
VERY
VERY
CAREFUL
about where I click on the screen. If I release the mouse at a time when the RDC connection "thinks" I didn't release the mouse click then suddenly the graph is ghosting under the mouse and is getting dragged all over the screen. Aside from being amazingly annoying, it can be
VERY
VERY
VERY
VERY
VERY
difficult to release - and sometimes it disappears altogether because the workbench 'thinks' I meant to drag it to the trash can.
3. User should be able to mouse over/right click on the graph legend to see *what* exactly is being traced. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
4. Zoom Tool needed: The user should be able to 'draw' (by click and drag) an X-Y grid/box over an area of a graph to zoom in (essentially 'breaking' zoom/follow sync with other graphs) to view an area in detail. Then, the 'Sync' button should snap the zoomed graph back to tracking with the baseline zoom/follow setting. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
5. Graphs should be re-sizable. Seriously. The children's toy UI for this app makes me want to slap the first European software designer I see. Fortunately there are only French Canadians in the office from time to time - and they merely rate an aggressive look to keep them in line. But seriously - again - there should be a button/control/handle to collapse/expand the graph to a Y-scale that's useful to the user (i.e. I want to see more graphs at once)
(see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at)
6. Graphs should be 0-scalable. Wow. Really? Do I have to state this 'out loud'?
7. Graphs should have an option to 'lock' the scale baseline (Y-axis start point) at the outset of the test run.
8. Monitors in the Components views should take the (unique) name given to them when they're created. I have four app servers that I'm monitoring via SNMP and the component drop-down doesn't show me WHICH app server I'm graphing.
THIS.
IS.
INSANITY.[/font:37638p7f]
Aside from the annoyance, it robs me of the chance to have stacked graphs where the style is aligned per app server across separate graphs (one for CPU, one for IO, one for disc, etc)
WE HAVE TO SHOW THESE GRAPHS TO OTHER USERS WHO NEED TO BE ABLE TO FOLLOW THE LOGIC EASILY.
THIS.
IS.
TOO.
DIFFICULT.
WITH.
LOADUI.
I had to invest a considerable amount of time extracting raw data and curating/graphing it in Excel to get an executive to look at any work product. Furthermore, it's IMPOSSIBLE to convince an operations manager that the Netscaler is misconfigured when EVERY CHART has a different color assigned to a particular app server.
These missing details exact a specific opportunity cost that robs loadUI of potential value as a tool to communicate to other working groups. The reporting is something I'm not even going to comment about here. I'll save that for another post. In short,
SPEED KILLS
CONSISTENCY MATTERS
9. There really need to be a split-pane view between the primary loadUI interface and the Stats Workbench. I spent a LOT of time just trying to get to the point where I could have *just* the right graph in view so that I could context-switch to the primary loadUI interface and make changes to the Generators.
MORE.
INSANITY.[/font:37638p7f]
Extra credit goes to putting the VU Gen controls directly on the Stats Workbench main view to control load drive while looking at graphs without switching app views/context. Dare I dream?
10. The Stats Workbench should manage JVM memory better. If it starts to run out of headroom - it should 'trap' and warn the user to either stop the test or some other action that will load data. I had a 35-minute run that was critically important - getting really good findings - on the day of a go-no-go decision. The Status workbench crapped out when I tried to generate a report, and after reloading the app the previous run data would not run/load so I 1) couldn't see the data, and 2) couldn't generate a report from the app. I was able to extract the raw data and graph in Excel - but again, this is time-consuming. I think there are bugs in this area that can and should be addressed.
