Improve [for efficiency] the flow to add a new GUI object from scratch.

[LuniMoon]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Based on Keith_1357's request on the forum.

Today's System:

For the flow "New object from Scratch" when it comes to GUI elements

The system asks the user for their selected ressource

And after its selection, it sends the user to the Scene (closes all the modals).

---

Suggested Flow:

(Increase efficiency)

• The user selects its GUI element
• The system opens the Object Properties

to reflect the same flow that the system does when adding other type of object, and to increase efficiency.

Bonus:

[see forum issue] If the user clicks a GUI element, but do not want to add it to the object list, the system does it anyway.
Change: To add an object to the object list, the user would have to click on the "Apply" button on the bottom right in order to add it to the list.

• Adding automatically the selection to the project might have been done for efficiency, but it is not following the system UI interaction standards from other windows. The system must stay the same (tho I agree that the patters must be reworked).

Steps to reproduce

1. Add a new object from scratch
2. Select a GUI element (button, slider, bar)
3. The system will take you to the Scene screen.

GDevelop platform

Desktop, Web, Mobile

GDevelop version

5.3.181

Platform info

OS (e.g. Windows, Linux, macOS, Android, iOS)

OS Version (e.g. Windows 10, macOS 10.15)

Browser(For Web) (e.g. Chrome, Firefox, Safari)

Device(For Mobile) (e.g. iPhone 12, Samsung Galaxy S21)

Additional context

No response

[4ian]

I'm not sure we want to go in this direction.
These objects are "custom objects", which can be sensibly longer to configure than traditional objects because they are more complex, especially if you want to get a good looking result.

We have a button for starting from 0, it's called "Skip and create from scratch" - I don't have numbers but I assume usually it's just faster to start with an existing button (and we can add more when some are made by the community).

[LuniMoon]

I agree. Custom objects require some fine work and tuning and the V0 UI screen is cognitive heavy.
I do have memories of having this "the custom object parameters are complex" conversation when we did the "skip and create from scratch" button for V0.

However, the creation flow is not as the one that a user would have found in other elements.
We could argue that it is to protect the user from a heavy UI screen, but I think that not respecting the patterns hurts system reliability: A user will "muscle memorise" that X action is located on W corner which button is a certain colour. While using software, we rely and trust that these learned patterns because they repeat across the UI.

However on GDevelop these patterns could be irregular depending on the flow.
On this screen, the Primary button - which is often "Accept" on these flows - is "Skip and create from scratch". Also, after clicking a custom object; the user cannot "cancel" because the system selects the object (without them clicking "Accept"), closes the modal, and automatically goes to the Scene.
This is not the pattern that is present in the flow for other object types. This issue changes system reliability requiring time to carefully read the buttons (impacting efficiency).

The requested change is to respect the UI pattern across the platform. I can eventually take a"how to improve button custom object usability" so the apparition of that screen is "less frightening".
As for how this change will impact users now... I don't think it's a dangerous move because users have already seen and interacted with the properties screen from other object types. My guess is that they'll know how to navigate it/use it for a custom object too.

The suggested button structure for this custom object dialog could be: Cancel [Secondary], Skip and create from scratch [Secondary], Accept [Primary].

[D8H]

On this screen, the Primary button - which is often "Accept" on these flows - is "Skip and create from scratch".

What do you suggest?
Do you think that users could miss the button and a thumbnail should also be added for an empty object?

Also, after clicking a custom object; the user cannot "cancel" because the system selects the object (without them clicking "Accept"), closes the modal, and automatically goes to the Scene.

Even if the object creation was cancelled, the resources would remain in the project. I'm not sure there is an easy way around this.

The requested change is to respect the UI pattern across the platform.

I think that the current behavior doesn't break the UI logic:

• the user choose a ready to use configuration, I bet they don't need to change the configuration 99% of the time, so they don't need to see an extra dialog just to close it
• the user choose to setup the object themselves from scratch, the object editor is shown

[4ian]

On the forum issue, there were some alternative suggestions. I think always opening the object editor at the end was one of them.

[LuniMoon]

I'll back pedal a little bit because this issue is pointing to a flow-specific UX bug (adding custom UI object types to the project), but this flow is not optimal because it is a consequence of a problem that contains this particular UI interaction. I'll explain:

Said "zoomed-out" problem is the fact that in certain dialogs (modals), the buttons do not work as "promised" by the copy they display: a "Cancel" button does not cancel the action (an object was created on the object list), a "Close" button closes a modal but it isn't clear if the changes made on that level are saved... and so on -see related forum issue here-.
These UI inconsistencies impact the efficiency of "Adding a GUI object from scratch", and other flows -see Tristan's feedback on core discord-. The output of what a "cancel" button is, can vary from modal to modal, and that impacts: trust in the system (the outcome is hard to predict), and efficiency (the user has to correct what the product did against their expectations).

Now, back to this issue: There is a modal step in which the "Accept" or "Apply" button that is present in all dialogs, is not there and it is not following the same steps as equivalent flows... I think this is a consequence of the UX issue that dialogs aren't very consistent (which I think is the root of this, and similar frictions).

A bigger action to execute is to standardise all modal buttons (copy, and what they do) to improve efficiency and product trust.
A smaller scope (this issue for this flow) would be:
On the "new object from scratch" modal for UI components:

• The user clicks on a selected object and the system does nothing (this would allow the user to change their choice in case it is not their final).
• To select an object and add it to their object list, the user has to click an "Accept" button (currently inexistent).

These changes leave us with the following buttons:

• Close (secondary) -> Currently there -tho I wonder if "Cancel" isn't a better term for this so it's clear for the user that the system won't process any change on that dialog-.
• Skip and create from scratch (secondary) -> Existent, but added as primary
• Accept (primary) -> Not existent yet.

As for opening the object parameters just after (just as adding a sprite does)... I think the user is right: we should open it for consistency with other flows. Tho, there is a real concern of not wanting to show that screen because it could appear cognitive heavy, or because it won't be needed 99% of the time by other types of users. To make a decision on this, I would check any usability data (if we have it, and it not we might want to consider it) to have an idea on what percentage is opening their custom object dialogs to personalise their values. I do agree with Davy and think that it won't be more than 60%... for now, asking the user is the only way I can think of to acquire that info.

[D8H]

On the "new object from scratch" modal for UI components:

• The user clicks on a selected object and the system does nothing (this would allow the user to change their choice in case it is not their final).
• To select an object and add it to their object list, the user has to click an "Accept" button (currently inexistent).

It adds an extra click but I agree it's better.

These changes leave us with the following buttons:

• Close (secondary) -> Currently there -tho I wonder if "Cancel" isn't a better term for this so it's clear for the user that the system won't process any change on that dialog-.
• Skip and create from scratch (secondary) -> Existent, but added as primary
• Accept (primary) -> Not existent yet.

What do you think about a special thumbnail for "create from scratch" that is selected by default?
This way only 2 modal buttons are needed:

• Close
• Accept (as accept to start from scratch or accept the selected asset)

[LuniMoon]

What do you think about a special thumbnail for "create from scratch" that is selected by default?

I think you are right Davy: 90% of the times a user wouldn't want to start an object from scratch*. Therefore such option shouldn't be a primary action, so the UI should give it less visual importance.
I think that a thumbnail for "create from scratch" would give it more visual importance than needed (since such action won't be very popular cause starting from scratch can be laborious).

Therefore, I think that turning the "Skip and create from scratch" existent button into a Secondary Button is a good solution.

*What it seems to be happening according to the user is that they want to personalise the values and names of pre-made objects. Not starting an object from scratch. That is why they were requesting the parameters step on the flow: to be able to make these simple changes as part of their process, rather than having to open each object separetly to do so.