Forums » Suggestions
I am reading the feedback with interest, please continue.
Much of the UI strangeness comes from serious problems with the underlying UI-system "auto-organizing" in crazy ways on re-scale, or varied resolutions and aspects. So, it ends up being very time consuming to try and "fight" the UI to force things things to work across all the device types, and Ray ends up re-using "known working" (if, often inappropriate) interface dialogues, because the alternative is a dark rabbit hole that may take hours of time and yield only broken results.
We need to replace the entire UI system, and have kicked around options for years (Scaleform, integrating Chromium), but it's a huge undertaking, on the order of several months.
So, more realistically, I may be looking at re-using the current system, and trying to come up with a "new" set of reasonable interface cases, that align more easily to what we (now) know we need (as opposed to the multi-pane stuff "we thought we might need?" on 800x600+ PCs in 2003). That might be worth keeping in mind. A commonality of UX design-language is always beneficial, and all the more so when the development of any one interface "type" is an unknown-quantity of time.
For instance, with integrating all "Character" data into a single panel (Stats/Standings/Accomplishments), that could just be one scrollable field, which is probably doable. And if we do that there, we may also want to replicate the experience across a variety of other interfaces. Thus, coming up with a few common dialogue/window constructs that work effectively for most of our game use-cases (across PC/touch/10-foot).. that's some of the more valuable feedback you can give me, and a big part of what's been sitting on my plate for this UI redux.
Also keep in mind the need for D-pad navigation and skipping between interfaces. One has to be able to navigate entirely with a D-pad and no analog-stick virtual mouse. Some partners will not even approve apps that implement a virtual mouse, as they believe it breaks the optimal console-ness of a purely D-pad UI; we ran into this on AndroidTV and elsewhere. I don't disagree with them, D-Pad is always better given a properly designed UI, but it's been a bitch to quickly retrofit (obviously), and it's something to consider when having long lists of ribbons and factions, in a particular button order, that each have optional information (the current D-pad navigation is bad and has the same problem, but it's one more thing I'm looking to improve in the next rev). Much of the D-pad challenge is in common context (all interfaces work the same), and avoiding time consuming navigation (iteration through a ton of ordered buttons to get to one thing). D-pads can also be a little challenging with complex, sortable interfaces, like what you suggested for Inventory, and what we're moving towards for the mission system, etc.
I appreciate the notion of "jumping" the player to another interface, but in general I prefer to avoid anything that will disorient the user within the UI navigation ("how did I get here?! where was I?"). Modals, as much as I dislike them, are more appropriate to these kinds of cases that yield one-time information (Here's what your "Mining II" ribbon is about, etc).
Much of the UI strangeness comes from serious problems with the underlying UI-system "auto-organizing" in crazy ways on re-scale, or varied resolutions and aspects. So, it ends up being very time consuming to try and "fight" the UI to force things things to work across all the device types, and Ray ends up re-using "known working" (if, often inappropriate) interface dialogues, because the alternative is a dark rabbit hole that may take hours of time and yield only broken results.
We need to replace the entire UI system, and have kicked around options for years (Scaleform, integrating Chromium), but it's a huge undertaking, on the order of several months.
So, more realistically, I may be looking at re-using the current system, and trying to come up with a "new" set of reasonable interface cases, that align more easily to what we (now) know we need (as opposed to the multi-pane stuff "we thought we might need?" on 800x600+ PCs in 2003). That might be worth keeping in mind. A commonality of UX design-language is always beneficial, and all the more so when the development of any one interface "type" is an unknown-quantity of time.
For instance, with integrating all "Character" data into a single panel (Stats/Standings/Accomplishments), that could just be one scrollable field, which is probably doable. And if we do that there, we may also want to replicate the experience across a variety of other interfaces. Thus, coming up with a few common dialogue/window constructs that work effectively for most of our game use-cases (across PC/touch/10-foot).. that's some of the more valuable feedback you can give me, and a big part of what's been sitting on my plate for this UI redux.
Also keep in mind the need for D-pad navigation and skipping between interfaces. One has to be able to navigate entirely with a D-pad and no analog-stick virtual mouse. Some partners will not even approve apps that implement a virtual mouse, as they believe it breaks the optimal console-ness of a purely D-pad UI; we ran into this on AndroidTV and elsewhere. I don't disagree with them, D-Pad is always better given a properly designed UI, but it's been a bitch to quickly retrofit (obviously), and it's something to consider when having long lists of ribbons and factions, in a particular button order, that each have optional information (the current D-pad navigation is bad and has the same problem, but it's one more thing I'm looking to improve in the next rev). Much of the D-pad challenge is in common context (all interfaces work the same), and avoiding time consuming navigation (iteration through a ton of ordered buttons to get to one thing). D-pads can also be a little challenging with complex, sortable interfaces, like what you suggested for Inventory, and what we're moving towards for the mission system, etc.
I appreciate the notion of "jumping" the player to another interface, but in general I prefer to avoid anything that will disorient the user within the UI navigation ("how did I get here?! where was I?"). Modals, as much as I dislike them, are more appropriate to these kinds of cases that yield one-time information (Here's what your "Mining II" ribbon is about, etc).
If you dislike modals, why not try to eliminate some really common ones, like the one that appears for every single call to purchaseprint() anywhere in the PDA/Station UI on Android?
Implement some small dialog that pops up and fades away on its own instead of getting in the user's way every time they buy something, sell something, reload their weapons, repair their ship, etc.
Implement some small dialog that pops up and fades away on its own instead of getting in the user's way every time they buy something, sell something, reload their weapons, repair their ship, etc.
Implement some small dialog that pops up and fades away on its own instead of getting in the user's way every time they buy something, sell something, reload their weapons, repair their ship, etc.
I don't think there's a UI primitive we have that does anything like that. Implementing new UI primitives tends to encounter the same black-hole-of-development like anything else in the windowing system. Many of our internal UI discussions revolve around my asking for something, and hearing back that "it doesn't do that", and that hacking the system to do so may be prohibitively time consuming, with uncertain long-term ramifications (based on other UI changes). Hence, ideally we need something.. else.
We could purely output to the chat-log/console area. But then people might not realize what they're doing, in some cases. We had problems in the past with newbie awareness of what actions they were taking, which I think is when a lot of this stuff went modal in the first place (in alpha). It might be possible to have some kind of selectable setting.
I don't think there's a UI primitive we have that does anything like that. Implementing new UI primitives tends to encounter the same black-hole-of-development like anything else in the windowing system. Many of our internal UI discussions revolve around my asking for something, and hearing back that "it doesn't do that", and that hacking the system to do so may be prohibitively time consuming, with uncertain long-term ramifications (based on other UI changes). Hence, ideally we need something.. else.
We could purely output to the chat-log/console area. But then people might not realize what they're doing, in some cases. We had problems in the past with newbie awareness of what actions they were taking, which I think is when a lot of this stuff went modal in the first place (in alpha). It might be possible to have some kind of selectable setting.
"I get it! Don't show me this again." *click* and dismiss. I know i've seen modal windows in VO like this.
Yes, we can flag individual windows for "Don't show me this again", with a check-box. That's an option too. Basically the same as my "selectable setting" notion, but on a modal-by-modal basis.
Sensor log menu
The information represented in the Sensor Log is both current and historical. Its really two different things and therefore should be renamed "Sensor" and the historical information would fall under "Log" and should be a sub menu of it.
Nearby Ships
This is the most important information. This really is the "Sensor". Get rid of the "Nearby" submenu and make "Sensor" a top level menu item.
This data should include local cargo and roids. I see how some sectors could lag out the experience. Perhaps a Sensor scanning step could be discretionally used by the player to list cargo floating in the sector. I get that there would be some technical limitations to the current or "live" data. So this suggestion falls under wishful thinking i'm sure.
Stations, Killed List, Killed By List, PVP menu
Stations - historical info. I have never used this tab.
Killed List - historical info, redundant tab
Killed By List - historical info, redundant tab
PVP menu - historical info. combat specific.
Solution:
Consolidate these 4 tabs down to one sub menu called "Log". The tabs above are really just sorting items of historical Log data. I'd love to see a chronological snapshot of this data and be able to sort or filter it. Perhaps the chat log would fit here too.
*I'm sure there are some functions in Targetless that could be incorporated into this menu as well though i'm not terribly familiar with that plugin. Is there some happy medium that could include some of the goodies in Targetless and current Sensor and Log data that be appropriate?
The information represented in the Sensor Log is both current and historical. Its really two different things and therefore should be renamed "Sensor" and the historical information would fall under "Log" and should be a sub menu of it.
Nearby Ships
This is the most important information. This really is the "Sensor". Get rid of the "Nearby" submenu and make "Sensor" a top level menu item.
This data should include local cargo and roids. I see how some sectors could lag out the experience. Perhaps a Sensor scanning step could be discretionally used by the player to list cargo floating in the sector. I get that there would be some technical limitations to the current or "live" data. So this suggestion falls under wishful thinking i'm sure.
Stations, Killed List, Killed By List, PVP menu
Stations - historical info. I have never used this tab.
Killed List - historical info, redundant tab
Killed By List - historical info, redundant tab
PVP menu - historical info. combat specific.
Solution:
Consolidate these 4 tabs down to one sub menu called "Log". The tabs above are really just sorting items of historical Log data. I'd love to see a chronological snapshot of this data and be able to sort or filter it. Perhaps the chat log would fit here too.
*I'm sure there are some functions in Targetless that could be incorporated into this menu as well though i'm not terribly familiar with that plugin. Is there some happy medium that could include some of the goodies in Targetless and current Sensor and Log data that be appropriate?
Is there some happy medium that could include some of the goodies in Targetless and current Sensor and Log data that be appropriate?
Please feel free to distill and suggest whatever functionality you think is appropriate (please be specific about what it does and how), and we'll evaluate on a case by case basis.
I've been meaning to use targetless for awhile and see what we can consolidate into the interface, but.. it'd save me time if someone else could get a head-start on that.
Please feel free to distill and suggest whatever functionality you think is appropriate (please be specific about what it does and how), and we'll evaluate on a case by case basis.
I've been meaning to use targetless for awhile and see what we can consolidate into the interface, but.. it'd save me time if someone else could get a head-start on that.
I don't have Targetless installed. I'm sure somebody else can weigh in on this with more authority, but I understand you can save roid data.
This entire discussion has been about the PDA's UI, not the HUD. Targetless' main advantage is displaying nearby object (ship/asteroid) information in the HUD. If you are looking at incorporating targetless -- the HUD is the place to start, not the PDA.
That's right. I've specifically addressed sensor data here which from my memory, Targetless does some of that.
About targetless: I haven't played for a while, but I considered targetless indispensable when I did. So, some things can have changed in the meantime (in targetless or vanilla), but what I really liked was:
- situational awareness, by immediately seeing a list of other ships, with list options for PvP, PvE and normal/capship. When jumping into a system, it is very useful to get a list of ships in the system immediately instead of opening the sensor screen.
- easy targetting, by pressing the numeric key (1..9) corresponding to the list entry (usually 1 is the closest enemy)
- pinning ships to the list and automatically pinning if someone shoots you (so if they move further they stay on top of the list).
It also has roid information persistence, which is very useful for mining, but I never did more than minimal mining so I'm not in a position to comment.
- situational awareness, by immediately seeing a list of other ships, with list options for PvP, PvE and normal/capship. When jumping into a system, it is very useful to get a list of ships in the system immediately instead of opening the sensor screen.
- easy targetting, by pressing the numeric key (1..9) corresponding to the list entry (usually 1 is the closest enemy)
- pinning ships to the list and automatically pinning if someone shoots you (so if they move further they stay on top of the list).
It also has roid information persistence, which is very useful for mining, but I never did more than minimal mining so I'm not in a position to comment.
I installed Targetless and several other plugins. It's great and gives lots of useful data, but I don't see how you're planning to shoehorn that info onto a five inch screen. Perhaps you can add a sensor button to the mobile interface. Though I'd be happy to see the current interface cleaned up before adding more features.
VO straddles a line between the 50 or so PC vets that play the game and actively contribute—for better or worse—to these suggestions, and the 7000 mobile noobs that get pwnd by said vets with bigger screens and various plugins yet bring home the bacon for Guild.
Good luck with that!
VO straddles a line between the 50 or so PC vets that play the game and actively contribute—for better or worse—to these suggestions, and the 7000 mobile noobs that get pwnd by said vets with bigger screens and various plugins yet bring home the bacon for Guild.
Good luck with that!