T3D 4.x UX/UI Makeover (WIP)

[Nils]

I'm working on a UX/UI makeover for Torque 3d 4.x. This will include changes of the current user experience design and  modification of GUIs.

While in the past a theme to copy & paste in the project folder was sufficient, now some changes on the engine side are inevitable to get the wanted results.

The aim of this initiative is to:

• get the most optimal UX with the least impact to the existing code 
• serve new/certain users with a recognizable layout & visual language (equity)
• improve readability & usability, as well simplification where possible (accessibility)
• improve visual appearance & aesthetics / implement graphic design principles
• serve veteran users with certain long time request regarding UX

On the side I will also do/add:

• hints/proposals to visual identity (logo, style, typography etc.)
• add certain functionality in the editors
• solve bugs & issues that hinder the development of this project

Limitations and things to consider are:

• no replacement of current UI framework
• current GUIs all have a relatively fixed design
• unable to get a full responsive design because of above 2
• limited time scope
• "Take it or leave approach" for release(s) 

My apologies up front; I do not have time for: debates, writing extensive blogs, discussing or defending certain design styles or aesthetics. Each person has his own taste and preferences. While serving as much as users possible is equity playing an important role within this initiative; For example some users prefer tabs with text and technical terms for labels, but others with less linguistic skills (or not native English speaking etc.) prefer icons and simplification & clarification of the text. Eventually it is my task to find the balance and optimal outcome for all - this within the limited time scope I have!

As a longtime user of the T3D engine myself (since version 1.2, with the latest 4y dev game published here with a custom 3.5+), being a graphic designer by profession, and recently doing further specializations in UX design; do I think I'm able to contribute something solid, God willing.

Cheers, Nils

 

Dev branch: https://github.com/Eikelenboom/Torque3d-UI-MakeOver

Releases (including binaries): https://github.com/Eikelenboom/Torque3d-UI-MakeOver/releases

 

Please remember this is a work in progress!
Thanks!

[Nils]

Quick Preview of #13 WIP

(the colors are a bit distorted / desaturated)

[Azaezel]

Looking good!. couple quickie notes:
On the ao|rough|metal RGBA bit: That's the channel of the input texture to look up when feeding it in.

https://github.com/TorqueGameEngines/Torque3D/blob/development/Templates/BaseGame/game/core/gameObjects/datablocks/defaultDatablocks.tscript#L19-L63 for the default particle and emitter names to fall back to.

For the profiler, that's a start/stop sample, so might suggest adding a profile 30 seconds button if it's one intended to be clicked for an "immediate" dump.

Should have the other end we'd discussed rolled in some time this week.

[Nils]

@Azaezel

Thanks Az!  

Quote

For the profiler, that's a start/stop sample, so might suggest adding a profile 30 seconds button if it's one intended to be clicked for an "immediate" dump.

Yeah, that's why it's dumping twice (another time when hitting the button 2nd time) but indeed, the 1st dump isn't useful and confusing. Thanks!

[Nils]

UX improvements for the windowed console.

This is also an example for additional button styles for certain uses.

[Nils]

Strange use of values for "Rotation Animation" U & V (Material Editor) Wouldn't it more appropriate to have the the pivot center at "0" and min & max values to "-1" & "1" ?

Anyways, it's too late after a decade off projects being made with these :-\

[Azaezel]

20 hours ago, Nils said:

Strange use of values for "Rotation Animation" U & V (Material Editor) Wouldn't it more appropriate to have the the pivot center at "0" and min & max values to "-1" & "1" ?

Yes and no. While it might make some sort of sense to the presentation side, it would be a straight lie to the user for the math that's occurring, since almost all shader values end up in some form of 0-1 range when dealing with UVs.

[Nils]

1 hour ago, Azaezel said:

Yes and no. While it might make some sort of sense to the presentation side, it would be a straight lie to the user for the math that's occurring, since almost all shader values end up in some form of 0-1 range when dealing with UVs.

Yes that's all understandable, from the mathematical point of view to have the range between 0 and 1. Yet in this case it goes from -1 to -0 as it is using the right-bottom as -1.  But then I'm not all that familiar enough with shaders to get it, probably  *(correction: right-bottom as -1)

Logically, I'm now more concerned with the front-end of things and how things are interpreted there  (but not too long though)

Edited February 3, 2023 by Nils

[Azaezel]

Ah. see what you mean. scroll axis vs rotation point. Was looking at the wrong one. Apologies. 

[Nils]

19 hours ago, Azaezel said:

Ah. see what you mean. scroll axis vs rotation point. Was looking at the wrong one. Apologies. 

Ah no need for apologies Az, really! But thanks, and for your replies

Something else I would like to ask...I noticed these errors in the console for some time:
 

data/UI/scripts/menuNavigation.tscript (288): Unknown command count.
data/UI/scripts/menuNavigation.tscript (78): Unknown command getIndexFromKey.

Also the top menu buttons as "options"  stopped functioning on my side. Haven't done anything with the scripts (yet) and just did some tweaks to the profiles and assets files. I think it started around this time (but maybe off here, not sure)



Would you perhaps know/think what's the issue?

[Azaezel]

https://github.com/Eikelenboom/Torque3d-UI-MakeOver/blob/4x_UI_makeover_/Templates/BaseGame/game/data/UI/scripts/menuNavigation.tscript#L12 sounds like somehow that's not getting tripped your end?

[Nils]

After merging the 'data' folder afresh it seems to be fixed. My apologies, must have likely been a faulty merge on my side. Thanks @Azaezel!

[Nils]

Guess the longer I'm working on this, the trickier merges with the upstream branch becomes 

[JeffR]

Well, game plan is to have 4.1 be the tools/UI update, so we can definitely try and start bringing in the bits to make it part of the devhead to make that less ornerous

Worth noting that the menuNavigation stuff was an attempt to sort of standardize page-to-page navigation with namespace frameworks and stuff, but honestly it ended up being pretty opaque. The better route would be to design tools that let you just build out the nav logic in the GUIEditor direct.

Obviously you can do button commands or the like easy enough, but there's no rules for, say, going "back" or the like. Like say going from the Main Menu into the Options Menu, then backing out and wanting to get back to the Main Menu again.

Easy enough in a vacuum, but if you also have a pause menu, then you want the options menu to back out to the pause menu if that's where you originated from.

So that's the tricky part for figuring out page-to-page navigation stuff in a native context.

 

If you've got any ideas to toss in on the brainstorming side for how we can make menu navigation more like DESIGNING and less like pure code it'd definitely be a spot that could use some refinement I'm itching to polish up.

[Nils]

1 hour ago, JeffR said:

If you've got any ideas to toss in on the brainstorming side for how we can make menu navigation more like DESIGNING and less like pure code it'd definitely be a spot that could use some refinement I'm itching to polish up.

Yes, I understand the situation, I agree with you it's a bit opaque.
I'll need to have a good thought so I can perhaps add something constructive. 

Who would you like to serve in this case; a new user (developer) who has limited knowledge of T3D or the more experienced one?

[Nils]

@JeffRJust brainstorming now:

The options pages are almost completely similar to a GuiTabBook with GuiTabPages. The current controls only allow a tabPosition "Top" and "Bottom". I believe if you'd add "Left" and "Right" positioning of the tabs you can have the same layout but completely manageable in the GUI editor.

The issue with tabPages would be that the tabs are always visible, even when a certain page would need to be hidden and skipped when cycling through. By adding a variable (PersistField) "Exclude deactivated" that simply ignores the GuiTabPages that have the field "Active" set to "false" you solve that issue. At the same time a designer can also choose to keep those deactivated visible (default) for certain reasons, or choose a different layout. Hope I make sense with this description.

Children of a GuiStackControl are easily manageable and can be excluded by setting "visible" to false. I would suggest though to add the option to align the children centered, next to the existing (left, right, top, down) 

For the navigation part, I would consider creating scripts that are really easy to understand can be handled by newbies. The main menu will probable one the first things that a new user involved with design would like to change (I remember I did when I had T3D 1.2 installed or the 1st time) Perhaps considering a mainMenu.tscript and place the functions called from the menu buttons in there. With code like:

if ($missionRunning == true) 
{
	button.setVisible(true);
	tabPage.setActive(false);
}

it might seem a bit low level, but makes it much less opaque. With a simple setup and enough comments I think you'd get enough gratitude from those who are just starting. T3D veterans will likely to just make something (almost) completely new. 

Anyways,  just some thoughts!

Cheers!



 
 

[JeffR]

Not bad ideas. Definitely a solid start.

As for the target? I'd say it's less about experience generally, and more about the skillset of the user. Aka, artists or designers are more likely to be building out GUIs, so making it more visual and less scripty would be the desirable case, i think.

The other wrinkle with navigation is I want the engine to be able to handle at least most of the base UI with a gamepad, as well as the normal keyboard and mouse. Mostly because a lot of people are gunna use gamepads if possible, and the engine does support them out of the box. So that means we need rules for navigating between tabs in the tabbooks or the like too.

I think we can get most of the way there by being able to just flag a tabbook or container as first responder so the system automatically 'focuses' to the navigatable control. Otherwise I do agree, expanding out how to organize tabs, and also being able to show/hide those to make them work like stacks would prooobably cover a lot of the baseline behavior.

[Nils]

As a new web standards move away from the property "tabIndex" for HTML objects, do I think it may fit well for T3D. If navigation with keys works well, you'd almost automatically have it working for controllers as well.

Here is an idea how you may use a tabIndex concept (or for example "selection Index") to navigate through tab pages and its children.

 

 

Index:

• tabIndex "-1" will be ignored all together, including the children
• tabIndex "0" will be excluded for selection , but the children are included
• tabIndex "1" and greater will be included for selection
• lowest index greater/equal than/to "1" will be handled first, highest the last.

Navigation:

• Using "left" & "right" will navigate through containers at the same level (no children are selected)
•  "up" & "down" are used to navigate through the children
• Navigating through children that aren't containers will result in automatically selecting them.
• The "enter" key, "A" (or X for PS controller) and "RB" should be the same as left-mouse clicking the object (button eg)
• No children are automatically selected until user interaction ("up" & "down")
  So for example the mainMenu will not pop up with a button already selected, but waits for the player

A tabIndex concept involves in some code changes/additions for a lot of GUI objects but the result I think would be quite useful for many other GUIs than just menus. The name "tabIndex" is easy to recognize (most will know at least basic HTML)  but might be a bit confusing in T3D since you have the GUI control tabBook and tabPage; so perhaps "selectionIndex" or such would be preferable.

Anyways, just some thoughts.

(Edit: GuiTabBookCtrl in the image should have an index of "0")

Edited February 7, 2023 by Nils

[JeffR]

Yeah, makes sense. Only spot I could see there being problems with navigation for a strictly linear index list would be like, an inventory grid or the like.

One thing me and Az discussed earlier today was, I was already looking to create a "keybind editor", so you could just build the actionmaps in the editor tools, rather than needing to hand-craft all that stuff in script.

So, if you figure there's an easy route for designing out an action map for any given reason, we could capitalize on that. We could tweak GuiInputCtrl to accept an action map, and it could push/pop the actionmap when the Ctrl wakes/sleeps. Then you pretty much have something akin to the accelerator field on some controls, but you can design out what any/all inputs do on a given menu.

Which ties back into your ideas for navigation with buttons. If someone wants to tweak or rework the buttons for THEIR menu, then you can just edit the actionmap the GuiInputCtrl uses.

Otherwise, we can have some standard functions to do stuff like you're saying, with navigating up/down | left/right | activate/back and so on.

Would probably cover the bases pretty well for most standard menu layouts. As said, only one that'd still be a bit squirrely would be grids, which wouldn't play as nice with the tabIndex, but it could still probably rely generally on the other navigation logic. Maybe it'd be as simple as just having a separate InputCtrl and actionmap for navigating the grid(again, i'm imagining like, an inventory screen or something) and it'd just change the left/right to not change containers, but just navigate left/right through the children too.

[Nils]

Quote

Only spot I could see there being problems with navigation for a strictly linear index list would be like, an inventory grid or the like.

Each GUI control may have to be treated differently regarding certain aspects, especially with containers. A GuiStackControl (as we see with the mainMenu), though while having the possibility to create multiple columns & rows, is I believe primarily meant for linear use. If one is creating something as an inventory grid (with for example 9 or more cells) then perhaps GuiControlArrayControl and GuiDynamicCtrlArrayControl are containers that better suit such uses. For these controls you could make exceptions on the tabIndex behavior, as those are obviously meant to work as a grid and not linear.

[JeffR]

Sorry, yeah, for clarity, I was meaning something where you'd be using the ArrayControls. Mostly just thinking that a simple tabIndex wouldn't work on it's own. It'd need to be like, a Point2I tabIndex variant or something along those lines. So you can figure an x and y index for traversal.

Though I suppose if we're talking about the array controls specifically we could just override the nav behavior to sidestep the index logic entirely while we're operating within it as a container and just let it process the left/right/up/down nav(again being a row/column offset)

[Nils]

Quote

Though I suppose if we're talking about the array controls specifically we could just override the nav behavior to sidestep the index logic entirely while we're operating within it as a container and just let it process the left/right/up/down nav(again being a row/column offset)

Yes, certainly!  That would be the best solution, IMHO as well

[Nils]

back to the T3D 4.x UX/UI Makeover , here's an incomplete list of things still to be done:

Important work to be done:

* fix hover states of certain toolbar buttons
* open dialogues that aren't docked all in same place
* restore window (after maximize) results in incorrect canvas dimensions (x y)
* add "close" ( X ) and "restore" ( [] ) buttons right top fullscreen editor window
* keep all bottom panel windows (asset browser etc.) as one when docked
* keep fixed positions for bottom panel tabs for each specific window
* fix all GUI text controls that have content cut off after font changes
* align all GUI elements properly after font changes
* distribute GUI elements neatly on grids / guide lines
* Get all Convex Editor / Sketch Tool functionality in one panel
* Design a proper UX layout for the convex Editor
* Fix incorrect Shape Editor window positions and dimensions
* Get the Shape Editor windows to behave as one when docked
* Pay more attention to UX design in the Shape Editor (clarity, grid etc.)
* Show camera controls properly in the status bar (bottom)
* Fix dead links in the menus
* Fix missing assets (reduce console warnings)
* Proper Tree behavior in the Asset Browser
* Scale icons (previews, folders) with steps of 25% to reduce jaggies
* After creating a new asset in order to open an editor, do open the editor
* Increase contrast of certain button & class icons
* Fix behavior of the Verve editor window
* Gather feedback and issue reports
* Code redaction to reduce the repetitions
* Review the World & GUI Editor short keys
* Document all the changes
* Clean up the project and make it ready for a pull request

 

Additional work maybe be done:

* Add option to show editors menubar as: icons/ icons w text/ tabs w text
* Create a tools/editor GUI template with docking panels/windows
* Dropdown menus with icons next to text
* Ability to dock panels to other positions in the canvas
* Truly nest a whole GUI (guiContent) in a tabPage control instead of faking
* Sort (to front/back) GUI (children) windows even when not sharing same mother
* Copy console log to clipboard without the need to ship with T3D tools
* Design/implement advanced metrics panel for profiling
* Add help buttons which are linked to documentation
* Add script window for preview purposes w "edit" buttons (external editors)
* Thinking/testing future changes to improve UI responsiveness (font size eg.)

 

[Azaezel]

As much a note-to self as anything else, but we really should add a 'make font cache' button at some point to profiles:

https://github.com/TorqueGameEngines/Torque3D/blob/development/Templates/BaseGame/game/core/utility/scripts/helperFunctions.tscript#L646

[Nils]

@AzaezelThat's certainly a useful function, especially these days in where we have to worry less about having MBs of memory use. This also avoids the issue of certain characters not generated before shipping and being displayed incorrectly at the player's (who may not have the font installed on their system). Good thought there!