ArchSin
   |
Posted - 2009.02.16 14:06:00 -
[1]
As for bit into the UI side, in the usability issues most of you are ignoring the most important question: "Why?"
In the end, all we are still going to get is a system where we move points in 3d space with 2d viewport, wether it is the currently implemented POS-widget or a Homeworld ripoff. Since Devs have been holding on to a current asset so deeply, I'm inclined to believe there is no time nor need to develop new system from scratch due there being more important issues still around; the current system does its job, albreit with usability issues. In order to alleviate the forementioned..
Few keypoints regarding the current implementation of widget:
#1 Change the scaling of widget's controlbox relative camera zoom level instead of fixed to probe scanning range
- The control box should be always displayed in same size in screen; there is never need to see widget covering half the screen nor to see only 3 pixels of it.
- The effect is already implemented in drag'n'drop for scan radius changing in main view.
- This would eliminate the need for zooming in to be able to see the element in first place and the need for zooming out to be able to rotate camera if too close. Also accuracy of positioning the probes would increase dramatically but not remove the need to do so.
#2 Indicator if two or more probes had their results too close and were merged to single
- Add color coding and/or label modification for distinquishing the collisioning probes.
- Highlight/recolor the group of probes with same color that are sharing the same result.
- If single scanning result is selected, only display those probes relating to the hit.
- This would clarify the "must have atleast four hits"-situation and inform user directly of which probes are responsible for not providing otherwise warp-able result.
#3 Undo latest move
- On probe moving, save the original coordinates and ID of the probe affected, with keybinding to reset the previous move-order with the ID.
- Single undo per user(client) is sufficient to cover the accidental missclicks and to prevent abuse of pre-pathing probes along known routes, also doesn't increase count of saved variables in excess.
#4 Reduce reflection in 3d view from control box-widget
- Reflection in the control box widget currently goes from black (#000000) to white (#ffffff) and in its extreme edges is very hard to distinquish from background or other probes.
- Suggestion: Limit the color scale to 25%-75% of greyscale (#3f3f3f to #bfbfbf).
#5 Grouping for enabling control of multiple probes
- When multiple probes are selected, the proceeding command should apply to all those probes; this commonly would be setting scan range, recalling and destroying selected probes.
- If moving is also grouped, it would not accelerate the initial setup per solar system but would render every scan after the first trivial (gameplay balancing issue, doesn't belong here but felt obliged to comment).
#6 Key-modifier to scaling scan radius in main view
- Add a keybinding (eg. holding down shift) to force the scan range mode on when clicking probe radius spheres.
- Commonly the scan range handle of the widget is accidentally clicked when trying to move probe around or rotate camera causing extra clicks.
- User rarely needs to move a probe and scale radius at the same time; This is done most of the cases prior to actually trying to move the probes to correct place when pinpointing a found site, not simultaneously.
#7 Visually notify the user of the axis/plane of which the probe is currently being moved against.
- When moving a probe, add a reference grid or line to 3d view to clarify which direction/plane the probe is moving in.
- Preferably with very thin line for axis, transparent grid for plane.
- Possiblity to cause harmful LOS blocking effect; option to toggle off would be advisable addition.
We come in peace. Stop running away. |