VASSAL modules that have to do some kind of processing need a progress indicator–an hourglass, spinning swirley, progress bar, whatever. This issue came up a lot recently when playing the Combat Commander module, which does a lot of calculations about modifiers to attack, defense, and morale modifiers.
Without this indicator, you think that something’s not working, when instead VASSAL may be taking the action you wanted. Which, of course, means that you click again, and nothing seems to be happening…
I’m assuming that the VASSAL framework is where this progress indicator is needed, instead of implementing it at the module layer.
Thanks for taking the time to make a concrete suggestion on how to improve Vassal.
It can be difficult for we developers to ‘stand back’ and see VASSAL with a clear-eyed persepective. Real concrete design ideas with implementation suggestions make life SO much easier for us.
It’s also difficult to get around and see the hundreds of modules available to see what needs to be done to suit specific modules.
I have added
RFE [2816017] Busy Indicator when Vassal processing
for your suggestion, so it is in the pipeline now.
Once a game has started, Vassal can essentially be in one of 3 states,
Idle
Busy processing a Toolbar button click
Busy processing a Command sent to a Counter
2 and 3 are basically the same, but are fired off from different parts of
the code.
We need some sort of Idle/Busy feedback indicator.
Personally, I don’t like cursors because they always seem to end up
getting confused and the wrong cursor showing, but am open to suggestions.
Perhaps a small widget at the start of the toolbar that changes color or shape to indicate when Vassal is busy?
The problem with a progress meter is that we have no idea how long the operation will take, so we cannot do a proper moving percentage bar. This means you end up with one of those pointless progress bars where the progress is shown going from 0 up 100, then restarts at 0 again and so on until the operation finally completes.
I was thinking of a small image the same size as the toolbar buttons that just flicks between two colors, or two states to indicate busy/idle state.
How about this then? Is kind of boring but more obvious. What about a simple
popup window in center of main map window (always on top of main map window)
that just says “busy” or something like that.
Putting something in the toolbar up top may get overlooked / missed by user.
Having something “popup” like a window dead in the center of the users
screen cant be missed. When its done - poof it turns off and goes away, user
is ready to resume
Personally, I would find that annoying, a subtle reminder is all that is really needed. If we went this route, we would need to build in a delay of, say 1/2 second, so that in the normal course of events, you would never see it. It would only appear when heavy processing gets done.
With a seperate indicator that is always visible, this wouldn’t be a problem, it could flick back and forward between the two states and show the exact status. Something like the attached Icon as the busy state and the Vassal Icon as the idle state.
Well, you can do that, but no amount of fixing is going to make a badly designed, over-engineered module fast enough, nor convince the author to redisign it. I think some sort of busy indicator is a reasonable expectation in an interactive piece of software.
I’d re-phrase the business case a bit, and throw in a couple of extra points:
This feedback mechanism is not only a common convention of application UIs, it’s an expected one. Users are conditioned to believe that, in the absence of an hourglass or similar indicator, nothing is happening. I could track down the references to this point in the user experience (UX) literature, but is it really necessary?
No matter how efficient you make VASSAL, it’s a framework in which people can build inefficient modules.
You can’t predict the future with certainty. Future versions of VASSAL may introduce performance issues that make the indicator that much more useful. (And that’s not saying that the performance issues are necessarily because of mistakes. You might have a thousand users asking for some hot new feature. Unfortunately, there’s no way to implement it without introducing some initial performance hiccups that you’ll have to deal with later.)