Making the UX closer to popular OS & APPs

[salborrelli]

One thing that I've found quite annoying during game play is that sometimes the effect of pressing a key is not what you would expect, or at least does not match the normal user experience provided by almost all common environments (Operating Systems and popular Applications).

For example, while looking at the BBS I frequently find myself clicking the ESC key, expecting to escape to the previous screen (the Station View), but alas I find myself in the Settings Views instead, with no immediate way to go back to the BBS. Similarly, I have tried to use the Up / Down arrow keys to scroll up / down the list of missions, with no luck: looks like the only way to scroll the list is to use the rightside slider.

An interesting idea (for me at least :-) would be to do a general review of the application in order to make the user experience someway closer to what regular users might expect from their interaction with common operating systems and apps, for example:

1) the ESC key should bring users back to the previous "main" view, at least while in contexts where we expect that to happen
2) the Down / Up keys should allow users to scroll down / up a page in all cases where a scrollbar is available
3) etc ...

Before digging into the code in search of ways to improve to the UX, I would like to hear your opinions and personal experiences. Any suggestion about how to improve the UX by making the game to react to keyboard-related users actions in a more "natural" way?

[impaktor]

I have no objections. It would be nice to arrow up/down menues, but this raises the questions what panel, or scroll bar, is the currently active? Otherwise, nozmajner is the main thinker on UI and layout for pioneer.

Also, for some menues or windows one might not want to be able to ESC from. For instance, for a future thing I'm thinking about implementing where there would be a pop-up window saying "Please stand by while customs are searching your ship" (when landed). I imagine that should be on a fixed timer, and then disapear, without ESC or close possibility.

[salborrelli]

I have no objections. It would be nice to arrow up/down menues, but this raises the questions what panel, or scroll bar, is the currently active? Otherwise, nozmajner is the main thinker on UI and layout for pioneer.

As far as I can see Pioneer is a single - window application, that is there is no use case in Pioneer where the player can be using two different windows at the same time like we do when we work with Excel or Word, for example. So the problem of what is the currently active window shouldn't be too big. And even if it was a multi - window application, the active one is usually the window that owns the keyboard "focus".

Also, for some menues or windows one might not want to be able to ESC from. For instance, for a future thing I'm thinking about implementing where there would be a pop-up window saying "Please stand by while customs are searching your ship" (when landed). I imagine that should be on a fixed timer, and then disapear, without ESC or close possibility.

My personal experience is that users will always try to use the ESC button when they are stuck on a window where they have nothing to do. Even "modal dialogs" like the one you are thinking of implementing should offer a chance to close them. Ok users cannot undock or move the ship or do anything else when they are waiting for help, but they might want to be looking at the ship status, or the map or do something else while waiting for someone to come to rescue. In such a use case we should show the message "Please stand by etc.." but then allow users to close the message window and do what they can do in that context, while disabling all the controls that are not available.

That said I am not thinking of applying the same behaviour (e.g. ESC = escape from the currently active window and go back to the previous one) in all cases of course, but only to the cases where we reasonably expect the ESC button (or the Up / Down arrow buttons, etc.) to work that way.

[impaktor]

As far as I can see Pioneer is a single - window application

We have several places with a split window, like the ship market, or commodity market, or future UI, where it might be unclear if arrow up/dwn is for the left or right panel.

Even "modal dialogs" like the one you are thinking of implementing should offer a chance to close them

Well, my idea was that the game should freeze / be blocked for a couple of seconds during boarding by the law enforcement, possibly showing progress bar. So, it should not be possible to ESC from it. That is the easiest way to make the game behave like that, I think.

Either way, I'm poiting out potential problems, so you know what you're getting into.

[bszlrd]

Keyboard UI navigation would be nice to have for sure.

Esc for "root window" seems reasonable, but might not that straightforward, because there isn't really a hierarchy in most of the screens either in the Station view or the Ship Info view. Ctrl tab, or even simply tab would also be a good and familiar way to switch between the screens, since right now they kinda act like browser tabs. (Although tab might be better fit for focus switching in multi-part windows).

Arrow navigation would be intuitive enough in most parts I think. It could be useful to have an alternative set of keys to it on WASD (+ E or something for confirmation) though, because it's more comfortable if you are right handed and don't want to release the mouse (or leftie, who uses the mouse with your right, like me).

Ship market right now doesn't really seem that problematic, since you can't really do much on the right side apart from scrolling the stats on smaller screens. Once a while ago I mocked up a tabbed way of doing that screen, for in-depth stats, description and such, which might need more thought from this pov if somebody ever considers implementing it. (It's in the UI ideas thread here).

The Commodities market might be a bit problematic too, with it's current way of buying and selling (which needs a bit of redesigning I think), but I guess it can be worked around. Like Up/Down goes trough the list, left and right increases, decreases the amount, and if you have stuff in your hold, then going left puts it to sell, and then you just confirm it.

The Equipment market can be problematic too, but I guess Left/Right could switch between the two sides, since right now you can't set any amount for stuff. Not that this would really be consistent with the Commodities market above.

Repairs and Police screen seems straightforward to me, even if they are implemented a bit differently right now. (Little button for the Police fines, Large button with the text in it for the Repairs screen.)

In the Info Screen (F3) it seems straightforward mostly, since there's only one way of interaction for both the Mission listing and the Crew screen. But I think they might be done in a non-modal way, listing the stuff on the left, and the details of the selected item on the right, so you don't have to open a separate screen to view each item.

The cargo hold might be a bit more problematic, since you have several stuff to do.
Selecting the cargo and jettisoning could be simple I guess. Up/Down for going trough the list, Left/Right for the amount, Enter for Jettison. But it might need a confirmation dialog or something to avoid accidental jettisons.
Refueling and Pump down could have separate hotkeys I guess, indicated by underlining the letter or something.

F4 Comms and Navigation screen is a mess anyway, and on the old UI, so keyboard interaction can be considered when it's eventually gets ported to NewUI. Same goes to most of the Map screens, with the exception of the stuff @jpab worked/works on, like the new System view and Galaxy view.
The Galaxy view is straightforward I guess, Zoom and directions.
The System view could have arrow navigation, but the tabbed info part might need some other way of switching, like Tab or ctrl+Tab, if Tab is used for top level tab switching.

[salborrelli]

Thank you @nozmajner for the lengthy explanation. It seems to me that some additional analysis is required in order to come up with a reasonable plan, but after looking at the issues tracker I realise that I'm not the only one pointing out this problem, see for example #2727 and #2732. Therefore, spending some time doing that further analysis is worth the effort in my opinion.

Maybe going on one step at the time is the wisest, let me do some more testing (an excuse for actually playing the game ;-) and get back to you with a more detailed proposal about the ESC key, for example.

[salborrelli]

I've just completed an analysis of the main views that I think do not correctly respond to the pressing of the ESC key. As a result I've prepared an Excel file with a proposal of how should the game respond to the ESC key on a per view basis, you can check the document out and download it from my Google Drive account @

https://drive.google.com/file/d/0B3YT4w ... sp=sharing

Can you please read the document and send me back your comments? I will complete the Excel accordingly, afterwards I can take care of implementing the new behavior as soon as we reach a stable version.

[bszlrd]

Nice.
Some places where it feels like if it should behave differently in my opinion:

Start - I think it shouldn't quit. The [ctrl+q] working there too would be much more consistent in my opinion. And if it does quit, what happens when the quit prompt is enabled in the settings? Would/should cancel it I guess.
Flight UI - It might be better if pressing it once, it would only pause the game, if already paused, then bring up the settings.

Otherwise it seems consistent to me.
One question is how the going back to flightUI should work? Should it go to front view, or to the state where the player left it? Including internal/external view and head rotation.

[salborrelli]

Good points @nozmajner, I have updated the Excel file accordingly, you can view / download the latest version using the same link.

One question is how the going back to flightUI should work? Should it go to front view, or to the state where the player left it? Including internal/external view and head rotation.

If I go to another view from the Flight UI and then go back to the Flight UI I get the state where I left it, so it seems logical that by pressing ESC I get the same. Basically pressing ESC would be equivalent to pressing F1.

[impaktor]

It would be very valuable with input from robn here, I suspect, or jpab who seems to understand that newUI stuff as well.

Keep in mind: I don't know what I'm talking about, but I had the notion of pioneer's Lua-newUI stacking windows on top of each other, so pressing ESC should just close the top one and the next one is revealed. The only special case might be WorldView, where we might want the settings dialogue box. Maybe I can poke robn in the weekend.