I would like to ask any plan to make runtime UI authoring tooling to as user friendly as uGUI? From what I know, currently it’s still quite hard and time consuming to create ui runtime like uGUI u can just drag the UI element to quickly resize it but at UI Toolkit u need to slowly type the value to resize it.
1 Like
There is a visual editor for UIToolkit called UIBuilder: Unity - Manual: UI Builder
I think it is still an “experimental” package.
Sadly, it has some flaws that make working with it fiddly, e.g. the object hierarchy folds on save and your current selection is lost.
But still, I think it is better than nothing.
@ , what are current goals / roadmap for the UIBuilder?
My feeling is that it has all basic features (editing UXML and USS), but it lacks convenience (like not losing the selection on save).
Are you in contact with customers (outside the forum) that use the UIBuilder?
Has the UIBuilder the same prio as UXML and USS?
1 Like
It is complex to make a UI using the new tools.
Forcing you to do things in a way that reminds me of web design.
And I dislike the UI Builder tool.
It may technically be better, but it is limited and not user friendly.
If it had to be like web design, then it would be better to be like Wix or Weebly.
It is not as intuitive as dropping stuff in the old canvas, moving and scaling them where you need them and having the whole thing being responsive. You could set up an entire screen in minutes and it works.
Instead of designing the tool more like Photoshop, they did it more like Dreamweaver. It may be good for large studios that would perhaps hire a web designer to do that, but for small studios and teams with traditional UI artists (which I suspect is the more common Unity case) this is bad.
The old system is much easier and friendlier for artists and designers.
Most of the new tools Unity has introduced are opposing the original Unity tool design philosophy.
Many of them have become more technical and more programmer friendly.
Designers and artists do not script. Even if that is basic xml stuff.
And they are not going to start doing it for Unity’s sake.
Contrary to that, Unreal is becoming less and less technical.
Just dump stuff in the engine and they just work. This is how Unity used to be.
4 Likes
On the other hand for cases where UI Artists work only in Photoshop and programmers integrate UI into engine
UXML file is faster way for programmers but it don’t work with Builder
Once you setup everything in uxml and open builder it will just kill everything and rewrite in some generator ugly way
So question is: When UI Builder will stop killing everything and start edit only what changes like only add internal style, only change, name etc instead of rewrite entire UXML
4 Likes
I don’t agree with soleron. I feel that your arguments will not change with the future. Thus, I recommend taking a look at other engines.
It is complex to make a UI using the new tools.
I don’t think it is more complex (to use) than uGUI when creating UI.
For me it is simpler and I can do stuff faster, because it is more like established web technology.
It is not as intuitive as dropping stuff in the old canvas
The UIBuilder provides a drag’n’drop interface. That’s only a matter of tooling.
However, UXML and USS provide a language and mechanics that do not require a proprietary GUI application to create a UI.
Similarly, you don’t need Dreamweaver to create HTML.
Same for Android XML layouts, Windows Forms XML layout, JavaFX XML layout, and others that implement the same approach.
Futher, text editing has other advantages over GUI tools, for example, easy copy&paste, insert stuff, good for version control and diffs.
There are existing, powerful text editors / IDEs that can be used to edit the UI, no need to reinvent the wheel.
Futher, new tooling for text is implemented more easily, e.g., linters, static checks, etc.
For example, you can easily write a test case that scans your UXML files to enforce some naming convention.
In the end, having the UI as code, enables to work with it like code, re-use tools, principles, etc.
The advantages have also grown into other areas, e.g. “infrastructure as code”.
When the language is present, the rest is only a matter of rendering it. That’s Unity’s main task.
And I dislike the UI Builder tool.
Me too, it just feels unfinished, unpolished.
But that’s a matter of the UIBuilder, not of UXML and USS.
It may be good for large studios
Unity is a big commercial company. I hope they focus on the needs of their customers.
In a way, these “large studios” also pay for the many hobbyists that use Unity for free.
> The old system is much easier and friendlier for artists and designers.
I don’t agree.
Most I know and I also assume new designers (just finished with studies) have learned some web design basics, at least some CSS maybe HTML.
Most of the new tools Unity has introduced are opposing the original Unity tool design philosophy
I agree.
I really wonder if it would not have been easier to apply flex-box layout and stylesheets on top of uGUI. But now it’s to late anyway…
I agree, there is a huge conceptual difference.
For example, you cannot just add a collider to a VisualElement like you would add it to a sprite.
I wonder if Unity plans to overcome this conceptual difference somehow.
Anyway, when only creating a 2D UI, without physics and other stuff, UIToolkit is fine.
Designers and artists do not script
I doubt that.
I think web designers either directly do HTML or CSS, or they deliver concepts to devs who have to implement them using HTML / CSS.
Similarly for other XML and Stylesheet UI frameworks (Android etc.).
But for game design, I think you are right.
At least for previous Unity game design you are right, just because uGUI did not allow to edit stylesheets and layout XML. There war only drag’n’drop.
Contrary to that, Unreal is becoming less and less technical.
This sounds great!
I would definitely evaluate Unreal today (although I am not a fan of C++).
But I wonder, if it is so great, why are people still complaining about Unity instead of moving to Unreal engine?
soleron, why did you not change yet?
Just dump stuff in the engine and they just work. This is how Unity used to be.
I never had this feeling with Unity XD
I always had bugs coming from the engine. And the tooling, I was never too happy with it.
At least with UIToolkit, the UI is much less painful for me.
All that said, you might have guessed already: I am a developer with web design background, not working in game industry 
This thread is already highly opinion driven. If this is the level of questions for todays “day with Unity UI team” then I am disappointed (but at least I was a part of it, yay! ).
I am using both engines.
Depends on the project and the client. I am a professional, not a fanboy.
You will always have bugs coming from any engine.
That is how software development is like.
The question is, when was the period in time that you could set up your scene faster and with what version of what engine.
This has changed drastically in the last few years as Unity tried to imitate Unreal because users were complaining, and on the other hand, Unreal tried to imitate Unity because… users were complaining.
One was going up towards the ease of use that made Unity ubiquitous, while the other went down the complex path that was holding Unreal back from new user adoption.
Unreal users were justifying Unreal’s complexity and rigidness to “better structured production methods” which was a pure nonsensical elitist deflection. Unreal 5 got rid of a lot of the complexities of the past, removing decades of Unreal’s outdated UX/UI baggage while unfortunately, Unity tried to emulate it to appeal to those people who were praising it.
Obviously, that was an awfully bad decision as so many people today say that Unity has become more complex with a poor ROI considering the effort and bad PR. Pushed more towards Unreal.
Funny you call this thread opinionated when
A. You say you are not working in the game industry, so why do you have such confident opinion to start an argument?
B. You said you have yet to try Unreal so how can you be so sure about your opinion?
4 Likes
Ohh, I was just trolling.
A lot of stuff in the forum reads more like complaining than questions.
I had hoped for today to be more about questions.
Unity tried to imitate Unreal because users were complaining, and on the other hand, Unreal tried to imitate Unity because… users were complaining.
I see. At least they try to learn from each other…
Thanks for your thoughts on Unreal vs. Unity and how they developed. I didn’t know that.
Competition is good for the product. It seems, at least for Unreal
Coming back to the original question:
I would like to ask any plan to make runtime UI authoring tooling to as user friendly as uGUI?
1 Like
I would like get reply from official. I really hope official can rethink about UI Toolkit authoring tooling for runtime UI and try to make it as user friendly as uGUI.
1 Like
Hey, thanks for sharing your feedback! The UI Builder balances the support of authoring via a visual editor while supporting authoring via code. When users need to collaborate, this gives them the freedom to work how and where they need to — obviously, with that comes some restrictions so that everything “plays nicely” together. Supporting code and visual editing both at the same time (and having a back-and-forth translation) can be a difficult balance to master, but with every piece of feedback we get and new features we release, we learn more and make adjustments.
What artist-focused UI workflows are you expecting and hoping to see? There were a few comments touching on editing via the canvas (as you’d edit UI in the scene view while using uGUI), and while the UI Builder does support some canvas editing, we do have more work to do there. While software used for web tools (like Dreamweaver) utilizes literal selectors and classes, design tools like Figma or Sketch use shared styles which are similar in concept and there can be further improvements to narrow that gap in mental model. If you have specific ideas or examples of workflows you’re expecting, please feel free to share.
Since UI Toolkit utilizes flexbox, dropping items onto your canvas in the UI Builder will automatically be responsive since it follows a set of rules. You can always turn the position to absolute if you prefer your element to be moved freely. I understand this isn’t the same as the anchors used in UGUI but pairing the position properties with selectors can be a pretty powerful way to ensure that the position of one element can be carried across multiple elements by updating just one selector.
Additionally, I’m happy to say that we are currently making improvements to the Builder inspector to have more “visual” widgets so that the user has to interact with less text fields in order to edit values. Keep a look out for this in the future!
1 Like
Currently the most wanted feature for me is uGUI like feature that I able to create UI element like Image and I can directly change its position and resize it freely at the UI element and UI Builder can auto and dynamically figure it out itself so I can have almost the same uGUI like authoring experience to create runtime UI easily.
2 Likes
Hi all, thanks so much for the discussion and feedback in the thread so far – I’ll do my best to tackle a couple of the specific points made throughout the thread.
Can you expand more on this? Do you mean in the context of the UI Builder, or when authoring directly via UXML / USS or in code?
The reason why the UI Builder handles the UXML this way is that it’s beneficial for workflows that need to support multiple people – it lets someone write via UXML if that’s more efficient for them, but also ensures that what they write can be further modified via the Builder for someone who prefers authoring in a visual editor.
If there are specific things being overwritten in your code that you would otherwise like to preserve, or if there are bugs / issues with it, please let us know! Additionally, we’ve gotten feedback that it would be nice if something like comments don’t get removed, and we’re aware it’s something to look into.
We actually fixed this bug!
You can check out our roadmap here, which is where you can submit requests and bump existing ones. We try to bring minor improvements in every release but looking at bringing more impactful changes in future releases.
As well, if you have any other feedback about the user friendliness of authoring in UITK, please feel free to respond to our survey . We’re always looking for feedback to help improve the usability and user experience of our tools!
Yes, we work with customers in different market segments to better understand their needs
We try to expose features uniformly across the three different layers: API, UI assets and UI Builder. Sometimes when we want to release something early in order to unblock users ASAP, we limit to API or UI assets level but typically we’d want to features to be consumable by everyone.
1 Like
UI Builder for creating runtime UI. What I mean is currently seems like it’s really tedious that u need to manually put the value at inspector to do all kind of resize and positioning. It’s not like uGUI that u can just author the UI Element itself u created directly.
1 Like
Got it, thanks for elaborating. I would mostly point to what Stefania said above:
Another aspect that we have considered is adding more authoring tools on the canvas directly, but no work is currently planned for it. If you’d like to bump it, you can do so here.
It is wonderful that you are thinking this way.
I just wonder, based on what development experience, and which large teams’ game development work do you decide/design how this new feature should be in order to fulfil the requirements you mentioned?
Who validated the solution you provided to fulfil these requirements?
As optimise said.
Not just tedious, contrary to ANY tool that does design work. Positioning, scaling, these should happen freely.
Not only does what you chose for users make design work unnecessarily rigid and mentally cumbersome, against several UX paradigms and good practices, but also makes it difficult to animate like you used to do before.
All you had to do was enable the auto key for animation and scale or position the UI element exactly where and how you wanted it. And that was all. All a programmer had to do for you was run the animation “on click” with a simple script.
Now this becomes cumbersome and increases the amount of back and forth between programmer and designer.
A bad solution through and through as it removes control from the designer and gives the often-unpleasant task for the programmer (not to mention awkward and out of their expertise) to make aesthetic decisions.
Increases production load, friction between the team members, and gives room for miscommunication and human error.
2 Likes
just everything
it is like write code in readable way and then it will be rewritten by codegen in totally unreadable form like full namespaces in names, ugly punctuation, etc.
In my case I just define namespaces in root tag to write more compact and redable file
write some space and empty line separator
offering using tabs and many more code formatting things
After opening builder everything gone
Any tag that is legal from UXML point of view of don’t known to Builder was deleted by builder.
I think current approach to generate entire file is bad one
Builder must change only sort of InnerHTML or OuterHTML but never entire file
Just look how browser code builders work. They never change sources until necessary. We need the same behaviour from UI Builder to really work in both ways
So current tool don’t allow to work from code and builder only one or another never both.
2 Likes
We have clients shipping both large and small games right now using UI Toolkit. This also includes writing Editor tooling with UI Toolkit. We also have more and more internal teams converting Editor UI to UI Toolkit and giving us feedback from their experience.
When it comes to how we decide what to work on next, it’s a mix of “what will accelerate the transition away from uGUI and IMGUI” as well as “what will make the lives of existing UI Toolkit users easier”. We have to balance an already large existing user base with the future users coming from other UI frameworks. But I can’t be more specific than that because it depends on each feature and state of our resourcing (that cycle).
As for “who validated the solution”, we have our internal validation process but ultimately, it’s you that decide. Nothing is written in stone. If it turns out it was a bad call, we’ll change it. It’s not like certifying an airplane. All the blunt feedback in this thread is valid and for the most part, it’s well known. It just comes down to resourcing. Bare with us.
On difficulty we have is that the UI Builder is NOT a design tool. It’s not equivalent to Figma of Photoshop. At least, that’s not its main purpose. UI Builder was created to make dynamic UI authoring easier. It assumes UI is dynamic by default, meaning there are no fixed sizes or even positions. Everything is relative to everything else. So if you change the font size across the whole of your UI, everything adjusts according to the rules you set. This is in direct conflict with the “let me resize everything manually directly in the canvas” approach. Manual control means we can’t do anything for you once you want to go back and change something across many elements.
As mentioned above, if you set the Position to Absolute, you can freely move and resize this element as you would expect in uGUI. You can even “anchor” it, though it’s obviously not as easy as it is in uGUI. But when you’re in this mode, we can’t help you anymore when it comes to the layout. It’s all on YOU. This was exactly the feedback we got against uGUI - auto layout.
That said, it doesn’t mean we don’t want to bring the two worlds closer together. There’s a lot more we can do to combine the auto-layout default of UI Toolkit with the ease of manual control that’s great with uGUI. I just wanted to add some detail as to why we prioritized one approach over the other.
Just to add to the comments above, the reason for the hard reset when you open your UXML in the UI Builder is that the UI Builder does not work on top of UXML (text). The UIB works on top of the actual runtime in-memory asset that is created when UXML is imported. Obviously we don’t want to parse UXML text at runtime, so when you import a .uxml asset, it gets imported as this VisualTreeAsset type. Since comments or whitespace are not relevant for the runtime, all of this information is lost when the asset is imported. This means that when you save the document in the UI Builder, we essentially generate brand new UXML text from this internal VisualTreeAsset asset. Your comments and whitespace is long gone.
I just wanted to add a bit of background as to why things are how they are today. Of course, we fully agree this is a problem, but it’s also a very difficult problem to solve and as such, difficult to prioritize.
The namespace IS something we would preserve without a major refactor to be text-diff based. I’d suggest adding or voting for this in our roadmap page:
https://portal.productboard.com/xvo8kmgtx7tkv7desh8cyaj7/c/437-didn-t-find-what-you-were-looking-for?utm_medium=social&utm_source=portal_share
Pretty sure this is a straight-up bug. Please report it when this happens. The UI Builder should never “corrupt” your UXML’s actual tags, even if it doesn’t support that specific feature of UXML yet.
I quit web designing in 2002. I don’t want to go back there thanks. Borrrrring! Make the UI Toolkit work like a game engine component of Classical Unity. uGUI is fine. easy to teach to noobs, has world, camera and overlay modes which can be mixed and matched and is WYSIWYG. We have enough API’s and different code stytes to cope with already. Stop adding complexity just because the new engineers you hired do not have experience in other than what is trying to be shoved down our throats as usable. It took me all of 5 minutes in UI Toolkit to deem it a sucker of my time and a rep killer on freelance contracts… “You took how many days for that UI???”
3 Likes
You are free to keep using it then. It will continue to be fine.
No one is doing anything of the sort. We’re even still officially recommending you keep using uGUI for runtime UI because we know UI Toolkit’s usability is not there yet (for runtime).
This implies you were able to accurately judge 7 years of continuous development and all future development in 5 minutes. Consider me impressed.
1 Like