Terrible design, nobody asked for it, should be API for custom editor etc… but given how @thomh_unity is defending this thing, someone’s job is on the line so let’s help him make it usable.
I start.
(I also attached the psd if you want to chime in)
3 Likes
Hi Laurent, first of all, thank you for this feedback, I appreciate you taking the time to put this together.
Regarding the build buttons; Based on feedback from the earlier builds we have updated the button section to include a disabled build button that will give a hint as to where these buttons will appear once the profile or platform is active. For some additional context the buttons were moved to the top in an editor wide effort to make the button placement more consistent across the whole editor.
Regarding how you’re highlighting the build profile at the bottom, the relationship with the build profile and the content panel goes beyond the player settings section you’ve highlighted. The platform settings and build data can all be customized per profile, so it doesn’t make total sense to highlight a subset of that window.
Remember that this is a beta, I hope you can see that we are reading all the feedback and taking action were it makes sense. Please look forward to the next update from our team who have fixed a lot of little inconsistencies with the layout of the window. You’ll be pleased to hear that player settings can collapse in this version, and some unnecessary help boxes have been collapsed to make the space more readable.
8 Likes
@thomh_unity I know what I am going to say may not very useful as feedback or perhaps a bit harsh, because you have done a lot of work, but I think the proposed layout design for the new build properties is so bad that there is no saving it. All the hard work was put to a direction that is not really helping anyone.
It just has such convoluted design thinking behind it that it is painful to even look at and try to make sense and figure out what affects what and how the structure of information and choices are related to each other.
Really poor design in almost every way.
The UI is not designed to be uniform/consistent across the editor for a reason. Not by mistake.
Different tasks require different thinking and different flow of information and actions.
I am not even sure what you tried to slove with this redesign. To bring all the buttons to the top?
Sounds to me more like OCD than meaningful and functional design.
All I see, like in other screens, (i.e. Graphics in Project Settings) everything thrown in our face regardless if it is relevant to our main choices and if it should be there at all.
You have turned a super simple and compact and efficient menu into an endless and unnecessary scroll fest.
1 Like
I currently use this for one project GitHub - superunitybuild/buildtool: A powerful automation tool for quickly and easily generating builds with Unity.
I had a my own change log… but I always felt above the above tool was missing a decent built in change log feature… like this…
…Now Unity made a build tool change and… well doesn’t seem like a huge improvement over what it had before and neither does it seem to offering either of what the above tools do overall… does it?
Like where release files get dumped based on profile build platforms etc…
2 Likes
Agreed.
What’s important here is that build, like renderfarm, is advanced stuff and like renderfarm, if you need it you can afford it. If Unity wants to do it right it will:
- Not please the folks who have the experience to need it, and they’ll deploy their own.
- Confuse people like is already happening.
But it’s already in the list of U6 new features so let’s play along…
I got that. As long as what makes the old build window good is back, it’s fine.
Tucking away the power features?
If that’s the case, good.
What is important is to not get in the way of 99% of usage.
Can you give an example scenario?
1 Like
I just mean that everything on the right is customizable specifically for the profile selected. So all of those elements relate to the selected profile.
This is from beta 16, more layout improvements coming in the next version.
So, these are in fact bookmarks. Better call them like that and make it behave that way don’t you think?
I don’t see anything wrong with naming it “Build Profiles”, if anything it makes more sense than a more ambiguous “Bookmarks”.
7 Likes
Seems like the Prefab/Variant/Override system is a much closer analog to this profile system than “bookmarks.” What a strange suggestion. Profiles in OS accounts, web accounts, and other software work pretty much like this: there’s a stock standard set of preferences, and then you switch hats to get a whole new set of preferences or overrides to better suit that working situation.
I still think the old Build Configuration, that was introduced around the Unity 2020 entities era was in terms of design and UX the way to go.
It was simple, I didn’t have a list of platforms I’m not interested in which clutter the screen space.
The process was incremental with adding more and more features, with features being very simple like:
- CompanyName
- OutputFileName
- Scripting Defines
- Platform
etc…
I had actual files in my project that could be added to version control. I was able to select multiple platforms and just hit build.
I really don’t know what happened here because everyone I knew and talked with said, hey this is great and everyone was sad when it went away.
So why did you not build upon it?
5 Likes
This is unfortunately a backwards compatibility concern that we didn’t manage to figure out by this release. But it something we are addressing in a future release. To be specific, we needed:
- All the existing build scripts that people have written continue working. In particular, there are editor scripting APIs that allow you to switch to a different build target and thus the new build profiles window has to provide equivalent functionality without creating custom build profiles;
- Existing projects have their build settings configured in a certain way so keeping the same platforms list that was there in the older build window allows us to keep those settings intact.
It was playing catch up and could never quite match the old build window in terms of settings. We constantly received bug reports about some setting being missing. Also it being in a package meant that it constantly got out of sync of the settings in different Unity versions.
That is the case with build profiles too.
I agree this functionality is not available with build profiles.
It was not built in a way that we could leverage to make it do all the things we needed it to do, especially in not completely breaking everyone’s workflows department.
Appreciate the answer!
Yeah, that’s what was said when it got deprecated. I do understand that a package wasn’t working out and there was a big problem of maintainability. But, whoever built it struck, a chord when it comes to the design and usage of Build Configuration.
I think, if you’d strike a balance between the current and deprecated Build Configuration and take the best parts of it, especially how modular it was, the new build system would get much more praise.
One of the big benefits was that I could override nearly every build option without writing a script. Having all options available from the beginning is overwhelming and a bit confusing so that’s where the modular feature system shined.
Something that would be really nice and I miss dearly is just setting the filename to export.
1 Like
yes its a tad bit confusing when you create a build profile and it yields 3 entirely different UI sections that all have the potential to override another 
after creating a build profile asset the user has to interpret between the following UI panels:
-
File > Build Profiles > Player Settings Overrides
-
Edit > Project Settings > Player
-
(In project view) Assets > Settings > Build Profiles > “platform”.asset > Inspector > “Platform” (Build Profile)
Is there anyway for the user to customize the UI themselves without a complete rewrite? Just a simple option to remove things like unused platforms (which are not removed when you set module visibility to false in the editor module file) and also removing the inspector editor UI on the actual .asset file as it becomes confusing when you can edit the profile settings in 2 places.
Also, opening the new build profile .asset files yields over 800 lines of useless platforms that make automation with outside scripts a bit messy. Why is all of this data being include in a build profile asset that’s intended for ONE platform? Android, EmbeddedLinux, GameCoreScarlett, GameCoreXboxOne, Nintendo Switch, PS4, PS5, QNX, VisionOS, WebGL, Windows Store Apps, XboxOne, iPhone, tvOS
It’s probably a lot more complicated than I’m making it seem, but if the only way to make build profiles work is with 1 master asset that has every single platform included, why not also include the "Platform specific build settings’ as well as the “Shared build settings” all in 1 nice and clean profile .asset? It’s just confusing to have these two outside categories. I am still unsure why there must be this “Add build profile” warning talking about global player settings AFTER a custom build profile was made.
Dream User Experience:
-
File > Build Profiles should be the ONLY window related to build / player settings
-
Remove “Player” from project settings
-
Allow the user to remove any platforms / modules entirely (tvOS and linux server options are clogging up my screen and thoughts)
-
Make the new “build profile.asset” files have no inspector edit options. The inspector for these .assets should simply prompt user / auto open the before mentioned Build Profile window where all the build profile editing is done.
-
Make the new build profile.asset files only produce the data for that 1 respective platform that was selected when making the build profile.A thousand lines of nintendo switch and tvOS settings is nauseating.
-
Remove the concepts of “global”, “platform”, and “shared” build settings. These categories imply that the build profile assets (platform specific??) are capable of overriding the global build settings. This defeats the entire purpose of build profiles which is to make dozens of hyper specific iterations of build platforms and their respective settings.
I think these 6 bullet points would solve the very huge elephant in the room. Backwards compatibility is important and that’s great that there is very clear attention + care for people who have set up automated systems, but I think a lot more people would be happier with this updated and fixed. Cinemachine 3.0 threw out backwards compatibly and everyone was happy because it’s a much cleaner system and takes less than 5 minutes to learn and rework. Unity 6 is a fresh start + perfect opportunity to fix all of this.
4 Likes
Thanks for the feedback, keep it coming! There are great, we are internally talking about all these and about setting the build path per profile that was suggested above.
Yes, but on a more positive note, the rest of the editor UI is pretty much perfect / better than previous LTS
Clean, easier on eyes, nice subtle design choices which end up changing entire workflow for the better.
Now imagine how much time and energy would be saved if all of this editor UI / layout grunt work was offloaded to the community. Unity 6 could have a nice editor themes ecosystem… Editor UI more flexible and customizable… Heavy simplification of UI toolkit / odin inspector… Let the users do all the labor… Users happy, unity happy, everyone happy.
I’d like to repeat the thanks for this, it’s great feedback and I agree with a lot of what you’re suggesting here.
2 Likes
Some solid discussions, I like how @AdamandEveStudios illustrated our plea with just one image.
After using it for a few days on and off, I still don’t understand why this was changed.
If you’re a studio that can multi target in one project then you do this:
If you can’t do this, then you’re too green for multi-platform deploy - because let’s not kid ourselves here, it’s not just a few settings.
The only improved form is with a complete embed of ALL the project settings that are scattered around.
WITH A SEARCH FIELD.
Including SRP assets.
Then I’d tuck it in my layout and never chase settings ever again AND Build buttons at the top makes sense.
Most useful panel ever.
1 Like
What else has buttons on top?
uh… UPM, if you’re lucky enough to expand the layout until the button shows itself
UPM if your layout is wide enough
Prefabs Apply