Error : #nextDefaultNameForObject was sent to nil

[labordep]

The problem is a UI design problem, I think that the input field Choose a name for your object is the way to create a Chest, in fact this is just a search field.
Solution :

• Rename the input field with "Search xxx"
• Confirm buttons need to be disable without chest selection

To reproduce :

1. Inspect an object, and use contextual menu action to Store object into a Chest.

2. The Chest UI is opening, then set a name into the text field.

3. Use the Confirm button, the exception appears.

Same problem when a Chest is exists, you clic on Confirm but without Chest in selection.

[adri09070]

Yes, indeed. I think you will find A LOT of UI design problems.

UI is really not my cup of tea so I would be glad to receive all the advice that you can give

[adri09070]

The problem is a UI design problem, I think that the input field Choose a name for your object is the way to create a Chest, in fact this is just a search field.

Actually, this is nor an input field to create a chest nor a seach field.
This is an input field to give a name (or a key, if you prefer) to the object you're storing, inside the chest that is selected

[labordep]

Yes I know :) but I made a mistake between the search field and the chest creation field :)
From a user point of view there is a UI problem, and the solution can be :

• Rename the search field with "Search a chest..."
• Confirm buttons need to be disable without chest selection

What do you think about these propositions ?

[adri09070]

Yes I know :) but I made a mistake between the search field and the chest creation field :) From a user point of view there is a UI problem, and the solution can be :

• Rename the search field with "Search a chest..."

Actually, what is the search field field you're talking about? I don't understand the problem? You thought that this was a search field for chests but this isn't, and you would like me to rename it (and make it become a real search field), right?
Where should I put the input field to give a name to the object then?

• Confirm buttons need to be disable without chest selection

I agree with this. In fact, I tried to fix it yesterday but I couldn't because of a Spec bug, so... I made an issue on the Spec repository and I don't know what to do in the meantime. I could change the behavior so that it does nothing when nothing is selected but the button would look the same so that's not good.
I'm always frustrated because Spec always makes me believe that a lot of features should work with all widgets but a lot of features just don't work

[labordep]

Sorry I'm editing this topic because I made another confusion between Chest creation field and Var into a Chest creation field. So my topic below is wrong.

Actually, what is the search field field you're talking about? I don't understand the problem? You thought that this was a search field for chests but this isn't, and you would like me to rename it (and make it become a real search field), right? Where should I put the input field to give a name to the object then?

The search field is :

There is some UI problems about this view :

• The user can confuse this field with a chest creation field because the prompt text is "choose a name for your object" and I was not sure of the function of the field, is it the chest creation field ? Not clear.
• When there is no chest (first usage) this confusion increase because you need to create a chest first and this field appears like the way to create chest due to in prompt text.
• The title of the view is not clear : I'm doing to choose a name for my object but how and where ? I need a chest before in my use case (first utilisation).

Why this is "Choose a name for your object" than "Choose a name for you chest" ? I suggest to change the prompt text to "Searching chest" or something like that to remove all ambiguities about this field job.
I suggest to place button on first to help the user in his journey.

If you want we can do a little paper mockup for this panel at the next debug workshop :)

• Confirm buttons need to be disable without chest selection

I agree with this. In fact, I tried to fix it yesterday but I couldn't because of a Spec bug, so... I made an issue on the Spec repository and I don't know what to do in the meantime. I could change the behavior so that it does nothing when nothing is selected but the button would look the same so that's not good. I'm always frustrated because Spec always makes me believe that a lot of features should work with all widgets but a lot of features just don't work

Yes we know, actually we are working with @Nyan11 on a Spec application and we have a lot of problems too. But we need to use and do feedback about Spec usage (and tickets) to make Spec more usable :) We need to exchange about these limitations and solutions to advance, we can work on common tickets :).

[adri09070]

Thanks, I understand better the problem.

I can turn this field into a search field but we still need a creation field (or any equivalent) for the object that is added to a chest.

I have some ideas to make it clearer.

• better window naming and better placeholders
• turn the current creation field into a search field for chests
• move the creation field above the object table instead of the chest table (actually, I think that I tried to put it there and I found that the object table was too small when I did that so I changed it. But, I will try to find a workaround).
• maybe putting the object in the default chest if no chest is selected?

Still, I'm interested in doing a paper mockup at the next debugging workshop :)