Monday, July 8, 2013

Against Z-axis Arrows in Scanning

Odyssey has come and been patched N times now.  CCP has certainly made exploring easier.  They made many changes to the UI that make it easier to control.  For example, it used to be that without keyboard modifiers, operating on a probe only affected that one probe.  You had to hold down shift or alt to control all probes collectively.  The situations where you might have wanted to move individual probes were rare, and almost negligible excepting getting your probe pattern established initially.  Whereas you want to move probes as a group almost always.  So, this change is very welcome.

Similarly, being able to pattern probes with one click is a great improvement to the UI.  Unfortunately, the two patterns we are given are not ideal; I'd prefer a more regular 8 probe pattern, and a flat pattern for hunting people.  Ideally there should be user-determined patterns so we can each have what we want.  However, at least it is clear that CCP is aware that what we have now in this respect is not ideal.  They are working on it.

There was one change that I was expected, but which did not occur.  And I don't know if they even know.  (How can they not know?  And yet: there it is.)  That change is removing the ability to drag on the probe-movement arrow which is pointing primarily in the Z axis.

The Z axis is computer-programmer lingo for the depth "into" the screen (which, being 2D, you cannot actually show).  Put another way, the Z axis is near to parallel with the direction of view.  The "Z-axis arrow" is the one that points almost straight "up" out of the plane of your computer screen.  Here's a picture:
Z-axis arrow, seen edge-on in the center.  Image stolen from Penny.
Z-axis arrows are hard to see, because they are thin and you are looking edge-on.  But they are hittable, and dragging on them moves the probe-group in the Z (depth) dimension.  Although this is logically consistent with how the arrows behave otherwise, it is also bad.  Allowing this drag is just terrible user-interface design; nobody could possibly be using it intentionally because you simply cannot tell where a probe is depth-wise.  When you do drag a Z-axis arrow, it is always a mistake.  And the effect is not even neutral, which might be more tolerable.  Rather it retards what you are attempting to do.  If you had your probes close to centered where you wanted, now you don't.  They are some random distance up or down in Z.  You will have to do at least one more 90 degree rotate and adjust, and probably two, since you failed to do the one you were expecting initially.  You may also have to re-zoom the view if you happened to get really unfortunate and send the probe position a zillion AU, which is quite possible.

Adjusting probes by dragging on the square itself is superior to using the arrows; the arrows have their limited uses, but the "power prober" almost always searches faster by adjusting two dimensions at once.  And yet, dead center in a UI element (the cube) that does one thing (planar adjustment) is a teensy tiny, almost invisible UI element (the edge-on Z arrow) that does something completely different -- and completely unwanted.  But it is easy enough to hit accidentally that I still do it almost every time I scan down a system.

Is this broken?  No.  But is it annoying?  Hell yes!  It really does make we wonder if nobody at CCP who works on this code actually does exploration.  I imagine them doing a very limited amount of exploration, where they only use the arrows to adjust things.

There are two fixes I think I'd be happy with.

One way to go would be to leave the UI drawn as it is, but make the arrows insensitive when they are sufficiently parallel to the Z axis.  Ideally I'd like to be able to grab the cube instead (this is always what I am trying to do).  But if it were simply a no-op, I could probably live with it.

The better way to deal with it is to not display the arrow when it is pointing mostly in Z.  This is the better UI.  To show a control element at all is to suggest it is there for a good reason and that it can be profitably interacted with.  In this case, there is no good interaction with the arrow once it gets to an angle of perhaps 45 degrees or less with Z.  So, stop drawing it then.  (Indeed, if the "don't draw" angle were as large as 60 degrees I think that would be even better.)

1 comment:

  1. I tend to drag using boxes, altering two dimensions at once, and this has been a problem for me for a while too. I've also noticed that if an erroneous z-axis drag is significant, the probes can now all become clustered in to one big ball, losing the formation you had. This is on top of them zipping off a few hundred AU out of the system. Maybe the pattern can be recovered, with the new pattern options, but it's still frustrating and takes time to correct.

    I'm not sure about not drawing the arrows when they are barely visible. It seems the kind of change that would attract bug reports. But I really would like it if they weren't selectable when they are obviously in a position the player will never want to select them. There is a precedent for this type of change too. With Odyssey, the scanning patch notes (I believe, or it may have been a devblog) said that planets will no longer get in the way of grabbing probes.

    If you remember, prior to Odyssey another issue was trying to reposition a probe that had its box over a planet. You'd select the planet instead. Personally, this wasn't as much of an issue because all of the probe boxes were visible by default too, and I could simply choose a different probe box. But the problem was fixed, and now selecting a probe takes precedence over selecting a planet.

    Similarly, I suggest that selecting the probe box take precedence over selecting an arrow. Logically, this seems to solve the issue. If the arrow and box are coincident, then the arrow is not really in a position to be selected purposefully.

    Maybe the same code that checks if a probe and planet are coincident can be modified or repurposed to do this similar check. If a mouse-click can select both an arrow and box simultaneously, ignore the arrow. No more will probes dash unexpectedly out of the system.