[patch] Graphical Combat Summary

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderators: Committer, Committer

Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12573
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [patch] Graphical Combat Summary

#31 Post by Geoff the Medio » Tue Dec 16, 2014 11:44 am

Dilvish wrote:I strongly assert that people are generally not at all used to assessing bar graphs in terms of sums of area of the different bars, and for most people that possibility wouldn't cross their mind at all.
I would say the same about sums of widths of the bars. Bar graphs indicate relative (and absolute) sizes of things by the height of the bars. When faced with a bar graph with different widths, I'd be initially confused about the meaning. (In this case, having the height of the green bars and the width of the red and green bars also indicate the same thing would be more confusing.)
The total linear width in a bar chart is normally not as important as in Mitten's proposal, but it very often does have some type of significance...
In my experience, "total linear width in a bar chart" is not a thing at all... the x-axis of a bar chart assigns a value on that axis to the bar's position, not its width. Bars are usually all the same width, and usually evenly spaced along the axis. In that case, the area and height of a bar are all proportional by the same factor for all bars.
...I really don't think that humans are nearly so good at adding up areas of differently dimensioned rectangles as they are at assessing a simple linear extent.
Even for equal-width rectangles, adding many small areas / heights visually to compare with a single larger area is problematic, and the point seems reasonable / true from the example you refer to...

So, given the confusion about the different meanings of heights and widths of multiple coloured bars and axes, it seems like it would be best to use a separate indicator to show total fleet strength to remove this difficulty. So, have all bars the same width. Height of the red bars indicates ship max structure, and height of the green indicates current structure. Both scaled so the largest bar fills the vertical space. Total green area indicates fleet total structure, but a separate group of bars per empire also represents the total fleet structures for all fleets.

I also have attached a mockup that, I think, shows how using bar width and height to indicate current structure can lead to very "unintuitive" illustrations.
summary_mockup_edit_single_ship_fleet.png
single ship vs. many ship fleets unclear?
summary_mockup_edit_single_ship_fleet.png (16.35 KiB) Viewed 1021 times
In this case, the green area looks much larger. There is no issue with being unclear about if it's half or one third... it's vastly larger. But it's intending to represent two fleets with the same total current structure. But it looks like the single ship fleet is vastly stronger.
I'm very uncertain [about my area] guess and I had to look very hard at the chart and imagine stacking things up...
I agree this mental addition is difficult... hence above I suggest a separate total fleet structure comparative bar.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [patch] Graphical Combat Summary

#32 Post by Dilvish » Tue Dec 16, 2014 4:40 pm

Geoff the Medio wrote:But it's intending to represent two fleets with the same total current structure. But it looks like the single ship fleet is vastly stronger.
To me it looks extremely clear that they both do have equal current health, and that the top fleet must then have substantially greater max health then the bottom fleet. Any confusion on that point only comes from a strange insistence on intentionally misinterpreting the graph, which no graph is immune to. It also seems there also must be something rather odd going on for this result to be even slightly plausible, perhaps like the bottom fleet having extremely strong shields relative to the top fleet, so the bottom big green bar should indeed be attention-getting.
hence above I suggest a separate total fleet structure comparative bar
Care to even show a mockup of something that you would actually consider acceptable (for the entire/composite display, not just a little total structure comparison bar)?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12573
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [patch] Graphical Combat Summary

#33 Post by Geoff the Medio » Tue Dec 16, 2014 5:17 pm

Along these lines...

The bars for fleets or ships could also indicates loses during the combat similar to meter growth prediction bars for planets.
Attachments
Fleet_Combat_Report_Summary.png
vague mockup
Fleet_Combat_Report_Summary.png (17.81 KiB) Viewed 1016 times

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: [patch] Graphical Combat Summary

#34 Post by Bigjoe5 » Tue Dec 16, 2014 5:45 pm

Dilvish wrote:I strongly assert that people are generally not at all used to assessing bar graphs in terms of sums of area of the different bars, and for most people that possibility wouldn't cross their mind at all.
The issue isn't about how to asses the entire graph - people will assess the graph in terms of what the individual bars mean, and from there, extrapolate a sense of what the overall graph indicates. The won't start by looking at it in terms of some overarching property of the graph like "width" or "total green area". This is why I'm arguing that a representation that would represent the remaining current structure as the total green area is more intuitive: because it means that the representation is consistent between bars (in terms of how much green represents how much health), and no redundant information is shared between the X and the Y of a given bar. This makes the interpretation of the overall graph more intuitive and easier to arrive at.

From the perspective of determining the meaning of an individual bar, it's very much unintuitive that a nearly full thin bar represents a ship with less health remaining than a taller, but very slightly thicker almost empty bar. Geoff's mockup illustrates this quite well.
Dilvish wrote:Even after you've instructed them on the significance, they'll have a tremendously harder time assessing the sum of areas instead of a simple linear extent.
You're right about that, certainly. But that's what the actual labels on the graph are for. Having an unintuitive meaning for each individual bar isn't a fair tradeoff for making it a bit easier to see who has the overall advantage when there's a numerical label right there.
Dilvish wrote:So, assume that the total area is what matters, and then you tell me that the assumption gives poor results. Of course, for ANY chart, if you remove the explanatory labels and then assume it means something different than it does, it's fairly likely to give bad results.
No - assume that by comparing two bars, you could get a good idea of the relative strength of two ships in an intuitive way. To me at least, the most intuitive way is definitely not to compare the length of the base - it's how much green there is.
Dilvish wrote:The idea that the chart is supposed to be readily understandable without any labels or explanation does not make any sense to me and I do not at all think it is possible.
Without labels, no, you're right. Without explanation, definitely, and it's something we need to strive for. I honestly can't think of any graph I've seen in a game that required an explanation aside from the labels.
Dilvish wrote:Also, in an attempt to satisfy Geoff's concerns Mitten has proposed some changes which you don't appear to acknowledge or address at all.
The label stuff is irrelevant to my point. His other suggestion, which is to have constant width, is an improvement, but still awkward, as the scaling is inconsistent between empires.
Dilvish wrote:Mitten's code is fairly easy to modify. I suggest that anyone wanting to propose some different significance to the graph dimensions actually try the thing both ways in gameplay, and take any graphs for discussion from actual screenshots so that you can be sure they are internally consistent or else they make a rather poor focal point for discussion.
Code-first, design-later is neither a practical nor a desirable approach to game design.

Geoff's most recent mock-up is better than anything anyone has posted thus far. As long as it's practical to have consistent scaling between empires with that kind of representation, I'm all for using that one.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [patch] Graphical Combat Summary

#35 Post by Dilvish » Tue Dec 16, 2014 6:22 pm

Bigjoe5 wrote:
Dilvish wrote:Mitten's code is fairly easy to modify. I suggest that anyone wanting to propose some different significance to the graph dimensions actually try the thing both ways in gameplay,...
Code-first, design-later is neither a practical nor a desirable approach to game design.
Mitten had already put plenty of time into design before he coded up the feature and proposed it for testing/evaluation. Much of the critique and alternate suggestions put up here in response looked impractical and/or poorly thought out. Since testing out many of the alternatives discussed is trivially easy as a refinement to the posted patch I think that it was entirely suitable to suggest that the person pushing for them does indeed try them out. I think that's entirely suitable for refinements to UI issues which really sometimes do need to be actually used to make any significant assessment of it.
Geoff's most recent mock-up is better than anything anyone has posted thus far.
As near as I can tell, the only modifications here to Mitten's last proposal are moving the current/total fleet health numbers to the very top, adding a corresponding bar, and then having all the graphs having the same scale for their vertical axis. Plus the possibility of having the bars be narrower rather than using all the available space. I'm just pointing that out because it just feels like Mitten's work has caught too much criticism here and not enough appreciation. This latest suggestion looks fine to me, and I hope that Mitten likes it enough to make the changes and so this feature can get into the game.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: [patch] Graphical Combat Summary

#36 Post by Bigjoe5 » Tue Dec 16, 2014 6:33 pm

Dilvish wrote:Mitten had already put plenty of time into design before he coded up the feature and proposed it for testing/evaluation. Much of the critique and alternate suggestions put up here in response looked impractical and/or poorly thought out.
I've never found a single person's design better than what can be produced by a group of people evaluating and making suggestions.
Dilvish wrote:Since testing out many of the alternatives discussed is trivially easy as a refinement to the posted patch I think that it was entirely suitable to suggest that the person pushing for them does indeed try them out. I think that's entirely suitable for refinements to UI issues which really sometimes do need to be actually used to make any significant assessment of it.
That's probably fair. Unfortunately, I don't have my dev environment set up.
Dilvish wrote:As near as I can tell, the only modifications here to Mitten's last proposal are moving the current/total fleet health numbers to the very top, adding a corresponding bar, and then having all the graphs having the same scale for their vertical axis. Plus the possibility of having the bars be narrower rather than using all the available space.
Also, the bars aren't different widths - instead, the height of the bar represents max structure, and the height of the green portion represents current structure, as in a traditional stacked/layered bar graph.
Dilvish wrote:I'm just pointing that out because it just feels like Mitten's work has caught too much criticism here and not enough appreciation.
I don't mean to dismiss Mitten's efforts and design. The only reason I'm interested in this thread is because I think the idea has merit, and is worthwhile to follow up on.
Warning: Antarans in dimensional portal are closer than they appear.

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: [patch] Graphical Combat Summary

#37 Post by Mitten.O » Wed Dec 17, 2014 9:03 pm

I have not encountered any situations like those in Bigjoe5s mockups in actual games, and feel that they are somewhat contrived, but on a theoretical level, he does have a point. He is at least correct in that this sort of thing is best formulated through discussion. A good balance between conveying as much information as quickly as possible to an experienced player and not scaring a novice is precarious, and I feel he and Geoff are on the side of the novice here.

I also think that deciding this requires some playing around with possibilities. In the interest of such toying, and potentially also as a solution to the novice-expert balance, I started to make the bar very configurable. I have been busy lately and haven’t had time to make it very good, yet, but the discussion is getting so lively that I'll just post what I have now to add more data for consideration.

The idea in these changes to the patch is to try and move all the logic about the bars into one place, so that it can be modified (by hard coding and options) centrally without having to deal with the details of the Wnd hierarchy.

A reminder: This creates a savegame incompatibility, so you'll need to play a game with the patch on to get a savegame with the proper data. (One could make it tolerate older saves with a bit of extra work I suppose).
Note: This patch isn't actually tested against the current master (more than that it compiles), since I am affected by the static initialization deadlock there is a thread about.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Any code by me in this post is released under GPL 2.0 or later.

User avatar
Vezzra
Release Manager, Design
Posts: 5186
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: [patch] Graphical Combat Summary

#38 Post by Vezzra » Thu Dec 18, 2014 12:20 pm

Mitten.O wrote:Note: This patch isn't actually tested against the current master (more than that it compiles), since I am affected by the static initialization deadlock there is a thread about.
Revert to r7784 and work based on that rev. The deadlock issue was introduced in r7786.

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: [patch] Graphical Combat Summary

#39 Post by Mitten.O » Tue Dec 23, 2014 8:24 pm

Well, it seems the discussion slowed down. That's as well, it gave me the time to make a proper version of the configurable toy. And I already found a pretty sweet option with it.

First, some motivation:
There are three things which I think the user needs to find out here.
1. How much health do I have relative to the enemy?
2. Does the health come from many low health ships or a few high high health ones?
3. Is that ship there a weak ship at full health or a strong ship at low health?

My original design achieved all these goals by using two dimensions to convey the information. This was found confusing by some and useful by others.

But now I came up with another way. With the default options in this patch, information is only conveyed with one spatial dimension, while the rest is coded in change of colour. I think this works delightfully.

In this option, the width of a ship is it's current health and therefore those widths summed is the health of the fleet. That covers points 1 and 2. The third point is conveyed by tinting the bar more red or green depending on the percentage of it's health it has left.

There are also quite a few toggles you can use to inspect other possibilities and it should be relatively easy to add new ones if you feel like it. They are not meant to be a permanent part of the UI, at least not at this granularity, just an aid in figuring this out.
Attachments
freeorion.graphical.coloured.png
My current favourite.
freeorion.graphical.coloured.png (34.23 KiB) Viewed 986 times

[The extension patch has been deactivated and can no longer be displayed.]

Any code by me in this post is released under GPL 2.0 or later.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12573
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [patch] Graphical Combat Summary

#40 Post by Geoff the Medio » Tue Dec 23, 2014 9:20 pm

Mitten.O wrote:I think this works delightfully.
Unless someone is colourblind...

I don't mind using colour to indicate things, but as the only indication, I'm hesitant.

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: [patch] Graphical Combat Summary

#41 Post by Mitten.O » Tue Dec 23, 2014 9:35 pm

Not the only. The same information is available in numeric form in the tooltip.
Plus, we can have some toggles in the final version also (Maybe in the options window).
Any code by me in this post is released under GPL 2.0 or later.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [patch] Graphical Combat Summary

#42 Post by Dilvish » Tue Dec 23, 2014 9:48 pm

Geoff the Medio wrote:Unless someone is colourblind... I don't mind using colour to indicate things, but as the only indication, I'm hesitant.
What about if one of our UI settings were for color gradient choice, so that folks who are partially colorblind could choose a setting that would still work for them. Anyone who is totally colorblind will already have a great deal of difficulty with the game, and while it's great to give them as much support as possible it sounds like we both agree we shouldn't rule out a feature simply because it would not be useful to someone who is totally colorblind.

A color gradient setting could for most flexibility allow the user to choose both end colors, with the defaults being green and red as Mitten has proposed. This same option choice could also be used to guide the color selection for other UI elements-- I seem to recall this same issue being raised regarding the blockade/warning red/yellow indicators used in the fleet movement projection lines. So instead of a fixed red/yellow those could be keyed to the far end color and a mid-range color (so with default settings would still be red/yellow).
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12573
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [patch] Graphical Combat Summary

#43 Post by Geoff the Medio » Tue Dec 23, 2014 10:22 pm

Dilvish wrote:What about if one of our UI settings were for color gradient choice...
It could be based off of the existing increment / decrement colours.
Attachments
colours.png
colour options
colours.png (12.89 KiB) Viewed 980 times

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: [patch] Graphical Combat Summary

#44 Post by Mitten.O » Tue Jan 06, 2015 12:30 pm

I made the colors configurable. Still has the buttons for testing various representations.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Any code by me in this post is released under GPL 2.0 or later.

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: [patch] Graphical Combat Summary

#45 Post by Mitten.O » Sun Mar 01, 2015 1:27 pm

At long last I get back to this. I rebased this on top of the current SVN so that it applies again.

I also added versioning to the saving of the historical information. You can now load saves made without this patch. Just don't try to look at the summaries of combats that happened without the patch. This should make it easier to try the patch, as you can now load a save and immediately have a glorious battle with your magnificent fleet instead of having to start from the beginning to see a graphical summary.

BTW: I noticed that the windows 7 file copy progress indicator is a multi dimensional graph. Yes, the details are entirely different, but I feel quite vindicated in my initial premise, which is still not on by default in this one, since I think the colourful one is even better.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Any code by me in this post is released under GPL 2.0 or later.

Post Reply