Feature request: Unit Cycling Features

[itanasi]

Before creating

• This is NOT a gameplay feature from Civ VI, BNW, or outside - see Roadmap
• This is NOT a gameplay feature from Vanilla Civ V or from G&K - If so, it should be a comment in Missing features from Civ V - G&K #4697

Problem Description

Some players would like a feature to skip past the current selected unit, but then cycle back to it later. This previously was Wait, but apparently that was confusing, and now Wait acts like Next Unit. That is, we set due=false and don't come back this turn automatically.

There is also some concern that Next Unit is silently marking units due=false and so players may unintentionally be skipping that unit's turn, not understanding they won't cycle back.

Overall we should have clarity without cluttering the UI. Please discuss different solutions.

Related Issue Links

#12745 #12308

Desired Solution

Open to discussion

Alternative Approaches

Current situation:

• Next Turn marks current unit due=false and moves to next unit in queue
• Unit Action "Wait" marks current unit due=false and moves to next unit in queue

Additional Context

No response

[sulai]

Proposal A

• the Giant Button shows "Next Unit" and sets due=false, but changes its label to "Skip Unit" if a unit is selected and still has action points to spend. This avoids accidentally letting units skip one turn.
• Currently, when no unit is selected, there's no unit-info-table and the bottom left is empty. Proposal: we add a small "unit summary" info box which sits in the bottom left and has this content:

< 3 waiting, 6 due >

Purpose:

• when no unit it selected, give the player a way to start cycling. we could add a shortcut like . to cycle forward.
• when the Giant Button finished cycling units, it deselects the last one. This window would appear and would leave no doubt about the amount of units waiting a turn, it would show something like < 3 skipped and waiting > or < all units busy >.

Proposal B

• make the Giant Button NOT set due=false. The risk of accidentally skipping units is unacceptable.
• Instead the Giant Button sets done=true, so we have a separate flag for the Giant Button.
• Once all units are done, we check if some of them haven't been decided on yet.
• In case there are matching units, ...
  • that means the player hit the Giant Button but did not give orders to all of the units.
  • we show the player this hint: "This unit has no orders. Click (Wait) to let the unit skip one turn."
  • we reset done and let the Giant Button start cycling again.

This also avoids the mixed use of the terms "Skip" and "Wait" and it avoids accidental skipping when using the Giant Button. We could still implement that "unit summary" info box, that should be always helpful.

Thoughts?

[itanasi]

Fundamentally we have two options. The Giant Button either sets due=false skipping the current unit's turn, which is the current behavior, or Giant Button doesn't and effectively just cycles though all units unless they are given a Wait or other order.

If we want to change the behavior, I feel like we need a very compelling reason and improvement system designed. It may have silent behavior, but people figure it out pretty quickly.

Adding a summary table counting the number of Wait vs Due Orders is a handy use of unused UI space, but I don't feel like gives a lot of useful information. Especially since it doesn't provide immediate feedback as you give orders. Might be nice for at a glance if the number of units you have and potentially spot any that are currently Skipped/Wait, but then finding them requires more thought.

[itanasi]

The crazy 3rd option is move Unit Cycling out of the Big Button into two separate buttons below, and Big Button only is used for other important Next Things TODO. I don't particularly like this option though. Eats up real estate. But would allow two very explicit buttons right next to each other, one for Wait Order, one for Cycle to Next Due Unit, providing very clear contrast.

Total War actually puts the Skip Unit Action button next to their Big Do Mext Thing button.

[sulai]

Adding a summary table counting the number of Wait vs Due Orders is a handy use of unused UI space, but I don't feel like gives a lot of useful information. Especially since it doesn't provide immediate feedback as you give orders. Might be nice for at a glance if the number of units you have and potentially spot any that are currently Skipped/Wait, but then finding them requires more thought.

Finding them is a matter of clicking those < and > buttons present in the summary table. They start cycling just as the same-shaped buttons in the unit info pane are doing. This is what makes the summary table useful: you can start cycling units, even when no unit is selected. Currently, when no unit is selected, we have no way to start cycling.

Proposal C

When the user hits the Giant Button on a unit which has no orders yet, a Dialog appears:

This unit has no orders yet. What do you want to do?

[ ] remember decision and don't show again

[ (o) Order unit to *Ẁait* one turn ]
[ (>) *Cycle* back to it later this turn]
[ Show on map ]

(o) - the icon of the (Wait) unit action
(>) - the icon of the cycle unit button in the unit info pane

I personally like this solution best

• it excels in clarity
• it satisfies all use cases
• it's easy to implement

[najevi]

If we want to change the behavior, I feel like we need a very compelling reason and improvement system designed.
It may have silent behavior, but people figure it out pretty quickly.

I strongly disagree with the sentiment of that second sentence. Leaving a user to "figure out" undocumented, silent behavior is not kind to the user.

As to the first sentence I am re-phrasing (and yes, also refining) much of the same argument/reasoning that I put forward in some off-topic comments for #12745 and presenting below as Proposal D.

The crazy 3rd option is move Unit Cycling out of the Big Button into two separate buttons below, and Big Button only is used for other important Next Things TODO. I don't particularly like this option though. Eats up real estate. But would allow two very explicit buttons right next to each other, one for Wait Order, one for Cycle to Next Due Unit, providing very clear contrast.

I very much agree with the Big button being reserved for the phases of a turn rather than Unit Cycling. The two buttons for cycling forwards or backwards through the unit-queue already exist within the UnitInfo table. The "Wait Order" button rightfully belongs in the Unit-action menu immediately above those cycling/navigation buttons. This is where every other unit order can be found. So your stated goal of those 4 buttons (3 for navigation and 1 for Wait) all being close together is natively achievable in the lower left corner of the WorldView. That screen real estate is already set aside in that much more relevant place on the screen.

Adding a summary table counting the number of Wait vs Due Orders is a handy use of unused UI space, but I don't feel like gives a lot of useful information. Especially since it doesn't provide immediate feedback as you give orders. Might be nice for at a glance if the number of units you have and potentially spot any that are currently Skipped/Wait, but then finding them requires more thought.

I think you will find the section of Proposal D headed "Wait a minute..." addresses the underscored portion of your remark.

I find Proposal D to be a compelling, holistic argument however, you may disagree ... in which case I gladly welcome criticism.

First of all a recap of the precedence established or apparent trends for other phases of a turn and other aspects of the UI. This is important if the UI is to be seen as consistent.

The so-called (Next Turn) - a.k.a. (20) - a.k.a. "things to do" ... button

I understand the fundamental goal of mimicking the Civ V user interface behavior. Keep in mind that Civ V also behaves badly/poorly. Therefore I am not convinced that mimicking that bad/poor behavior is virtuous.

That button, labeled (20) in the Civilopedia article on WorldView, and being discussed here serves a different function that depends upon the phase of a turn:

• Move automated units
• Next turn
• Pick a tech
• Pick a policy
• Found/Enhance a religion
• (Next/Skip/Wait) unit

The oddball in this list is the last one ... (Next/Skip/Wait) unit. It describes a much finer granularity of the turn than a phase in the turn. It really belongs within the UnitInfo pane or the Unit-action menu.

For each of those other phases in a turn that button causes a Picker table to appear (usually full screen) and the user then picks whatever needs to be chosen and then closes that table. I hasten to add that the (Close/Dismiss) button for each of those Picker tables is consistently in the lower-left corner of the screen. That close button is not necessarily the button used to finalize a pick.
Upon return from the Picker table, the (Next turn) button now describes the new phase of the turn that demands the user's attention/management.

Adhering to the apparent trend:

• just as the business of choosing a new technology is left to the TechnologyPicker table
• just as the business of choosing a new policy is left to the PolicyPicker table
• just as the business of choosing a new religion is left to the ReligionPicker table

So too should the business of navigating through the due-unit-queue be left to the UnitInfo table and the dynamically generated Unit-action menu that appears immediately above it. Dynamic because there are different Unit-actions depending on the currently selected unit.

End of summary of the apparent trend/precedence established for other phases of any given turn.

Proposal D

With the above precedence/apparent trend in mind, during that phase of a turn that I am describing as: "manage units with unspent movement/action points" :-

1. Let button (20) display "Task a unit" - I think this is consistent with the messaging used for other phases of a turn.
2. The only action that button ought to perform is to cause the UnitInfo pane to appear in the lower-left of WorldView
   • the initially selected unit can be arbitrary although, it might help a human to remember their previous chain of thought if that unit is the same unit that the user had last selected (i.e. was last managing), whether within the current turn or the immediately prior turn.
3. Whenever the UnitInfo pane is displayed this button (20) should:
   • become disabled
   • have a black background
   • display the following summary of the entire unit-queue
     1. number of units due (these units have non-zero action points)
     2. number of units with zero remaining action points (i.e. spent/exhausted/done/dispatched)
     3. number of units already tasked with an action (whether or not they were tasked during this turn or some prior turn)
        • Yes, this count includes units tasked with the Wait action and also any units tasked with an automated-movement that has yet to complete. (these units also have non-zero action points)

That set of 3 numbers is more comprehensive/inclusive than @sulai 's proposal for a very good reason that is explained in the section of this proposal headed "Wait a minute ..." . Aside from that very compelling and novel reason, there is a certain sense of reassurance or check and balance that I believe any user, new or veteran, can appreciate when they see, in one tidy window, that all of their civilization units are accounted for.

The ever-present alternate way that a user can cause the Unit/CityInfo pane to appear is to click on a tile occupied by a unit (or a city) belonging to the user's civilization.

• In the special case of that selected tile having stacked units, whether (civ & mil) or (mil & mil), then the present day UnitPicker prompts the user to remove the ambiguity of their intended selection.
• In the case when a user has chosen to select a city then
  1. the 3 navigation buttons for the equivalent CityInfo pane should exactly align on screen with the 3 navigation buttons for the UnitInfo pane (The test for this is the "user muscle memory test", described under the next section heading.) AND
  2. (as is the present day behavior) navigating away from that city using one of those 3 buttons should select the last unit the user had chosen

Whenever the UnitInfo pane appears in the bottom-left of WorldVIew it's 3 navigation buttons:- (Prev, Next and Close/Deselect) ought to be located:

1. at the left-hand border AND
2. the vertical position of those 3 navigation buttons ought never change even as the selected unit:
   • Name changes AND/OR
   • Promotions are present or absent AND FURTHER
   • In some special cases when the 'unit' selected by the user is not a mobile unit but rather, is a city, then the on-screen location of those 3 navigation buttons needs to be identical. (deliberately reiterated because this is easily overlooked)

The present day Unit-action menu changes from one unit to the next. There is one important unit action button that ideally would never change on-screen position relative to the 3 navigation buttons in the UnitInfo pane immediately below the Unit-action menu. That button/action is described next.

Wait/Skip/Do nothing/

At any time a unit is selected the user may decide not to spend any remaining movement/action points within the current turn.

That decision should always be an explicit decision made by the user clicking a Unit-action button. Under no circumstances should the UI presume to make this decision for the user. The name of that action ought to be identical for every unit in the game and ideally that action-button would be in the identical (on-screen) position within the Unit-action menu even as the selected unit changes. Refer, once again, to "the user muscle memory test".

I am agnostic as to what that action-button be labelled. I only suggest that consideration be given to the many ways that any single-word label might be _mis_interpreted or have it's meaning "lost in translation". There is adequate room in the Unit-action menu width for multiple words so please, use all of that horizontal space wisely to give the action an unambiguous description. e.g. "Do nothing more in this turn" ... or similar.

Wait a minute ... did I skip a unit that I did not intend to skip?

OK, so recall that I added a third number to the Summary of the status of the Unit-queue? Well here is the reason for that.

I readily admit that it is feature-creep and is more of a QOL matter than anything else. It does however, have the potential to make Unciv UI significantly superior to Civ V UI. You may not realize this until you observe other turn-based games mimic Unciv in this unique aspect of UI design.

As the Due-unit-queue shrinks in size the user reaches a point where there are no more Due units. The (20) button should still be disabled (although, I offer a compelling argument, below, as to why it should turn a shade of Amber) and should display the same three numbers that summarizes the entire unit queue.

• The Due: number will be zero.
• The Tasked: number may be non-zero. I make no assumptions as to whether this number is small or large.
• The Spent: number is not relevant to this aspect of Proposal D.

At this point the user may continue to navigate through the unit queue. The difference between this cycle of navigation and previous cycles of navigation is that whilst the (20) button is Amber the units being cycled are those units with non-zero movement/action points remaining ... even though they may have already been tasked with some action!

• Behind the scenes the UI is keeping track of the user's successive navigation of this slightly abbreviated unit-queue. (It still may be a large number of units!)
  Here is where my pedantic argument about muscle memory, ballistic-eye movements and predictably located navigation buttons really pays dividends. This cycling through the unit queue can happen very quickly so long as the navigation buttons stay in the same spot on the screen. The user's train of thought is never interrupted by a search for wherever that navigation button moved to just because the unit has promotions or the length of a unit name changes.
• Once the user has finished one complete unidirectional and uninterrupted cycle/navigation of Tasked units the UI changes the color of the (20) button and displays (Next turn) just as it does today.
  • In some turns there may first be the (Move automated units) phase to dispatch before (Next turn).

The virtue of this part of the proposal is that the user can have no doubt that they have been shown and had the opportunity to review/modify any and all unit movements OR actions for the current turn. Even those actions that were tasked/assigned in some prior turn.

• No more sinking feeling after that (Next button) has been clicked that "Oh shit! Did I really leave that dumb auto move in effect even after I unwittingly blocked that pathway bottleneck with my whatever unit?"
• Suppose a worker is constructing something that the user wants to stop constructing one turn short of completion (Yes, I am thinking of pre-building roads here but you may have other tile improvements in mind as well.) This final cycle through while the (20) button has turned amber gives the user the opportunity to say, "Oh yes, I'll move that worker along to start construction at the adjacent tile." ... or whatever else the user had in mind.
• There is no special reason (other than elapsed time - which might be a valid consideration for multiplayer) why the user should stop cycling through the unit queue even after the (20) button has turned green or transitioned to (Move automated units) or (Next turn). A paranoid user may very well decide to cycle through in the same direction or switch to the opposite direction of cycling through ... and the UI should permit the human to make such decisions without passing judgement as to how productive or unproductive that user's actions might seem to the code-writer implementing this aspect of the user interface!

The user muscle memory test

List/queue/stack navigation ought to be achievable with the user relying solely on muscle memory to locate the point on the screen to (mouse) click or (finger/thumb) tap to advance forward (or backward) through the list/queue/stack. This so-called muscle memory places no demand on the user for ballistic eyeball movement to re-discover the on-screen location of those stationary/static navigation buttons.

Why is Proposal D compelling?

1. First of all, it is a properly holistic proposal. It is not piece-meal or band-aid like. I respectfully submit that some of the other proposals are band-aid like.

2. No other proposal has addressed the onscreen location of those sets of 3 navigation buttons which are absolutely crucial to the design of a consistent user input experience.

3. Proposal D describes a UI that dutifully works for the human user. The UI coder should not presume that a user is a veteran or a newcomer to the game. The only valid assumption about the user is that the user is a human. Humans bring different personalities and styles to game play. The UI ought to accommodate all styles of game-play that can be imagined.

4. It is a proposal that from the outset, addresses the broadest imaginable spectrum of players.

   • If, while rereading Proposal D, your gut tells you, "Crikey, that sounds tedious/wasteful to me!" ... then please ask yourself the question "Who would want to do this?" If you can't find an answer using your own imagination then please ask me that same question (about whichever specific aspect of Proposal D) and I will very quickly describe a feasible scenario for you.
   • If you can imagine the other kind of player then the smart question to be asking is what option should I put in place to allow impatient players to skip all of this tedious check and balance.
     • When I think of such situations I imagine a right click (or long press) on whichever button to rapidly (if not instantaneously) advance through the remaining units in the queue. Such shortcuts need to be documented of course otherwise an uninformed user might accidentally stumble into it and wonder what the hell just happened!!

[sulai]

I very much agree with the Big button being reserved for the phases of a turn rather than Unit Cycling.

You can turn off to "check for idle units" in the Options.

[sulai]

Thanks @najevi, that's a lot to take in.

Proposal D has a few problems:

• A newbie hitting the disabled button is probably very confused as to what he's supposed to do. There is no clue given that he's supposed to use these tiny prev/next buttons in the unit pane, and he's likely not aware that there's a Wait action he's supposed to use if a unit should just stay. A newbie is likely going to give the unit some order and then finds himself stuck with a disabled button. There's some guidance/education missing here.
• Proposal D doesn't take Android into account, and there's literally no space. Every pixel counts. So "Wait" as a label is worlds better than "Do nothing more in this turn". Also, pressing those tiny buttons < and > is possible with some practice, but it does take some effort and not always works the first time. Playing on smart phone, it definitely works much better to push that Giant Button.

As a rule of a thumb, I think the Giant Button should never get disabled. Not sure if this can currently happen under some circumstance.

| did I skip a unit that I did not intend to skip?

Currently, < and > actually includes due=false units in the cycle. You can check them that way, but it's not very obvious these buttons do that.

What I do like is that little hint window you mentioned, giving information about how many units are still due, etc. That might help players understand what's going on.

[najevi]

Thanks @najevi, that's a lot to take in.

Holistic solutions do demand a great deal of attention but if you read carefully you will see that some of the existing UI components already do what I have described. I include those in my proposal specifically to show how it all dove-tails together.
Verbosity is something I must use because I cannot assume knowledge that all of you take for granted by virtue of your longer history of working together.

Proposal D has a few problems:

* A newbie hitting the disabled button is probably _very_ confused as to what he's supposed to do. There is no clue given that he's supposed to use these tiny prev/next buttons in the unit pane, and he's likely not aware that there's a Wait action he's supposed to use if a unit should just _stay_. A newbie is likely going to give the unit some order and then finds himself stuck with a disabled button. There's some guidance/education missing here.

I could not disagree more! The whole point of replacing button (20) with unit management progress status numbers is to remind the user where their attention ought to be focused in the current phase of the turn. By all means discuss the information that should be displayed where button (20) was but don't lure the user into managing the units in a way that quickly moves them onto the next phase of the turn if, in the process of doing so you inadvertently cause the user to overlook managing one unit or another.

• That accidental oversight is what confused me (just one user) in Civ V and I am sad to report that this confusion has been successfully preserved in the present day Unciv UI.

* Proposal D doesn't take Android into account, and there's literally no space. Every pixel counts. So "Wait" as a label is worlds better than "Do nothing more in this turn". Also, pressing those tiny buttons `<` and `>` is possible with some practice, but it _does_ take some effort and not always works the first time. Playing on smart phone, it definitely works much better to push that Giant Button.

I agree. I am not in a position to examine how Unciv behaves on an Android platform. That is beyond my scope so far as providing feedback/input.

I might suggest however, that Next/Previous buttons are not ideal for hand held platforms. Left-swipe and Right-swipe are more familiar gestures for "navigation" on a hand-held platform. A little searching reveals that Koplin language can support such gestures but I do not presume to understand how useful that might be to Unciv.

Is it the case that the very same Tables/popups are used on the Android platform? Or is there some switch/case style statement that chooses a platform-appropriate popup?

As a rule of a thumb, I think the Giant Button should never get disabled. Not sure if this can currently happen under some circumstance.

Is that rule of thumb based in logical argument or traditional dogma?

| did I skip a unit that I did not intend to skip?

Currently, < and > actually includes due=false units in the cycle. You can check them that way, but it's not very obvious these buttons do that.

Yes, we have discussed this elsewhere and I agree that a button should not make more change to game state than it's label describes it as changing. i.e. No hidden helpers that go undocumented and inevitably lead to a confused/bewildered user.

What I do like is that little hint window you mentioned, giving information about how many units are still due, etc. That might help players understand what's going on.

Good! Because what you have acknowledged here is precisely the solution to your very first point of criticism against Proposal D. viz.

A newbie hitting the disabled button is probably very confused ...

Please think about that a little longer.

[itanasi]

You seem to be very convinced you are correct by stint of fundamental prior opinions in a vacuum. Please try to be kinder and with a bit more humility.

[najevi]

You seem to be very convinced you are correct by stint of fundamental prior opinions in a vacuum.

I am not familiar with the phrasing "correct by stint of" ... so I fear I have not understood your message in this regard.

Please try to be kinder and with a bit more humility.

I have been extremely polite and patient!

That should not inhibit me from being persistent in presenting logical reasoning especially when there is no counter-argument yet written in response.

[itanasi]

I am not familiar with the phrasing "correct by stint of" ... so I fear I have not understood your message in this regard.

Ah, my apologies. Considering your verbosity I had assumed.

That should not inhibit me from being persistent in presenting logical reasoning especially when there is no counter-argument yet written in response.

You have a great amount of zeal and have put a lot of thought into this. However, you also seem to believe your way and only your way is the logical and correct answer moving forward. Insinuating others are missing the point due to blind dogma, punting logistics as out of scope, and snidely insisting someone "think about that a little longer" is unbecoming of a collaborative spirit.

It doesn't matter if you're the smartest person in the world. If you can't express yourself succinctly, with generosity, and in a way others will agree with, it is useless.

To a specific point, it seems the vast majority intuitively understood how the Next Unit button would work and would skip past the unit for the turn. Also players learn from the feedback and quickly adjust as part of learning the UI and the game. There are certainly opportunities to explain during a tutorial or on-boarding for a completely new player, but once it's explained we don't need to explain it every time they press a button.

[najevi]

I very much agree with the Big button being reserved for the phases of a turn rather than Unit Cycling.

You can turn off to "check for idle units" in the Options.

Thank you . I just finished experimenting with that option both checked and unchecked and I can see that unchecking it makes button (20) prompt for (Next turn) ... and never prompt for (Next unit) ... while the user is assigning movements and/or orders to units.

[najevi]

To illustrate the unit cycling user interface that I imagine I generated the GIF below to simulate a user stepping through 6 units in the unit queue.

Overlayed in gold is that area of the Unity/CityInfo pane where I propose the unit queue navigation/cycling buttons (Prev, Next, Deselect/Close) have fixed positions on screen regardless of:

• unit name length
• presence or absence of unit promotions
• unit or city having been selected

For that gold region to have fixed height, some combination of the suggestions made within the comments in response to #12745 would be necessary. I have no preference for one button graphic over another so chose to illustrate one of @sulai 's suggestions in this GIF to hopefully engender some familiarity/resonance/agreement.

• While preparing this I had the, albeit mouse-centrist, thought that maybe the mouse scroll-wheel might be used to cycle through those units! Of course, I realize that would be of no benefit on an Android platform but I am reminded of flick-up/flick-down gestures for scrolling through (and picking from) such lists as "year" or "calendar month" or "date" when that kind of information must be entered on a hand-held device. So I mention that possibility here in case it resonates with anyone else.

Relative to those 3 navigation buttons the proposed (Skip turn) button could quite feasibly be pinned immediately above the (Show more) button within the menu of Unit-Action-Buttons. Highlighted in lavender with purple border. With this illustration I hope you can begin to appreciate:

• how the functionality of the Giant Button is, imho, more than adequately provided by either up-arrow or down-arrow button and
• how the functionality of the proposed (Skip this turn) button can be provided in an unchanging location on the screen

The present day (Wait) button has been given a watercolor-red fill just to draw attention to how that button currently changes position on screen as the selected unit changes. If I have understood the proposal for a (Skip) button correctly then this Wait button will be removed. Is this correct?

• If not then perhaps that (Wait) button should also be pinned immediately above the purple/lavender area. I believe that would very tidily address all unit-action-buttons common to every mobile unit in the game.

Does this help you imagine how these 5 buttons being fixed in place on screen as the user cycles through the queue of idle/due units will facilitate the same functionality that is being proposed for the Giant Button in #12799 and also Proposals A, B and C within this thread?

This is what my perhaps overly-enthusiastic and verbose language elsewhere was trying to describe but clearly failed to do so adequately.

Center-aligned or left-aligned ?

Not strictly on-topic but I hope you will agree the following is relevant to the animated illustration is the observation that center-aligned:

• Unit name,
• Unit promotions and
• Unit stats

bobbing left and right as a user cycles through units tends to pull focus.
Here, I am referring to the unavoidable ballistic eye-movement necessary to take in this information. Were that information to be left aligned then some information would seemingly overlay from one unit to another and that might very well prove to be a serendipitous benefit to the user.

I realize only now that I probably could have given the present-day right-arrow and Close/Deselect (X) button a watercolor-red splotch of color to draw attention to how that pair also jumps left and right as the user cycle through the queue.

I can't easily photo-shop these images to render an example of left-alignment but I can easily imagine it and I reckon it would look quite tidy. What do you think?

[najevi]

Proposal B

* make the Giant Button NOT set `due=false`. The risk of accidentally skipping units is unacceptable.

* Instead the Giant Button sets **`done=true`**, so we have a **separate flag for the Giant Button**.

* Once all units are done, we check if some of them haven't been decided on yet.

* In case there are matching units, ...
  
  * that means the player hit the Giant Button but did not give orders to all of the units.
  * we show the player this hint: "This unit has no orders. Click (Wait) to let the unit skip one turn."
  * we reset `done` and let the Giant Button start cycling again.

Could you please explain the subtle difference between due=false and done=true ?

I am beginning to think that perhaps what you describe as done or decided on might very possibly be the same concept that I was describing in that section headed "Wait a minute ... did I skip a unit that I did not intend to skip?"

[najevi]

Finding them is a matter of clicking those < and > buttons present in the summary table. They start cycling just as the same-shaped buttons in the unit info pane are doing. This is what makes the summary table useful: you can start cycling units, even when no unit is selected. Currently, when no unit is selected, we have no way to start cycling.

Yes, I can visualize that as well. It is a very effective/clever way to draw a user's attention to the lower-left of the WorldView screen for that unit-management phase of a turn.

[sulai]

@najevi I think we have common ground here regarding the layout of the unit info box and the position of the "wait/skip" a turn button. It's on my wish list, but sadly, I currently can't invest the time to try it in code.

Good job on the mockup!

[najevi]

Does the following ring true to you?

From a user's perspective the units a user is responsible for managing may be divided into sets/categories as follows:

(a) Currently has an order (whether assigned within: this turn or some previous turn)
(b) Currently has no order

(i) Has non-zero movement/action points remaining
(ii) Has zero m/a points remaining

The above two pairs of classification are not mutually exclusive. Together they form a matrix of 4 categories: (a-i), (a-ii), (b-i), (b-ii).

Depending on the situation, it may be worth a user's time to step/cycle through a unit with any of the following orders so as to review that order in light of any change in circumstances relative to whenever the order was issued:

• Wait
• Sleep
• Fortify
• Skip turn¹
• Build road
• Build railroad
• Automated-movement

Independent of any of the above, the units may also be divided into two sets according to:
(1) A unit the user has selected at least once during this turn
(2) A unit the user has not yet selected during this turn

Why mention this?

To perhaps influence your choice of words used as you consider changes currently afoot for the UI.

Most notably the excellent idea of a unit summary table visible whenever the Unit/City-Info-pane is not visible.

A potential custom-filter for "cycling" units

If you do agree with my observation about the bulleted list of 7 unit orders then just perhaps there is the potential for a user-customizable 'filter' to determine which subset of units will be stepped/cycled through starting from that proposed summary table and morphing into the Unit/City-Info-pane.

Such a filter may be in the form of check boxes so that any combination of those 7 bulleted orders plus the 6 classifications: (a, b, i, ii, 1, 2) may be selected as the subset of units that are "cycled" through when using the Prev & Next buttons on the Unit/City-Info-pane.

Footnotes

1. "Skip turn" has also been called "Wait" and perhaps is most accurately described as "Do nothing more in this turn" ↩

[sulai]

Agreed. Effectivly the two categories you describe could be summarized with

• A) Idle units that have no order yet (Wait is an order)
• B) Units that still have action points and could receive a (different) order. These are idle units, and non-idle units like waiting, auto-moving, auto-constructing and probably others.

Currently the unit table cycles Idle and Waiting units. I'm not opposed to the idea to cycle all of category B) in the UnitTable, while NextUnit only cycles Category A). I have no strong opinion about that though.

there is the potential for a user-customizable 'filter' to determine which subset of units will be stepped/cycled through

Conceptually, we could allow long-click / right click on the < and >, which would open a context menu and allows to set up such a filter.

[najevi]

Clarifying questions

• A) Idle units that have no order yet (Wait is an order)

To which "Wait" are you referring here? The "wait" that means:

• cycle back to this unit later in this turn? or
• do nothing more with this unit in this turn but resume managing this unit next turn?

Your use of the word "Idle" sounds like it might be the same as what I categorize as { (b-i) , (b-ii) }.

• B) Units that still have action points and could receive a (different) order. These are idle units, and non-idle units like waiting, auto-moving, auto-constructing and probably others.

When you think about what you mean by "... and probably others" does the bulleted list that I gave above ring true for you as an exhaustive list or are there some omissions or perhaps even some invalid entries?

Your (B) sounds like it might be the same as what I categorize as { (a-i), (b-i) }.

Correction

I actually described four (4) categories ... not two. viz.

Together they form a matrix of 4 categories: (a-i), (a-ii), (b-i), (b-ii)

It really puzzles me when (it appears to me that) you minimize (in this case 4 categories into 2 categories) without making crystal clear your logic behind the simplification even if that logic is painfully obvious to you.

If I've understood you correctly this far then the category that is not yet addressed is (a-ii). Are you quite sure there is no need for a user to review the orders (whether unit-movement or unit-action) for a unit that falls into category (a-ii)?

[najevi]

Conceptually, we could allow long-click / right click on the < and >, which would open a context menu and allows to set up such a filter.

Yes, this represents so-called "feature creep" and it was cheeky of me to even mention it here.

[sulai]

To which "Wait" are you referring here?

The "Wait" unit action as it is in the game right now. When a user decides to let a unit "wait one turn", that unit is not idle. However, it still has action points and you could change its order.

@itanasi should we do a poll whether or not we should rename the "Wait" unit action to "Skip turn"? I like Wait, because it is "stays in role". However, "Skip turn" can't be mistaken as to what it does. If we changed to "Skip Turn", we should also change the icon to a curved arrow.

When you think about what you mean by "... and probably others" does the bulleted list that I gave above ring true for you as an exhaustive list or are there some omissions or perhaps even some invalid entries?

I didn't double check your list, but I think it's complete.

It really puzzles me when (it appears to me that) you minimize (in this case 4 categories into 2 categories)

I'm sorry for the confusion. I wanted to reduce the 4 categories to the 2 meaningful ones that could be worth cycling.

This would be the matrix you mentioned:

Unit	no order	has order
has action points	Idle	Still can change order
no action points	Finished non-automated move	Automated and moved already

The upper 2 cells are meaningful to cycle, I called them A) and B) previously. The Big Button cycles Idle units and the UnitInfoBox currently only cycles Idle and Waiting units, but could by extended to all units that we still can change order (has order and has action points).

Slightly off topic, as a user, I would like to have the flexibility to cancel, change or assign long term orders to the units that have no action points (the two lower cells). The game currently doesn't fully support this.

To keep it simple, we could offer the user to cycle one of these in the UnitTable:

• Idle
• Has action points
• All

[itanasi]

Skip is the more common verb. Remember that Wait was originally chosen so that we would come back to the unit when cycling. And it's what people usually mention when I ask about replacing Wait. So we can definitely do that change.

[itanasi]

Slightly off topic, as a user, I would like to have the flexibility to cancel, change or assign long term orders to the units that have no action points (the two lower cells). The game currently doesn't fully support this.

It does, but you need to select the unit first.

Also, don't forget that the full list of units, along with their current commands, is in the Units Overview screen.

[sulai]

You can't change a unit movement destination though, that's what I'm missing (a bit).

Units Overview screen

So it doesn't make much sense to cycle all units. So we're left with only idle (big button) and we could change the unit box to cycle all units with remaining action points. What do you think would that make sense?

[itanasi]

I would also comment that my assumption was the arrows on the table would cycle through All units. Not only Idle units. That's usually the convention in a lot of games.

[najevi]

Oh! Thank you so much!! Your description of the design target specification for the list of units for "unit-cycling" is much clearer to me when communicated in terms of that 2x2 table.

Now that I more clearly understand your intention I think that there is one, albeit thin, slice of (Has order, Has zero action points) that ought to be a candidate for the "unit-cycling" list. That is a unit with Automated-movement order even when that movement has ended for the current turn (i.e. zero action points remaining). As you know that is possible when a certain option is set.

• You may not be able to change that unit's destination but you can give it just one order from the unit-action menu and that is the (Stop-movement) order. So to be thorough such a unit really ought to be on your "unit cycling" list ... if I have understood your design target specification correctly.

There may be another such example that I haven't thought of yet but this is one that is easy to overlook and can lead to a wasted turn or to lost opportunity (if it weren't for save files).

• I just remembered it ... Promote! Units with a promotion available are also candidates for unit-cycling. If the UI is to work for the user then allowing (or nudging) a user to cycle to any promote-able units before giving that unit an action or a movement order would result in that user being less likely to waste a turn by forgetting to promote a unit before giving it an order. Currently the only fool-proof way for a user to not miss a timely promotion opportunity is to (remember to) review the history of notifications accessible via the Overview/Notifications tab.

Unit-cycling primary interface

That niggling thought of a "unit cycling list" filter that each user can customize to their own style of game play keeps recurring to me!

• and the notion of unit-cycling (in either direction) happening in the Unit/City-Info-pane is a hard notion for me to shrug off in favor of the Big Button location.
• if such a filter would also allow units to be reordered (e.g. alphabetically by unit Name) then I would very hastily begin to use letter and/or number prefixes in my custom unit names to logically group units into the equivalent of 'platoons' or 'work-groups' or 'task-forces', etc ... having some common goal or plan of action. This would be a significant productivity improvement and represent a UI that is really working hard for each user's individual style of game play.

Skip turn versus Wait

To me, Skip turn conveys the meaning best. For so long as that order is a part of the Unit-action-menu it is very clear the order is being applied to just that one unit. For me, the association with just the selected unit is lost (or made ambiguous) when such a button is replicated in the top-right of World-View.

There may be yet another verb that might be worth considering.

In a very real sense the verb for "Do nothing more this turn but resume managing this unit next turn" might be described as Sleep (just this turn) ... as distinct from Sleep (until local activity wakes you). So a verb that resembles a short sleep might be ... Snooze!!

[itanasi]

So it doesn't make much sense to cycle all units. So we're left with only idle (big button) and we could change the unit box to cycle all units with remaining action points. What do you think would that make sense?

This would pick up units that already have orders/are Automated but we haven't executed this turn yet. Is that your intention?