Hi all, The interface for whiteboard planned moves definition is at an early prototype stage, and I need help determining which of the two UI approaches explained below is best. I'd rather avoid wasting time on refining an interface that proves to be less-than-optimal.
As a reminder or for those who never read it, here's the project page<http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba>; a few UI and technical details have evolved since it was updated, but the overall concept is the same. *Please do not reply if you haven't built and tested both prototypes !!!* As much as your opinion is appreciated, throwing advice around without a common basis won't help at all. - *To start the whiteboard* for either prototype, type :debug and :whiteboard (or :wb). - For a real quick test, launch "wesnoth --test --debug" and type ":wb" once you're in the test scenario. - There are several known crash bugs and visual glitches. No need to report these. - Don't be too impatient with the interface (i.e. don't stress test it), some things like selecting a unit while another's move is animated causes problems. *Prototype A ("dst ghost prototype" / "show future position"**)*: destination unit shown as ghost, and source/origin as regular unit. [The mockups<http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba#Mockups_for_various_interface_elements>on my project page are based on this solution.] SVN rev. 43513 - To execute moves in prototype A, define the same move twice. There are no hotkeys since they were implemented in a later revision. *Prototype B ("dst real prototype" / "pretend the unit is already there"**)*: destination unit shown as regular unit, and source/origin as ghost SVN rev. 43605 - To execute moves in prototype B, use the 'y' key. You can erase moves with 'h'. * The main question* that needs answering is whether the approach of prototype A or prototype B is better: is it preferable to show the dest. unit as a ghost, or with the appearance of the real unit. Factors to consider: - With prototype B, dealing with the potential intrusions of WML events is difficult. Units are perceived by the player to be at the new position he planned for them. However if any of those units is affected by the WML event, this happen at its current, real location in the unit map. Therefore the unit needs to visually jump back to its original position, to be affected by whatever the event does. This is a challenge to represent visually. - Again with prototype B, "select" events are problematic since I'm told they can show custom menus; but whatever effect the commands in the menu have they probably assume the unit is at its src location. The only solution I found is disabling "select" events for any unit that has at least one planned action. *Secondary questions*: 1. What works better, almost-transparent arrows that highlight on mouseover like in prototype B, or clearly visible arrows (that also highlight on mouseover) as in prototype A? Which kind of arrow is best for which prototype's approach? 2. Is it necessary to allow defining several moves for the same unit? Such as planning "move unit X, then move unit Y, then move unit X again"? (It's essential if we want to allow planning in advance the moves of 2 units that want to swap places.) 3. Assuming we want the whiteboard to be usable exclusively with the mouse, what kind of interface could we use for that? Example solution: double-clicking the destination could execute a move, and deleting moves or executing all in sequence would be done with context menus. Drag-and-drop of the dst unit could also be useful, but it's much harder to implement. 4. Once you plan a move for some unit W, you can schedule another unit Z to take its place. This possibility is pretty essential for manoeuvering in tight situations (example, when two units do the three moves necessary to swap places). But this creates an overlap between W's src unit and Z's dst unit. How to deal with that visually, and what should be the mouseover behavior? Thanks in advance for your testing and advice. And double thanks for the generous among you who can provide binaries for the technically-challenged testers. Gabriel aka gabba
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
