UI Preview - Feedback Requested

Hello all,
We are working on a revamp of our UI. Mostly this is small changes that should make things more intuitive for those jumping in fresh. We would love feedback on this from the community. This build of addressables is untested, and likely has bugs. The docs in this build have not been updated to the new flow, so you'll have to somewhat go blind based on your current knowledge and exploring the included CHANGELOG.

This is not intended as a build for you to move to now, but one for you to try, specifically to give feedback. For your actual development, continue to use the latest released version (1.2.2 as of this post). To try it out:

1. Unzip the attached file.
2. Unzip the file
3. In a Unity project where you feel comfortable testing this package, go to Window > Package Manager
4. Add it as a local package:
   1. In recent versions of Unity, click the “+” button in the top left of package manager and select “add from disk”, then select the package.json file in the folder you unzipped.
   2. Prior to recent versions of Unity 2019, the “+” was located in the bottom right corner of the left panel. Select the package.json file in the folder you unzipped
5. The package should now be installed, and you can find the new main-window at Window > Asset Management > Addressables->Groups
   

Please provide feedback either on this thread, or (and?) by filling out this survey: https://docs.google.com/forms/d/1L850pLrsbhLu3L0TwT5g2Yi1x_x3B9U6kyxfu9dOZ4c/edit

We really appreciate whatever feedback you have time to give. Please focus on the UI changes specifically, and make new threads for unrelated issues you find.

 

Based on what I can see / notice it's globally a good improvement on many tiny things that create a good global experience now.
But, I still have some remarks on some stuff :

- The separated labels window is quite a problem cause it creates a longest path to edit them, it was for me better to keep them into the AddressableAssetSettings location but if some people prefer to see them in a dedicated window (why not). For me it's longer to edit them so it's a problem.

- The dedicated profile windows is a good thing but with the current display it's not because it's quite hard to read (at least on my computer or with my unity version, maybe it could be nice with 2019 and UIElement I don't know)


- In each tabs or windows I don't think it's necessary to keep the "Addressables" word. For example in the window above, I would just write "Profiles" instead of "Addressables Profiles".

There is maybe more to notice but with my first test of Addressables 1.3.0 preview it's what I noticed.

The Hosting window is really better This is small change but the readability is way much better !

 

I'll start off talking about feeling. The overall feels better and I agree with aurelien, this is a step in the right direction.

The way I see, I have to open many different panels (windows) to see all settings. What I feel, is that it would feel better if those panels were actually tabs of a single panel with collapsible content, pretty much the same way the Lighting window works.

It's not like it's a problem to have all those windows, but it feels like, everything is necessary for the whole system to work, and but you have to open every and each panel to edit specific things. Maybe putting them all together would feel like I can have a better picture of the whole. I know it's a long shot, but I think worth pointing that out.

I also agree with aurelien in regards of the label window. My suggestion is that the readability would be better if the profiles were collapsible and you could read each row as a separate line. Making sure you can read the path from end to end is important.

Last, I don't get why the Addressables Labels is a window instead of a panel. Don't know if it's intended, but surely feels weird to have a window like that.

 

I agree with @danilonishimura about the multiple windows. Unity Editor is so vast, it took me a while to go an look for what I needed with addressables and having to refer back to the documentation. If it was all together, that would help with the learning curve for some.

 

@danilonishimura is on point! Combining those windows would be huge. If you use different packages, asset store plugins and maybe custom tools your workspace gets cluttered with lots of windows and tabs. If there's a chance to tighten things up, I'm all for it!

 

And then maybe even one better, create a label in place.
I sometimes forget to create a new label, have to go to the Labels first and then create a new label just to be able to set this asset under a label. If only I could be able to add another label while using the dropdown rather than going to manage labels. Like maybe at the top or bottom of the dropdown list -> "Create new label" and have it popup with a new label and set it immediately.
If you really need to get rid of a label you can go back into the label management. [edit] Or put an x behind the label to remove it from the list. Then everything about labels is in one place, the dropdown. Can add and delete in place. The you don’t need a whole different area for labels.

I like the update restriction, now it is clear what the intention of the bundle is. To either be able to change post release or not.

An easier way to get to the documentation would be nice.
The ? at the right top of a group doesn't link to the addressables manual but rather to the Unity Manual with a 404.
To go to the addressables manual I'd first have to go to the packages manager, search addressables and then go to the documentation. Would be nice to just be able to use the ? at the given component to link to the right manual page. Or in the addressables menu itself.


[edit, just found out that there is a way to add presets to the groups by using the settings. So I edited the paragraph below]

When creating a new group it only gives the sub menu option for 'packed assets'.
Maybe a few more presets by default like 'streamed assets (Local)', 'localhost assets', 'remote assets' . It saves a few clicks. By default it has local and remote as well. It would only be logical to include those groups then as default as well.


As for the addressables profiles I'd kind of want to see what my actual value is. Maybe I made a typo in the spelling.
[ ... ] means BuildTime value
{ ... } mean constant evaluated value (?)
After filling them in I'd still have to check at my bundle what the actual path will be. But there's no current 'simulated' path visible in the profile settings. Maybe a toggle between editable fields and actual evaluated fields? If you made a typo it is easy to find out where the problem is if the path still isn't what you'd expect. That could save a build and debugging.
Or maybe give an error / warning that the value between [ ... ] is invalid and cannot be evaluated.

 

IMHO, to understand what should be grouped together, we should think about at what time each window needs to be accessed. Are we setting up the project? Are we building content? Are we testing/debugging? Each moment demands a set of windows. Grouping them together makes it easier to remember what constitutes that stage of development.

About the column, I did adjust the width, but when the URL is long, it isn't enough. You have to undock it and/or keep resizing it until you can read the whole URL.
Take a look at the screenshot previously posted.
Almost every column would have to be resized. That's why a column approach for wide elements doesn't always work.
If each profile is a collapsible item, and once expanded it shows 5 lines, each one containing its path, would be a lot easier to check each item. Once again, my opinion, but I think people are more used to vertical scrolling than horizontal scrolling, so I'd rather have a long (tall) list than a wide list.

 

1. "Manage Labels" button should be outside of the scroll area.


2. Addressable name should be removed, it's over-designed and unnecessary. AssetReference should be able to receive dragging file or open the asset-picker window just like a common unity object reference. (If user drag a mismatching file the cursor should look like disabled)

3. If user rename or move asset to other folder in project window, the path in Addressable Groups window is unchanged but it should change, and the asset-type icon disappears.

4. Right button menu should use separator between item-operations and group-operations.


5. AssetReference should not provide method to load asset. It should be a parameter of load method of Addressables (hide runtimeKey property at the same time). Please keep things clear and simple. If you don't agree, please let AssetReference has ability to load scene additive/inactive and unload scene.

6. LoadSceneAsync is confusing. It means "load" or "instantiate"? Unity should differentiate loading a scene-asset from instantiating a scene-instance, so we can destroy a scene-instance then instantiate a new one to "Restart Level" quickly without unloading asset, or instantiate more than once to additive same content. Same reason Unity should differentiate unloading a scene-asset from destroy a scene-instance, please make the APIs clear. (Load vs Unload, Instantiate vs Destroy, please don't use Release...)

7. LoadAssetAsync should has a priority parameter like LoadSceneAsync. (And please improve the documentation about this parameter.)

8. How to load a group/pack directly? Is there "AssetGroupReference"?

 

I actually use the addressable name in static classes. So no they have their use case. And to make a label for every asset that is used in a static class wouldn't be really efficient either.
So for classes that are not MonoBehaviour and don't have a Awake or Start method it is nice to have the addressable asset name as key.

I don't really mind where to unload it tbh. Whether it is centralized or that it is done through AssetReference.
Via the asset reference itself it does make sure you're unloading that specific asset and prevents copy pasting errors where you might have forgotten to replace the asset reference parameter.
They are quite simple and clear as is imo.

The scene never gets "instantiated", they're always loaded. Instantiation is something you do with prefabs but not scenes. You only load and unload scenes, you don't instantiate them.
LoadSceneAsync has the same name as

SceneManager.LoadSceneAsync()

. So theres nothing wrong with that method name.

 

Do not hide runtime key! By accessing it you can get assets synchronously via custom database. Using this class just for referencing. Also you can create some custom tools in editor whose auto assign or validate Assets Reference fields. And for that you will need to know which one is already assigned (by runtime key).

 

Well, I still can't understand why using a common object reference without extra name but no one is against that. Yes you can use a bad design, but it's unnecessary.

You are right, and that is what I want to change. In fact, Unity can load a scene multi-times now.

 

I'm afraid you can't do that...The runtimeKey is a System.Object, it's not constant every time you start game.

 

AssetReference.RuntimeKey.ToString() is ajust a guid(in most cases) of asigned asset. And it is highly persistent on one machine in one project. You can rename or move asset and guid will be persistent. Also it will be persistent between builds and editor sessions.

 

I just have a look at the source code, runtimekey is asset guid, so it might be useful.

 

This is a big issue for me right now! I'm starting a new project and wanted to "do it right" with Addressables from the beginning... but like any brand new project, my project structure is getting reorganized fairly often. No other object references in the editor break on a move operation, so clearly the ability to track resources exists.

Having a path change break the Addressable link also violates one of the core principles of Addressable Assets: decoupling a thing's name from it's location. Once I name an asset, I should be able to drag it anywhere in my Assets folder and still be able to load it via that name!

 

yes, we have some bugs related to path changes. I believe some instances of it are fixed in the 1.3.3 release, but I don't think all made it in this release.

 

In Last release we have separate window for labels and there is no scroll so even stretching window to max size dont get me able to add/remove label because buttons out of window

 

Is there UI where I can see what will be in bundle, why and what its size, bundle compressed and uncompressed(not project raw size)?