* Another Possible Solution to the Occupants Display Problem
@ 2004-09-06 19:42 Eric McDonald
2004-09-06 20:49 ` Jim Kingdon
0 siblings, 1 reply; 5+ messages in thread
From: Eric McDonald @ 2004-09-06 19:42 UTC (permalink / raw)
To: xconq7
Another thought just occurred to me as to how we might solve the
occupants display problem:
Transport occupied with 2 units:
|------------|
| TTT |
| T |
| T |
| |
| OOO OOO |
| O O O O |
| OOO OOO |
|------------|
Transport occupied with > 2 units:
|------------|
| TTT |
| T |
| T |
| |
| |--------| |
| | Occs | |
| |--------| |
|------------|
Big "T" is transport unit. Big "O" is an occupant unit. Figures not
drawn to any sort of scale or proportion. "Occs" is a button that brings
up a popup containing images of the occupants.
This would be for an 88x88 (64x64) or 44x44 (32x32) view. For 22x22
(16x16), it might be necessary to abbreviate down to "OV" or maybe just
a plain rectangle with no text, since even the small font might be too
tall to fit. For 11x11 (8x8), clicking anywhere in the transport should
probably bring up the occupant view popup.
As to how the occupant view popup would present information, that is
still an open question. I would suggest that it be centered over (and
obscuring the transport), and should always present occ images at least
at 44x44 (32x32), and that the transport's name, location, and
similarly-sized image should be near the top of the popup. This means
that the popup would be variably-sized according to the number of occs.
The benefit is that all of the occs would be shown clearly and in easily
clickable spatial regions. The popup could be dismissed by either
clicking a close box in its upper, right corner, or by hitting the
escape key. Popups could be layered for transports inside of transports.
|----------------------------------------|
| |X X|
| TTT Your transport "Foo" | X |
| T in plains at (x,y) |X X|
| T ----|
| |
| |---| |---| OOO OOO |
| |T | |T | O O O O |
| ||-|| |O O] OOO OOO |
| |---| |---| |
|----------------------------------------|
In the above example, the popup for transport "Foo" shows 4 occs, two of
which are transports as well. The leftmost occ has a popup button in the
lower part of its transport box because it has more than 2 occs. The occ
to the right of it (second from left) only has 2 occs and so they are
displayed as is. The big "X" in the upper, right corner is the close box.
Thoughts?
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Another Possible Solution to the Occupants Display Problem
2004-09-06 19:42 Another Possible Solution to the Occupants Display Problem Eric McDonald
@ 2004-09-06 20:49 ` Jim Kingdon
2004-09-06 22:09 ` Eric McDonald
0 siblings, 1 reply; 5+ messages in thread
From: Jim Kingdon @ 2004-09-06 20:49 UTC (permalink / raw)
To: mcdonald; +Cc: xconq7
> "Occs" is a button that brings up a popup containing images of the
> occupants.
Instead of "Occs" or "OV", I think I'd go with an icon (if someone can
design one which makes sense and fits in 16x8 or so). Or maybe just
"...". That fits in almost any size box and seems to be kind of
logical for what the button does (and indicates). Or maybe just draw
the transport full-size in the "unit in a white box meaning occupants"
which the tcltk interface now uses at 16x16 (hmm, I guess that only
works if the popup is a mouseover, because click means to act on that
unit).
> For 11x11 (8x8), clicking anywhere in the transport should probably
> bring up the occupant view popup.
Yes. Likewise at any magnification for clicking on occupants which
are displayed in the transport (in the 1-2 occupant case).
But it seems odd for click to sometimes mean act on the unit and
sometimes mean bring up the popup. I'm thinking more that the popup
should be a mouseover (although I don't know about things like nested
popups in that context).
> the transport's name, location, and similarly-sized image should be
> near the top of the popup
Also ACPs, materials and plans (hit points optionally, although there
is already a damage bar for that). As long as we are bringing up a
popup, might as well make it possible to avoid having to glance over
to a separate unit details pane.
I'm not as sure about location - it seems like the fact that you get
to the popup from the map maybe means location is reduant. It seems
kind of inelegant to be using a bunch of text if there is some way to
provide the information visually in a contextual way.
Anyway, if the popup has this kind of information, it would be useful
to be able to bring up this popup by clicking on the transport itself
(or a unit with no occupants).
> Thoughts?
I don't remember what the other choices du jour were, but this one
seems promising. Or some variant thereof...
I think the main alternative which is springing to mind is being able
to magnify the map more than you can now (with probably a key or
something which takes you immediately to the maximum zoom which is
needed to see the selected unit and its occupants, or something).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Another Possible Solution to the Occupants Display Problem
2004-09-06 20:49 ` Jim Kingdon
@ 2004-09-06 22:09 ` Eric McDonald
2004-09-07 17:03 ` Jim Kingdon
0 siblings, 1 reply; 5+ messages in thread
From: Eric McDonald @ 2004-09-06 22:09 UTC (permalink / raw)
To: Jim Kingdon; +Cc: xconq7
Jim Kingdon wrote:
> Instead of "Occs" or "OV", I think I'd go with an icon (if someone can
> design one which makes sense and fits in 16x8 or so). Or maybe just
> "...". That fits in almost any size box and seems to be kind of
> logical for what the button does (and indicates).
This seems reasonable.
> Or maybe just draw
> the transport full-size in the "unit in a white box meaning occupants"
> which the tcltk interface now uses at 16x16 (hmm, I guess that only
That's a thought. I wonder how obvious its intended meaning would be for
newbies?
>>For 11x11 (8x8), clicking anywhere in the transport should probably
>>bring up the occupant view popup.
>
> Yes. Likewise at any magnification for clicking on occupants which
> are displayed in the transport (in the 1-2 occupant case).
Hmmm... This would be overriding the meaning of a mouseclick on an unit.
But, I can see the advantage as well....
(If the idea is just get more info on an occ, then switch into survey
mode and click on it.)
> But it seems odd for click to sometimes mean act on the unit and
> sometimes mean bring up the popup. I'm thinking more that the popup
> should be a mouseover (although I don't know about things like nested
> popups in that context).
Wrt the magnifier idea that I had earlier, I had suggested that the
magnifications happen during a mouseover, only if a modifier key is
being pressed.
However, there are really only two universal modifier keys, shift and
control, and I would rather not use either of them for this, as I can
think of better uses for them. Also, there is the issue of dismissing a
popup/magnified transport box. Should it disappear when the mod key is
released? And, if so, then how do you get nested popups/magnified
transport boxes, or, at leat, just the one(s) you want? If we opt to use
escape, then there seems to be an asymmetry: mouseover+keydown to
invoke, but keypress to revoke.
These concerns are what made me shy away from the magnifier idea, and
suggest what I am now suggesting.
To address the question about what a click means....
The idea of using a click to bring up an occs display popup initially
concerned me in the same way that you seem to be concerned. But, then I
asked myself, "Are we really overriding the meaning of a click?" The
fact that we are clicking on a button in the transport box rather than
the transport itself makes me think we are okay in this regard. Context
can be preserved inside the popup boxes. If the cursor is in attack
mode, then clicking on the popup button will bring up a display of occs
to attack (assuming one can attempt such a thing). If the cursor is in
move mode, then clicking on the popup button will bring up a display of
occs that can be entered (after entering/passing through their transport
of course); the move/enter code still needs some work to properly handle
this, but I started looking into it a few months ago. (And got
sidetracked, as usual....) In survey mode, yada yada.... Etc, etc....
The main point here is that clicking on the button is not the same as
clicking on the transport (though at the lowest map zooms, clicking on a
transport may be the same as clicking on the popup button; but, this is
not a big deal, because the transport can be clicked on inside the
resulting popup window).
> Also ACPs, materials and plans (hit points optionally, although there
> is already a damage bar for that).
I might concede the ACP's, and possibly the goal and plan description. I
am less enthusiastic about materials; as it is, I am on the brink of
deciding whether to keep the materials in the unit info panel in the SDL
interface, or whether they should only be displayed (with the
possibility of showing more than 9 of them, and showing their icons, if
they have any) in a popup if a button in the unit info panel is clicked.
> As long as we are bringing up a
> popup, might as well make it possible to avoid having to glance over
> to a separate unit details pane.
I agree with this in principle. The question is what is necessary for
the peruser to make an informed decision. Also, there is the question of
how much info would actually be available to the peruser. If I am
looking for something to attack and click on the popup button of an
enemy's unit view, I can really only know location.
> I'm not as sure about location - it seems like the fact that you get
> to the popup from the map maybe means location is reduant. It seems
> kind of inelegant to be using a bunch of text if there is some way to
> provide the information visually in a contextual way.
Point conceded. I guess this would leave us with name, ACP, health, and
goal and plan. Possibly materials, but I think a materials display
triggered by a button might be better. Most decisions don't involve
in-dpeth knowledge of materials, construction being a possible
exception. If I am attacking or moving, it is generally good enough to
just to see the "SupplyLow" indicator. IMO, the existing materials
display is inadequate and hogs too much space in comparison to its
relative worth.
> Anyway, if the popup has this kind of information, it would be useful
> to be able to bring up this popup by clicking on the transport itself
> (or a unit with no occupants).
This is true. The info on the transport would be more than what is
provided by simply hovering the mouse over an unit. I guess this
bolsters the case for the kind of popup being proposed.
> I don't remember what the other choices du jour were, but this one
> seems promising. Or some variant thereof...
Good.
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Another Possible Solution to the Occupants Display Problem
2004-09-06 22:09 ` Eric McDonald
@ 2004-09-07 17:03 ` Jim Kingdon
2004-09-08 1:29 ` Eric McDonald
0 siblings, 1 reply; 5+ messages in thread
From: Jim Kingdon @ 2004-09-07 17:03 UTC (permalink / raw)
To: mcdonald; +Cc: xconq7
> The fact that we are clicking on a button in the transport box rather
> than the transport itself makes me think we are okay in this regard.
Sure, making it consistently a button would work. What muddied those
waters was the question of what to do at 8x8, where there is no room
to draw a button. Maybe just make people zoom in before they can
click to bring up the occupant popup.
> IMO, the existing materials display is inadequate and hogs too much
> space in comparison to its relative worth.
Agreed on that.
How about one icon for each material. Mouse over the icon to get the
numbers ("5/200"). Perhaps the icon itself would have a greyscale
border from light grey to black for how much is present, or a red
border if LowSupply, or a bar similar to the damage bar (although this
is a problem if reaching capacity is rare) or something.
Of course the real problem here is that so often materials are either
100% or 0% (the latter in cases where this unit type never gets any of
that material).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Another Possible Solution to the Occupants Display Problem
2004-09-07 17:03 ` Jim Kingdon
@ 2004-09-08 1:29 ` Eric McDonald
0 siblings, 0 replies; 5+ messages in thread
From: Eric McDonald @ 2004-09-08 1:29 UTC (permalink / raw)
To: Jim Kingdon; +Cc: xconq7
On Mon, 6 Sep 2004, Jim Kingdon wrote:
> > The fact that we are clicking on a button in the transport box rather
> > than the transport itself makes me think we are okay in this regard.
>
> Sure, making it consistently a button would work. What muddied those
> waters was the question of what to do at 8x8, where there is no room
> to draw a button. Maybe just make people zoom in before they can
> click to bring up the occupant popup.
Well, if a cell is either so small that the popup button cannot be
drawn for any transports in it, or if a cell contains so many
units that they are too small to show any popup buttons, then
perhaps it would be good to extend the idea of the popup
"ellipsis" button to the cell itself. The popup button would be
drawn in the cell itself, depending on the ratio of cell size to
number of units contained therein....
Psychologically, I don't know what impact it would have for a
player to see a single button in the middle of a cell, when the
cell may contain dozens of units. I suppose that, after a while,
one would become conditioned to fear and respect any cell
displaying an ellipsis button with an enemy emblem next to it. (In
the case where a cell contains a horde of seen units of mixed
allegiances, I would probably still opt to place the banner of the
first seen enemy unit next to the popup button, _even if there are
friendlies in the cell, a possibility with ZOC == -1).
And, I think that for really small cells, where a button cannot be
drawn, that the cell itself should be the button. Occupant display
issues not withstanding, this would probably be an improvement
over squinting and hoping that you click the right pixel. Instead,
it would simply be click and then choose a decent-sized unit (or
cell) image in the cell popup window. Or, if the player changed
his/her mind, then he/she would just hit escape. Not much effort,
_probably less than squinting and "precision-clicking". Of course,
I don't know whether there is a big demand for playing Xconq at
such low magnifications.... (Build it and they will come?)
> How about one icon for each material. Mouse over the icon to get the
> numbers ("5/200"). Perhaps the icon itself would have a greyscale
> border from light grey to black for how much is present, or a red
> border if LowSupply, or a bar similar to the damage bar (although this
> is a problem if reaching capacity is rare) or something.
I like this idea, especially the standout border for which
individual materials are needed. Maybe even do a flashing border
for materials that the unit is starving without.
I think the existing mouseover panel in the SDL interface could
accomodate any info we would want to display regarding a material,
though a "tooltip" might also be nice to add at some point.
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-09-07 17:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-06 19:42 Another Possible Solution to the Occupants Display Problem Eric McDonald
2004-09-06 20:49 ` Jim Kingdon
2004-09-06 22:09 ` Eric McDonald
2004-09-07 17:03 ` Jim Kingdon
2004-09-08 1:29 ` Eric McDonald
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).