UIElements roadmap update

Hi everyone, here’s an important update regarding the UIElements roadmap.

We were very excited at the idea of sharing our early progress with UIElements for runtime with you all, working very hard at releasing a preview package around the 2019.3 timeframe, but we decided to delay it until 2020.1 instead. Let me walk you through the thinking that lead to this decision.

First, a bit of context. When the development for UIElements began, with the goal of providing a single UI framework for both extending the editor and building runtime UI, the Unity features landscape was somewhat different: Packages and DOTS where not a thing and features had to be shipped with the Unity engine. This comes with a few but considerable restrictions:

  • Iteration - Updates are released either via official builds, which happens roughly every 3 months, or by dropping custom builds, which is time consuming for us to produce, and tedious for users to deploy.

  • DOTS - It’s currently impossible for us to provide a version of UIElements that will be compatible with the DOTS runtime, or to leverage DOTS capabilities in order to increase performance.

  • Packages - Unity features are either moving, or being created, into packages, contributing to a constantly growing ecosystem, which UIElements can’t be part of. Some features, such as Addressable Asset Bundles, are particularly appealing but out of reach.

Yikes.

Moving UIElements itself into a Package is inevitable, and we’re confident it should be done sooner rather than later, for a few reasons:

  • Stability - This change will most likely impact anyone using UIElements. Doing this while in Preview will preemptively avoid a lot of disruption.

  • Quality - UIElements for runtime is still in an early stage of development and it is critical that we iterate tightly with the community in order to ship a product that you really want to use.

  • Visibility - Distributing into a package also means we’ll be able to share a more granular roadmap and publish updates at a higher frequency.

Meanwhile, we’ve decided to release the Runtime implementation seen in the Unite Copenhagen 2019 demo as part of the demo project itself.

The demo project repo, along with the Runtime implementation, can now be found here, and requires Unity 2019.3:

https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo

This is a temporary and unsupported early preview of UIElements Runtime support. It is meant as an evaluation tool that you can use until we ship the official implementation. It is only meant as an evaluation tool. Any APIs in the project might change. That said, the general workflow should not change much going forward.

We welcome any feedback you have and will use it to inform the official package implementation as we work on it.

To see how you can use UIElements at runtime, here’s the Unite talk recording:

We know some of you will be initially disappointed by this change but we strongly believe it’s the best thing to do, which will ultimately result in a higher quality UI framework.

Cheers,

17 Likes

Awesome! Was a bit sad at first about the delay but seeing a runtime version was released along with the demo project definitely made up for it. And I’m glad UI elements will be moved into a package with more frequent updates. Looking forward to where the runtime system is going in the next few months - keeping my fingers crossed for news on data binding!

3 Likes

Totally understand the decision. The demo you guys gave at Unite looked solid. So I know it should be on the right track and is certainly what people want. One thing I want to ask though: how do you envision the DOTS compatibility is gonna work out? What are you looking to leverage from DOTS?

Great news with the package! Will it depend on Unity 2020.1 or will it run on 2019.3 as well when it’s released?

Welp, there goes my planning for next week.

The interaction between package versions and editor versions is still a bit unclear to me, but if I understand correctly:

  • The first version of the package will be built against 2020.1 and released when that comes out of beta.
  • Because it’s a package, it’ll then be able to get updates between Editor versions.
  • With the eventual verified one being verified against a specific versions of the Editor again.

Is that correct?

Compatibility is something we’re still discussing but the high level objectives is to use UIElements for making UI in all DOTS related scenarios: A project using current Unity but with ECS to optimize certain systems (generally referred to as Hybrid), a project targeting the DOTS runtime only, a project targeting the Tiny subset. In all those cases, UIElements should work well with features like Live Link and DOTS Conversion workflows.

As for leveraging DOTS, we’re mostly looking at Burst and Jobs, to optimize certain updaters that are frequently running on the entire tree.

2 Likes

It will depend on 2020.1

Nice! The example contains everything in package layout. So one could easily build an npm package or just import from disk… Just did, and now started prototyping with UI Elements and Runtime :smile::sunglasses:

4 Likes

Yes that’s nicely summarized. A package is verified against a version of the Editor, but we can then branch a new preview version. For example we could release a verified version of UIElements 1.0 against Unity 2020.2, and then branch 1.1 in Preview to continue development in the open.

Sorry about your planning :frowning:

Nice, I did get it then. Considering the roadmap for UIElements rolling out the new features as part of preview packages makes much sense and should make the process easier all round. So I’m happy to see a package for UIElements. :slight_smile:

I’ll just have to change it to evaluating the demo project and doing preliminary design work based on that. It was just a bit of an emotional rollercoaster this morning: Yay release candidate 1 for 2019.3! :smile: Noooo, UIElements is delayed. :hushed:

2 Likes

Does it mean you guys started considering using UI Elements in Tiny too?

Yes. Tiny needs a solid UI solution and we’d like to avoid making yet another UI framework :slight_smile:

1 Like

that’d be awesome :slight_smile:

I’m disappointed. It made things much worse for me. I think you shouldn’t do this.

Sorry to hear that. Can you elaborate on how this makes things worse for you?

I don’t find your comment funny. My work and my roadmap depends on your work and your roadmap. And I do take my work seriously. just wanna say you souldn’t announce this delay at the last moment.

If your roadmap depends on what they showed at Unite, then good news! Everything they showed during the talk is available on github: https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo

If your roadmap depends on the less concrete details and rough timeline items mentioned during the talk, then I’m afraid you’re gonna need to wait a bit longer.

Now, this post is intended to be funny, uDamian’s was not.

But in all seriousness, last minute delay happens. We vent our frustration when it’s happening in an unreasonable manner. But in this case, they a) released the runtime code (also in a nice package-friendly setup), and b) gave reasonable points for their decision (desire to go the package route, etc).

1 Like

I didn’t mean to be funny. I’d just like to know how this impacts you so we can see how we can help.

This change was inevitable. If we waited longer it would have impacted people even more than it does now. We have a lot of internal users that will also be impacted by this, including the UI Builder itself. But we think it’s worth it for the long term.

3 Likes

True, its better to wait for the right tech in stable form than using something which agains get replaced.

Since Unity has been buzzing about DOTS for a long time now it makes sense that Unity would want UIElements to be DOTS compatible. Saying it’s currently impossible to provide a version of UIElements compatible with DOTS is a little unsettling. How much investigation has been made to see how feasible it is to support DOTS by 2020.1?