As an update, I used the UI tree to undock from a station, which was something I previously struggled a lot with. It was quite tedious, but I was so gratified when I was able to find the button and left-click on it, and then use the context menus to move to another place and dock successfully again.
Since the visualization is already a thing, hopefully it won’t be too difficult to make things a little easier.
Thank you for the clarification. It seems like we can continue with refining the user interface then.
The UI tree under the View UI Tree option should have it all. In case something is missing, I can look into adding that.
The UI nodes there should also come each with buttons to send left and right mouse clicks. If you want to send over key presses or some text from the web UI, that would need an addition.
How can we make it easier for you? Right now, I don’t have a memory of how the process worked for you so far.
One thing I tried was to add navigation using arrow keys to the tree view. I think if I could navigate using arrow key like in Windows Explorer, that would be nice.
It would be a little easier if I could have a way to send clicks to the visible UI without having to drill down through the entire tree. As a trivial example, accessing the undock button in a station takes walking down several nodes, most of which I’m not all that interested in except as ways to get to whereI really want to go.
The arrow key navigation does work well, it’s mostly just the lag time that I find a little hard to deal with, especially when trying to figure out where/what an unfamiliar UI looks like.
The graphical tree visualization is nice if only because it avoids OCR errors, which were a persistent issue with my previous setup, and in theory could make it possible to click on things faster.
I hope this makes sense. I think the tree is ideal for programmers and people who want to inspect the UI but it’s hard to imagine playing the game with it, just because it takes a while to navigate in many cases.
I should try the parsed UI tree instead of the regular one. I honestly didn’t notice many differences on a brief inspection, and maybe it will be a little less confusing. 
I wonder if it might be possible to “bookmark,” parts of the UI tree which are used frequently. Maybe that would help speed up my processing time even if it’s harder to make the entire currently visible state clickable live, so to speak.
Just as another thing that would be good to get streamlined help for, the character sheet display is a nightmare with the current tree view if I want to understand it practically. It makes sense if I read the alt text from the visualization, but the skill groups are buried in hundreds of nearly identical tree nodes. Is it possible to maybe aadd some kind of text search, so I can find a desired node without having to walk the entire tree each time?
Another random thought: overview presets. I have the advantage of running the game on the same machine as my client, so can switch between them as needed, but it would be useful to be able to swap those out without having to do that, just because not everyone is going to run it on the same machine, I imagine.
I’ll stop yammering now
Good point, this reminds me of some shortcuts. These might be less obvious. Maybe I did not mention it before in this thread. Besides the “View UI Tree” option, there is the “View Parsed User Interface” option. That one also contains a tree, but that one has many shortcuts, including one to the undock button. Under the “View Parsed User Interface”, you can reach the undock button via two nodes. In the root node, there is the “stationWindow” field. When you expand that, you already get the undock button in the “undockButton” field.
Developers face a similar problem when they want to read information from the game client: If they started from a generic “UI node”, they have to deal with the raw UI tree structure, which contains some redundancy.
The UI tree in the EVE Online client can contain thousands of nodes and tens of thousands of individual properties. Because of this large amount of data, navigating in there can be time-consuming. The parsed UI tree offers a different view that contains less redundant information and uses names more closely related to the experience of players;
After evolving for some years, this filter function contains shortcuts to UI elements used for popular in-game activities.
Interesting. When I worked on the arrow key navigation some months ago, something did not yet work quite as I wanted, so I classified it as “not done” back then. Looking at it again now, I see one problem: When I use the “up” or “down” arrow when the next node is not expandable, the focus does not go there.
Sure, if you link a memory reading with such a character sheet, I will look into that.
About the text search: Adding a text input and computing a list of matching nodes is relatively simple. The question is how to present the results then.
The text search could display matching nodes in a list and a button on each that would expand the tree to that node and focus it. Is that the kind of text search that you mean?
Hi Michael,
Okay, here is a reading with the character sheet displayed.
I was confused about your comments about the parsed UI, because I don’t think that is working as intended. The tree given by the two radio buttons is identical, starting with UIRootDesktop, andgoing down into the main game windows. The only difference I can see is the displayed information above the tree.
Your implementation for text search sounds like a good one. I think that once that is added, and the parsed UI tree is actually displayed, things will become a lot clearer.
I’m linking the reading below. I Hope it helps.
Some further experimentation here…
I think that the parsed UI isn’t keyboard-accessible for some reason. It’s hard to see the differences between them because I immediately arrow down and find the regular UI tree, but the various parsed UI entries don’t seem to be available when exploring with arrows. I’m able to get to them using advanced screen reader commands but that’s not an ideal experience.
Sorry for the confusion. I hope we can sort this out.
Hi Michael,
HEre’s a reading about the ship hanger. This is one more area I think could use some tabularization, similar to how we did the overview. I think this is a common pattern in the game UI. The biggest problem I have at the moment is that it takes me minutes of fumbling through the tree to find the given item I’m interested in, whereas the overview is an almost perfect experience.
Just wondering what other windows we might be able to apply the same kind of pattern to? I figure that headings can be used to separate the data of one window from another, so there’s no risk of interactive with “inactive,” windows.
Hope this makes sense and that we can do something with it. I am enjoying the game immensely, it’s just hard working with the UI tree, though the parsed version does make things a little easier now I know what’s going on.
This observation surprises me. I loaded the file you linked (Character sheet Reading.json) to take a closer look what difference I see between the two views.
Under ‘Select a view mode’, I get following three options:
I am comparing only the latter two here, ‘View Parsed User Interface’ and ‘View UI Tree’.
Before I expand the root node, they both look the same also on my setup.
After expanding the root node, I get more text in the “View Parsed User Interface” view. The first child node there is labeled “uiTree = …”. That is already different than in the “View UI Tree” view. Under “View UI Tree”, I get a label containing “pythonObjectAddress” as the first child node.
Maybe it is better when I list the first child nodes here as I see them. So here is a list of nodes I see:
Do you get one of those two representations? If these are not readable for you, we probably need to change how it renders the tree to HTML.
What label do you get on the first child node in the expanded root node?
Hi Michael,
I figured out the source of my confusion. The problem is that when I’m using the arrow keys to navigate, only the UI NODES are visible, that is, the arrow keys only move from one UI node to another, they bypassed the parsed nodes completely. Was this intentional, or is it something that can be resolved? It is possible to access the parsed UI tree nodes if I use my screen readers commands to open them, but it is less fluid.
No this is not intentional. Have not heard of such a scenario before. I am not familiar with your setup, but we can explore to see if it can be resolved.
The problem is that when I disable the screen reader special functionality, I’m only able to use the arrow keys to navigate through the list, as you coded. It just skips over the parsed tree in that scenario, though I can navigate it using screen reader commands. I would say that this is a fairly low priority compared to some of the other items I’ve mentioned, such as an ability to handle other windows that are tabular, or make navigating them a little less tedious at any rate.
Ok, then I will focus on finding shortcuts in the two samples you linked.
I will look into Character sheet Reading.json first. What parts of this UI tree do we want shortcuts for?
Looking in an earlier post, I found this:
That means we are now looking for shortcuts to “skill groups”.
Meanwhile, I have an idea how you can to your ship hangar faster: In the inventory window, you also have access to the ship hangar.
In the leftTreeEntries field in the inventory window, you have a tree view that should also contain the ship hangar when you are docked.
I added shortcuts to the skills groups based on the Character sheet Reading.json sample.
Since version 2020-08-26, the parsed UI tree has the characterSheetWindow field. In this window, the skillGroups field contains the skill groups.
Thank you!
I’ve noticed that a lot of my slowness involves having to manually move from one “entry,” type field to another, carefully checking it to see if it’s the one I want. Is there any way to laet the app create HTML tables for these dynamically, so we don’t have to custom code for each one? It would let us get more use out of the “alternate UI,” tab, especially since that already has code for context menus, which is useful everywhere.
Sure, you can let the app create any HTML you want.
This link is broken.
@csharper here is the new link: https://github.com/Arcitectus/Sanderling/tree/master/implement/alternate-ui